Metodología para reutilizar componentes de IU

Los proyectos de UiPath tienen dos capas principales:

• Capa de lógica: contiene toda la validación y procesamiento de datos y cualesquiera otras instrucciones lógica necesarias para el flujo del proceso.
• Capa de interacción de GUI: se usa para extraer e introducir datos en la aplicación.

Para evitar problemas relativos a la capacidad de mantenimiento y la reutilización de los componentes, debes separar la capa de interacción de GUI creando una serie de bibliotecas con componentes reutilizables dedicados exclusivamente a la interacción con las interfaces de usuario. De esta manera, puedes crear una biblioteca versátil y robusta fácil de mantener (solo contiene elementos de interacción de GUI y ninguna otra lógica dependiente de proceso) y extremadamente reutilizable (es muy probable que un proceso diferente que automatice la misma aplicación pueda reutilizar al menos algunos de los componentes).

Además, el Repositorio de objetos presentado en la versión 2020.10 de Studio ha ofrecido una forma completamente nueva de crear y gestionar elementos usados en la automatización de IU, lo que es totalmente nuevo a la hora de diseñar automatizaciones de IU escalables y altamente reutilizables.

This article defines a methodology in which we can use libraries and the Object Repository to build easily maintainable and reusable code, describes the architectural principles and best practices behind it, and offers a detailed breakdown of the steps needed to create reusable components, together with a number of examples that use the ACME web application.

General principles

Hay diversos principios de desarrollo de software que se pueden aplicar independientemente del lenguaje de programación o la plataforma usados y que pueden probar ser muy útiles en el contexto del desarrollo de RPA con UiPath Studio.

Separation on concerns

Este es el principio más importante que abordar. La separación de preocupaciones establece que un programa debe separarse en diferentes secciones, de modo que cada sección aborde un problema separado. En nuestro caso, necesitamos establecer capas para nuestra solución, lo que significa que cada sección debe convertirse en una capa. Separar una solución en capas hace posible probar las capas una a una. Para una aplicación de software normal, solemos tener tres capas diferentes:

• Capa de presentación: relativa a la interacción con el usuario, muestra datos y los presenta al usuario. Esta capa no debería contener lógica empresarial. 

  En el contexto de un proyecto de RPA, la capa de interacción de GUI sustituye a esta capa, ya que el objetivo principal de una automatización es interactuar con otras aplicaciones en lugar de con un usuario real.

• Capa de dominio: se refiere a la lógica del dominio, es decir, al dominio de problema general/empresarial que resuelve la aplicación.

  En el contexto de un proyecto de RPA, se trata de la Capa lógica que se refiere a la lógica de la aplicación.

• Capa de persistencia: es donde se almacenan los datos requeridos por la aplicación.

  No se trata de una capa obligatoria en un proyecto de RPA, porque hay casos de uso en los que no hay almacenamiento de datos permanente. Dado el ámbito de este artículo, no trataremos esta capa.

Single responsibility

Another principle we need to take into consideration when designing an RPA project is the single responsibility principle. This means that a XAML file should do one thing and one thing only. This principle is associated with the low coupling and high cohesion principle. This means that the code should be modularized, even though it is layered. Therefore, we can have multiple modules for a single layer.

• El acoplamiento bajo significa que un módulo debería depender de otro módulo lo menos posible. En un proyecto de UiPath obtenemos la modularización usando bibliotecas (puedes encontrar más información sobre esto en la sección de Métodos).
• Alta cohesión significa que las acciones asociadas con la misma aplicación deberían mantenerse en el mismo módulo.

Aprovechamiento del Repositorio de objetos

An RPA process can be simply defined as a combination of data, data manipulation, and application interaction.

• Data - Pre-defined data types selected when defining variables or arguments, or your own types that you can import and use in Studio. In addition, the Data Service feature introduced in v2020.10 offers a centralized location where you can create data types and reuse them across automations.
• Data manipulation - This can de done through activities which are the building blocks of automation and/or data manipulation expressions. Activities are available in packages that you can install in Studio. You can also create your own custom activities when certain functionalities are not covered by the available packages. For more information about how you can build custom UiPath activities, see Creating a Custom Activity.
• Application interaction - This can be done through UI Automation or integrations/APIs. UI Automation can be used for most applications available today. UI interaction components can be reused with the help of libraries or the Object Repository.

El Repositorio de objetos tiene una estructura jerárquica donde cada nodo representa pantallas o elementos, todo ello bajo el nivel de la aplicación. La estructura es la siguiente:

