Normes de contenu

Toutes les listes sur Marketplace doivent respecter les directives générales suivantes :

Directives	Détails (Details)
Composants modulaires et réutilisables	Les accélérateurs de solution doivent être conçus dans un souci de modularité, offrant une architecture conçue pour les modèles de processus, les modèles d'apprentissage automatique, les bibliothèques réutilisables, etc. Ces composants modulaires doivent être faciles à intégrer et à combiner pour créer des processus personnalisés destinés au cas d'utilisation spécifique initialement visé ou avoir la capacité de transférer divers composants réutilisables entre les processus. Cela devrait réduire l'effort de duplication et promouvoir la cohérence avec les directives de développement à travers les différents processus.
Paramètres et paramètres configurables	Les accélérateurs de solution doivent fournir des paramètres configurables et des paramètres qui peuvent être ajustés pour correspondre aux exigences de l'utilisateur final et à leurs besoins commerciaux. Les configurations peuvent inclure, sans s'y limiter, des variables, des seuils, des délais d'attente, des points de terminaison, des modèles d'apprentissage automatique, des bénéficiaires humains dans la boucle et d'autres paramètres ajustés pour permettre la personnalisation et l'évolutivité. Le fichier de configuration du processus, les ressources Orchestrator et les arguments de processus sont quelques-uns des moyens que vous pouvez utiliser pour réaliser la configurabilité.
Architecture évolutive et flexible	La conception de l'architecture doit être évolutive, flexible, capable de gérer diverses exigences d'automatisation et permettre une extension facile avec plus de robots ou plus de processus à mesure que les besoins de l'entreprise évoluent ou que de nouveaux cas d'utilisation apparaissent. L'architecture doit permettre l'intégration avec divers systèmes, applications et technologies trouvés dans l'industrie du cas d'utilisation. Les utilisateurs doivent pouvoir échanger facilement divers composants de l'accélérateur de solution ou en intégrer de nouveaux, en fonction des besoins de leur organisation.
Capacités d'intégration	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. L'intégration transparente avec les systèmes et applications externes rationalise l'échange de données et permet aux accélérateurs de solution de fonctionner avec l'infrastructure informatique existante, minimisant le besoin de modifications importantes ou de développements personnalisés. 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.
Extensibilité et personnalisation	Les accélérateurs de solution doivent être conçus pour être extensibles et personnalisables, permettant aux utilisateurs d'accélérateurs de solution d'adapter le workflow d'automatisation aux besoins spécifiques de leur organisation. Les accélérateurs de solution doivent être développés dans l'idée que les organisations doivent utiliser l'accélérateur de solution spécifique comme base du cas d'utilisation tout en ayant la capacité de les adapter à leurs besoins commerciaux uniques.

:::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

La conception d'un accélérateur de solution doit implémenter une séparation entre la couche de logique métier (couche d'implémentation) et la couche d'application (couche d'interaction GUI, si nécessaire). Ceci peut être réalisé directement dans les différents workflows de processus ou, si la réutilisabilité est requise, en utilisant des bibliothèques.

2. Business logic layer (implementation layer)

• Cette couche est responsable de la mise en œuvre de la logique métier de base et des workflows d’automatisation de l’ accélérateur de solution.
• Il porte sur les tâches et les processus spécifiques que l'accélérateur de solution vise à automatiser dans un domaine ou un cas d'utilisation donné.
• La couche de logique métier définit les règles, les conditions et les actions requises pour atteindre les résultats d'automatisation souhaités.
• Cela peut impliquer la manipulation de données, la prise de décisions, l'intégration avec des systèmes externes et d'autres tâches de traitement.
• Cette couche est conçue pour être modulaire et personnalisable, permettant aux organisations d’adapter l’accélérateur de solution à leurs besoins commerciaux spécifiques.
• Il utilise généralement les capacités d'automatisation UiPath, telles que les activités, les workflows et les variables, pour orchestrer le flux d'automatisation.

