Diferentes estados de tareas de integración

Se genera una tarea cada vez que los datos se mueven a través de Alumio y ayuda a rastrear los datos en cada paso del proceso de integración. Proporciona información sobre el estado de la integración, si se ha realizado correctamente, si está en curso, en espera, si se está omitiendo o si se han producido errores. Por lo tanto, además de medir el intercambio de datos dentro de Alumio, las tareas también sirven de base para la supervisión y la solución de problemas de las integraciones.

Por eso, una de las primeras cosas que le muestra el panel de control de Alumio es el estado en tiempo real de sus tareas de integración. Además de mostrarte el número total de tareas que has generado, el monitor de tareas del panel de control de Alumio ofrece una visión general clara de las diferentes etapas del ciclo de vida de una tarea en Alumio. Desglosa el recorrido de los datos que pasan de una aplicación a otra de la siguiente manera:

• Nueva tarea: Cuando los datos se importan por primera vez de una fuente como parte de una ruta, se reconocen como una tarea nueva.
• Tarea de procesamiento: Una vez que Alumio comienza a enviar estos datos a una aplicación de destino, la tarea pasa al procesamiento.
• Tarea finalizada: Si la tarea se completa correctamente, se marca como finalizada.
• Tarea fallida: Si se produce un error durante el intercambio de datos, la tarea se etiqueta como fallida.
• Tarea omitida: En situaciones como las pruebas o cuando es necesario filtrar ciertos datos, las tareas se pueden omitir deliberadamente de forma manual o automatizada.

Exploremos brevemente cómo cada uno de estos estados de tareas es vital para que Alumio iPaaS ayude a agilizar y monitorear todo el proceso de integración en cada paso del camino.

Nueva tarea:

Para integrar datos entre aplicaciones, primero debe recopilar datos de una aplicación de origen (Sistema A) y luego enviarlos a una aplicación de destino (Sistema B). Se genera una nueva tarea cuando Alumio importa correctamente los datos del Sistema A, mediante una configuración entrante, dentro de una ruta.

Al configurar esta configuración entrante, Alumio le permite definir exactamente qué datos recuperar y con qué frecuencia recuperarlos. ¿Necesita extraer todos los datos disponibles o solo partes específicas de una entidad de datos (p. ej., pedidos de una región específica)? ¿Debería convertirse el formato de datos? (p. ej., de XML a JSON)? ¿Con qué frecuencia se deben importar los datos: cada minuto, hora, día o semana? Alumio proporciona transformadores para modificar y estructurar los datos entrantes y un planificador para determinar cuándo y con qué frecuencia se deben recuperar los datos. Esto garantiza que pueda ser muy específico sobre el tipo de datos que desea enviar a la aplicación de destino.

Por ejemplo, al integrar un sistema ERP con una plataforma de comercio electrónico y un sistema PIM, Alumio recupera los datos del producto y crea una nueva tarea, dejándola en cola para su procesamiento. En esta etapa, puede filtrar registros específicos (por ejemplo, solo productos actualizados), estandarizar los formatos (por ejemplo, convertir monedas) y enriquecer los datos (por ejemplo, agregar los atributos que faltan). Esto le permite recopilar y estructurar primero los datos en Alumio antes de decidir cómo transformarlos para diferentes destinos. Puedes asignar las categorías de productos de forma diferente para el sistema PIM y, al mismo tiempo, ajustar los formatos de precios para la plataforma de comercio electrónico, todo desde la misma nueva tarea.

Nota: Si una configuración entrante no está configurada dentro de una ruta (activa), no se creará una nueva taread.

Tareas de procesamiento:

Cuando crea una configuración saliente y ejecuta la ruta en Alumio para enviar los datos que ha extraído de una fuente (sistema A) a una aplicación de destino (sistema B), una nueva tarea se convierte en una tarea de procesamiento.

Como se indicó anteriormente, esta es la razón por la que Alumio no envía (exporta) inmediatamente los datos que extrae (importa) a través de una configuración entrante y los pone en cola como una nueva tarea. Es para que pueda elegir dónde y cómo desea enviar estos datos mediante la creación de una configuración saliente. ¿Necesita filtrar, modificar o asignar el formato de los datos que ha importado para que coincidan con la aplicación de destino? ¿O desea enviar los datos en lotes cada minuto, hora, semana, etc.? Alumio le permite decidir cómo quiere transformar y programar los datos que ha obtenido del Sistema A antes de enviarlos al sistema B.

