Framework de automação da UiPath®

Configure a Communications Mining Dispatcher Framework, um modelo do UiPath Studio para criar fluxos de trabalho de automação que consomem dados do Communications Mining.

Observação:

O conteúdo das atividades foi realocado para o guia Atividades do Communications Mining™ .

Visão geral

A Estrutura do dispatcher do Communications Mining™ é um modelo do UiPath® Studio que você pode usar ao integrar o Communications Mining com implementações de RPA. Seu objetivo é pegar os comentários de um stream do Communications Mining e adicioná-los um a um, em uma ou muitas filas de referências exclusivas do UiPath Orchestrator.

Você deve definir uma fila para cada processo downstream que precisa dos dados de um stream como entrada. Por padrão, no arquivo de configuração, configuramos duas filas de processo (para Processos A e B) e uma genérica, mas você pode configurar quantas forem necessárias.

Você pode obter a estrutura do Studio, em Modelos, procurando por Communications Mining Dispatcher.

Importante:

Ao criar suas filas, selecione a opção Impor referências exclusivas .

O modelo é baseado na Estrutura Empresarial Robótica (REFramework), abrangendo todas as práticas recomendadas essenciais em projetos de RPA, como a configuração flexível por meio do arquivo Config.xlsx, tratamento de exceções, mecanismos de repetição e registros em log significativos.

Observação:

Antes de trabalhar com o dispatcher do Communications Mining, certifique-se de consultar a documentação oficial do REFramework, se você não estiver familiarizado com ela.

Começando de um projeto REFramework, encapsulamos as duas operações principais que precisam ser realizadas ao consumir dados de um fluxo do Communications Mining: busca e progresso. Buscar é o processo de obter dados de um fluxo do Communications Mining e avançar é basicamente marcar os comentários como lidos, para que não retornemos os mesmos da próxima vez que buscarmos. Vamos discuti-los com mais detalhes na próxima seção.

Por padrão, a estrutura interromperá o ciclo de busca e avançar quando passar o fim do stream, ou seja, quando o stream não tiver mais comentários não lidos. No entanto, você pode configurar a estrutura para ser executada continuamente, mesmo quando atinge o final do fluxo. Para fazer isso, você pode marcar a configuração ExitOnEmptyStream como False no arquivo Config.xlsx.

This setting allows the framework to cycle infinitely, and whenever new data becomes available in the stream, it will process it instantly, with no need to wait for when the process of the framework is scheduled to run.

Saída da fila

O objetivo final é ter os comentários disponíveis em uma fila do Orchestrator utilizável, um item de fila por comentário, contendo seus dados correspondentes e rótulos previstos e campos gerais. Dessa forma, as automações downstream terão acesso às informações previstas.

Regras de validação

A comunicação não é adicionada à sua fila correspondente sem passar as regras de validação. Existem algumas regras de validação básicas já definidas no framework — principalmente para entender a qual processo cada item pertence — mas você pode adicionar seus próprios algoritmos de validação ao código.

Além disso, como exemplo, no arquivo Config.xlsx, temos planilhas de configurações de validação separadas para cada processo de automação downstream, ou seja, ProcessAValidations e ProcessBValidations. Como eles foram configurados apenas como exemplos para processos matemáticos, fique à vontade para adicionar suas próprias planilhas e configurações.

Importante:

• Make sure you do not have multiple settings with the same name in the Config file, even if they are on different sheets. They will all be added to the same Config dictionary and override each other. In the file, we offered some examples of naming conventions for the validation settings that might be useful. The logic in the workflow that checks the validation rules follows the same conventions, so be careful when implementing your own, in case you want to change them. If the validation fails, the information is added to a human-in-the-loop queue, which also requires unique references, for a human to validate in Action Center. You can add the name of your human-in-the-loop queue in the Config file. Config file, even if they are on different sheets. They will all be added to the same Config dictionary and override each other.

  No arquivo, oferecemos alguns exemplos de convenções de nomenclatura para as configurações de validação que podem ser úteis. A lógica no fluxo de trabalho que verifica as regras de validação segue as mesmas convenções; portanto, tenha cuidado ao implementar as suas próprias, caso queira alterá-las.

  If the validation fails, the information is added to a human-in-the-loop queue, which also requires unique references, for a human to validate in Action Center. You can add the name of your human-in-the-loop queue in the Config file.

