Projektorganisation

High-Level Frameworks

Wenn Sie von einem generischen (und prozess-agnostischen) Framework aus starten, stellen Sie sicher, dass jeder Prozess konsistent und strukturiert abgewickelt wird. Ein Framework hilft Ihnen dabei mit einer Ansicht aus höchster Ebene zu starten, und dann gehen Sie tiefer auf die spezifischen Details jedes Prozesses ein.

Die Robotic Enterprise Framework-Vorlage schlägt eine Übersicht auf hoher Ebene über einen wiederholbaren Prozess vor sowie einen guten Satz Praktiken, die in diesem Handbuch beschrieben werden. Sie kann einfach als solider Startpunkt für die RPA-Entwicklung mit UiPatch verwendet werden. Die Vorlage baut auf einer State Machine-Struktur auf.

Wie es funktioniert:

• Der Roboter lädt die Einstellungen von der Konfigurationsdatei und den Orchestrator-Assets, und speichert sie in einem Lexikon, das über Workflows hinweg geteilt wird.
• Der Roiter ruft die erforderlichen Anmeldedaten und Protokolle in alle Anwendungen ab.
• Falls Fehler auftreten, versucht er es noch ein paarmal, bis er entweder erfolgreich ist oder abbricht.
• Der Roboter prüft die Eingabewarteschlange oder andere Eingabequellen, um eine neue Transaktion zu starten.
• Wenn keine Eingabedaten (mehr) verfügbar sind, wird der Workflow entweder auf Warten und erneut versuchen oder auf das Beenden des Prozesses konfiguriert.
• Die UI-Interkationen zum Verarbeiten der Transaktionsdaten werden ausgeführt.
• Wenn die Transaktionen erfolgreich verarbeitet wurden, wird der Transaktionsstatus aktualisiert und der Robooter fährt mit der nächsten Transaktion fort.
• Wenn Validierungsfehler auftreten, wird der Transaktionsstatus aktualisiert und der Roboter fährt mit der nächsten Transaktion fort.
• Wenn Ausnahmen auftreten, versucht der Roboter entweder, die Transaktion ein paarmal erneut zu verarbeiten (falls dies konfiguriert wurde) oder das Element wird als fehlerhaft markiert und der Roboter startet erneut.

• Am Ende wird eine E-Mail mit dem Status des Prozesses gesendet, falls dies konfiguriert wurde.

  
  

  

  
  

Für transaktionsbasierte Prozesse (wie beispielsweise die Verarbeitung aller Rechnungen von einer Excel-Datei), die nicht über Orchestrator ausgeführt werden, können lokale Warteschlangen erstellt werden (mithilfe der .NET-Methode zum Einfügen/Entfernen von Warteschlangen).

Danach kann der Fluss des Prozesses höchster Ebene (Ausnahmeverarbeitung, Neuversuch, Wiederherstellung) einfach repliziert werden – leichter als durch die Gruppierung des gesamten Prozesses in einer Für jede Zeile-Schleife.

Alle REFrameWork-Dateien finden Sie zusammen mit ihrer Dokumentation auf dieser Seite.

Designprinzipien

Die Aufteilung von Projekten in kleinere Workflows und die Verwendung von Invoke Workflow File-Aktivitäten steht für ein gutes Projektdesign an oberster Stelle. Dedizierte Workflows ermöglichen das unabhängige Testen von Komponenten, fördern die Zusammenarbeit im Team und verbessern die Design- und Ausführungsleistung im Vergleich zu Projekten, die in weniger, größeren Dateien organisiert sind. Es wird empfohlen, die Größe der Workflow-Dateien unter 5 MB zu halten. Workflow-Dateien über 10 MB werden nicht unterstützt.

Wählen Sie den Layouttyp vernünftig aus (Flowcharts und Sequences). Normalerweise verbleibt die Logik des Prozesses in den Flowcharts, während sich die Navigation und die Datenverarbeitung in den Sequences befindet.

Durch die Entwicklung komplexer Logik innerhalb einer Sequence werden Sie mit einem Labyrinth von Containern und Entscheidungsblöcken enden, die sehr schwierig nachzuverfolgen und zu aktualisieren sind.

Im Gegensatz dazu machen es UI-Interaktionen in einem Flowchart schwieriger zu erstellen und zu pflegen.

