- Versionshinweise
- Erste Schritte
- Einstellung und Konfiguration (Setup and Configuration)
- Automationsprojekte
- Abhängigkeiten
- Workflow-Typen
- Dateivergleich
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Workflowdesign
- UI-Automatisierung (UI Automation)
- Projektorganisation
- Automatisierungs-Lifecycle
- Integration der Quellenkontrolle
- Debugging
- Das Diagnose-Tool
- Workflow-Analyse
- Über die Workflow-Analyse
- ST-NMG-001 – Namenskonvention für Variablen
- ST-NMG-002 – Namenskonvention für Argumente
- ST-NMG-004 – Duplizierung des Anzeigenamens
- ST-NMG-005 – Variable überschreibt Variable
- ST-NMG-006 – Variable überschreibt Argument
- ST-NMG-008 – Variablenlänge überschritten
- ST-NMG-009: Datentabellenvariablen mit Präfix versehen
- ST-NMG-011 – Datentabellenargumente mit Präfix versehen
- ST-NMG-012 – Standardwerte für Argumente
- ST-NMG-016 – Argumentlänge überschritten
- ST-DBP-002 – Hohe Anzahl von Argumenten
- ST-DBP-003 – Leerer Catch-Block
- ST-DBP-007 – Mehrere Flussdiagrammebenen
- ST-DBP-020 – Nicht definierte Ausgabeeigenschaften
- ST-DBP-023 – Leerer Workflow
- ST-DBP-024 – Prüfung der Persistenzaktivität
- ST-DBP-025 – Voraussetzung für Variablenserialisierung
- ST-DBP-026 – Verwendung der Verzögerungsaktivität
- ST-DBP-027 – Bewährte Methode für Persistenz
- ST-DBP-028 – Voraussetzung für Argumentenserialisierung
- ST-USG-005 – Hartcodierte Aktivitätsargumente
- ST-USG-009 – Nicht verwendete Variablen
- ST-USG-010 – Nicht verwendete Abhängigkeiten
- ST-USG-014 – Paketbeschränkungen
- ST-USG-020 – Minimale Protokollmeldungen
- ST-USG-024 – Nicht verwendet, gespeichert für später
- ST-USG-025 – Missbrauch gespeicherter Werte
- ST-USG-026 – Aktivitätseinschränkungen
- ST-USG-027 – Erforderliche Pakete
- ST-USG-028 – Aufruf von Dateivorlagen einschränken
- Variablen
- Argumente
- Importierte Namespaces
- Aufzeichnung
- UI-Elemente
- Kontrollfluss
- Selektoren
- Objekt-Repository
- Data-Scraping
- Bild- und Textautomatisierung
- Automatisierung von Citrix-Technologien
- RDP-Automatisierung
- Salesforce-Automatisierung
- SAP-Automation
- VMware Horizon-Automatisierung
- Protokollierung
- Das Tool ScreenScrapeJavaSupport
- Das WebDriver-Protokoll
- Test Suite – Studio
- Erweiterungen
- Fehlersuche und ‑behebung
- Informationen zur Fehlerbehebung
- Microsoft App-V – Unterstützung und Einschränkungen
- Fehlerbehebung bei Internet Explorer x64
- Probleme in Microsoft Office
- Erkennen von UI-Elementen in PDF mit Zugriffsoptionen.
- Fehlerbehebung bei JxBrowser-Anwendungen
- Überwachung der Benutzerereignisse (User Events Monitoring)
- Citrix-Fehlerbehebung
Projektorganisation
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.
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.
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.
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.
.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.
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.
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).
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).
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.
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.
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.
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.
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.
-
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.