Infrastructure d’automatisation UiPath®

Configurez le Communications Mining Dispatcher Framework, un modèle UiPath Studio permettant de créer des workflows d’automatisation qui utilisent les données de Communications Mining.

Remarque :

Le contenu des activités a été déplacé vers le guide Activités Communications Mining™ .

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 avec des 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 en tant qu'entrée. Par défaut, dans le fichier de configuration, nous avons configuré deux files d'attente de processus (pour les processus A et B), et une file d'attente 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 Dispatcher 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'elle dépasse la fin du flux, c'est-à-dire lorsque le flux ne contient plus de commentaires non lus. Cependant, vous pouvez 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 ExitOnVideStream comme False dans le fichier Config.xlsx.

Ce paramètre permet à l'infrastructure de réaliser des cycles indéfiniment, et chaque fois que de nouvelles données seront disponibles dans le flux, il les traitera instantanément, sans qu'il soit nécessaire d'attendre que le processus de l'infrastructure soit planifié pour s'exécuter.

Sortie de la file d'attente

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.

Règles de validation

La communication n’est pas ajoutée à sa file d’attente correspondante sans passer les règles de validation. Certaines règles de validation de base sont déjà définies dans l'infrastructure, principalement pour comprendre le processus auquel appartient chaque élément, mais vous pouvez ajouter vos propres algorithmes de validation dans le code.

De plus, à titre d'exemple, dans le fichier Config.xlsx, nous avons des feuilles de paramètres de validation distinctes pour chaque processus d'automatisation en aval, c'est-à-dire ProcessAvalidations et ProcessBValidations. Comme ils ont été configurés à titre d'exemples de processus théoriques, n'hésitez pas à ajouter vos propres feuilles et paramètres.

Important :

• Assurez-vous de ne pas avoir plusieurs paramètres avec 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 les uns les autres. Dans le fichier, nous avons offert quelques exemples de conventions d'affectation de noms pour les paramètres de validation qui pourraient être utiles. La logique dans le workflow qui vérifie les règles de validation suit les mêmes conventions, vous êtes donc prudent lorsque vous implémentez les vôtres, au cas où vous souhaiteriez les modifier. Si la validation échoue, les informations sont ajoutées à une file d’attente d’intervention humaine, ce qui nécessite également des références uniques, permettant à un humain de valider dans Action Center. Vous pouvez ajouter le nom de votre file d'attente d'intervention humaine dans le fichier de configuration. Configurer le fichier, 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 les uns les autres.

  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 d’intervention humaine, ce qui nécessite également des références uniques, permettant à un humain de valider dans Action Center. Vous pouvez ajouter le nom de votre file d'attente d'intervention humaine dans le fichier de configuration.

• Il est recommandé de définir un déclencheur dans la file d'attente d'intervention humaine, ce qui lance un nouveau processus d'orchestration pour chaque nouvel élément, créant ainsi une tâche dans Action Center. La tâche contiendrait les données extraites de Communications Mining pour l’élément actuel, et l’humain doit la valider avant de l’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 avec 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. Dans le diagramme ci-dessous, l'intégration générique d'UiPath et de Communications Mining est décrite:

Notre approche recommande que pour n automatisations, n + 1 processus soient configurés dans UiPath: n Processus RPA et un flux de file d’attente. Un processus de flux unique est introduit, lequel 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 des files d'attente Orchestrator.

Toutes les exceptions qui peuvent survenir en raison de l’extraction par Communications Mining peuvent être ensuite marquées pour la Validation humaine manuelle. Les processus permettant d'extraire 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 du répartiteur fournie remplit le rôle du fluxeur de file d’attente.

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 REFramework, il peut être utilisé exactement tel quel, en tant que solution plug-and-play.

Vous pouvez l'utiliser comme tel, car sans aucune modification au code (simple ajout de vos paramètres dans le fichier Excel de configuration), il obtient chacun des commentaires du flux défini (comme les objets de type CommunicationsMining.Result, définis dans Communications Mining dans le package) et ajoute ses données dans une file d'attente correspondante. Pour plus d'informations, consultez la section Dépendances.

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’infrastructure du répartiteur de Communications Mining Dispatcher Framework utilise l’approche Récupérer et progresser en boucle comme décrit précédemment, et nous pouvons faire progresser un commentaire à la fois ou un lot de commentaires à la fois (nous pouvons configurer la taille du lot dans le fichier Config).

