Rozwój aktualizacji danych

Ten artykuł opisuje sposób postępowania przy implementacji aktualizacji danych. Szczegółowo opisano, jak zbudowana jest struktura programu aktualizacji danych. Ponadto wyjaśniono różnice między aktualizacjami danych uruchamianymi w trybie dialogowym i w tle.

W artykule dotyczącym aplikacji Zapytanie o aktualizacje danych znajdują się dodatkowe informacje na temat sposobu wykonywania aktualizacji danych.

Wymagania wstępne

Wymagana jest znajomość aplikacji Obiekty deweloperskie oraz Zapytanie o aktualizacje danych, a także obiektu deweloperskiego typu Aplikacja.

Opis

Aktualizacje danych to aplikacje, za pomocą których można modyfikować dane dowolnych obiektów biznesowych. Każda aktualizacja danych jest wykonywana dla wszystkich baz danych, które zawierają dane obiekty biznesowe. Do uruchamiania aktualizacji danych należy używać aplikacji Zapytanie o aktualizacje danych.

Aktualizacja danych jest rejestrowana jako aplikacja w aplikacji Obiekty deweloperskie. Na podstawie wpisanego głównego obiektu biznesowego definiuje się, na których bazach danych ma zostać uruchomiona aktualizacja danych. Zależy to od tego, na której bazie danych dany obiekt biznesowy został utworzony (baza OLTP, baza OLAP, baza repozytorium, baza konfiguracji). Aktualizacja danych nie musi jednak odnosić się wyłącznie do wskazanego obiektu biznesowego. Dla aktualizacji danych pracujących na obiektach OLAP należy wybrać obiekt OLTP pasujący do obiektu OLAP.

Istnieją różne typy aktualizacji danych:

• Aktualizacje danych w tle to aplikacje działające w tle, które mogą być uruchamiane w zleceniach przetwarzania.
• Równoległe aktualizacje danych to aktualizacje danych w tle, w których dane są przetwarzane równolegle. Z reguły równoległe przetwarzanie wyraźnie skraca czas wykonania aktualizacji danych.
• Dialogowe aktualizacje danych to aplikacje dialogowe, uruchamiane interaktywnie przez użytkownika. Mogą przed wykonaniem pobierać od użytkownika parametry.

Pomoc kontekstowa aktualizacji danych powinna zawierać następujące informacje:

• cele aktualizacji danych
• wymagania wstępne dla uruchomienia aktualizacji danych

Aktualizacje danych w tle

Aktualizacje danych w tle są aplikacjami działającymi w tle o szczególnym zastosowaniu Aktualizacja danych lub Aktualizacja danych w tle. Aktualizacje danych w tle powinny znajdować się w obszarze nazw com.<obszar nazw>.app.update.log.

W zależności od ustawienia pola Szczególne zastosowanie aktualizacje danych w tle są uruchamiane w zleceniu przetwarzania albo automatycznie podczas instalacji aktualizacji oprogramowania.

Aktualizacje danych powinny wymagać uruchomienia tylko jednokrotnie. Aplikacje do regularnych korekt danych należy implementować jako aplikacje dialogowe lub aplikacje w tle, a reorganizacje — jako aplikacje reorganizacyjne.

Szczególne zastosowanie Aktualizacja danych

Aktualizacje danych w tle o szczególnym zastosowaniu Aktualizacja danych są wykonywane podczas instalacji tej aktualizacji oprogramowania, która zawiera daną aktualizację danych. W czasie wykonywania tych aktualizacji danych żaden użytkownik nie może zalogować się do systemu.

Takie zachowanie ma następujące zalety:

• nie można zapomnieć o wykonaniu aktualizacji danych,
• aktualizacja danych jest wykonywana, gdy żaden użytkownik nie jest aktywny w systemie,
• aktualizacja danych jest z pewnością wykonywana, zanim ewentualnie zmieniona logika aplikacji zacznie pracować na danych,
• brak dodatkowej pracy podczas instalacji aktualizacji oprogramowania.

Wadą jest to, że w czasie wykonywania aktualizacji danych żaden użytkownik nie może pracować w systemie. System jest podczas instalacji aktualizacji oprogramowania znacząco dłużej niedostępny.

Szczególne zastosowanie Aktualizacja danych w tle

Aktualizacje danych w tle o szczególnym zastosowaniu Aktualizacja danych w tle nie są uruchamiane automatycznie, lecz muszą zostać uruchomione w zleceniu przetwarzania za pomocą aplikacji Zapytanie o aktualizacje danych.

