Wprowadzenie¶

Koncepcja EDA (Event Driven Automation) wywodzi się z koncepcji systemów sterowanych zdarzeniowo. Systemy sterowane zdarzeniowo są to systemy, które generują zdarzenia wtedy, kiedy coś się w nich dzieje (np pojawiło się nowe zamówienie, zamówienie zmieniło stan, pojawiła się nowa dostawa towaru, itp). Użytkownik z odpowiednimi uprawnieniami (np administrator) ma możliwość definiowania zestawu reguł automatyzacji. Reguła automatyzacji łączy zdarzenie spełniające jakieś warunki (np zamówienie zmieniło stan na “w realizacji”) z czynnością lub zestawem czynności, które są automatycznie wywoływane, gdy wystąpi takie zdarzenie (np. wysłanie maila do klienta wg zadanego szablonu). Dzięki takim regułom system zaczyna “żyć” i wykonywać zadania biznesowe bez ingerencji programistów.

Obecnie technologia Neos nie wspiera jeszcze możliwości definiowania reguł na poziomie administratora ani użytkownika, ale będzie rozbudowywana w tym kierunku. Od wersji 5.4 pozwala jednak deweloperom mającym dostęp do Neos Experta definiować komunikaty (zdarzenia i komendy), zgłaszać je na specjalną szynę w momencie, gdy wystąpi odpowiednie zdarzenie biznesowe, oraz tworzyć reakcje na te zdarzenia pisząc odpowiednie metody (handlery) w języku C#. W zależności od typu komunikatu, handlery mogą wykonać dowolny kod, który np. zaktualizuje coś w bazie danych lub skomunikuje się z webservice'em, czy też wygeneruje następne komunikaty do obsługi przez innych konsumentów. Schemat działania EDA pozwala na pracę asynchroniczną.

Zastosowania¶

Mechanizm EDA jest asynchroniczny oraz automatycznie zapisuje i gromadzi wszystkie przesyłane komunikaty. Znacznie upraszcza to niektóre procesy w technologii NEOS. Dzięki EDA można w łatwy, szybki i bezpieczny sposób rozwiązać takie problemy jak:

Komunikacja z zewnętrznymi serwisami - w prosty sposób możemy asynchronicznie zapytać dowolny serwis w sieci i przetworzyć wynik. Cała komunikacja zostaje zapisana w osobnej bazie danych co znacznie upraszcza detekcję błędów i ponowienie przetworzenia tych komunikatów, które z jakichś przyczyn przetworzyły się z błędem.
Buforowanie danych przekazywanych między systemami - od tej pory nie trzeba tworzyć struktur pośrednich do których najpierw zapiszemy odebrany komunikat a następnie mechanizmu opartego o scheduler, który asynchronicznie zacznie przetwarzanie danych. Zamiast struktur pośrednich mamy struktury danych w C#, które automatycznie są zapisywane wraz z komunikatami przez mechanizm EDA.
Konfigurację dostępu do zewnętrznych usług - konektory gromadzą parametry konfiguracyjne driverów do zewnętrznych serwisów, np wybór bramki (testowa / produkcyjna), konto, dodatkowe parametry, itp. Wywołanie komunikacji powołuje się na konkretny konektor EDA i nie musi bezpośrednio przekazywać tych parametrów.
Monitoring błędów przetwarzania - monitor EDA umożliwia filtrację historii zdarzeń wg różnych kryteriów. Umożliwia np. ponowne przetworzenie komunikatu pochodzącego w WS, który pierwotnie przetworzył się z błędem oraz jego modyfikację przed ponownym wysłaniem na szynę.
Zgłaszanie event'ów (zdarzeń) bezpośrednio z bazy danych i reagowanie na nie w kodzie projektów NEOS'owych.
Komunikację między projektami bez ingerowania w kod obnych projektów - jeśli np moduł HiD generuje zdarzenie o wystawieniu faktury VAT, to możemy we własnym projekcie napisać kod reagujący na to zdarzenie. Nie trzeba modyfikować kodu modułu HiD.
Zbyt długie i złożone przetwarzanie w ramach jednej transakcji BD - jeśli np po wystawieniu faktury VAT mamy triggery wykonujące wiele dodatkowego przetwarzania, co wydłuża transakcje i potencjalnie generuje deadlocki, to możemy w triggerze jedynie wygenerować zdarzenie, a kod przenieść do osobnej procedury SQL lub metody C#, wywoływanej w handlerze tego zdarzenia. Przetworzenie odbędzie się w osobnej transakcji, a monitor EDA zapewni kontrolę nad tym, czy wszystko się przetworzyło i gdzie są ewentualne błędy.
Replikację danych - wystarczy, że systemy stanmowiące źródło replikacji zgłoszą zdarzenia na szynę o tym, że jakieś dane pojawiły się lub uległy modyfikacji, a handler tego zdarzenia skopiuje te dane do systemu docelowego. Dzieki buforowaniu danych w komunikatach EDA mamy pełne informacje bez sięgania do bazy źródłowej, co ułatwia replikację informacji o usunięciu danych.
Przetwarzanie periodyczne - w przyszłości planowane jest wbudowanie zdarzeń timerów, co pozwoli pisać handlery wykonujące pewien kod, w określonym interwale czasu. Dzięki temu funkcjonalność schedulera zostanie wcielona do spójnego mechanizmu EDA.

