Data Loading

Introducción

Carga de datos en el conector

La carga de datos se refiere al tiempo necesario para cargar nuevos datos en el Conector. Esto está determinado por el número de columnas al leer de la base de datos.

Algunos tipos de datos son más rápidos de cargar que otros. En un sentido amplio, el orden es el siguiente.

1. ODBC: esto también depende del controlador y la base de datos.
2. Archivos sin formato: csv’s.
3. Excel: estos archivos contienen una sobrecarga para el uso en Excel, lo que los hace más lentos. Si es posible, utilice archivos de texto en lugar de archivos de Excel. Los archivos de texto son mucho más rápidos.

El script de múltiples archivos es bastante lento para analizar todos los diferentes archivos planos juntos y debe evitarse si es posible. Evite también las API para cargar cantidades masivas de datos.

 

Carga de datos en la aplicación

Los datos se pueden cargar de las siguientes maneras:

• cuando se inicia la aplicación (datos en vivo);
• como resultado de una ejecución de datos programada (datos en caché);
• una combinación de datos en vivo y en caché (carga incremental).

Datos en vivo

En general, los datos en vivo son mucho más lentos, especialmente si hay muchos datos. Los datos en vivo también necesitan acceso continuo a los datos, lo que puede ser un problema durante las horas de producción.

Como pauta general, se recomienda mantener los datos en vivo por debajo de 100 000 eventos. El rendimiento real depende en gran medida de los datos y las fuentes de datos utilizadas.

Es posible recuperar datos en vivo basados en el valor de un filtro. Si se cambia el filtro, se solicitan los nuevos datos. El rendimiento debe tenerse muy en cuenta para este tipo de casos.

Las tablas en vivo se cargan cuando el usuario inicia sesión y / o cambia un control de filtro. Las tablas en vivo suelen dar lugar a problemas de rendimiento. Se recomienda utilizar tablas en caché siempre que sea posible.

Datos en caché

Para los datos almacenados en caché, la hora de inicio de la aplicación es independiente del número de columnas. Cuando los datos se precalculan y se almacenan en caché, se pueden cargar directamente desde la caché cuando se solicite. Extraer datos de los sistemas de origen puede requerir mucho tiempo. Se recomienda programar las actualizaciones de la caché, por ejemplo, fuera del horario de producción.

Además de la extracción de datos, los datos también se transforman al formato interno de UiPath Process Mining y todos los cálculos que no dependen de la entrada del usuario se almacenan en caché.

Para los cálculos que dependen de la entrada del usuario, el estado inicial se almacena en caché. Cuando el usuario cambia un control o filtro que cambia el cálculo, el cálculo se realiza de nuevo. Mantener estos nuevos cálculos al mínimo es muy importante para un buen diseño de aplicaciones.

Carga incremental

De forma predeterminada, UiPath Process Mining no carga datos de forma incremental. Dado que a menudo las mutaciones tienen lugar en los elementos de los sistemas ERP, el archivo de datos no suele ser el enfoque deseado. Por lo tanto, todos los datos se cargan desde el sistema para garantizar que tengamos los últimos cambios en nuestro modelo de datos.

En teoría, los desarrolladores de aplicaciones pueden configurar la carga incremental de datos. Esto requiere suficiente información en la base de datos para determinar qué datos son nuevos y cuáles deben ser consultas. El rendimiento debe considerarse detenidamente. Solo recomendamos utilizar la carga de datos incremental cuando sea absolutamente necesario.

Una alternativa más adecuada es ejecutar cargas incrementales desde el sistema de origen en un lago de datos / almacén usando herramientas especializadas, luego consultar el laga de datos / almacén de UiPath Process Mining. Esto garantiza un bajo impacto en el sistema de origen y comparte los beneficios de las cargas incrementales con toda la organización, en lugar de hacerlo especialmente con UiPath Process Mining.

Scripts externos

En UiPath Process Mining , puede cargar datos a través de scripts usando o por ejemplo Python o R. Estos scripts llamarán a un programa externo para ejecutarse y esta salida se podrá leer de nuevo. UiPath Process Mining proporciona soporte en la interfaz entre nuestra plataforma y el script. UiPath Process Mining no admite problemas con el script real que pueden causar un largo tiempo de ejecución de la herramienta externa.

 

Soluciones

Drivers

Asegúrese siempre de haber instalado las últimas versiones de los controladores ODBC de MSSQL para Windows Server 2016.

Módulo de depuración

A veces no es posible reducir los datos para leer, por ejemplo. cuando los datos de entrada aún no se pueden filtrar. Con una entrada grande en su conector, los tiempos de reacción pueden ser lentos. Para acelerar el desarrollo, puedes añadir módulos a tu aplicación.

Puede usar el código del módulo para asegurarse de que solo en un módulo se lean los datos, mientras que el otro módulo no cargue datos y se pueda usar para realizar cambios en su modelo de datos. De esta manera los cambios se ven afectados sin tener que esperar a que los datos se inicialicen.