Takie zachowanie ma następujące zalety:

• wykonanie aktualizacji danych może zostać zaplanowane na dowolny moment,
• aktualizacja danych wykonywana jest w tle podczas normalnej pracy, a więc dostępność systemu nie jest ograniczona.

Wady:

• nie ma ustalonego momentu wykonania aktualizacji danych; do czasu jej uruchomienia programy pracują na niepoprawionych danych,
• wykonanie aktualizacji danych nie jest wymuszane przez system.

Dialogowe aktualizacje danych

Dialogowe aktualizacje danych są aplikacjami dialogowymi o szczególnym zastosowaniu Aktualizacja danych. Powinny znajdować się w obszarze nazw com.<obszar nazw>.app.update.ui.

Dialogowe aktualizacje danych mogą być uruchamiane w aplikacji Zapytanie o aktualizacje danych wyłącznie pojedynczo i interaktywnie. Umożliwiają wprowadzanie parametrów poprzez interfejs.

Zaleta:

• przed wykonaniem można wprowadzić parametry.

Wady:

• muszą być uruchamiane pojedynczo, co w każdym systemie, do którego wgrywana jest odpowiednia aktualizacja oprogramowania, powoduje relatywnie wysoki nakład pracy ręcznej,
• są wykonywane w sesji interaktywnej; przy długim czasie wykonania przeglądarka może zostać zamknięta albo połączenie może wygasnąć i w takiej sytuacji użytkownik może nie móc już odczytać istotnych komunikatów,
• do wprowadzania parametrów mogą być potrzebni użytkownicy merytoryczni, ponieważ administrator często nie jest w stanie określić parametrów.

Jeżeli aktualizacja danych nie wymaga wprowadzania parametrów, zamiast dialogowej aktualizacji danych należy użyć aktualizacji danych w tle.

Przy wyborze aktywnej bazy danych dla dialogowych aktualizacji danych należy uwzględnić:

• jeżeli jako wymaganą aktywną bazę danych wybrano OLTP, aktualizacja danych może zostać wykonana tylko na bazie danych bieżącej sesji. Próba wyboru innej połączonej bazy OLTP zostanie zablokowana komunikatem błędu,
• jeżeli dialogowa aktualizacja danych ma zostać wykonana na wszystkich bazach OLTP podłączonych do systemu, jako wymagana aktywna baza danych może być wpisana wyłącznie baza repozytorium.

Możliwość wykonywania aktualizacji danych

Aktualizacja danych nie może zostać wykonana, jeżeli wpisany obiekt biznesowy jest zablokowany przez zadanie deweloperskie lub przez instalację aktualizacji oprogramowania. Jeżeli obiekt biznesowy jest jednostką biznesową, sprawdzana jest blokada również wszystkich powiązanych zależności. W przypadku zależności sprawdzany jest wyłącznie jej status blokady. Ograniczenie to jest konieczne, ponieważ w takim stanie nie można określić stanu tabel bazy danych.

Uruchamianie aktualizacji danych podczas instalacji aktualizacji oprogramowania

Jeżeli aplikacja jest zablokowana przez zadanie deweloperskie, aktualizacja danych nie może zostać wykonana, ponieważ status po wykonaniu nie jest zapisywany. W konsekwencji nie można stwierdzić, czy aktualizacja danych została wykonana poprawnie.

Jeżeli klasa Java lub bezpośrednio używana klasa Java jest zablokowana przez zadanie deweloperskie, aktualizacja danych również nie może zostać wykonana. Wymagana wersja klasy Java znajduje się w zadaniu deweloperskim, a nie w systemie plików. W efekcie zostałaby użyta wersja poprzednia i nie można zagwarantować poprawnego wykonania aktualizacji danych.

Uruchamianie aktualizacji danych w aplikacji Zapytanie o aktualizacje oprogramowania

Jeżeli aplikacja, klasa Java lub bezpośrednio używane przez nią klasy Java są zablokowane przez aktualizację oprogramowania, aktualizacja danych nie może zostać wykonana.

Jeżeli aplikacja jest zablokowana przez zadanie deweloperskie, klasa Java oraz bezpośrednio używane klasy Java mogą być zablokowane wyłącznie w tym samym zadaniu deweloperskim. Tylko wtedy jest zagwarantowane, że podczas wykonania zostanie użyty właściwy stan klas. Ponadto status wykonania nie jest zapisywany. Służy to ułatwieniu prac deweloperskich nad aktualizacją danych.