• You are recommended to define a trigger on the human-in-the-loop queue, which starts a new Orchestration Process for each new item, creating a task in Action Center. The task would contain the data retrieved from Communications Mining for the current item, and the human should validate it before sending it into its corresponding downstream automation process queue.

Transmissões

Depois de treinar com sucesso um modelo no Communications Mining™, podemos criar um novo fluxo e configurar os limites para cada um dos conceitos que treinamos. Um stream define uma coleção de comentários em um conjunto de dados. Ele permite a iteração persistente e com estado por meio dos comentários, com rótulos previstos e campos gerais calculados usando uma determinada versão do modelo.

Observação:

Recomendamos que você siga a Documentação e a Academia oficiais do Communications Mining para obter as etapas de treinamento do modelo e detalhes sobre todos os conceitos envolvidos.

The integration of UiPath® Studio with Communications Mining consists of the consumption of each of the comments from the Communications Mining stream. Each of the communication's predictions can then be used in one or multiple downstream processes. In the diagram below, the generic UiPath and Communications Mining integration is described:

Nossa abordagem recomenda que, para n automações, n + 1 processos sejam configurados no UiPath: n Processos de RPA e um Feeder de Filas. Um único processo feeder é introduzido, o qual é responsável por ler as comunicações estruturadas de um stream do Communications Mining e distribuí-las aos processos de RPA relevantes por meio de Filas do Orchestrator.

Quaisquer exceções que possam ocorrer devido à extração do Communications Mining podem ser marcadas para Validação Humana manual. Os processos que obtém itens das filas serão automações UiPath padrão que leem seus dados de entrada a partir dos dados do item da fila. A estrutura do dispatcher fornecida preenche a função do feed da fila.

Loop de busca avançada

Para consumir comentários de um stream, nossa estrutura precisa implementar o Loop Fetch e Advance, que é descrito da seguinte forma:

1. Todo fluxo tem um comentário atual:

   

2. É possível buscar comentários a partir deste comentário atual. Na imagem a seguir, estamos buscando dois comentários:

   

3. Cada comentário retornado de um fluxo terá um sequence_id:

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

4. Podemos usar esse sequence_id para avançar o comentário atual para o próximo na fila. Agora, ao buscarmos o 2, retornaremos os comentários 2 e 3:

   

A Estrutura do Communications Mining implementa esse loop de buscar e avançar para você.

Visão geral da estrutura Dispatcher

Basta modificar as configurações necessárias para configurar a estrutura do dispatcher para consumir comentários do seu próprio fluxo, economizando tempo de implementação e garantindo que as melhores práticas sejam seguidas.

Assim como o REFramework, ele pode ser usado exatamente como está, como uma solução plug-and-play.

Você pode usá-lo dessa forma, pois sem qualquer modificação no código (apenas adicionando suas configurações no arquivo do Excel à configuração), ele obtém cada um dos comentários do stream definido (como objetos do tipo CommunicationsMining.Result, definidos no arquivo Communications Mining) e adiciona seus dados a uma Fila correspondente. Para obter mais detalhes, consulte a seção Dependências.

Como alternativa, ela pode ser completamente personalizada, e você pode adicionar sua própria lógica conforme necessário (as regras para validar as previsões do Communications Mining™, por exemplo).

The Communications Mining Dispatcher Framework uses the Fetch and Advance Loop approach as previously described, and we can advance one comment at a time, or one batch of comments at a time (we can set up the size of the batch in the Config file).

Lembre-se de que o Dispatcher é usado como feed de um ou vários processos downstream, portanto, no arquivo de configuração, também definimos a fila correspondente para cada um desses processos e as regras para adicionar o item à fila.

As etapas gerais são as seguintes:

