Podręcznik referencyjny: Wymiana danych

Dla prostych jednostek biznesowych wymiana danych jest możliwa bez dodatkowego nakładu pracy programistycznej, ponieważ usługa Business Integration Service (BIS) obsługuje generyczny import i eksport. Jednak w wielu przypadkach spotykanych w praktyce, stworzenie kontrolera jest celowe i konieczne, aby jednostka biznesowa mogła być dostępna do wymiany danych.

Niniejszy artykuł wyjaśnia podstawowe procedury implementacji kontrolera oraz zawiera wskazówki dotyczące korzystania z odpowiedniego API udostępnianego w tym celu przez Comarch ERP Enterprise.

Grupa docelowa

• Programiści aplikacji

Definicje terminów

• Kontroler — kontroler to klasa Java, która realizuje import lub eksport podmiotu biznesowego. Powiązane interfejsy to interfejsy Java: com.cisag.pgm.bi.ImportController i com.cisag.pgm.bi.ExportController. Kontroler dostarcza model danych, który ma być używany do importu lub eksportu, a tym samym określa ilość obiektów, atrybutów i relacji dostępnych dla jednostki biznesowej. Model danych może być różny dla importu i eksportu. W przypadku prostych jednostek biznesowych import lub eksport może odbywać się również bez istniejącego kontrolera, czyli generycznie.
• Aplikacja korygująca — aplikacja korygująca to aplikacja dialogowa, która jest używana do interaktywnej obróbki prostych plików z błędami w systemie Comarch ERP Enterprise. Dla jednej jednostki biznesowej może istnieć jedna lub kilka aplikacji korygujących. Zasadniczo, aplikacja korygująca jest odpowiednią aplikacją należącą do danej jednostki biznesowej (np. aplikacja Partnerzy dla jednostki biznesowej com.cisag.app.general.obj.Partner), która jest otwierana w specjalnym trybie. W tym trybie instancje jednostki biznesowej z pliku z błędami można otwierać pojedynczo, interaktywnie edytować i zapisywać.

Rozwój kontrolerów

Kontroler BIS

Kontroler to klasa Java, która realizuje import i eksport dla określonej jednostki biznesowej. Ta klasa Java musi implementować jeden lub oba z poniższych interfejsów:

• Kontroler, który ma wspierać eksport, implementuje interfejs com.cisag.pgm.bi.ExportController
• Kontroler, który ma wspierać import, implementuje interfejs com.cisag.pgm.bi.ImportController
• Kontroler, który ma wspierać zarówno eksport, jak i import, implementuje oba interfejsy
• Jeśli dla jednostki biznesowej ma być wspierany eksport i import, ale import ma obejmować tylko wycinek modelu danych eksportu, należy zaimplementować kontroler importu i eksportu w dwóch różnych klasach, aby móc podać odmienne modele danych

Klasy Java, które implementują te interfejsy, muszą zostać zarejestrowane jako kontrolery. Rejestracja ta jest opisana w dalszej części artykułu.

Budowa modelu BIS

ObjectInfo

Każdy kontroler definiuje model danych BIS, który jest używany podczas importu lub eksportu. Model danych BIS określa strukturę importowanych i eksportowanych danych.

Kontroler definiuje swój model danych BIS poprzez implementację metody ObjectInfo getObjectInfo().

Dla definicji modelu danych BIS, kontrolery zazwyczaj stosują strategię budowania modelu danych w oparciu o opis obiektu biznesowego w bazie danych repozytorium, w jak największym możliwym stopniu. Można to osiągnąć dla jednostki biznesowej poprzez użycie klasy

CisObjectInfo info= new CisObjectInfo(<BusinessObject>.class);

Ten ObjectInfo może zostać następnie zmodyfikowany. Możliwe jest usuwanie atrybutów lub relacji, przekształcanie relacji, które nie są Dependent, w relacje Dependent, rejestrowanie nowych deskryptorów oraz zmiana kolejności atrybutów lub relacji. Metody do tego celu są zdefiniowane w nadklasie com.cisag.pgm.bi.model.DefaultObjectInfo klasy CisObjectInfo.

