Automatisierungs-Lifecycle

Prozessverständnis

Die Entscheidung zwischen einer Automatisierung für beaufsichtigte Roboter und unbeaufsichtigte Roboter ist die erste wichtige Entscheidung, die sich auf die Art und Weise auswirkt, wie Entwickler den Code erstellen, da das allgemeine Laufwerk (Roboterauslösung, Interaktion, Ausnahmeverarbeitung) unterschiedlich ist. Ein späterer Wechsel auf den anderen Robotertyp kann umständlich sein.

Für zeitkritische, lebendige, menschlich ausgelöste Prozesse, wie in einem Call Center, könnte ein beaufsichtigter Roboter. der Seite an Seite mit einem Menschen arbeitet, die einzig mögliche Antwort sein.

Aber nicht alle Prozesse, die menschlichen Input benötigen, sollen mit beaufsichtigten Robotern laufen. Wenn eine rein beurteilende Entscheidung (nicht regelbasiert) während des Prozesses nicht vermieden werden konnte, bewerten Sie, ob eine Änderung des Flusses möglich ist, wie z. B. die Aufteilung des größeren Prozesses in zwei kleinere Teilprozesse, wenn die Ausgabe des ersten Teilprozesses zum Input für den zweiten wird. Obwohl dazwischen menschliche Eingriffe stattfinden, wie z. B. die Validierung/Änderung der Ausgabe des ersten Teilprozesses, könnten beide Teilprozesse automatisch ausgelöst und unbeaufsichtigt laufen.

Ein typischer Fall wäre ein Prozess, der irgendwo während des Prozesses einen manuellen Schritt erfordert, wie z.B. das Überprüfen des unstrukturierten Kommentarabschnitts eines Tickets und darauf aufbauend die Zuordnung des Tickets zu bestimmten Kategorien.

Im Allgemeinen gewährleistet die Verwendung eines unbeaufsichtigten Roboters eine effizientere Nutzung der Roboterlast und einen höheren ROI, eine bessere Verwaltung und Verfolgung der Roboterkapazitäten.

Diese Berechnungen sollten jedoch verschiedene Aspekte berücksichtigen, wie z. B. die Tatsache, dass ein beaufsichtigter Roboter in der Regel nur in den normalen Arbeitszeiten einer Person laufen kann oder dass er die Maschine und den Benutzer bis zum Ende der Ausführung beschäftigt halten kann. Eingabetypen, Transaktionsvolumen, Zeitbeschränkungen, die Anzahl der verfügbaren Roboter und andere spielen ebenfalls eine Rolle bei dieser Entscheidung.

Dokumentieren des Prozesses – DSD

Die Prozessdokumentation leitet die Arbeit des Entwicklers und bietet Hilfe bei der Verfolgung der Anfragen und der Anwendungspflege. Natürlich gibt es noch viele andere technische Dokumente, aber eines ist entscheidend für eine reibungslose Umsetzung, nämlich das DSD (Development Specification Document).

Das Entwicklungsspezifikationsdokument sollte die Details des automatisierten Prozesses enthalten und sich auf zwei Hauptkategorien konzentrieren: Laufzeithandbuch und Entwicklungsdetails.

Das Laufzeithandbuch sollte ein High-Level-Laufzeitdiagramm sowie Details über die Funktionalität des Roboters enthalten, wie z. B. Subprozesse, Zeitpläne, Konfigurationseinstellungen, Eingabedateien, Ausgabedateien, temporäre Dateien und ausgeführte Aktionen. Zusätzliche Details über den Master-Prozess sollten spezifiziert werden, wie z. B. Voraussetzungen, automatische und manuelle Fehlerbehandlung, Fortsetzung des Prozesses im Fehlerfall, Nutzung des Orchestrators, Protokollierung und Berichterstellung, Berechtigungsverwaltung und alle anderen relevanten Informationen im Zusammenhang mit Sicherheit oder Funktion.

Die Entwicklungsdetails sollten Informationen über die verwendeten Pakete, die Entwicklungsumgebung, die Protokollierungsebene, das Quellcode-Repository und die Versionierung, eine Liste der Workflow-Komponenten mit ihrer Beschreibung und Argumentliste, eine Liste der wiederverwendbaren Komponenten, den Workflow-Aufrufbaum, definierte benutzerdefinierte Protokolle und Protokollfelder, relevante Snapshots des Prozess-Flowchart, den Grad der Hintergrund- und Vordergrundautomatisierung und alle anderen relevanten oder offenen Entwicklungselemente enthalten.

