Organización del proyecto

Marcos de alto nivel

Partir de un marco genérico (y sin proceso definido) te garantiza tratar de forma coherente y estructurada cualquier proceso. Un marco te ayuda a comenzar con la visión de alto nivel, para luego profundizar en los detalles específicos de cada proceso.

The Robotic Enterprise Framework Template proposes a flexible high-level overview of a repetitive process and includes a good set of practices described in this guide and can easily be used as a solid starting point for RPA development with UiPath^®. The template is built on a State Machine structure.

Cómo funciona:

• El Robot carga los ajustes desde el archivo de configuración y los activos de Orchestrator, manteniéndolos en un diccionario que debe ser compartido entre los flujos de trabajo.
• El Robot busca las credenciales requeridas y accede a todas las aplicaciones.
• Lo reintenta un par de veces si se encuentra algún error, hasta lograrlo o abortar.
• El Robot comprueba la cola de entrada u otras fuentes de entrada para iniciar una nueva transacción.
• Si no hay (más) datos de entrada disponibles, configura el flujo de trabajo para que espere y reintente, o para finalizar el proceso.
• Se ejecutan las interacciones de IU para procesar los datos de la transacción.
• Si las transacciones se procesan con éxito, el estado de la transacción se actualiza y el Robot continúa con la siguiente transacción.
• Si se encuentra algún error de validación, el estado de la transacción, se actualiza y el Robot pasa a la siguiente transacción.
• Si se encuentra cualquier excepción, el Robot reintenta procesar la transacción un cierto número de veces (según su configuración), o marca el elemento como fallido y se reinicia.

• Al terminar, envía un email con el estado del proceso, si está configurado para ello.

  
  

  

  
  

Para los procesos basados en transacciones (como el procesamiento de todas las facturas de un archivo Excel) que no son ejecutadas a través de Orchestrator, pueden construirse colas locales utilizando los métodos .NET enqueue/ dequeue.

Después, el flujo del proceso de alto nivel (control de excepciones, reintento, recuperación) podría ser fácilmente replicado, siendo más fácil que teniendo todo el proceso agrupado bajo un bucle Para cada fila.

Todos los archivos de REFrameWork, junto con la documentación, se encuentran en esta página.

Principios de diseño

Dividir proyectos en flujos de trabajo más pequeños y utilizar actividades Invocar archivo de flujo de trabajo es fundamental para un buen diseño del proyecto. Los flujos de trabajo dedicados permiten la prueba independiente de componentes, fomentan la colaboración del equipo y mejoran el diseño y el rendimiento de ejecución en comparación con proyectos organizados en menos archivos y más grandes. Se recomienda hacer que los archivos del flujo de trabajo sean menores que 5 MB, y no se admiten archivos de flujo de trabajo superiores a 10 MB.

Selecciona cuidadosamente el tipo de diseño (diagrama de flujo y secuencias). Normalmente, la lógica del proceso se mantiene en los diagramas de flujo, mientras que la navegación y el procesamiento de datos se realizan en secuencias.

Al desarrollar una lógica compleja dentro de una secuencia, terminarás con un laberinto de contenedores y bloques de decisión, muy difícil de seguir y actualizar.

Por otra parte, las interacciones de IU en un diagrama de flujo la hacen más difícil de crear y mantener.

Los archivos relacionados con el proyecto (como las plantillas de correo electrónico) podrían organizarse en carpetas locales o unidades compartidas.

Nota: Si se colocan dentro de la carpeta del proyecto, se replican durante el proceso de despliegue (junto con los flujos de trabajo del proyecto) en todas las máquinas UiPath Robot de la carpeta lib/net45.

Estas carpetas también pueden ser almacenadas en una unidad compartida, de modo que todos los Robots se conectan a la misma fuente única. De este modo, los archivos relacionados con el proceso podrían ser revisados y mantenidos por los usuarios de la empresa en su totalidad, sin el apoyo del equipo de RPA. Sin embargo, la decisión (carpetas compartidas o locales) es compleja y deben tenerse en cuenta varios aspectos relacionados con el proceso y el entorno: tamaño de los archivos, frecuencia de los cambios, concurrencia para editar un mismo archivo, políticas de seguridad, etc.

Control de origen

Para gestionar con facilidad el versionado del proyecto y compartir el trabajo en más desarrolladores, recomendamos usar un Sistema de Control de Versiones. UiPath Studio está directamente integrado con GIT, TFS y SVN. Puedes encontrar un tutorial que explica los pasos de conexión y las funcionalidades aquí.

