Methodik für die Wiederverwendung von UI-Komponenten

UiPath-Projekte haben zwei Hauptebenen:

• Logikebene – Enthält alle Datenvalidierung und -verarbeitung sowie alle anderen logischen Anweisungen, die für den Prozessablauf erforderlich sind.
• GUI-Interaktionsebene – Wird zum Extrahieren und Eingeben von Daten in die Anwendung verwendet.

Um Probleme in Bezug auf die Wartbarkeit und Wiederverwendbarkeit der Komponenten zu vermeiden, können Sie die GUI-Interaktionsebene trennen, indem Sie eine Reihe von Bibliotheken mit wiederverwendbaren Komponenten erstellen, die ausschließlich für die Interaktion mit den Benutzeroberflächen bestimmt sind. Auf diese Weise können Sie eine vielseitige und sehr robuste Bibliothek erstellen, die einfach zu warten (sie enthält nur GUI-Interaktionselemente und keine andere prozessabhängige Logik) und extrem wiederverwendbar ist (es ist sehr wahrscheinlich, dass ein anderer Prozess, der dieselbe Anwendung automatisiert, zumindest einige der Komponenten wiederverwenden kann).

Darüber hinaus bietet das in Studio v2020.10 eingeführte Object Repository eine völlig neue Möglichkeit zum Erstellen und Verwalten von Elementen, die in der UI-Automatisierung verwendet werden. Damit bietet es in Bezug auf das Erstellen von skalierbaren und umfangreich wiederverwendbaren UI-Automatisierungen bahnbrechende Vorteile.

Dieser Artikel definiert eine Methodik, bei der wir Bibliotheken und das Object Repository verwenden können, um einfach wartbaren und wiederverwendbaren Code zu erstellen, beschreibt die zu Grunde liegenden Architekturprinzipien und bewährten Methoden und bietet eine detaillierte Aufschlüsselung der Schritte, die zum Erstellen wiederverwendbarer Komponenten erforderlich sind, zusammen mit zahlreichen Beispielen, die die ACME-Webanwendung verwenden.

Allgemeine Grundsätze

Es gibt eine Vielzahl von Softwareentwicklungsprinzipien, die unabhängig von der verwendeten Programmiersprache oder Plattform angewendet werden können und sich im Kontext der RPA-Entwicklung mit UiPath Studio als sehr nützlich erweisen können.

Trennung bei Bedenken

Das ist der wichtigste Grundsatz, den es zu beachten gilt. Trennung bei Bedenken besagt, dass ein Programm in verschiedene Abschnitte unterteilt werden muss, sodass jeder Abschnitt ein separates Anliegen behandelt. In unserem Fall müssen wir unsere Lösung überlagern, was bedeutet, dass jeder Abschnitt zu einer eigenen Ebene werden sollte. Das Unterteilen einer Lösung auf einzelnen Ebenen ermöglicht es, die Ebenen einzeln zu testen. Für eine normale Softwareanwendung haben wir normalerweise drei verschiedene Ebenen:

• Die Präsentationsebene bezieht sich auf die Interaktion mit dem Benutzer, bei der Daten angezeigt und dem Benutzer präsentiert werden. Diese Ebene sollte keine Geschäftslogik enthalten. 

  Im Kontext eines RPA-Projekts ersetzt die GUI-Interaktionsebene diese Ebene, da das Hauptziel einer Automatisierung darin besteht, mit anderen Anwendungen statt mit einem tatsächlichen Benutzer zu interagieren.

• Die Domänenebene befasst sich mit der Domänenlogik und bezieht sich auf die allgemeine Geschäfts-/Problemdomäne, die die Anwendung löst.

  Im Kontext eines RPA-Projekts ist das die Logikebene, die sich mit der Logik der Anwendung befasst.

• Auf der Persistenzebene werden von der Anwendung benötigten Daten gespeichert.

  Das ist keine obligatorische Ebene in einem RPA-Projekt, da es Anwendungsfälle gibt, in denen es keine dauerhafte Datenspeicherung gibt. Angesichts des Umfangs dieses Artikels lassen wir diese Ebene aus.

Einzelverantwortung

