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.

When Attended Robots Make Sense

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.

Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

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.

Benefits and Practical Considerations

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.

However, several factors affect this decision:

• Attended Robots typically run only during working hours
• Attended Robots keep machines and users busy until execution completes
• Input types and transaction volumes
• Time restrictions and scheduling
• Number of available Robots

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.

The Runtime Guide should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

The Development Details should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

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

After each component is built, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the REFramework’s Test_Framework folder for test files. The RunAllTests.xaml file enables automated testing of multiple .xaml files. Run tests outside office hours in testing environments to optimize developer time.

La arquitectura recomendada de UiPath incluye Entornos de desarrollo y de Prueba que permiten probar el proceso fuera de los sistemas de producción en vivo.

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.

Use the UiPath.config file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When True, the automation follows test routes and doesn't execute fully. For example, skip notifications and use Cancel instead of Save. When False, follow normal production routes.

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:

1. Los desarrolladores crean el proceso, lo prueban y lo depuran localmente (Studio).
2. 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.
3. La carpeta del proyecto está confirmada (no empaquetada) en una carpeta de la Biblioteca Maestra (en VCS).
4. 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.
5. Si cualquier problema es revelado durante las pruebas, se repiten los pasos anteriores.
6. Una vez superadas todas las pruebas de control de calidad, el paquete es enviado a un entorno de Producción: Process Pckgs (Prod).
7. 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

Use Log Message activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

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.