Definicja Hook Contract dla dokumentów

Wprowadzenie

Definicje Hook Contract dla dokumentów służą do rozszerzania aplikacji typu Dokument oraz aplikacji typu Lista dla dokumentów na poziomach Logika oraz Interfejs użytkownika poprzez implementacje Hook Contract.

W artykule opisano, jakie rozszerzenia można wdrożyć za pomocą definicji Hook Contract oraz jakie ograniczenia i szczególne przypadki należy wziąć pod uwagę.

Artykuł dotyczy poniższych ogólnych interfejsów stanu Hook:

• com.cisag.app.general.order.hook.log.EntityState
• com.cisag.app.general.order.hook.log.HeaderSourceState
• com.cisag.app.general.order.hook.log.MutableHeaderState
• com.cisag.app.general.order.hook.log.DetailSourceState
• com.cisag.app.general.order.hook.log.MutableDetailState
• com.cisag.app.general.order.hook.log.MakePersistentState

Artykuł dotyczy poniższych ogólnych interfejsów Hook:

• com.cisag.app.general.order.hook.log.EntityHook
• com.cisag.app.general.order.hook.log.HeaderDependentHook
• com.cisag.app.general.order.hook.log.HeaderApplyDefaultsHook
• com.cisag.app.general.order.hook.log.HeaderValidateHook
• com.cisag.app.general.order.hook.log.HeaderValidateDeleteHook
• com.cisag.app.general.order.hook.log.MakePersistentHook
• com.cisag.app.general.order.hook.log.RefreshHeaderHook
• com.cisag.app.general.order.hook.log.ReorganisationValidateHook
• com.cisag.app.general.order.hook.log.DetailDependentHook
• com.cisag.app.general.order.hook.log.DetailApplyDefaultsHook
• com.cisag.app.general.order.hook.log.DetailValidateHook
• com.cisag.app.general.order.hook.log.DetailValidateDeleteHook
• com.cisag.pgm.appserver.hook.BatchActionHook

Interfejs pgm–BatchActionHook jest w niniejszym artykule rozpatrywany wyłącznie w kontekście użycia w Hook Contractach dla aplikacji typu Dokument oraz aplikacji typu Lista dla dokumentów.

Poszczególne aplikacje obsługują dodatkowe interfejsy Hook, np. dla konwersji i zostały one opisane w dedykowanych rozdziałach dotyczących poszczególnych aplikacji typu Dokument.

Opis interfejsu znajduje się w odpowiednim obiekcie deweloperskim typu Hook Contract. Szczegółowe informacje na temat metod zadeklarowanych w interfejsach znajdują się jako uzupełnienie tego dokumentu w JavaDoc w poszczególnych interfejsach Java.

Informacje dotyczące infrastruktury Hook można znaleźć w artykule Hook Contracts.

W systemie ADO dostępne są również przykłady dla każdej z aplikacji typu Dokument wymienionych w tym artykule, które mogą posłużyć jako wzór dla własnych rozszerzeń.

Grupa docelowa

• Programiści

Opis

Definicje Hook Contract dla aplikacji dokumentów wspierają obecnie za pomocą odpowiednich implementacji następujące funkcjonalności:

• Dodawanie atrybutów bezpośrednio w nagłówku dokumentu
• Dodawanie atrybutów bezpośrednio na pozycji dokumentu
• Dodawanie danych podstawowych w dodatkowym zbiorze danych
• Dodawanie danych pozycji w dodatkowym zestawie danych
• Przeniesienie dodanych atrybutów nagłówka i pozycji podczas konwersji następujących dokumentów:
  • Zapytanie ofertowe zakupu –> Oferta zakupu
  • Oferta zakupu –> Zamówienie zakupu
  • Zamówienie zakupu –> Dokumenty zamówień zakupu/Zmiany zamówienia zakupu
  • Dokumenty zamówień zakupu/Zmiany zamówienia zakupu –> Potwierdzenie zamówienia
  • Potwierdzenie zamówienia –> Zamówienie zakupu
  • Dokumenty szybkiej rejestracji sprzedaży –> Zapytania ofertowe sprzedaży
  • Dokumenty szybkiej rejestracji sprzedaży –> Oferty sprzedaży
  • Dokumenty szybkiej rejestracji sprzedaży –> Zamówienie sprzedaży
  • Zapytania ofertowe sprzedaży –> Oferty sprzedaży
  • Oferty sprzedaży –> Zamówienie sprzedaży