Como en nuestro ejemplo anterior, programar el envío de los datos que ha extraído del sistema ERP a la plataforma de comercio electrónico crea una tarea de procesamiento. Una tarea de procesamiento pasa a la lista de espera en Alumio y se prepara para enviar los datos cuando esté programada.
‍

Nota: Alumio también permite a los usuarios seleccionar la opción de «procesamiento en tiempo real» al crear una ruta, en el caso de que los datos críticos deban integrarse de inmediato. En este caso, en el momento en que se ejecuta la ruta, se crea directamente una tarea de procesamiento en lugar de una nueva tarea, e inmediatamente busca convertirse en una tarea finalizada.
‍

Tareas finalizadas:

Una tarea de procesamiento se convierte en una tarea finalizada cuando el intercambio de datos entre la aplicación de origen y la aplicación de destino se completa correctamente. Esto significa que Alumio ha enviado correctamente los datos importados al sistema de destino y que las reglas de transformación o programación que configuró se aplicaron sin problemas.

Por ejemplo, si el sistema ERP envía correctamente las actualizaciones de productos a la plataforma de comercio electrónico y todos los datos se han recibido, procesado y almacenado correctamente, la tarea pasa del estado Procesando al estado Finalizada.

Tareas fallidas:

Una tarea de procesamiento se convierte en una tarea fallida si algo impide que el intercambio de datos se procese correctamente. Esto puede deberse a una serie de problemas, como:

• La aplicación de destino (Sistema B) no está disponible temporalmente.
• El formato de datos no coincide con la estructura esperada en el sistema receptor.
• Errores de autenticación o permiso que impiden el intercambio de datos.

Cuando una tarea falla, Alumio proporciona registros de errores y opciones de solución de problemas para ayudarlo a identificar y resolver el problema rápidamente. Puede volver a intentar la tarea una vez que se haya solucionado el problema, asegurándose de que no se pierda ningún dato.

Por ejemplo, si un ERP intenta enviar actualizaciones de productos a un sistema de comercio electrónico, pero falta el campo SKU o tiene un formato incorrecto, la tarea fallará y los detalles del error se registrarán para su revisión. A continuación, puede comprobar los registros para identificar y resolver rápidamente el error y volver a intentar la tarea.
‍

Tareas omitidas:

También hay una «Tareas omitidas» en la iPaaS de Alumio que cuenta las tareas que, por diversos motivos, como las pruebas o las reglas de filtrado predefinidas, se omiten intencionalmente. Una tarea se clasifica como «omitida» cuando Alumio detecta que los datos que se están procesando no necesitan enviarse al sistema de destino. Esto ocurre cuando:

• Los datos ya existen en el sistema de destino y no han cambiado.
• La lógica de integración tiene condiciones que determinan si los datos deben procesarse (por ejemplo, solo enviar nuevos pedidos pero omitir los ya procesados).
• Las reglas de transformación filtran datos específicos antes de que lleguen a la configuración saliente.

Alumio le permite omitir manualmente datos específicos o aplicar reglas para omitir automáticamente datos específicos de forma masiva. Por ejemplo, supongamos que un ERP está configurado para enviar actualizaciones de productos a una plataforma de comercio electrónico cada 10 minutos, pero no se ha realizado ningún cambio en los datos del producto desde la última actualización. Alumio puede reconocerlo y marcar la tarea como omitida. Esto evitará un procesamiento innecesario. Esto ayuda a optimizar el rendimiento y a evitar llamadas redundantes a la API.

Dado que los datos omitidos permanecen almacenados en Alumio, también permite que Alumio iPaaS actúe como un sistema de almacenamiento en caché. Esto significa que si los datos omitidos anteriormente pasan a ser relevantes más adelante, como un pedido que pasa de «Pendiente» a «Pagado», puedes volver a procesarlos fácilmente sin necesidad de volver a extraerlos de la aplicación de origen. Esto mejora la eficiencia y reduce la carga en los sistemas conectados.

‍

Cómo se puede usar Alumio como sistema de almacenamiento en caché

Alumio también se puede usar como un sistema de almacenamiento en caché, en el que solo las versiones delta de los datos, o solo las versiones actualizadas o nuevas de los datos, se enviarán de una aplicación a otra.