Ein weiteres Prinzip, das beim Entwerfen eines RPA-Projekts berücksichtigt werden muss, ist das Prinzip der einzigen Verantwortung. Das bedeutet, dass eine XAML-Datei nur eine einzige Funktion erfüllen sollte. Dieses Prinzip ist mit dem Prinzip der niedrigen Kopplung und der hohen Kohäsion verbunden. Das bedeutet, dass der Code modularisiert werden sollte, obwohl er mehrschichtig ist. Daher können mehrere Module für eine einzelne Schicht vorliegen.

• Niedrige Kopplung bedeutet, dass ein Modul so wenig wie möglich von einem anderen Modul abhängen sollte. In einem UiPath-Projekt erreichen wir die Modularisierung mithilfe von Bibliotheken (mehr dazu finden Sie im Abschnitt „Methode“).
• Hohe Kohäsion bedeutet, dass Aktionen, die derselben Anwendung zugeordnet sind, im selben Modul bleiben sollten.

Nutzung des Object Repository

Ein RPA-Prozess kann einfach als Kombination aus Daten, Datenmanipulation und Anwendungsinteraktion definiert werden.

• Daten – Beim Definieren von Variablen oder Argumenten ausgewählte vordefinierte Datentypen oder Ihre eigenen Typen, die Sie importieren und in Studio verwenden können. Darüber hinaus bietet die in v2020.10 eingeführte Data Service-Funktion einen zentralen Ort, an dem Sie Datentypen erstellen und übergreifend über Automatisierungen wiederverwenden können.
• Datenmanipulation – Dies kann über Aktivitäten erfolgen, die die Bausteine von Automatisierungs- und/oder Datenmanipulationsausdrücken sind. Aktivitäten sind in Paketen verfügbar, die Sie in Studio installieren können. Sie können auch eigene benutzerdefinierte Aktivitäten erstellen, wenn bestimmte Funktionen nicht von den verfügbaren Paketen abgedeckt werden. Weitere Informationen zum Erstellen benutzerdefinierter UiPath-Aktivitäten finden Sie unter Erstellen einer benutzerdefinierten Aktivität.
• Anwendungsinteraktion – Dies kann über UI-Automatisierung oder Integrationen/APIs erfolgen. Die UI-Automatisierung kann für die meisten heute verfügbaren Anwendungen verwendet werden. UI-Interaktionskomponenten können mithilfe von Bibliotheken oder dem Objekt-Repository wiederverwendet werden.

Das Object Repository hat eine hierarchische Struktur, bei der jeder Knoten Bildschirme oder Elemente darstellt, die sich alle unter der Anwendungsebene befinden. Die Struktur ist wie folgt:

• Eine UI-Anwendung ist eine Zielanwendung, die mehrere Versionen mit je mehreren Bildschirmen haben kann.
• Screen ist ein UI-Scope, der mehrere Elemente zusammenfasst, die zu demselben Bildschirm gehören. Der UI-Scope wird entweder aus Aktivitäten innerhalb des Workflows extrahiert oder zum Zeitpunkt der Elementerfassung generiert.
• UI-Elemente enthalten vollständige oder partielle Elementselektoren, Ankerselektoren, Kontext für die Bildschirm- und Elementbilderfassung sowie andere Metadaten, die das Element auf dem Bildschirm beschreiben.
• Ein UI-Deskriptor ist eine übergeordnete Gruppe von Selektoren und enthält Informationen zum eindeutigen Identifizieren von Elementen auf dem Bildschirm. UI-Deskriptoren werden aus Aktivitäten im Workflow extrahiert und einem strukturierten Schema hinzugefügt, das sie nach UI-Anwendungen, Bildschirmen und UI-Elementen gruppiert. Außerhalb der Taxonomiestruktur enthalten nur Bildschirme und Elemente Deskriptorinformationen, während der Rest zur Gruppierung verwendet wird und ihre Rolle darin besteht, Upgrades zwischen Versionen einer Anwendung sicherzustellen.

In der folgenden Abbildung können wir beispielsweise Folgendes identifizieren:

• UI-Anwendung: ACME-Version 1.0.0.
• Bildschirme: Dashboard, Rechnungen, Anmeldung.

• UI-Elemente: E-Mail, Schaltfläche „Anmelden“.

  
  

  

  
  

Geben Sie für jedes Element und jeden Bildschirm im Object Repository die folgenden Details an:

• Der genaue Name des Bildschirms, der Seite oder des Elements, wie er in der Benutzeroberfläche angezeigt wird (z. B. Schaltfläche „Anmelden“).
• Der Typ, z. B. Schaltfläche oder Eingabe (nur für Elemente).
• Eine optionale Beschreibung. Wir empfehlen, einen kurzen Überblick darüber hinzuzufügen, wie das Element verwendet werden kann (z. B. Klicken Sie auf „Anmelden“, um den Anmeldeprozess abzuschließen).

• UI-Deskriptor – Informationen, die das Element eindeutig identifizieren. Enthält klassische Selektoren, Fuzzy-Selektoren und Image-basierte Automatisierung. Wir empfehlen, die Image-basierte Automatisierung nur zu verwenden, wenn die anderen Methoden nicht funktionieren.

  
  

  

  
  

Weitere Informationen zur Verwendung des Object Repository finden Sie unter Über Object Repository.

Hochskalieren durch Kombinieren von Workflow-Bibliotheken und dem Object Repository

Das Object Repository kann das Erstellen von UI-Automatisierungen deutlich einfacher und effizienter gestalten, aber um diese Funktion voll auszuschöpfen, können Sie die Object Repository-Elemente in ein separates Bibliotheksprojekt integrieren, das auch alle UI-Interaktionen enthält, die erstellt werden müssen. Auf diese Weise können Sie Projekte erstellen, die keine UI-Interaktionen enthalten und nur die Logik der Automatisierungen enthalten.

Wir empfehlen, eine Bibliothek für jede Anwendung zu erstellen, die Sie automatisieren möchten, und alle UI-Interaktionen und Object Repository-Elemente darin aufzunehmen. Die Bibliotheksaktivität kann dann aus einer Workflowdatei aufgerufen werden, die Teil der Logikebene (des Hauptprojekts) ist. Dadurch wird sichergestellt, dass:

• Änderungen an der UI-Interaktion wirken sich nicht auf die Logik der Anwendung aus. Das kann mit einer Trennung zwischen Modell, Ansicht und Controller verglichen werden, bei der sich die Modellschicht in unserem Fall hauptsächlich mit den Daten befasst, die vom Controller an die Ansicht übergeben werden.
• Sobald eine Bibliothek veröffentlicht und ein Paket erstellt wurde, kann sie in verschiedenen Projekten referenziert werden, ohne dass sie jedes Mal neu geschrieben werden muss und ohne dass Code zwischen mehreren Projekten kopiert und eingefügt werden muss. Wenn die UI-Interaktion geändert wird, kann die Bibliothek aktualisiert, eine neue Version veröffentlicht und alle Projekte können für die Verwendung der neuesten Version aktualisiert werden. Darüber hinaus wirken sich Änderungen, die in der Logikebene auftreten können, nicht auf die UI-Interaktion aus.
• Da der Orchestrator mehrere Versionen derselben Bibliothek speichern kann, kann eine frühere Version leicht abgerufen werden, wenn sie erneut verwendet werden muss. Auf diese Weise können verschiedene Versionen derselben Bibliothek in verschiedenen Projekten verwendet werden und ein einzelnes Automatisierungsprojekt kann sofort zwischen verschiedenen Versionen derselben Bibliothek wechseln.

Mit dieser Methodik enthält das Hauptautomatisierungsprojekt (der Controller) die gesamte prozessabhängige Logik und interagiert mit der UI, indem es die Workflows innerhalb der Bibliothek nutzt (die als Pseudo-Ansicht vorstellbar sind). Schließlich wird das Modell durch die Argumente dargestellt, die uns helfen, Daten zwischen diesen beiden Komponenten zu übergeben.

Erstellen einer UI-Bibliothek

Führen Sie die folgenden Schritte aus, um eine UI-Bibliothek wie oben beschrieben zu erstellen:

1. Analysieren Sie Ihren Prozess und unterteilen Sie ihn in die darin enthaltenen Schritte

Wir empfehlen, ein Flussdiagramm zu erstellen, um den Prozess zu visualisieren.

2. Weisen Sie jeden der Schritte einer Kategorie zu

Weisen Sie jeden Schritt basierend auf der Ebene, zu der er gehört, entweder der GUI-Ebenenkategorie oder der Logik-Ebenenkategorie zu. Zum Beispiel:

• Weisen Sie Schritte wie Click, Type Into und Get Text der GUI-Interaktionsebene zu.

  Tipp: Fügen Sie der Bibliothek keine einzelnen Aktivitäten hinzu, sondern nur komplexere Aktionen wie Klicken, bis etwas auf der Benutzeroberfläche erscheint, alle Seiten einer Tabelle durchgehen und alle Zeilen extrahieren oder eine komplexere Aktion wie das Anmelden, die aus mehreren kleineren GUI-Interaktionsteilen besteht. Als allgemeine Regel gilt: Jede Komponente, die Sie einer Bibliothek hinzufügen, sollte eine Aktion sein, ein komplexerer Teil der Automatisierung, der mehrere Aktivitäten umfasst, und keine einzelne UI-Automatisierungsaktivität.

• Weisen Sie Aktionen wie Dateiverarbeitung, Datenvalidierung und -filterung sowie Behandlung von Geschäftsausnahmen der Logikebene zu. Denken Sie daran, dass die Logikebene die GUI-Ebene aufrufen muss, um ihre Schritte auszuführen.

3. Erstellen Sie eine separate Bibliothek für jede Anwendung, die in der Automatisierung verwendet wird.

4. Füllen und veröffentlichen Sie die UI-Bibliotheken

Gehen Sie für jede Bibliothek, die Sie erstellen, wie folgt vor:

1. Erstellen Sie das Anwendungsobjekt und die erforderlichen Bildschirme im Object Repository.

   
   

   

   
   

2. Erstellen Sie für jeden Bildschirm im Object Repository die erforderlichen Elemente und erstellen Sie ihre Deskriptoren.

   
   

   

   
   
   Hinweis: Wenn Sie das Object Repository nicht verwenden können, führen Sie dasselbe Verfahren aus, überspringen Sie jedoch die vorherigen beiden Schritte (4-1 und 4-2).

3. Entwickeln Sie eine XAML-Datei für jede erforderliche Aktion. Bildschirme und Elemente können hinzugefügt werden, wenn neue Workflowdateien erstellt werden, sodass dieser Schritt austauschbar mit den beiden vorherigen Schritten ausgeführt werden kann.

   Dies sind beispielsweise einige der Komponenten, die zur Automatisierung der Acme-Testprozesse entwickelt wurden.

   
   

   

   
   
4. Veröffentlichen Sie die Bibliothek im Orchestrator oder in einem lokalen NuGet-Feed.

5. Installieren Sie die Bibliotheken in Ihren Automatisierungsprojekten

Installieren Sie die erforderlichen Bibliotheken über das Fenster Pakete verwalten, um sie als Projektabhängigkeiten hinzuzufügen. Jeder Workflow innerhalb der Bibliotheken ist als Aktivität im Bereich Aktivitäten verfügbar. Sie können diese per Drag-and-Drop in den Projektworkflow ziehen und auf die gleiche Weise wie Aktivitäten verwenden.

Best Practices

Argumente