• Określenie wartości domyślnych dla danych dodawanych do nagłówka dokumentów
• Określenie wartości domyślnych dla danych dodanych do pozycji dokumentu
• Nowe walidacje nagłówka dla istniejących lub nowych danych
• Nowe walidacje dla pozycji dla istniejących lub nowych danych
• Nowe walidacje usuwania dla bazy dokumentu
• Nowe walidacje usuwania dla pozycji dokumentu
• Nowa walidacje przed reorganizacją dokumentu
• Uwzględnienie dodanych atrybutów nagłówka i pozycji w statusie zamówienia zamówienia
• Uwzględnianie dodanych atrybutów podstawy i pozycji przy statusie potwierdzenia zlecenia zaopatrzenia oraz zamówienia/zmiany zamówienia, a także przy statusie zmiany zamówienia w potwierdzeniu zamówienia
• Dodawanie akcji, które przekazują do aplikacji działającej w tle:
  • bieżący nagłówek dokumentu (aplikacja typu Dokument) lub
  • wybrane dane (aplikacja typu Lista dla dokumentów)
    w celu dalszego przetwarzania
• Rejestrowanie zmienionych danych podczas operacji usuwania i zapisywania
• Aktualizacja podstawy przy zmianach pozycji
• Określanie atrybutów rodzaju dokumentu, które nie mogą być już zmieniane, jeśli istnieje dokument danego rodzaju

Dodawanie atrybutów bezpośrednio w nagłówku dokumentów

Za pomocą obiektu deweloperskiego Extension można rozszerzyć istniejący nagłówek dokumentu (np. SalesOrder) o dodatkowe własne atrybuty.

W wyniku generowania odpowiedni widok obiektu zostaje automatycznie rozszerzony o nowe atrybuty. Domyślnie atrybuty są widoczne i można je zmieniać – w razie potrzeby można to zmienić za pomocą odpowiedniego rozszerzenia widoku obiektu. Dzięki temu odpowiednie pola są również dostępne w dostosowywalnej aplikacji oraz podczas eksportu/importu.

Ze względu na to, że atrybuty należą bezpośrednio do nagłówka dokumentu, są one automatycznie przenoszone.

Jeśli nowe atrybuty należą do aplikacji, podczas akcji [Kopiuj nagłówek] wszystkie atrybuty aplikacji zostaną automatycznie skopiowane z podstawy źródłowej do podstawy docelowej.

Jeśli wymagane jest inne zachowanie, w razie potrzeby należy zaimplementować metodę duplicateHeader interfejsu Hook HeaderDependentHook.

W razie potrzeby interfejs Hook HeaderApplyDefaultsHook jest dostępny do określania wartości domyślnej nowych atrybutów – jest on również używany do przesyłania wartości ze źródła (np. poprzedniego dokumentu, portu wewnętrznego itp.) (patrz także odpowiedni rozdział poniżej).

Nowe atrybuty powinny być również sprawdzane za pomocą implementacji HeaderValidateHook.

W razie potrzeby można wstawić nowe atrybuty do aplikacji dokumentu i zapisać zmiany w obiekcie deweloperskim Application extension w bazie danych repozytorium, a tym samym przenieść je do kolejnego systemu.

Należy również pamiętać, że chociaż bardzo łatwo jest dodawać atrybuty bezpośrednio w nagłówku dokumentów, może to prowadzić do problemów związanych z maksymalną liczbą kolumn – dotyczy to w szczególności aplikacji, których potencjalnie może być duża liczba. Jak zarządzać dodatkowymi danymi podstawowymi w oddzielnym zbiorze danych, można dowiedzieć się z rozdziału Dodawanie danych podstawowych w dodatkowym zbiorze danych.

Dodawanie atrybutów bezpośrednio w pozycji dokumentu