• Aplicación de IU es la aplicación de destino que puede tener varias versiones y cada versión puede tener múltiples pantallas.
• Pantalla es un ámbito de la IU que agrupa varios elementos pertenecientes a la misma pantalla. El ámbito de la IU se extrae de actividades dentro del flujo de trabajo o se genera en tiempo de captura de elementos.
• El Elemento de la IU contiene selectores completos o parciales, selectores de anclaje, contexto de captura de imagen de pantalla y otros metadatos que describen el elemento de la pantalla.
• Descriptores de IU es un superconjunto de selectores que mantiene información de elementos de identificación única en la pantalla. Se extraen de actividades del flujo de trabajo y se añaden al esquema estructurado que los agrupa por Aplicación, Versión de aplicación, Pantallas y Elementos de IU. De la estructura taxonómica, solo las Pantallas y los Elementos mantienen la información de descriptor, mientras que el resto se usa para agrupar y su rol es garantizar las actualizaciones entre las versiones de una aplicación.

Por ejemplo, en la siguiente imagen podemos identificar:

• Aplicación de IU: versión 1.0.0 de ACME.
• Pantallas: panel de control, facturas, inicio de sesión.

• Elementos de IU: correo electrónico, botón de inicio de sesión.

  
  

  

  
  

Para cada elemento y pantalla del Repositorio de objetos, proporciona los siguientes detalles:

• El nombre exacto de la pantalla, página o elemento, tal como aparece en la IU (por ejemplo, botón de inicio de sesión).
• El tipo, por ejemplo Botón o Entrada (solo para elementos).
• Una descripción opcional. Recomendamos añadir una breve descripción de cómo se puede usar el elemento (por ejemplo, Haz clic para completar el proceso de inicio de sesión).

• Descriptor de IU: información que identifica de forma única el elemento. Incorpora selectores clásicos, selectores difusos y automatización basada en imágenes. Recomendamos utilizar automatización basada en imágenes solo si los otros métodos no funcionan.

  
  

  

  
  

See About Object Repository for more information on how to use the Object Repository.

Scaling up by combining workflow libraries and the Object Repository

El Repositorio de objetos puede afectar significativamente a la facilidad y la eficiencia del diseño de automatizaciones de IU, pero para aprovechar por completo esta característica puedes incorporar los elementos del Repositorio de objetos a un proyecto de biblioteca independiente que también incluya todas las interacciones de IU que deben diseñarse. Esto te permite diseñar proyectos que no contengan interacciones de IU y que solo incluyan la lógica de las automatizaciones.

Recomendamos diseñar una biblioteca para cada aplicación que planees automatizar e incluir en ella todas las interacciones de IU y elementos del Repositorio de objetos. La actividad de biblioteca se puede llamar, entonces, desde un archivo de flujo de trabajo que sea parte de la capa de lógica (el proyecto principal). Esto garantiza que:

• Los cambios en la interacción de la IU no afectarán a la lógica de la aplicación. Esto se puede comparar con una separación de controlador de vista de modelo en la que, en nuestro caso, la capa de modelo se refiera principalmente a los datos pasados desde el controlador a la vista.
• Una vez publicada una biblioteca y creado un paquete, se puede hacer referencia a ellos en diferentes proyectos sin tener que reescribirlos cada vez y sin tener que copiar y pegar código entre diversos proyectos. Si se produce algún cambio en la interacción de la IU se puede actualizar la biblioteca, publicar una nueva versión, y actualizar todos los proyectos para que usen la versión más reciente. Además, los cambios que se pueden producir en la capa de lógica no afectarán a la interacción de la IU.
• Como Orchestrator puede almacenar varias versiones de la misma biblioteca, si debe volver a usarse una versión más antigua, se recuperará fácilmente. De esta manera se pueden utilizar diferentes versiones de la biblioteca en diferentes proyectos, y un proyecto de automatización único puede cambiar instantáneamente entre diferentes versiones de la misma biblioteca.

Usando esta metodología, el principal proyecto de automatización (el controlador) contendrá toda la lógica dependiente de procesos e interactuará con la IU aprovechando los flujos de trabajo dentro de la biblioteca (que se puede considerar como una seudovista). Finalmente, el modelo está representado por los argumentos que nos ayudan a pasar datos entre estos dos componentes.

Creating a UI library

Sigue estos pasos para crear una biblioteca de IU como se describió anteriormente:

1. Analiza tu proceso y divídelo entre los pasos que contiene

We recommend creating a flow diagram to visualize the process.

2. Asigna cada uno de los pasos a una categoría

