Normas de 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	Los conectores de Integration Service prediseñados o las conexiones creadas con Connector Builder deben utilizarse, cuando sea posible, para habilitar la automatización mediante API con una biblioteca de conectores listos para usar, al tiempo que proporcionan una forma estándar de configurar y gestionar conexiones con autenticación estandarizada. 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. Si la automatización de la API no es posible, la automatización de la IU debe estar contenida dentro de una capa de integración de GUI/capa de aplicación como se describe más adelante. Esto debería utilizar el repositorio de objetos dentro de una biblioteca de aplicaciones.
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.

Nota:

A través de estas áreas, un acelerador de soluciones debería proporcionar un marco estructurado pero flexible para crear una solución de automatización eficiente y escalable. En resumen, tu Solution Accelerator debe promover la modularidad, la adaptabilidad, el cumplimiento de las mejores prácticas y la fácil integración con sistemas y aplicaciones para facilitar el rápido desarrollo e implementación de la automatización.

Atención:

Para que un listado se publique en UiPath Marketplace, debe incluir en la Descripción del listado todos los detalles sobre los productos de UiPath que se utilizan en la automatización o que son compatibles con su automatización, y el papel que desempeñan.

Los socios no podrán incluir los nombres de terceros o de aplicaciones u otros productos de terceros en el texto de su listado o descripción del producto en UiPath Marketplace sin la autorización expresa del tercero.

Estándares para aceleradores de soluciones

1. Arquitectura en capas

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. Capa de lógica empresarial (capa de implementación)

• 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. Capa de aplicación

• 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.

Tipos de arquitectura estándar

Procesos transaccionales/basados en colas

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.

Robotic Enterprise Framework es una plantilla de proyecto basada en máquinas de estado. Se ha creado para adaptarse a todas las mejores prácticas relacionadas con el registro, el manejo de excepciones, la inicialización de aplicaciones y otros, y está preparado para abordar un escenario empresarial complejo. La plantilla contiene varios contenedores de estado prefabricados para inicializar aplicaciones, recuperar datos de entrada, procesarlos y finalizar la transacción. Todos estos estados están conectados a través de múltiples transiciones que cubren casi todas las necesidades en un escenario de automatización estándar. También hay múltiples flujos de trabajo invocados, cada uno de los cuales maneja aspectos particulares del proyecto.

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. Procesos de Document Understanding

La mayoría de los procesos que trabajan con documentos tienen en común el requisito de "comprender" también su contenido. Por lo tanto, se ha puesto en marcha un marco dedicado especializado en la comprensión de documentos: el marco de procesos de Document Understanding (DU).

Este marco es esencialmente una plantilla de proyecto de UiPath Studio basada en un diagrama de flujo de procesamiento de documentos típico. El proceso proporciona registro, gestión de errores, mecanismos de reintento y todos los métodos que deben utilizarse en un flujo de trabajo de DU. El flujo de trabajo tiene una arquitectura desvinculada de otras automatizaciones conectadas:

• 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)

• Lógica humana en el bucle (validación) utilizando Action Center para robots desatendidos, o una estación de validación local para robots atendidos

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:

• El distribuidor recopila los documentos que se van a procesar desde la aplicación o el sistema anterior.

• El Proceso de Document Understanding extrae la información necesaria de cada documento de uno en uno con escalabilidad gracias al método Dispatcher.

• Por último, el Ejecutante utiliza los datos extraídos del documento para completar el proceso.

3. Procesos transaccionales con Action Center

Esta arquitectura consta de procesos de distribuidor, ejecutor y finalizador con procesos humanos en el bucle, o flujo de trabajo de larga duración, en algún punto intermedio. La plantilla estándar para flujos de trabajo de larga duración es la Plantilla de proceso de orquestación. Los flujos de trabajo de larga duración tienen las mejores prácticas que deben seguirse para admitir la orquestación de servicios, la intervención humana y las transacciones de larga duración en entornos desatendidos.

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. Otras arquitecturas

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.

• Se pueden considerar otros marcos de automatización como UiPath Attended Framework si son aplicables al proceso.

Mejores prácticas de proceso

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

• Sigue las reglas del Analizador de flujo de trabajo listas para usar. Cuando se analiza con esta herramienta, tu proyecto debería generar advertencias mínimas o nulas. Deben seguirse las convenciones de nomenclatura, las mejores prácticas de diseño, las reglas de mantenimiento y legibilidad y las reglas de uso . Algunos ejemplos clave de esas reglas:

  • 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.

  • Considere la posibilidad de utilizar UiPath Test Suite y proporcionar flujos de trabajo de prueba para su automatización.

• 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.

Mejores prácticas de biblioteca

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

• Sigue las reglas del Analizador de flujo de trabajo listas para usar. Su proyecto debe poder ejecutarse en el Analizador de flujo de trabajo y tener advertencias mínimas, si no nulas. Deben seguirse las convenciones de nomenclatura, las mejores prácticas de diseño, las reglas de mantenimiento y legibilidad y las reglas de uso . Algunos ejemplos clave de esas reglas:

  • 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.

• Gestión de errores: implementa mecanismos sólidos de gestión de errores dentro de la biblioteca para gestionar las excepciones y los fallos con gracia. Utiliza bloques try-catch y proporciona mensajes de error informativos para ayudar en la resolución de problemas.

  • 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.

  • Considere la posibilidad de utilizar UiPath Test Suite y proporcionar flujos de trabajo de prueba para su automatización.

• 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.