- 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
- 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
- Automatización atendida basada en desencadenadores
- 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
- Automatización de Citrix Technologies
- 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
Organización del proyecto
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.
La plantilla de Robotic Enterprise Framework propone una descripción general flexible de alto nivel de un proceso repetitivo e incluye un buen conjunto de prácticas descritas en esta guía y puede utilizarse fácilmente como un punto de partida sólido para el desarrollo RPA con UiPath. La plantilla se basa en una estructura de Máquina de estado.
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.
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.
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.
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í.
.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).
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.
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).
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).
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.
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.
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.
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.
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.
-
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.