W tym tygodniu chciałbym Wam się do czego przyznać. Kiedy zadzwoniłem do Rafała, żeby omówić zagadnienia dotyczące Framwork`a zdałem sobie sprawę, że praca z całym zespołem XELTO DIGITAL to czysta przyjemność. Każdy w naszym zespole odpowiada za konkretne automatyzacje procesów, ale kiedy ktoś z Nas boryka się z zagadnieniem, którego nie może „rozgryźć” nie zostaje z tematem sam. Dzięki temu wsparciu, wspólnym rozmowom i „burzom mózgów” powstał właśnie wzór budowy robotów. Ale zanim o tym wszystkim z Rafałem opowiemy, muszę w tym miejscu podziękować moim Koleżankom i Kolegom za tą współpracę.
Okiem Eksperta:
UiPath promuje tworzenie rozwiązań w oparciu o tak zwany 'Robotic Enterprise Framework’, który gwarantuje podstawową implementację najważniejszych koncepcji wspierających tworzenie automatyzacji. Razem z zespołem XELTO DIGITAL poszliśmy o krok dalej i stworzyliśmy rozbudowaną wersję frameworke’a, który stanowi podstawę budowanych przez nas robotów.
Co nam to daje?
1.Standaryzacja
Dla każdego klienta wszystkie procesy zbudowane są dokładnie w taki sam sposób. Pozwoliło nam to zaimplementować wiele wspólnych mechanizmów już na etapie projektowania wzorów. Otwierając nowy projekt programista nie musi się już martwić o logowanie, główną obsługę błędów czy też przygotowanie środowiska. Dla przykładu: wykorzystując procedurę TypeIntoElement programista jednym klockiem zaloguje czy element istnieje, wpisze do niego wartość wybraną przez siebie metodą, sprawdzi czy wprowadzona wartość jest poprawna i jeśli coś nie zadziała, to powtórzy to X razy. Ponadto, zarówno logi, jak i komunikaty błędów mają jednolity format i dostarczają nam kluczowych informacji.
2. Bezpieczeństwo
Dzięki wbudowanym mechanizmom każdy z procesów potrafi dokonać podstawowego przygotowania maszyny do pracy, jak i pozostawić po sobie środowisko gotowe na kolejnego robota. Ponadto, co by się nie wydarzyło, robot jest w stanie z gracją zamknąć wszystkie otwarte aplikacje i pozostawić stację w takim samym stanie, w jakim ją zastał. Jeżeli robot pracuje na Windows serwerze to wie, żeby zamykać procesy jedynie dla konkretnej sesji użytkownika, pozwalając na bezpieczną pracę wielu robotów jednocześnie.
3.Przyspieszona produkcja
Przygotowanie wzoru dla nowego projektu zajmuje ok. 30 minut. W tym czasie programista otrzymuje pakiet kompleksowych rozwiązań, których jednorazowe projektowanie, budowanie i testowanie zajmowałoby co najmniej kilka dni. Z kolei wykorzystanie reużywalnych komponentów pozwala na szybką budowę akcji procesowych. Piszę tu zarówno o uniwersalnych procedurach obecnych we framework’u, jak i tych przygotowanych pod konkretne aplikacje, które są dostępne w zbudowanych przez nas bibliotekach pomocniczych. Dla przykładu, wspomniany już TypeIntoElement oraz ClickElement będą działać na każdej aplikacji webowej, natomiast NavigateFastPathJDE jest procedurą zbudowaną stricte pod obsługę szybkiej ścieżki w JDE.
4.Lepsze SLA wsparcia technicznego
Standaryzacja procesu tworzenia robota pozwala na poprawę czasu diagnostyki w przypadku wystąpienia błędów w pracy procesu. Są tego dwa powody: po pierwsze, konkretne błędy mogą wystąpić jedynie w konkretnych miejscach. Jeśli nie działa połączenie ODBC to od razu wiemy, że problemu należy szukać w obszarze 'get transactions data’. Dzięki temu czas potrzebny na samo szukanie miejsca problemu zostaje znacząco skrócony. Po drugie, wprowadziliśmy jednolite kody błędów dla wszystkich robotów oraz podzieliliśmy je między te, za które odpowiedzialny jest biznes, jak i te, które występują po stronie używanych aplikacji. Gdy podczas monitoringu pracy robotów pojawi nam się komunikat, np. B0001, to od razu dla nas jest jasne, że nie udało się robotowi zalogować do aplikacji, ponieważ hasło wygasło.
Podsumowując, wdrożenie własnego wzoru budowy robotów spowodowało, że nowe procesy budowane są szybciej, bezpieczniej i pozwalają łatwo wpasowywać je do już istniejącej infrastruktury robotycznej u dowolnego klienta.
Autor: Rafał Korporowicz – Senior RPA Developer
Foto: iStock