RPA Pruebas de velocidad del robot de software

Introduccion


Hace unos días, en un evento interno, mis colegas y yo discutimos el tema de la robotización de procesos en proyectos para implementar un EDMS. Las noticias de RPA y las revisiones de proveedores dicen que podemos reemplazar el conector API con un robot de software. Es decir, use un RPA para transferir grandes cantidades de datos.

Los escépticos creen que el RPA es una "muleta", ersatz. Y si la situación requiere una interacción completa de las aplicaciones, el RPA no funcionará y aún necesita un conector API.
Nuestros vendedores y especialistas de la implementación cumplen con la tarea de migración de datos en cada proyecto.

Un rasgo característico de la migración es un gran volumen y un período muy corto. La compañía está lista para asignar para esto solo 2-3 días. Los especialistas en implementación se preparan con mucho cuidado, literalmente planean su trabajo en minutos. Los desarrolladores preparan utilidades.

Se planteó una pregunta lógica: ¿en qué momento el robot podrá arrastrar al menos varios miles de registros de una base de datos a otra?

En un artículo anterior ( enlace ), analizamos las RPA de Automation Anywhere. Esta vez probaremos el robot de otro estudio conocido: UiPath RPA. Pondremos a prueba la velocidad del trabajo: transfiera 64 mil registros de una base de datos a otra.

A modo de comparación, haremos esto de varias maneras:
  • conector API de bajo nivel en el YP;
  • robot a través de la API incorporada;
  • un robot a través de un archivo intermedio de Excel en la tarjeta de formulario de la base final;
  • un robot desde el formulario de la tarjeta fuente hasta la tarjeta de formulario base final;
  • manos de tarjeta en tarjeta.


El resultado puede ser útil para "pensar" a los desarrolladores, administradores y todos los que buscan una manera de establecer la interacción de software disparejo, evitando la programación profunda.

Además, describimos algunas de las características de UiPath RPA que conocimos en nuestro mini estudio.

En este artículo bajaremos la economía: este tema merece una consideración separada y detallada. Solo indicaremos las circunstancias específicas de cada escenario.

Entonces, la tarea: transferir la lista de contactos de la base de datos de origen a la base de datos de destino.
El número de registros: 64,000 piezas. Cada entrada contiene Nombre, Apellido, Correo electrónico, Organización.
Las bases de datos de origen y destino son simples bases de datos de MS Access con una tabla para almacenar contactos y un formulario para mostrar un contacto individual.

Una breve descripción de cada escenario.


Conector API


Se espera que el desarrollador posea competencias API para ambos sistemas y tenga acceso a la base de datos. En nuestro ejemplo, escribiremos un conector en el lenguaje VBA incorporado de MS Access.
Los nombres de los campos en la fuente y el receptor pueden no coincidir: en el código nosotros mismos configuramos qué datos toma el conector de la fuente y dónde los escribe en el receptor.
El programa transfirió la cantidad total de datos en 26 segundos.

API Robot


Se espera que el robot pueda configurar el administrador del sistema actual. Para hacer esto, debe tomar un curso de capacitación en desarrollo de RPA, la capacitación es gratuita para muchos proveedores.
No se requiere un conocimiento profundo de DAO. Para trabajar con bases de datos en el nivel "bajo", el RPA tiene un conjunto de comandos especiales: actividades de base de datos. UiPath establece la configuración de conexión requerida utilizando el asistente en sí. Tomamos la línea de la consulta SQL directamente del diseñador de consultas de Access.

El punto principal es que los encabezados de campo deben coincidir en las bases de datos iniciales y finales. En este caso, el orden de los campos en la solicitud no es importante.
El robot arrastró todo el volumen en 1 minuto y 52 segundos. Aunque es más largo que el conector API, el orden sigue siendo acorde.

Robot a través de Excel


Según la mayoría de los DBMS, puede exportar datos a algún formato intermedio: xls, xlsx, xml, html, csv. El robot UiPath puede trabajar directamente con dichos archivos a través de las Actividades integradas.

Se espera que el desarrollador de RPA esté familiarizado con la interfaz del programa fuente para cargar datos en un archivo intermedio. También necesita conocer la GUI del programa receptor de datos. Es decir, un administrador capacitado hará frente a la tarea.