• Buscamos um lote inicial de comentários. Isso retornará um lote de comentários do fluxo do Communications Mining, o sequence_id do último item do lote e o número de itens filtrados do lote atual.
• Se nenhuma exceção ocorrer (conectados com sucesso ao fluxo) e não estivermos no final do fluxo, verificamos se há itens restantes para processar no lote atual. Podemos até buscar lotes sem comentários, se houver filtros aplicados no Communications Mining para o fluxo atual e nenhum dos comentários no lote atual se aplica).
• Se houver itens a serem processados, nós os processamos um por um: dependendo do processo de RPA do consumidor ao qual o item atual pertence, verificamos as regras de validação dos dados do item.
• Se o item for aprovado nas verificações, adicionamos um novo item de fila à fila relevante (conforme definido no arquivo de configuração do Excel). O uid do comentário será definido como a referência do item da fila. Se ele não for aprovado nas regras de validação, adicionamos um item de fila à fila Meta. Cada item de fila que é criado conterá todos as previsões de campo geral e rótulo do comentário para uso em processos downstream.
• Após cada item do lote atual ser processado, primeiro avançamos o fluxo (usando o sequence_id do último item do lote) e, depois, buscamos um novo lote no fluxo.
• Se estivermos no final do fluxo (como não recuperamos nenhum comentário no lote e não há comentários filtrados), saberemos que avançamos além do final do fluxo e o processamento termina.

Configuração

Todas as configurações necessárias para configurar o Dispatcher são encontradas no arquivo Data/Config.xlsx.

Observação:

Certifique-se de adicionar todos os ativos correspondentes ao Orchestrator.

As configurações e planilhas de ativos

Nome	Descrição
OrchestratorProcessAQueueName	Esta é a Fila para a qual nosso Dispatcher enviará comentários VÁLIDOS para serem processados pelo Processo A do Consumidor de RPA.
OrchestratorProcessBQueueName	Esta é a Fila para a qual nosso Dispatcher enviará comentários VÁLIDOS para serem processados pelo Processo B do Consumidor de RPA.
OrchestratorHITLQueueNameA	Esta é a Fila para a qual nosso Dispatcher enviará comentários que não passaram nas Regras de validação definidas para seu Processo correspondente. A HITLQueue será processada pelo Human In The Loop, Processo de Orquestração que cria Ações de Validação para cada um dos itens da fila adicionados.
OrchestratorGeneralQueueName	Esta é a Fila para a qual nosso Dispatcher enviará comentários que não foram categorizados para um Processo de Consumo de RPA específico.
Communications MiningApiTokenCredential	O token de API do Communications Mining™ necessário para buscar no stream e avançar dentro do stream, armazenado em um Ativo de credenciais.
ExitOnEmptyStream	Se essa configuração for False, o framework será executado continuamente, mesmo quando atingirmos o fim do fluxo.

Cada uma das Planilhas de validação de processo

Nome	Descrição
{ProcessName}_Label	A convenção de nomenclatura da configuração é o rótulo que marca um comentário como sendo designado para ser processado pelo processo atual + "_"+ palavra-chave "Label". O valor dele é o nome do processo downstream. Exemplo: Nome Policy_Label, Valor ProcessA.

Como o Dispatcher pode preencher filas de entrada para um ou mais processos downstream, sugerimos que você crie uma nova planilha no arquivo de configuração para cada um dos processos, na qual você definirá as regras de validação para cada processo. A convenção de nomenclatura da Planilha deve ser: "{ProcessName}Validations". Por padrão, o arquivo de configuração contém 2 planilhas de validação para o processo A e o processo B.

Manuseio de exceção

A Estrutura coleta todas as exceções que ocorrem durante o processamento de cada um dos itens de transação (comentários do Communications Mining™) em duas TabelasDeDados: uma para Exceções do sistema e outra para Exceções de regras de negócios.

Em Estado do processo final, você pode usar as tabelas para lidar com as exceções de acordo com sua lógica de negócios (criar arquivos do Excel com elas, enviá-las anexadas a um e-mail de relatório, etc).

Arquitetura

Dependências