Configuración de controles

Para evitar la codificación de ajustes externos (como rutas de archivos, URL, etc.) en los flujos de trabajo, recomendamos mantenerlos en un archivo .config (.xlsx, .xml o .json) o en Orchestrator, como activos, si cambian a menudo.

Por lo general, la solución final debería ser extensible para permitir la variación y cambios en los datos de entrada sin la intervención del desarrollo. Por ejemplo, las listas con los clientes a los que se les permite un determinado tipo de transacción, los correos electrónicos de quienes deben recibir notificaciones, etc., deben almacenarse en archivos externos (como Excel) que el departamento comercial u otros departamentos puedan modificar directamente (añadir/eliminar/actualizar).

Para cualquier proceso repetitivo, todas las invocaciones del flujo de trabajo desde el bucle principal deben ser marcadas con la opción Aislar para contrarrestar posibles caídas del Robot (como, por ejemplo, por falta de memoria).

Credenciales

No se deben almacenar credenciales en el flujo de trabajo directamente, sino que deben cargarse desde lugares más seguros como el almacén de credenciales local de Windows o los activos de Orchestrator. Puedes utilizarlos en los flujos de trabajo a través de la actividad GetCredential.

Administración de errores

Dos tipos de excepciones pueden ocurrir al ejecutar un proceso automatizado: más o menos predecibles o totalmente inesperadas. Según esta diferencia, hay dos maneras de abordar las excepciones, ya sea mediante acciones explícitas ejecutadas automáticamente dentro del flujo de trabajo o mediante la escalada del problema a los operadores humanos.

En situaciones en las que se pueden encontrar excepciones, es útil añadir un Controlador global de excepciones al proyecto de automatización. Solo se puede añadir un tipo de flujo de trabajo de este tipo por proyecto de automatización, y el Controlador global de excepciones no está disponible para las bibliotecas.

El flujo de trabajo puede configurarse para determinar el comportamiento del flujo de trabajo al encontrar una excepción, haciendo que la ejecución ignore el error y continúe desde la siguiente actividad, reintente la actividad que causó el error, aborte la ejecución o continúe y vuelva a causar el error.

Además, los argumentos contenidos en el Controlador global de excepciones se pueden configurar para registrar el nombre de la actividad que arrojó la excepción o reintentar la actividad un número de veces. Para más información sobre como utilizar sus argumentos, consulte la pagina de Controlador global de excepciones.

Como alternativa al Controlador global de excepciones, la propagación de excepciones puede ser controlada colocando el código susceptible dentro de bloques Intentar/Capturar donde las situaciones pueden ser manejadas apropiadamente. Al nivel más alto, el diagrama del proceso principal debe definir medidas correctoras amplias para abordar todas las excepciones genéricas y garantizar la integridad del sistema.

Los controladores contextuales ofrecen más flexibilidad para que los Robots se adapten a varias situaciones, y deben ser utilizados para implementar técnicas alternativas, depuración o personalización de mensajes de usuario/registro. Aprovecha el mecanismo de propagación vertical de las excepciones para evitar controladores duplicados en secciones de captura, transfiriendo el controlador algunos niveles hacia arriba, donde pueda cubrir todas las excepciones desde un único lugar.

En el mensaje de excepción deben proporcionarse suficientes detalles para que un humano pueda entenderlo y tomar las medidas necesarias. Los mensajes de excepciones y las fuentes son esenciales. La propiedad fuente del objeto de excepción indica el nombre de la actividad que ha fallado (dentro de un flujo de trabajo invocado). Una vez más, el nombre es vital, porque una mala nomenclatura no da ninguna indicación clara sobre el componente que haya fallado.

Como puede ver a continuación, al elegir no cambiar el nombre de la actividad Invoke el origen de la excepción no tiene sentido en caso de un fallo (como Invoke Workflow File > Invoke Workflow File > Type Into).

Mantenlo simple

En el flujo del proceso, asegúrate de cerrar las aplicaciones de destino (navegadores, aplicaciones) después de que los Robots interactúen con ellas. Si se dejan abiertas, utilizan los recursos de la máquina y pueden interferir en los demás pasos de automatización.

Antes de publicar el proyecto, echa un último vistazo a los flujos de trabajo y haz algo de limpieza:

• Elimina variables no referenciadas.
• Eliminar salidas temporales de la línea de escritura.
• Eliminar código deshabilitado.
• Asegúrate de que el nombre es significativo y único.
• Elimina los contenedores innecesarios (Hacer clic con el botón derecho del ratón > Eliminar secuencia).

El nombre del proyecto también es importante. Ese es el aspecto del proceso en Orchestrator, por lo que debería estar en consonancia con tus reglas de nomenclatura internas. Por defecto, la ID del proyecto es el nombre inicial del proyecto, pero puede modificarlo desde el archivo project.json.

La descripción del proyecto también es importante (es visible en Orchestrator). Podría ayudarte a diferenciar más fácilmente entre procesos, así que elige una descripción significativa.

Reutilizabilidad del código

A la hora de desarrollar, con frecuencia necesitamos automatizar los mismos pasos en más de un flujo de trabajo/proyecto, así que debería ser una práctica habitual crear flujos de trabajo que contengan pequeñas piezas de automatización que se produzcan y agregarlas a la Biblioteca.

No hay una receta universal que te indique cómo dividir un proceso determinado.

Sin embargo, la separación de la lógica empresarial de los componentes de automatización es un buen principio que ayuda a crear un código que se puede reutilizar.

Ejemplo

Supongamos que una parte de tu proceso requiere leer la información del cliente y, a continuación, basándose en esa información y en las reglas de negocio internas, actualizar los detalles del cliente.

Obtener información del cliente y Cambiar la información del cliente deberían ser dos componentes de automatización distintos y completamente agnósticos de cualquier proceso. La lógica (actualiza el tipo de cliente solo cuando la cantidad total es superior a 100k en los últimos 12 meses) debe mantenerse separada de la automatización. Ambos componentes podrían utilizarse después, por separado, en el mismo proyecto o en otro diferente, con una lógica distinta. Si es necesario, pueden enviarse datos específicos a estos componentes mediante argumentos.

Obtener información del cliente no deberíaser convocado desde la Obtención de información del cliente, ya que dificulta las pruebas, el manejo de excepciones y la reutilización.

Nota: Utiliza componentes separados para Obtener información y Modificar información.

Cuando la separación entre las acciones no resulta tan evidente, el hecho de copiar y pegar el código existente de un flujo de trabajo a otro (o de un proyecto a otro) constituye también un buen indicio de que se debe crear un componente independiente (flujo de trabajo) para el código y llamarlo cuando sea necesario.

Dónde almacenar los componentes reutilizables

Arrastrar y soltar el código existente desde la Biblioteca al flujo de trabajo resulta más fácil que recrear el código desde cero, una y otra vez. El hecho de tratar con datos (ordenación, filtrado) o texto (división, patrones Regex) son ejemplos de lo que podría añadirse a la biblioteca de muestras. Ten en cuenta que, una vez añadido el código al flujo de trabajo, este se vuelve estático, por lo que si actualizas el flujo de trabajo en la Biblioteca, no se reflejará en los procesos vivos existentes.

Los componentes comunes (reutilizables) (como la navegación por la aplicación, el inicio de sesión o la inicialización) se almacenan y mantienen mejor por separado, en unidades compartidas de red. Desde esa unidad, pueden ser invocados por diferentes Robots, desde diferentes procesos. La mayor ventaja de este enfoque está en que cualquier cambio hecho en el componente maestro se refleja instantáneamente en todos los procesos que lo utilizan.

Importante: los proyectos Windows y multiplataforma no admiten la invocación de archivos .xamly .cs fuera de la ubicación del proyecto.

Cómo comprobar la automatización de la calidad

• Modularidad:

  • La separación de intereses con flujos de trabajo dedicados hace posible el desarrollo y las pruebas de granularidad fina;
  • Extrae y comparte componentes o flujos de trabajo reutilizables entre proyectos.

• Mantenimiento:

  • Buena estructura y normas de desarrollo.

• Legibilidad:

  • Estructura de proceso estandarizada que permite prácticas de desarrollo claras;
  • nombres significativos para los archivos de flujo de trabajo, actividades, argumentos y variables.

• Flexibilidad:

  • Mantén la configuración del entorno en archivos de configuración externos o en instancias de Orchestrator, facilitando la ejecución de la automatización tanto en entornos de prueba como de producción.

• Fiabilidad:

  • Manejar las excepciones e informes de errores;
  • Actualización del progreso de la ejecución en tiempo real.

• Extensible:

  • Listos para la incorporación de nuevos casos de uso.