Za pomocą obiektu deweloperskiego Extension można dodać atrybuty do istniejącej pozycji dokumentu (np. pozycji dokumentu (np. SalesOrderDetail) z dodatkowymi własnymi atrybutami.

Generacja automatycznie dodaje również nowe atrybuty do powiązanego widoku obiektu. Atrybuty są domyślnie widoczne i możliwe do zmiany – w razie potrzeby można to zmienić za pomocą odpowiedniego rozszerzenia widoku obiektu. Oznacza to, że odpowiednie pola są również dostępne w dostosowywanej aplikacji i podczas eksportu/importu.

Ze względu na to, że atrybuty należą bezpośrednio do pozycji dokumentu, są one automatycznie uwzględniane.

Jeśli nowe atrybuty należą do aplikacji, wszystkie atrybuty aplikacji są również automatycznie kopiowane z elementu źródłowego do elementu docelowego podczas akcji [Duplikuj] w edytorze elementów.

Jeśli wymagane jest inne zachowanie, w razie potrzeby należy zaimplementować metodę duplicateDetail interfejsu Hook DetailDependentHook.

Należy pamiętać, że w przypadku funkcji Wyszukaj i dodaj pozycje obowiązują inne zasady. Więcej informacji na ten temat można znaleźć w artykule Definicja Hook Contract: Wyszukaj i dodaj pozycje.

W razie potrzeby interfejs Hook DetailApplyDefaultsHook jest dostępny do określania wartości domyślnych nowych atrybutów. Służy on również do przesyłania wartości ze źródła (np. poprzedniego dokumentu, portu wewnętrznego itp.). Więcej informacji można znaleźć w rozdziale Określanie wartości domyślnej dla danych dodanych do pozycji dokumentu.

Nowe atrybuty powinny być również sprawdzane za pomocą implementacji DetailValidateHook.

W razie potrzeby można wstawić nowe atrybuty do aplikacji dokumentu i zapisać zmiany w obiekcie deweloperskim Application extension w bazie danych repozytorium, a tym samym przenieść je do kolejnego systemu.

Należy również pamiętać, że chociaż bardzo łatwo jest dodawać atrybuty bezpośrednio w pozycji dokumentu, może to prowadzić do problemów związanych z maksymalną liczbą kolumn. Dotyczy to w szczególności aplikacji, których potencjalnie może być bardzo wiele. Jak zarządzać dodatkowymi danymi pozycji w oddzielnym zbiorze danych, można dowiedzieć się w rozdziale Dodawanie danych pozycji w dodatkowym zbiorze danych.

Dodawanie danych podstawowych do dodatkowego zbioru danych

Do istniejącej bazy dokumentów (np. SalesOrder) można dodawać własne obiekty biznesowe.

W najprostszym przypadku jest to obiekt, który ma identyfikator GUID nagłówku dokumentów jako klucz podstawowy i jest opcjonalnie dostępny.

Aby móc korzystać z dodatkowego zestawu danych w Hook, konfigurowalnych interfejsach, eksporcie/imporcie itp., należy rozszerzyć istniejący widok obiektu odpowiedniego nagłówka dokumentów za pomocą obiektu deweloperskiego Data view extension. Teraz można albo zdefiniować odpowiedni widok obiektu dla nowego obiektu biznesowego i odwołać się do niego za pomocą zmiennego odniesienia (przykłady ADO wykorzystują ten wariant), albo można wstawić nowe atrybuty jako atrybuty wirtualne, aby były one bezpośrednio dostępne w widoku obiektu nagłówka dokumentów.

Podstawowe dane dokumentu są edytowane przy użyciu tak zwanej encji, w której nowe lub zmienione podstawowe dane implementacji Hook są przechowywane w EntityHookState dla każdego modułu i instancji dokumentu. W związku z tym najpierw potrzebna jest odpowiednia implementacja dla własnych danych.

Odpowiedni EntityHookState zawiera nie tylko nowe lub zmienione dane podstawowe, ale także dane nowych i zmienionych elementów. Interfejs Hook EntityHook udostępnia zatem metody reset, create i load, za pomocą których można zainicjować EntityHookState niezależnie od rozszerzenia nagłówka lub pozycji.

Nagłówek dokumentów jest zawsze edytowana w taki sposób, że tworzony jest obiekt MutableHeader z własnym stanem (MutableHeaderState), a wszelkie zmiany są następnie przenoszone do encji w dodatkowym kroku. Zmiany te są następnie zapisywane w kolejnym kroku. Metody initMutableHeader, storeHeader i saveHeader są dostępne w tym celu w interfejsie Hook HeaderDependentHook. Potrzebna jest również implementacja MutableHeaderState, która zawiera zmienione dane podstawowe modułu.

Podczas kopiowania nagłówka dokumentu, metoda duplicateHeader jest używana do inicjalizacji obiektu MutableHeader (lub danych MutableHeaderState) bazy docelowej, który jest następnie przesyłany z powrotem do jednostki za pomocą storeHeader.

Interfejs HeaderDependentHook zawiera również metody deleteHeader i reorganizeHeader, które są wywoływane, gdy nagłówek dokumentów jest usuwany lub reorganizowany (patrz także sekcja Zredukowane interfejsy Hook do reorganizacji).

Jeśli dodatkowy zestaw danych ma być również obsługiwany podczas eksportu/importu, potrzebna jest również implementacja interfejsu Hook com.cisag.pgm.bi.hook.DependentAssociationHook.

Dodawanie danych pozycji w dodatkowym zestawie danych

Do istniejącej pozycji dokumentu (np. SalesOrderDetail) można dodać własne obiekty biznesowe.

W najprostszym przypadku jest to obiekt, który ma GUID nagłówka i szczegółów pozycji jako klucz podstawowy i jest opcjonalnie dostępny.

Aby móc korzystać z dodatkowego zestawu danych w Hook, konfigurowalnych interfejsach, eksporcie/imporcie itp., należy rozszerzyć istniejący widok obiektu odpowiedniego nagłówka dokumentów za pomocą obiektu deweloperskiego Data view extension. Teraz można albo zdefiniować odpowiedni widok obiektu dla nowego obiektu biznesowego i odwołać się do niego za pomocą zmiennego odniesienia (przykłady ADO wykorzystują ten wariant), albo można wstawić nowe atrybuty jako atrybuty wirtualne, aby były one bezpośrednio dostępne w widoku obiektu nagłówka dokumentów.

Dane pozycji dokumentu są przetwarzane przy użyciu encji, przy czym nowe lub zmienione dane pozycji implementacji Hook są przechowywane w EntityHookState dla każdego modułu i instancji dokumentu. W związku z tym najpierw potrzebna jest odpowiednia implementacja dla własnych danych.

Odpowiedni EntityHookState zawiera nie tylko nowe lub zmienione dane pozycji, ale także dane nowego lub zmienionego nagłówka dokumentu. Interfejs Hook EntityHook udostępnia zatem metody reset, create i load, za pomocą których można zainicjować EntityHookState niezależnie od rozszerzenia nagłówka lub pozycji.

Pozycja dokumentu jest zawsze przetwarzana w taki sposób, że tworzony jest obiekt MutableDetail z własnym stanem (MutableDetailState), a wszelkie zmiany są następnie przenoszone do encji w dodatkowym kroku. Zmiany te są następnie zapisywane w kolejnym kroku. Metody initMutableDetail, storeDetail i saveDetail są dostępne w tym celu w interfejsie Hook DetailDependentHook. Potrzebna jest również implementacja MutableDetailState, która zawiera zmienione dane pozycji modułu.

Podczas kopiowania pozycji dokumentu, metoda duplicateDetail jest używana do inicjalizacji obiektu MutableDetail (lub danych MutableDetailState) elementu docelowego, który jest następnie przesyłany z powrotem do jednostki za pomocą storeDetail.

Interfejs DetailDependentHook zawiera również metody deleteDetail i reorganizeDetail, które są wywoływane, gdy pozycja dokumentu jest usuwana lub reorganizowana (patrz także rozdział Zredukowane interfejsy Hook do reorganizacji).

Jeśli dodatkowy zestaw danych ma być również obsługiwany podczas eksportu/importu, potrzebna jest również implementacja interfejsu Hook com.cisag.pgm.bi.hook.DependentAssociationHook.

Zredukowane interfejsy Hook do reorganizacji

Niektóre dokumenty nie obsługują pełnych interfejsów HeaderDependentHook lub DetailDependentHook do zarządzania własnymi danymi w odpowiednim Hook Contract. Przykładowo, niektóre generacje dokumentów mają inne interfejsy Hook, które mogą być używane do zapisywania własnych danych, które mają zostać zmienione lub usunięte w trakcie reorganizacji.

W tym celu dostępne są interfejsy HeaderReorganisationHook i DetailReorganisationHook. Interfejs Hook HeaderDependentHook rozszerza interfejs Hook HeaderReorganisationHook, a interfejs Hook DetailDependentHook rozszerza interfejs HeaderReorganisationHook.

Zazwyczaj konkretna Hook Contract dokumentu zawiera interfejsy DependentHook lub ReorganisationHook.

Jeśli początkowo dostępne były tylko interfejsy ReorganisationHook, a interfejsy DependentHook zostały dodane później, wówczas konkretna implementacja Hook powinna implementować tylko interfejsy ReorganisationHook lub tylko interfejsy DependentHook.

Konwersja dokumentu

Dane własne, które rozszerzają nagłówek lub pozycję rozważanych dokumentów, mogą zostać udostępnione w obiekcie źródłowym docelowego nagłówka/pozycji przy użyciu implementacji Hook dla nagłówka/pozycji w kroku konwersji. Dane w obiekcie źródłowym można następnie uwzględnić w HeaderApplyDefaultsHook lub DetailApplyDefaultsHook w dokumencie docelowym.

Przykładowo, można zaimplementować metodę convertProposalHeader interfejsu Hook ProposalHeaderConverterHook dla bezpośrednio istniejącego atrybutu w następujący sposób:

public void convertProposalDetail(
 CustomerProposalDetailView srcDetailView,
 ProposalDetailConverterHook.Context detailConversionContext,
 TargetSource<SalesOrderDetailView> trgSource) {
 ...
 trgSource.setValue(SalesOrderDetailView.Attribute.$ado_orders_partner,
 srcDetailView.getAdo_orders_partner());
 trgSource.setValue(SalesOrderDetailView.Attribute.$ado_orders_partnerName,
 srcDetailView.getAdo_orders_partnerName());
 ...
}

Transfer z obiektu źródłowego do obiektu docelowego odbywa się w następujący sposób:

public void applyHeaderDefaults(
 SalesOrderView previousData, Source<SalesOrderView> sourceData,
 SalesOrderAccess currentData) {
 ...
 if ( sourceData != null &&
 (sourceData.contains(SalesOrderView.Attribute.$ado_orders_partner) ||
 sourceData.contains(SalesOrderView.Relation.$Ado_Orders_Partner))) {
 // from source
 currentData.setAdo_orders_partner(
 sourceData.getData().getAdo_orders_partner());
 }
 // partner name: optional attribute, from source or partner (if changed only)
 if (sourceData != null &&
 sourceData.contains(SalesOrderView.Attribute.$ado_orders_partnerName)) {
 // from source
 currentData.setAdo_orders_partnerName(
 sourceData.getData().getAdo_orders_partnerName());
 } else {
 ...
 }
 ...
}

Te dwa poziomy są używane, ponieważ obiekt źródłowy w kroku applyDefaults jest również używany dla innych źródeł, np. podczas importu, dla akcji [Wyszukaj i dodaj pozycje] itp.

Określanie wartości domyślnej dla danych dodanych do nagłówka dokumentów

Niestandardowe dane bazowe można wstępnie przyporządkować za pomocą metody applyHeaderDefaults klasy HeaderApplyDefaultsHook. Wstępnego przyporządkowania można dokonać dla nowych danych, ale także w przypadku zmian w innych istotnych atrybutach.

Poprzednie dane są również przekazywane do tej metody, dzięki czemu możliwe jest wykonanie nowego wywołania applyDefaults przed zresetowaniem w encji, przy czym poprzednie dane są zawsze dostępne jako previousData po zakończeniu ostatniego wywołania.

Implementacja Hook powinna również uwzględniać każdy istniejący obiekt źródłowy, który jest używany, np. podczas importu, konwersji itp.

Należy pamiętać, że ten Hook może być używany tylko do wstępnego przypisywania własnych atrybutów. Ograniczenie to jest konieczne, ponieważ w przeciwnym razie różne implementacje Hook nie byłyby od siebie niezależne.

Określanie wartości domyślnej dla danych dodanych do pozycji dokumentu

Niestandardowe dane elementu mogą być wstępnie przypisane za pomocą metody applyDetailDefaults klasy DetailApplyDefaultsHook. Wstępnego przypisania można dokonać dla nowych danych, ale także w przypadku zmian innych istotnych atrybutów.

Poprzednie dane są również przekazywane do tej metody, przy czym jest całkiem możliwe, że nowe wywołanie applyDefaults zostanie wykonane przed ponownym ustawieniem danych w encji, przy czym poprzednie dane są zawsze dostępne jako previousData po zakończeniu ostatniego wywołania.

Implementacja Hook powinna również uwzględniać każdy istniejący obiekt źródłowy, który jest używany, na przykład podczas importu, konwersji itp.

Należy pamiętać, że ten Hook może być używany tylko do wstępnego przypisywania własnych atrybutów i że nie można wprowadzać żadnych zmian strukturalnych w elementach (np. dodawać/usuwać szczegółowych elementów). Ograniczenie to jest konieczne, ponieważ w przeciwnym razie różne implementacje Hook nie byłyby od siebie niezależne.

Nowe podstawowe kontrole dla istniejących lub nowych danych

Metoda validateHeader klasy HeaderValidateHook może być używana do dodawania nowych sprawdzeń dla nagłówka dokumentu.

Kontrole te mogą odnosić się do własnych atrybutów lub do atrybutów istniejących w standardowym systemie.

Sprawdzanie nowych pozycji dla istniejących lub nowych danych

Metoda validateDetail klasy DetailValidateHook może być używana do dodawania nowych sprawdzeń dla pozycji dokumentu.

Kontrole te mogą odnosić się do własnych atrybutów lub do atrybutów istniejących w standardowym systemie.

Nowe walidacje usuwania dla nagłówka dokumentów

Metoda validateDeleteHeader klasy HeaderValidateDeleteHook może być użyta do dodania nowych walidacji usuwania dla nagłówka dokumentu.

Nowe walidacje usuwania dla pozycji wiersza

Metoda validateDeleteDetail klasy DetailValidateDeleteHook może być użyta do dodania nowych walidacji usuwania dla pozycji dokumentu.

Nowa walidacja przed reorganizacją dokumentu

Metoda validateReorganization klasy ReorganizationValidateHook może być użyta do dodania nowych walidacji, które mogą uniemożliwić przeprowadzenie reorganizacji.

Interfejsy Hook dla statusu zamówienia

W definicji Hook Contract zamówienia zakupu dostępne są interfejsy Hook HeaderCorrespondenceStatusHook i DetailCorrespondenceStatusHook do uwzględniania rozszerzonych atrybutów nagłówka lub pozycji w statusie zamówienia nagłówka lub pozycji zamówienia zakupu.

Interfejs DetailCorrespondenceStatusHook jest również używany do wpływania na status zmiany pozycji zmiany zamówienia.

Interfejsy Hook dla statusu potwierdzenia i zmiany zamówienia w potwierdzeniu zamówienia

W definicji Hook Contract zamówienia, interfejsy Hook HeaderConfirmationStatusHook i DetailConfirmationStatusHook są dostępne do uwzględnienia rozszerzonych atrybutów nagłówka lub pozycji w statusie potwierdzenia nagłówka lub pozycji zamówienia, jak również nagłówka lub pozycji zamówienia.

Ponadto interfejsy Hook ChangeOrderHeaderHook i ChangeOrderDetailHook są dostępne w definicji Hook Contract potwierdzenia zamówienia. Z jednej strony można je wykorzystać do znalezienia odpowiednich zmian podczas przygotowywania realizacji potwierdzenia zamówienia. Z drugiej strony, w razie potrzeby można przenieść niestandardowe atrybuty nagłówka lub atrybuty pozycji z potwierdzenia zamówienia do zamówienia.

Interfejs Hook do dodawania akcji

W definicjach Hook Contract w aplikacji typu Dokument i aplikacji typu Lista dla dokumentów interfejs Hook BatchActionHook zapewnia prostą opcję przesyłania bieżącego nagłówka dokumentów (aplikacja typu Dokument) lub wybranego nagłówka lub danych pozycji (aplikacja typu Lista dla dokumentów) do zdefiniowanej aplikacji działającej w tle w celu dalszego przetwarzania.

Ta aplikacja działająca w tle może być wykonywana za pomocą przycisków [Natychmiast] i/lub [W tle], a także może mieć opcjonalne ustawienia wydruku dla wszelkich niezbędnych dokumentów wydruku.

Opcjonalnie można również zdefiniować parametry, które są przesyłane podczas wykonywania aplikacji działającej w tle.

Dalsze szczegóły można znaleźć w odpowiednich definicjach Hook Contract oraz w opisie interfejsu Hook BatchActionHook.

Interfejs Hook do rejestrowania zmienionych danych podczas procesu usuwania i zapisywania

Interfejs Hook MakePersistentHook i interfejs Hook MakePersistentState są dostępne do rejestrowania zmienionych danych podczas procesu usuwania i zapisywania.

Każdy moduł powinien udostępniać implementację MakePersistentState. Służy ona do rejestrowania zmian podczas zapisywania lub usuwania.

Na początku zapisywania lub usuwania tworzona jest nowa instancja MakePersistentState i wywoływana jest metoda beginMakePesistent interfejsu MakePersistentHook.

Pod koniec zapisywania lub usuwania wywoływana jest metoda endMakePersistent interfejsu MakePersistentHook. W tym kontekście możliwe jest zawarcie wszystkich zarejestrowanych zmian w dokumencie w jednym bloku.

Implementacja metod saveHeader/deleteHeader w HeaderDependentHook lub saveDetail/deleteDetail w DetailDependentHook jest wymagana do faktycznego rejestrowania zmian w nagłówku lub pozycji. Widoki obiektów przekazywane do tych metod implementują interfejs MakePersistentStateRetriever, dzięki czemu odpowiednia instancja MakePersistentState jest również dostępna podczas zapisywania/usuwania w celu rejestrowania odpowiednich zmian.

Opcjonalnie, metody mainCommitPerformed i mainRollbackPerformed mogą być również zaimplementowane w MakePersistentHook.

Po tym kończy się czas życia instancji MakePersistentState.

Interfejs Hook do aktualizacji nagłówka w przypadku zmian pozycji

Podstawowe dane mogą zależeć od właściwości pozycji (np. liczniki, sumy itp.). Interfejs Hook RefreshHeaderHook jest dostępny do aktualizacji danych podstawowych. Służy on do przesyłania poprzednich i nowych danych pozycji do wszystkich implementacji Hook, a także zapewnia zmienny nagłówek, która jest następnie zapamiętywana w encji.

Interfejs Hook do definiowania atrybutów rodzaju dokumentu, które nie powinny być już zmienne po pierwszej instancji dokumentu

Można użyć interfejsu Hook com.cisag.app.general.order.hook.log.CriticalTypeAttributesRegistrationHook, aby zdefiniować atrybuty rodzaju dokumentu, które nie powinny być już zmieniane, jeśli dokument już istnieje dla danego rodzaju dokumentu.

Interfejs Hook com.cisag.app.general.order.hook.log.CriticalTypeAttributesRegistrationHook jest dostępny w następujących Hook Contractach:

Hook Contract

Poziom Logika

Dla następujących dokumentów dostępne są odpowiednie definicje Hook Contract dla poziomu Logika.

Poziom Interfejs użytkownika

Aplikacje typu Dokument

Dla następujących aplikacji typu Dokument dostępne są odpowiednie definicje Hook Contract dla poziomu Interfejs użytkownika.

Aplikacje typu Lista dla dokumentów

Dla następujących aplikacji typu Lista dla dokumentów dostępne są odpowiednie definicje Hook Contract dla poziomu Interfejs użytkownika.