Infrastructure d’automatisation UiPath®

Remarque :

Accessibilité améliorée : localisation du contenu des activités

Nous travaillons toujours en permanence pour améliorer votre expérience et rendre nos ressources plus conviviales.

Nous avons réorganisé notre guide du Développeur et déplacé les activités vers le nouveau guide Activités Communications Mining™ . Vous avez désormais un accès plus facile et une navigation améliorée.

Nous espérons que ce changement optimise votre expérience et vous aide à trouver les informations nécessaires plus efficacement. Nous apprécions vos commentaires et nous sommes impatients de vous aider à poursuivre le succès de notre plate-forme.

Vue d'ensemble (Overview)

L’infrastructure du répartiteur de Communications Mining™ est un modèle UiPath® Studio que vous pouvez utiliser lors de l’intégration de Communications Mining aux implémentations RPA. Son objectif est de prendre les commentaires d’un flux Communications Mining et de les ajouter une par une dans une ou plusieurs files d’attente de références uniques UiPath Orchestrator. Vous devez définir une file d’attente pour chaque processus en aval ayant besoin des données d’un flux comme entrée. Par défaut, dans le fichier de configuration, nous avons configuré deux files d'attente de processus (pour le processus A et B) et une générique, mais vous pouvez en configurer autant que vous le souhaitez.

Vous pouvez obtenir l'infrastructure depuis Studio, sous Modèles, en recherchant Communications Mining Dispatcher.

Important : lors de la création de vos files d'attente, sélectionnez l'option Appliquer des références uniques .

Le modèle est basé sur l'infrastructure d'entreprise robotique (REFramework), couvrant toutes les meilleures pratiques essentielles des projets RPA, telles que la configuration flexible via le fichier Config.xlsx, la gestion des exceptions, les mécanismes de nouvelle tentative et la journalisation significative.

Remarque : avant de travailler avec le répartiteur de Communications Mining, veillez à consulter la documentation officielle de REFramework, si vous ne la connaissez pas.

À partir d'un projet REFramework, nous avons encapsulé les deux opérations clés qui doivent être effectuées lors de la consommation de données à partir d'un flux Communications Mining : la récupération et l'avancement. La récupération est le processus d'extraction des données d'un flux Communications Mining, et l'avancement consiste essentiellement à marquer les commentaires comme lus afin que nous ne renvoyions pas les mêmes lors de la prochaine récupération. Nous les aborderons plus en détail dans la section suivante.

Par défaut, l’infrastructure arrête le cycle de récupération et de progression lorsqu’il passe la fin du flux, c’est-à-dire lorsque le flux ne contient plus de commentaires non lus. Vous pouvez cependant configurer l’infrastructure pour qu’elle s’exécute en continu, même lorsqu’elle atteint la fin du flux. Pour ce faire, vous pouvez marquer le paramètre ExitOnVideFlux comme False dans le fichier Config.xlsx. Ce paramètre permet à l'infrastructure de fonctionner à l'infini, et chaque fois que de nouvelles données seront disponibles dans le flux, il les traitera instantanément, sans avoir à attendre l'exécution du processus de l'infrastructure.

L'objectif est que les commentaires soient disponibles dans une file d'attente Orchestrator utilisable, un élément de la file d'attente par commentaire, contenant leurs données correspondantes et les libellés prévus et les champs généraux. De cette façon, les automatisations en aval auront accès aux informations prédites.

La communication n’est pas ajoutée à sa file d’attente correspondante sans passer par les règles de validation. Il existe déjà des règles de validation de base définies dans l'infrastructure, principalement pour comprendre à quel processus appartient chaque élément, mais vous pouvez ajouter vos propres algorithmes de validation dans le code. Par exemple, dans le fichier Config.xlsx, nous avons des paramètres de validation distincts pour chaque processus d'automatisation en aval, c'est-à-dire, ValidationsProcessus et ValidationsProcessus. Dans la mesure où ils ont été configurés uniquement à titre d'exemples de processus théoriques, n'hésitez pas à ajouter vos propres feuilles et paramètres.

Important :

