Etapas del Pipeline
Cada registro que EZY Integrations procesa pasa por cinco etapas en orden. Comprender estas etapas te ayuda a diagnosticar dónde ocurrió un fallo y qué acción tomar. Cada etapa se reintenta de forma independiente ante un fallo, y un registro que agota todos los reintentos se mueve a la Cola de Mensajes Fallidos para revisión manual.
Flujo de etapas
Sección titulada «Flujo de etapas»flowchart LR
A[Ingestión] --> B[Normalización]
B --> C[Transformación]
C --> D[Ejecución]
D --> E[Finalización]
D -- fallo tras reintentos --> F[Cola de Mensajes Fallidos]
F -- reintento manual --> A
Referencia de etapas
Sección titulada «Referencia de etapas»| Etapa | Propósito | Qué puede fallar aquí | Solución para el usuario |
|---|---|---|---|
| Ingestión | Lee registros del sistema fuente usando las credenciales del perfil de conexión y las reglas de extracción de la configuración de mapeo. Avanza el cursor de sincronización al completarse. | Fallo de autenticación; sistema fuente no disponible; consulta de extracción inválida; ningún registro coincide con la ventana del cursor. | Verifica las credenciales del perfil de conexión; confirma que el sistema fuente está en funcionamiento; revisa el bloque de extracción en la configuración de mapeo. |
| Normalización | Convierte los datos crudos del sistema fuente al formato de entidad canónica. Aplica conversiones de tipo y valida los campos requeridos. | Un campo requerido está vacío o nulo; falla una conversión de tipo (por ejemplo, un valor no numérico en un campo decimal); el tipo de entidad no se reconoce. | Revisa el bloque de normalización de tu configuración de mapeo; verifica que los campos fuente requeridos estén completos; confirma que el nombre del tipo de entidad coincide exactamente. |
| Transformación | Da forma a la entidad canónica en el payload exacto que el sistema destino espera. Aplica mapeos de campos, transformadores de valores, campos estáticos y mapeos condicionales de la configuración de mapeo. | Un transformador recibe un valor incompatible; un campo destino requerido no tiene mapeo; se especifica una ruta destino inválida. | Revisa el bloque de transformación; verifica las opciones del transformador; asegúrate de que cada campo destino requerido tenga un mapeo o una entrada de campo estático. |
| Ejecución | Envía el payload transformado al sistema destino. El conector reconcilia si crear o actualizar un registro existente, basándose en una tabla de mapeo de IDs fuente-destino. | El sistema destino rechaza el payload (error de validación, fallo de autenticación, límite de velocidad); sistema destino no disponible. | Verifica el perfil de conexión destino; inspecciona el mensaje de error de la ejecución para conocer la razón del rechazo del sistema destino; revisa las restricciones de longitud de campos en la configuración de mapeo. |
| Finalización | Registra el resultado de la ejecución (éxito, éxito parcial o fallo). Actualiza los cursores de sincronización incremental para que la próxima ejecución comience donde dejó esta. | Raramente falla por sí sola; un fallo de finalización puede indicar un problema de conectividad de la base de datos en el servicio de integración. | Contacta a tu administrador de sistema si la finalización falla consistentemente después de que Ejecución tenga éxito. |
Qué ocurre cuando falla una etapa
Sección titulada «Qué ocurre cuando falla una etapa»- El servicio de integración reintenta el registro fallido automáticamente, hasta un máximo configurable.
- Si el registro sigue fallando tras todos los reintentos, se coloca en la Cola de Mensajes Fallidos (DLQ).
- La ejecución se marca como éxito parcial (algunos registros tuvieron éxito) o fallida (ningún registro tuvo éxito).
- Puedes inspeccionar el mensaje de error de cada registro fallido en la vista de detalles de la ejecución.
- Una vez resuelto el problema subyacente, puedes reintentar mensajes de la DLQ desde la página de DLQ, que los reinyecta en la etapa de Ingestión.
Éxito parcial
Sección titulada «Éxito parcial»Una ejecución se marca como éxito parcial cuando al menos un registro tiene éxito y al menos uno falla. Los registros procesados correctamente se escriben en el destino; solo los registros fallidos aparecen en la DLQ. No es necesario volver a ejecutar todo el trabajo: basta con reintentar solo los mensajes de la DLQ.
Relacionado
Sección titulada «Relacionado»- Descripción General de la Arquitectura — Cómo las cinco etapas encajan en el flujo de datos general.
- Configuración de Mapeo — Cómo configurar las reglas de extracción, normalización y transformación.
- Cola de Mensajes Fallidos y Reintento — Cómo inspeccionar y reintentar mensajes fallidos.