- Notas relacionadas
- Primeros pasos
- Instalación y configuración
- Proyectos de automatización
- Acerca de la publicación de proyectos de automatización
- Diseñar automatizaciones
- Administrar paquetes de actividades
- Configuración de los Ajustes del Proyecto de Actividades
- Firma de paquetes
- Control
- Importar entidades
- Experiencia de diseño moderna
- Vincular un proyecto a una idea en Automation Hub
- Usar Data Manager
- Dependencias
- Tipos de flujos de trabajo
- Comparación de archivos
- Mejores prácticas de automatización
- Diseño de flujo de trabajo
- Automatización de IU
- Organización del proyecto
- Ciclo de vida de la automatización
- Metodología para reutilizar componentes de IU
- Integración del control de código fuente
- Depuración
- La herramienta de diagnóstico
- Analizador de flujo de trabajo
- Acerca del analizador de flujo de trabajo
- ST-NMG-001: convención sobre nombres de variables
- ST-NMG-002: convención de nombres de argumentos
- ST-NMG-004: duplicación de nombres de visualización
- ST-NMG-005: anulación de variables
- ST-NMG-006: argumentos de anulación de variables
- ST-NMG-008: longitud variable excedida
- ST-NMG-009: variables de datos prefijados
- ST-NMG-011: argumentos de prefijo Datatable
- ST-NMG-012: valores predeterminados de los argumentos
- ST-NMG-016: longitud del argumento excedida
- ST-DBP-002: recuento de Argumentos elevado
- ST-DBP-003: bloque de Catch vacío
- ST-DBP-007: múltiples capas de diagramas de flujo
- ST-DBP-020: propiedades de salida no definidas
- ST-DBP-023: flujo de trabajo vacío
- ST-DBP-024: comprobación de actividad de persistencia
- ST-DBP-025: requisito previo para la serialización de variables
- ST-DBP-026: retraso en el uso de la actividad
- ST-DBP-027: mejor práctica de persistencia
- ST-DBP-028: requisito de serialización de argumentos
- ST-USG-005: argumentos de actividad codificados
- ST-USG-009: variables no utilizadas
- ST-USG-010: dependencias sin utilizar
- ST-USG-014: restricciones de los paquetes
- ST-USG-020: mensajes de registro mínimos
- ST-USG-024: guardado sin usar para más adelante
- ST-USG-025: uso incorrecto de los valores guardados
- ST-USG-026: restricciones de actividad
- ST-USG-027: paquetes necesarios
- ST-USG-028: Restringir la invocación de plantillas de archivo
- ST-USG-032 - Etiquetas obligatorias
- ST-USG-034 - URL Automation Hub
- Variables
- Argumentos
- Espacios de nombres importados
- Automatizaciones codificadas
- Introducción
- Registrar servicios personalizados
- Contextos Antes y Después
- Automatización atendida basada en desencadenadores
- Grabación
- Elementos de la IU
- Flujo de control
- Selectores
- Repo. de objetos
- Extracción de datos
- Automatización de imágenes y texto
- Acerca de la automatización de imágenes y texto
- Actividades con el ratón y el teclado
- Ejemplo de uso de la automatización de ratón y teclado
- Actividades de texto
- Ejemplo de uso de la automatización de texto
- Actividades de OCR
- Actividades de imagen
- Ejemplo de uso de la automatización de OCR y la automatización de imágenes
- Automatizar las tecnologías de Citrix
- Automatización RDP
- Automatización de Salesforce
- Automatización SAP
- Automatización de VMware Horizon
- Registro
- La herramienta ScreenScrapeJavaSupport
- El protocolo WebDriver
- Conjunto de pruebas - Estudio
- Extensiones
- Acerca de las extensiones
- Herramienta SetupExtensions
- UiPathRemoteRuntime.exe no se está ejecutando en la sesión remota
- UiPath Remote Runtime impide que la sesión de Citrix pueda cerrarse
- UiPath Remote Runtime provoca una fuga de memoria
- Las versiones de UiPath Remote Runtime y UiPath Remote Runtime no coinciden
- La extensión de UiPath necesaria no está instalada en la máquina remota
- Configuración de la resolución de la pantalla
- Directivas de grupo de Chrome
- No se puede comunicar con el navegador
- La extensión de Chrome se elimina automáticamente
- Es posible que la extensión se haya dañado
- Comprueba si la extensión para Chrome está instalada y habilitada
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Habilitar el acceso a las URL de archivos y el modo de incógnito
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Chrome
- Extensión de Chrome en Mac
- Directivas de grupo de Edge
- No se puede comunicar con el navegador
- Edge extension is removed automatically
- Es posible que la extensión se haya dañado
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Edge
- Extensión para VMware Horizon
- Complemento SAP Solution Manager
- Add-in de Excel
- Solución de problemas
- Acerca de la resolución de problemas
- Compatibilidad y limitaciones de Microsoft App-V
- Solución de problemas de Internet Explorer x64
- Problemas de Microsoft Office
- Identificación de elementos de la interfaz de usuario en PDF con opciones de accesibilidad
- Reparar Soporte Active Accessibility
- Validation of large Windows-legacy projects takes longer than expected
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.
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.
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.
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.
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.
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.
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:
-
Crea el objeto de aplicación y las pantallas necesarias en el Repositorio de objetos.
-
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). -
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.
- 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.
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
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:
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:
- 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.
To exemplify the creation and usage of a library using Object Repository, we created a use case with the ACME web application.
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:
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.
- Descargar todas las facturas.xaml: extrae todos los elementos de la tabla de facturas dentro de la aplicación y los devuelve como un
-
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.
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:
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.