Organisation du projet

Infrastructures de haut niveau

Commencer par une infrastructure générique (et indépendante des processus) permet de gérer n'importe quel processus de manière cohérente et structurée. Une infrastructure permet de commencer par une vue de haut niveau, puis d'explorer les détails spécifiques de chaque processus.

Le modèle Infrastructure d'entreprise robotique (Robotic Enterprise Framework) propose un aperçu détaillé flexible d'un processus répétitif et inclut un ensemble représentatif de pratiques décrites dans ce guide. Il peut être facilement utilisé comme point de départ solide pour le développement de l'automatisation des processus par la robotique (RPA) avec UiPath. Le modèle repose sur une structure Machine d'état (State Machine).

Mode de fonctionnement :

• Le Robot charge les paramètres à partir du fichier de configuration et les actifs Orchestrator, tout en les conservant dans un dictionnaire qui doit être partagé entre les workflows.
• Le Robot récupère les identifiants requis et se connecte à toutes les applications.
• Il effectue d'autres tentatives en cas d'erreurs, puis réussit ou abandonne.
• Le Robot vérifie la file d'attente d'entrée ou d'autres sources d'entrée pour démarrer une nouvelle transaction.
• Si plus aucune donnée d'entrée n'est disponible, configurez le workflow afin d'attendre et de réessayer ou de terminer le processus.
• Les interactions d'IU pour traiter les données de transaction sont exécutées.
• Si les transactions sont correctement traitées, l'état de la transaction est mis à jour et le Robot passe à la transaction suivante.
• En cas d'erreurs de validation, l'état de la transaction est mis à jour et le Robot passe à la transaction suivante.
• Si des exceptions sont générées, le Robot réessaye de traiter la transaction un certain nombre de fois (si configuré), ou marque l'élément comme échec et redémarre.

• À la fin, un e-mail est envoyé avec l'état du processus, si configuré.

  
  

  

  
  