Entwicklung und Codeprüfung

Der RPA Solution Architect ist dafür verantwortlich, die Entwickler kontinuierlich über die besten Praktiken zu informieren. Daher sind regelmäßige und gründliche Codeprüfungen ein Muss, um eine sehr hohe Qualität der entwickelten Workflows zu gewährleisten. Auf diese Weise werden die Entwickler motiviert, robuste Workflows zu erstellen und dem Best Practice Guide zu folgen.

Test

Nachdem jede Komponente gebaut wurde, sollte ein Einheiten-Test durchgeführt werden. Wenn jede Komponente gründlich getestet wird, läuft die Integration reibungsloser, und das Debugging wird kürzer. Das REFramework enthält einen Ordner Test_Framework, in dem alle Testdateien abgelegt werden sollen. Mit Hilfe der Datei RunAllTests.xaml kann ein Entwickler eine Sequence mit vielen .xaml-Dateien automatisch testen und so kleine Integrationen zwischen Komponenten ausprobieren und Stresstests durchführen. Am Ende jedes Texts wird ein Bericht erzeugt. Normalerweise sollten diese Art von Tests außerhalb der Bürozeiten, in Testumgebungen, durchgeführt werden, um die Zeit des Entwicklers zu optimieren.

The recommended UiPath^® architecture includes Dev and Test environments that allow the processes to be tested outside the live production systems.

Manchmal sehen Anwendungen zwischen den Entwicklungs-, Test- oder Produktionsumgebungen unterschiedlich aus oder verhalten sich unterschiedlich, und es müssen zusätzliche Maßnahmen ergriffen werden, um Selektoren zu bereinigen oder sogar bestimmte Aktivitäten bedingt auszuführen.

Verwenden Sie die Datei UiPath.config oder Orchestrator-Assets, um Flags oder Einstellungen für die aktuelle Umgebung zu wechseln. Ein Testmodusparameter (Boolean) kann vor der Interaktion mit Live-Anwendungen überprüft werden. Dies könnte als Asset-(oder Argument-)Input empfangen werden. Wenn es auf True gesetzt ist, folgt es beim Debuggen und Integrationstesten dem Testweg und führt den Fall nicht vollständig aus. So kann beispielsweise der Testpatch das Senden von Benachrichtigungen überspringen, die Schaltfläche OK oder Speichern überspringen oder stattdessen die Schaltfläche Abbrechen oder Schließen drücken. Wenn auf False gesetzt, wird der normale Produktionsmodus-Route gefolgt.

Auf diese Weise können Sie Modifikationen vornehmen und in Prozessen testen, die direkt in Produktivsystemen arbeiten.

Freigabe

Es gibt verschiedene Möglichkeiten, die Architektur und den Release-Fluss zu entwerfen, unter Berücksichtigung des Infrastrukturaufbaus, Bedenken bezüglich der Trennung von Rollen usw.

In diesem vorgeschlagenen Modell können UiPath-Entwickler ihre Projekte erstellen und auf Entwicklungsumgebungen in Orchestrator testen. Sie dürfen das Projekt auf einem Laufwerk einchecken, das von einem Versionskontrollsystem (VCS) wie GIT, SVN oder TFS verwaltet wird.

Die Veröffentlichung des Pakets und die Bereitstellung für Test- und Produktionsumgebungen ist die Arbeit eines anderen Teams, wie beispielsweise der IT.

Die Bereitstellungspfade auf Orchestrator wurden von ihrer Standardeinstellung in Ordner geändert, die vom VCS verwaltet werden, indem der Wert Storage.Location in der UiPath.Orchestrator.dll.config-Datei im Abschnitt Bereitstellung geändert wurde.

Das Modell enthält auch ein Repository von wiederverwendbaren Komponenten.

Hier ist der Ablauf der Projektveröffentlichung, Schritt für Schritt:

1. Entwickler erstellen den Prozess und testen und debuggen ihn lokal (Studio).
2. Nachdem die Automatisierungsentwicklung abgeschlossen ist, wird der Prozess zum Development-Orchestrator veröffentlicht und erneut durchgängig getestet.
3. Danach checken sie den Projektordner (nicht verpackt) in einem Master-Bibliotheksordner (auf VCS) ein.
4. Das IT/RPA-Betriebsteam erstellt das Paket für die Qualitätssicherung. Dieser Schritt ist als zusätzliche Sicherheitsmaßnahme gedacht: der Automatisierungsquellcode wird vor der Paketerstellung überprüft (von einer anderen Entität) und von Robotern ausgeführt. Beispielsweise wird der verpackte Prozess im Ordner Process Pckgs (QA) auf VCS gespeichert und vor dort aus an die QA-Roboter bereitgestellt und ausgeführt.
5. Wenn während der Tests ein Problem auftritt, werden die obigen Schritte wiederholt.
6. Nachdem alle QA-Tests bestanden sind, wird das Paket in eine Produktionsumgebung – Process Pckgs (Prod) weitergeleitet.
7. Wenn der Prozess in Betrieb geht, wird das Prozesspaket an die Produktionsroboter bereitgestellt und ausgeführt.

Wiederverwendbare Inhalte werden separat erstellt und bereitgestellt, als UiPath-Code (Reusable Code Library) und Invokes (Invokes-Repository).

Workflows mit Quellcode sind .xaml-Dateien mit Aktivitäten zur Automatisierung gängiger Prozesse, wie z. B. Log in to SAP:

Invokes repräsentieren Workflows, die nur aus einer Invoke-Aktivität der oben genannten Code-Workflows bestehen.

Das Snippet-Panel eines Studioentwicklers sollte auf dieses Aufrufen- (Invoke) Repository verweisen, um den einfachen Zugriff (Drag & Drop) auf wiederverwendbaren Inhalt (Reusable Content) zu ermöglichen.

Die lokale Designbehörde, die für die Pflege der des wiederverwendbaren Inhalts (Reusable Content) zuständig ist, aktualisiert die Workflows mit Code (z. B. durch eine Änderung des Prozesses). Die Invokes bleiben unverändert.

Der Vorteil dieses Ansatzes (im Gegensatz zur direkten Arbeit mit der Quellcodebibliothek) besteht darin, dass bei einer Änderung an einer wiederverwendbaren Komponente alle laufenden Projekte diese Änderung ebenfalls widerspiegeln, da sie nur einen Invoke des geänderten Workflows enthalten.

Überwachung

Die Verwendung von Protokollnachricht-Aktivitäten zur Verfolgung der Entwicklung eines laufenden Prozesses ist für die Überwachung, Diagnose und Fehlersuche eines Prozesses unerlässlich. Die Nachrichten sollten alle relevanten Informationen enthalten, um eine Situation genau zu identifizieren, einschließlich der Transaktions-ID und des Status.

Eine Protokollierung sollte in folgenden Fällen verwendet werden:

• Zu Beginn und Ende eines jedenWorkflow;
• Wenn Daten aus externen Quellen eingehen;
• Jedes Mal, wenn eine Ausnahme auf der höchsten Ebene abgefangen wird.

Nachrichten werden mit der angegebenen Priorität (z. B. Info, Trace, Warnung) an Orchestrator gesendet und ebenfalls in der lokalen Datei .nlog gespeichert.

Benutzerdefinierte Protokollfelder

Um Daten in Kibana für Berichtszwecke leicht zugänglich zu machen, kann der Roboter Protokollmeldungen mit zusätzlichen Werten über die Aktivität Protokollfelder hinzufügen (Add Log Fields) versehen. Standardmäßig hat jede UiPath-Protokollausgabe bereits mehrere Felder, darunter message, timestamp, level, processName, fileName und die Windows-Identität des Roboters. Protokollfelder sind persistent, wenn wir also nicht alle Nachrichten mit einem Tag markieren müssen, sollten Felder sofort nach der Protokollierung mit der Aktivität Protokollfelder entfernen (Remove Log Fields) entfernt werden. Verwenden Sie keinen bereits vorhandenen Feldnamen. Es ist wichtig, beim ersten Hinzufügen des Feldes die richtige Art des Arguments anzugeben. So indiziert Elasticsearch sie.