N'oubliez pas que le répartiteur est utilisé comme flux de 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.

Pour que l'infrastructure du répartiteur se charge correctement, téléchargée depuis la Marketplace UiPath, vous devez disposer du package CommunicationsMining dans l'un de vos flux.

É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 avec les workflows invoqués dans l'infrastructure, ou décident simplement du flux d'exécution via 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 provenant 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 extraction (filtrés hors du lot extrait 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 flux de commentaires de Communications Mining™. L'activité Récupérer le flux se connectera à Communications Mining et remplira l'objet Récupérer la sortie avec: - la collection de résultats (de la taille que nous avons demandée) - l'ID de séquence du lot en cours (l'ID de séquence du dernier commentaire dans le lot récupéré) - le nombre de commentaires filtrés (si nous avons appliqué des filtres à notre flux Communications Mining, les commentaires qui ne correspondent pas au filtre seront ignorés) L'activité Récupérer effectue une requête HTTPs à Communications Mining.
AdvanceStreamBatch	Nous essayons de faire progresser le flux de commentaires CommunicationsMining. L'activité Flux avancé se connectera à CommunicationsMining et utilisera comme entrée l'ID de séquence de l'un des commentaires dans le flux. Il marquera les commentaires (avant et en incluant celui avec l'ID de séquence donné) comme lus dans le flux afin que nous ne renvoient pas les mêmes la prochaine fois que nous extrayons une extraction à partir d'un flux. Si vous allez récupérer plusieurs fois de suite sans faire progresser un flux, vous recevrez les mêmes e-mails à chaque fois. L’activité Avancé effectue une requête HTTPs à CommunicationsMining.
GetTransactionData	Récupérez un élément de transaction à partir d'un tableau de commentaires. Comme il existe 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 progresser le flux et récupérer le lot suivant. Si nous extrayons plusieurs fois de suite sans faire progresser un 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 dans le 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 progresser le flux. Nous ne définissons pas io_TransactionItem sur rien ici car cela arrêterait le traitement de l'ensemble de l'infrastructure. Il est possible qu'il reste encore des éléments dans les prochains lots. La condition Arrêter est définie dans l'État de Obtenir les données de transaction
CheckValidationRules	Il s'agit d'un exemple d'algorithme de validation de base qui permet de décider si les prédictions sont valides uniquement en fonction du nombre de libellés prédit pour l'élément actuel. Si nous avons un libellé, nous avons une validation réussie et nous avons simplement besoin d'obtenir le nom du processus en aval dans le 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 consommateur et si les prédictions sur les éléments sont valides OU nécessitent une validation humaine. Si nous n’avons qu’un seul libellé prédit pour l’élément actuel, nous devons obtenir le nom de son processus correspondant. Nous prenons le nom du processus en aval (consommateur) dans le fichier de configuration, en fonction de ce libellé ONE prédit pour l’élément actuel. Dans le fichier de configuration, la convention d'affectation de noms du paramètre de nom de processus est la suivante: Le libellé du commentaire + "_" mot-clé. S’il était prévu que l’élément actuel comporte plusieurs libellés, nous avons besoin de l’humain pour décider comment procéder dans l’automatisation en aval. Ainsi, la réussite de la validation automatique doit être marquée comme fausse afin que l'élément actuel soit ajouté à la file d'attente Human-in-the-loop 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)	La finalité 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 des consommateurs dans l'automatisation en aval. Dans ce workflow, nous devons ajouter l'élément actuel à sa file d'attente correspondante. Steps: 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écidant de son processus client correspondant et vérifions les règles de validation par rapport aux données prédites.3. Si la validation est réussie, nous ajoutons l’élément à la file d’attente du processus client. Sinon, nous l’ajoutons à la file d’attente Human In the loop, pour qu’il soit validé et potentiellement traité par un humain. Pour la transaction en cours: - 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 faire l’objet d’une nouvelle tentative.
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ègle métier qui se sont produites lors de l'exécution actuelle 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é.