Communications Mining
Más reciente
False
Imagen de fondo del banner
Guía para desarrolladores de Communications Mining
Última actualización 8 de feb. de 2024

Marco de automatización de UiPath

Información general

El marco Dispatcher de Communications Mining es una plantilla de UiPath Studio que se puede utilizar al integrar UiPath Communications Mining con implementaciones de RPA. Su objetivo es tomar los comentarios de un flujo de Communications Mining y añadirlos uno a uno, en una o varias colas de referencias únicas de UiPath Orchestrator. Debes definir una cola para cada proceso descendente que necesite los datos de un flujo como entrada. De forma predeterminada, en el archivo de configuración hemos configurado dos colas de proceso (para los procesos A y B) y una genérica, pero puedes configurar tantas como necesites.

Puedes descargar el marco desde aquí.

Importante:

COLAS DE REFERENCIAS ÚNICAS

Al crear tus colas, selecciona la casilla de verificación "Aplicar referencias únicas".

La plantilla se basa en Robotic Enterprise Framework (REFramework), por lo que cubre todas las mejores prácticas esenciales en proyectos RPA (configuración flexible a través del archivo Config.xlsx, manejo de excepciones, mecanismos de reintento, registro significativo).

Nota:

Robotic Enterprise Framework

Consulta la documentación oficial de REFramework si no estás familiarizado con ella, antes de trabajar con Communications Mining Dispatcher.

A partir de un proyecto REFramework, hemos encapsulado las dos operaciones clave que deben realizarse al consumir datos de un flujo de Communications Mining: obtener y avanzar. Obtener es el proceso de obtener datos de un flujo de Communications Mining y avanzar consiste esencialmente en marcar los comentarios como leídos para que no se devuelvan los mismos la próxima vez que los obtengamos. Los discutiremos con más detalle en la siguiente sección.

De forma predeterminada, el marco detendrá el ciclo de obtención y avance cuando pase el final de la transmisión (cuando la transmisión no tenga más comentarios "no leídos"). Sin embargo, si lo prefieres, puedes configurarlo para que se ejecute de forma continua, incluso cuando llegue al final de la transmisión: simplemente marca la configuración ExitOnEmptyStream como FALSO en el archivo Config.xlsx. En este caso, el ciclo será infinito, y cada vez que haya nuevos datos disponibles en la transmisión, los procesará al instante, sin necesidad de esperar a que el proceso del marco esté programado para ejecutarse.

El objetivo final es tener los comentarios disponibles en una cola de Orchestrator utilizable, un elemento de cola por comentario, que contenga sus datos correspondientes y las etiquetas y entidades previstas. De esta manera, las automatizaciones posteriores tendrán acceso a la información prevista.

La comunicación no se añade a su cola correspondiente sin pasar las reglas de validación. Hay algunas reglas de validación básicas ya definidas en el marco (principalmente para entender a qué proceso pertenece cada elemento), pero puedes añadir tus propios algoritmos de validación en el código. Además, solo como ejemplo, en el archivo Config.xlsx, tenemos hojas de configuración de validación separadas para cada proceso de automatización posterior (ProcessAValidations, ProcessBValidations). Dado que se configuraron solo como ejemplos para procesos teóricos, no dudes en añadir tus propias hojas y ajustes.

Importante:

Asegúrate de no tener varias configuraciones con el mismo nombre en el archivo de configuración, incluso si están en hojas diferentes; todos se añadirán al mismo diccionario de configuración y se anularán entre sí.

En el archivo, ofrecimos algunos ejemplos de convenciones de nomenclatura para la configuración de validación que podrían ser útiles. La lógica del flujo de trabajo que comprueba las reglas de validación sigue las mismas convenciones, así que ten cuidado al implementar las tuyas propias, en caso de que quieras cambiarlas.

Si la validación falla, la información se añade a una cola Human in the Loop (HitL) (que también requiere referencias únicas), para ser validada por un humano en Action Center. Puedes añadir el nombre de tu cola HitL en el archivo de configuración.

Importante:

Recomendamos que definas un desencadenador en la cola Human in the Loop que inicie un nuevo proceso de orquestación para cada elemento nuevo; crear una tarea en Action Center. La tarea contendría los datos recuperados de Communication Mining para el elemento actual, y el humano debería validarlo antes de enviarlo a su correspondiente cola de proceso de automatización posterior.

Transmisiones

Después de entrenar con éxito un modelo en Communications Mining, podemos crear un nuevo flujo y configurar los umbrales para cada uno de los conceptos que hemos entrenado. Una secuencia define una colección de comentarios en un conjunto de datos. Permite la iteración persistente y con estado a través de los comentarios, con etiquetas predichas y entidades calculadas utilizando una versión de modelo determinada.