3. Application layer

• La couche d'application sert d'interface entre le workflow d'automatisation et le GUI (interface utilisateur graphique) ou l'API (interface de programmation d'application) des différentes applications et/ou systèmes participant au processus automatisé.
• Cette couche pourrait gérer les interactions avec les éléments de l'interface utilisateur, tels que les boutons, les champs, les menus et les boîtes de dialogue, dans les applications ou systèmes cibles. Cette couche pourrait également gérer l'implémentation de l'interface de programmation d'application dans les applications ou systèmes cibles, comme la saisie de données via la communication de code au lieu d'utiliser l'interface utilisateur de l'application.
• Cette couche peut inclure des activités et des composants qui permettent l’automatisation de l’interface utilisateur, tels que l’extraction de données d’écran, l’entrée/la sortie de données et la navigation. Cette couche peut également inclure une logique d’application pour l’implémentation par programmation des mêmes commandes.
• La couche d'application est conçue pour s'adapter à l'application cible spécifique - toute mise à jour des API ou des interfaces utilisateur doit avoir lieu en un seul endroit, puis s'adapter à toutes les implémentations de ce composant.
• La couche d'interaction GUI doit fournir la flexibilité pour gérer les variations dans les éléments d'IU, les mises en page d'écran et les chemins de navigation.
• Dans la Couche d'interaction API, la sortie de tout workflow doit être cohérente avec l'objectif du workflow. Par exemple, si votre workflow s'appelle « Récupérer tous les utilisateurs », il faut s'attendre à ce qu'une collection d'objets utilisateur soit renvoyée, et non à un JSON qu'il faudra ensuite analyser pour extraire les données utilisateur requises.
• Limitez au minimum la durée des appels d'API en utilisant la pagination et en appliquant des filtres pertinents chaque fois que ceux-ci sont implémentés par l'API cible.

Remarque :

La séparation entre une couche métier et une couche d'application garantit une distinction claire entre la logique d'automatisation et de processus par rapport aux détails spécifiques à l'application. Cela permet une architecture modulaire et évolutive dans laquelle les modifications de l'interface graphique ou de l'API peuvent être gérées séparément de la logique métier de base. Cette séparation permet de simplifier la maintenance, la réutilisation dans l' accélérateur de solution ou le transfert vers d'autres processus, ainsi que la personnalisation de l' accélérateur de solution. L'utilisateur final de l' accélérateur de solution peut facilement remplacer la couche d'application pour s'adapter aux modifications des applications cibles sans affecter la logique de processus sous-jacente. De même, la logique métier peut être modifiée ou étendue indépendamment de l'application pour répondre à l'évolution des besoins de l'entreprise.

Standard architecture types

Transactional / queue based processes

Il s’agit du modèle standard de Dispatcher-Performer. L'infrastructure d'entreprise robotique (Robotic Enterprise Framework) doit être utilisée pour la mise en œuvre d'un processus simple basé sur les transactions.

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.

Le modèle Dispatcher et Performer est une solution préconçue pour séparer les deux étapes principales d'un processus en plaçant une file d'attente entre les deux. De cette façon, la production des éléments de transaction est entièrement indépendante de leur consommation. Cet asynchronisme interrompt la dépendance temporelle entre le répartiteur et l'exécuteur.

Dans cette approche standard, un répartiteur est une automatisation pour charger des données dans une file d'attente UiPath. Il extrait des données d'une ou plusieurs sources et les utilise pour créer des éléments de file d'attente à traiter. Les informations sont transmises vers une ou plusieurs files d'attente, permettant au répartiteur d'utiliser un format commun pour toutes les données stockées dans les éléments de la file d'attente. Ces données peuvent ensuite être traitées dans une automatisation plus récente, l'assistant. L'assistant peut traiter les données selon les besoins, car les éléments de la file d'attente sont traités un par un. Il utilise la gestion des erreurs et des mécanismes de nouvelle tentative pour chaque élément traité. L'un des principaux avantages de l'exécuteur réside dans son évolutivité (plusieurs exécutables peuvent être utilisés avec une seule file d'attente).

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:

