- 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
Automatisierungs-Lifecycle
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.
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.
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.
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.
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.
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.
RunAllTests.xaml
kann ein Entwickler eine Sequence mit vielen .xaml
-Dateien automatisch testen und so kleine Integrationen zwischen Komponenten ausprobieren und Stresstests durchführen. Am Ende jedes Texts wird ein Bericht erzeugt. Normalerweise sollten diese Art von Tests außerhalb der Bürozeiten, in Testumgebungen, durchgeführt werden, um die Zeit des Entwicklers 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.
UiPath.config
oder Orchestrator-Assets, um Flags oder Einstellungen für die aktuelle Umgebung zu wechseln. Ein Testmodusparameter (Boolean) kann vor der Interaktion mit Live-Anwendungen überprüft werden. Dies könnte als Asset-(oder Argument-)Input empfangen werden. Wenn es auf True gesetzt ist, folgt es beim Debuggen und Integrationstesten dem Testweg und führt den Fall nicht vollständig aus. So kann beispielsweise der Testpatch das Senden von Benachrichtigungen überspringen, die Schaltfläche OK oder Speichern überspringen oder stattdessen die Schaltfläche Abbrechen oder Schließen drücken. Wenn auf False gesetzt, wird der normale Produktionsmodus-Route gefolgt.
Auf diese Weise können Sie Modifikationen vornehmen und in Prozessen testen, die direkt in Produktivsystemen arbeiten.
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.
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:
- Entwickler erstellen den Prozess und testen und debuggen ihn lokal (Studio).
- Nachdem die Automatisierungsentwicklung abgeschlossen ist, wird der Prozess zum Development-Orchestrator veröffentlicht und erneut durchgängig getestet.
- Danach checken sie den Projektordner (nicht verpackt) in einem Master-Bibliotheksordner (auf VCS) ein.
- 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.
- Wenn während der Tests ein Problem auftritt, werden die obigen Schritte wiederholt.
- Nachdem alle QA-Tests bestanden sind, wird das Paket in eine Produktionsumgebung – Process Pckgs (Prod) weitergeleitet.
- 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).
.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.
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.
.nlog
gespeichert.
Benutzerdefinierte Protokollfelder
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.