Automatisierungs-Lifecycle

Entwerfen Sie Automatisierungsprojekte in Studio, indem Sie zwischen Attended- und Unattended-Robotermodellen wählen und Workflows entsprechend strukturieren.

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.

Mixed processes

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.

ROI and efficiency

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.

Runtime Guide

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

After each component is built, unit testing should be conducted. If every component is thoroughly tested, the integration runs more smoothly, and debugging lasts for a shorter period of time.

The REFramework contains a Test_Framework folder where all the test files should be placed. Using the RunAllTests.xaml file, a developer can test a sequence containing a lot of .xaml files automatically, thus being able to try out small integrations between components and to run stress tests. A report is generated at the end of each test. Typically, these kinds of tests should be executed outside of office hours, in testing environments, to optimize the developer’s time.

Testumgebungen

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.

Test mode

Use the UiPath.config file or Orchestrator assets to switch flags or settings for the current environment.

A test mode parameter (Boolean) could be checked before interacting with live applications. This could be received as an asset (or argument) input.

Test mode behavior

When it is set to True, during debug and integration testing, it follows the test route, does not execute the case fully. For example, the test patch can skip sending notifications, skips the OK or Save button or press the Cancel or Close button instead. When set to False, the normal Production mode route is followed.

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.

Bereitstellungsmodell

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.