Standards für Qualitätsinhalte

Alle Auflistungen in UiPath Marketplace müssen die folgenden allgemeinen Richtlinien erfüllen:

Richtlinien	Details
Modulare und wiederverwendbare Komponenten	Lösungsbeschleuniger sollten im Hinblick auf Modularität konzipiert sein und eine durchdachte Architektur für Prozessvorlagen, Machine-Learning-Modelle, wiederverwendbare Bibliotheken und vieles mehr bieten. Diese modularen Komponenten sollten einfach zu integrieren und zu kombinieren sein, um benutzerdefinierte Prozesse für den spezifischen Anwendungsfall zu erstellen, an den ursprünglich gedacht wurde, oder die Möglichkeit haben, verschiedene wiederverwendbare Komponenten zwischen Prozessen zu übertragen. Dies sollte den Aufwand für Duplikate reduzieren und die Konsistenz mit den Entwicklungsrichtlinien in verschiedenen Prozessen fördern.
Konfigurierbare Parameter und Einstellungen	Lösungsbeschleuniger sollten konfigurierbare Parameter und Einstellungen bereitstellen, die an die Anforderungen der Endbenutzer und ihre geschäftlichen Anforderungen angepasst werden können. Konfigurationen können unter anderem Variablen, Schwellenwerte, Timeouts, Endpunkte, Machine-Learning-Modelle, Menschen in den zugewiesenen Schleifen und andere anpassbare Parameter umfassen, um Anpassung und Anpassungsfähigkeit zu ermöglichen. Die Prozess-Konfigurationsdatei, Orchestrator-Assets und Prozessargumente sind einige der Mittel, mit denen Sie Konfigurierbarkeit erreichen können.
Skalierbare und anpassungsfähige Architektur	Der Architekturentwurf sollte skalierbar, anpassungsfähig und in der Lage sein, unterschiedlichste Automatisierungsanforderungen zu erfüllen. Außerdem sollte er eine einfache Erweiterung mit mehr Robotern oder mehr Prozessen ermöglichen, wenn sich die Geschäftsanforderungen ändern oder neue Anwendungsfälle aufkommen. Die Architektur sollte die Integration mit verschiedenen Systemen, Anwendungen und Technologien ermöglichen, die in der Branche des Anwendungsfalls zu finden sind. Benutzer sollten in der Lage sein, verschiedene Solution Accelerator-Komponenten einfach auszutauschen oder neue zu integrieren, um den Anforderungen ihrer Organisation gerecht zu werden.
Integrationsfunktionen	Pre-built Integration Service connectors or connections built using Connector Builder should be utilized, when possible, to enable automation using APIs with an out of the box library of connectors while also providing a standard way to set up and manage connections with standardized authentication. Die nahtlose Integration mit externen Systemen und Anwendungen optimiert den Datenaustausch und ermöglicht es Solution Accelerators, mit der vorhandenen IT-Infrastruktur zu arbeiten, wodurch umfangreiche Modifikationen oder benutzerspezifische Entwicklungen minimiert werden. If API automation is not possible, UI automation should be contained within a GUI Integration Layer / Application Layer as described further below. This should utilize Object Repository within an Application Library.
Erweiterbarkeit und Anpassung	Solution Accelerators sollten so gestaltet sein, dass sie erweiterbar und anpassbar sind, sodass Solution Accelerator-Benutzer den Automatisierungsworkflow an die spezifischen Anforderungen ihrer Organisation anpassen können. Lösungsbeschleuniger sollten mit der Einstellung entwickelt werden, dass Organisationen den spezifischen Lösungsbeschleuniger als Grundlage für den Anwendungsfall verwenden sollten, während sie gleichzeitig die Möglichkeit haben, sie an ihre individuellen Geschäftsanforderungen anzupassen.

:::note Through these areas, a Solution Accelerator should provide a structured but flexible framework for building an efficient and scalable automation solution. In summary, your Solution Accelerator should promote modularity, adaptability, best practice compliance, and easy integration with systems and applications to facilitate rapid development and deployment of automation. ::: :::note For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.

Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on UiPath Marketplace without express authorization from the third party. :::

Standards for solution accelerators

1. Layered architecture

Das Design eines Solution Accelerators sollte eine Trennung zwischen der Geschäftslogikebene (Implementierungsebene) und der Anwendungsebene (falls erforderlich, GUI-Interaktionsebene) implementieren. Dies kann direkt in den verschiedenen Prozess-Workflows oder, wenn Wiederverwendbarkeit erforderlich ist, mithilfe von Bibliotheken erreicht werden.

