Zmiana rejestru kodów źródłowych w obiekcie deweloperskim (rgymgr)

Wprowadzenie

Narzędzie rgymgr (migracja rejestru) przenosi dane z „rejestru” klas Java do nowych obiektów programistycznych przy użyciu danych runtime. Na przykład dla rejestrów wymiany danych, które zostały udostępnione w klasie Java com.cisag.app.bi.Registry lub do migracji rejestrów aplikacji specyficznych dla typu organizacji wyświetlanych w klasie Java com.cisag.app.multiorg.log.ApplicationRegistry.

Grupa docelowa

  • Programista aplikacji

Opis

Narzędzie rgymgr służy do przenoszenia rejestru, który został wcześniej zapisane w tak zwanych klasach Java „rejestru”, do obiektów programistycznych. Dotyczy to następujących obiektów programistycznych:

  • obiekt programistyczny Application– przyjmowane są odniesienia organizacyjne z klasy Java com.cisag.app.multiorg.log.ApplicationRegistry.
  • obiekt programistyczny Function– przyjmowane są odniesienia organizacyjne z klasy Java com.cisag.app.customizing.log.FunctionRegistry.
  • obiekt programistyczny Java class – przyjmowane są zamienniki klas z klasy Java com.cisag.app.Replacements.
  • obiekt programistyczny Business object registry – rejestracje, które są istotne dla wymiany danych i są rejestrowane w klasie Java com.cisag.app.bi.Registry oraz rejestracje filtrów dla wpisów menu kontekstowego z klasy Java com.cisag.app.general.log.CisInitializerImpl są łączone i tworzony jest nowy obiekt programistyczny Rejestr obiektów biznesowych.

Warunkiem wstępnym jest utworzenie zadania programistycznego. Gdy narzędzie jest uruchomione, dane runtime są analizowane, a odpowiednie obiekty programistyczne są blokowane w zadaniu programistycznym na podstawie danych.

Uwaga
Jeśli obiekt programistyczny, który został już zmigrowany, nadal istnieje w jednej z klas Java „Registry”, ten obiekt programistyczny jest pomijany.

Polecenie

Poniżej znajduje się polecenie zawierające wszystkie możliwe parametry.

rgymgr [-j:<text>] [-t:<vs-1> … -t:<vs-n>] [-p:<str-1> … -p:<str-n>] [-o:<str-1> … -o:<str-n>] [-noAppend] [-verbose]

Parametry

Parametry polecenia zostały wyjaśnione w poniższej tabeli. Parametry w nawiasach kwadratowych są opcjonalne, podczas gdy pozostałe są obowiązkowe. Gwiazdka (*) może być określona jako symbol zastępczy dla niektórych parametrów, aby móc wyświetlić wszystkie możliwe wartości. Nie wszystkie parametry mogą być określone więcej niż jeden raz; tylko te z następującym dodatkiem do zmiennych parametrów są dozwolone do wielokrotnego określenia: „<str-1> … <str-n>”.

Parametry Wyjaśnienie
[-j:<str>] Identyfikacja zadania programistycznego, które ma zostać wykorzystane.
[-t:<vs-1> … -t:<vs-n>]. Typ obiektu deweloperskiego. Możliwe wartości:

  • Zastosowanie
  • Funkcja
  • Klasa Java
  • Rejestr obiektów biznesowych
[-p:<str-1> … -p:<str-n>]. Ograniczenie przestrzeni nazw.
[-o:<tekst-1> … -o:<tekst-n>*]. Ograniczenie do nazw obiektów programistycznych. Bez przestrzeni nazw.
[-noAppend] W przypadku podania parametru wpisy z bieżącej klasy Java Registry; com.cisag.app.bi.Registry nie są dodawane ani zastępowane w istniejących rejestrach obiektów biznesowych.
Uwaga
Parametr dotyczy wpisów, które nie są przypisane do przestrzeni nazw CISAG.
[-verbose] Umożliwia wyświetlanie danych wyjściowych w powłoce narzędzi.

Procedura aktualizacji wydania

Jeśli przeprowadzana jest aktualizacja systemu, należy zwrócić uwagę na następujące kwestie podczas wywoływania narzędzia rgymgr:

  • zmiany wprowadzone do klasy Java Registry: com.cisag.app.bi.Registry nie mogą być stosowane przed wywołaniem narzędzia. W przeciwnym razie zmiany wprowadzone w tej klasie Java Registry przed zmianą wydania zostaną utracone.
  • narzędzie musi zostać wywołane na serwerze aplikacji, który ma „rejestrowe” klasy Java w ścieżce klas, które mają status przed zmianą wydania. W tym przypadku te klasy Java są traktowane jako źródło migracji.
  • jeśli rejestr obiektów biznesowych już istnieje, wpis w klasie Java Registry (z wyjątkiem com.cisag.app.bi.Registry) jest ignorowany.
  • wpisy z klasy Java com.cisag.app.bi.Registry są domyślnie dodawane do istniejącego rejestru obiektów biznesowych (np. dodatkowe wyszukiwanie OQL) lub istniejące elementy (np. ImportController) w tym obiekcie programistycznym są zastępowane.

Parametr -noAppend nie powinien być używany, w przeciwnym razie zmiany wprowadzone w tej klasie Java Registry przed zmianą wydania nie zostaną przeniesione do istniejących rejestrów obiektów biznesowych.

Czy ten artykuł był pomocny?