Criamos Atividades personalizadas que lidam com as principais operações que podem ser realizadas a partir do UiPath® para se integrar ao Communications Mining™: Fetch Stream, Advance Stream. Além disso, as Transações do framework são do tipo CommunicationsMining.Result, um tipo de dados definido no pacote que manterá todas as informações definidas para cada comentário e seus rótulos previstos e campos gerais correspondentes.

Você precisa ter o pacote CommunicationsMining em um dos seus feeds para que a Estrutura do dispatcher seja carregada corretamente, baixado do Marketplace: aqui.

Estados

Como o Framework é basicamente um REFramework, ele é uma Máquina de estado com os mesmos estados. Consulte a documentação do REFramework para obter mais detalhes sobre cada estado.

A única modificação é a adição da Transição de Fluxo Avançado entre o Estado de Dados da Transação GET e o Estado de Transação de Processo. Caso não haja itens a serem processados no lote atual buscado, a execução retorna ao estado GetTransactionData para progresso no fluxo.

Variáveis compartilhadas

The variables below are declared in the Main.xaml file and shared as arguments to the workflows invoked in the Framework or they simply decide the execution flow through the framework:

Nome da variável	Descrição
ShouldStop(Boolean)	Verdadeiro quando o trabalho é interrompido à força (a partir do Orchestrator).
TransactionItem(CommunicationsMining.Result)	The Transaction Item is represented by one comment from the Communications Mining stream. We're processing one item at a time and adding its data to the corresponding queue.
SystemException(Exception)	Usado durante transições entre estados para representar outras exceções que não exceções de negócios.
BusinessException(BusinessRuleException)	Usado durante as transições entre estados e representa uma situação que não está em conformidade com as regras do processo automatizado.
TransactionNumber(Int32)	Contador sequencial de itens de transação.
Config(Dictionary(String,Object))	Dictionary structure to store configuration data of the process (settings, constants, assets and Validation properties).
RetryNumber(Int32)	Usado para controlar o número de tentativas de novo processamento da transação em caso de exceções do sistema.
TransactionData(IList(CommunicationsMining.Result))	O lote de comentários atualmente recuperados do fluxo, pela última Busca.
ConsecutiveSystemExceptions(Int32)	Usado para controlar o número de exceções do sistema consecutivas.
BusinessExceptionsDT(DataTable)	Tabela com detalhes sobre BusinessRulesExceptions ocorridas durante o processamento das Transactions. Uma linha contém informações sobre uma transação com falha.
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)	O intervalo de tentativa global definido por padrão para cada Escopo de Tentativa no Framework.
GlobalMaxAttempts(Int32)	The global number of Max Attempts set by default for every Retry Scope in the Framework.
CurrentSequenceId(String)	O ID de sequência recuperado pela Busca mais recente de um Lote de stream. É o ID de sequência do último item no lote de fluxo atual.
CurrentBatchFilteredResults(Int32)	The number of items that don't fit the filter that was defined for the stream in Communications Mining and were filtered out by the latest Fetch (filtered out of the Current Fetched Batch).
CommunicationsMiningApiToken(SecureString)	The API token defined in Communications Mining. Its value should be stored in a Credential Asset in Orchestrator.
CurrentBatchNumber(Int32)	É uma boa prática dividir sua transmissão em vários lotes (para ajudar no tempo de desempenho de recuperação dos dados). Isso nos dirá o lote atual que está sendo processado.
ShouldAdvanceTheStream(Boolean)	Caso não haja itens a processar no lote atual buscado, a execução retorna ao estado GetTransactionData para maior progresso no fluxo.

Fluxos de trabalho específicos do Communications Mining™