2. Business logic layer (implementation layer)

• Diese Ebene ist für die Implementierung der Kerngeschäftslogik und der Automatisierungsworkflows des Solution Accelerators verantwortlich.
• Es konzentriert sich auf die spezifischen Aufgaben und Prozesse, die der Lösungsbeschleuniger innerhalb einer bestimmten Domäne oder eines bestimmten Anwendungsfalls automatisieren möchte.
• Die Geschäftslogik-Ebene definiert die Regeln, Bedingungen und Aktionen, die erforderlich sind, um die gewünschten Automatisierungsergebnisse zu erzielen.
• Sie kann Datenmanipulation, Entscheidungsfindung, Integration in externe Systeme und andere Verarbeitungsaufgaben beinhalten.
• Diese Ebene ist modular und anpassbar konzipiert, sodass Organisationen den Solution Accelerator an ihre spezifischen Geschäftsanforderungen anpassen können.
• In der Regel werden Automatisierungsfunktionen von UiPath wie Aktivitäten, Workflows und Variablen genutzt, um den Automatisierungsablauf zu orchestrieren.

3. Application layer

• Die Anwendungsschicht dient als Schnittstelle zwischen dem Automatisierungsworkflow und der GUI (grafischen Benutzeroberfläche) oder API (Anwendungsprogrammierschnittstelle) der verschiedenen Anwendungen und/oder Systeme, die am automatisierten Prozess beteiligt sind.
• Diese Ebene kann die Interaktionen mit den Benutzeroberflächenelementen, z. B. Schaltflächen, Felder, Menüs und Dialogfelder, innerhalb der Zielanwendungen oder -systeme verarbeiten. Diese Ebene könnte auch die Implementierung der Anwendungsprogrammschnittstelle in den Zielanwendungen oder -systemen übernehmen, z. B. die Dateneingabe über Codekommunikation anstelle der Verwendung der Benutzeroberfläche der Anwendung.
• Diese Ebene kann Aktivitäten und Komponenten enthalten, die eine UI-Automatisierung ermöglichen, z. B. Screen Scraping, Dateneingabe/-ausgabe und Navigation. Diese Ebene kann auch die Anwendungslogik für die programmatische Implementierung der gleichen Steuerelemente enthalten.
• Die Anwendungsschicht ist so konzipiert, dass sie an die jeweilige Zielanwendung angepasst werden kann. Alle Aktualisierungen von APIs oder Benutzeroberflächen sollten an einer Stelle erfolgen und sich dann für alle Implementierungen dieser Komponente anpassen.
• Die GUI-Interaktionsebene sollte Flexibilität bieten, um Variationen bei UI-Elementen, Bildschirmlayouts und Navigationspfaden zu verarbeiten.
• Innerhalb der API-Interaktionsebene muss die Ausgabe eines jeden Workflows mit dem Ziel des Workflows übereinstimmen. Wenn Ihr Workflow beispielsweise „Alle Benutzer abrufen“ heißt, sollte eine Sammlung von Benutzerobjekten zurückgegeben werden und kein JSON-Objekt, das dann weiter analysiert werden muss, um die erforderlichen Benutzerdaten zu extrahieren.
• Halten Sie die Dauer des API-Aufrufs auf einem Minimum, indem Sie die Paginierung verwenden und relevante Filter anwenden, wenn diese von der Ziel-API implementiert werden.

Hinweis:

Eine Trennung zwischen einer Geschäftsebene und einer Anwendungsebene gewährleistet eine klare Unterscheidung zwischen der Automatisierung und Prozesslogik und den anwendungsspezifischen Details. Dies ermöglicht eine modulare und skalierbare Architektur, in der Änderungen in der GUI oder API separat von der Kerngeschäftslogik verwaltet werden können. Diese Trennung ermöglicht eine einfachere Wartung, die Wiederverwendbarkeit innerhalb des Solution Accelerators oder die Übertragung auf andere Prozesse und die Anpassung des Solution Accelerators. Der Endbenutzer des Solution Accelerators kann die Anwendungsebene einfach ersetzen, um Änderungen in den Zielanwendungen anzupassen, ohne die zugrundeliegende Prozesslogik zu beeinflussen. Ebenso kann die Geschäftslogik unabhängig von der Anwendung geändert oder erweitert werden, um wechselnden Geschäftsanforderungen gerecht zu werden.

