Estándares para contenido de calidad

Todos los listados en Marketplace deben cumplir las siguientes pautas generales:

Directrices	Detalles
Componentes modulares y reutilizables	Los aceleradores de soluciones deben diseñarse teniendo en cuenta la modularidad, ofreciendo una arquitectura pensada para plantillas de proceso, modelos de aprendizaje automático, bibliotecas reutilizables y más. Estos componentes modulares deben ser fáciles de integrar y combinar para crear procesos personalizados para el caso de uso específico originalmente en mente o tener la capacidad de transferir varios componentes reutilizables entre procesos. Esto debería reducir el esfuerzo de duplicación y promover la coherencia con las directrices de desarrollo en los diferentes procesos.
Parámetros y ajustes configurables	Los aceleradores de soluciones deben proporcionar parámetros y ajustes configurables que se puedan ajustar para que coincidan con los requisitos del usuario final y sus necesidades empresariales. Las configuraciones pueden incluir, entre otros, variables, umbrales, tiempos de espera, puntos finales, modelos de aprendizaje automático, asignaciones humanas en el bucle y otros parámetros ajustables para permitir la personalización y la adaptabilidad. El archivo de configuración del proceso, los activos de Orchestrator y los argumentos del proceso son algunos de los medios que puedes utilizar para lograr la configurabilidad.
Arquitectura escalable y adaptable	El diseño de la arquitectura debe ser escalable, adaptable, capaz de manejar diversos requisitos de automatización y permitir una fácil expansión con más robots o más procesos a medida que evolucionan las necesidades empresariales o surgen nuevos casos de uso. La arquitectura debe permitir la integración con varios sistemas, aplicaciones y tecnologías que se encuentran dentro de la industria del caso de uso. Los usuarios deben poder intercambiar fácilmente varios componentes de Solution Accelerator o integrar otros nuevos para adaptarse a las necesidades de su organización.
Capacidades de integración	Pre-built Integration Service connectors or connections built using Connector Builder should be utilized, when possible, to enable automation using APIs with an out of the box library of connectors while also providing a standard way to set up and manage connections with standardized authentication. La perfecta integración con sistemas y aplicaciones externos agiliza el intercambio de datos y permite a los Aceleradores de soluciones trabajar con la infraestructura de TI existente, minimizando la necesidad de modificaciones extensas o desarrollo personalizado. If API automation is not possible, UI automation should be contained within a GUI Integration Layer / Application Layer as described further below. This should utilize Object Repository within an Application Library.
Extensibilidad y personalización	Los aceleradores de soluciones deben diseñarse para ser extensibles y personalizables, lo que permite a los usuarios de los aceleradores de soluciones adaptar el flujo de trabajo de automatización a las necesidades específicas de su organización. Los aceleradores de soluciones deben desarrollarse teniendo en cuenta que las organizaciones deben utilizar el acelerador de soluciones específico como base para el caso de uso, al tiempo que tienen la capacidad de adaptarlo a sus necesidades empresariales únicas.

:::note Through these areas, a Solution Accelerator should provide a structured but flexible framework for building an efficient and scalable automation solution. In summary, your Solution Accelerator should promote modularity, adaptability, best practice compliance, and easy integration with systems and applications to facilitate rapid development and deployment of automation. ::: :::note For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.

Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on UiPath Marketplace without express authorization from the third party. :::

Standards for solution accelerators

1. Layered architecture

El diseño de un acelerador de soluciones debe implementar una separación entre la capa de lógica empresarial (capa de implementación) y la capa de aplicación (capa de interacción GUI, si es necesario). Esto se puede lograr directamente dentro de los distintos flujos de trabajo del proceso o, si se requiere reutilización, utilizando bibliotecas.

2. Business logic layer (implementation layer)

• Esta capa es responsable de implementar la lógica empresarial básica y los flujos de trabajo de automatización del Acelerador de soluciones.
• Se centra en las tareas y procesos específicos que Solution Accelerator pretende automatizar dentro de un dominio o caso de uso determinado.
• La capa de lógica empresarial define las reglas, condiciones y acciones necesarias para lograr los resultados de automatización deseados.
• Puede implicar la manipulación de datos, la toma de decisiones, la integración con sistemas externos y otras tareas de procesamiento.
• Esta capa está diseñada para ser modular y personalizable, lo que permite a las organizaciones adaptar el Solution Accelerator a sus requisitos empresariales específicos.
• Normalmente utiliza capacidades de automatización de UiPath, como actividades, flujos de trabajo y variables, para orquestar el flujo de automatización.