• Benennen Sie Argumente mit dem PascalCase-Standard. Das ist der Standard, der für die Parameter von Aktivitäten in UiPath Studio-Bibliotheken verwendet wird.
• Fügen Sie keine in_, out_, io_`-Präfixe in die Argumentnamen ein, da sie als Eigenschaften der Aktivitäten in der Bibliothek erscheinen.

  Argumente könnten beispielsweise wie in der folgenden Abbildung aussehen. Wenn Sie sich Ihre veröffentlichte Komponente ansehen, sehen Sie, dass Ihre Argumente bereits basierend auf ihrem Typ in verschiedene Kategorien unterteilt sind, sodass das Hinzufügen des Präfixes überflüssig wäre.

  
  

  

  
  
• Alle Workflows innerhalb einer GUI-Bibliothek, welche die zu automatisierende Anwendung öffnen/starten (z. B. eine Aktivität, die sich öffnet und sich bei der Anwendung anmeldet), sollten das resultierende Anwendungsfenster mit einem out-Argument vom Typ UiPath.Core.UiElement für eine moderne Designumgebung oder UiPath.Core.Window oder UiPath.Core.Browser für die klassische Umgebung zurückgeben. Darüber hinaus sollten alle anderen Aktivitäten im Paket sowohl für die klassische als auch für die moderne Umgebung ein in-Argument vom Typ UiPath.Core.Window oder UiPath.Core.Browser haben, welches das richtige Fenster angibt, in dem die aktuelle Aktion ausgeführt werden soll. Das ist äußerst hilfreich, wenn Sie während der Laufzeit der Prozesse mehrere Instanzen einer Anwendung geöffnet haben. Wenn Sie die klassische Entwurfsumgebung verwenden, senden Sie keine Selektoren als Argumente.

Das Entwickeln einer Bibliothek von Automatisierungskomponenten für die ACME-Website (Sie können die Beispielbibliothek unten herunterladen) erfordert eine Komponente, die den Browser öffnet und den Anmeldevorgang durchführt. Diese Aktivität sollte als Argumente den Benutzernamen, das Kennwort, die Site-URL verwenden und das Browser-Element zurückgeben. Optional kann der Browser als In-/Out-Argument gesendet werden, um ein Szenario zu unterstützen, in dem die Anmeldung in einem vorhandenen Fenster erfolgt.

Das Browser-Element hat den Typ UiPath.Core.UiElement:

So würden die Argumente aussehen:

Beim Erstellen des Workflows, der den Browser öffnet (z. B. der Anmelde-Workflow), müssen Sie zuerst überprüfen, ob das Browser-Argument NULL ist, und falls das der Fall ist, öffnen Sie <https://acme-test.uipath.com/> in einem neuen Browser in einem separaten Workflow:

Nachdem die Anmeldung durchgeführt und das Browser-Element an den Prozess zurückgegeben wurde, benötigen alle anderen Aktivitäten aus dieser Bibliothek diesen Parameter. Die Aktivität, die alle Rechnungen von der Website herunterlädt, hat beispielsweise die folgenden Parameter:

Wenn kein gültiger Browser an diese Aktivität übergeben wird, führt die Ausführung zu einem Fehler.

Fehlerbearbeitung

• Geben Sie innerhalb einer Bibliothek immer Fehler aus, wenn sie auftreten, und signalisieren Sie sie nicht durch Ausgabeargumente.
• Am Ende einer Bibliothekskomponente, sollte ihr Ergebnis validiert werden. Überprüfen Sie, ob die gewünschte Aktion stattgefunden hat, und lösen Sie eine Ausnahme aus, wenn dies nicht der Fall ist.

Beispiel

Wenn Sie eine Komponente erstellen, welche die Anwendungsanmeldung durchführt, möchten Sie beim nicht ordnungsgemäßen Ausführen der Anmeldung möglicherweise eine Ausnahme auslösen. Dazu fügen Sie nach Eingabe der Anmeldeinformationen und dem Anklicken der Schaltfläche „Anmelden“ eine Aktivität Check App State (bei Verwendung der modernen Designumgebung) oder Element Exists (bei Verwendung der klassischen Designumgebung) mit einem Timeout von 10 Sekunden hinzu, die überprüft, ob die Beschriftung „Willkommen…“ angezeigt wird. Wenn diese Aktivität falsezurückgibt, war der Authentifizierungsprozess nicht erfolgreich und eine Ausnahme wird ausgelöst:

Struktur und Benennung

Das Erstellen einer Komponente für jede Aktivität bedeutet, dass Ihre Bibliothek sehr schnell sehr groß wird. Damit Ihre Entwickler sie im Bereich „Aktivitäten“ leicht identifizieren können, sollte ein Standard für die Benennung Ihrer Komponenten definiert sein. Der von uns empfohlene Standard für die Benennung von Komponenten ist {Action} {Entity Used by Activity}. Dieser Standard:

• Ermöglicht Entwicklern die Suche nach einer Komponente entweder anhand ihres Namens, der von dieser Aktivität ausgeführten Aktion oder der während dieser Aktion verwendeten Entität.
• Vereinfacht das Verständnis, wofür die Komponente verwendet werden kann und mit welchen Seiten der Anwendung sie interagiert.

In einigen Fällen können Sie einfach {Action} verwenden. Das ist möglich, wenn die Aktion nicht für eine Entität ausgeführt wird (z. B. Login) oder wenn Sie weitere Informationen über den Namen angeben müssen, indem Sie dem Namen weitere Attribute hinzufügen, die jeweils durch ein Leerzeichen getrennt sind.

Darüber hinaus empfehlen wir, eine Ordnerstruktur innerhalb des Bibliotheksprojekts zu erstellen und ähnliche Komponenten im selben Ordner zu gruppieren. Als gute Faustregel sollten Sie einen Ordner für jede Hauptentität haben, mit der Sie innerhalb der GUI-Schicht interagieren. Wenn Sie in einer Anwendung mit einer großen Anzahl von Entitäten interagieren können, kann eine mehrschichtige Ordnerstruktur verwendet werden. Dies verbessert die Kohärenz Ihrer Bibliothek erheblich und verbessert den Überblick über die möglichen Aktionen, die für jede Entität genutzt werden können.

Sie können Ordner benennen, indem Sie entweder den Namen der Entität verwenden, mit der die Komponenten interagieren {Entity Used by Activity}, oder die allgemeine Aktivität {Action}, die sie ausführen. Wenn Sie beispielsweise einen Ordner erstellen möchten, in dem alle Komponenten für die Navigation durch die Seiten einer Webanwendung gespeichert werden, können Sie ihn Navigation nennen.

Auch auf Object Repository-Entitäten wie Bildschirme oder Elemente muss eine Namenskonvention angewendet werden, vorzugsweise die gleiche wie im Fall von Workflows und Ordnern, PascalCase.

Beispiel

Die ACME-Website (https://acme-test.uipath.com/) enthält mehrere Seiten, die es Benutzern ermöglichen, mit Entitäten wie Arbeitselementen, Prüfungen, Konten, Lieferanten, Rechnungen usw. zu interagieren.

Beim Erstellen einer Bibliothek mit Komponenten, die mit den oben genannten Elementen auf der ACME-Website interagieren, können Sie eine Ordnerstruktur erstellen und die Workflows in der Bibliothek wie in der folgenden Abbildung benennen:

Hinweis: Wir empfehlen die Verwendung des Title Case-Standards für die Namen der einzelnen Komponenten/Ordner (Application Name, Action, Entity Used by Activity).

Ansatz für größere Lösungen

In größeren Automatisierungsprojekten können mehrere Komponenten innerhalb einer Bibliothek einen sehr ähnlichen oder sogar identischen Code haben. In diesem Fall sollten Sie diese Komponente in einem separaten Workflow isolieren und wenn Sie nicht möchten, dass dieser Workflow außerhalb der Bibliothek zugänglich ist, markieren Sie ihn als von der Veröffentlichung ignoriert, um ihn privat zu machen.

Darüber hinaus ist es möglich, dass dieselbe Logik zwischen mehreren Prozessen implementiert werden muss. In diesem Fall sollte die wiederverwendbare Logik in einer separaten Bibliothek isoliert werden.

Das folgende Diagramm gibt einen Überblick darüber, wie eine Lösung wie diese aussehen könnte:

Vorteile

• Erstellen Sie nur eine Ebene, ohne die andere zu beeinträchtigen.
• Verwenden Sie vorhandenen Code wieder, ohne ihn bei jeder Verwendung neu schreiben zu müssen.
• Ändern Sie ganz einfach die UI-Interaktion, wenn eine Aktualisierung in der Anwendung erfolgt, und übertragen Sie die Änderung auf alle Prozesse, die die Bibliothek verwenden, ohne sie erneut veröffentlichen zu müssen.
• Die gemeinsame Nutzung der UI-Interaktionsschicht durch mehrere Prozesse bedeutet, dass dasselbe Modul gründlicher getestet wird und dass alle Korrekturen für alle Prozesse gleichzeitig vorgenommen werden können, was zu sehr robusten und zuverlässigen Automatisierungen führt.
• Eine dedizierte GUI-Interaktionsbibliothek macht es sehr einfach, dedizierte Testautomatisierungsprojekte zum Testen der UI-Automatisierung für bestimmte Anwendungen zu erstellen. Dadurch wird sichergestellt, dass Code sehr einfach zu testen ist und wichtige Änderungen an der Anwendung schnell erkannt werden.

Beispielprojekte

Um die Erstellung und Verwendung einer Bibliothek mithilfe des Object Repository zu veranschaulichen, haben wir einen Anwendungsfall mit der ACME-Webanwendung erstellt.

Bibliothek

Die Bibliothek mit allen ACME-Automatisierungsaktivitäten heißt Acme_ObjectRepository. Die neueste Version finden Sie unten:

Das Bibliotheksprojekt herunterladen

Bibliothekspaket herunterladen

Obwohl die Bibliothek ein Modul ist, das sich auf die Interaktion mit der ACME-Webanwendung konzentriert, ist sie auch modularisiert und in mehrere Ordner organisiert, die auf ihren Zwecken basieren:

Hier ist eine kurze Aufschlüsselung der Bibliothekskomponenten:

• Login Acme.xaml – Meldet sich bei der Anwendung an. Es enthält die folgenden Argumente:

  • Vier In-Argumente (URL, Benutzername, Kennwort, TimeoutDesired).

  • Das Browser-In/Out-Argument vom Typ UiPath.Core.UiElement – Diese Komponente wird entweder an bereits geöffnet ACME-Fenster angefügt oder öffnet ein neues Browserfenster, wenn noch keins geöffnet ist, und führt die Anmeldung durch. Der Browser-Parameter gibt das Browserfenster zurück und diese Variable wird an alle anderen Komponenten in der Bibliothek übergeben.

    
    

    

    
    
• Logout Acme.xaml – Ruft den Workflow Zur Startseite navigieren aus dem Navigationsmodul auf und beendet anschließend die aktuelle Sitzung. 

• Modul Benutzeroptionen – Enthält die Optionen, die die Konfigurationen des aktuellen Kontos in der ACME-Webanwendung ändern können. 

  • Reset test data.xaml – Setzt die Testdaten zurück, die in der ACME-Anwendung verwendet werden.

• Modul Rechnungen – Enthält die Aktionen, die für die in den Testdaten gefundenen Rechnungen ausgeführt wurden.

  • Download all invoices.xaml – Extrahiert alle Elemente in der Rechnungstabelle innerhalb der Anwendung und gibt sie als DataTable zurück.
  • Download invoices by vendor tax ID.xaml – Navigiert durch die gesamte Rechnungstabelle, bis eine Rechnung mit einer bestimmten Steuer-ID gefunden wird, die dann zurückgegeben wird. 

• Modul Navigation – Enthält Workflows, die durch die verschiedenen Seiten der Webanwendung navigieren

  • Die Komponenten in diesem Modul werden hauptsächlich von den anderen Bibliothek-Workflows verwendet und sollten normalerweise nicht direkt aus dem Hauptprozess aufgerufen werden. Sie sind jedoch als „Veröffentlichbar“ markiert, da sie in Attended-Prozessen nützlich sein können, bei denen der Roboter zu einer bestimmten Seite navigieren und dem Benutzer dann die Interaktion mit der Anwendung ermöglichen soll.

• Modul Arbeitselemente – Enthält die Aktionen, die für die in der Anwendung gefundenen Arbeitselemente ausgeführt werden.

  • Download all work items.xaml – Lädt alle Arbeitselemente in den Testdaten herunter.

Prozess

Download-Prozess

Das Hauptprojekt AcmeProcess_ObjectRepository besteht aus vier verschiedenen Anwendungsfällen. Dazu muss der Benutzer Windows-Anmeldeinformationen vom Typ Generic mit dem Namen ACMETest erstellen, in denen der Benutzername und das Kennwort gespeichert werden, mit denen sich der Roboter bei der ACME-Webanwendung anmeldet.

Die Anwendungsfallkomponenten in diesem Prozess führen verschiedene Aufgaben mithilfe von mehreren Komponenten aus, die in der ACME-UI-Komponentenbibliothek integriert sind.

Wenn der Workflow Main.xaml aufgerufen wird, meldet sich der Roboter bei der ACME-Anwendung an. Ein Dialogfeld fordert den Benutzer dann auf, einen der Anwendungsfälle auszuwählen, und ruft dann den Workflow entsprechend der Auswahl des Benutzers auf:

Testprojekt

Das Testprojekt herunterladen

Das Testprojekt Test_UiPath.AcmeProcess_ObjectRepository besteht aus fünf verschiedenen Testfällen, die verschiedene Funktionalitäten des Prozesses testen: Anmeldung/Abmeldung, Herunterladen aller Rechnungen/Herunterladen von Rechnungen nach Steuer-ID des Anbieters, Herunterladen von Arbeitselementen.