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.

When Attended Robots Make Sense

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.

Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

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.

Benefits and Practical Considerations

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.

However, several factors affect this decision:

• Attended Robots typically run only during working hours
• Attended Robots keep machines and users busy until execution completes
• Input types and transaction volumes
• Time restrictions and scheduling
• Number of available Robots

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.

The Runtime Guide should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

The Development Details should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

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, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the REFramework’s Test_Framework folder for test files. The RunAllTests.xaml file enables automated testing of multiple .xaml files. Run tests outside office hours in testing environments to optimize developer time.

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.

Use the UiPath.config file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When True, the automation follows test routes and doesn't execute fully. For example, skip notifications and use Cancel instead of Save. When False, follow normal production routes.

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

Use Log Message activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

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.