Exportamos la lista de todos los contactos a un archivo de Excel. Desde Excel, los datos se pueden leer de la siguiente manera:
  • completamente en una variable de tipo DataTable (pero debe tener en cuenta la cantidad de RAM y conocer la estructura de datos de este tipo);
  • pueden ser líneas (se requiere menos memoria);
  • pero puede tomar una celda a la vez (la memoria es casi libre + el ensamblaje del robot es más fácil, no se usa DataTable) Haremos la última opción.

En el lado del sistema final, el robot abre una tarjeta de formulario para un nuevo registro y la llena con datos de Excel.
En 10 minutos y 24 segundos, el robot migró 64 registros. Es decir, ~ 173 horas tomarán una transferencia completa. La razón de esta ralentización es el tiempo de arranque de la GUI en cada operación.

Robot de tarjeta a tarjeta


Se espera que el usuario personalizado pueda configurar dicha transferencia. Solo necesita familiarizarse con el curso simplificado del desarrollo de RPA (1-2 días de estudio). De todos los métodos robóticos, este es el más fácil de desarrollar.
Aquí, el robot actúa como un "clicker" avanzado: encuentre el campo en la tarjeta fuente => tome su valor => encuentre el campo en la tarjeta receptora => inserte el valor => haga clic en "guardar".

Tomamos tarjetas estándar. Access genera dichas tarjetas sin ninguna programación.
Tiempo de operación 9 minutos 02 segundos para 64 registros. Es decir, ~ 151 horas para una transferencia completa.

Transporte manual


Se espera que un usuario ordinario del sistema haga frente a esta tarea. El nivel de competencias requeridas es el más bajo: solo el conocimiento de la interfaz del software fuente y el software receptor es suficiente. No se requiere entrenamiento adicional.

Usamos el mouse y Ctrl + A, Ctrl + C, Ctrl + V, Alt + Tab y las mismas cartas.
La transferencia de 10 registros tomó 5 minutos. Es decir: ~ 533 horas para todo el volumen. Y esto es solo tiempo puro hecho a mano. Y una persona debe descansar, distraerse con otras tareas y corregir los errores de su propio descuido. Si el robot reemplaza a una persona en operaciones con la GUI, entonces el proceso gana en velocidad varias veces.
Los resultados generales se resumen en las tablas a continuación.

Resultados resumidos


imagen

Características de RPA


Varias características que nos encontramos en esta prueba:
  • cuando trabaje con Access en un sistema de 64 bits, debe instalar AccessDatabaseEngine.exe de 32 bits;
  • en el escenario "Robot a través de Excel", el proceso "tropezó" en el campo "Organizaciones" en la tarjeta del destinatario. El campo en la tarjeta y el campo en la tabla en sí es del tipo "Campo con sustitución". Cuando la operación de escritura en este campo se enmarcó en velocidades de obturación de dos segundos, el proceso se estabilizó;
  • El asistente UiPath Studio para conectarse a bases de datos inserta comillas adicionales en la línea de configuración; esto debe verificarse dos veces;
  • en el campo con la consulta SQL, el texto no debe contener un retorno de carro, de lo contrario, UiPath Studio devuelve un error. El texto de la solicitud debe ser una línea;
  • Es muy conveniente cuando hay botones de navegación en el formulario en la tarjeta de formulario: siguiente tarjeta / anterior / primero / último. Con tales botones, es más fácil ensamblar el robot y su funcionamiento será más estable. Esto puede considerarse como una recomendación general para desarrollar una GUI. Por ejemplo, Access en sus formularios de tarjeta proporciona tales facilidades por defecto;
  • al configurar robots, no tuvimos que programar en el sentido habitual. El algoritmo se ensambla a partir de bloques, como un diagrama. Los bloques se configuran en la ventana de propiedades. El concepto de código bajo / sin código realmente funcionó en nuestra tarea;
  • Otro escenario de migración está disponible con RPA, a través de la GUI de escritorio remoto. El robot se inicia localmente y, con la ayuda de CV y ​​OCR, realiza acciones en el terminal. Los datos se pueden transferir directamente a través del portapapeles.


La cuestión sigue siendo la viabilidad económica. Pero la recuperación de la inversión depende en gran medida del proyecto de implementación específico y la disponibilidad de recursos. En el aspecto técnico, obtuvimos buenas impresiones del rendimiento del robot y la conveniencia de las herramientas de desarrollo de RPA.

Source: https://habr.com/ru/post/479930/


All Articles