Grupa docelowa
Każdy deweloper wprowadzający zmiany w schemacie bazy danych powinien być zaznajomiony z podstawową zasadą działania narzędzi generujących.
Wymagania wstępne
Do zrozumienia niniejszego artykułu wymagana jest znajomość podstaw działania usługi persystencji. Szczegółowe informacje dotyczące usługi persystencji znajdują się w artykule Persistence service.
Opis
Zmiany modelu danych w obiektach biznesowych (Business Object) muszą być starannie zaplanowane, ponieważ nieprawidłowo przeprowadzone modyfikacje mogą prowadzić do utraty danych u klienta. Zmiany modelu danych powinny być wykonywane w systemie produkcyjnym możliwie jak najszybciej.
Klasa aktualizacji zawiera reguły oraz algorytmy umożliwiające realizację zadań związanych ze zmianami modelu danych. Zakres klasy aktualizacji ogranicza się do zadań podstawowych, czyli operacji wykonywanych na kolumnach obiektu biznesowego, takich jak inicjalizacje oraz modyfikacje. Dla każdej zmienionej kolumny obiektu biznesowego klasa aktualizacji zawiera informację określającą sposób obsługi danej zmiany.
Klasa aktualizacji jest tworzona podczas pierwszej zmiany lub nowego utworzenia obiektu biznesowego. Przy kolejnych zmianach dodawane są odpowiednie metody, które mogą lub muszą zostać zmodyfikowane przez programistę. Proces generowania nigdy nie usuwa metod ani zmiennych z klas aktualizacji – w razie potrzeby dodawane są wyłącznie nowe metody.
Klasa aktualizacji może być modyfikowana wyłącznie w tym systemie, w którym powstał lub został zmieniony powiązany obiekt biznesowy albo rozszerzenie. Takie podejście zapobiega powstawaniu konfliktów w tej klasie podczas instalowania aktualizacji oprogramowania, która ją zawiera, oraz sytuacji, w której powiązany obiekt biznesowy zostałby skonwertowany z użyciem zmodyfikowanej klasy zamiast klasy pochodzącej z aktualizacji oprogramowania.
Dla każdego obiektu biznesowego oraz każdego rozszerzenia istnieją oddzielne klasy aktualizacji. Każda z tych klas odpowiada za atrybuty przypisanego obiektu. Dzięki temu nie powstają konflikty wymagające ręcznej ingerencji, na przykład w sytuacji, gdy standardowy obiekt biznesowy jest rozszerzany za pomocą rozszerzenia. Klasy aktualizacji są zapisywane w przestrzeni nazw com.<prefiks_deweloperski>.upd, na przykład com.cisag.upd.app… lub com.cisag.upd.sys….
Klasy aktualizacji implementują logikę umożliwiającą transformację trwałych danych obiektu biznesowego lub rozszerzenia z dowolnej wersji źródłowej do aktualnej wersji docelowej.
Zmiany modelu danych są analizowane osobno dla każdej kolumny. W standardowym trybie przetwarzania wszystkie zmiany kolumn są rejestrowane z użyciem domyślnego zachowania, które może zostać nadpisane przez programistę. Różnice pomiędzy schematem źródłowym a schematem docelowym decydują o tym, które metody zostaną zastosowane.
Klasy aktualizacji obsługują następujące operacje:
- Inicjalizacja nowych kolumn (metoda Init)
- Stałe wartości początkowe
- Zmiana typu danych istniejących kolumn (metoda ChangeDatatype)
- Niezgodna zmiana typu danych
Przykład klas aktualizacji
Ten przykład ma na celu wyjaśnienie działania klas aktualizacji. Zmiany w obiekcie biznesowym i zastosowane metody klasy aktualizacji zapisano pogrubioną czcionką.
Przykład standardowy
W powyższym przykładzie Business Object Item jest zmieniany dwukrotnie. Najpierw atrybut description zostaje skrócony ze 100 do 80 znaków, a następnie dodany zostaje atrybut unit.
-
Metoda changeDatatype€description€str100_str80 – oblicza niekompatybilną zmianę typu danych atrybutu description ze 100 do 80 znaków
-
Metoda init€unit – oblicza wartość początkową dla nowego atrybutu unit
Metody są wywoływane podczas wykonywania zmiany modelu danych.
Przykład rozwoju partnera
Najpierw tworzy się rozszerzenie dla obiektu biznesowego Item z atrybutami abc_type i abc_color, a następnie importuje się wersję 1.1 obiektu Item. W przypadku rozszerzenia nie jest wymagana ręczna obsługa konfliktów w klasach aktualizacji obiektu biznesowego.
-
Metoda init€abc_type – oblicza wartość początkową dla kolumny abc_type
-
Metoda init€abc_color – oblicza wartość początkową dla kolumny abc_color
Podczas tworzenia rozszerzenia wywoływane są metody klas aktualizacji rozszerzenia. W przypadku zmiany bazowego obiektu biznesowego Item nie ma konieczności zmiany klas aktualizacji i nie są wywoływane żadne metody klasy aktualizacji rozszerzenia.
Przykład rozwoju klienta
Analogicznie do systemu rozszerzeń partnerskich, również w systemie adaptacji klienta nie jest wymagana ręczna obsługa konfliktów w klasach aktualizacji obiektu biznesowego ani rozszerzeń obiektu biznesowego z systemu rozszerzeń partnerskich. Wraz z rozszerzeniem obiektu biznesowego XYZ_Item dodawane są atrybuty typu Part xyz_coordinate z Part Coordinate oraz xyz_length z Part Quantity.
-
Metoda init€xyz_length – oblicza wartość początkową kolumn atrybutu typu Part xyz_length.
Part com.cisag.app.general.obj.Quantity jest traktowany przez klasy aktualizacji jako całość, dlatego może zostać zainicjalizowany jako całość i istnieje tylko jedna metoda inicjalizacji (patrz sekcja Datentypen). -
Metody init€xyz_coordinate…€… – obliczają wartości początkowe kolumn atrybutu typu Part xyz_coordinate.
Dla Part Coordinate nie ma specjalnego traktowania, dlatego wszystkie kolumny muszą zostać zainicjalizowane osobno i posiadają oddzielne metody inicjalizacji (patrz sekcja Datentypen).
Zmiana modelu danych
Przebieg zmiany modelu danych zależy od sposobu przeniesienia danych z wersji źródłowej do wersji docelowej.
Generowanie obiektu biznesowego podczas prac deweloperskich przebiega w następujących krokach:
Po edycji obiektu biznesowego, widoku lub Part w aplikacji Obiekty deweloperskie należy wygenerować ten obiekt za pomocą narzędzia crtbo. Podczas tego procesu generowane są źródła Java dla klas Mapper i klas aktualizacji, a także tabele tymczasowe. Następnie, w razie potrzeby, klasy aktualizacji muszą zostać dostosowane przez dewelopera. Zmodyfikowane klasy aktualizacji umożliwiają testową konwersję danych do tabel tymczasowych.
Serwer aplikacji dewelopera uzyskuje dostęp do tabel tymczasowych (patrz następna sekcja), co umożliwia sprawdzenie, czy konwersja przebiegła pomyślnie. Po zatwierdzeniu zadania deweloperskiego dane są ponownie konwertowane, a zmiana zostaje aktywowana na wszystkich bazach danych. Po aktywowaniu zmiany modelu danych możliwe jest aktywowanie zadania deweloperskiego.
Zmiany modelu danych zazwyczaj stanowią całość wraz ze zmianami w przetwarzającym kodzie źródłowym. Możliwe jest przetestowanie konsekwencji zmiany schematu przed jej aktywowaniem, dzięki czemu unika się potencjalnego zakłócenia pracy innych użytkowników systemu. Nowe klasy Mapper utworzone w bieżącym zadaniu deweloperskim uzyskują dostęp do tabeli tymczasowej z nowym schematem i skonwertowanymi danymi, podczas gdy stare (aktywne w systemie klasy Mapper) nadal korzystają z dotychczas aktywnych tabel w starym schemacie.
Należy pamiętać, że tabele tymczasowe są tworzone wyłącznie dla tych obiektów biznesowych, które zostały zablokowane w zadaniu deweloperskim i w nim wygenerowane. Dostęp do tych tabel jest domyślnie możliwy tylko w trybie odczytu. Z tego powodu testowanie aplikacji jest możliwe jedynie w ograniczonym zakresie. Parametr startowy serwera aplikacji -writeConvertedTables umożliwia włączenie zapisu do tabel tymczasowych. Jego użycie należy dokładnie przeanalizować, ponieważ możliwe skutki uboczne są trudne do przewidzenia.
Jeśli w zadaniu deweloperskim zablokowano Entity, a jego zależności Dependents nie zostały zablokowane, podczas tworzenia nowej instancji Entity zostanie ona zapisana w tabeli tymczasowej, natomiast Dependents tej instancji zostaną zapisane w aktywnych tabelach. Pozostali użytkownicy, korzystający ze starych, nadal aktywnych klas Mapper, zapisują nowe Entities wyłącznie w aktywnych tabelach. W rezultacie w bazie danych powstają niespójne stany. Podobne problemy mogą występować również w przypadku schematów numeracji i liczników.
Aby odczytać dane z tabeli tymczasowej w aplikacji OQL-Anweisungen, należy umieścić słowo kluczowe CONVERTED_TABLE pomiędzy nazwą obiektu biznesowego a nazwą aliasu. Dostęp do aktywnej tabeli odbywa się przy użyciu słowa kluczowego ACTIVE_TABLE.
Nowe tabele mogą zostać aktywowane tylko wtedy, gdy zadanie deweloperskie zostało zatwierdzone, ale nie zostało jeszcze aktywowane. Zmiany w bazie danych stają się widoczne dla innych użytkowników systemu dopiero po aktywacji. Po aktywacji obiektu biznesowego lub widoku należy ponownie uruchomić wszystkie serwery, które uzyskują dostęp do tego obiektu biznesowego.
Ogólny dostęp do obiektów biznesowych
W klasach aktualizacji nie jest możliwy dostęp do obiektów biznesowych przy użyciu standardowych klas Mapper obiektu biznesowego. Wszystkie obiekty biznesowe są odczytywane przy użyciu generycznych klas Mapper. W tej sekcji opisano generyczny dostęp do obiektów biznesowych.
Schemat obiektu
Każdy obiekt biznesowy jest w pełni opisany za pomocą metadanych. Metadane schematu obiektu biznesowego można odczytać jako com.cisag.pgm.appserver.CisObjectSchema w CisObjectManager.
W klasach aktualizacji schemat źródłowy i docelowy zmiany modelu danych można odczytać za pomocą metod CisUpdateBase:getFromSchema oraz CisUpdateBase:getToSchema.
Schemat zawiera między innymi opis wszystkich kolumn obiektu biznesowego. Opis kolumn można odczytać w schemacie za pomocą metod CisObjectSchema:getColumn oraz CisObjectSchema:getColumns.
Dostęp ogólny
Usługa persystencji standardowo uzyskuje dostęp do obiektów biznesowych za pomocą wygenerowanych klas Business Object Mapper. Klasy Mapper muszą dokładnie odpowiadać tabeli wygenerowanej w bazie danych, w przeciwnym razie dane nie mogą być poprawnie odczytywane i zapisywane. Dla historycznych wersji obiektu biznesowego takie klasy Mapper nie są już dostępne.
Klasa com.cisag.pgm.datatype.CisGenericObject umożliwia generyczny dostęp do dowolnych wersji obiektu biznesowego. Klasy aktualizacji wykorzystują te generyczne obiekty podczas zmian modelu danych. Każdy dostęp do usługi persystencji, np. getObject, który w normalnym przypadku zwraca instancję obiektu biznesowego, w klasach aktualizacji zwraca obiekt generyczny.
Podczas generycznego dostępu do obiektów biznesowych można używać wszystkich metod dostępu Object Managera, np. getObject, getObjectIterator, getResultSet itd. Object Manager zawsze uzyskuje dostęp do wersji obiektu biznesowego aktualnie aktywnej w bazie danych. Dzięki generycznemu dostępowi możliwe jest odczytanie stanu bazy danych sprzed zmiany modelu danych. Nie jest natomiast możliwy dostęp do wyniku transformacji danych. Nie można również używać metod Object Managera służących do zapisu w bazie danych – możliwy jest wyłącznie odczyt danych.
Kolumny generycznego obiektu biznesowego mogą być odczytywane za pomocą ścieżki atrybutu. Dla każdego prymitywnego typu danych oraz dla Special Parts dostępne są odpowiednie metody Get i Set.
Aby sprawdzić, czy dla kolumny atrybutu typu Part można odczytać prawidłową wartość, zapytanie kolumny logicznej tego atrybutu Part musi zwrócić wartość prawda. Nazwa tej kolumny odpowiada ścieżce atrybutu Part.
Za pomocą metody buildPrimaryKey można utworzyć klucz główny lub zależny od czasu klucz główny obiektu biznesowego.
CisGenericObject item = (CisGenericObject)om.getObject(
CisGenericObject.buildPrimaryKey(
“com.cisag.app.general.obj.Item“,itemGuid)
oldDescription=item.getString(”description“);
Należy zwrócić uwagę, że odczyt atrybutu daty lub znacznika czasu, którego logiczny typ danych bazuje na typie logicznym com.cisag.sys.kernel.ObjectTimeStamp, musi być wykonywany metodą getTimeStamp(), która zwraca obiekt java.util.Date. W razie potrzeby wartość CisDate należy utworzyć samodzielnie.
Date dateValue = item.getTimeStamp(“purchaseStatusDate”);
Byte[] timeZoneGuid = item.getGuid(“_timeZoneGuid”);
CisDate purchaseStatusDate =
com.cisag.pgm.datatype.CisDateUtility.createCisDate(timeZoneGuid,
dateValue);
…
Korzystanie z transakcji
Przed wywołaniem metody klasy aktualizacji system automatycznie otwiera transakcję dla bazy danych, która ma zostać poddana konwersji. Dzięki temu wszystkie standardowe użycia Object Managera działają w odpowiednim kontekście transakcji. W przypadku korzystania z automatycznie otwartej transakcji nie jest możliwe użycie podtransakcji.
Dozwolone jest otwarcie dodatkowej transakcji najwyższego poziomu za pomocą metody menedżera transakcji beginNew(byte[] databaseGuid). Przekazana GUID bazy danych musi odpowiadać GUID bazy danych, która ma zostać poddana konwersji. Wartość tę należy ustalić za pomocą metody getDatabaseGuid() klasy aktualizacji.
Dla nowo utworzonej transakcji możliwe jest również tworzenie podtransakcji.
Klasy aktualizacji
Klasy aktualizacji określają, w jaki sposób dane zapisane w schemacie źródłowym są przenoszone do schematu docelowego. Klasy aktualizacji definiują transformację danych dla każdej kolumny w obiekcie biznesowym za pomocą metod Init oraz ChangeDatatype.
W sekcji Opis przedstawiono klasę aktualizacji dla obiektów biznesowych i rozszerzeń. W tej sekcji opisano sposób implementacji zmiany modelu danych przez dewelopera w tej klasie aktualizacji.
Metoda Init
Metoda Init oblicza wartość początkową podczas tworzenia nowej kolumny. Wartość początkowa jest wymagana wtedy, gdy kolumna istnieje w schemacie docelowym, ale nie występuje w schemacie źródłowym. Metoda Init jest generowana w klasie aktualizacji z ustaloną wartością początkową. W razie potrzeby metoda Init może zostać zmieniona w klasie aktualizacji w celu obliczenia innej wartości początkowej.
Nazwa metody Init jest tworzona według następującego schematu:
<Java-Datatype> init€<AttributePath> ()
Ścieżka atrybutu kolumny odpowiada nazwie kolumny w OQL. Nawiasy kwadratowe [] oraz kropka . są jednak zastępowane znakiem dolara $, aby ścieżka atrybutu mogła zostać użyta jako identyfikator metody.
Sekcja Datentypen zawiera dodatkowe informacje dotyczące typu danych w nazwie metody.
Dla atrybutu typu Part oprócz metod Init powiązanych kolumn generowana jest dodatkowo metoda Init dla logicznej kolumny Part. Jako ścieżkę atrybutu wykorzystuje ona ścieżkę atrybutu Part. Wartość zwracana przez metodę określa, czy wartość Part jest prawidłowa. Aby zainicjalizować atrybut Part wartością, metoda Init logicznej kolumny Part musi zostać nadpisana tak, aby zwracała wartość true.
Metoda Init jest generowana w klasie aktualizacji obiektu biznesowego, jeśli kolumna należy do atrybutu obiektu biznesowego. Jeśli kolumna należy do atrybutu rozszerzenia obiektu biznesowego, metoda Init jest generowana w klasie aktualizacji rozszerzenia obiektu biznesowego.
Obliczenie wartości początkowej kolumny description z typem danych String i długością 100. String init€description () { Ponowne utworzenie kolumny występuje na przykład wtedy, gdy kolumna została utworzona w wersji V1, usunięta w V2 i ponownie utworzona w V3. Technicznie nie ma tu różnicy w porównaniu z utworzeniem nowej kolumny, jednak może się zdarzyć, że w klasie aktualizacji nadal istnieje wcześniejsza metoda Init. Deweloper powinien to sprawdzić i w razie potrzeby dostosować. Generowanie nigdy nie usuwa istniejących metod z klasy aktualizacji. Jeśli atrybut typu Part ma zostać zainicjalizowany złożoną wartością, metoda init() dla logicznej kolumny Part musi zwracać wartość true. W ten sposób wskazuje się, że wartość Part istnieje. Nazwa tej kolumny odpowiada ścieżce atrybutu atrybutu Part. Dla wszystkich kolumn Part generowane są odpowiednie metody init(). Podczas tworzenia nowej kolumny z Special-Part generowana jest tylko jedna metoda init(). Typ danych kolumny może zostać zmieniony. Aby przekształcić zawartość kolumny ze starego typu danych do nowego, wymagane jest wykonanie obliczenia. Obliczenie to jest realizowane w metodzie ChangeDatatype, która jest generowana w klasie aktualizacji: Odpowiednia metoda ChangeDatatype jest oczekiwana i wykonywana wtedy, gdy podczas konwersji zostanie wykryta zmiana typu danych między schematem źródłowym a docelowym. Jeśli typ danych kolumny zostanie zmieniony wielokrotnie, dla każdej potencjalnie występującej zmiany typu danych wymagana jest odpowiednia metoda. Generowanie tworzy jednak tylko jedną metodę dla ostatniej zmiany typu danych w systemie deweloperskim. Za utworzenie ewentualnie brakujących metod ChangeDatatype odpowiada deweloper. Analogicznie metody ChangeDatatype mogą zostać usunięte, jeśli odpowiednia zmiana schematu nie została jeszcze dostarczona. Decyzję w tym zakresie również podejmuje deweloper. tworzona jest nowa kolumna z typem danych boolean typ danych zostaje zmieniony na short typ danych zostaje ponownie zmieniony, tym razem na String W takiej sytuacji w drugim kroku generowanie utworzy metodę ChangeDatatype z boolean na short. W trzecim kroku powstanie metoda ChangeDatatype z short na String. Jeśli zmiana modelu danych z pierwszego kroku została już dostarczona, deweloper musi dodatkowo utworzyć metodę ChangeDatatype z boolean na String. Z drugiej strony metody ChangeDatatype mogą zostać usunięte, jeśli zmiany schematu nie zostały jeszcze dostarczone i na potencjalnych systemach docelowych będzie wykonywana jedynie inicjalizacja typu String. Zmiana modelu danych jest kompatybilna, jeśli prymitywny typ danych nie zostaje zmieniony, a długość typu danych zostaje zwiększona. Wszystkie pozostałe zmiany są niekompatybilne. zmiana z String 80 na String 100 jest kompatybilna zmiana z String 100 na String 90 jest niekompatybilna zmiana z Decimal 10,3 na Decimal 17,6 jest kompatybilna zmiana z Short na ValueSet jest niekompatybilna zmiana z Boolean na ValueSet jest niekompatybilna Jeśli zmiana typu danych jest niekompatybilna, metody ChangeDatatype są generowane w klasie Update, ale bez zdefiniowanej wartości zwracanej. Celowo prowadzi to do błędu kompilacji, dzięki czemu metoda musi zostać zaimplementowana przez dewelopera. Niekompatybilne zmiany modelu danych zawsze prowadzą do konwersji na poziomie instancji. Jeśli instancja nie powinna zostać skonwertowana, lecz usunięta, w jednej z wywoływanych metod zmiany należy wywołać metodę delete(). Powoduje to przerwanie konwersji bieżącej instancji i nie zostaje ona przeniesiona. Po wywołaniu metody delete() należy zakończyć metodę zmiany instrukcją return. Po delete() nie mogą występować żadne dalsze instrukcje. Typ danych jest częścią metod Init i Change. W nazwach metod typ danych jest kodowany w następujący sposób: Powyższe typy danych są traktowane w klasach Update jako całość, tzn. istnieje tylko jedna metoda zmiany, nawet jeśli w tabeli zostało z nich wygenerowanych kilka kolumn. Wszystkie Parts i Arrays, które nie są wymienione w tabeli, nie są traktowane jako całość – każda kolumna wygenerowana z tych elementów jest obsługiwana oddzielnie w klasach Update. Do transformacji danych obiektu biznesowego w bazie danych tworzona jest jedna lub więcej instancji klas Update. Każda instancja klasy Update jest używana wyłącznie dla instancji obiektu biznesowego w danej bazie danych. Jeśli instancje obiektu biznesowego mają zostać przekształcone w innej bazie danych, tworzone są nowe instancje klasy Update. Klasy Update przekształcają dane z wersji źródłowej – czyli wersji aktywnej w bazie danych – do wersji docelowej, która dla dewelopera jest wersją zablokowaną w zadaniu deweloperskim. Schemat wersji źródłowej i docelowej można odczytać za pomocą następujących metod: Metoda initialize() klasy Update jest wywoływana przed użyciem każdej instancji. Metoda initialize może zostać nadpisana w klasie Update, aby zainicjalizować instancję klasy do użycia w danej bazie danych. W tej metodzie możliwy jest jedynie odczyt danych z obiektów biznesowych przy użyciu generycznego dostępu (patrz sekcja Generischer Zugriff auf Business Objects). W metodzie initialize należy dla każdej inicjalizacji sprawdzić za pomocą metody getFromSchema(), czy jest ona wymagana. W tym celu należy wykorzystać schemat wersji źródłowej. Dla metody Init kolumny myUnit wartość domyślna jest obliczana w metodzie initialize. Wartość ta jest potrzebna tylko wtedy, gdy kolumna myUnit nie istnieje w wersji źródłowej. Podczas transformacji danych często wymagany jest dostęp do danych aplikacji Konfiguracja. Dostęp do danych aplikacji Konfiguracja jest możliwy przy użyciu następujących metod: Należy pamiętać, że klasy Update muszą być wykonywalne niezależnie od stanu aplikacji Konfiguracja. Aby klasy Update mogły działać również w „pustej” bazie danych, zawsze należy uwzględnić możliwość, że metody te mogą zwrócić wartość null. Konwersja danych jest bardzo ważnym etapem. Jeśli podczas konwersji dane zostaną przeniesione nieprawidłowo, w najgorszym przypadku mogą zostać utracone. Jeśli nie jest możliwe odtworzenie pierwotnych danych, konieczne jest przywrócenie kopii zapasowej odpowiedniej bazy danych lub całego systemu. Jeśli błędna konwersja została dostarczona klientowi, skutki są jeszcze poważniejsze. Z tego powodu zaleca się jak najdokładniejsze testowanie konwersji, dopóki obiekt biznesowy nie został jeszcze aktywowany. Konwersja danych może być wykonywana w obrębie bazy danych, jeśli z klas Update do konwersji wymagane są wyłącznie stałe wartości początkowe lub kompatybilne zmiany modelu danych. Jeśli choć jedna wymagana metoda wymaga konwersji na poziomie instancji, konwersja musi zostać wykonana za pośrednictwem serwera aplikacji. Uwaga Metody wymagane dla przeskoku wersji można wyświetlić za pomocą polecenia wrkupdcls –printUpgrade. Konwersja wykonywana w bazie danych może odbywać się bez użycia tabel tymczasowych. Konwersja przebiega całkowicie w obrębie bazy danych, bez konieczności przesyłania instancji obiektu biznesowego do serwera aplikacji. Taka konwersja zazwyczaj wymaga znacznie mniej czasu niż zmiana modelu danych wykonywana dla każdej instancji. Aktywna tabela jest zmieniana za pomocą polecenia ALTER TABLE. Podczas prac deweloperskich zawsze tworzona jest tabela tymczasowa, aby można było lokalnie testować także jeszcze nieaktywowane zmiany modelu danych. W przypadku złożonych konwersji klasy aktualizacji muszą być wywoływane dla każdej instancji. Na potrzeby konwersji tworzona jest tymczasowa tabela do przechowywania pośredniego skonwertowanych instancji. Konwersja odbywa się przez Application-Server, jeżeli co najmniej jedna metoda, która musi zostać wywołana z klas aktualizacji dla zmiany modelu danych, wymaga konwersji dla poszczególnych instancji. Konwersja za pośrednictwem serwera aplikacji jest wolniejsza niż konwersja za pośrednictwem bazy danych, ale umożliwia specjalną logikę konwersji poszczególnych instancji. W przypadku przeprowadzania konwersji przez serwer aplikacji prowadzi to do znacznie dłuższych czasów działania podczas wgrywania aktualizacji oprogramowania do systemu produkcyjnego. Jeżeli nowa wersja obiektu biznesowego zawiera obiekt BLOB, konwersja zawsze odbywa się przez serwer aplikacji. Za pomocą właściwości com.cisag.sys.kernel.tools.ObjectUpdateConvertWorkerNumber można skonfigurować stopień równoległości konwersji. Więcej informacji na ten temat znajduje się w artykule Właściwości ERP. Widoki również są najpierw tworzone tymczasowo, aby możliwe było przetestowanie widoku przed aktywacją. Jeżeli widok uzyskuje dostęp do obiektów biznesowych, które znajdują się w tym samym zadaniu deweloperskim, wówczas dla tego tymczasowego widoku następuje dostęp do skonwertowanych tabel. Standardowy cykl rozwoju obiektu biznesowego obejmuje kilka kroków, które muszą zostać wykonane przy użyciu narzędzi, aplikacji lub aplikacji zewnętrznych. Standardowy cykl przetwarzania widoków i obiektów biznesowych przebiega następująco: crtbo -j:xyz cnvbo -j:xyz actbo -j:xyz W standardowym przebiegu prac deweloperskich może wystąpić konieczność wielokrotnego dostosowywania zmian metadanych obiektu. Kroki 1–7 mogą być powtarzane dowolną liczbę razy, w zależności od potrzeb. Kroki 8–11 mogą być wykonywane wyłącznie sekwencyjnie i tylko w podanej kolejności. W narzędziach crtbo oraz cnvbo można jawnie określić, z którymi obiektami ma być prowadzona praca. W tym celu dostępne są opcje: W standardowym cyklu deweloperskim najczęściej stosowana jest opcja -j. W przypadku dużych zadań deweloperskich lub podczas testowania konkretnego programu aktualizacji zasadne może być generowanie obiektów pojedynczo w celu skrócenia czasu oczekiwania na wynik. Generowanie tabel tymczasowych może zostać cofnięte przy użyciu narzędzia rmvbo poprzez wskazanie obiektu lub zadania deweloperskiego. Narzędzie rmvbo usuwa obiekt z zadania deweloperskiego. Wszystkie zmiany w obiekcie zostają utracone bez dodatkowego potwierdzenia. Aktywacja zmian może zostać przeprowadzona wyłącznie dla całego zadania deweloperskiego przy użyciu narzędzia actbo -j:<numer zadania deweloperskiego>. Rozszerzenia rozszerzają tabelę w bazie danych o kolumny zdefiniowane w rozszerzeniu. Bazy danych podlegają jednak ograniczeniom. Ogranicza to na przykład maksymalną szerokość wiersza bazy danych. Kolumny z obiektu biznesowego oraz rozszerzenia sumują się i w niekorzystnym przypadku przekraczają maksymalny rozmiar. Obecnie zaleca się stosowanie tak zwanych suplementów. Są to obiekty biznesowe posiadające własną tabelę. Jeżeli dla obiektu biznesowego zdefiniowano suplement, wówczas podczas operacji na bazie danych suplement jest również wczytywany lub zapisywany. Obiekty biznesowe oraz części mogą być rozszerzane za pomocą rozszerzeń. Za pomocą rozszerzenia możliwe jest rozszerzenie obiektu o nowe właściwości. Rozszerzenie nie może ograniczać właściwości obiektu. Oznacza to, że rozszerzenie stanowi kompatybilne i bezkonfliktowe rozszerzenie obiektu biznesowego lub części. Rozszerzenia dla części, w odróżnieniu od rozszerzeń dla obiektów biznesowych, mogą powodować konflikty w standardowych obiektach biznesowych. Części mogą być rozszerzane za pomocą rozszerzenia między innymi o dodatkowe atrybuty. Nowe atrybuty części muszą zostać utworzone we wszystkich obiektach biznesowych, które wykorzystują tę część. Część może być używana przez dowolną liczbę obiektów biznesowych. Zasadniczo nie jest wiadomo, które obiekty biznesowe w systemie podrzędnym wykorzystują daną część. Atrybut cde_abc rozszerzenia F obiektu biznesowego B ma jako typ danych część P. Część P zostaje rozszerzona za pomocą rozszerzenia E o atrybut xyz_bcd. Dla kolumny cde_abc.xyz_bcd generowana jest metoda inicjalizacji w klasach aktualizacji rozszerzenia F. Jeżeli zostanie zainstalowana nowa wersja rozszerzenia F, konflikt w klasach aktualizacji rozszerzenia F musi zostać opracowany ręcznie. Atrybut typu string obiektu biznesowego może zostać wydłużony za pomocą rozszerzenia obiektu biznesowego. Wymagana do tego metoda ChangeDatatype jest generowana w klasach aktualizacji przypisanych do wydłużanego atrybutu. Wydłużenie atrybutu może zatem wymagać modyfikacji klas aktualizacji, które nie znajdują się w deweloperskiej przestrzeni nazw systemu deweloperskiego. Jeżeli zostanie zainstalowana nowa wersja zmodyfikowanej klasy aktualizacji, może powstać konflikt wymagający ręcznego opracowania. System ERP może zostać zainstalowany jako system standardowy, a następnie mogą zostać zainstalowane modyfikacje wraz z aktualizacjami oprogramowania, na przykład z systemu deweloperskiego klienta. W tym podejściu konieczne jest, aby wartości początkowe atrybutów rozszerzeń obiektu biznesowego mogły zostać obliczone na podstawie atrybutów standardowego obiektu biznesowego. Jeżeli system produkcyjny zostanie zainstalowany z wersją 7.0 obiektu biznesowego i zostaną zainstalowane aktualizacje oprogramowania z systemu deweloperskiego partnera, wówczas metoda inicjalizacji dla xyz_abc dla wersji 7.0.1 musi zostać wywołana i obliczyć swoją wartość początkową na podstawie przekazanej instancji obiektu w wersji 7.0. Metoda inicjalizacji musi również przetwarzać instancje obiektu w wersji 6.0. Rozszerzenia obiektów biznesowych przy wgrywaniu aktualizacji oprogramowania z systemu poprzedzającego standardowo nie wymagają ręcznego opracowywania konfliktów. Ręczne opracowywanie konfliktów może być konieczne, jeżeli rozszerzenia zostały utworzone dla części lub jeżeli wydłużono atrybuty typu string. Dla jednego prefiksu deweloperskiego może być równolegle utrzymywanych kilka systemów deweloperskich z różnymi wersjami. Jeżeli obiekt biznesowy lub rozszerzenie zostanie zmienione w starszej wersji, wówczas dany obiekt biznesowy musi zostać przejęty do kolejnej wersji. Proces ten musi być kontynuowany aż do najnowszej wersji. Przejęcie zmienionego obiektu biznesowego odbywa się przez transport poprzeczny. Jeżeli transportowany obiekt biznesowy został już zmieniony w systemie docelowym, aktywna wersja obiektu biznesowego zostaje przeniesiona do zadania konfliktowego. Klasy aktualizacji są generowane w taki sposób, aby obsługiwały przejście zarówno z wersji aktywnej, jak i z zaimportowanej wersji obiektu biznesowego do wersji obiektu biznesowego zablokowanej w zadaniu konfliktowym. Przejście z wersji aktywnej do wersji zablokowanej może zostać przetestowane w systemie deweloperskim. Przejście z wersji zaimportowanej do wersji zablokowanej nie może zostać przetestowane w systemie deweloperskim. Przejście to jest wykonywane dopiero wtedy, gdy system ze starszym stanem wersji zostanie podniesiony do stanu wersji systemu deweloperskiego. Kompatybilne zmiany w starszych wersjach są stosunkowo mało problematyczne. Zazwyczaj wystarczy przejąć do wersji zablokowanej te metody inicjalizacji, których brakuje w logice aktualizacji wersji zablokowanej, z logiki aktualizacji wersji zaimportowanej. Niekompatybilne zmiany typów danych lub usuwanie kolumn w starszych wersjach są problematyczne, jeżeli inne metody w klasach aktualizacji uzyskują dostęp do zmienionych kolumn. Wszystkie metody uzyskujące dostęp do zmienionego atrybutu muszą zostać odpowiednio dostosowane. Zmiany w klasach aktualizacji nie mogą zostać przetestowane w systemie deweloperskim. W celu przetestowania zmian konieczne jest przetestowanie zmiany wersji w systemie testowym. Należy dokładnie sprawdzić, czy możliwe jest uniknięcie niekompatybilnej zmiany w starszej wersji. Rozszerzenia obiektów biznesowych w aplikacji generują, jak zwykle, klasy aktualizacji. Metody rozszerzeń z aplikacji są zawsze wywoływane podczas konwersji po metodach klas aktualizacji obiektu biznesowego oraz innych rozszerzeń obiektów biznesowych. Nie wszystkie możliwe zmiany mogą zostać przeprowadzone przy użyciu opisanych wcześniej mechanizmów bez dodatkowych działań. Jeżeli obiekt biznesowy zawiera atrybuty lokalizowalne, może być konieczne dostosowanie programów aktualizacji tabel NLS. W większości przypadków kolumny istniejących tabel NLS nie ulegają zmianie, dlatego dostosowanie klas aktualizacji nie jest wymagane. Jeżeli zawartość atrybutu możliwego do zlokalizowania ma zostać zmieniona, należy uwzględnić, że w klasach aktualizacji obiektu biznesowego może zostać zmieniony wyłącznie język główny bazy danych. Języki dodatkowe atrybutu muszą zostać zmienione w odpowiednich klasach aktualizacji tabel NLS. W tych klasach aktualizacji powiązany obiekt biznesowy musi zostać odczytany przy użyciu dostępu generycznego lub zestawów wyników. Podczas dodawania atrybutu NLS lub gdy atrybut nielokalizowalny zostaje przekształcony w lokalizowalny, wszystkie tłumaczenia są inicjalizowane wartością atrybutu w języku głównym obiektu. W takim przypadku zawsze wymuszana jest konwersja instancji odpowiedniego głównego obiektu biznesowego. Ewentualne metody changeDatatype istniejące w klasach aktualizacji dla obiektu biznesowego NLS nie są wykonywane, ponieważ nie istnieją jeszcze instancje obiektu biznesowego NLS, do których mogłyby zostać zastosowane. Zmiany klucza głównego obiektu biznesowego są bardzo krytyczne i w miarę możliwości powinny być unikane. W przypadku zmiany klucza głównego obiektu biznesowego wszystkie referencje obiektów stają się nieważne. Powoduje to między innymi utratę wszystkich powiązań aktywności workflow z tym obiektem. Ponieważ atrybuty możliwe do zlokalizowania również odwołują się do powiązanego obiektu biznesowego za pomocą referencji obiektów, po zmianie klucza głównego tłumaczenia tracą powiązanie z obiektem głównym. Jeżeli zmiana klucza głównego jest konieczna, należy utworzyć aktualizację danych, która zastąpi referencje obiektów w tabelach NLS. Ponieważ tabela NLS zawiera dodatkowo atrybuty klucza głównego obiektu głównego, dla każdego tłumaczenia możliwe jest załadowanie obiektu głównego i na tej podstawie obliczenie nowej referencji obiektu.
return “”;
}
return “Artikel”);
}Metoda Init przy ponownym utworzeniu
Metody Init dla atrybutów części
Metoda ChangeDatatype
changeDatatype€<AttributePath>€<SourceDatatype>_<TargetDatatype>(
CisGenericObject object)
String changeDatatype€description€str100_str90(
CisGenericObject object) {
String value = object.getString(“description”);
if (value.length()<=90) {
return value;
} else {
return value.substring(0,87)+”…”;
}
}Usuwanie instancji
Typy danych
Typ danych
Oznaczenie w nazwie metody
Part: com.cisag.app.general.obj.DomesticAmount
DomesticAmount
Part: com.cisag.app.general.obj.Duration
Duration
Part: com.cisag.app.general.obj.ForeignAmount
ForeignAmount
Part: com.cisag.app.general.obj.Quantity
Quantity
Part: com.cisag.app.general.obj.PointInTime
PointInTime
com.cisag.pgm.datatype.CisAttributeTimeStamp
CisDate
com.cisag.pgm.datatype.CisAttributeDate
CisDate
com.cisag.pgm.datatype.CisAttributeDateUntil
CisDate
com.cisag.pgm.datatype.CisCalendar
Calendar
com.cisag.pgm.datatype.CisTimeInterval
TimeInterval
com.cisag.pgm.datatype.CisSymbolicInterval
SymbolicInterval
Binarny o długości 123
bin123
BLOB
blob
boolean
bool
byte
byte
char
char
Liczba dziesiętna o długości 12 i 3 miejscach po przecinku
dec12X3
double
double
float
float
GUID
guid
int
int
long
long
short
short
Ciąg znaków o długości 123
str123
ValueSet
vset
Znacznik czasu
stmp
Inicjalizacja
void initialize() {
if (getFromSchema().getColumn(„myUnit”)==null) {
myUnitDefault=…
}
}
byte[] init$myUnit () {
return myUnitDefault;
}Dostęp do danych aplikacji Konfiguracja
boolean isAvailable(String functionName, byte[] organizationGuid)
Object getConfiguredValues(String functionName,
byte[] organizationGuid)
Object getConfiguredValues(String functionName)Konwersja
Konwersja przez bazę danych
Konwersja za pośrednictwem serwera aplikacji
Widoki
Narzędzia generowania
Narzędzie
Opis
crtbo
Narzędzie crtbo (create business object) łączy generowanie opisu tabeli, klas mappera, klas aktualizacji oraz tabeli tymczasowej.
cnvbo
Polecenie cnvbo (convert business object) służy do przenoszenia danych z tabeli aktywnej do tabeli tymczasowej.
Do konwersji wymagane są mappery utworzone przez crtbo oraz ewentualnie dostosowane klasy aktualizacji.
actbo
Jeśli zadanie deweloperskie, w którym obiekty były przetwarzane, zostało zwolnione, należy następnie za pomocą narzędzia actbo (activate business object) aktywować obiekty zawarte w tym zadaniu.
Narzędzie actbo tworzy ponownie tabele tymczasowe i konwertuje dane z tabel aktywnych do tabel tymczasowych. Po konwersji tabele aktywne są usuwane, a tabele tymczasowe aktywowane lub tabele aktywne są modyfikowane za pomocą ALTER TABLE. Następnie można aktywować zadanie deweloperskie.
rmvbo
Generowanie tabel tymczasowych można cofnąć za pomocą rmvbo (remove business object), podając obiekt lub zadanie deweloperskie. Obiekt zostaje usunięty z zadania deweloperskiego.
wrkupdcls
Narzędzie wrkupdcls (work update class) wspiera dewelopera dodatkowymi informacjami i wskazówkami:
• –printUpgrade – wyświetlenie wszystkich metod klas aktualizacji obiektu biznesowego wykonywanych przy zmianie wersji.
• -printHistory – wyświetlenie historii zmian obiektu biznesowego.
Rozszerzenia
Rozszerzenia dla części
Rozszerzanie atrybutu string
Metody inicjowania
Normalny transport
Konserwacja równoległa
Aplikacje
Funkcje specjalne
Atrybuty możliwe do zlokalizowania
Tworzenie nowych elementów
Zmiany klucza głównego
Referencje obiektów