3. Application layer

• La capa de aplicación sirve como interfaz entre el flujo de trabajo de automatización y la GUI (interfaz gráfica de usuario) o la API (interfaz de programación de aplicaciones) de las diversas aplicaciones y/o sistemas que participan en el proceso automatizado.
• Esta capa podría manejar las interacciones con los elementos de la interfaz de usuario, como botones, campos, menús y cuadros de diálogo, dentro de las aplicaciones o sistemas de destino. Esta capa también podría manejar la implementación de la interfaz de programación de aplicaciones dentro de las aplicaciones o sistemas de destino, como la entrada de datos a través de la comunicación de código en lugar de utilizar la interfaz de usuario de la aplicación.
• Esta capa puede incluir actividades y componentes que permiten la automatización de la IU, como la extracción de pantalla, la entrada/salida de datos y la navegación. Esta capa también puede incluir lógica de aplicación para la implementación programática de los mismos controles.
• La capa de aplicación está diseñada para adaptarse a la aplicación de destino específica: cualquier actualización de las API o de las interfaces de usuario debe realizarse en un solo lugar y luego adaptarse a todas las implementaciones de ese componente.
• La capa de interacción de la GUI debe proporcionar flexibilidad para manejar las variaciones en los elementos de la IU, los diseños de pantalla y las rutas de navegación.
• Dentro de la capa de interacción de la API, la salida de cualquier flujo de trabajo debe ser coherente con el objetivo del flujo de trabajo. Por ejemplo, si tu flujo de trabajo se llama "Recuperar todos los usuarios", se debe esperar que se devuelva una colección de objetos de usuario y no un JSON que luego habría que analizar para extraer los datos de usuario necesarios.
• Mantén la duración de las llamadas a la API al mínimo haciendo uso de la paginación y aplicando los filtros pertinentes siempre que la API de destino los implemente.

Nota:

La separación entre una capa empresarial y una capa de aplicación garantiza una clara distinción entre la automatización y la lógica del proceso frente a los detalles específicos de la aplicación. Esto permite una arquitectura modular y escalable en la que los cambios en la GUI o la API pueden gestionarse por separado de la lógica empresarial básica. Esta separación permite un mantenimiento más sencillo, la reutilización dentro de Solution Accelerator o la transferencia a otros procesos, y la personalización de Solution Accelerator. El usuario final de Solution Accelerator puede reemplazar fácilmente la capa de aplicación para adaptarse a cualquier cambio en las aplicaciones de destino sin afectar a la lógica del proceso subyacente. Del mismo modo, la lógica empresarial puede modificarse o ampliarse independientemente de la aplicación para adaptarse a las necesidades empresariales en evolución.

Standard architecture types

Transactional / queue based processes

Este es el modelo estándar de Dispatcher-Performer. El marco de Robotic Enterprise debe utilizarse para la implementación de un proceso sencillo basado en transacciones.

The Robotic Enterprise Framework is a project template based on State Machines. It is created to fit all the best practices regarding logging, exception handling, application initialization, and others, being ready to tackle a complex business scenario. The template contains several pre-made State containers for initializing applications, retrieving input data, processing it and ending the transaction. All these states are connected through multiple transitions which cover almost every need in a standard automation scenario. There are also multiple invoked workflows, each handling particular aspects of the project.

El modelo Dispatcher and Performer es una solución prediseñada para separar las dos etapas principales de un proceso colocando una cola en el medio. De esta manera, la producción de elementos de transacción es totalmente independiente de su consumo. Este asincronismo rompe la dependencia de tiempo entre el distribuidor y el ejecutante.

En este enfoque estándar, un distribuidor es una automatización para cargar datos en una cola de UiPath. Extrae datos de una o varias fuentes y los utiliza para crear elementos de cola para que los procesen los robots de Performer. La información se envía a una o más colas, lo que permite al distribuidor utilizar un formato común para todos los datos almacenados en los elementos de la cola. Estos datos pueden procesarse en una automatización posterior, el Ejecutante. El ejecutante puede procesar los datos según sea necesario, ya que los elementos de la cola se procesan de uno en uno. Utiliza mecanismos de manejo de errores y reintento para cada elemento procesado. Una de las principales ventajas del ejecutante es su escalabilidad (se pueden utilizar varios ejecutantes con una sola cola).

2. Document Understanding processes