Nota:

Te recomendamos que sigas la Documentación oficial de Communications Mining y Academy para conocer los pasos de entrenamiento del modelo y los detalles de todos los conceptos implicados.

La integración de UiPath Studio con Communications Mining consiste en el consumo de cada uno de los comentarios del flujo de Communications Mining. Cada una de las predicciones de la comunicación puede utilizarse en uno o varios procesos posteriores. En el siguiente diagrama, se describe la integración genérica de UiPath y Communications Mining:


Nuestro enfoque recomienda que para n automatizaciones, se configuren n + 1 procesos en UiPath: n procesos RPA y un alimentador de cola. Se introduce un único proceso de alimentación que es responsable de leer las comunicaciones estructuradas de un flujo de Communications Mining y distribuirlas a los procesos RPA relevantes a través de las colas de Orchestrator. Cualquier excepción que pueda producirse debido a la extracción de Communications Mining puede marcarse para la validación humana manual. Los procesos que extraen elementos de las colas serán automatizaciones estándar de UiPath que leen sus datos de entrada de los datos del elemento en cola. El marco del distribuidor proporcionado cumple el rol del alimentador de colas.

Bucle Obtener-Avanzar

Para consumir comentarios de una transmisión, nuestro marco debe implementar el bucle Obtener y avanzar como se describe a continuación:

  1. Cada transmisión tiene un comentario actual:


  2. Podemos obtener comentarios a partir de este comentario actual. A continuación, recuperamos 2:


  3. Cada comentario devuelto de una transmisión tendrá un sequence_id:
    {
       "comment":{
          "messages":[ ... ],
          "user_properties":{ ... },
          "id":"Comment 1"
       },
       "entities":[ ... ],
       "labels":[ ... ],
       "sequence_id":"ABC123"
    }{
       "comment":{
          "messages":[ ... ],
          "user_properties":{ ... },
          "id":"Comment 1"
       },
       "entities":[ ... ],
       "labels":[ ... ],
       "sequence_id":"ABC123"
    }
    
  4. Podemos usar este sequence_id para avanzar el comentario actual al siguiente en la cola. Ahora, cuando obtengamos 2, devolveremos los comentarios 2 y 3:


El marco de Communications Mining implementa este bucle de obtención y avance por ti.

Descripción general del marco del distribuidor

Simplemente modificando los ajustes necesarios puedes configurar el marco del distribuidor para consumir comentarios de tu propio flujo, ahorrando tiempo de implementación y garantizando que se siguen las mejores prácticas.