Standard architecture types

Transactional / queue based processes

Dies ist das Standard-Dispatcher-Performer-Modell. Das Robotic Enterprise Framework sollte für die Implementierung eines einfachen transaktionsbasierten Prozesses verwendet werden.

The Robotic Enterprise Framework is a project template based on State Machines. It is created to fit all the best practices regarding logging, exception handling, application initialization, and others, being ready to tackle a complex business scenario. The template contains several pre-made State containers for initializing applications, retrieving input data, processing it and ending the transaction. All these states are connected through multiple transitions which cover almost every need in a standard automation scenario. There are also multiple invoked workflows, each handling particular aspects of the project.

Das Modell „Verteiler und Ausführender“ ist eine vorgefertigte Lösung, um die beiden Hauptphasen eines Prozesses zu trennen, indem eine Warteschlange dazwischen platziert wird. Auf diese Weise ist die Produktion der Transaktionselemente völlig unabhängig von deren Verbrauch. Diese Asynchronität unterbricht die Zeitabhängigkeit zwischen dem Verteiler und dem Ausführender.

Bei diesem Standardansatz ist ein Verteiler eine Automatisierung zum Laden von Daten in eine UiPath-Warteschlange. Sie extrahiert Daten aus einer oder mehreren Quellen und verwendet sie, um Warteschlangenelemente zu erstellen, die von Ausführenden-Robotern verarbeitet werden können. Die Informationen werden an eine oder mehrere Warteschlangen übertragen, sodass der Verteiler ein gemeinsames Format für alle in Warteschlangenelementen gespeicherten Daten verwenden kann. Diese Daten können dann später in einer Automatisierung, dem Ausführenden, verarbeitet werden. Der Ausführender kann die Daten nach Bedarf verarbeiten, da die Warteschlangenelemente einzeln nacheinander verarbeitet werden. Es verwendet Fehlerbehandlungs- und Wiederholungsmechanismen für jedes verarbeitete Element. Ein Hauptvorteil des Ausführenders ist seine Skalierbarkeit (mehrere Ausführender können mit einer einzelnen Warteschlange verwendet werden).

2. Document Understanding processes

Most of the processes working with documents have in common their requirement to also "understand" their content. Hence, a dedicated framework specialized in document understanding has been put in place – the Document Understanding (DU) Process Framework.

This framework is essentially a UiPath Studio Project template based on a typical document processing flowchart. The process provides logging, error handling, retry mechanisms, and all the methods that should be used in a DU workflow. The workflow has an architecture decoupled from other connected automations:

• Es spielt keine Rolle, woher die zu verarbeitenden Dateien stammen oder was die Ausführung auslöst – das findet in einem vorgelagerten Prozess statt.
• Es spielt keine Rolle, wo die extrahierten Informationen verwendet werden sollen – das liegt in der Verantwortung des nachgelagerten Prozesses.
• Die Architektur des Frameworks ist sowohl für Attended- als auch für Unattended-Roboter gleich:
• Logik des Dokumentverständnisses (Digitalisierung, Klassifizierung, Datenextraktion)
• Human-in-the-loop logic (validation) using *Action Center
• for unattended robots, or a local *Validation Station
• for attended ones

Aufgrund dieser Mechanismen und Architekturen kombinieren die meisten Automatisierungen, die Document Understanding verwenden, in der Regel ein Dispatcher-Performer-Modell mit einem Document Understanding-Framework dazwischen:

• The *Dispatcher
• gathers documents to be processed from the upstream application or system.
• The *Document Understanding Process
• extracts the necessary information from each document one at a time with scalability because of the Dispatcher method.
• Finally, the *Performer
• utilizes the extracted data from the document to complete the process.

3. Transactional processes with Action Center

This architecture consists of Dispatcher – Performer - Finalizer processes with human in the loop, or Long-Running Workflow, process somewhere in the middle. The standard template for longrunning workflows is the Orchestration Process Template. Long-Running workflows have best practices that need to be followed to support service orchestration, human intervention, and long-running transactions in unattended environments.

Diese Architektur wird verwendet, wenn menschliches Eingreifen erforderlich ist, um die Automatisierung zu genehmigen oder zu überwachen. Infolgedessen müssen alle Flows nach Action Center-Aufgaben sowohl Zustimmung als auch Ablehnung berücksichtigen.

4. Further architectures