Projektbezogene Dateien (wie E-Mail-Vorlagen) können in lokalen Ordnern oder auf freigegebenen Laufwerken organisiert werden.

Hinweis: Wenn sie innerhalb des Projektordners gespeichert werden, werden sie während des Bereitstellungsprozesses repliziert (zusammen mit den Projektworkflows) und zwar auf allen Robotermaschinen im Ordner lib/net45.

Diese Ordner könnten also auf einem freigegebenen Laufwerk gespeichert werden, damit alle Roboter sich mit der gleichen eindeutigen Quelle verbinden. Auf diese Art und Weise können die prozessbezogenen Dateien komplett von den Geschäftsbenutzern überprüft und gepflegt werden, ohne Unterstützung durch das RPA-Team. Diese Entscheidung (freigegebene oder lokale Ordner) ist jedoch komplex und es sollten dabei verschiedene Aspekte in Hinsicht auf den Prozess und die Umgebung in Betracht gezogen werden: die Größe der Dateien, die Änderungshäufigkeit, die Gleichzeitigkeit bei der Bearbeitung der gleichen Datei, Sicherheitsrichtlinien usw.

Quellenkontrolle

Um die Projektversionen einfach verwalten zu können und die Arbeit mit weiteren Entwicklern teilen zu können, empfehlen wir ein Versionskontrollsystem. UiPath Studio ist direkt mit GIT, TFS und SVN integriert. Das Tutorial, in dem die Verbindungsschritte und Funktionen erklärt werden, finden Sie hier.

Kontrolleinstellungen

Um das Hartkodieren externer Einstellungen in den Workflows zu vermeiden (wie Dateipfade, URLs usw.), empfehlen wir, sie in einer .config-Datei (.xlsx, .xml, oder .json) oder in Orchestrator als Assets aufzubewahren, falls sie sich oft ändern.

Im Allgemeinen bedeutet dies, dass die endgültige Lösung erweiterbar sein soll, damit Variationen und Änderungen der Eingabedaten ohne Entwicklerintervention möglich sind. So sollten beispielsweise Listen mit Kunden, die die Berechtigung für bestimmte Transaktionstypen haben, E-Mails von Personen, die Benachrichtigungen erhalten sollen usw. in externen Dateien gespeichert werden (wie etwa Excel), damit Geschäftsleute oder andere Abteilungen sie direkt ändern können (hinzufügen/entfernen/aktualisieren).

Für alle repetitiven Prozesse sollten alle Workflow-Aufrufe von der Hauptschleife mit der Option Isoliert (Isolated) markiert werden, damit sie vor möglichen Abstürzen von Robot (wie Out of Memory) geschützt sind.

Credentials

Im Workflow selbst sollten keine Anmeldedaten gespeichert werden. Sie sollten stattdessen aus sicheren Speicherorten wie dem Windows Credential Store oder Orchestrator-Assets geladen werden. In den Workflows können Sie sie über die Aktivität GetCredential abrufen.

Fehlerabwicklung

Wenn Sie einen automatisierten Prozess ausführen, können zwei Ausnahmen auftreten: etwas vorhersehabr oder komplett unerwartet. Basierend auf dieser Unterscheidung gibt es zwei Möglichkeiten, auf Ausnahmen zu reagieren, entweder durch explizite Aktionen, die automatisch innerhalb des Workflows ausgeführt werden, oder durch die Eskalation des Problems zu menschlichen Bearbeitern.

In Situationen, in denen Ausnahmen angetroffen werden können, ist es hilfreich, eine globale Ausnahmebearbeitung (Global Exception Handler) zum Automationsprojekt hinzuzufügen. Zu jedem Automationsprojekt kann nur ein Workflow dieser Art hinzugefügt werden. Für Bibliotheken steht die globale Ausnahmebearbeitung nicht zur Verfügung.

Der Workflow kann darauf eingestellt werden, das Verhalten des Workflows bei Antreffen einer Ausnahme festzulegen, indem die Bearbeitung den Fehler ignoriert und ab der nächsten Aktivität fortfährt, erneut versucht, die Aktivität, bei der der Fehler aufgetreten ist, zu starten, die Ausführung abbricht oder fortsetzt und der Fehler erneut auftritt.

