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	Les connecteurs Integration Service ou les connexions créés à l'aide de Connector Builder doivent être utilisés, dans la mesure du possible, pour activer l'automatisation à l'aide d'API avec une bibliothèque de connecteurs prête à l'emploi, tout en fournissant également un moyen standard de configurer et de gérer les connexions avec une authentification standardisée. 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. Si l'automatisation de l'API n'est pas possible, l'automatisation de l'IU doit être contenue dans une couche d'intégration GUI/une couche d'application, comme décrit plus en détail ci-dessous. Il doit utiliser le référentiel d’objets dans une bibliothèque d’applications.
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 Dans ces domaines, un accélérateur de solution devrait fournir un cadre structuré mais flexible pour créer une solution d'automatisation efficace et évolutive. En résumé, votre accélérateur de solution doit promouvoir la modularité, l'adaptabilité, la conformité des meilleures pratiques et une intégration facile avec les systèmes et les applications pour faciliter le développement et le déploiement rapides de l'automatisation. Pour qu'une liste soit publiée sur UiPath Marketplace, vous devez inclure dans la Description de la liste tous les détails sur les produits UiPath utilisés dans l'automatisation ou qui sont compatibles avec votre automatisation, et le rôle qu'ils jouent .

Les partenaires peuvent ne pas inclure les noms de tiers, d’applications tierces ou d’autres produits tiers dans le texte de leur liste ou de la description de leurs produits sur UiPath Marketplace sans l’autorisation explicite du tiers. Should :

Normes relatives aux accélérateurs de solution

1. Architecture en couches

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. Couche de logique métier

• 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. Couche d'application

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

Types d'architecture standard

Processus transactionnels/ basés sur des files d'attente

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.

L' infrastructure d'entreprise robotique est un modèle de projet basé sur les Machines à états. Il a été créé pour répondre à toutes les meilleures pratiques concernant la journalisation, le traitement des exceptions, l'initialisation des applications, etc. Il est ainsi prêt pour un scénario métier complexe. Le modèle contient plusieurs conteneurs State prédéfinis pour l'initialisation des applications, la récupération des données d'entrée, leur traitement et la fin de la transaction. Tous ces états sont connectés via plusieurs transitions qui couvrent pratiquement tous les besoins dans un scénario d'automatisation standard. Il existe également plusieurs workflows invoqués, chacun gérant des aspects spécifiques du projet.

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. Processus Document Understanding

La plupart des processus utilisant des documents ont en commun leur exigence de « comprendre » leur contenu. Par conséquent, une infrastructure dédiée spécialisée dans le Document Understanding a été mise en place – le Document Understanding (DU) Process Framework.

Cette infrastructure est essentiellement un modèle de projet UiPath Studio basé sur un organigramme type de traitement de document. Le processus fournit la journalisation, la gestion des erreurs, les mécanismes de nouvelle tentative et toutes les méthodes qui doivent être utilisées dans un workflow DU. Le workflow a une architecture découplée des autres automatisations connectées :

• 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)
• Logique de type Human-in-the-loop (validation) utilisant *Action Center
• pour les robots Unattended, ou une station de validation locale
• pour les éléments Attended

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 :

• Le *Réparateur
• rassemble les documents à traiter à partir de l’application ou du système en amont.
• Le *processus Document Understanding
• extrait les informations nécessaires de chaque document une à la fois avec évolutivité grâce à la méthode Sélecteur.
• Enfin, le *exécuteur
• utilise les données extraites du document pour terminer le processus.

3. Processus transactionnels avec Action Center

Cette architecture se compose de processus Réparateur – Exécuteur - Finalisateur avec un humain dans la boucle, ou de workflow de longue durée, processus quelque part au milieu. Le modèle standard pour les workflows de longue durée est le modèle de processus d'orchestration (Orchestration Process Template. Les workflows de longue durée comportent des bonnes pratiques à suivre pour prendre en charge l'orchestration des services, l'intervention humaine et les transactions de longue durée dans les environnements sans surveillance.

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. Autres 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.
• D'autres infrastructures d'automatisation telles que l' infrastructure Attended UiPath peuvent être prises en compte s'ils sont applicables au processus.

Meilleures pratiques de processus

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

• Suivez les règles prêtes à l’emploi de l’Analyseur de workflow. Lorsqu'il sera analysé à l'aide de cet outil, votre projet devrait générer un avertissement minimal voire zéro. Les conventions d'affectation de noms, les meilleures pratiques de conception, les règles de maintenabilité et de lisibilité, et les règles d'utilisation doivent être respectées. Voici quelques exemples clés de ces règles :
  • 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.
  • Pensez à utiliser UiPath Test Suite et à fournir des workflows de test pour votre automatisation.
• 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.

Meilleures pratiques des bibliothèques

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 :

• Suivez les règles prêtes à l’emploi de l’Analyseur de workflow. Votre projet doit pouvoir être exécuté selon l' analyseur de workflow et n'afficher aucun avertissement. Les conventions d'affectation de noms, les meilleures pratiques de conception, les règles de maintenabilité et de lisibilité, et les règles d'utilisation doivent être respectées. Voici quelques exemples clés de ces règles :
  • 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.
• Gestion des erreurs : implémentez des mécanismes robustes de gestion des erreurs dans la bibliothèque, afin de gérer correctement les exceptions et les défaillances. Utilisez des blocs Try-Catch et fournissez des messages d’erreur informatifs pour faciliter le dépannage.
  • 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.
  • Pensez à utiliser UiPath Test Suite et à fournir des workflows de test pour votre automatisation.
• 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.