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.

Este artículo define una metodología en la que podemos utilizar bibliotecas y el Repositorio de objetos para diseñar código fácilmente mantenible y reutilizable, describe los principios arquitectónicos y las mejores prácticas tras ella, y ofrece un desglose detallado de los pasos necesarios para crear componentes reutilizables, junto con diversos ejemplos que usan la aplicación web ACME.

Principios generales

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.

Separación en referencias

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.

Responsabilidad única

Otro principio que debemos tener en cuenta al diseñar proyectos de RPA es el principio de responsabilidad única. Esto significa que un archivo XAML debe hacer una cosa y solo una única cosa. Este principio está asociado con el principio de acoplamiento bajo y alta cohesión. Esto significa que el código debe estar modularizado, incluso aunque vaya en capas. Por tanto, podemos tener varios módulos para una única capa.

• 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

Un proceso RPA puede definirse simplemente como una combinación de datos, manipulación de datos e interacción con aplicaciones.

• Datos: tipos de datos predefinidos seleccionados al definir variables o argumentos, o tus propios tipos que puedes importar y usar en Studio. Además, la característica de Data Service presentada en la versión 2020.10 ofrece una ubicación centralizada donde puedes crear tipos de datos y reutilizarlos en diversas automatizaciones.
• Manipulación de datos: puede realizarse mediante actividades que son los componentes básicos de la automatización y/o expresiones de manipulación de datos.Las actividades están disponibles en paquetes que puedes instalar en Studio. También puedes crear tus propias actividades personalizadas cuando ciertas funcionalidades no están cubiertas por los paquetes disponibles. Para obtener más información sobre cómo construir actividades de UiPath personalizadas, consulta Creación de una actividad personalizada.
• Interacción con la aplicación: puede realizarse mediante la automatización de la interfaz de usuario o mediante integraciones/API. UI Automation puede utilizarse para la mayoría de las aplicaciones disponibles en la actualidad. Los componentes de interacción de la interfaz de usuario pueden reutilizarse con ayuda de bibliotecas o del repositorio de objetos.

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.

  
  

  

  
  

Consulta Acerca del Repositorio de objetos para obtener más información sobre cómo utilizar el Repositorio de objetos.

Ampliación mediante la combinación de bibliotecas de flujos de trabajo y el Repositorio de objetos

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.

Creación de una biblioteca de IU

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

Recomendamos crear un diagrama de flujo para visualizar el proceso.

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.

El desarrollo de una biblioteca de componentes de automatización para el sitio web de ACME (puedes descargar la biblioteca de ejemplo a continuación) requiere un componente que abre el explorador y realiza la operación de inicio de sesión. Esta actividad debe tomar como argumentos el nombre de usuario, la contraseña, el URL del sitio y devolver el elemento del explorador. De forma opcional, para admitir un escenario en el que el inicio de sesión tiene lugar en una ventana existente, el explorador puede enviarse como argumento In/Out.

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

Enfoque para soluciones más grandes

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.

Proyectos de ejemplo

Para ejemplificar la creación y el uso de una biblioteca mediante Object Repository, hemos creado un caso de uso con la aplicación web ACME.

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:

Descargar proyecto de biblioteca

Descargar paquete de biblioteca

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

Descargar proceso

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:

Proyecto de prueba

Descargar proyecto de prueba

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.