Ferryt 2.0 to zaawansowana platforma do automatyzacji procesów biznesowych i administracyjnych, w tym przetwarzania różnego rodzaju wniosków. Jak każde narzędzie tego typu, wymaga od użytkowników odpowiedniego podejścia do wdrażania i obsługi procesów, ponieważ wiele potencjalnych błędów może wynikać z niepoprawnej konfiguracji, błędnych danych wprowadzonych przez użytkowników, jak również problemów technicznych, takich jak niewłaściwe działanie skryptów czy utrudniona komunikacja z bazą danych.
W sytuacji, gdy pojawiają się trudności w działaniu systemu, kluczowe staje się szybkie zlokalizowanie ich przyczyny i skuteczne rozwiązanie problemu. Dlatego warto dobrze poznać narzędzia diagnostyczne, które Ferryt 2.0 udostępnia developerom. W zależności od rodzaju problemu można skorzystać z zakładki zarządzania procesami, bardziej zaawansowanej analizy logów w bazie danych lub narzędzi developerskich w przeglądarce. Każde z tych podejść wspiera użytkowników w identyfikacji określonego typu błędów i ułatwia ich szybkie wyeliminowanie. W tym artykule przybliżę powyższe narzędzia oraz dobre praktyki w zakresie ich wykorzystania.
Zarządzanie procesami
Ferryt 2.0 oferuje moduł zarządzania procesami – podstawowe narzędzie diagnostyczne dostępne bezpośrednio w Architekcie. Umożliwia ono analizę wykonanych akcji w pojedynczych instancjach procesów oraz podgląd wartości pól na aktualnym etapie wniosku. Dokładny opis tej funkcjonalności możemy znaleźć w dokumentacji Ferryt Wiki:
http://ferryt2wiki.domdata.com/pl/Utrzymanie/Zarzadzanie_procesami
Pierwszym miejscem, które warto sprawdzić w przypadku jakichkolwiek błędów z ustawieniami pól bądź ich nieprawidłowymi wartościami, jest JSON zawierający aktualne wartości wszystkich pól wniosku.
Analiza pól może nakierować nas na błędy w mapowaniach czy walidacjach procesowych. Takie zestawienie skraca też znacząco czas analizy błędów na rejestrach, serwisach zewnętrznych, funkcjach workflow, itp. Stosując dobrą praktykę podpinania pól obsługi błędów w każdym bloczku, który daje taką możliwość, gwarantujemy sobie łatwy dostęp do kodów i opisów błędów, które mogą się na nich wydarzyć.
Historia wykonanych akcji na wniosku jest drugim przydatnym narzędziem analizy błędów. Zawiera szczegółowe informacje o wszystkich operacjach przeprowadzonych na danym wniosku, w tym o wszystkich zmianach wartości i ustawień pól wykonanych w ramach danej operacji.
Analiza historii pozwala zobrazować przepływ danej instancji procesu, jak i pojedynczych akcji. Jest to niezastąpiona pomoc w odtwarzaniu zgłoszonych błędów. Narzędzie umożliwia także namierzenie miejsc, w których błędnie przypisujemy wartości lub ustawienia pól.
Analiza błędów na poziomie bazy danych
Zdarzają się przypadki, gdy wbudowane narzędzia nie dostarczają wystarczających informacji. Wówczas bardziej szczegółową analizę można przeprowadzić na poziomie bazy danych. Ferryt 2.0 przechowuje szczegółowe informacje o wszystkich zdarzeniach w systemie, co pozwala na dogłębną diagnostykę problemów technicznych i biznesowych.
Rejestr instancji procesu to najbardziej pomocne narzędzie w analizie błędów developerskich. Jest to baza, w której – tak jak w historii wykonywanych akcji – zapisywane są wszystkie zmiany wartości pól na danym wniosku. Jednak w odróżnieniu od historii wykonywanych akcji, jesteśmy tu w stanie korzystać z warunków wyszukiwania, co znacząco przyspiesza namierzanie nieoczekiwanych zmian na kluczowych polach. W rozbudowanych procesach, nad którymi pracują duże zespoły, większość błędów możemy rozwiązać dzięki temu narzędziu, dlatego kluczowe jest jego opanowanie.
Aby namierzyć rejestr instancji procesu należy w Ferryt.Admin wejść w zakładkę kategorii procesów. Wchodzimy w interesującą nas kategorię i w zakładce partycje sprawdzamy, jaka baza oraz prefiks są przypisane do partycji standardowej. Poniżej znajduje się zapytanie (baza PostgreSQL) dla procesu o prefiksie „wniosek” w schemacie motion:
with cte as( SELECT il.taskid, il.entrytype, il.modifytimestamp, il.modifyuserid, convert_from(decode(encode(il."data", 'escape'), 'escape'),'UTF8')::jsonb as jsondata FROM motion.wniosek_instancelog il inner join motion.wniosek_instance si on il.instanceid = si.id inner join motion.wniosek_lookup_applicationnumber wla on wla.instanceid = si.id where wla.value = 'Techniczny_numer_wniosku' and il."data" like '%Nazwa_szukanego_pola%' ) select modifytimestamp, jsondata ->> 'action' AS action, jsondata ->> 'activity' AS activity, jsondata ->> 'details' AS details from cte order by "modifytimestamp" desc;
Rejestr log.ferrytlog___ to kluczowe źródło informacji o zdarzeniach systemowych. Aby z niego poprawnie korzystać musimy zadbać o prawidłową konfigurację środowiska. W parametrze ”Logger.Db.Level” należy ustawić wartość „TRACE, DB, SECRET, DATA”. Na tak skonfigurowanym środowisku rejestr ten będzie przechowywał wszystkie przeprowadzane na nim operacje, w tym błędy związane z komunikacją z innymi systemami, wyniki kompilacji czy problemy z wypełnianiem wniosków. Jeśli akcje wykonują się długo lub nie wykonują się poprawnie, analiza logów może pomóc znaleźć przyczynę problemu.
W procesach, w których występują rozbudowane reguły z wieloma warunkami, dobrą praktyką jest użycie polecenia ENV.Diagnostics.Log(). Historia wykonanych akcji w zarządzaniu procesami oraz rejestr instancji procesów pokazują rezultaty wykonanych reguł, nie wskazują jednak gdzie dokładnie w kodzie dane wartości zostały nadane. Takie informacje mogą okazać się bardzo przydatne w analizie. Na bazie możemy odłożyć je sami używając ENV.Diagnostics.Log(level, message). Niezależnie od wartości w polu level, wpisy w rejestrze odłożą się na poziomie „DEBUG”. Jeśli polecenie jest wykorzystywane wielokrotnie w procesie zalecane jest ustandaryzowanie tworzenia wartości message, np. Techniczny numer wniosku + Nazwa akcji + Nazwa reguły + wartości, które chcemy odłożyć na bazie. W taki sposób ułatwimy sobie wyszukiwanie takich wpisów. Wartości z pola message odkładają się w kolumnie description w rejestrze log.ferrytlog.
Narzędzia developerskie przeglądarki
Przedstawione wcześniej rozwiązania są pomocne w analizie błędów akcji serwerowych. Dla akcji prostych zarówno w zarządzaniu procesami, jak i na bazie odkłada się zdecydowanie mniej informacji. W takich przypadkach pomocne są narzędzia developerskie przeglądarki, które pozwalają na debugowanie skryptów oraz śledzenie zapytań sieciowych.
Aby znaleźć skrypty zawierające akcje proste, na otwartym wniosku wykonujemy inspekcję (ctrl+shift+i). Wchodzimy w zakładkę sources, tam wybieramy top -> link do naszego środowiska -> ferryt -> web/workplace -> formscripts -> simpleactions.
Znajdziemy tutaj wszystkie akcje proste dla danego statusu wniosku. W akcjach prostych wypisane są zestawy reguł, które wykonują. W skrypcie możemy wstawiać breakpointy w celu namierzenia konkretnej linii wywołującej błąd. Pozwala to również zweryfikować, czy akcja na pewno się wykonuje. Zakładka Network w narzędziach developerskich pozwala na analizę ruchu sieciowego między przeglądarką a serwerem. Tutaj możemy znaleźć informacje na temat błędów wywołujących mało opisowe komunikaty, np. „Prośba o kontakt z administratorem”.
Jeśli taki komunikat pojawił się przy próbie otwarcia wniosku, jego opis znajdziemy w zapytaniu open.
Analiza takich zapytań pozwala na znalezienie dodatkowych informacji pomocnych w znalezieniu źródła problemu.
Podsumowanie
Ferryt 2.0 oferuje zestaw narzędzi diagnostycznych do analizy błędów wynikających z działań użytkowników oraz błędów technicznych. Zarządzanie procesami umożliwia szybkie sprawdzenie historii operacji i wartości pól, co jest przydatne w podstawowej diagnostyce. Analiza bazy danych pozwala na głębsze zrozumienie problemów technicznych i nieprawidłowości w zapisanych wartościach. Z kolei narzędzia developerskie przeglądarki pomagają wykrywać błędy związane z akcjami prostymi.
Skuteczne korzystanie z tych metod pozwala na szybkie identyfikowanie błędów i ich usuwanie. Regularna analiza błędów i optymalizacja procesów pozwala osiągnąć wyższą stabilność systemu i zwiększa efektywność pracy z Ferryt 2.0.
Autor: Małgorzata Marciniak – Ferryt Developer