Architektura i różnice względem podejścia "klasycznego Sente"¶

Aplikacje tworzone w dotychczasowej technologii opierały się na mechanizmach bazodanowych Firebirda (procedury składowane, triggery), oraz mechanizmach frameworków Sente takich jak akcje S_APPINI czy metody Neosowe. Przepływ operacji w tak tworzonych procesach był zawsze synchroniczny. Operacje zazwyczaj bywały transakcyjne. Jest to implementacja wzorca spójności natychmiastowej - w danym momencie system dokonuje operacji, oraz jest całościowo spójny. Przykładem może być proces składania zamówienia. Jeśli dodajemy zamówienie i dodajemy do niego jakieś towary, to system sprawdza, czy te towary są dostępne. W razie niedostępności dostajemy od razu wyjątek i wiemy, że danego towaru nie ma. Co więcej dodawania towarów do zamówienia, może powodować jeszcze inne operacje, nie związane z samym dodawaniem zamówienia. Może to być np. wygenerowanie powiadomień, przeliczenie stanów, czy wygenerowanie kluczy do indeksowania zamówienia. W przypadku, jeśli jakaś z tych operacji się nie uda - nie uda się złożenie zamówienia. Czasem jest to pożądane - np. żeby nie sprzedawać, towaru, którego nie mamy. Niemniej są operacje, które nie są niezbędne w danym procesie - jak np. przeliczenie kluczy indeksacji. Co więcej, błąd w mechanizmie przeliczania, może spowodować, niemożliwość złożenia zamówienia. Z kolei zbyt skomplikowane algorytmy odpalane podczas składania zamówienia, mogą powodować, długi czas dodawania np. pozycji zamówienia.

Reasumując podejście spójności natychmiastowej gwarantuje: * Spójność systemu od razu po zakończeniu operacji * Ustrzega, przed nieokreślonym stanem systemu * Zapobiega błędnemu działaniu, ze względu na nieaktualne dane

Jednocześnie niesie za sobą pewne wady i ograniczenia: * Ograniczona dostępność * Możliwość wystąpienia problemów wydajnościowych * Kiepski User Expirience spowodowany niemożnością dokonania operacji, ze względu na błędy w systemach towarzyszących

EDA z kolei implementuje mechanizm spójności ostatecznej (Eventual consistency - https://en.wikipedia.org/wiki/Eventual_consistency). Odznacza się, to tym, że spójność systemu jest osiągana po pewnym czasie. W takim modelu dodanie zamówienia czy pozycji, powinno generować zdarzenia komendy indeksujące, przeliczające stany etc. jednak przetwarzane są one asynchronicznie, niezależnie od zakończenia operacji dodania pozycji. Takie podejście gwarantuje szybkie zakończenie macierzystej operacji (całość operacji towarzyszących jest wykonywana asynchronicznie), nie blokuje systemu w momencie błędu w procesie towarzyszącym. Wada takiego podejścia jest fakt, że spójność całego systemu zostanie osiągnięta, dopiero po pewnym czasie. Dla przykładu - dodanie pozycji zamówienia spowoduje zapoczątkowanie procesu indeksacji, jednak to zamówienie nie będzie możliwe do wyszukania, po towarze jaki dodaliśmy od razu po dodaniu tego towaru, a dopiero po pewnym czasie, gdy system osiągnie spójność (przetworzą się eventy indeksujące).

Podejście spójności ostatecznej gwarantuje: * Szybkość działania, uniezależniając podstawowy proces od procesów powiązanych * Wysoką dostępność - procesy powiązane nie wpływając na funkcjonowanie procesu głównego * Wysokie User Expirience

Jednocześnie niesie za sobą wady i ograniczenia: * Całość systemu nie jest od razu spójna * System jest narażony na błędy wynikające z niespójności systemu, na co należy reagować i przewidywać.

Obecnie w taki sposób zorganizowane są dwa procesy - indeksowanie danych w Global Quick Search (GQS), oraz proces OCR faktur kosztowych (driverem SkanujTo). W momencie zmiany aktywności Workflow, generuje się zdarzenie ponownej indeksacji GQS. Zmiana w Workflow jest natychmiastowa, lecz wyszukiwarka zindeksuje sobie dopiero po chwili te zmiany i dopiero wtedy aktywność, można będzie wyszukać po poczynionych zmianach. W przypadku OCR, gdy klikniemy przycisk OCR -> system zleca OCR dokumentu i umożliwia dalsza prace na okienku faktur kosztowych, natomiast sam dokument dopiero po jakimś czasie zostanie uzupełniony danymi z serwisu OCR. Czyli w obydwóch przypadkach spójność systemu będzie ostatecznie osiągnięta, ale po jakimś czasie, jednocześnie nie blokując na ten czas systemu.