Jeżeli używana klasa Java jest zablokowana przez zadanie deweloperskie, aktualizacja danych w tle może zostać wykonana wyłącznie natychmiast na bieżącym SAS. Użytkownik musi zapewnić, że bieżący SAS używa właściwego stanu klas.

Status wykonania

Po wykonaniu aktualizacji danych status wykonania informuje o powodzeniu lub niepowodzeniu wykonania. Status wykonania jest zapisywany i wyświetlany w aplikacji Zapytanie o aktualizacje danych.

Dostępne są następujące statusy wykonania:

• State.SUCCESS — wykonano pomyślnie: aktualizacja danych została wykonana bez błędów
• State.ABORTED_WITH_ERROR — przerwano z błędem: podczas wykonywania aktualizacji danych wystąpił błąd. Proces został przerwany. Aktualizację danych należy uruchomić ponownie.
• State.PROCESSED_WITH_ERROR — wykonano z błędem: podczas wykonywania aktualizacji danych wystąpił błąd. Proces nie został przerwany.
• State.NOT_CALLED — jeszcze nie wywołano (domyślnie): aktualizacja danych nie została wykonana
• State.INTERNAL_ERROR — wewnętrzny, nieobsłużony błąd

Implementacja aktualizacji danych w tle

Abstrakcyjna klasa com.cisag.pgm.base.CisUpdateBatchApplication jest klasą bazową dla wszystkich aktualizacji danych w tle. Dla każdej bazy danych wywoływana jest metoda execute, w której wykonywane są właściwe działania. Metoda execute jest abstrakcyjna i musi zostać zaimplementowana.

W klasie bazowej dostępny jest obiekt CisEnviroment, z którego można korzystać (MessageManager, SystemManager, ObjectManager, TransactionManager).

Podczas implementacji aktualizacji danych w tle należy dokładnie sprawdzić, czy nie lepiej zrealizować jej jako równoległej aktualizacji danych. Dalsze informacje znajdują się w rozdziale Implementacja równoległych aktualizacji danych.

Metody logiki w API

protected abstract short execute();

W metodzie execute wykonywana jest aktualizacja danych. Jeżeli główna encja biznesowa aktualizacji danych znajduje się w bazie OLTP, wówczas execute jest wywoływane osobno dla każdej bazy OLTP — każdorazowo w odpowiedniej sesji.

W związku z tym w implementacji metody execute można m.in. zakładać istnienie transakcji typu dummy. Za pomocą wartości zwracanej można przekazać status wykonania (czy aktualizacja danych przebiegła pomyślnie, czy wystąpił błąd). Metoda protected short getState( ) umożliwia odczyt dotychczasowego statusu wykonania aktualizacji danych.

Metoda protected void setMultipleAllowed(short allowed) ustawia status wywołania aktualizacji danych. Pozwala to sterować tym, czy aktualizacja danych może zostać uruchomiona jednokrotnie, czy wielokrotnie.
Przykład: jeżeli aktualizacja danych zakończy się powodzeniem, nie ma potrzeby uruchamiania jej ponownie. Jeżeli jednak wystąpi błąd, powinna istnieć możliwość ponownego uruchomienia aktualizacji danych.

• Wielokrotne wywołanie (domyślnie): MultipleCalls.ALLOWED
• Jednorazowe wywołanie: MultipleCalls.NOT_ALLOWED

Metoda protected void setParameterList(CisParameterList parameters) umożliwia zapisanie informacji wykonawczych (runtime) aktualizacji danych. Zawartość listy jest zapisywana. Dzięki temu np. w przypadku błędu można zapisać w liście parametrów dane, które przy ponownym uruchomieniu aktualizacji danych zostaną wczytane i przeanalizowane. Pozwala to np. określić, w którym miejscu należy kontynuować aktualizację danych albo dla której bazy danych aktualizacja danych zakończyła się powodzeniem.

Wcześniej zapisane dane można odczytać metodą protected CisParameterList getParameterList().

Przykładowa struktura aktualizacji danych w tle