Poniżej znajdują się informacje, które należy wziąć pod uwagę podczas tworzenia lub modyfikowania modelu danych BIS:

• Niepotrzebne atrybuty i relacje powinny bezwzględnie zostać usunięte z modelu danych. Dzięki temu model danych staje się mniejszy i łatwiejszy do zrozumienia. Przykładowo, użycie klasy CisObjectInfo często tworzy wsteczne relacje z obiektu zależnego (Dependent) do obiektu głównego. Nie są one potrzebne przez BIS i dlatego powinny zostać usunięte.
• Każda późniejsza zmiana w ObjectInfo jest zmianą w modelu danych BIS i musi zostać zweryfikowana pod kątem kompatybilności z poprzednim stanem modelu danych. Dotyczy to również zmian w obiektach biznesowych.

DataViewBIS

DataViewBIS to dodatek do węzła ObjectInfo, który umożliwia rozszerzenie kontrolera o hooki BIS zależne od kontrolera.

W tym celu węzeł można wyposażyć w DataViewBIS w następujący sposób: DataViewBIS.create( info);

DataViewBIS musi być również uwzględniony w przetwarzaniu eksportu lub importu kontrolera. Należy również wziąć pod uwagę wskazówki zawarte w kolejnych sekcjach.

Eksport i import

Przebieg eksportu

W procesie eksportu instancje jednostki biznesowej do wyeksportowania są określane przez wybrane ograniczenie, które następuje za pomocą wyszukiwania OQL lub instrukcji OQL.

Dla eksportu każdej instancji obiektu biznesowego wywoływana jest metoda kontrolera:

boolean process(Target target, Object obj)

Za pomocą parametru target przekazywany jest obiekt docelowy (interfejs com.cisag.pgm.bi.Target), za pomocą którego można zapisywać dane do pliku docelowego. W parametrze obj przekazywana jest instancja głównego obiektu, w której atrybuty klucza głównego i klucza biznesowego są już wypełnione. Za pomocą wartości w tych atrybutach, kontroler musi otworzyć instancję jednostki biznesowej. Wartości atrybutów, które nie są kluczami, są niezdefiniowane i nie powinny być używane.

Implementacja metody process() w kontrolerze musi zapisać wszystkie obiekty, które należą do instancji jednostki biznesowej, do przekazanego target. W tym celu używana jest instancja klasy DefaultSerializer (com.cisag.pgm.bi.helper.DefaultSerializer).

Przetwarzanie, które kontroler musi wykonać w ramach wywołania metody process(), jest zgodne ze wzorcem przedstawionym w poniższym kodzie źródłowym Java. Zakłada się przy tym, że kontroler utworzył instancję serializer klasy DefaultSerializer, a obiekty target i obj są parametrami metody process().

CisObject loadedObject;

Map lodedObjectNLS;

// Otwarcie obiektu i jego danych NLS za pomocą CisObjectManager.

// Wartości atrybutów klucza są zawarte w parametrze obj. …

// Zapisanie obiektu.

serializer.write(target, loadedObject, lodedObjectNLS);

// Przejście przez relacje zależne (Dependent) filtru.

AssociationDescriptor[] assocs = target.getAssociations();