Je nach den Automatisierungsanforderungen können andere Architekturentscheidungen vorhanden und angemessen sein:

• Ein Finalizer kann immer für jede Bereinigung in Betracht gezogen werden, die innerhalb eines Prozesses erforderlich ist.
• Ein Reporter, der selten oder Ad-hoc ausgeführt wird, kann Automatisierungsstatistiken an die erforderlichen Stakeholder senden
• Extract-, Transform- und Load-Prozesse (ETL) können Daten aus mehreren Quellen in einem großen zentralen Repository kombinieren.
• Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.

Process best practices

Diese bewährten Methoden müssen bei der Entwicklung eines UiPath-Prozesses für einen Solution Accelerator befolgt werden:

• Follow the out of the box Workflow Analyzer rules. When analyzed with this tool, your project should raise minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • Es sollten keine hartcodierten Verzögerungen vorhanden sein.
  • Keine Aktivitäten dürfen Standardnamen haben.
  • Innerhalb eines Workflows dürfen keine zwei Aktivitäten denselben Namen haben.
  • Argumente müssen der Namenskonvention in_, out_ und io_ entsprechen.
  • Tief geschachtelte Aktivitäten sollten nicht vorhanden sein und als Argument für die Aufteilung des Workflows in kleinere Komponenten betrachtet werden.
• Bevor Sie mit der Entwicklung beginnen, sollten Sie die Prozessanforderungen gründlich analysieren und eine Lösung entwerfen, die auf die spezifischen Anforderungen zugeschnitten ist. Zerlegen Sie den Prozess in kleinere Aufgaben und identifizieren Sie Abhängigkeiten, um einen klaren und effizienten Workflow zu gewährleisten.
• Identifizieren Sie wiederverwendbare Komponenten oder Workflows, die einfach in anderen Projekten gewartet und wiederverwendet werden können, und trennen Sie sie von einem frühen Zeitpunkt. Dieser modulare Ansatz verbessert die Wiederverwendbarkeit, vereinfacht das Debuggen und verbessert die Skalierbarkeit.
• Implementieren Sie robuste Fehlerbehandlungsmechanismen, um Ausnahmen und Fehler ordnungsgemäß zu behandeln. Verwenden Sie Try-Catch-Blöcke, und stellen Sie informative Fehlermeldungen bereit, um die Fehlerbehebung zu unterstützen und die Stabilität des Prozesses zu erhöhen.
  • Fehler müssen spezifisch sein und eine entsprechende Fehlermeldung anzeigen. Eine Nullzeigerausnahme darf nicht ausgelöst werden, wenn eine Zeichenfolge ausgefüllt werden soll, dies jedoch nicht aufgrund des Rückgabewerts einer Anwendung erfolgt – die Ausnahme sollte als von der Anwendung verursachte Geschäftsregelausnahme klassifiziert werden.
• Integrieren Sie konfigurierbare Einstellungen in Ihren Prozess, z. B. Eingabeparameter, um Flexibilität und Anpassungsfähigkeit zu ermöglichen. Dies ermöglicht es Benutzern, den Prozess einfach basierend auf ihren spezifischen Anforderungen anzupassen, ohne den Kernworkflow zu ändern.
• Validieren Sie Eingaben, um sicherzustellen, dass sie die erforderlichen Kriterien erfüllen, und verarbeiten Sie Ausnahmen für ungültige oder unerwartete Daten. Implementieren Sie geeignete Datenverarbeitungstechniken, wie z. B. Datenbereinigung und -transformation, um eine genaue und zuverlässige Verarbeitung sicherzustellen.
• Integrieren Sie Protokollierungsmechanismen, um relevante Informationen während der Ausführung des Prozesses zu erfassen. Dies hilft bei der Fehlerbehebung und liefert wertvolle Erkenntnisse für die Prozessoptimierung. Verwenden Sie Debugging-Tools, um Probleme effizient zu identifizieren und zu lösen.
  • Protokollierungsmechanismen für die Berichterstattung und UiPath Insights sollten ebenfalls berücksichtigt werden.
• Testen Sie den Prozess gründlich, um seine Funktionalität und Zuverlässigkeit sicherzustellen. Verwenden Sie Testfälle und Daten, um die erwarteten Ergebnisse zu validieren und Grenzfälle zu behandeln. Dies hilft, Fehler oder Inkonsistenzen vor der Bereitstellung zu identifizieren und zu beheben.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Überprüfen und verbessern Sie Ihre Prozesse regelmäßig basierend auf Feedback, sich entwickelnden Anforderungen und technologischen Fortschritten. Suchen Sie kontinuierlich nach Möglichkeiten, den Prozess zu optimieren, die Effizienz zu verbessern und neue Funktionen oder Funktionen zu integrieren.

