Ciclo de vida de la automatización

Comprensión de los procesos

La decisión de elegir entre una automatización para Robots atendidos o Robots desatendidos constituye la primera decisión importante que repercute en la forma en que los desarrolladores construyen el código, ya que el marco general de ejecución (activación del Robot, interacción, manejo de excepciones) es diferente. El cambiar al otro tipo de Robots más tarde puede resultar engorroso.

Para procesos de tiempo crítico, en vivo, desencadenados por el ser humano, como en un centro de llamadas, un Robot atendido que trabaje junto a un humano podría ser la única respuesta posible.

Sin embargo, no todos los procesos que necesitan de la intervención humana deben ejecutarse con Robots atendidos. Si no se puede evitar una decisión exclusivamente de juicio (que no esté basada en reglas) a lo largo del proceso, evalúa si es posible un cambio de flujo, como dividir el proceso más grande en dos subprocesos más pequeños, cuando la salida del primer subproceso se convierta en la entrada del segundo. Aunque la intervención humana tenga lugar en el medio, como la validación/modificación de la salida del primer subproceso, ambos podrían activarse automáticamente y ejecutarse sin supervisión.

Un caso típico sería un proceso el cual requiere un paso manual en alguna parte del proceso, como por ejemplo revisar la sección de comentarios no estructurados de un ticket y, en base a eso, asignar el ticket a ciertas categorías.

Generalmente, optar por un Robot desatendido garantiza un uso más eficiente de la carga del Robot y un mayor ROI, una mejor gestión y seguimiento de las capacidades robóticas.

Sin embargo, estos cálculos deben tener en cuenta varios aspectos, como el hecho de que un Robot atendido normalmente solo podría funcionar en las horas normales de trabajo que tiene una persona, o puede mantener la máquina y el usuario ocupados hasta que se termine la ejecución. También influyen en esta decisión los tipos de entrada, los volúmenes de transacciones, las restricciones de tiempo, el número de Robots disponibles, etc.

Documentar el proceso: DSD

La documentación de los procesos orienta el trabajo del desarrollador y le ayuda a realizar el seguimiento de las solicitudes y el mantenimiento de la aplicación. Desde luego, puede haber muchos otros documentos técnicos, pero hay uno que es fundamental para una aplicación sin problemas, concretamente el DSD (Documento de especificaciones de desarrollo).

El Documento de especificaciones de desarrollo debe contener los detalles del proceso automatizado y se centra en dos categorías principales: Guía de tiempo de ejecución y Detalles de desarrollo.

La Guía de tiempo de ejecución debe contener un diagrama de tiempo de ejecución de alto nivel, además de detalles sobre la funcionalidad del Robot, como subprocesos, horarios, ajustes de configuración, archivos de entrada, archivos de salida, archivos temporales y acciones realizadas. Deben especificarse los detalles adicionales sobre el proceso maestro, tales como los prerrequisitos, la gestión automática y manual de errores, la reanudación del proceso en caso de fallo, el uso de Orchestrator, el registro y los informes, la gestión de credenciales y cualquier otra información relevante relacionada con la seguridad o la función.

Los Detalles de desarrollo deben contener información sobre los paquetes en uso, el entorno de desarrollo, el nivel de registro, el repositorio de código fuente y el versionado, una lista de componentes del flujo de trabajo con su descripción y lista de argumentos, una lista de componentes reutilizables, la estructura de invocación del flujo de trabajo, los registros personalizados definidos y los campos de registro, las instantáneas relevantes del diagrama de flujo del proceso, los niveles de automatización en segundo plano y en primer plano, y cualquier otro elemento de desarrollo relevante o pendiente.

Desarrollo y revisión del código

El arquitecto de soluciones de RPA es el responsable de formar continuamente a los desarrolladores en las mejores prácticas. Por lo tanto, es necesario realizar revisiones frecuentes y minuciosas del código para garantizar una calidad muy alta de los flujos de trabajo desarrollados. De este manera, se motiva a los desarrolladores para que construyan flujos de trabajo robustos y sigan la guía de mejores prácticas.

Prueba

Una vez construido cada componente, deben realizarse pruebas unitarias. Si cada componente se somete a pruebas exhaustivas, la integración se lleva a cabo con mayor fluidez y la depuración dura menos tiempo. El REFramework contiene una carpeta Test_Framework donde deben ser colocados todos los archivos de prueba. Al utilizar el archivo RunAllTests.xaml, un desarrollador puede probar una secuencia que contenga muchos archivos .xaml de forma automática, lo que permite probar pequeñas integraciones entre componentes y realizar pruebas de estrés. Un informe es generado al final de cada prueba. Por lo general, este tipo de pruebas deben ejecutarse fuera del horario de oficina, en entornos de prueba, para optimizar el tiempo del desarrollador.

The recommended UiPath^® architecture includes Dev and Test environments that allow the processes to be tested outside the live production systems.

En ocasiones, las aplicaciones se ven o se comportan de forma diferente entre los Entornos de desarrollo, Prueba o Producción y se deben tomar medidas adicionales, saneando los selectores o incluso la ejecución condicional de algunas actividades.

