Roboti, stejně jako my, ne vždy dávají pozor na naše okolí. Rozdíl mezi nimi a námi je v tom, že robot musí předvídat všechna potenciální selhání a musí být připraven (samozřejmě s pomocí vývojáře) na nadcházející komplikace. Kdysi jsem se naučil, že správa chyb je klíčovým faktorem automatizačního projektu z cca 80%. S tím plně souhlasím. Kromě toho, když chybí část pro zpracování chyb, pak já – robot, nemusím fungovat tak, jak je po mě vyžadováno. Rozhodujícími body jsou interakce s lidmi. Když nejsou vstupní data extrahována nebo stažena z aplikací, ale jsou dodána člověkem, což znamená, že tento vstup je připraven ručně, pak existuje vysoké riziko, že robot obdrží chybná data nebo data související se scénářem, který není zpracován. V takovém případě je třeba zavést preventivní opatření.
Poka Yoke
Z metodologie Lean Six Sigma pochází přístup zvaný Poka-Yake (v japonštině: odolný proti chybám). Zabraňuje funkčnosti nesprávným používáním daných nástrojů. Například, když má být robot spuštěn pomocí e-mailu zaslaného operátorem, je připraven list aplikace Excel jako šablona pro uživatele, která poskytne vstupní data. Na základě kontrolního souboru XLSX robot zpracuje validaci dat a poté provede plánované kroky. Řešení lze navrhnout na základě jazyka Visual Basic nebo procedur ověřování dat. Uživatel tak získá účinný nástroj, který mu zjednoduší práci a zároveň zabrání robotovi v páchání chyb. Přirozeně to má tendenci vést k situaci, kdy chybné příkazy robot vůbec nedostane. Není-li na straně operátora možné předběžné ověření údajů.
Prostředí aplikace a práce robota
Dalším zdrojem chyb je chybějící kontrola nad prostředím, ve kterém robot pracuje. Například není znám stav robotické stanice:
- Zanechal za sebou proces, který dříve běžel, nepořádek?
- Byly pro spuštění nutné aplikace?
- Jsou licence dostupné pro každou z používaných aplikací?
- Jsou zdroje RAM dostatečné?
Lze se setkat s chybami při startu procesu i během jeho průběhu. Aby se proces správně rozběhl, musí mít robot možnost připravit si pracovní prostředí, tedy uzavřít všechny nepotřebné aplikace běžící jak v procesu robota, tak v dalších procesech spuštěných pro stroj, na kterém robot pracuje. Když necháme na počítači paralelně běžet několik relací, je důležité zavřít aplikace z příslušné relace. Možnost ukončit, bohužel, nerozlišuje mezi aplikací, kterou jsme právě spustili, a aplikací spuštěnou jiným uživatelem, takže musíme dávat pozor, aby robot nezavřel funkce věnované jiným procesům, než je ten náš.
Připravení na každý scénář
I když víme, jak daný program dobře funguje, neznamená to, že tento program funguje identicky na straně klienta. Nejprve musíte celý proces probrat s obchodním analytikem, abyste rozpoznali a pojmenovali kritické body, u kterých v případě manuálních operací existuje riziko selhání. S jejich znalostmi může dobrý vývojář definovat kroky procesu, které vyžadují zvláštní pozornost. Naštěstí existuje mnoho různých nástrojů pro správu takových scénářů, které lze mnoha způsoby kombinovat. Například pro strukturu „Try-catch“ můžeme vybrat více než jeden akční scénář v závislosti na typu vrácené chyby, abychom nechali některé z nich zpracovat ještě jednou. Takže chyba typu „Selector not found“ může vést k závěru, že webová aplikace ještě nezačala zpracovávat. Poté musíme počkat dalších 30 sekund. Zatímco ostatní chyby ukončí práci na transakci a robot sáhne po dalším úkolu z fronty.
XELTO DIGITAL rámec
Jakákoli dlouhotrvající analýza zaručuje, že robot je dobře připraven na jakýkoli scénář. Proto je velmi důležité postavit takovou strukturu robota, která dokáže předvídat různé druhy dosud neznámých chyb, které budou standardně zpracovávány. Tímto výchozím způsobem může být odhlášení z provozu aplikace, zavření prohlížeče a restart procesu. Již jsme se zmínili o našem frameworku – klikněte pro vyvolání – který se používá v každé automatizaci, kterou dodáváme. Jedním z jeho klíčových faktorů je toto výchozí zpracování chyb. Díky těmto zařízením lze v práci pokračovat, i když nastane nepředvídatelný scénář.
Standardizovaná nomenklatura chyb
V neposlední řadě je problémem při zpracování chyb komunikace. V závislosti na daném scénáři může být problém dočasný nebo může vyžadovat prošetření operátora nebo vývojáře. Xelto Digital Framework má vestavěný mechanismus pro rozlišení mezi systémovými chybami a obchodními chybami. Obchodní chyby jsou odesílány uživatelům pracujícím s robotem, zatímco systémové chyby jsou záležitostí opravných akcí poskytovatele. Pojmenování chyb je velmi důležitým prvkem zavedeným do Frameworku a pomáhá organizovat zpracování chyb v procesech, do kterých je zapojeno několik robotů. Tímto způsobem není důležité, u kterého robota je konkrétní chyba nalezena – důležitý je význam chyby a způsob řešení, které jsou pro všechny roboty stejné.
Nejdůležitější a nejtěžší
Sečteno a podtrženo, zpracování chyb je jedním z nejobtížnějších a nejzásadnějších kroků v návrhu automatizace. Automatizace musí být vícevrstvá, počínaje validací vstupních dat a online kontrolou připojení, přes monitorování rizikových míst až po zpracování nepředvídatelných scénářů.