public class UPD.. extends CisUpdateBatchApplication {
public UPD..() {
}
// Wykonywanie aktualizacji danych
public short execute() {
// Zainicjalizować status aktualizacji danych
short result = STATE_SUCCESS;
setMultipleAllowed( MULTICALL_NOT_ALLOWED );
// Otworzyć transakcję
byte[] tmGuid = tm.beginNew();
try {
// Kod aktualizacji
// w przypadku błędu:
//result = STATE.ABORTED_WITH_ERROR;
//lub STATE.PROCESSED_WITH_ERROR;
//setMultipleAllowed(MULTICALL_ALLOWED);
//koniec obsługi błędu

tm.commit(tmGuid);
} catch (RuntimeException ex) {
tm.rollback(tmGuid);
//w zależności od błędu ustawić odpowiedni status
result = STATE_ABORTED_WITH_ERROR;
//lub STATE_PROCESSED_WITH_ERROR
//lub INTERNAL_ERROR;
setMultipleAllowed(MULTICALL_ALLOWED);
}
return result;
}
}

Implementacja równoległych aktualizacji danych

Równoległa aktualizacja danych jest aktualizacją danych w tle, która jest wykonywana w wielu wątkach. Dzięki takiemu równoległemu wykonywaniu możliwe jest lepsze wykorzystanie sprzętu, a czas wykonania aktualizacji danych może zostać znacząco skrócony.

Równoległe aktualizacje danych szczególnie dobrze nadają się do jednakowych i niezależnych zmian w wielu rekordach danych. Kolejność przetwarzania rekordów danych w przypadku równoległej aktualizacji danych nie może być zagwarantowana. Jeżeli istnieją zależności pomiędzy modyfikowanymi rekordami danych lub kolejność przetwarzania ma znaczenie, wówczas realizacja jako równoległa aktualizacja danych może być w pewnych okolicznościach trudna albo nie mieć sensu.

Równoległa aktualizacja danych jest wykonywana w następujących fazach:

1. Podział danych na bloki (metoda start())
2. Równoległe przetwarzanie bloków (metoda process())
3. Scalenie wyników przetwarzania (metoda finish())
4. Zakończenie przetwarzania (metoda end())

Od tych faz nie można odstąpić w implementacji. Można jednak dowolnie modyfikować dane zarówno w metodzie start(), jak i w metodzie finish().

Abstrakcyjna klasa com.cisag.pgm.base.CisUpdateSubJobApplication jest klasą bazową dla wszystkich równoległych aktualizacji danych. Klasa ta dziedziczy po klasie com.cisag.pgm.base.CisUpdateBatchApplication. Dzięki temu wszystkie funkcje aktualizacji danych w tle są dostępne również w równoległej aktualizacji danych. W tym rozdziale opisano wyłącznie specyfikę równoległych aktualizacji danych.

Za pomocą metody getParameterList() można wymieniać dane pomiędzy metodami start(), finish() oraz end(). Należy pamiętać, że zawartość listy parametrów jest trwała. Oznacza to, że lista parametrów w metodzie start() nie musi być pusta, lecz może zawierać wartości z poprzedniego wykonania aktualizacji danych.

Podział danych na bloki

Należy nadpisać metodę start(), aby podzielić przetwarzane dane na mniejsze bloki. W zależności od przypadku użycia trzeba dobrać odpowiedni sposób podziału danych. Metoda void submitJob(CisUpdateSubJobParameter block) służy do przekazania bloku do przetwarzania. Do opisania zakresu bloku należy użyć klasy CisUpdateSubJobParameter. W tej klasie metodą getParameters() można zapisać dowolne dane w CisParameterList.

Dane należy dzielić na bloki o czasie wykonania wynoszącym co najmniej kilka sekund. Jeżeli bloki mają zbyt krótki czas wykonania, narzut związany z zrównolegleniem zniweluje korzyści. Jeżeli pojedyncze bloki mają zbyt długi czas wykonania, korzyść z zrównoleglenia będzie ograniczona.

Możliwości podziału danych na bloki:

• Lista z GUID — lista parametrów bloku zawiera listę GUID-ów instancji obiektów biznesowych, które mają zostać zmienione. Listy w blokach mają ograniczony rozmiar. Podział na listy GUID-ów jest łatwy do zaimplementowania, ale w zależności od liczby GUID-ów może powodować pewien narzut.
• Podział według kryteriów merytorycznych — bloki mogą być tworzone według kryteriów merytorycznych, np. rodzajów zleceń, magazynów, organizacji itp. Podział według kryterium merytorycznego może prowadzić do bardzo nierównych rozmiarów bloków, np. gdy klient używa tylko jednej organizacji.
• Podział według przedziałów czasowych, np. kwartałów — podział przetwarzania według przedziałów czasowych może być szczególnie sensowny w przypadku danych ruchu. Okresy szczytowe, takie jak np. sezon świąteczny, również mogą prowadzić do nierównych rozmiarów bloków.

