Amint több, éjt nappallá tevő, dolgozó robotunk lesz, a robotoknak is szükségük lesz valamilyen szintű karbantartásra, mint minden más szoftvernél. Például, ha egy orchestrator ’job’ elhal egy rendszerhiba miatt, a fejlesztőnek szükséges megvizsgálnia a hiba okát, mivel egy ilyen leállás azt is jelentheti, hogy a robotban van egy javítandó hiba.

Hasonlóan, ha egy ’queueitem’ bármelyik ’queue’-ban ’abandoned’ állapotba kerül,  ez is indikálhat egy problémát magával a kóddal is, de akár egy infrastrukturális problémát is: ha csurig van töltve az Orchestrator alatti adatbázis, néhány Orchestrator folyamat időtúllépési hiba miatt nem lesz képes lefutni. Megtörténhet az is (ahogyan már pár ügyfelünknél ez elő is fordult), hogy az Orchestrator-ban a ’Set Transaction’ studio-s tevékenységgel elindított folyamat az adatbázisban időtúllépési hibára fut.

Mindig hasznos karbantartani és archiválni a már nem használt adatokat az Orchestrator alatti adatbázisból legalább 90 naponta, mert ezzel tudjuk biztosítani az Orchestrator stabilitását.

A robotokat is, mint más szoftvereket teljeskörűen szükséges tesztelni élesbe állás előtt, ám sokszor nem megvalósítható a folyamat minden zegzugának tesztelése, kiváltképpen a hibakezelés, ezért előfordulhat, hogy néhány probléma az éles környezetben bukkan csak elő – potenciálisan hónapokkal az élesítés után.

Általában az üzleti oldal vagy az operáció az a terület, aki azzal a feladattal van megbízva, hogy az ilyen hibákat, ha észreveszik, jelentsék az infra vagy a fejlesztői csapatnak valamilyen jegykezelő rendszeren keresztül. Mivel ez egy manuális és nem túl hatékony munkafolyamat, ezért ez késéseket okozhat ahhoz képest amilyen gyorsasággal szeretnénk, hogy az ilyen problémák megoldásra találjanak.   

Itt lépnek színpadra a Webhook-ok. A Webhook-ok nagyjából olyanok, mint a körlevelek, amiket az Orchestrator küld a megadott végpontra, de gondolhatunk rájuk figyelmeztető üzenetként is.

Amennyiben egy esemény történik az Orchestratorban, egy API hívás kerül kiküldésre a bekonfigurált végpontra. Amennyiben ennek a végpontnak a másik oldalán egy jegykezelő rendszer áll, akkor potenciálisan automatizálható a jegyek generálása a fent említett problémákra, ezzel eltávolítva a manuális és nem hatékony részét a jegykezelési munkafolyamatnak.

Az Orchestrator API végpontok lehetővé teszik a könnyebb integrációt különböző rendszerekkel workflow-k vagy microservice jellegű megoldások segítségével.

Amennyiben egy folyamatot egy workflow-nak szükséges indítania, a workflow potenciálisan elküldheti a robotfolyamat input adatait az /odata/Queues/UiPathODataSvc végpontra, amivel közvetlenül tudja létrehozni a ’queue’-ban található munkaelemeket. Amennyiben az orchestrator-ban beütemezett munkafolyamathoz tartozik egy queue és a folyamatot magát egy ’queuetrigger’ indítja, akkor az Orchestator allokálni fog egy robotot, amint az elérhetővé válik, hogy kezelje a queue-ban elhelyezett feladatot, így indíthatunk egy robotfolyamatot akár egy workflow részeként is.

Hasonlóan, amennyiben vállalati szinten szükséges a folyamatok leállítása egy bizonyos időperiódusra (például egy élesítés miatt), úgy a munkaütemezések is módosíthatóak közvetlenül az Orchestrator API-kon keresztül. Még ütemezési naptárakat is lehet módosítani, az /odata/Calendars({key}) végponttal, ami meghatározza, hogy az adott folyamat futni fog-e egy adott időpontban (vállalaton belüli speciális munkanapok, élesítési időpontok, vagy áthelyezett munkanapok kezelésében lehet például ez hasznos.)

Megvitattuk, hogy hogyan alkalmazhatók a Webhook-ok és hogyan integrálódjunk egy jegykezelő rendszerrel. Majd megvitattuk, hogy hogyan lehet könnyedén integrálódni egy workflow megoldásba. Ahogy láthattuk ezek a funkcionalitások csak eszközök, amiket kreatívan használhatunk, hogy elősegítsük az integrációt más rendszerekkel a vállalaton belül. Gyakran az RPA megoldások használói sem biztosak benne, hogy hogyan lehetne integrálni az Orchestrator-t vagy a robotfolyamataikat más IT megoldásokkal. Számukra a legjobb dolog, amit ajánlani tudok, amit egy enterprise architect már tökéletesen megfogalmazott: „Ha már megvan nekünk az eszköz, akkor használjuk azt! Nemde?”