• Assurez-vous que vous n'avez pas plusieurs paramètres portant le même nom dans le fichier de configuration, même s'ils se trouvent sur des feuilles différentes. Ils seront tous ajoutés au même dictionnaire de configuration et se remplaceront.

  Dans le fichier, nous avons proposé quelques exemples de conventions d'affectation de noms pour les paramètres de validation qui pourraient être utiles. La logique du workflow qui vérifie les règles de validation suit les mêmes conventions, alors soyez prudent lorsque vous implémentez la vôtre, au cas où vous souhaiteriez les modifier.

  Si la validation échoue, les informations sont ajoutées à une file d'attente Human-in-the-loop, qui nécessite également des références uniques, afin que l'utilisateur puisse valider dans Action Center. Vous pouvez ajouter le nom de votre file d’attente Human-in-the-loop dans le fichier Config.

• Il est recommandé de définir un déclencheur sur la file d'attente Human-in-the-loop, qui démarre un nouveau processus d'orchestration pour chaque nouvel élément, créant une tâche dans Action Center. La tâche contient les données récupérées à partir de Communications Mining pour l’élément actuel, et l’utilisateur doit les valider avant de les envoyer dans sa file d’attente de processus d’automatisation en aval correspondante.

Flux

Après avoir entraîné avec succès un modèle dans Communications Mining™, nous pouvons créer un nouveau flux et configurer les seuils pour chacun des concepts que nous avons entraînés. Un flux définit une collection de commentaires dans un ensemble de données. Il permet une itération persistante et détaillée à travers les commentaires, avec des libellés et des champs généraux prévus, calculés à l’aide d’une version de modèle donnée.

Remarque :

Nous vous recommandons de suivre la documentation et l' Académie officielles de Communications Mining pour connaître les étapes de formation du modèle et les détails sur tous les concepts concernés.

L’intégration de UiPath® Studio à Communications Mining consiste à utiliser chacun des commentaires du flux Communications Mining. Chacune des prédictions de la communication peut ensuite être utilisée dans un ou plusieurs processus en aval. Le diagramme ci-dessous présente l'intégration générique UiPath et Communications Mining comme suit :

Notre approche recommande que pour les automatisations, n + 1 processus soient configurés dans UiPath : n Processus RPA et un flux de file d'attente. Un seul processus de flux est introduit, qui est chargé de lire les communications structurées hors du flux de Communications Mining et de les distribuer aux processus RPA pertinents par le biais de files d'attente Orchestrator. Toutes les exceptions qui peuvent survenir en raison de l’extraction par Communications Mining peuvent ensuite être marquées pour une validation humaine manuelle. Les processus qui extraient les éléments des files d'attente seront des automatisations UiPath standard qui lisent leurs données d'entrée à partir des données de l'élément de la file d'attente. L’infrastructure de répartiteur fournie remplit le rôle de flux de travail.

Boucle Récupérer-Avancer

Pour consommer les commentaires d’un flux, notre infrastructure doit implémenter la boucle Récupérer et Avancé, qui est décrite comme suit :

1. Chaque flux a un commentaire actuel :
   
   

   

   
   
2. Nous pouvons récupérer les commentaires à partir de ce commentaire actuel. Dans l'image suivante, nous récupérons deux commentaires :
   
   

   

   
   
3. Chaque commentaire renvoyé à partir d'un flux aura une sequence_id:

   {
      "comment":{
         "messages":[ ... ],
         "user_properties":{ ... },
         "id":"comment 1"
      },
      "entities":[ ... ],
      "labels":[ ... ],
      "sequence_id":"ABC123"
   }

4. Nous pouvons utiliser ce sequence_id pour faire passer le commentaire actuel au suivant dans la file d'attente. Désormais, lorsque nous récupérons 2, nous renvoyons les commentaires 2 et 3 :
   
   

   

   
   

L'infrastructure Communications Mining implémente cette boucle de récupération et d'avance pour vous.

Vue d'ensemble de l'infrastructure du répartiteur

En modifiant simplement les paramètres nécessaires, vous pouvez configurer l'infrastructure du répartiteur pour utiliser les commentaires de votre propre flux, ce qui permet d'économiser du temps d'implémentation et de garantir que les meilleures pratiques sont suivies.