Wartością zwracaną metody start() jest status wykonania. Każda wartość inna niż State.SUCCESS przerywa dalsze przetwarzanie. Wyjątków zasadniczo nie należy przechwytywać, lecz przekazywać dalej.

Równoległe przetwarzanie bloków

Bloki, które zostały podzielone przez metodę start(), są przetwarzane w metodzie process(). Zawartość każdego bloku jest opisana za pomocą listy parametrów.

Każdy blok ma oddzielny status wykonania, który jest ustawiany przez wartość zwracaną metody process(). Każda wartość zwracana inna niż SUCCESS przerywa dalsze przetwarzanie bloków.

Lista parametrów w klasie CisUpdateSubJobParameter może zostać zmieniona w metodzie process(), aby przekazać informacje do metody finish(). Za pomocą tej listy parametrów można na przykład przekazać, ile obiektów w danym bloku zostało przetworzonych pomyślnie, a ile z błędami.

Scalenie wyników przetwarzania

W metodzie finish() wyniki przetwarzania wszystkich bloków są scalane. Domyślna implementacja tej metody ustala status aktualizacji danych na podstawie statusów przetwarzania poszczególnych bloków. Jeżeli tylko jeden blok ma wartość inną niż SUCCESS, metoda finish() przerywa działanie i zwraca pierwszą wartość różną od SUCCESS. Wartość zwracana metody finish() staje się statusem wykonania aktualizacji danych. Metoda finish() nie jest wywoływana, jeżeli metoda start() zwróci wartość inną niż SUCCESS.

Metodę finish() można nadpisać, aby zaimplementować rozszerzoną obsługę błędów albo aby po równoległym przetwarzaniu wykonać dalsze kroki aktualizacji danych. Do metody finish() przekazywane są CisUpdateSubJobParameter dla wszystkich przetworzonych bloków. Lista parametrów bloku może zawierać dodatkowe informacje z metody process(). W liście parametrów może być na przykład podane, ile obiektów zostało przetworzonych pomyślnie, a ile z błędami w danym bloku przez metodę process().

Zakończenie przetwarzania

Metoda end() jest wywoływana na końcu przy każdym wykonaniu aktualizacji danych. Metodę można nadpisać, aby w razie potrzeby posprzątać dane tymczasowe. Nie można zagwarantować, że end() zostanie zawsze wywołana. Jeżeli na przykład serwer aplikacji zostanie zatrzymany podczas wykonywania aktualizacji danych, wówczas end() może już nie zostać wywołana.

Implementacja dialogowych aktualizacji danych

Abstrakcyjna klasa com.cisag.pgm.base.UpdateApplication jest klasą bazową dla wszystkich dialogowych aktualizacji danych. W tej klasie sterowany jest przebieg dialogowej aktualizacji danych. Każda baza danych, na której ma zostać uruchomiona aktualizacja danych, jest rozpatrywana osobno. Najpierw wywoływana jest metoda checkPreConditions — tutaj sprawdzane jest, czy aktualizacja danych może zostać wykonana na danej bazie danych. Po pomyślnej weryfikacji wywoływana jest metoda execute, w której wykonywane są właściwe działania. Są to metody abstrakcyjne, które muszą zostać zaimplementowane.

Kolejnym elementem tej klasy bazowej jest prosta aplikacja interfejsu użytkownika, która zawiera przycisk uruchomienia na standardowym pasku narzędzi oraz opis aktualizacji danych (pomoc kontekstowa aplikacji). Interfejs może zostać dowolnie rozszerzony. Jest to konieczne na przykład wtedy, gdy wymagane są określone dane wejściowe od użytkownika.

W klasie bazowej dostępny jest obiekt CisEnviroment, z którego można korzystać (MessageManager, SystemManager, ObjectManager, TransactionManager).

Metody logiki w API

protected abstract boolean checkPreConditions(byte[] databaseGuid)

W tej metodzie można sprawdzić warunki wstępne, czy aktualizacja danych może zostać wykonana na bieżącej bazie danych. Przekazana GUID jest identyfikatorem GUID bazy danych. Wszystkie transakcje powinny być otwierane z użyciem tej GUID, aby transakcja nie odwoływała się za każdym razem do aktywnej bazy OLTP. Przykładowo, tm.beginNew(databaseGuid). Tylko jeżeli w tej metodzie spełnione są wszystkie warunki, aktualizacja danych może zostać wykonana.

protected abstract short execute(byte[] databaseGuid)

