Como usar RPA para subir 300.000 registros a FileMaker Cloud en 35 minutos o menos

Updated: Mar 24, 2020


Transporta data en vivo, rápido
Cola RPA

Bienvenido a nuestra primera publicación de blog multilingüe, dirigida a ustedes en español, inglés, italiano y "digital". Hoy, discutimos cómo realizar cargas masivas, actualizaciones y eliminaciones de más de 300,000 registros en FileMaker Cloud / FileMaker Server en aproximadamente 35 minutos en vivo y de manera segura, sin incurrir ningún tiempo de inactividad. Aférrense a sus sombreros, este blog está definitivamente destinado para aquellas "clavijas cuadradas en agujeros redondos".


El problema

Ya sea en las instalaciones locales o en la nube, la mayoría de las bases de datos multiusuario a menudo requieren rutinarias cargas, actualizaciones o descargas de grandes conjuntos de datos. Muchas veces estos datos originan en otros sistemas y son recibidos en forma de un archivo plano, como por ejemplo un archivo .csv o un archivo ASCII de longitud fija. El método preferido para tales actualizaciones es desconectar la base de datos y realizar toda la importación masiva en modo de usuario único ("offline"), pero ¿y si eso no es una opción?


Algunas aplicaciones están "Siempre activas" las 24 horas del día. En situaciones donde hay tres turnos de trabajo que acceden a tu aplicación durante todo el día, el tiempo máximo de inactividad disponible puede ser menos de una (1) hora, a veces tan corto como 30 minutos. En situaciones extremas, el tiempo de inactividad puede ser inexistente.

¿Cuáles son los desafíos que presentan los procesos de importación típicos? Hay varios factores a considerar:


1. Una importación bloquea una tabla

Operaciones como la importación de registros o la realización de "reemplazar todos" los valores en un campo colocan un bloqueo exclusivo sobre toda la tabla. En una importación de 300,000 registros, eso puede significar que la tabla permanecerá bloqueada durante un período prolongado de tiempo, hasta que se completado la importación.


2. Las importaciones concurrentes en realidad serán más lentas

Si hay múltiples importaciones grandes para realizar en diferentes tablas durante un período de tiempo limitado, tampoco es aconsejable ejecutar dos o más importaciones simultáneas con tal de ahorrar tiempo, ya que el rendimiento de cada importación individual se verá afectado. También puede haber consecuencias no deseadas a causa de dependencias desconocidas tales como uniones entre las tablas (campos ingresados ​​/ calculados automáticamente que vendrían rellenados con información errónea a causa de a cálculos incompletos).


3. Una importación masiva puede dañar los archivos de restauración de inicio

Para agravar el problema está el problema de los registros de transacciones utilizados por el servidor de bases de datos para la restauración de inicio. Al realizar una gran importación, Claris recomienda deshabilitar el registro de transacciones para evitar posibles daños a la base de datos. Desafortunadamente, para deshabilitar el registro de transacciones se requiere un reinicio suave del motor de la base de datos, lo cual anula el propósito de evitar el tiempo de inactividad del servidor.


4. Un guión de importación del lado del servidor toma demasiado tiempo

Aunque es una práctica más segura, en nuestras pruebas una importación de más de 300.000 registros en una sola tabla, puede tomar más de 48 horas en completarse si es programada del lado del servidor, incluso cuando se trata de una tabla estrecha de menos de 40 campos. Si tiene que completar tres importaciones a tres tablas semejantes (aproximadamente 1 millón de registros a subir) y una ventana de tiempo limitado para hacerlo, las matemáticas simplemente no cuadran.


5. El tiempo puede ser esencial

Si bien se pueden lograr resultados similares utilizando ciertas técnicas como el transcambio de tabla mediante la "ventana deslizante" (lo cual se puede lograr a través de la manipulación del gráfico de tablas y el modelo de separación), para cualquier sistema OLTP bajo restricciones de ventana de mantenimiento, el cuello de botella sigue siendo cuánto tiempo toma el subir los datos al servidor. Para situaciones en las que los datos deben estar en línea "ahora", se requiere algo de trabajo pesado.


La solucion

Implementa una cola de guiones con envío por lotes y pausa / reanudo de guión


En vez de ejecutar una importación masiva de toda la data, optamos por CREAR cada registro (uno por uno) utilizando el paso de guión Ejecutar guión en el servidor (conocido por "PSoS"). Los resultados fueron muy positivos, ya que conseguimos poblar una tabla de 34 campos modificables con cerca de 300.000 registros en poco más de 33 minutos (¡hasta desde un iPad!).


Con este enfoque, logramos realizar el equivalente de una "importación masiva" de registros en vivo y sin interrumpir el funcionamiento del servidor (sin bloqueo de tablas, sin desconectar archivos, etc.). El proceso también es de alto rendimiento, ya que numerosas pruebas sobre múltiples servidores FileMaker (tanto virtuales como reales) demostraron un promedio de 145-150 registros por segundo.

