Normes de qualité du 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 prédéfinis ou les connexions créées à l'aide du générateur de connecteurs doivent être utilisés, dans la mesure du possible, pour permettre l'automatisation à l'aide d'API avec une bibliothèque de connecteurs prête à l'emploi tout en fournissant également une méthode standard de configuration et de gestion des 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'interface utilisateur doit être contenue dans une couche d'intégration/une couche d'application GUI comme décrit plus loin. Cela doit utiliser le référentiel d'objets dans une bibliothèque d'application.
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.

Remarque :

À travers ces zones, un accélérateur de solution doit fournir une infrastructure structurée 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'évolutivité, la conformité aux meilleures pratiques et une intégration facile aux systèmes et applications pour faciliter le développement et le déploiement rapides de l'automatisation.

Attention :

Pour qu’une liste soit publiée sur UiPath Marketplace, vous devez inclure dans la Description (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 ne peuvent pas inclure les noms de tiers ou d'applications de tiers ou d'autres produits tiers dans le texte de leur liste ou description de produit sur UiPath Marketplace sans l'autorisation expresse du tiers.

Normes pour les 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 (couche d'implémentation)

• 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 la file 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 ( Robotic Enterprise Framework) est un modèle de projet basé sur les Machines à états (State Machines). 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 prêt pour gérer 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 l’exigence liée à la « compréhension » de leur contenu. Par conséquent, une infrastructure dédiée spécialisée dans Document Understanding a été mise en place : l' infrastructure de processus Document Understanding (DU) (Document Understanding (DU) Process Framework).

Cette infrastructure est essentiellement un modèle de projet UiPath Studio basé sur un organigramme de traitement de documents standard. 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 d'intervention humaine (validation) à l'aide d'Action Center pour les robots Unattended, ou d'une station de validation locale pour les robots 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épartiteur 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 un par un avec évolutivité grâce à la méthode du répartiteur.

• Enfin, l’ assistant utilise les données extraites du document pour terminer le processus.

3. Processus transactionnels avec Action Center

Cette architecture se compose de processus Dispatcher – Performer - Finalizer 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. Les workflows de longue durée ont de meilleures pratiques qui doivent être suivies pour prendre en charge l'orchestration des services, l'intervention humaine et les transactions de longue durée dans des 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. Architectures supplémentaires

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' UiPath Attended Framework peuvent être prises en compte si elles 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 de l'analyseur de workflow prêtes à l'emploi. Lorsqu'il est analysé avec cet outil, votre projet devrait générer des avertissements minimaux, voire nuls. Les conventions de nommage, 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.

  • Envisagez d'utiliser UiPath Test Suite et de 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.

Bonnes pratiques de bibliothèque

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 de l'analyseur de workflow prêtes à l'emploi. Votre projet doit pouvoir être exécuté sur l'analyseur de workflow et comporter des avertissements minimaux, voire nuls. Les conventions de nommage, 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 (Error Handling) : implémentez des mécanismes de gestion des erreurs robustes dans la bibliothèque pour gérer avec succès les exceptions et les échecs. 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.

  • Envisagez d'utiliser UiPath Test Suite et de 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.