En función de la capa a la que pertenece, asigna cada paso bien a la categoría de capa de GUI o a la categoría de capa de lógica. Por ejemplo:

• Asigna pasos como Hacer clic, Escribir en y Obtener texto a la capa de interacción de GUI.

  Consejo: no añadas actividades individuales a la biblioteca, añade solo acciones más complejas como hacer clic hasta que algo aparezca en la IU, navegar por todas las páginas de una tabla y extraer todas las filas, o una acción más compleja como iniciar sesión, que consta de varias partes de interacción de GUI más pequeñas. Como norma general, cada componente que añades a una biblioteca debería ser una acción, una parte más compleja de una automatización que implica varias actividades, en lugar de una actividad de automatización de IU única.

• Asigna acciones como procesamiento de archivos, validación y filtrado de datos, manejo de excepciones empresariales a la capa de lógica. Ten en cuenta que la capa de lógica debe llamar a la capa de GUI para poder realizar sus pasos.

3. Crea una biblioteca independiente para cada aplicación usada en la automatización

4. Rellena y publica las bibliotecas de la IU

Para cada biblioteca que crees haz lo siguiente:

1. Crea el objeto de aplicación y las pantallas necesarias en el Repositorio de objetos.

   
   

   

   
   

2. Para cada pantalla del Repositorio de objetos, crea los elementos necesarios y construye sus descriptores.

   
   

   

   
   
   Nota: si no puedes usar el Repositorio de objetos, sigue el mismo procedimiento, pero omite los dos pasos previos (4-1 y 4-2).

3. Desarrolla un archivo XAML para cada acción necesaria. Se pueden añadir pantallas y elementos como nuevos archivos de flujo de trabajo, de modo que este paso se puede realizar de forma intercambiable con los dos pasos anteriores.

   Por ejemplo, estos son algunos de los componentes construidos para automatizar los Procesos de prueba de Acme.

   
   

   

   
   
4. Publica la biblioteca en Orchestrator on en una fuente local de NuGet.

5. Instala las bibliotecas en tus proyectos de automatización

Instala las bibliotecas necesarias desde la ventana Gestionar paquetes para añadirlas como dependencias del proyecto. Cada flujo de trabajo dentro de las bibliotecas está disponible como una actividad en el panel Actividades. Puedes arrastrarlos y soltarlos en el flujo de trabajo del proyecto y usarlos de la misma manera que usas actividades.

Mejores prácticas

Argumentos