W metodzie execute wykonywana jest aktualizacja danych. Również tutaj wszystkie transakcje powinny być otwierane z użyciem przekazanej GUID bazy danych. Za pomocą wartości zwracanej można przekazać status wykonania: czy aktualizacja danych przebiegła pomyślnie, czy wystąpił błąd.

Status wykonania można ustawić również metodą protected void setState(short state).

Metodą protected short getState() można odczytać dotychczasowy status aktualizacji danych.

Metoda protected void setMultipleAllowed(short allowed) ustawia status wywołania aktualizacji danych.
Pozwala to sterować tym, czy aktualizacja danych może zostać uruchomiona jednorazowo czy wielokrotnie. Przykładowo, jeżeli aktualizacja danych zakończy się powodzeniem, nie trzeba jej uruchamiać ponownie. Jeżeli jednak wystąpi błąd, powinna istnieć możliwość ponownego uruchomienia aktualizacji danych.

• Wywołanie wielokrotne (domyślnie): MULTICALL_ALLOWED
• Wywołanie jednorazowe: MULTICALL_NOT_ALLOWED

Metoda protected void setParameterList(CisParameterList parameters) umożliwia zapisanie informacji wykonawczych aktualizacji danych. Zawartość listy jest zapisywana. Dzięki temu np. w przypadku błędu można zapisać w liście parametrów dane, które przy ponownym uruchomieniu aktualizacji danych zostaną wczytane i przeanalizowane. Pozwala to m.in. określić, w którym miejscu należy kontynuować aktualizację danych albo na której bazie danych aktualizacja danych zakończyła się powodzeniem.

Wcześniej zapisane dane można odczytać metodą protected CisParameterList getParameterList().

Metody GUI w API

protected void initUserInterface()

Dostosowanie/rozszerzenie interfejsu użytkownika. Metoda klasy bazowej musi zostać w każdym przypadku wywołana (super.initUserInterface()).

protected void applyDefaults()

Przy rozszerzeniu interfejsu użytkownika można tutaj ustawić określone ustawienia domyślne.

protected void initCoolBar()

Przed dodaniem nowych akcji do standardowego paska narzędzi należy wywołać metodę klasy bazowej (super.initCoolBar()). Tylko wtedy jest zagwarantowane, że przycisk uruchomienia zostanie poprawnie zainicjalizowany.

protected void dataFromUi()
protected void dataToUi()

Aktualizacja interfejsu. Również tutaj należy wywołać metody klasy bazowej (super.dataFromUi(), super.dataToUi()).

protected void validate()

Sprawdzenie wprowadzonych danych w dostosowanym interfejsie użytkownika.

Przykładowa struktura dialogowej aktualizacji danych

public class UPD.. extends UpdateApplication {
public UPD..() {
}
// Sprawdzenia przed uruchomieniem aktualizacji danych na
// konkretnej bazie danych
protected boolean checkPreConditions(byte[] databaseGuid) {
boolean result = true;
// Otworzyć transakcję na konkretnej bazie danych
byte[] tmGuid = tm.beginNew(databaseGuid);
try{
// dalsze sprawdzenia
result = true; //result = false;
} finally {
tm.rollback(tmGuid);
}
return result;
}
// Wykonywanie aktualizacji danych na konkretnej bazie danych
protected short execute(byte[] databaseGuid) {
// Zainicjalizować status aktualizacji danych
short result = STATE_SUCCESS;
setMultipleAllowed( MULTICALL_NOT_ALLOWED );
// Otworzyć transakcję na konkretnej bazie danych
byte[] tmGuid = tm.beginNew(databaseGuid);
try {
// Kod właściwej aktualizacji

// w przypadku błędu w tym miejscu
//(np. nieoczekiwane wartości, zazwyczaj przyczyny merytoryczne):
//result = STATE_ABORTED_WITH_ERROR;
//lub STATE_PROCESSED_WITH_ERROR;
//setMultipleAllowed(MULTICALL_ALLOWED);
//tm.rollback(tmGuid);//w zależności od potrzeby
//koniec obsługi błędu dla tego przypadku.

tm.commit(tmGuid);
}catch (RuntimeException ex) {
tm.rollback(tmGuid);
//w zależności od występującego błędu ustawić odpowiedni status
result = STATE_ABORTED_WITH_ERROR;
//lub STATE_PROCESSED_WITH_ERROR;
setMultipleAlowed(MULTICALL_ALLOWED);
//lub MULTICALL_NOT_ALLOWED
}
return result;
}
}