Pour les processus basés sur une transaction (tels que le traitement de toutes les factures à partir d'un fichier Excel) qui ne sont pas exécutés via Orchestrator, des files d'attente locales peuvent être générées (à l'aide des méthodes mettre en file d'attente/supprimer de la file d'attente de .NET).

Ensuite, le flux du processus de haut niveau (gestion des exceptions, nouvelles tentatives, récupération) peut être facilement répliqué. Cela est beaucoup simple que regrouper le processus entier sous une boucle Pour chaque ligne (For Each Row).

Tous les fichiers REFrameWork, ainsi que le documentation sont disponibles sur cette page.

Principes de conception

La division des projets en workflows plus petits et l'utilisation des activités Appeler le fichier de flux de travail (Invoke Workflow File) sont primordiales pour une bonne conception de projet. Des flux de travail dédiés permettent des tests indépendants des composants, encouragent la collaboration en équipe et améliorent les performances de conception et d'exécution par rapport aux projets organisés en fichiers moins nombreux et plus volumineux. Nous vous recommandons de limiter la taille des fichiers de flux de travail à moins de 5 Mo. Les fichiers de workflow de plus de 10 Mo ne sont pas pris en charge.

Choisissez judicieusement le type de mise en page (organigrammes et séquences). En général, la logique du processus réside dans les organigrammes, tandis que la navigation et le traitement de données s'effectuent en séquences.

En développant une logique complexe dans une séquence, vous vous retrouverez dans un labyrinthe de conteneurs et de blocs décisionnels dont le suivi et la mise à jour ne sont pas simples.

Par contre, les interactions d'IU dans un organigramme compliquent la création et la gestion.

Les fichiers associés au projet (tels que les modèles d'e-mail) peuvent être organisés dans des dossiers locaux ou des lecteurs partagés.

Remarque : si placés à l'intérieur du dossier de projet, ils sont répliqués lors du processus de déploiement (avec les workflows de projets) sur toutes les machines Robot dans le dossier lib/net45.

Ces dossiers peuvent être également stockés sur un lecteur partagé de sorte que tous les Robots se connectent à la même source unique. De cette façon, les fichiers associés au processus peuvent être vérifiés et gérés entièrement par les utilisateurs professionnels, sans assistance de l'équipe RPA. En revanche, la décision (dossiers partagés ou locaux) est complexe et doit prendre en compte différents aspects liés au processus et à l'environnement : taille des fichiers, fréquence des modifications, simultanéité de modification du même fichier, stratégies de sécurité, etc.

Contrôle de code source

Afin de gérer facilement la gestion des versions des projets et de partager le travail avec davantage de développeurs, nous vous recommandons d'utiliser un système de contrôle de version. UiPath Studio est directement intégré à GIT, TFSet SVN. Vous pouvez trouver un tutoriel expliquant les étapes de connexion et les fonctionnalités ici.

Paramètres de contrôle

Pour éviter les paramètres externes de codage en dur (tels que les chemins d'accès aux fichiers, les URL, etc.) dans les workflows, nous recommandons de les conserver dans un fichier .config, (.xlsx, .xml ou .json) ou dans Orchestrator, en tant qu'actifs, s'ils changent souvent.

De manière générale, la solution finale doit être évolutive afin de permettre des variations et des modifications des données d'entrée sans intervention du développeur. Par exemple, les listes avec les clients autorisés à accéder à un certain type de transaction, les e-mails de personnes pour recevoir des notifications, etc. doivent être stockés dans des fichiers externes (tels qu'Excel) où les professionnels ou autres départements peuvent les modifier directement (ajouter/supprimer/mettre à jour).

Pour tout processus répétitif, toutes les invocations de workflows à partir de la boucle principale doivent être marquées avec l'option Isolé (Isolated) pour fournir une protection contre les pannes potentielles du Robot (telles qu'une mémoire insuffisante).

Identifiants

Aucun identifiant ne doit être stocké directement dans le workflow, mais plutôt chargé à partir d'emplacements plus sécurisés tels que le magasin d'informations d'identification Windows local ou les actifs Orchestrator. Vous pouvez les utiliser dans les workflows via l'activité Extraire l'identifiant (GetCredential).

Gestion des erreurs

Deux types d'exceptions peuvent être générés lors de l'exécution d'un processus automatisé : assez prévisibles ou totalement inattendus. En fonction de cette distinction, il existe deux manières de résoudre les exceptions, par actions explicites exécutées automatiquement dans le workflow ou en réaffectant le problème à des opérateurs humains.

Dans les cas où des exceptions peuvent être rencontrées, il est utile d'ajouter un Gestionnaire global d'exceptions (Global Exception Handler) au projet d'automatisation. Seulement ce type de workflow peut être ajouté par projet d'automatisation. Le Gestionnaire global d'exceptions n'est pas disponible pour les bibliothèques.

Le workflow peut être défini pour déterminer le comportement du workflow lorsqu'une exception est rencontrée en ignorant l'erreur et en passant à l'activité suivante, en recommençant l'activité qui a généré l'erreur, en abandonnant l'exécution ou en continuant et en générant à nouveau l'erreur.

En outre, les arguments contenus dans le Gestionnaire global d'exceptions peuvent être définis pour consigner le nom de l'activité qui a levé l'exception ou retenter l'activité un certain nombre de fois. Pour plus d'informations sur l'utilisation de ses arguments, consultez la page Gestionnaire global d'exceptions.

Comme solution de rechange au Gestionnaire global d'exceptions, la propagation des exceptions peut être contrôlée en plaçant le code sensible à l'intérieur de blocs Try/Catch où les situations peuvent être gérées de manière appropriée. Au niveau supérieur, le diagramme de processus principal doit définir des mesures correctives générales pour résoudre toutes les exceptions génériques et pour garantir l'intégrité du système.

Les gestionnaires contextuels offrent plus de flexibilité afin que les Robots s'adaptent aux différentes situations. Ils doivent être utilisés pour implémenter d'autres techniques, le nettoyage ou la personnalisation des messages de l'utilisateur/du journal. Bénéficiez du mécanisme de propagation verticale d'exceptions pour éviter des gestionnaires en double dans les sessions de capture en remontant le gestionnaire à des niveaux où il peut couvrir toutes les exceptions à un seul emplacement.

Vous devez fournir suffisamment de détails dans le message d'exception afin que l'humain le comprenne et qu'il prenne les mesures nécessaires. Les messages et les sources d'exceptions sont essentiels. La propriété source de l'objet exception indique le nom de l'activité qui a échoué (dans un workflow invoqué). Une fois de plus, l'affectation de noms est cruciale, car des noms imprécis ne fournissent aucune indication claire sur le composant qui est tombé en panne.

Comme vous le voyez ci-dessous, le choix de ne pas renommer l'activité Invocation (Invoke) rend la source de l'exception insignifiante en cas de panne (par exemple Invoquer le fichier de workflow (Invoke Workflow File) > Invoquer le fichier de workflow (Invoke Workflow File) &gt ; Invoquer le fichier de workflow (Invoke Workflow File) &gt ; Saisir dans (Type Into)).

Maintenir propre

Dans le flux de processus, assurez-vous de fermer les applications cible (navigateurs, applications) après que les Robots interagissent avec elles. Si elles restent ouvertes, elles utilisent les ressources de la machine et peuvent interférer avec les autres étapes de l'automatisation.

Avant de publier le projet, examinez une dernière fois les workflows et effectuez le nettoyage :

• Supprimez les variables non référencées.
• Supprimez les sorties Ligne d'écriture (Write Line) temporaires.
• Supprimez le code désactivé.
• Assurez-vous que l'affectation de noms est significative et unique.
• Supprimez les conteneurs inutiles (Cliquer droit (Right-click) > Supprimer la séquence (Remove Sequence)).

Le nom du projet est également important. Il s'agit de la manière dont le processus est perçu dans Orchestrator. Il doit donc être conforme aux règles internes d'affectation de noms. Par défaut, l'ID de projet est le nom de projet initial. Mais, vous pouvez le modifier dans le fichier project.json.

La description du projet est également importante (elle s'affiche dans Orchestrator). Elle permet de différencier plus facilement les processus. Par conséquent, choisissez également une description significative.

Réutilisation du code

Lors du développement, nous devons souvent automatiser les mêmes étapes dans plus d'un workflow/projet. Par conséquent, il est pratique courante de créer des workflows qui contiennent des petits éléments d'automatisation et de les ajouter à la bibliothèque.

Il n'existe aucune recette universelle qui indique comment fractionner des processus donnés.

Cependant, la séparation de la logique métier des composants d'automatisation est un bon principe qui permet de créer un code qui peut être réutilisé efficacement.

Exemple

Supposons qu'une partie de votre processus requiert la lecture des informations du client. Ensuite, selon ces informations et les règles métier internes, mettez à jour les détails du client.

Extraire les informations du client (Get Customer Info) et Modifier les informations du client (Change Customer Info) doivent être deux composants d'automatisation distincts, complètement indépendants des processus. La logique (mettez à jour le type de client uniquement lorsque le nombre total est supérieur à 100 000 dans les 12 derniers mois) doit être indépendante de l'automatisation. Les deux composants peuvent être utilisés ultérieurement, séparément, dans le même projet ou dans un autre, avec une logique différente; Si nécessaire, des données spécifiques peuvent être envoyées à ces composants via des arguments.

Modifier les informations du client (Change Customer Info) ne doit pas être invoqué depuis Extraire les informations du client (Get Customer Info), car cela complique le test, la gestion et la réutilisation des exceptions.

Remarque : utilisez des composants distincts pour Extraire des informations (Get Info) et Modifier des informations (Change Info).

Lorsque la séparation entre les actions n'est pas évidente, le copier et coller du code existant d'un workflow vers un autre (ou d'un projet vers un autre) est également une bonne indication que vous devez créer un composant (workflow) distinct pour le code et l'invoquer, au besoin.

Où stocker les composants réutilisables

Glisser et déplacer le code existant de la bibliothèque vers un workflow est plus simple que recréer entièrement le code plusieurs fois. La gestion des données (tri, filtrage) ou du texte (fractionnement, modèles Regex) sont des exemples d'éléments qui peuvent être ajoutés à la bibliothèque type. Veuillez prendre en compte qu'une fois le code ajouté au workflow, il devient statique. Si vous mettez à jour ainsi le workflow dans la bibliothèque, il ne sera pas reflété dans les processus opérationnels existants.

Les composants courants (réutilisables) (tels que Navigation dans l'appli, Connexion, Initialisation) sont mieux stockés et gérés séparément sur des lecteurs partagés en réseau. À partir de ce lecteur, ils peuvent être invoqués par des Robots différents, à partir de processus différents. Le principal avantage de cette méthode est que les modifications apportées dans le composant principal s'appliquent immédiatement dans tous les processus qui l'utilisent.

Attention : les projets Windows et multiplate-forme ne prennent pas en charge l'appel des fichiers .xaml et .cs en dehors de l'emplacement du projet.

Comment vérifier l'automatisation de qualité

• Modularité :

  • La séparation des problèmes avec des workflows dédiés permet un développement et des tests très précis.
  • Extrayez et partagez des composants ou workflows réutilisables entre des projets.

• Maintenabilité :

  • Normes correctes de structure et de développement.

• Lisibilité :

  • Structure de processus standardisée encourageant des pratiques de développement claires ;
  • Noms significatifs pour les fichiers de workflow, les activités, les arguments et les variables.

• Flexibilité :

  • Le stockage des paramètres d'environnement dans des fichiers de configuration externes ou des instances d'Orchestrator simplifie l'exécution de l'automatisation dans les environnements de test et de production.

• Fiabilité :

  • Gestion des exceptions et rapports d'erreurs :
  • Mise à jour de l'avancement de l'exécution en temps réel.

• Évolutif :

  • Prêt pour l'incorporation de nouveaux cas d'utilisation.