Diseño de flujo de trabajo

Diagramas de diseño

UiPath ofrece cuatro diagramas para integrar actividades en una estructura de trabajo al desarrollar un archivo de flujo de trabajo:

• Diagrama de flujo
• Secuencia
• Máquina de estado
• Controlador global de excepciones

Secuencia

Las secuencias tienen una representación lineal sencilla que fluye de arriba a abajo y son las más adecuadas para escenarios sencillos en los que las actividades se suceden. Por ejemplo, son útiles en automatización de la interfaz de usuario, en la que la navegación y la escritura se producen un clic o una pulsación a la vez. Como las secuencias son fáciles de integrar y entender, son el diseño preferido para la mayoría los flujos de trabajo.

Diagrama de flujo

Los diagramas de flujo ofrecen más flexibilidad para conectar actividades y suelen establecer un flujo de trabajo en dos dimensiones. Debido a su forma libre y su atracción visual, los diagramas de flujo son más adecuados para mostrar puntos de decisión dentro de un proceso. Las flechas que pueden apuntar a cualquier lugar se asemejan mucho a la declaración de programación IrA no estructurada y, por lo tanto, hacen que los grandes flujos de trabajo sean propensos a un entrelazamiento caótico de actividades.

Máquina de estado

Una máquina de estado es una estructura más compleja que se puede entender como un diagrama de flujo con flechas condicionales, llamadas transiciones. Permite una representación más compacta de la lógica y la encontramos adecuada para un diagrama de proceso estándar de alto nivel de plantillas de procesos de negocio transaccionales.

Controlador global de excepciones

El Controlador de Excepciones está diseñado para ser utilizado tanto en proyectos de automatización pequeños como grandes, para identificar errores de ejecución y, lo que es más importante, determinar el comportamiento del flujo de trabajo cuando se produce un error de este tipo. Si se encuentra un error de ejecución durante la depuración, el Controlador global de excepciones puede ser configurado para intervenir y te permite verificar el comportamiento del flujo de trabajo de acuerdo a las opciones establecidas previamente en el Controlador de excepciones.

Opciones

Las decisiones deben ser implementadas en un flujo de trabajo para permitir que el Robot reaccione en varias condiciones en el procesamiento de datos y la interacción de la aplicación. Seleccionar la representación más apropiada de una condición y sus ramas posteriores tiene un gran impacto en la estructura visual y la legibilidad de un flujo de trabajo.

Actividad Si

La actividad Si divide una secuencia verticalmente y es perfecta para ramas lineales cortas. Los desafíos vienen cuando es necesario encadenar más condiciones de una manera Si... Entonces Si, especialmente cuando las ramas exceden el tamaño de la pantalla disponible, ya sea en anchura o en altura. Como pauta general, se deben evitar las sentencias Si anidadas para mantener el flujo de trabajo simple/lineal.

Decisión de flujo

Los diseños de diagramas de flujo son útiles para mostrar la lógica empresarial importante y las condiciones relacionadas, como las declaraciones Si anidadas o las construcciones Si... Entonces Si. Hay situaciones en las que un diagrama de flujo puede ser adecuado incluso dentro de una Secuencia.

Operador Si

El operador VB If es muy útil para condiciones locales menores o para informática de datos, y a veces puede reducir todo un bloque a una sola actividad.

Actividad Cambiar

La actividad Cambiar puede utilizarse a veces en convergencia con el operador Si para racionalizar y compactar una cascada Si... Entonces Si con distintas condiciones y actividades por rama.

Cambio de flujo

La actividad Cambiar de flujo selecciona el siguiente nodo dependiendo del valor de una expresión; Cambiar de flujo puede entenderse como el equivalente de la actividad Cambiar procesal en diagramas de flujo. Puede igualar más de 12 casos al iniciar más conexiones desde el mismo nodo de conmutación.

Datos

Respecto a la visibilidad y el ciclo de vida, dividimos los datos en dos tipos: argumentos y variables. El propósito de los argumentos es enviar datos de un flujo de trabajo a otro, mientras que las variables están vinculadas a un contenedor dentro de un único archivo del flujo de trabajo y solo se puede usar localmente.

Ámbito de variables

A diferencia de los argumentos, disponibles en todos los archivos del flujo de trabajo, las variables solo son visibles dentro del contenedor en el que están definidos, el llamado ámbito.

Las variables deben mantenerse en el ámbito más interno para reducir el desorden en el panel de Variables y para mostrar solamente lo que es relevante en un punto particular del flujo de trabajo en el autocompletado.

Nota: Si existen dos variables con el mismo nombre, aunque lo desaconsejamos seriamente, tendrá prioridad la definida en el ámbito más interno.

Argumentos

Ten en cuenta que al invocar los flujos de trabajo con la opción Aislado (que ejecuta el flujo de trabajo en un proceso independiente del sistema), solo se pueden utilizar tipos serializables como argumentos para pasar datos de un proceso a otro. Por ejemplo, los objetos SecureString, Navegador y Conexión terminal no pueden traspasar con seguridad la frontera entre procesos.

Valores predeterminados

Las variables y los argumentos de entrada tienen la opción de iniciarse con algunos valores estáticos predeterminados. Esto es muy útil cuando se prueban los flujos de trabajo individualmente, sin requerir datos de entrada reales de los flujos de trabajo de llamada u otras fuentes externas.

Convenciones de nombres

Deberías asignar nombres significativos a los archivos, actividades, argumentos y variables del flujo de trabajo para describir con precisión su uso a lo largo del proyecto.

Los proyectos deberían tener descripciones significativas, ya que también se muestran en la interfaz de usuario de Orchestrator y podrían ayudar en entornos multiusuario.

Para mejorar la comprensión, los nombres de variables y argumentos también deberían seguir una convención de nomenclatura:

• Caso de Snake: First1_Name2, first_name2,
• Caso superior o inferior de Camel: FirstName, lastName,
• Caso Pascal: First1Name2, First1Name,
• Caso kebab: First-Name, First-Name1.

Los nombres de argumentos deben tener un prefijo que indique el tipo de argumento, como in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.

Los nombres de las actividades deben reflejar la acción realizada, como Haz clic en el botón Guardar. Mantén la parte del título que describe la acción (Haz clic, Escribe en, El elemento existe, etc).

Excepto el Principal, todos los nombres de flujo de trabajo deben contener el verbo que describe la acción del flujo de trabajo, como GetTransactionData, ProcessTransaction o TakeScreenshot.

Comentarios y Anotación

La actividad Comentario y Anotaciones debe utilizarse para describir con más detalle una técnica o las particularidades de una determinada interacción o comportamiento de la aplicación. Ten en cuenta que otras personas pueden, en algún momento, encontrarse con un proyecto de robótica en el que puedes intentar facilitarles la comprensión del proceso.