Most of the processes working with documents have in common their requirement to also "understand" their content. Hence, a dedicated framework specialized in document understanding has been put in place – the Document Understanding (DU) Process Framework.

This framework is essentially a UiPath Studio Project template based on a typical document processing flowchart. The process provides logging, error handling, retry mechanisms, and all the methods that should be used in a DU workflow. The workflow has an architecture decoupled from other connected automations:

• No importa de dónde provengan los archivos a procesar o qué desencadene la ejecución: esto es responsabilidad de un proceso anterior.
• No importa dónde se deba utilizar la información extraída: esta es responsabilidad del proceso posterior.
• La arquitectura del marco es común tanto para los robots atendidos como para los desatendidos:
• Lógica de comprensión de documentos (digitalización, clasificación, extracción de datos)
• Human-in-the-loop logic (validation) using *Action Center
• for unattended robots, or a local *Validation Station
• for attended ones

Como resultado de estos mecanismos y arquitectura, la gran mayoría de las automatizaciones que utilizan Document Understanding suelen combinar un modelo Dispatcher-Performer con un marco Document Understanding intermedio:

• The *Dispatcher
• gathers documents to be processed from the upstream application or system.
• The *Document Understanding Process
• extracts the necessary information from each document one at a time with scalability because of the Dispatcher method.
• Finally, the *Performer
• utilizes the extracted data from the document to complete the process.

3. Transactional processes with Action Center

This architecture consists of Dispatcher – Performer - Finalizer processes with human in the loop, or Long-Running Workflow, process somewhere in the middle. The standard template for longrunning workflows is the Orchestration Process Template. Long-Running workflows have best practices that need to be followed to support service orchestration, human intervention, and long-running transactions in unattended environments.

Esta arquitectura se utiliza cuando se necesita la intervención humana para aprobar o supervisar la automatización. Como resultado, cualquier flujo posterior a las tareas de Action Center debe tener en cuenta tanto la aceptación como el rechazo.

4. Further architectures

Pueden existir otras decisiones arquitectónicas y ser apropiadas en función de las necesidades de automatización:

• Siempre se puede considerar un finalizador para cualquier limpieza necesaria dentro de un proceso.
• Se puede considerar que un informador que se ejecuta con poca frecuencia o ad-hoc envíe estadísticas de automatización a las partes interesadas necesarias
• Los procesos de extracción, transformación y carga (ETL) podrían combinar datos de múltiples fuentes en un gran repositorio central.
• Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.

Process best practices

Es necesario seguir estas mejores prácticas al desarrollar cualquier proceso de UiPath para un acelerador de soluciones:

• Follow the out of the box Workflow Analyzer rules. When analyzed with this tool, your project should raise minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • No debe haber retrasos codificados.
  • Ninguna actividad debe tener nombres predeterminados.
  • Dos actividades no deben tener el mismo nombre dentro de un flujo de trabajo.
  • Los argumentos deben seguir la convención de nomenclatura in_, out_ y io_.
  • Las actividades profundamente anidadas no deberían existir y deberían considerarse un argumento sólido para dividir el flujo de trabajo en componentes más pequeños.
• Antes de iniciar el desarrollo, analiza a fondo los requisitos del proceso y diseña una solución que aborde las necesidades específicas. Divide el proceso en tareas más pequeñas e identifica las dependencias para garantizar un flujo de trabajo claro y eficiente.
• Identifique componentes o flujos de trabajo reutilizables que puedan mantenerse fácilmente y reutilizarse en otros proyectos y separarlos desde una etapa temprana. Este enfoque modular mejora la reutilización, simplifica la depuración y promueve la escalabilidad.
• Implemente mecanismos sólidos de manejo de errores para manejar con gracia las excepciones y los fallos. Utiliza bloques try-catch y proporciona mensajes de error informativos para ayudar en la resolución de problemas y mejorar la estabilidad del proceso.
  • Los errores deben ser específicos y mostrar un mensaje de error relevante. No se debe lanzar una excepción de puntero nulo si se debe rellenar una cadena, pero no como resultado del valor devuelto por una aplicación; la excepción debe clasificarse como una excepción de regla empresarial causada por la aplicación.