• Peu importe d'où proviennent les fichiers à traiter ou ce qui déclenche l'exécution, cela relève d'un processus en amont.
• Peu importe où les informations extraites doivent être utilisées, cela relève du processus en aval.
• L'architecture de l'infrastructure est commune à la fois aux robots Attended et Unattended :
• Logique Document Understanding (numérisation, classification, extraction de données)
• Human-in-the-loop logic (validation) using *Action Center
• for unattended robots, or a local *Validation Station
• for attended ones

Suite à ces mécanismes et architecture, la grande majorité des automatisations utilisant Document Understanding combinent généralement un modèle Dispatcher-Performer avec une infrastructure Document Understanding entre :

• 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.

Cette architecture est utilisée lorsqu'une intervention humaine est nécessaire pour approuver ou surveiller l'automatisation. Par conséquent, tous les flux après les tâches Action Center doivent prendre en compte à la fois l'acceptation et le rejet.

4. Further architectures

D’autres choix architecturaux peuvent exister et être appropriés en fonction des besoins d’automatisation :

• Un finaliseur peut toujours être pris en compte pour tout nettoyage nécessaire dans un processus.
• Un journal dont l’exécution est rarement exécutée ou qui est imprécisé peut envoyer des statistiques d’automatisation aux parties prenantes nécessaires
• Les processus d' extraction, de transformation et de chargement (ETL) pouvaient combiner des données de plusieurs sources dans un grand référentiel central.
• Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.

Process best practices

Il est nécessaire de suivre ces bonnes pratiques lors du développement d'un processus UiPath pour un accélérateur de solution :

• 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:
  • Il ne devrait pas y avoir de délais codés en dur.
  • Aucune activité ne doit avoir de noms par défaut.
  • Deux activités ne doivent pas avoir le même nom dans un workflow.
  • Les arguments doivent suivre la convention d'affectation de noms in_, out_ et io_.
  • Les activités profondément imbriquées ne devraient pas exister et doivent être considérées comme un argument solide pour diviser le workflow en composants plus petits.
• Avant de commencer le développement, analysez en détail les exigences du processus et concevez une solution qui répond aux besoins spécifiques. Décomposez le processus en tâches plus petites et identifiez les dépendances pour garantir un workflow clair et efficace.
• Identifiez les composants ou workflows réutilisables qui peuvent être facilement maintenus et réutilisés dans d'autres projets et séparez-les des étapes antérieures. Cette approche modulaire améliore la réutilisation, simplifie le débogage et facilite l'évolutivité.
• Implémentez des mécanismes de gestion des erreurs robustes pour gérer correctement les exceptions et les échecs. Utilisez des blocs try-catch et fournissez des messages d'erreur informatifs pour faciliter le dépannage et améliorer la stabilité du processus.
  • Les erreurs doivent être spécifiques et afficher un message d'erreur pertinent. Une exception de pointeur nul ne doit pas être levée si une chaîne doit être renseignée, mais elle ne doit pas être générée à la suite de la valeur de retour d'une application – l'exception doit être classée comme une exception de règle métier provoquée par l'application.
• Incorporez des paramètres configurables à votre processus, tels que des paramètres d'entrée, pour permettre la flexibilité et l'évolutivité. Cela permet aux utilisateurs de personnaliser facilement le processus en fonction de leurs besoins sans modifier le workflow de base.
• Validez les entrées pour vous assurer qu’elles répondent aux critères requis et gérez les exceptions pour les données non valides ou inattendues. Implémentez des techniques de traitement de données appropriées, telles que le nettoyage et la transformation des données, pour garantir un traitement précis et fiable.
• Intègre des mécanismes de journalisation pour capturer des informations pertinentes lors de l'exécution du processus. Cela facilite le dépannage et fournit des informations précieuses pour l'optimisation des processus. Utilisez des outils de débogage pour identifier et résoudre efficacement les problèmes.
  • Les mécanismes de journalisation pour les rapports et UiPath Insights doivent également être pris en compte.
