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.

Wann Attended-Roboter sinnvoll sind

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.

Überprüfung von Attended-Robotern

Nicht alle Prozesse, die menschliche Eingaben erfordern, müssen Attended-Roboter verwenden. Wenn eine objektive Entscheidung unausweichlich ist, sollten Sie den Prozess in kleinere Teilprozesse aufteilen, die unbeaufsichtigt ausgeführt werden können.

Zum Beispiel könnte ein Teilprozess Daten sammeln und nach der Validierung durch Menschen wird ein zweiter Teilprozess automatisch fortgesetzt.

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.

Vorteile und praktische Überlegungen

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.

Mehrere Faktoren beeinflussen jedoch diese Entscheidung:

• Attended-Roboter werden in der Regel nur während der Arbeitszeiten ausgeführt
• Attended-Roboter halten Maschinen und Benutzer beschäftigt, bis die Ausführung abgeschlossen ist
• Eingabetypen und Transaktionsvolumen
• Zeitbeschränkungen und Planung
• Anzahl der verfügbaren Roboter

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.

Der Runtime-Leitfaden sollte ein übergeordnetes Runtime-Diagramm und Details zur Roboterfunktionalität enthalten, einschließlich Teilprozessen, Zeitplänen, Konfigurationseinstellungen und Dateiverwaltung.

Geben Sie Details zu den Voraussetzungen, der Fehlerbehandlung, der Wiederaufnahme des Prozesses, der Orchestrator-Nutzung, der Protokollierung, der Berichterstellung und der Verwaltung von Credential an.

Die Entwicklungsdetails sollten Pakete, Entwicklungsumgebung, Protokollierungsebenen, Source Control-Informationen und Workflow-Komponenten mit Beschreibungen enthalten.

Dazu gehören auch wiederverwendbare Komponenten, Aufrufstrukturen, benutzerdefinierte Protokolle, Flowchart-Snapshots, Automatisierungsstufen und andere Entwicklungsdetails.

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, führen Sie einen Einheiten-Test durch. Gründliche Komponententests sorgen für eine reibungslosere Integration und ein schnelleres Debugging.

Verwenden Sie den Ordner Test_Frameworkvon REFramework für Testdateien. Die Datei RunAllTests.xaml ermöglicht das automatisierte Testen mehrerer .xaml -Dateien. Führen Sie Tests außerhalb der Bürozeiten in Testumgebungen durch, um die Entwicklerzeit zu optimieren.

Die empfohlene UiPath-Architektur umfasst Entwicklungs- und Testumgebungen, die es ermöglichen, die Prozesse außerhalb der Live-Produktionssysteme zu testen.

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 UiPath.config -Datei oder Orchestrator-Assets, um umgebungsspezifische Flags zu wechseln. Definieren Sie einen booleschen Parameter für den Testmodus, um das Verhalten während des Debuggens zu steuern.

Bei True folgt die Automatisierung den Testpfaden und wird nicht vollständig ausgeführt. Überspringen Sie beispielsweise Benachrichtigungen und verwenden Sie Cancel anstelle von Save. Bei „False“ folgen Sie den normalen Produktionspfaden.

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

Verwenden Sie Log Message- Aktivitäten, um die Prozessausführung für die Überwachung, Diagnose und Fehlersuche nachzuverfolgen. Nachrichten sollten Transaktions-IDs und Statusinformationen für eine genaue Identifizierung enthalten.

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.