Autonomous Transactions - warto wiedzieć

Obecnie pracujemy nad pewnym projektem, który w dużej mierze opiera się na interfejsach. Interfejsy te będą służyły do zaciągania zewnętrznych informacji z kilku systemów. Wszystko było by fajnie jak by dane zewnętrzne wprowadzane do interfejsów były czyste. Niestety, mówimy tutaj o sytuacji idealnej, która występuje jedynie w teorii. Praktyka to wieczna walka z bzdurami, które próbują się wkraść przez wszelkie dziury interfejsów, tu np próba przekazania informacji do naszego systemu z ID (klucz obcy), który nie istnieje u nas (detail nie posiada mastera w naszym systemie) itp itd.
Jeżeli ktoś kiedyś próbował robić integrację wielu systemów to wie o czym mówię.
Jak nad tym wszystkim zapanować ?
Jak kontrolować rekord po rekordzie z obcą informacja, która może zrobić po naszej stronie zupełny mess ?
A na końcu, jak namierzyć winowajcę naszego kłopotu ?

Lekarstwem na to wszystko jest dobry system logowania. Innymi słowy mechanizm, który będzie zapisywał w odpowiednich tabelach wszelkie dodatkowe/wewnętrzne informacje, które dla użytkownika nie wiele mówią ale dla developera/help desku sporo podpowiedzą. Dobry system logowania to bardzo szeroki zakres tematyczny, który nie da się w kilku słowach na blogu przekazać, jednak pierwszą podstawową wskazówką przy budowie takiego właśnie mechanizmy powinna być tak zwana transakcja autonomiczna (Autonomous Transaction).
Co to takiego ? Jest to blok programu pls/sql, który wykonuje się poza głównym mechanizmem. Zatwierdzanie lub ewentualnie wycofywanie transakcji odbywa się niezależnie od programu wywołującego.

Poglądowo wygląda to mniej więcej tak:
załóżmy że mamy tabele LOG z jedną kolumną OPIS varchar2(4000) teraz tworzymy bardzo prosty system zapisu autonomicznego do tebaeli LOG

create or replace procedure loguj_autonomiczna_transakcja (OPISx varchar2)
is
--1 element autonomicznej transakcji
PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN
INSERT INTO LOG (OPIS) VALUES (to_char(SYSDATE,'dd/mm/yyyy hh24:mi:ss ')||OPISx);
--2 element aytonomicznej transakcji (oczywiście może też być rollback)
COMMIT;
end;

A teraz tworzymy zupełnie niezależny program który ma swoją logikę (przykład poglądowy)

begin program_wywolujacy
rozne_mechanizmy programu wywolujacego;
loguj_autonomiczna_transakcja(informajce_z_mechanizmów);

loop programu_wywolujacego
loguj_autonomiczna_transakcja(informajce_z_loop-a);
end loop;

end program_wywolujacy;

I co nam da taki mechanizm, a no to, że jak wystąpi jakiś błąd to nam nie wycofa (usunie) wszystkiego z tabeli LOG ponieważ każdy krok jest osobno commit-owany niezależnie od programu wywołującego. Dzięki temu będziemy mogli w łatwy sposób znaleźć miejsce wywrotki programu głównego, będziemy mieli zapis wartości zmiennych czasu i wszelkich innych (pewnego rodzaju czarna skrzynka programu).
Nie jest to może ściśle związane z APEX-em, ale jeżeli robiłeś chociaż raz średniej wielkości system, który wymagał pewenego nadzoru to pewenie wiesz o czym piszę.
Oczywiście projekt o którym wspominam na samym początku wpisu robimy w APEX-ie : )