Al igual que el REFramework, se puede utilizar tal y como es, como una solución Plug and Play, ya que sin ninguna modificación en el código (simplemente añadiendo tu configuración en el archivo Excel de configuración), obtiene cada uno de los comentarios de los stream (como objetos de tipo CommunicationsMining.Result, definidos en el paquete CommunicationsMining (consulta la sección Dependencias a continuación), y añade sus datos a una cola correspondiente. Como alternativa, se puede personalizar por completo y puedes añadir tu propia lógica según sea necesario (las reglas para validar las predicciones de Communications Mining, por ejemplo).


El marco Communications Mining Dispatcher utiliza el enfoque de obtención y bucle avanzado descrito anteriormente, y podemos avanzar un comentario a la vez, o un lote de comentarios a la vez (podemos configurar el tamaño del lote en el archivo de configuración). Recuerda que el distribuidor se utiliza como alimentador de uno o varios procesos posteriores, por lo que en el archivo de configuración también definimos la cola correspondiente para cada uno de estos procesos y las reglas para añadir el elemento a la cola.

Los pasos generales son los siguientes:

  • Obtenemos un lote inicial de comentarios. Esto devolverá un lote de comentarios del flujo de Communications Mining, el sequence_id del último elemento del lote y el número de elementos filtrados del lote actual.
  • Si no se produjo ninguna excepción (nos conectamos con éxito a la transmisión) y no estamos al final de la transmisión, comprobamos si quedan elementos por procesar en el lote actual (podríamos incluso obtener lotes sin comentarios, si hay filtros aplicados en Communications Mining para la transmisión actual, y no se aplica ninguno de los comentarios en el lote actual).
  • Si hay elementos para procesar, los procesamos uno por uno: dependiendo del proceso RPA del consumidor al que pertenece el elemento actual, comprobamos las reglas de validación de los datos del elemento.
  • Si el elemento pasa las comprobaciones, añadimos un nuevo elemento de cola a la cola correspondiente (como se establece en el archivo de configuración de Excel). El uid del comentario se establecerá como referencia del elemento de la cola. Si no pasa las reglas de validación, añadimos un elemento de cola a la cola HitL. Cada elemento de cola que se cree contendrá todas las predicciones de entidad y etiqueta del comentario para su uso en procesos posteriores.
  • Una vez que se ha procesado cada elemento del lote actual, primero avanzamos la transmisión (utilizando el sequence_id del último elemento del lote) y luego recuperamos un nuevo lote de la transmisión.
  • Si estamos al final de la transmisión (ya que no recuperamos comentarios en el lote y no hay comentarios filtrados), sabemos que avanzamos más allá del final de la transmisión y el procesamiento finaliza.

Configuración

Todos los ajustes que necesitamos para configurar el distribuidor se encuentran en el archivo Data/Config.xlsx.

Nota: Asegúrate de añadir todos los activos correspondientes a Orchestrator.
Las hojas de configuración y activos
NombreDescripción
OrchestratorProcessAQueueNameEsta es la cola en la que nuestro distribuidor enviará comentarios VÁLIDOS para que los procese el proceso A del consumidor de RPA.
OrchestratorProcessBQueueNameEsta es la cola en la que nuestro distribuidor enviará comentarios VÁLIDOS para que los procese el proceso B del consumidor de RPA.
OrchestratorHITLQueueNameAEsta es la cola en la que nuestro distribuidor enviará los comentarios que no pasaron las reglas de validación definidas para su proceso correspondiente. HITLQueue será procesado por el proceso de orquestación Human In The Loop que crea acciones de validación para cada uno de los elementos de cola añadidos.
OrchestratorGeneralQueueNameEsta es la cola en la que nuestro distribuidor enviará los comentarios que no se clasificaron para un proceso de consumidor de RPA específico.
Communications MiningApiTokenCredentialEl token de la API de Communications Mining necesario para obtener de la transmisión y avanzar dentro de la transmisión, almacenado en un activo de credencial.
ExitOnEmptyStreamSi esta configuración es Falso, el marco se ejecutará de forma continua, incluso cuando lleguemos al final de la transmisión.
Cada una de las hojas de validación del proceso
NombreDescripción
{ProcessName}_LabelLa convención de nomenclatura de la configuración es la etiqueta que marca un comentario como designado para ser manejado por el proceso actual+ palabra clave "_"+"Etiqueta". Su valor es el nombre del proceso descendente. Ejemplo: Nombre Policy_Label, Valor ProcessA.

Dado que el distribuidor puede rellenar colas de entrada para uno o más procesos posteriores, te proponemos que crees una nueva hoja en el archivo de configuración para cada uno de los procesos, en la que definirás las reglas de validación para ese proceso. La convención de nomenclatura de la hoja debe ser: "{ProcessName}Validations". De forma predeterminada, el archivo de configuración contiene 2 hojas de validación para el proceso A y el proceso B.

Manejo de excepciones

El marco recopila cada excepción que se produce durante el procesamiento de cada uno de los elementos de transacción (comentarios de minería de comunicaciones) en dos tablas de datos: una para las excepciones del sistema y otra para las excepciones de las reglas empresariales.

En el estado de proceso final, puedes utilizar las tablas para gestionar las excepciones según tu lógica empresarial (crear archivos de Excel con ellas, enviarlas adjuntas a un correo electrónico de informes, etc.).

Arquitectura



Dependencias

Hemos creado actividades personalizadas que gestionan las principales operaciones que podrían realizarse desde UiPath para integrarse con Communications Mining: Fetch Stream, Advance Stream. Además, las Transacciones del Marco son de tipo CommunicationsMining.Result, un tipo de datos definido en el paquete que contendrá toda la información definida para cada comentario y sus correspondientes Etiquetas y Entidades previstas.

Debes tener el paquete CommunicationsMining en una de tus fuentes, para que el Dispatcher Framework se cargue correctamente, descargado desde Marketplace: aquí.

Estados

Dado que el marco es básicamente un REFramework, es una máquina de estados con los mismos estados. Consulta la documentación de REFramework para obtener más detalles sobre cada estado.

La única modificación es la adición de la transición de flujo avanzado entre el estado Obtener datos de transacción y el estado Procesar transacción. En caso de que no haya elementos para procesar en el lote actual recuperado, la ejecución vuelve al estado ObtenerDatosDeTransacción para seguir avanzando en la transmisión.

Variables compartidas

Las siguientes variables se declaran en el archivo Main.xaml y se comparten como argumentos para los flujos de trabajo invocados en el marco o simplemente deciden el flujo de ejecución a través del marco:

Nombre de la variableDescripción
ShouldStop(Boolean)Verdadero cuando el trabajo se detiene a la fuerza (desde Orchestrator).
TransactionItem(CommunicationsMining.Result)El Elemento de transacción está representado por un comentario del flujo de Communication Mining. Estamos procesando un elemento a la vez y añadiendo sus datos a la cola correspondiente.
SystemException(Exception)Se utiliza durante las transiciones entre estados para representar excepciones distintas de las excepciones empresariales.
BusinessException(BusinessRuleException)Se utiliza durante las transiciones entre estados y representa una situación que no se ajusta a las reglas del proceso que se está automatizando.
TransactionNumber(Int32)Contador secuencial de elementos de transacción.
Config(Dictionary(String,Object))Estructura de diccionario para almacenar datos de configuración del proceso (configuración, constantes, activos y propiedades de validación).
RetryNumber(Int32)Se utiliza para controlar el número de intentos de reintento del procesamiento de la transacción en caso de excepciones del sistema.
TransactionData(IList(CommunicationsMining.Result))El lote de comentarios recuperados actualmente de la transmisión, por la última Fetch.
ConsecutiveSystemExceptions(Int32)Se utiliza para controlar el número de excepciones consecutivas del sistema.
BusinessExceptionsDT(DataTable)Tabla con detalles sobre las BusinessRulesExceptions ocurridas durante el procesamiento de las Transacciones. Una fila contiene información sobre una transacción defectuosa.
ApplicationExceptionsDT(DataTable)Tabla con detalles sobre las Excepciones del sistema ocurridas durante el procesamiento de las Transacciones. Una fila contiene información sobre una transacción defectuosa
GlobalRetryInterval(TimeSpan)El intervalo de reintento global establecido de forma predeterminada para cada ámbito de reintento en el marco.
GlobalMaxAttempts(Int32)El número global de intentos máximos establecido de forma predeterminada para cada ámbito de reintento en el marco.
CurrentSequenceId(String)El ID de secuencia recuperado por la última recuperación de un lote de transmisión. Es el ID de secuencia del último elemento del lote de transmisión actual.
CurrentBatchFilteredResults(Int32)El número de elementos que no se ajustan al filtro definido para la transmisión en Communication Mining y que fueron filtrados por la última recuperación (filtrados del Lote recuperado actual).
CommunicationsMiningApiToken(SecureString)El token de API definido en Communication Mining. Su valor debe almacenarse en un activo de credenciales en Orchestrator.
CurrentBatchNumber(Int32)Es una buena práctica dividir tu transmisión en varios lotes (para ayudar con el tiempo de rendimiento de la recuperación de datos). Esto nos indicará el lote actual que se está procesando.
ShouldAdvanceTheStream(Boolean)En caso de que no haya elementos para procesar en el lote actual recuperado, la ejecución vuelve al estado ObtenerDatosDeTransacción para seguir avanzando en la transmisión.
Flujos de trabajo específicos de Communications Mining
Nombre del flujo de trabajoDescripción
GetNextStreamBatchEstamos intentando obtener los siguientes comentarios de Stream Batch of Communications Mining. La actividad Obtener flujo se conectará a Communications Mining y rellenará el objeto de salida Obtener con:- la colección de resultados (del tamaño que solicitamos)- el ID de secuencia del lote actual (el ID de secuencia del último comentario en el lote recuperado ): el número de comentarios filtrados (en caso de que hayamos aplicado filtros en nuestro flujo de Communications Mining, se omitirán los comentarios que no coincidan con el filtro). La actividad Obtener realiza una solicitud HTTP a Communications Mining.
AdvanceStreamBatchEstamos intentando hacer avanzar el flujo de comentarios de CommunicationsMining. La actividad Avanzar flujo se conectará a CommunicationsMining y, utilizando como entrada el ID de secuencia de uno de los comentarios en el flujo, marcará los comentarios (antes e incluyendo el que tiene el ID de secuencia dado) como leídos en el flujo para que podamos no devuelva los mismos la próxima vez que los obtengamos de una transmisión. Si obtienes varias veces seguidas sin avanzar una transmisión, recibirás los mismos correos electrónicos cada vez. La actividad Avanzar realiza una solicitud HTTPs a CommunicationsMining.
GetTransactionDataObtener un elemento de transacción de los comentarios de una matriz. Como hay varias transacciones, utilizamos el argumento en_NúmeroDeTransacción como índice para recuperar la transacción correcta que se va a procesar. Si no quedan más transacciones en el lote actual, debemos avanzar en la transmisión y obtener el siguiente lote. Si recuperamos varias veces seguidas sin avanzar en una transmisión, obtendrás los mismos resultados cada vez. Si hay elementos en el lote y aún quedan algunos por procesar, tomamos la instancia del siguiente elemento de transacción del lote. De lo contrario, marcamos el hecho de que no quedan más elementos para procesar en el lote actual y que necesitamos avanzar en la transmisión. No establecemos io_TransactionItem en nada aquí, ya que eso detendría el procesamiento de todo el marco, y tal vez todavía haya elementos en los siguientes lotes. La condición STOP se establece en el estado Obtener datos de transacción
CheckValidationRulesEste es un ejemplo de algoritmo de validación básico que decide si las predicciones son válidas únicamente en el número de etiquetas previstas para el elemento actual. Si tenemos una etiqueta, tenemos una validación exitosa y solo necesitamos obtener el nombre del proceso posterior del archivo de configuración. Si tenemos varias etiquetas, la validación automática se establece como fallida. Añade tu propia lógica para decidir el nombre del proceso del consumidor y si las predicciones de los elementos son válidas O necesitan validación humana. Si solo tenemos una etiqueta predicha para el elemento actual, tenemos que obtener el nombre de su proceso correspondiente. Tomamos el nombre del proceso descendente (consumidor) del archivo de configuración, en función de esa etiqueta ONE prevista para el elemento actual. En el archivo de configuración, la convención de nomenclatura de la configuración del nombre del proceso es: la etiqueta del comentario + "_" + palabra clave "Etiqueta". Si se predijo que el elemento actual tendría varias etiquetas, necesitamos que el ser humano decida cómo proceder en la automatización posterior. Por lo tanto, el éxito de la validación automática debe marcarse como falso para que el elemento actual se agregue a la cola Human in the Loop para una posterior validación manual.
CreateDictionaryFromCommunicationsMiningItemTendremos que añadir la información tomada de CommunicationsMining para el elemento actual a una cola. Así que estamos creando un diccionario basado en él. Usaremos el diccionario para añadir las propiedades definitorias del nuevo elemento de cola.
AddTransactionItemToQueueAñadir un nuevo elemento a la cola. Todas sus propiedades ya deben estar configuradas en el diccionario in_QueueItemProperties. Asegúrate de que tu cola tenga seleccionada la casilla de verificación Aplicar referencias únicas.
ProcesoEl propósito del distribuidor es rellenar las colas correspondientes con la información obtenida en Communications Mining para cada uno de los elementos para que puedan ser procesados por los procesos de consumidor en la automatización descendente. En este flujo de trabajo, tenemos que añadir el elemento actual a su cola correspondiente. Pasos: 1. Estamos creando un diccionario basado en TransactionItem. Usaremos el diccionario para añadir las propiedades definitorias del nuevo elemento de cola.2. Basándonos en la información obtenida en Communications Mining para el elemento actual, estamos decidiendo su proceso de consumidor correspondiente y comprobando las reglas de validación con los datos previstos.3. Si la validación tiene éxito, añadiremos el elemento a la cola del proceso del consumidor. Si no es así, lo añadiremos a la cola Human In The Loop, para que sea validado y potencialmente procesado por un ser humano. Para la transacción actual: Si se lanza una BusinessRuleException, la transacción se omite. Si se produce otro tipo de excepción, se puede volver a intentar la transacción actual.
ExceptionsHandlerEste flujo de trabajo debe utilizarse como controlador de excepciones final en el marco. Si se rellenan las TablasDeDatos de entrada, contienen detalles sobre todas las Excepciones de la aplicación y/o de las reglas empresariales que se produjeron durante la ejecución actual del proceso.

Uso del marco

Antes de utilizar el marco:

  • Asegúrate de configurar todos los activos necesarios en Orchestrator (consulta la sección Configuración y activos) y realiza las modificaciones necesarias en el archivo Data/Config.xlsx.
  • Asegúrate de que las colas en las que añadirás los elementos existan en Orchestrator y tengan seleccionada la casilla de verificación "Aplicar referencias únicas" para evitar añadir duplicados a la cola y procesar el mismo elemento varias veces en las automatizaciones posteriores.
  • Añade tus propias reglas de validación en Communications Mining/CheckValidationRules.xaml . Por el momento solo comprobamos si el elemento actual tiene varias etiquetas previstas. Si es así, la validación falla. Si no, tomamos el Nombre del proceso correspondiente al elemento actual, en función de su etiqueta.

Was this page helpful?

Obtén la ayuda que necesitas
RPA para el aprendizaje - Cursos de automatización
Foro de la comunidad UiPath
Logotipo blanco de UiPath
Confianza y seguridad
© 2005-2024 UiPath. All rights reserved.