Roboty, podobnie jak ludzie, nie zawsze mają całkowity wpływ na to, co się wokół nich dzieje. Różnica jest taka, że robot musi przewidzieć wszelkie możliwe sytuacje, jakie mogą się wydarzyć i z pomocą programisty przygotować się na taką ewentualność. Kiedyś usłyszałem, że zarządzanie błędami stanowi 80% projektu. Zgadzam się z tym stwierdzeniem, zwłaszcza, że gdy brak tego zarządzania, robot może nie działać tak jak należy. Głównymi punktami krytycznymi są wszelkie interakcje z użytkownikami. Jeśli dane wejściowe nie są wyciągane z systemu, a dostarczane przez pracownika występuje duże prawdopodobieństwo, że robot otrzyma dane niepoprawne lub dotyczące przypadku, który w danym momencie jest nieobsługiwany. W takich przypadkach należy wybrać odpowiednie działania prewencyjne. Poka-Yoke W metodologii Lean Six Sigma funkcjonuje rozwiązanie Poka-Yoke (jap. Zapobieganie błędom), które ma uniemożliwiać błędne wykorzystanie dostępnych narzędzi. Przykładowo, jeśli robot uruchamiany jest poprzez wysłany do niego mail, przygotowujemy wzorcowy Excel, do którego użytkownik wprowadza dane. Dzięki kontrolnemu plikowi XLSX robot będzie dokonywał bieżącego sprawdzania poprawności danych, a następnie wykonana zaplanowane czynności. Rozwiązanie można zaprojektować wykorzystując np. VBA oraz walidację danych. Dzięki temu pracownik otrzymuje przygotowane specjalnie dla niego narzędzie, które zarówno ułatwi jemu pracę, jak i zabezpieczy robota przed potencjalnymi błędami. W teorii ma to doprowadzić do sytuacji, w której niepoprawne zlecenia nie będą docierały do robota. Jeżeli niemożliwa jest wstępna weryfikacja danych po stronie użytkownika, wtedy należy wymusić walidację po stronie robota. Środowisko systemowe a praca robota Kolejnym powodem błędów jest brak wpływu na środowisko, w którym robot pracuje. Po pierwsze, podczas uruchamiania robot nie zna aktualnego stanu stacji, na której pracuje: Czy wcześniej uruchomiany proces nie pozostawił po sobie bałaganu? Czy niezbędne aplikacje są już uruchomione? Czy do każdej używanej aplikacji dostępne są wolne licencje? Czy dostępne są odpowiednie zasoby pamięci? Błędy możemy napotkać zarówno podczas uruchomienia, jak i w trakcie trwania automatyzacji. W pierwszym przypadku ważne jest, aby robot w jednym z pierwszych kroków spróbował przygotować sobie odpowiednie środowisko poprzez prewencyjne zamykanie aplikacji używanych zarówno w tym, jak i w innych procesach uruchamianych na danej maszynie. Co ważne, jeśli pracujemy na maszynie umożliwiającej kilka jednoczesnych sesji, musimy zamknąć aplikację z tej odpowiedniej. Niestety, ale podstawowa aktywność Kill nie rozróżnia, czy uruchomiona aplikacja została otwarta przez nas czy innego użytkownika, co może prowadzić do zamykania nie tych programów co trzeba. Przygotowani na każdą ewentualność W drugim przypadku nie wiemy, gdzie aplikacja może napotkać na wąskie gardło. Nawet jeśli znamy dany program, to nie oznacza, że u danego klienta działa on tak samo. Z całą pewnością ważnym etapem jest praca ze specjalistą nad analizą procesu, gdzie należy zwrócić uwagę na miejsca krytyczne, w których manualny proces, kolokwialnie mówiąc, się sypie. Łącząc tę wiedzę ze zdobytym dotychczas doświadczeniem, programista powinien być w stanie określić, które elementy wymagają szczególnej uwagi. Na szczęście do obsługi tych fragmentów mamy do dyspozycji wiele narzędzi, które możemy dowolnie ze sobą łączyć. Przykładowo, wykorzystując strukturę try-catch możemy dopasować więcej niż jedną ścieżkę reakcji w zależności od otrzymanego typu błędu, dopuszczając niektóre z nich do ponownego przeprocesowania. Oznacza to, że jeśli po wprowadzeniu danych otrzymamy błąd Selector Not Found może to prowadzić do wniosku, że aplikacja webowa po prostu jeszcze procesuje i powinniśmy poczekać kolejne 30 sekund, podczas gdy inne błędy powinny spowodować przerwanie pracy nad daną transakcją i pobranie kolejnego zadania z kolejki. Framework XELTO DIGITAL Niestety, jakkolwiek długa analiza nie jest w stanie przygotować robota na wszystkie ewentualności. W związku z tym struktura naszego robota powinna przewidywać przypadki wystąpienia błędu nieznanego, który zostanie obsłużony w sposób domyślny, czyli np. przez wylogowanie się z aplikacji, zamknięcie przeglądarki i uruchomienie pracy ponownie z kolejnym zleceniem. W jednym z wcześniejszych wpisów pisaliśmy o naszym framework’u, który wykorzystywany jest we wszystkich naszych automatyzacjach. Jednym z jego kluczowych elementów jest właśnie domyślna obsługa błędów, która umożliwia kontynuowanie pracy nawet w przypadku pojawienia się sytuacji nieprzewidzianej. Jednolity system nazewnictwa błędów Ostatnim bardzo ważnym aspektem zarządzania błędami jest przekazywanie informacji. W zależności od sytuacji może okazać się, że dany problem jest tymczasowy lub wymaga interwencji ze strony użytkownika bądź programisty. W naszym framework’u zaimplementowaliśmy rozróżnienie na błędy biznesowe, których rozwiązanie delegowane jest na pracowników oraz systemowe, o których informowany jest zespół opieki nad robotami. Co ważne, wprowadziliśmy jednolity system nazewnictwa błędów, co jest nieocenione przy dużej liczbie pracujących automatów i pomaga szybko identyfikować błędy. Tym samym nie jest istotne, w którym robocie pojawi się błąd – ale ważne, że jego oznaczenie zawsze będzie takie samo. Najważniejsze i najtrudniejsze Podsumowując, zarządzanie błędami jest to jeden z najtrudniejszych, a zarazem najważniejszych etapów przygotowywania automatyzacji, która sama w sobie powinna być wielowarstwowa: poczynając od weryfikacji danych wejściowych, bieżącego sprawdzania niezbędnych połączeń poprzez monitorowanie wąskich gardeł i kończąc na scenariuszu bliżej nieokreślonego błędu. Autor: Rafał Korporowicz – Senior RPA Developer
