Własny rejestrator

W przypadku, gdy wymienione powyżej narzędzia do wyszukiwania błędów nie wystarczą, zawsze można stworzyć własny logger i zaimplementować w nim wszystkie swoje potrzeby. Dla przykładu stwórzmy logger, który oprócz ogólnego opisu zdarzenia doda informacje o użytkowniku, który wywołał to zdarzenie oraz o jego poziomie dostępu.

Model danych loggera

Aby to zrobić, zacznijmy od stworzenia modelu w bazie danych. Potrzebujemy bardzo prostego modelu, z trzema wymaganymi polami.

• info (text) - ogólne informacje o zdarzeniu
• user (integer) - ID użytkownika
• access (array string) - grupy użytkowników (może być ich kilka)
  

Proces biznesowy loggera

Następnie stworzymy proces biznesowy zapisujący log do bazy danych. Jego zadaniem będzie odebranie informacji o dowolnym zdarzeniu, uzupełnienie jej o informacje o użytkowniku i zapisanie końcowego wyniku w bazie danych.

Aby uzyskać informacje o użytkowniku, należy użyć bloku Auth: Get current user blok. Zauważ, że będzie on w stanie reprezentować wynik jako model użytkownika tylko wtedy, gdy Middleware Token Auth był włączony na punkcie końcowym, który zainicjował jego wykonanie.

Używamy Expand User aby rozwinąć wynik i uzyskać wymagane pola. W naszym przypadku są to ID, Login, oraz Groups. Użycie dwóch pierwszych jest dość banalne, wystarczy przekonwertować Login z formatu pocztowego na standardowy String (To String blok).

W przypadku grup użytkowników sytuacja jest nieco bardziej skomplikowana. Są one przechowywane w Enum format. Jest to typ wyliczeniowy, który przechowuje w bazie danych jedynie listę identyfikatorów, a nie ich wartość tekstową. W naszym przypadku wartość 1 odpowiada grupie administratorów (Admins), a wartość 2 grupie użytkowników (Users).

Naszym zadaniem jest odszyfrowanie tego identyfikatora i zapisanie wyniku w postaci wygodnych danych tekstowych. Do tego celu potrzebne są:

• Zadeklaruj zmienną, do której będą wpisywane informacje tekstowe o grupach użytkowników. Używajmy String Array oraz Set Variable bloków.
• Rozpocznij pętlę od bloku For each loop blokiem. Otrzyma on tablicę grup użytkownika, a następnie w każdej iteracji będzie konwertował kolejną grupę na jej wartość tekstową i dodawał ją do tablicy.
• Używając Switch sprawdź grupę użytkownika i w zależności od wyniku skieruj proces dalej.
• Używając bloku String oraz Set Variable zapisz w zmiennej wymaganą wartość grupy użytkownika.
• Użyj bloków Append Array i Set Variable aby dodać wynik do tablicy i zapisać go w zmiennej zadeklarowanej przed rozpoczęciem pętli.
  

Po zakończeniu pętli powinieneś użyć bloku Concat Strings (Multiple) aby z rozproszonych danych utworzyć końcowy ciąg znaków, który zostanie przekonwertowany na Text i zapisany do dziennika.

Ostatnią czynnością jest wygenerowanie log modelu i zapisanie go do bazy danych.

Wynikowy BP powinien wyglądać tak:

Logger endpoint

Proces biznesowy jest już gotowy. Teraz musimy stworzyć dla niego endpoint. Aby to zrobić, zastąpimy systemowy proces biznesowy POST /log/ endpointa procesem biznesowym, który został właśnie utworzony.

Teraz nasz własny dziennik jest całkowicie gotowy do pracy. Można wrócić do samego początku modułu, do Basic functions procesu biznesowego i zastąpić standardowy dziennik tym, który sam stworzyłeś.

Teraz przy każdym uruchomieniu obliczeń specjalny dziennik będzie zapisywał nie tylko informacje o samym fakcie tego zdarzenia, ale także o tym, który użytkownik je wykonał. Wynik możemy sprawdzić w Swagger.

Świetnie, nasz log naprawdę działa. Teraz zawiera on informacje o zdarzeniu, loginie użytkownika oraz jego prawach dostępu.

Możliwe błędy i zalecane działania

W rezultacie strukturyzujemy możliwe warianty błędów i akcje do ich naprawienia.

• Błędy w samym procesie biznesowym. Zalecane jest wykorzystanie logów do weryfikacji krok po kroku. W ten sposób można sprawdzić sam fakt uruchomienia danego bloku procesu biznesowego oraz wszystkie parametry, które ten blok wykorzystuje, zarówno na wejściu, jak i na wyjściu.
• Błędy w wysyłaniu żądania do serwera. W tym celu należy użyć strony Developer Tools w przeglądarce. Możesz sprawdzić fakt wysłania żądania, sparsować jego strukturę i zobaczyć otrzymaną odpowiedź.
• Żądania są źle sformatowane. Zaleca się używanie Swagger do dokładnego testowania, sprawdzania różnych opcji zapytań, kombinacji parametrów.
• Wynik żądania nie jest poprawnie parsowany. Zdarza się, że czekamy na wynik tam, gdzie go nie powinno być. Na przykład dodajemy dane do bazy, ale nie aktualizujemy ich w tabeli, która te dane wyświetla. Pamiętaj, że każdy komponent wymaga odpowiedniego procesu biznesowego i upewnij się, że ten proces jest poprawnie skonfigurowany.