Überdies können in der globalen Ausnahmebearbeitung enthaltene Argumente darauf eingestellt werden, den Namen der Aktivität, bei der die Ausnahme aufgetreten ist, zu protokollieren oder einige Male erneut zu versuchen, die Aktivität auszuführen. Um weitere Informationen zur Verwendung dieser Argumente zu erhalten, gehen Sie auf die SeiteGlobale Ausnahmebearbeitung (Global Exception Handler).

Als Alternative zur globalen Ausnahmebearbeitung (Global Exception Handler) kann die Verbreitung von Ausnahmen gesteuert werden, indem anfälliger Code in Try/Catch-Blöcke eingefügt wird, in denen Situationen angemessen behandelt werden können. Auf der obersten Ebene muss das Hauptprozessdiagramm umfassende Korrekturmaßnahmen definieren, um alle allgemeinen Ausnahmen zu beheben und die Systemintegrität zu gewährleisten.

Kontext-Handler bieten mehr Flexibilität für Roboter, um sich an verschiedene Situationen anzupassen, und sie sollten für die Implementierung alternativer Techniken, Bereinigung oder Anpassung von Benutzer-/Protokollmeldungen verwendet werden. Nutzen Sie den vertikalen Verbreitungsmechanismus von Ausnahmen, um doppelte Handler in Catch-Abschnitten zu vermeiden, indem Sie den Handler um einige Ebenen nach oben bewegen, wo er alle Ausnahmen an einer einzigen Stelle abdecken kann.

In der Ausnahmemeldung sollten genügend Details angegeben werden, damit ein Mensch sie verstehen und die notwendigen Maßnahmen ergreifen kann. Ausnahmemeldungen und -quellen sind unerlässlich. Die Quell-Eigenschaft des Ausnahmeobjekts gibt den Namen der Aktivität an, die fehlgeschlagen ist (innerhalb eines aufgerufenen Workflows). Auch hier ist die Benennung wichtig, denn eine schlechte Benennung gibt keinen klaren Hinweis auf die Komponente, die abgestürzt ist.

Wie Sie unten sehen können, macht die Entscheidung, die Aktivität Aufrufen (Invoke) nicht umzubenennen, die Ausnahmequelle im Falle eines Absturzes bedeutungslos (z. B. Workflow-Datei aufrufen > Workflow-Datei aufrufen > Workflow-Datei aufrufen > Workflow-Datei aufrufen > Eingeben in).

Sauber halten

Stellen Sie im Prozessablauf sicher, dass Sie die Zielanwendungen (Browser, Apps) schließen, nachdem die Roboter mit ihnen interagiert haben. Wenn sie offen gelassen werden, nutzen sie die Maschinenressourcen und können die anderen Schritte der Automatisierung stören.

Bevor Sie das Projekt veröffentlichen, werfen Sie einen letzten Blick auf die Workflows und bereinigen Sie diese:

• Entfernen Sie nicht referenzierte Variablen
• Löschen Sie temporäre Zeile schreiben (Write Line)-Ausgaben
• Lölschen Sie deaktivierten Code.
• Stellen Sie sicher, dass die Benennung aussagekräftig und eindeutig ist.
• Entfernen Sie unnötige Behälter (Rechtsklick > Sequence entfernen).

Auch der Projektname ist wichtig. So wird der Prozess in Orchestrator gesehen, daher sollte er mit Ihren internen Benennungsregeln übereinstimmen. Standardmäßig ist die Projekt-ID der ursprüngliche Projektname, aber Sie können sie aus der Datei project.json ändern.

Die Beschreibung des Projekts ist ebenfalls wichtig (dies wird in Orchestrator angezeigt). Es könnte Ihnen helfen, einfacher zwischen den Prozessen zu unterscheiden, also wählen Sie auch eine aussagekräftige Beschreibung.

Wiederverwendbarkeit von Code

Bei der Entwicklung müssen wir oft die gleichen Schritte in mehr als einem Workflow/Projekt automatisieren, daher sollte es eine gängige Praxis sein, Workflows zu erstellen, die kleine Teile der auftretenden Automatisierung enthalten und diese der Bibliothek hinzufügen.