for (int i = 0; i < assocs.length; i++) {

AssociationDescriptor assoc = assocs[i];

if (DEPENDENT1.equals(assoc.getName())) {

// Zapisanie relacji zależnej (Dependent).

Iterator it = …

while (it.hasNext()) {

Object childObj = it.next();

Map childNLS = …

Target child = target.child(DEPENDENT1);

serializer.write(child, childObj, childNLS);

// Tutaj ewentualnie zapisać podrzędne obiekty zależne (Dependents). }

}

else if (…) { …. }

// Tutaj zapisać następną relację zależną (Dependent).

}

Oto co należy wziąć pod uwagę:

• Najpierw kontroler musi zapisać obiekt główny, a następnie obiekty zależne, o ile model danych BIS jednostki biznesowej zawiera obiekty zależne
• Dla wsparcia eksportu wielojęzycznego muszą być dostarczone instancje klasy NLSData
• Użycie klasy DefaultSerializer jest opisane w osobnym rozdziale
• Proste relacje do obiektów niezależnych nie mogą być zapisywane przez sam kontroler, ponieważ jest to już obsługiwane przez klasę DefaultSerializer

Szczególnie w przypadku relacji zależnych należy zwrócić uwagę na:

• Zależności typu Dependent muszą być zawsze zapisywane w tej samej kolejności, w jakiej występują w modelu danych kontrolera, i mogą być zapisane tylko wtedy, gdy zostały wybrane w filtrze. Oba te warunki są spełniane przez pętlę for.
• W przypadku zależności wielokrotnych, poszczególne instancje są zapisywane jedna po drugiej. Kontroler określa kolejność, w jakiej instancje Dependent pojawią się w pliku docelowym. Jest to osiągane dzięki pętli while.
• Dla każdej instancji Dependent przeznaczonej do zapisu, należy utworzyć nową instancję obiektu Target za pomocą metody child()
• Jeśli obiekt Dependent sam ma podrzędne obiekty Dependent, należy je zapisać po wywołaniu metody serializer.write() dla obiektu Dependent

Wsparcie dla Hooków:

• Jeśli istnieje obiekt DataViewBIS, należy ustawić widok obiektu do wyeksportowania jako wartość kontekstową w obiekcie DataViewBIS. Przykład można znaleźć w klasie SingleObjectEntityController.
• Jeśli istnieje obiekt DataViewBIS i ma być wspierany DependentAssociationHook, przetwarzanie obiektów Dependent musi być wywołane na klasie DataViewBIS (metody isExtensionDependent() i processDependentExport()). Przykład również znajduje się w SingleObjectEntityController.

Przebieg importu

W procesie importu, dla każdej instancji jednostki biznesowej do zaimportowania z pliku źródłowego, wywoływana jest metoda boolean process(Source source) w kontrolerze. Z parametrem source przekazywany jest obiekt źródłowy (interfejs com.cisag.pgm.bi.Source), który zawiera dane instancji jednostki biznesowej do zaimportowania.

Kontroler musi najpierw wczytać obiekty zawarte w obiekcie źródłowym, a następnie je zweryfikować. Podobnie jak w przypadku eksportu, najpierw wczytywany jest obiekt główny, a następnie obiekty zależne (Dependents). Jeśli cała instancja jednostki biznesowej została pomyślnie zweryfikowana, jest zapisywana w bazie danych. Należy pamiętać, że dokładny przebieg zależy również od samej jednostki biznesowej.

Zasady dotyczące rozszerzalności kontrolera za pomocą hooków są takie same jak w przypadku eksportu.

Przykład implementacji metody boolean process(Source source) znajduje się w kodzie źródłowym Java w klasie com.cisag.app.general.log.SingleObjectEntityController.

Wczytywanie obiektu

Ogólny przebieg wczytywania obiektu jest następujący:

1. Kontroler posiada lub tworzy przejściową, pustą instancję podklasy klasy CisObject dla wczytywanego obiektu.
2. Za pomocą instancji klasy DefaultSerializer dane z instancji interfejsu Source są wczytywane do obiektu w celu uzyskania atrybutów klucza.
3. Kontroler musi teraz ustalić, czy import dotyczy nowego obiektu, czy aktualizacji. Jeśli jest to aktualizacja, wczytuje dotychczasowe dane z bazy danych.
4. Za pomocą instancji klasy DefaultSerializer dane z instancji interfejsu Source są ponownie wczytywane do obiektu, aby uzyskać dane, które mają zostać zmienione przez import. Obiekt osiągnął teraz stan, który zostanie później zapisany w bazie danych.

Użycie klasy DefaultSerializer jest dokładniej wyjaśnione w rozdziale 4.3.3.

Należy przy tym wziąć pod uwagę następujące kwestie:

• Należy uwzględnić tryb importu, który jest określony przez instancję interfejsu Source. W zależności od trybu, na przykład, niedozwolone jest tworzenie nowych obiektów lub przeprowadzanie aktualizacji. Tryb importu jest odpytywany za pomocą metody int Source.getMode(), a stałe dla różnych trybów importu są zdefiniowane w klasie com.cisag.pgm.bi.Mode.
• Po dwukrotnym wczytaniu obiektu, dla nowo tworzonego obiektu, dla wszystkich atrybutów wielojęzycznych musi zostać wywołana metoda NLSData.applyDefaults( CisObject obj ). W ten sposób języki, które nie zostały podane, w atrybutach wielojęzycznych są wstępnie wypełniane podaną wartością z innego języka. Dla wielojęzycznego atrybutu instancji obj podklasy klasy CisObject oraz instancji nlsData klasy NLSData, przebieg jest następujący:

if (!obj.is_persistent()) {
nlsData.applyDefaults( obj);
}

• Jeśli tryb importu przewiduje usunięcie obiektu lub instancji jednostki biznesowej, krok 4 nie jest konieczny.

Walidacje i obsługa błędów

Podczas importu należy bezwzględnie przeprowadzić pełną obsługę błędów. Jest to odpowiedzialność kontrolera importu.

Należy wykonać następujące walidacje:

• Jeśli po wywołaniu metody klasy DefaultSerializer kolejka komunikatów programu zawiera błąd lub niepotwierdzone ostrzeżenie, oznacza to błąd importu
• Jeśli nie można przeprowadzić operacji zgodnej z trybem importu, oznacza to błąd importu. W takim przypadku kontroler musi dodatkowo wysłać komunikat o błędzie.
• Po wczytaniu obiektu przez klasę DefaultSerializer należy wykonać krok Verify. Ten krok realizuje dodatkowe walidacje, które są określone przez implementacje AttributeDescriptor. Jeśli ten krok zakończy się niepowodzeniem, oznacza to błąd importu.
• Następnie należy wywołać walidację specyficzną dla jednostki biznesowej (Validation). Są to walidacje, które są również przeprowadzane podczas zapisu w odpowiedniej aplikacji dialogowej. Ta walidacja, w zależności od kontrolera, odnosi się albo do całej jednostki biznesowej, albo do poszczególnych obiektów. Jeśli wywołanie walidacji zakończy się niepowodzeniem, oznacza to błąd importu.

Jeśli którakolwiek z tych walidacji zakończy się niepowodzeniem, obiekt źródłowy przekazany w parametrze source musi zostać oznaczony jako błędny poprzez wywołanie metody invalidate(), a następnie import musi zostać przerwany przez opuszczenie metody process(Source) z wartością zwracaną false i odpowiednimi komunikatami o błędach w kolejce komunikatów programu.

Tylko wtedy, gdy te walidacje zakończą się sukcesem, instancja jednostki biznesowej może zostać zapisana w bazie danych.

Obsługa obiektów zależnych

Po wczytaniu i zweryfikowaniu obiektu głównego (ale ewentualnie przed wywołaniem walidacji, więcej informacji na ten temat znajduje się w sekcji Walidacje i obsługa błędów), należy wczytać i zweryfikować obiekty zależne. Przykład złożonej jednostki biznesowej z wieloma obiektami zależnymi znajduje się w klasie com.cisag.app.general.item.log.ImportExport w metodzie void process(BaseItemEntity base, Target target).

Zapisywanie do bazy danych

Zapisywanie instancji jednostek biznesowych do zaimportowania może odbywać się pojedynczo lub blokowo. W obu przypadkach implementacja jest realizowana przez kontroler. Pojedyncze zapisywanie instancji jest łatwiejsze do zrealizowania, natomiast zapisywanie blokowe pozwala osiągnąć lepszą wydajność przy imporcie dużych ilości danych.

Dopiero podczas zapisywania do bazy danych używane są nietrwałe instancje podklasy klasy CisObject.

• Zapisywanie pojedyncze — instancja jednostki biznesowej jest zawsze zapisywana pojedynczo na końcu wywołanej metody process( Source) w kontrolerze importu. W tym celu musi być użyta oddzielna transakcja.
• Zapisywanie blokowe — w przypadku zapisywania blokowego, każda instancja jednostki biznesowej jest przetwarzana w odpowiednim wywołaniu metody process(), jak opisano powyżej, ale nie jest jeszcze zapisywana do bazy danych. Zamiast tego, kontroler zbiera dane do zapisania i zapisuje je dopiero, gdy zgromadzi wystarczająco dużą liczbę obiektów. Aby zapisać blok instancji, kontroler musi otworzyć nową transakcję najwyższego poziomu. Należy przy tym pamiętać, że kontroler musi najpierw usunąć wszystkie instancje przeznaczone do usunięcia, zanim zapisze instancje do utworzenia lub aktualizacji.

Użycie klasy DefaultSerializer

Za pomocą klasy DefaultSerializer pojedyncze obiekty Java są zapisywane w obiekcie docelowym (interfejs Target) lub wczytywane z obiektu źródłowego (interfejs Source) do obiektu Java.

Klasa DefaultSerializer zawiera wsparcie dla wielojęzycznego eksportu wielojęzycznych atrybutów typu String. Należy pamiętać, że kontroler nigdy nie musi rozróżniać, czy przeprowadza eksport jednojęzyczny, czy wielojęzyczny. Zamiast tego zawsze udostępnia dodatkowe dane potrzebne do eksportu wielojęzycznego.

Zapisywanie obiektu

Do zapisywania obiektu podczas eksportu dostępne są następujące dwie sygnatury metody write():

void write(Target target, Object obj, Map<String,NLSData> nlsDatas)
void write(Target target, Object obj)

Za pomocą tych metod przekazany obiekt obj jest zapisywany w przekazanym obiekcie docelowym target.

Jeśli zapisywany obiekt zawiera wielojęzyczne atrybuty typu String, a kontroler wspiera eksport wielojęzyczny, należy użyć pierwszej sygnatury. W takim przypadku parametr map zawiera dla każdego wielojęzycznego atrybutu typu String instancję klasy NLSData (com.cisag.pgm.datatype.NLSData). Instancje klasy NLSData muszą być w tym momencie wypełnione.

Jeśli zapisywany obiekt nie zawiera wielojęzycznych atrybutów typu String lub eksport wielojęzyczny nie jest wspierany, używana jest druga sygnatura.

Wywołanie jednej z sygnatur metody write() zapisuje obiekt oraz proste relacje do obiektów niezależnych tego obiektu, ale nie zapisuje pozostałych relacji.

Wczytywanie obiektu

Do wczytywania obiektu podczas importu dostępne są dwie sygnatury metody read():

void read(Source source, Object obj, Map<String,NLSData> nlsDatas)
void read(Source source, Object obj)

Za pomocą tych metod dane obiektu są wczytywane z przekazanego obiektu źródłowego source do przekazanego obiektu obj. Dla parametru obj powinna być użyta odpowiednia przejściowa instancja podklasy CisObject.

Jeśli wczytywany obiekt zawiera wielojęzyczne atrybuty typu String, a kontroler wspiera eksport wielojęzyczny, należy użyć pierwszej sygnatury. W tym przypadku kontroler musi dodatkowo przekazać instancję interfejsu java.util.Map, która dla każdego wielojęzycznego atrybutu typu String tego obiektu zawiera instancję klasy NLSData (com.cisag.pgm.datatype.NLSData). Te instancje klasy NLSData nie muszą być wypełnione. Wielojęzyczne atrybuty są wczytywane do obiektu obj w języku sesji, a w pozostałych językach do powiązanej instancji klasy NLSData.

Dolna sygnatura jest używana, jeśli obiekt nie zawiera wielojęzycznych atrybutów typu String lub gdy import wielojęzyczny nie jest wspierany przez kontroler.

Dodatkowo, dolna sygnatura może być użyta również w imporcie wielojęzycznym, gdy ma zostać wczytana tylko identyfikacja obiektu. W trybie językowym Wielojęzyczny atrybuty wielojęzyczne nie są jednak w tym przypadku wczytywane. Dzięki tej możliwości nie trzeba dostarczać instancji klasy NLSData, jeśli identyfikacja obiektu nie jest jeszcze znana.

Hooki BIS

Dla prostych jednostek biznesowych wymiana danych jest możliwa bez dodatkowego nakładu pracy programistycznej, ponieważ usługa Business Integration Service (BIS) obsługuje generyczny import i eksport. Jednak w wielu przypadkach spotykanych w praktyce, stworzenie kontrolera jest celowe i konieczne, aby jednostka biznesowa mogła być dostępna do wymiany danych.

Niniejszy artykuł wyjaśnia podstawowe procedury implementacji kontrolera oraz zawiera wskazówki dotyczące korzystania z odpowiedniego API udostępnianego w tym celu przez Comarch ERP Enterprise.

Modyfikowanie modelu danych BIS

ObjectInfoExtensionHook oferuje możliwość usuwania atrybutów i relacji z ObjectInfo, dodawania nowych atrybutów lub zastępowania AttributeDescriptor. Implementacja hook z systemu deweloperskiego może zmieniać tylko własne atrybuty (atrybuty z własnym prefiksem deweloperskim lub dowolne atrybuty wewnątrz złożonych atrybutów z własnym prefiksem deweloperskim).

Implementacja hooka wpływa na wszystkie kontrolery BIS i oddziałuje na węzły modelu danych BIS typu konkretnego obiektu biznesowego, który jest podany jako ograniczenie hooka. Hook jest wywoływany zarówno dla otoczki jednostki biznesowej, jak i dla relacji zewnętrznych; implementacja hooka może w każdym przypadku sprawdzić, czy modyfikowany węzeł modelu danych BIS należy do otoczki jednostki biznesowej, czy jest relacją zewnętrzną.

Atrybuty i relacje w obiektach Part obiektu biznesowego również mogą być zmieniane. Nie jest jednak możliwe nawigowanie do podrzędnych obiektów biznesowych. W tym celu należy użyć własnej implementacji hooka.

Relacje Dependent nie mogą być dodawane za pomocą tego hooka, a jedynie za pomocą DependentAssociationHook.

Ten sam cel ma DataViewBISHook, który jest jednak zależny od kontrolera. W przeciwieństwie do ObjectInfoExtensionHook, wpływa on tylko na jeden konkretny kontroler BIS i może działać wyłącznie na obiektach z otoczki jednostki biznesowej. Oferuje jednak dostęp do zmiennych kontekstowych, które są ustawiane przez kontroler.

DataViewBISHook musi być określony poprzez ograniczenie hooka na węźle modelu danych BIS, który musi być wyposażony w DataViewBIS.

Dostępność zmiennych kontekstowych zależy od kontrolera. Zazwyczaj kontroler udostępnia widok obiektu jako zmienną kontekstową, której węzeł został wyposażony w DataViewBIS.

Zastępowanie AttributeDescriptor

Za pomocą hooka BISRegistryHook można zarejestrować AttributeDescriptor dla logicznego typu danych w rejestrze BIS. AttributeDescriptor jest wtedy używany dla wszystkich atrybutów danego logicznego typu danych. Logiczny typ danych musi pochodzić z tego samego systemu deweloperskiego, co implementacja hooka.

Ten hook odpowiada metodzie registerAttributeDescriptors(Map<String, String>) klasy Java BIS-Registry, ale pozwala uniknąć konfliktów podczas wgrywania aktualizacji oprogramowania.

Dodawanie obiektów zależnych

Za pomocą DependentAssociationHook można dodać obiekt zależny (Dependent) do modelu danych BIS kontrolera, o ile kontroler to wspiera. Obiekty zależne mogą być jednak dodawane tylko do węzłów, których ObjectInfo zostało wyposażone w DataViewBIS.

Każda implementacja tego hooka tworzy obiekt zależny, ustala jego nazwę, krotność i ObjectInfo. Zawiera metody do zapisywania i wczytywania obiektu zależnego. Użycie hooka jest udokumentowane w Javadoc klasy com.cisag.pgm.bi.hook.DependentAssociationHook.

DependentAssociationHook transportuje dane między stanowym hookiem a plikiem eksportu/importu. Do wczytywania, walidacji i zapisywania obiektu zależnego wymagany jest hook na poziomie jednostki biznesowej oraz implementacja hooka.

Rejestr BIS

Rejestr BIS zawiera kontrolery oraz inne obiekty deweloperskie, które są używane przez kontrolery. W tym celu rejestr BIS jest podzielony na grupy, które są przedstawione w poniższej tabeli.

Grupy rejestrów, w których obiekty deweloperskie są rejestrowane z obiektem biznesowym jako kluczem, są rejestrowane w typie obiektu deweloperskiego dodatku do opisu obiektu. W innych przypadkach do rejestracji służy hook.

Ponadto, obiekty deweloperskie można rejestrować w klasie Java rejestru com.cisag.app.bi.Registry. Rejestracja w obiekcie deweloperskim ma jednak pierwszeństwo przed klasą Java rejestru, która w Comarch ERP Enterprise 5.0 powinna być używana tylko wtedy, gdy nie ma innej możliwości.

Rejestracja w obiekcie deweloperskim zapobiega konfliktom spowodowanym aktualizacjami oprogramowania, takim jakie występują w przypadku scentralizowanej klasy Java rejestru. W obrębie aplikacji możliwa jest tylko rejestracja w obiekcie deweloperskim.

Do migracji z klasy Java rejestru do obiektu deweloperskiego typu dodatku do opisu obiektu można użyć polecenia toolshell crtoda.

W kolejnych sekcjach niektóre grupy rejestrów zostały opisane dokładniej. Opis dodatku do opisu obiektu jako typu obiektu deweloperskiego znajduje się w artykule Obiekty deweloperskie.

Kontroler

Implementacje kontrolerów muszą być zarejestrowane, aby mogły być używane przez BIS. W tym przypadku należy rozróżnić eksport i import.

W obiekcie deweloperskim typu dodatek do opisu obiektu podaje się kontroler eksportu i kontroler importu oddzielnie, nawet jeśli jest to ta sama klasa implementacyjna. Nazwa dodatku do opisu obiektu jest zasadniczo taka sama jak nazwa obiektu biznesowego, który jest eksportowany lub importowany przez kontroler.

W klasie Java rejestru istnieją następujące możliwości: w metodzie

public static void registerControllers(Map<String,String> ctrls)

można rejestrować kontrolery, jeśli istnieje tylko kontroler eksportu, tylko kontroler importu, lub jeśli oba kontrolery są zaimplementowane w tej samej klasie.

public static void registerExportControllers(Map<String,String>eCtrls)
public static void registerImportControllers(Map<String,String>iCtrls)

można również rejestrować kontrolery, które dla danego podmiotu biznesowego są zaimplementowane w dwóch oddzielnych klasach.

Aby dokonać rejestracji, należy dodać wpis do przekazanej instancji java.util.Map, gdzie kluczem jest nazwa jednostki biznesowej, a wartością nazwa klasy kontrolera.

Wyszukiwanie OQL

Dla jednostki biznesowej można rejestrować wyszukiwania OQL, które są dostępne do zawężania kryteriów podczas eksportu. Zarejestrowane wyszukiwania są dostępne w aplikacji Eksport danych na zakładce Ograniczenia.

Jeśli dla jednostki biznesowej nie zarejestrowano wyszukiwań OQL, BIS samodzielnie określa pasujące wyszukiwania OQL. Zaleca się jednak rejestrowanie wyszukiwań OQL.

Aplikacje korygujące

Można zarejestrować aplikację korygującą dla jednostki biznesowej. Jeśli dla danej jednostki nie zarejestrowano żadnej aplikacji korygującej, BIS samodzielnie określa możliwe aplikacje korygujące na podstawie parametrów istniejących aplikacji dialogowych. Zaleca się jednak rejestrowanie aplikacji korygującej, ponieważ w większości przypadków automatyczne wyszukiwanie znajduje również aplikacje, które nie mogą być używane jako aplikacje korygujące.