Library best practices

Diese bewährten Methoden müssen beim Entwickeln einer UiPath-Bibliothek für einen Solution Accelerator befolgt werden:

• Follow the out of the box Workflow Analyzer rules. Your project should be able to be run against Workflow Analyzer and have minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • Es sollten keine hartcodierten Verzögerungen vorhanden sein.
  • Keine Aktivitäten dürfen Standardnamen haben.
  • Innerhalb eines Workflows dürfen keine Aktivitäten denselben Namen haben.
  • Argumente sollten NICHT der Namenskonvention in_, out_ und io_ folgen, da diese Argumente beim Erstellen der Bibliothek als Eigenschaften angezeigt werden. Die standardmäßige Workflow-Analyse-Regel für ungültige Argumentnamen kann beim Erstellen einer Bibliothek ignoriert werden.
  • Tief geschachtelte Aktivitäten sollten nicht vorhanden sein und für die Aufteilung des Workflows in kleinere Komponenten berücksichtigt werden.
• Jede UI-Interaktion darf nur über Object Repository erfolgen.
• Zerlegen Sie Ihre Bibliothek in kleinere, modulare Komponenten, die sich auf bestimmte Aufgaben oder Funktionalitäten konzentrieren. Das verbessert die Wiederverwendbarkeit und ermöglicht einfachere Wartung und Aktualisierungen.
• Stellen Sie eine umfassende Dokumentation für Ihre wiederverwendbare Bibliothek bereit, einschließlich Nutzungsanweisungen, Eingabe-/Ausgabebeschreibungen und etwaiger Abhängigkeiten oder Voraussetzungen. Die eindeutige Dokumentation hilft den Benutzern zu verstehen, wie die Bibliothek effektiv genutzt wird.
• Error Handling: Implement robust error handling mechanisms within the library to handle exceptions and failures gracefully. Use try-catch blocks and supply informative error messages to aid in troubleshooting.
  • Fehler müssen in den Prozessen des Solution Accelerators abgefangen und nicht in der Bibliothek verarbeitet werden
  • Alle Geschäftsausnahmen sollten eine Geschäftsregelausnahme auslösen. Alle Anwendungsausnahmen sollten eine Systemausnahme auslösen
• Bestätigen Sie Eingaben und behandeln Sie Randfälle, um sicherzustellen, dass die Bibliothek ordnungsgemäß funktioniert und unerwartete Fehler oder unerwünschte Ergebnisse verhindert. Eine richtige Eingabevalidierung verbessert die Zuverlässigkeit und Stabilität der Bibliothek.
  • Dies gilt auch für alle API-Automatisierungsausgaben.
• Testen Sie den Prozess gründlich, um seine Funktionalität und Zuverlässigkeit sicherzustellen. Verwenden Sie Testfälle und Daten, um die erwarteten Ergebnisse zu validieren und Grenzfälle zu behandeln. Dies hilft, Fehler oder Inkonsistenzen vor der Bereitstellung zu identifizieren und zu beheben.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Überprüfen und aktualisieren Sie Ihre Bibliothek regelmäßig, um Feedback zu integrieren, Fehler zu beheben und die Funktionalität basierend auf sich ändernden Anforderungen zu verbessern. Kontinuierliche Verbesserung stellt sicher, dass die Bibliothek im Laufe der Zeit relevant und effektiv bleibt.
• Wenn Sie Bibliotheken aktualisieren, sollten Sie Ihre nächste Aktualisierung unter Berücksichtigung der Abwärtskompatibilität entwerfen.

Beispiel

Nicht grundlegende Änderung: Erweitern einer Bibliothek mit einem neuen Workflow.

Potenziell grundlegende Änderung: Anpassen eines vorhandenen Workflows.

Wenn Sie sich nicht sicher sind, testen Sie die Abwärtskompatibilität mit einer Zwischenversion und verschieben Sie die Aktualisierung bei Bedarf in einen neuen Workflow oder eine neue Bibliothek, die nur von den Prozessen separat genutzt werden kann, für die die Aktualisierung erforderlich ist. Mit der Zeit kann der alte Workflow als veraltet betrachtet werden.