Es gibt kein Universalrezept, das Ihnen sagt, wie Sie einen bestimmten Prozess aufteilen müssen.

Die Trennung der Geschäftslogik von den Automatisierungskomponenten ist jedoch ein gutes Prinzip, das beim Aufbau eines Codes hilft, der effektiv wiederverwendet werden kann.

Beispiel

Nehmen wir an, dass ein Teil Ihres Prozesses das Lesen der Kundeninformationen erfordert, dann aktualisieren Sie basierend auf diesen Informationen und internen Geschäftsregeln die Kundendaten.

Get Customer Info und Change Customer Info sollten zwei verschiedene Automatisierungskomponenten sein, die von jedem Prozess völlig unabhängig sind. Die Logik (Aktualisierung des Kundentyps nur, wenn der Gesamtbetrag in den letzten 12 Monaten größer als 100.000 ist) sollte von der Automatisierung getrennt gehalten werden. Beide Komponenten können später, einzeln, im selben Projekt oder in einem anderen, mit einer anderen Logik verwendet werden. Bei Bedarf können spezifische Daten über Argumente an diese Komponenten gesendet werden.

Change Customer Info sollte nicht aus Get Customer Info heraus aufgerufen werden, da dies das Testen, Behandeln von Ausnahmen und die Wiederverwendung erschwert.

Hinweis: Verwenden Sie separate Komponenten für Get Info und Change Info.

Wenn die Trennung zwischen den Aktionen nicht so offensichtlich ist, ist das Kopieren von bestehendem Code von einem Workflow in einen anderen (oder von einem Projekt in ein anderes) auch ein guter Hinweis darauf, dass Sie eine separate Komponente (Workflow) für den Code erstellen und ihn bei Bedarf aufrufen sollten.

Wo speichern Sie wiederverwendbare Komponenten?

Das Ziehen und Ablegen von vorhandenem Code aus der Bibliothek in einen Workflow ist einfacher, als den Code immer wieder neu zu erstellen. Der Umgang mit Daten (Sortieren, Filtern) oder mit Text (Splitten, Regex-Muster) sind Beispiele dafür, was der Beispielbibliothek hinzugefügt werden kann. Bitte beachten Sie, dass der Code, sobald er dem Workflow hinzugefügt wurde, statisch wird. Wenn Sie also den Workflow in der Bibliothek aktualisieren, wird er sich nicht in den bestehenden Live-Prozessen widerspiegeln.

Gängige (wiederverwendbare) Komponenten (wie App-Navigation, Anmeldung, Initialisierung) werden besser separat auf netzwerkfreigeschalteten Laufwerken gespeichert und gepflegt. Von diesem Laufwerk aus können sie von verschiedenen Robotern, von verschiedenen Prozessen aus aufgerufen werden. Der größte Vorteil dieses Ansatzes besteht darin, dass sich jede Änderung an der Master-Komponente sofort in allen Prozessen widerspiegelt, die sie verwenden.

Wichtig: Windows- und plattformübergreifende Projekte unterstützen das Aufrufen von .xaml-Dateien nicht und .cs Dateien außerhalb des Projektspeicherorts speichern.

So überprüfen Sie die Qualität der Automatisierung

• Modularität:

  • Die Trennung von Anliegen mit dedizierten Workflows ermöglicht feingranulare Entwicklung und Testen;
  • Extrahieren und teilen Sie wiederverwendbare Komponenten oder Workflows zwischen Projekten.

• Instandhaltbarkeit:

  • Gute Struktur- und Entwicklungsstandards.

• Lesbarkeit:

  • Standardisierte Prozessstruktur mit klaren Entwicklungspraktiken;
  • Aussagekräftige Namen für Workflow-Dateien, Aktivitäten, Argumente und Variablen.

• Flexibilität:

  • Speichern Sie die Umgebungseinstellungen in externen Konfigurationsdateien oder Orchestrator-Instanzen, so dass Sie die Automatisierung sowohl in Test- als auch in Produktionsumgebungen problemlos durchführen können.

• Zuverlässigkeit:

  • Ausnahmebehandlung und Fehlermeldung;
  • Aktualisierung des Fortschritts der Ausführung in Echtzeit.

• Erweiterbar:

  • Bereit für die Aufnahme neuer Anwendungsfälle.