Por ejemplo, supongamos que obtenemos regularmente mil registros, lo que equivale a miles de productos, de una aplicación a otra. Resulta productivo enviar datos a la otra aplicación solo de aquellos productos que tienen precios, existencias, inventario, etc. actualizados, o datos de productos que son completamente nuevos y aún no se han registrado en la otra aplicación.

Con este enfoque, puede programar una actualización cada minuto y enviar solo un puñado de tareas, como tres, cinco o, en las horas punta, quizás veinte actualizaciones de productos nuevos. Esto es mucho más eficaz que intentar enviar los mil registros por minuto. Comprobar periódicamente si hay nuevos datos y enviar solo estos datos garantiza que no estamos desperdiciando tiempo y recursos procesando tareas redundantes. Si necesitas ver los datos filtrados, puedes consultar los registros que Alumio ayuda a mantener para cada acción e integración.
‍

Otros estados de tareas esenciales en Alumio

Además de los estados de las tareas principales que se muestran en el tablero, Alumio también administra los estados de las tareas adicionales que desempeñan un papel crucial para garantizar un procesamiento de datos fluido. Estos estados son «Reintento», «Rechazado» y «En espera», que ayudan a automatizar la gestión de errores, reforzar la validación de los datos y permitir el control manual de tareas específicas cuando sea necesario.
‍

Reintentar tareas:

Es posible que necesite volver a procesar una tarea para volver a exportar los datos al sistema de destino. Esto puede deberse a que la tarea falló anteriormente debido a un problema de configuración que ya se ha solucionado, o simplemente a que es necesario volver a procesar todas las entidades, incluso si ya estaban marcadas como Finalizadas.

Cuando la opción «Activar el reintento de tareas fallidas» esté habilitada en una ruta, Alumio intentará reprocesar automáticamente las tareas fallidas. Esto significa que Alumio intentará reprocesar automáticamente la tarea hasta que tenga éxito o alcance el límite de reintentos configurado. Esta función ayuda a recuperarse de problemas temporales, como interrupciones breves del sistema o interrupciones de la red, sin necesidad de intervención manual. Si una tarea sigue fallando después de haber agotado el número máximo de reintentos, se marcará como tarea fallida y los detalles del error se registrarán para su solución.

Al volver a intentar las tareas manualmente, el estado de las tareas se establecerá en Nuevo de nuevo, por lo que la ruta lo procesará en el sistema saliente en la próxima ejecución. En la página de descripción general de la tarea, puede filtrar y elegir volver a intentar varias tareas a la vez. También puedes elegir seleccionar una sola tarea y volver a intentarlo. De esta forma, solo puede volver a intentar una tarea que tenga el estado Finalizada, Fallida u Omitida.
‍

Tareas rechazadas:

Una tarea se clasifica como rechazada cuando no cumple con las restricciones específicas del sistema o las reglas de validación. Por ejemplo, si se establece un límite de 1000 bytes para los datos de la entidad y una tarea supera este umbral, se rechazará en lugar de procesarse. Del mismo modo, las tareas con datos de entidad no válidos pueden rechazarse automáticamente para evitar que los errores se propaguen a través de la integración. El motivo del rechazo se registra en los registros de importación de la página de detalles de la tarea, lo que permite a los usuarios revisar y solucionar el problema antes de volver a enviar los datos.

‍

Tareas en espera:

En algunos casos, los usuarios pueden configurar una ruta para que, en lugar de que una tarea se marque automáticamente como finalizada o fallida después del procesamiento, pase al estado «En espera». Esto brinda a los usuarios la oportunidad de revisar manualmente la tarea y determinar su resultado en función de la información disponible en los registros. Si una tarea está en estado «En espera», los usuarios pueden decidir si se debe marcar como finalizada o fallida mediante el menú «Acciones». También se pueden aplicar acciones masivas para actualizar varias tareas en espera a la vez. Este estado es especialmente útil en los casos en los que se requiere una validación manual antes de finalizar el proceso de integración.

Ahora que hemos entendido los diferentes tipos de tareas dentro de Alumio, exploremos todos los detalles que contiene una tarea para entender cómo, además, ayuda a rastrear, administrar y agilizar la integración en cada paso del proceso.
‍