Nome do fluxo de trabalho	Descrição
GetNextStreamBatch	We're trying to get the next Stream Batch of Communications Mining™ comments. The Fetch Stream activity will connect to Communications Mining and will populate the Fetch output object with: - the collection of results (of the size we requested) - the Sequence ID of the current batch (the Sequence ID of the last comment in the retrieved batch) - the number of filtered out comments (in case we applied filters on our Communications Mining stream, the comments that don't match the filter will be skipped) The Fetch activity performs an HTTPs request to Communications Mining.
AdvanceStreamBatch	We're trying to advance the stream of CommunicationsMining comments. The Advance Stream activity will connect to CommunicationsMining and using as an input the Sequence ID of one of the comments in the stream, it will mark the comments (before and including the one with the given Sequence ID) as read in the stream so that we do not return the same ones next time we fetch from a stream. If you fetch multiple times in a row without advancing a stream, you will get the same emails every time. The Advance activity performs an HTTPs request to CommunicationsMining.
GetTransactionData	Get a transaction item from an array of comments. Since there are multiple transactions, we use the argument in_TransactionNumber as an index to retrieve the correct transaction to be processed. If there are no more transactions left in the current batch, we need to advance the stream and fetch the next batch. If we fetch multiple times in a row without advancing a stream, you will get the same results every time. If there are items in the batch and there are still some left to process we take the instance of the next Transaction Item in the batch. Otherwise, we flag the fact that there are no more items left to process in the current batch and that we need to advance the stream. We don't set io_TransactionItem to nothing here as that would stop the processing of the whole framework, and maybe there are still items in next batches. The STOP condition is set in the Get Transaction Data STATE
CheckValidationRules	This is a basic validation algorithm example that decides whether the predictions are valid solely on the number of labels predicted for the current item. If we have one label, we have a successful validation and we just need to get the name of the downstream process from the config file. If we have multiple labels, the automatic validation is set as unsuccessful. Add your own logic for deciding the name of the Consumer process and whether the predictions on the items are Valid OR need human validation. If we have only one label predicted for the current item, we have to get the name of its corresponding process. We take the name of the Downstream (Consumer) Process from the Config file, based on that ONE label predicted for the current item. In the Config file, the naming convention of the process name setting is : The label of the comment + "_"+"Label" keyword. If the current item was predicted to have multiple labels, we need the human to decide how to proceed in the downstream automation. So the automatic validation success should be marked as false so that the current item will be added to the Human in the Loop queue for later manual Validation.
CreateDictionaryFromCommunicationsMiningItem	Precisamos adicionar as informações obtidas do CommunicationsMining para o item atual a uma fila. Então, estamos criando um dicionário com base nele. Usaremos o dicionário para adicionar as propriedades definidoras do novo item da fila.
AddTransactionItemToQueue	Adicionando um novo item à fila. Todas as suas propriedades já devem estar configuradas no dicionário in_QueueItemProperties. Certifique-se de que sua fila tenha a caixa de seleção Impor referências exclusivas marcada.
Processo	The purpose of the Dispatcher is to populate corresponding queues with the information obtained in Communications Mining for each of the items so that they can be processed by Consumer Processes in the Downstream Automation. In this workflow, we have to add the current item to its corresponding queue. Steps: 1. We're creating a dictionary based on the TransactionItem. We'll use the dictionary for adding the defining properties of the new queue item. 2. Based on the information obtained in Communications Mining for the current item, we're deciding its corresponding Consumer Process and checking the validation rules against the predicted data.3. If the validation is successful, we're adding the item to the queue of the Consumer Process. If not, we're adding it into the Human In The Loop queue, to be validated and potentially processed by a human. For the current Transaction: - If a BusinessRuleException is thrown, the transaction is skipped. - If another kind of exception occurs, the current transaction can be retried.
ExceptionsHandler	This workflow should be used as a final Exception Handler in the Framework. If the input DataTables are populated, they contain details on all the Application and/or Business Rule Exceptions that occurred during the current run of the process.

Como usar o Framework

Antes de usar o Framework:

• Certifique-se de configurar todos os ativos necessários no Orchestrator (verifique a seção Configurações e ativos) e faça as modificações necessárias no arquivo Data/Config.xlsx.
• Certifique-se de que as filas nas quais você adicionará os itens existam no Orchestrator e tenham a caixa de seleção “Impor referências exclusivas” selecionada para evitar adicionar duplicatas à fila e processar o mesmo item várias vezes nas automações downstream.
• Adicione suas próprias regras de validação em Communications Mining/CheckValidationRules.xaml . No momento, verificamos apenas se o item atual tem vários rótulos previstos. Se sim, a validação falhará. Caso contrário, consideramos o Nome do processo correspondente ao item atual, com base em seu rótulo.