Para una mayor funcionalidad de mantenimiento, ampliamos los guiones de bucle de nuestra Cola RPC para incluir la ACTUALIZACIÓN selectiva, las DELECIONES selectivas y, opcionalmente, el paso de TRUNCAR TABLA. Según nuestras pruebas, para ejecutar actualizaciones y eliminaciones de todo registro de la tabla basta toma un par de minutos más que las operaciones originales de crear nuevos registros.


He aquí hay una descripción general de las técnicas que empleamos:

  • Leer desde el archivo de datos: Utilizamos el paso de guión Leer desde el archivo de datos para leer todo el archivo de datos y guardarlo en un campo de texto global de una tabla de trabajo.

  • Fragmentación / procesamiento por lotes: escribimos cálculos y pasos de guión para tronchar el archivo de datos en varios lotes más pequeños que se puedan enviar al servidor como parámetros de guión.

  • Bucle: para acelerar el procesamiento de registros, el bucle se repite desde 1 hasta el número máximo de lotes de datos, disparando consecutivamente y a veloz modo un guión PSoS (en el servidor) por cada lote.

  • Ejecutar guión en el servidor: Al recibir un lote de registros por medio del parámetro, un sub-guión en el servidor recorre todo el lote, procesando rápidamente un registro a la vez. El servidor es capaz de ejecutar varias de estas sesiones de sub-guión al mismo tiempo, lo cual incrementa el rendimiento.

  • Auto-desaceleración: para evitar bloquear el motor de secuencias de guiones del servidor o sobrecargar los recursos del servidor, desarrollamos un mecanismo de autorregulación para pausar / reanudar la cola del lado del cliente.

  • Truncamiento: cuando es necesario limpiar la tabla, eliminando todos los registros y volviéndolos a ingresar, el guión puede opcionalmente truncar tabla.

  • Interrumpibilidad: si es necesario, la cola de secuencias de guiones se puede pausar permanentemente, reanudar o cancelar.

  • Automatización Robótica de Procesos: además de ejecutar tareas a pedido, también habilitamos la ejecución de tareas basada en intervalos de tiempo mediante "Instalar guión OnTimer". Esto transforma tu dispositivo FileMaker en una "robot" para la ejecución básica de tareas automatizadas (RPA).

Y ahora, los detalles


Leer desde el archivo de datos

Si el archivo de datos se encuentra archivado como documento en un campo contenedor, primero es exportado a la carpeta Documentos local del computador, desde donde pueda leerse e insertarse en campo de texto (como texto sin formato) usando Pasos de guión de archivos. Leer una archivo de datos de unos 170 MB e insertarlo en un campo global de texto toma menos de 30 segundos.


Fragmentación / procesamiento por lotes Cuando se trata de ejecutar scripts en el servidor usando grandes cantidades de registros, debes alimentar al servidor "por cucharada" en porciones más pequeñas o el servidor se atragantará al tratar de procesar todo de una sola vez. La fragmentación de datos es una solución de procesamiento por lotes comúnmente utilizada para la sincronización de datos. En FileMaker, la capacidad máxima del parámetro para el comando Ejecutar guión el servidor es de 1 millón de caracteres. Para mayor precaución y gestión, los tamaños de lotes / fragmentos que prepara nuestro guión está limitados a 560.000 caracteres, poco más de la mitad del máximo.

Ejecutar guión en el servidor También conocidos como procedimientos almacenados, la mayoría de las plataformas de bases de datos permiten la ejecución de guiones en el servidor. El motor de guiones FileMaker Server Script Engine (FMSE) implementa esta misma funcionalidad en toda la línea de servidores, y estos se pueden invocar a través del paso de guión Ejecutar guión en el servidor.

Colas La pieza faltante del rompecabezas de la plataforma FileMaker (al menos a partir de este escrito) es la ausencia de una cola de guiones. Sea del lado del cliente o del lado del servidor, por el momento en la plataforma FileMaker no existe un mecanismo para la gestión de sesiones a pedido de ejecución de guiones en el servidor. Existe la Programación de tareas administrativas, pero eso no es lo mismo que una cola de guiones PSoS. La cola de guiones que diseñamos es autocontrolable e interrumpible. Debido a que es más fácil de configurar, monitorear, administrar y cancelar si es necesario, nuestra solución implementa una cola de guiones PSoS del lado del cliente, lo cual significa que para ejecutar estos procesos de actualización de registros se requiere una estación de trabajo dedicada FileMaker (también conocida como un FileMaker Bot).

Monitoreo de carga y auto-desaceleración Al ajustar automáticamente la duración de la pausa del guión durante períodos mayores / menores, nuestra cola de guiones logra gestionar la carga colocada sobre el servidor de la mejor manera posible. En los servidores que admiten la versión 2 de la API REST FileMaker Admin API, la duración de la pausa se determina al monitorear la lista de guiones pendientes. En aquellos servidores que no admiten o no están configurados para aceptar llamadas FileMaker Admin API (si por ejemplo, no tienen certificado SSL), la duración de la pausa del la cola se calcula en función del tamaño de los lotes de datos. La duración de la pausa varía desde 2 segundos hasta 2 minutos, según la carga del servidor, o el tamaño del los lotes (es decir, un estimado de la duración de cada guión PSoS).