Usa el archivo UiPath.config o los activos de Orchestrator para cambiar las banderas o los ajustes del entorno actual. Un parámetro de modo de prueba (Booleano) podría ser comprobado antes de interactuar con las aplicaciones en vivo. Esto podría ser recibido como un activo (o argumento) de entrada. Cuando se establece en Verdadero, durante las pruebas de depuración e integración, se sigue la ruta de prueba, no se ejecuta el caso completamente. Por ejemplo, el patch de prueba puede omitir el envío de notificaciones, saltarse el botón Aceptar o Guardar o presionar el botón Cancelar o Cerrar en su lugar. Cuando se establece en Falso, se sigue la ruta del modo normal de Producción.

Esto te permite realizar modificaciones y pruebas en los procesos que funcionan directamente en los sistemas en vivo.

Emitir

Existen diferentes formas de diseñar la arquitectura y el flujo de liberación, teniendo en cuenta la configuración de la infraestructura, la preocupación por la segregación de roles, etc.

En este modelo propuesto, los desarrolladores de UiPath pueden construir sus proyectos y probarlos en entornos de Desarrollo en Orchestrator. Se les permite registrar el proyecto en una unidad gestionada por un sistema de control de versiones (VCS), como GIT, SVN o TFS.

La publicación del paquete y su puesta a disposición de los entornos de Prueba y Producción es tarea de otro equipo, como el de TI.

Las rutas de implementación en Orchestrator se han cambiado de su valor por defecto a las carpetas gestionadas por el VCS, cambiando el valor Storage.Location en el UiPath.Orchestrator.dll.configarchivo de la sección Implementación.

El modelo también contiene un repositorio de componentes reutilizables.

Aquí está el flujo de publicación del proyecto, paso a paso:

Los desarrolladores crean el proceso, lo prueban y lo depuran localmente (Studio).
Una vez completado el desarrollo de la automatización, el proceso se publica en el Desarrollo de Orchestrator y es probado nuevamente de principio a fin.
La carpeta del proyecto está confirmada (no empaquetada) en una carpeta de la Biblioteca Maestra (en VCS).
El equipo de operaciones de IT/RPA ha creado el paquete de proyecto para QA. Este paso pretende ser una medida de seguridad adicional: el código fuente de la automatización es inspeccionado (por una entidad diferente) antes de ser empaquetado y ejecutado por los robots. Por ejemplo, el proceso empaquetado es almacenado en la carpeta de Process Pckgs (QA) en VCS, desde donde es desplegado a los robots de QA y ejecutado.
Si cualquier problema es revelado durante las pruebas, se repiten los pasos anteriores.
Una vez superadas todas las pruebas de control de calidad, el paquete es enviado a un entorno de Producción: Process Pckgs (Prod).
Una vez que el proceso se pone en marcha, el paquete de procesos se despliega en los Robots de producción y es ejecutado.

El Contenido reutilizable se crea y despliega por separado, como código UiPath (Biblioteca de Código Reutilizable) e Invokes (Repositorio de Invokes).

Los flujos de trabajo con código fuente .xaml son archivos que contienen actividades para automatizar procesos comunes, tales como Iniciar sesión en SAP:

Las Invocaciones representan flujos de trabajo compuestos solo por una actividad de Invocación de los flujos de trabajo de código mencionados anteriormente.

El panel Fragmento de un desarrollador de Studio debería apuntar a este repositorio Invocar para poder acceder fácilmente (arrastrando y soltando) al Contenido reutilizable.

El responsable del diseño local encargado de mantener la actualización del Contenido reutilizable (debido a un cambio en el proceso, por ejemplo) actualiza los flujos de trabajo con código. Las Invocaciones permanecen sin cambios.

Una de las ventajas de este enfoque (frente a trabajar de forma directa con la biblioteca de código fuente) es que, cuando se ha realizado un cambio en un componente reutilizable, todos los proyectos en ejecución reflejan también este cambio, dado que solo contienen una Invocación del flujo de trabajo modificado.

Supervisión

El uso de las actividades de Mensaje de registro para trazar la evolución de un proceso en ejecución resulta esencial para supervisar, diagnosticar y depurar un proceso. Los mensajes deben proporcionar toda la información relevante para identificar con precisión una determinada situación, incluyendo la ID de la transacción y el estado.

Debe utilizarse el registro:

Al principio y al final de cada flujo de trabajo;
Cuando los datos provienen de fuentes externas;
Cada vez que se detecte una excepción al más alto nivel.

Los mensajes se envían con la prioridad especificada (p. ej., Información, Rastreo, Advertencia) en Orchestrator y son guardados también en el archivo local .nlog.

Campos de registro personalizados

Para facilitar la disponibilidad de los datos en Kibana para la elaboración de informes, el Robot puede etiquetar los mensajes de registro con valores adicionales usando la actividad Agregar campos de registro. Por defecto, cualquier salida de registro de UiPath ya cuenta con varios campos, entre ellos message, timestamp, level, processName, fileName y la identidad del robot en Windows. Los campos de registro son persistentes, de modo que si no necesitamos marcar todos los mensajes con una etiqueta, los campos deben eliminarse inmediatamente después del registro, usando la actividad Eliminar campos de registro. No uses un nombre de campo que ya exista. En la primera vez que añadas el campo, es importante que especifiques el tipo de argumento adecuado. Así es como lo indexa Elasticsearch.