• Testez attentivement le processus pour vous assurer de sa fonctionnalité et de sa fiabilité. Utilisez des cas de test et des données pour valider les résultats attendus et gérer les cas particuliers. Cela permet d'identifier et de corriger les erreurs ou les incohérences avant le déploiement.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Révisez et améliorez régulièrement vos processus en fonction des retours, de l'évolution des exigences et des avancées technologiques. Recherchez en permanence des opportunités d'optimisation du processus, d'amélioration de l'efficacité et d'intégration des nouvelles fonctionnalités.

Library best practices

Il est nécessaire de suivre ces bonnes pratiques lors du développement d'une bibliothèque UiPath pour un accélérateur de solution :

• 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:
  • Il ne devrait pas y avoir de délais codés en dur.
  • Aucune activité ne doit avoir de noms par défaut.
  • Aucune activité ne doit avoir le même nom dans un workflow.
  • Les arguments ne doivent PAS suivre la convention d'affectation de noms in_, out_ et io_ car ces arguments apparaîtront comme des propriétés lors de la création de la bibliothèque. La règle par défaut de l'analyseur de workflow pour les noms d'arguments non valides peut être ignorée lors de la création d'une bibliothèque.
  • Les activités profondément imbriquées ne devraient pas exister et doivent être prises en compte pour diviser le workflow en composants plus petits.
• Toute interaction de l’interface utilisateur ne doit se produire que par le biais du référentiel d’objets.
• Décomposez votre bibliothèque en composants plus petits et modulaires qui se concentrent sur des tâches ou des fonctionnalités spécifiques. Cela facilite la réutilisation et simplifie la maintenance et les mises à jour.
• Fournissez une documentation complète pour votre bibliothèque réutilisable, y compris des instructions d'utilisation, des descriptions d'entrée/de sortie, ainsi que toutes les dépendances ou prérequis. Une documentation claire aide les utilisateurs à comprendre comment utiliser efficacement la bibliothèque.
• 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.
  • Les erreurs doivent être détectées dans les processus de l'accélérateur de solution et non traitées dans la bibliothèque
  • Toutes les exceptions métier doivent générer une exception de règle métier. Toutes les exceptions d'application doivent générer une exception système
• Confirmez les entrées et gérez les cas particuliers pour vous assurer que la bibliothèque fonctionne correctement et évitez les erreurs inattendues ou les résultats indésirables. Une validation d'entrée appropriée améliore la fiabilité et la stabilité de la bibliothèque.
  • Cela s'applique également à toute sortie d'automatisation d'API.
• Testez attentivement le processus pour vous assurer de sa fonctionnalité et de sa fiabilité. Utilisez des cas de test et des données pour valider les résultats attendus et gérer les cas particuliers. Cela permet d'identifier et de corriger les erreurs ou les incohérences avant le déploiement.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Révisez et mettez à jour régulièrement votre bibliothèque pour intégrer des commentaires, résoudre les bogues et améliorer les fonctionnalités en fonction de l'évolution des besoins. L'amélioration continue garantit que la bibliothèque reste pertinente et efficace au fil du temps.
• Lors de la mise à jour des bibliothèques, concevez votre prochaine mise à jour en veillant à la rétrocompatibilité.

Exemple

Changement sans rupture : extension d'une bibliothèque avec un nouveau workflow.

Changement potentiellement radical : ajustement d'un workflow existant.

En cas de doute, testez la rétrocompatibilité avec une version intermédiaire et, si nécessaire, déplacez la mise à jour vers un nouveau workflow ou une nouvelle bibliothèque qui ne pourra être utilisée séparément que par les processus nécessitant la mise à jour. Avec le temps, l'ancien workflow peut être considéré comme obsolète.