Guía del usuario de Studio

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.

No todos los procesos que requieren intervención humana deben utilizar robots atendidos. Si una decisión de juicio es inevitable, considera dividir el proceso en subprocesos más pequeños que puedan ejecutarse unattended.

Por ejemplo, un subproceso podría recopilar datos y, después de la validación humana, un segundo subproceso continúa automáticamente.

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, varios factores afectan a esta decisión:

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 runtime debe contener un diagrama de runtime de alto nivel y detalles sobre la funcionalidad del robot, incluidos los subprocesos, las programaciones, los ajustes de configuración y la gestión de archivos.

Incluye detalles sobre los requisitos previos, la gestión de errores, la reanudación de procesos, el uso de Orchestrator, el registro, los informes y la gestión de credenciales.

Los Detalles de desarrollo deben incluir paquetes, entorno de desarrollo, niveles de registro, información de control de origen y componentes del flujo de trabajo con descripciones.

Incluye también componentes reutilizables, árboles de invocación, registros personalizados, instantáneas de diagramas de flujo, niveles de automatización y otros detalles de desarrollo.

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.

Después de crear cada componente, realiza pruebas unitarias. Las pruebas exhaustivas de componentes garantizan una integración más fluida y una depuración más rápida.

Utiliza la carpeta Test_Frameworkde REFramework para los archivos de prueba. El archivo RunAllTests.xaml permite realizar pruebas automatizadas de varios archivos .xaml . Ejecuta pruebas fuera del horario de oficina en entornos de prueba para optimizar el tiempo del desarrollador.

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.

Utiliza el archivo UiPath.config o los activos de Orchestrator para cambiar los marcadores específicos del entorno. Define un parámetro booleano de modo de prueba para controlar el comportamiento durante la depuración.

Cuando es Verdadero, la automatización sigue rutas de prueba y no se ejecuta completamente. Por ejemplo, omite las notificaciones y utiliza Cancelar en lugar de Guardar. Cuando es Falso, sigue las rutas de producción normales.

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

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:

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.

Utiliza las actividades de Mensaje de registro para realizar un seguimiento de la ejecución del proceso para la supervisión, el diagnóstico y la depuración. Los mensajes deben incluir ID de transacción e información de estado para una identificación precisa.

Debe utilizarse el registro:

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.

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.