- Notas relacionadas
- Primeros pasos
- Instalación y configuración
- Proyectos de automatización
- Acerca de la publicación de proyectos de automatización
- Diseñar automatizaciones
- Gestionar paquetes de actividades
- Configuración de los Ajustes del Proyecto de Actividades
- Firma de paquetes
- Control
- Importar entidades
- Experiencia de diseño moderna
- Vincular un proyecto a una idea en Automation Hub
- Usar Data Manager
- Dependencias
- Tipos de flujos de trabajo
- Comparación de archivos
- Mejores prácticas de automatización
- Integración del control de código fuente
- Depuración
- La herramienta de diagnóstico
- Analizador de flujo de trabajo
- Acerca del analizador de flujo de trabajo
- ST-NMG-001: convención sobre nombres de variables
- ST-NMG-002: convención de nombres de argumentos
- ST-NMG-004: duplicación de nombres de visualización
- ST-NMG-005: anulación de variables
- ST-NMG-006: argumentos de anulación de variables
- ST-NMG-008: longitud variable excedida
- ST-NMG-009: variables de datos prefijados
- ST-NMG-011: argumentos de prefijo Datatable
- ST-NMG-012: valores predeterminados de los argumentos
- ST-NMG-016: longitud del argumento excedida
- ST-DBP-002: recuento de Argumentos elevado
- ST-DBP-003: bloque de Catch vacío
- ST-DBP-007: múltiples capas de diagramas de flujo
- ST-DBP-020: propiedades de salida no definidas
- ST-DBP-023: flujo de trabajo vacío
- ST-DBP-024: comprobación de actividad de persistencia
- ST-DBP-025: requisito previo para la serialización de variables
- ST-DBP-026: retraso en el uso de la actividad
- ST-DBP-027: mejor práctica de persistencia
- ST-DBP-028: requisito de serialización de argumentos
- ST-USG-005: argumentos de actividad codificados
- ST-USG-009: variables no utilizadas
- ST-USG-010: dependencias sin utilizar
- ST-USG-014: restricciones de los paquetes
- ST-USG-020: mensajes de registro mínimos
- ST-USG-024: guardado sin usar para más adelante
- ST-USG-025: uso incorrecto de los valores guardados
- ST-USG-026: restricciones de actividad
- ST-USG-027: paquetes necesarios
- ST-USG-028: Restringir la invocación de plantillas de archivo
- ST-USG-032 - Etiquetas obligatorias
- ST-USG-034 - URL Automation Hub
- Variables
- Argumentos
- Espacios de nombres importados
- Grabación
- Elementos de la IU
- Flujo de control
- Selectores
- Repo. de objetos
- Extracción de datos
- Automatización de imágenes y texto
- Acerca de la automatización de imágenes y texto
- Actividades con el ratón y el teclado
- Ejemplo de uso de la automatización de ratón y teclado
- Actividades de texto
- Ejemplo de uso de la automatización de texto
- Actividades de OCR
- Actividades de imagen
- Ejemplo de uso de la automatización de OCR y la automatización de imágenes
- Citrix Technologies Automation
- Automatización RDP
- Automatización de Salesforce
- Automatización SAP
- Automatización de VMware Horizon
- Registro
- La herramienta ScreenScrapeJavaSupport
- El protocolo WebDriver
- Conjunto de pruebas - Estudio
- Extensiones
- Solución de problemas
- Acerca de la resolución de problemas
- Compatibilidad y limitaciones de Microsoft App-V
- Solución de problemas de Internet Explorer x64
- Problemas de Microsoft Office
- Identificación de elementos de la interfaz de usuario en PDF con opciones de accesibilidad
- Reparar Soporte Active Accessibility
- Automatizar aplicaciones que se ejecutan en un usuario de Windows diferente
- Validation of large Windows-legacy projects takes longer than expected
Diseño de flujo de trabajo
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
