Bot checkpoint przy wznawianiu

Picture of esitio2

esitio2

Opis wyzwania

Wyobraź sobie, że pracujesz nad projektem. Określasz swój cel, prawdopodobnie zapisujesz co należy zrobić, a następnie przekreślasz każde z tych działań po ich ukończeniu. Ten projekt prawdopodobnie zajmie trochę czasu – musisz spać, a trudno być skupionym i produktywnym przez cały dzień, prawda? Do tego dochodzą rozproszenia. Kiedy więc wracasz do pracy nad projektem (szczególnie po jakimś czasie) i chcesz go wznowić, od czego zaczynasz? W moim przypadku wziąłbym tę kartkę papieru i sprawdził, co zostało już zrobione i co należy zrobić dalej, aby określić etap, na którym obecnie znajduje się proces realizacji projektu.

Kiedy bot pracuje nad ukończeniem procesu, mogą wystąpić nieoczekiwane przerwy, takie jak problemy z siecią. W przypadku prostych automatyzacji zazwyczaj można go zrestartować i po prostu zacząć od początku procesu. Jednak czasami istnieją działania, których po wykonaniu nie można powtórzyć – co wtedy? Wtedy bot powinien rzucić okiem na swoją kartkę papieru.

Rozwiązanie

Podczas identyfikacji niedawno zautomatyzowanego procesu użytkownicy biznesowi zażądali, aby niektóre transakcje SAP były wykonywane tylko raz dla danego zestawu parametrów. Dodatkowe wymagania obejmowały zapisywanie przez bota danych wytworzonych podczas przetwarzania do plików Excel opartych na MS Teams, zawierających dane wejściowe dla różnych etapów procesu. Ze względu na wymagania bot musi sprawdzić swój stan przed rozpoczęciem przetwarzania. Wynikowa procedura, w uproszczonej formie, jest pokazana na poniższym diagramie BPMN:

[Graphics 1] Simplified self-orienting procedure
[Grafika 1] Uproszczona procedura samo-orientacji

Zauważmy, że możemy określić łącznie 6 stanów startowych bota, z których każdy jest poprzedzony węzłem warunkowym sprawdzającym warunek przejścia – jeśli dany warunek jest spełniony, bot pomija odpowiedni etap:

[Graphics 2] States in starting procedure
[Grafika 2] Stany w procedurze startowej

Ponadto, przyglądając się bliżej, możemy zobaczyć, że zakładając start bota od stanu 1, ścieżka optymalna całkowicie pomija stan 2 i przechodzi bezpośrednio do stanu 3. W przypadku niepowodzenia części generowania dokumentów bot wznawia od stanu 2, który wymaga danych wejściowych od użytkowników poza wykonaniem bota – numer dokumentu mógł już zostać wygenerowany, ale nie dostarczony do pliku, co skutkuje błędem:

[Graphics 3] States extended
[Grafika 3] Rozszerzone stany

Wnioski

W zależności od złożoności zautomatyzowanego procesu, określenie stanów bota podczas wykonania może być trudne. Liczba punktów kontrolnych zwiększa bezpieczeństwo przetwarzania danych, jednak kosztem ciągłego zapisywania i przesyłania danych, co zmniejsza efektywność wykonania. Ryzykiem można zarządzać, stosując różne sposoby zachowania stanu bota. Excel jest przyjaznym dla użytkownika, ale czasochłonnym rozwiązaniem. Z drugiej strony, jeśli proces wymaga komunikacji i opóźnionych danych wejściowych od użytkowników końcowych lub jest z innych powodów podatny na wielokrotne wznawianie, rozwiązanie pomaga zachować zasoby.

Share the Post:

Contact KTBNet today!

Everything in one place

Related