Tout comme le REFramework, il peut être utilisé exactement tel quel, en tant que solution Plug And And Plug, car sans aucune modification du code, il obtient chacun des commentaires du défini (en tant qu'objets de type CommunicationsMining.Result, définis dans le paquet CommunicationsMining ), et ajoute leurs données dans une file d'attente correspondante. Alternativement, elle peut être entièrement personnalisée et vous pouvez ajouter votre propre logique selon vos besoins (les règles de validation des prédictions Communications Mining™, par exemple).

L’ Communications Mining Dispatcher Framework utilise l’approche Récupérer et Boucle avancée comme décrit précédemment, et nous pouvons faire progresser un commentaire à la fois, ou un lot de commentaires à la fois. N'oubliez pas que le répartiteur est utilisé comme flux d'un ou plusieurs processus en aval. Par conséquent, dans le fichier de configuration, nous définissons également la file d'attente correspondante pour chacun de ces processus et les règles pour ajouter l'élément à la file d'attente.

Les étapes globales sont les suivantes :

• Nous récupérons un premier lot de commentaires. Cela renverra un lot de commentaires du flux Communications Mining, le sequence_id du dernier élément du lot et le nombre d'éléments filtrés dans le lot actuel.
• Si aucune exception ne s'est produite (nous nous sommes connectés avec succès au flux) et que nous ne sommes pas à la fin du flux, nous vérifions s'il reste des éléments à traiter dans le lot actuel (nous pouvons même récupérer des lots sans commentaires, s'il y en a des filtres appliqués dans Communications Mining pour le flux actuel, et aucun des commentaires du lot actuel ne s'applique).
• S'il y a des éléments à traiter, nous les traitons un par un : en fonction du processus RPA consommateur auquel l'élément actuel appartient, nous vérifions les règles de validation des données de l'élément.
• Si l'élément réussit les vérifications, nous ajoutons un nouvel élément de file d'attente à la file d'attente concernée. L'identifiant du commentaire sera défini comme référence de l'élément de la file d'attente. S'il ne respecte pas les règles de validation, nous ajoutons un élément de file d'attente à la file d'attente HitL. Chaque élément de file d’attente créé contiendra toutes les prédictions de champ général et de libellé du commentaire à utiliser dans les processus en aval.
• Une fois que chaque élément du lot actuel a été traité, nous faisons d'abord progresser le flux (en utilisant le sequence_id du dernier élément du lot), puis nous récupérons un nouveau lot à partir du flux.
• Si nous sommes à la fin du flux (car nous n'avons récupéré aucun commentaire dans le lot et il n'y a aucun commentaire filtré), nous savons que nous avons dépassé la fin du flux et que le traitement se termine.

Configuration

Tous les paramètres nécessaires pour configurer le répartiteur se trouvent dans le fichier Data/Config.xlsx.

Remarque : Assurez-vous d'ajouter toutes les ressources correspondantes à Orchestrator.

Les paramètres et feuilles de ressources

Nom	DESCRIPTION
OrchestratorProcessAQueueName	Il s'agit de la file d'attente où notre répartiteur transmettra les commentaires VALID pour qu'ils soient traités par le processus consommateur RPA A.
OrchestratorProcessBQueueName	Il s'agit de la file d'attente où notre répartiteur transmettra les commentaires VALID pour qu'ils soient traités par le processus consommateur RPA B.
OrchestratorHITLQueueNameA	Il s'agit de la file d'attente où notre répartiteur transmettra les commentaires qui n'ont pas transmis les règles de validation définies pour leur processus correspondant. La file d’attente HITL sera traitée par le processus d’orchestration de Human In The Loop, qui crée des actions de validation pour chacun des éléments de file d’attente ajoutés.
OrchestratorGeneralQueueName	Il s'agit de la file d'attente où notre répartiteur transmettra les commentaires qui n'ont pas été catégorisés pour un processus de consommation RPA spécifique.
Communications MiningApiTokenCredential	Le jeton API Communications Mining™ nécessaire pour récupérer le flux et progresser dans le flux, stocké dans une ressource d’informations d’identification.
ExitOnEmptyStream	Si ce paramètre est défini sur False, l'infrastructure fonctionnera en continu, même lorsque nous atteignons la fin du flux.

Chacune des feuilles de validation de processus

Nom	DESCRIPTION
{ProcessName}_Label	La convention d'affectation de noms du paramètre est le libellé qui marque un commentaire comme étant désigné pour être géré par le processus actuel + le mot-clé « _ »+ « Libellé ». Sa valeur est le nom du processus en aval. Exemple : Nom Policy_Label, Valeur ProcessA.

Étant donné que le répartiteur peut remplir des files d’attente d’entrée pour un ou plusieurs processus en aval, nous proposons que vous créiez une nouvelle feuille dans le fichier de configuration pour chacun des processus, dans lequel vous définirez les règles de validation de ce processus. La convention d'affectation de noms de la feuille doit être : « {ProcessName}Validations ». Par défaut, le fichier de configuration contient 2 feuilles de validation pour le processus A et le processus B.

Gestion des exceptions

Le framework collecte toutes les exceptions qui se produisent lors du traitement de chacun des éléments de transaction (commentaires Communications Mining™) dans deux DataTables : une pour les exceptions système et une autre pour les exceptions de règles métier.

Dans l' État de fin du processus (End Process State), vous pouvez utiliser les tables de gestion des exceptions selon votre logique métier (créer des fichiers Excel avec elles, les envoyer en joint à un e-mail de signalement, etc.).

Architecture

Dépendances

Nous avons créé des activités personnalisées qui gèrent les principales opérations qui pourraient être effectuées à partir de UiPath® dans le cadre de l’intégration à Communications Mining™ : Récupérer le flux, Avancer le flux. En outre, les transactions de l'infrastructure sont de type CommunicationsMining.Result, un type de données défini dans le package qui contiendra toutes les informations définies pour chaque commentaire et ses libellés et champs généraux prévus correspondants.

You need to have the CommunicationsMining package in one of your feeds, in order for the Dispatcher Framework to load correctly, downloaded from the Marketplace: here.

États

Étant donné que Framework est fondamentalement un REFramework, il s'agit d'une machine d'état avec les mêmes états. Veuillez consulter la documentation REFramework pour plus de détails sur chaque état.

La seule modification apportée est l’ajout de la transition avancée du flux (Advanced Stream Transition) entre l’état Obtenir les données de transaction (Get Transaction Data) et l’état Process Transaction (Process Transaction State). S'il n'y a pas d'éléments à traiter dans le lot actuellement récupéré, l'exécution revient à l'état GetTransactionData pour progresser davantage dans le flux.

Variables partagées

Les variables ci-dessous sont déclarées dans le fichier Main.xaml et partagées en tant qu'arguments aux workflows invoqués dans l'infrastructure ou elles décident simplement du flux d'exécution à travers l'infrastructure :

Nom de variable	DESCRIPTION
ShouldStop(Boolean)	True lorsque la tâche est arrêtée de force (à partir d'Orchestrator).
TransactionItem(CommunicationsMining.Result)	L'élément de transaction est représenté par un commentaire du flux Communications Mining. Nous traitons un élément à la fois et ajoutons ses données à la file d'attente correspondante.
SystemException(Exception)	Utilisé lors des transitions entre les états pour représenter des exceptions autres que les exceptions métier.
BusinessException(BusinessRuleException)	Utilisé lors des transitions entre les états et représente une situation non conforme aux règles du processus en cours d'automatisation.
TransactionNumber(Int32)	Compteur séquentiel des éléments de transaction.
Config(Dictionary(String,Object))	Dictionary structure to store configuration data of the process (settings, constants, assets and Validation properties).
RetryNumber(Int32)	Utilisé pour contrôler le nombre de nouvelles tentatives de traitement des transactions en cas d'exceptions système.
TransactionData(IList(CommunicationsMining.Result))	Le lot de commentaires actuellement récupéré à partir du flux, par la dernière Récupération (Fetch).
ConsecutiveSystemExceptions(Int32)	Utilisé pour contrôler le nombre d'exceptions système consécutives.
BusinessExceptionsDT(DataTable)	Table contenant des détails sur les BusinessRulesExceptions survenues lors du traitement des transactions. Une ligne contient des informations sur une transaction défectueuse.
ApplicationExceptionsDT(DataTable)	Table with details on the System Exceptions occurred during the processing of the Transactions. One row contains info about one faulty transaction
GlobalRetryInterval(TimeSpan)	L’intervalle de nouvelle tentative global défini par défaut pour chaque étendue de nouvelle tentative dans l’infrastructure.
GlobalMaxAttempts(Int32)	The global number of Max Attempts set by default for every Retry Scope in the Framework.
CurrentSequenceId(String)	L'ID de séquence récupéré par la dernière extraction d'un lot de flux. Il s'agit de l'ID de séquence du dernier élément du lot de flux actuel.
CurrentBatchFilteredResults(Int32)	Le nombre d'éléments qui ne correspondent pas au filtre défini pour le flux dans Communications Mining et qui ont été filtrés par la dernière valeur Récupérer (filtrer hors du Lot récupéré actuel).
CommunicationsMiningApiToken(SecureString)	Le jeton d'API défini dans Communications Mining. Sa valeur doit être stockée dans une ressource d'informations d'identification dans Orchestrator.
CurrentBatchNumber(Int32)	Il est recommandé de diviser votre flux en plusieurs lots (pour réduire les performances de récupération des données). Cela nous indiquera le lot en cours de traitement.
ShouldAdvanceTheStream(Boolean)	S'il n'y a pas d'éléments à traiter dans le lot actuellement récupéré, l'exécution revient à l'état GetTransactionData pour progresser dans le flux.

Workflows spécifiques à Communications Mining™

Nom du workflow	DESCRIPTION
GetNextStreamBatch	Nous essayons d’obtenir le prochain commentaire sur le flux de Communications Mining™. L’activité Récupérer le flux se connectera à Communications Mining et remplira l’objet de sortie Récupérer avec :- la collection de résultats (de la taille que nous avons demandée)- l’ID de séquence du lot actuel ) : le nombre de commentaires filtrés. L'activité Récupérer effectue une requête HTTPs pour Communications Mining Communications Mining
AdvanceStreamBatch	Nous essayons de faire progresser le flux de commentaires CommunicationsMining. L'activité Advanced Stream se connectera à CommunicationsMining et, en utilisant comme entrée l'ID de séquence de l'un des commentaires du flux, elle marquera les commentaires (avant et en incluant celui avec l'ID de séquence donné) comme lus dans le flux afin que nous ne renvoyez pas les mêmes la prochaine fois que nous récupérons à partir d'un flux. Si vous récupérez plusieurs fois de suite sans faire progresser un flux, vous obtiendrez toujours les mêmes e-mails.L'activité Advanced effectue une requête HTTPs pour CommunicationsMining.
GetTransactionData	Récupère un élément de transaction à partir d'un tableau de commentaires. Comme il y a plusieurs transactions, nous utilisons l'argument in_TransactionNumber comme index pour récupérer la transaction correcte à traiter. S'il n'y a plus de transactions dans le lot actuel, nous devons faire avancer le flux et récupérer le prochain lot. Si nous récupérons plusieurs fois de suite sans faire progresser de flux, vous obtiendrez les mêmes résultats à chaque fois. S'il y a des éléments dans le lot et qu'il en reste encore à traiter, nous prenons l'instance du prochain élément de transaction du lot. Sinon, nous signalons le fait qu'il n'y a plus d'éléments à traiter dans le lot actuel et que nous devons faire avancer le flux. Nous ne définissons pas io_TransactionItem sur rien ici car cela arrêterait le traitement de l'ensemble de l'infrastructure, et peut-être qu'il y a encore des éléments dans les prochains lots. La condition top est définie dans l'état Get Transaction Data
CheckValidationRules	Il s'agit d'un exemple d'algorithme de validation de base qui détermine si les prédictions sont valides uniquement sur le nombre de libellés prédits pour l'élément actuel. Si nous avons un libellé, nous avons une validation réussie et il nous suffit d'obtenir le nom du processus en aval à partir du fichier de configuration. Si nous avons plusieurs libellés, la validation automatique est définie comme infructueuse. Ajoutez votre propre logique pour décider du nom du processus de consommation et si les prédictions sur les éléments sont valides OU nécessitent une validation humaine. Si nous n'avons prédit qu'un seul libellé pour l'élément actuel, nous devons obtenir le nom de son processus correspondant. Nous prenons le nom du processus en aval (consommateur) du fichier Config, en fonction de cette étiquette ONE prédite pour l'élément actuel. Dans le fichier Config, la convention d'affectation de noms du paramètre de nom de processus est : Le libellé du commentaire + Le mot-clé "_"+"Label". S'il était prévu que l'élément actuel ait plusieurs libellés, nous avons besoin que l'humain décide comment procéder à l'automatisation en aval. Ainsi, le succès de la validation automatique doit être marqué comme false afin que l'élément actuel soit ajouté à l'humain dans la file d'attente de boucle pour une validation manuelle ultérieure.
CreateDictionaryFromCommunicationsMiningItem	Nous devrons ajouter les informations extraites de CommunicationsMining pour l'élément actuel à une file d'attente. Nous créons donc un dictionnaire basé sur celui-ci. Nous utiliserons le dictionnaire pour ajouter les propriétés de définition du nouvel élément de file d’attente.
AddTransactionItemToQueue	Ajout d'un élément à la file d'attente. Toutes ses propriétés doivent déjà être configurées dans le dictionnaire in_QueueItemProperties. Assurez-vous que la case Appliquer les références uniques (Enforce unique references) est cochée dans votre file d'attente.
Processus (Process)	L'objectif du répartiteur est de remplir les files d'attente correspondantes avec les informations obtenues dans Communications Mining™ pour chacun des éléments afin qu'ils puissent être traités par les processus consommateurs dans l'automatisation en aval. Dans ce workflow, nous devons ajouter l'élément actuel à sa file d'attente correspondante. Étapes : 1. Nous créons un dictionnaire basé sur l'objet ÉlémentTransaction. Nous utiliserons le dictionnaire pour ajouter les propriétés de définition du nouvel élément de file d’attente.2. Sur la base des informations obtenues dans Communications Mining pour l'élément actuel, nous décidons son processus consommateur correspondant et vérifions les règles de validation par rapport aux données prévues.3. Si la validation réussit, nous ajoutons l'élément à la file d'attente du processus consommateur. Sinon, nous l'ajoutons à la file d'attente Human in the loop, pour être validée et potentiellement traitée par un humain. Pour la transaction actuelle :- Si une exception BusinessRuleException est levée, la transaction est ignorée.- Si un autre type d'exception se produit, la transaction en cours peut être réessayée.
ExceptionsHandler	Ce workflow doit être utilisé comme gestionnaire d'exceptions final dans l'infrastructure. Si les tables de données d'entrée sont renseignées, elles contiennent des détails sur toutes les exceptions d'application et/ou de règles métier qui se sont produites pendant l'exécution en cours du processus.

Utilisation de l'infrastructure

Avant d’utiliser l’infrastructure :

• Assurez-vous de configurer toutes les ressources requises dans Orchestrator et apportez les modifications nécessaires dans le fichier Data/Config.xlsx.
• Assurez-vous que les files d'attente dans lesquelles vous ajouterez les éléments existent dans Orchestrator et qu'elles ont la case à cocher « Enforce unique references » cochée pour éviter d'ajouter des doublons à la file d'attente et de traiter le même élément plusieurs fois dans les automatisations en aval.
• Ajoutez vos propres règles de validation dans Communications Mining/CheckValidationRules.xaml. Pour le moment, nous vérifions uniquement si l'élément actuel a plusieurs libellés prévus. Si oui, la validation échoue. Sinon, nous prenons le Nom du processus (Process Name) correspondant à l'élément actuel, en fonction de son libellé.