• Incorpora ajustes configurables en tu proceso, como parámetros de entrada, para permitir flexibilidad y adaptabilidad. Esto permite a los usuarios personalizar fácilmente el proceso en función de sus requisitos específicos sin modificar el flujo de trabajo principal.
• Valide las entradas para asegurarse de que cumplen los criterios necesarios y maneje las excepciones para datos no válidos o inesperados. Implemente técnicas adecuadas de manejo de datos, como la limpieza y transformación de datos, para garantizar un procesamiento preciso y confiable.
• Incorporar mecanismos de registro para capturar información relevante durante la ejecución del proceso. Esto ayuda a la resolución de problemas y proporciona información valiosa para la optimización del proceso. Utiliza herramientas de depuración para identificar y resolver problemas de forma eficiente.
  • También se deben considerar los mecanismos de registro para los informes y UiPath Insights.
• Pruebe exhaustivamente el proceso para garantizar su funcionalidad y fiabilidad. Utiliza casos de prueba y datos para validar los resultados esperados y manejar casos extremos. Esto ayuda a identificar y corregir cualquier error o inconsistencia antes de la implementación.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Revise y mejore periódicamente sus procesos en función de los comentarios, la evolución de los requisitos y los avances tecnológicos. Busque continuamente oportunidades para optimizar el proceso, mejorar la eficiencia e incorporar nuevas características o funcionalidades.

Library best practices

Es necesario seguir estas mejores prácticas al desarrollar cualquier biblioteca de UiPath para un acelerador de soluciones:

• Follow the out of the box Workflow Analyzer rules. Your project should be able to be run against Workflow Analyzer and have minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • No debe haber retrasos codificados.
  • Ninguna actividad debe tener nombres predeterminados.
  • Ninguna actividad debe tener el mismo nombre dentro de un flujo de trabajo.
  • Los argumentos NO deben seguir la convención de nomenclatura in_, out_ y io_, ya que esos argumentos aparecerán como propiedades cuando se cree la biblioteca. La regla predeterminada del analizador de flujo de trabajo para los nombres de argumentos no válidos puede ignorarse al crear una biblioteca.
  • Las actividades profundamente anidadas no deben existir y deben considerarse para dividir el flujo de trabajo en componentes más pequeños.
• Cualquier interacción de IU debe ocurrir solo a través del Repositorio de objetos.
• Divide tu biblioteca en componentes modulares más pequeños que se centren en tareas o funcionalidades específicas. Esto promueve la reutilización y permite un mantenimiento y actualizaciones más fáciles.
• Proporciona documentación completa para tu biblioteca reutilizable, incluidas las instrucciones de uso, las descripciones de entrada/salida y cualquier dependencia o requisito previo. La documentación clara ayuda a los usuarios a entender cómo utilizar la biblioteca de forma eficaz.
• Error Handling: Implement robust error handling mechanisms within the library to handle exceptions and failures gracefully. Use try-catch blocks and supply informative error messages to aid in troubleshooting.
  • Los errores deben detectarse dentro de los procesos del Acelerador de soluciones y no procesarse dentro de la Biblioteca
  • Cualquier excepción empresarial debe lanzar una excepción de regla empresarial. Cualquier excepción de la aplicación debe lanzar una excepción del sistema
• Confirme las entradas y maneje los casos límite para garantizar que la biblioteca funcione correctamente y evite errores inesperados o resultados no deseados. Una validación de entrada adecuada mejora la fiabilidad y la estabilidad de la biblioteca.
  • Esto también se aplica a cualquier salida de automatización de API.
• Pruebe exhaustivamente el proceso para garantizar su funcionalidad y fiabilidad. Utiliza casos de prueba y datos para validar los resultados esperados y manejar casos extremos. Esto ayuda a identificar y corregir cualquier error o inconsistencia antes de la implementación.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Revise y actualice periódicamente su biblioteca para incorporar comentarios, corregir errores y mejorar la funcionalidad en función de los requisitos en evolución. La mejora continua garantiza que la biblioteca siga siendo relevante y eficaz a lo largo del tiempo.
• Al actualizar las bibliotecas, diseña tu próxima actualización teniendo en cuenta la compatibilidad con versiones anteriores.

Ejemplo

Cambio no disruptivo: ampliar una biblioteca con un nuevo flujo de trabajo.

Cambio potencialmente disruptivo: ajustar un flujo de trabajo existente.

Si no está seguro, pruebe la compatibilidad con versiones anteriores con una versión intermedia y, si es necesario, mueva la actualización a un nuevo flujo de trabajo o biblioteca que podría ser consumido por separado solo por aquellos procesos que requieren la actualización. Con el tiempo, el antiguo flujo de trabajo puede considerarse obsoleto.