• Nombra los argumentos usando el estándar PascalCase. Este es el estándar utilizado para los parámetros de actividades en las bibliotecas de UiPath Studio.
• No incluyas prefijos in_, out_, io_` en los nombres de argumentos porque aparecerán como propiedades de las actividades en la biblioteca.

  Por ejemplo, los argumentos podrían parecerse a los de la siguiente imagen. Si echas un vistazo a tu componente publicado, puedes ver que tus argumentos ya están separados en diversas categorías en función de su tipo, así que añadir el prefijo sería redundante.

  
  

  

  
  
• Todos los flujos de trabajo dentro de una biblioteca de GUI que abren/inician la aplicación para automatizar (por ejemplo, una actividad que abre e inicia sesión en la aplicación) deben devolver la ventana de la aplicación resultante usando bien un argumento de tipo UiPath.Core.UiElement para la experiencia de diseño moderno, o UiPath.Core.Window o UiPath.Core.Browser para la experiencia clásica. Además, tanto para la experiencia clásica como para la moderna, todas las demás actividades del paquete deben tener un argumento interno de tipo UiPath.Core.Window o UiPath.Core.Browser que indicará la ventana correcta en la que la acción actual debe realizarse. Esto es extremadamente útil si tienes varias instancias de una aplicación abiertas durante el runtime de los procesos. Si usas la experiencia de diseño clásica, no envíes selectores como argumentos.

Developing a library of automation components for the ACME website (you can download example library below) requires a component which opens the browser and performs the login operation. This activity should take as arguments the username, password, site URL, and return the Browser element. Optionally, to support a scenario in which the login takes place in an existing window, the browser can be sent as an in/out argument.

El elemento de explorador es de tipo UiPath.Core.UiElement:

Así es como deben aparecer los argumentos:

Al construir el flujo de trabajo que abre el explorador (por ejemplo, el flujo de trabajo del Inicio de sesión), debes comprobar primero si el argumento del explorador es nulo y, en caso de que esto sea cierto, abrir <https://acme-test.uipath.com/> en un explorador nuevo en un flujo de trabajo independiente:

Después de realizar el inicio de sesión y de que el elemento de Explorador se pase al proceso, todas las demás actividades de esta biblioteca requerirán este parámetro. Por ejemplo, la actividad que descarga todas las facturas desde el sitio web tendrá los siguientes parámetros:

Si no se pasa un explorador válido a esta actividad, la ejecución da lugar a un error.

Administración de errores

• Dentro de una biblioteca, arroja siempre errores cuando aparezcan, no los señales mediante argumentos de salida.
• Al final de un componente de biblioteca recomendamos validar su resultado. Comprueba si la acción deseada tuvo lugar y arroja una excepción si no lo ha hecho.

Ejemplo

Al crear un componente que realiza el inicio de sesión de la aplicación es posible que quieras arrojar una excepción si el inicio de sesión no se realiza correctamente. Para lograr esto, después de escribir las credenciales y hacer clic en el botón Inicio de sesión, añade una actividad Comprobar estado de aplicación (al usar la experiencia de diseño moderna) o una actividad Elemento existe (al usar la experiencia de diseño clásica) con un tiempo de espera de 10 segundos, que compruebe si aparece la etiqueta de "Bienvenida...". Si esta actividad devuelve false, significa que el proceso de autenticación no tuvo éxito y se arroja una excepción:

Estructura y nombramiento

Crear un componente para cada actividad significa que tu biblioteca se hará muy grande muy pronto. Para permitir que tus desarrolladores los identifiquen fácilmente en el panel de actividades, es esencial definir un estándar de nominación de los componentes. El estándar que recomendamos para nombrar componentes es {Acción} {Entidad usada por actividad}. Este estándar:

• Permite a los desarrolladores buscar un componente por su nombre, por la acción realizada por esta actividad o por la entidad usada durante esta acción.
• Hace que sea muy fácil entender para qué se puede usar el componente y con qué páginas de la aplicación interactúa.

En algunos casos, puedes usar simplemente {Acción}. Puedes hacer esto si la acción no se realiza en una entidad (por ejemplo, Iniciar sesión) o si necesitas dar más información mediante el nombre añadiendo más atributos al nombre, cada uno separado por un espacio.

Además, recomendamos crear una estructura de carpetas dentro del proyecto de biblioteca y agrupar componentes similares en la misma carpeta. Una regla de oro es disponer de una carpeta por cada entidad principal con la que interactúas dentro de la capa de GUI. Si hay un gran número de entidades con las que puedes interactuar en una aplicación, se puede usar una estructura de carpetas multicapa. Esto mejora en gran medida la cohesión de tu biblioteca y hace más fácil ver las posibles acciones que se pueden aprovechar para cada entidad.

Puedes nombrar las carpetas usando el nombre de la entidad con la que interactúan los componentes {Entidad usada por actividad} o la actividad general que realizan {Acción}. Por ejemplo, si quieres crear una carpeta donde guardar todos los componentes que navegan por las páginas de una aplicación web, puedes llamarla Navegación).

También hay que aplicar una convención de nomenclatura a las entidades del Repositorio de objetos como pantallas o elementos, preferiblemente la misma que en el caso de flujos de trabajo y carpetas, PascalCase.

Ejemplo

El sitio web de ACME (https://acme-test.uipath.com/)contiene varias páginas que permiten a los usuarios interactuar con entidades tales como Elementos de trabajo, Cheques, Cuentas, Vendedores, Facturas, etc.

Al crear una biblioteca con componentes que interactúan con los elementos mencionados anteriormente en el sitio web de ACME, puedes crear una estructura de carpetas y nombrar los flujos de trabajo de la biblioteca como en la siguiente imagen:

Nota: recomendamos usar el estándar Caso de título para los nombres de cada componente/carpeta (Nombre de aplicación, Acción, Entidad usada por actividad).

Approach for larger solutions

En proyectos de automatización mayores, varios componentes dentro de una biblioteca pueden tener una parte de código muy similar o incluso idéntica. En este caso, deberías aislar este componente en un flujo de trabajo independiente y, si no quieres que este flujo de trabajo sea accesible desde fuera de la biblioteca, marcarlo como ignorado desde publicación para hacer que sea privado.

Además, es posible que la misma lógica deba ser implementada entre varios procesos. En este caso, la parte de lógica reutilizable debería aislarse en una biblioteca independiente.

El siguiente diagrama ofrece una descripción general de cómo sería una solución como esta:

Beneficios

• Construye solo una capa sin interferir con la otra.
• Reutiliza el código existente sin tener que volver a escribirlo cada vez que se usa.
• Cambia fácilmente la interacción de IU cuando se produce una actualización de la aplicación y envía el cambio a todos los procesos usando la biblioteca sin tener que volver a publicarlos.
• Compartir la capa de interacción de IU entre varios procesos significa que el mismo módulo se prueba más a fondo y que se puede hacer cualquier corrección para todos los procesos al mismo tiempo, lo que da lugar a automatizaciones más robustas y fiables.
• Tener una biblioteca de interacción de GUI dedicada hace que sea muy fácil construir proyectos de automatización de prueba para probar la automatización de IU para aplicaciones concretas, por tanto garantizando que el código es muy fácil de probar y que los cambios que rompen la aplicación se detectan rápidamente.

Example projects

To exemplify the creation and usage of a library using Object Repository, we created a use case with the ACME web application.

Librería

La biblioteca que contiene todas las actividades de automatización ACME se llama Acme_ObjectRepository.Puedes encontrar la versión más reciente a continuación:

Download library project

Download library package

Aunque la biblioteca es un módulo centrado en la interacción con la aplicación web ACME, también está modularizada y organizada en varias carpetas, en función de su propósito:

He aquí un desglose rápido de los componentes de la biblioteca:

• Inicio de sesión Acme.xaml: inicia sesión en la aplicación. Contiene los siguientes argumentos:

  • Cuatro argumentos de entrada (URL, nombre de usuario, contraseña, tiempo de espera deseado).

  • El tipo de argumento In/Out del Explorador de UiPath.Core.UiElement Este componente se adjuntará a cualquier ventana ACME que ya esté abierta, o abrirá una nueva ventana del explorador si no hay una abierta ya y realizará el inicio de sesión. El parámetro del explorador devolverá la ventana del explorador y esta variable se pasará a todos los demás componentes de la biblioteca.

    
    

    

    
    
• Cierre de sesión Acme.xaml: invoca el flujo de trabajo Navegar a página de inicio desde el módulo de Navegación y posteriormente finaliza la sesión actual. 

• Módulo de opciones de usuario: contiene las opciones que pueden cambiar las configuraciones de la cuenta actual dentro de la aplicación web de ACME. 

  • Restablecer datos de prueba.xaml: restablece los datos de prueba usados en la aplicación de ACME.

• Módulo de facturas: contiene las acciones realizadas en las facturas encontradas en los datos de prueba.

  • Descargar todas las facturas.xaml: extrae todos los elementos de la tabla de facturas dentro de la aplicación y los devuelve como un DataTable.
  • Descargar facturas por ID fiscal de vendedor.xaml: navega por toda la tabla de facturas hasta que encuentra una factura con una ID fiscal concreta, que entonces devuelve. 

• Módulo de navegación: contiene flujos de trabajo que navegan por las diferentes páginas de la aplicación web

  • Los componentes de este módulo son utilizados principalmente por los otros flujos de trabajo de la biblioteca, y generalmente no deben invocarse directamente desde nuestro proceso principal. Sin embargo, se marcan como Publicables porque podrían ser útiles en procesos attended donde querríamos que el robot navegue hasta una página concreta y luego permita al usuario interactuar con la aplicación.

• Módulo de elementos de trabajo: contiene las acciones que tienen lugar en los elementos de trabajo encontrados en la aplicación.

  • Descargar todos los elementos de trabajo.xaml: descarga todos los elementos de trabajo en los datos de prueba.

Proceso

Download process

El proyecto principal, AcmeProcess_ObjectRepository, consta de cuatro casos de uso diferentes. Requiere que el usuario cree una credencial de Windows de tipo Genérico llamada ACMETest, que guarda el nombre de usuario y la contraseña con la que el robot iniciará sesión en la aplicación web de ACME.

Los componentes de caso de uso de este proyecto realizan diversas tareas usando los diversos componentes construidos en la biblioteca de componentes de la IU de ACME.

Cuando se invoca el flujo de trabajo Main.xaml, el robot iniciará sesión en la aplicación ACME, entonces un cuadro de diálogo solicitará al usuario que seleccione uno de los casos de uso, y luego invocará el flujo de trabajo correspondiente a la elección del usuario:

Testing project

Download testing project

El proyecto de prueba, Test_UiPath.AcmeProcess_ObjectRepository, consta de cinco casos de prueba diferentes que prueban diferentes funcionalidades del proceso: inicio de sesión/cierre de sesión, descarga de todas las facturas/descarga de facturas por ID fiscal del proveedor, descarga de elementos de trabajo.