Integración unidireccional o bidireccional: cómo decidir el sentido de sincronización sin crear conflictos de datos

Decidir entre una integración unidireccional o bidireccional no consiste solo en dibujar una flecha entre dos aplicaciones. Es una decisión sobre propiedad del dato, responsabilidades operativas y tolerancia al riesgo. Una conexión aparentemente simple entre un CRM, un ERP, una tienda online o una plataforma de atención puede producir duplicados, sobrescrituras y errores de estado si ambos sistemas modifican la misma información sin reglas explícitas.

La regla inicial es sencilla: sincronice en ambos sentidos solo cuando un proceso real requiera que ambos sistemas editen el mismo dominio de datos. Que dos aplicaciones puedan intercambiar información no significa que deban hacerlo. Reducir el número de flujos y de campos editables suele disminuir el coste de mantenimiento, las incidencias y las decisiones manuales posteriores.

Qué cambia entre una integración unidireccional y una bidireccional

En una integración unidireccional, un sistema publica o envía información y el otro la recibe, replica o consulta. Por ejemplo, un ERP puede enviar catálogo, disponibilidad y precio a un ecommerce. El ecommerce recibe esos valores, pero no los corrige ni los devuelve al ERP.

En una integración bidireccional, cada sistema puede generar cambios que terminan en el otro. Un caso típico es el pedido: el ecommerce lo crea, el ERP actualiza su preparación o facturación y el ecommerce necesita reflejar ese estado para informar al cliente. La bidireccionalidad puede ser correcta para ese objeto, pero no obliga a que todos sus campos lo sean.

Conviene evitar una clasificación global del tipo “la integración es bidireccional”. La decisión útil se toma por entidad, campo y operación:

• Entidad: cliente, pedido, producto, factura, ticket o inventario.
• Operación: crear, actualizar, cancelar, archivar o consultar.
• Campo: correo electrónico, dirección de envío, estado, precio, identificador fiscal o consentimiento.

Así, una integración puede ser unidireccional para precios, bidireccional para estados de pedido y solo de consulta para facturas. Este nivel de detalle evita que una modificación legítima en un canal sobrescriba información que pertenece a otro.

Empiece por la propiedad del dato, no por la API disponible

Antes de valorar webhooks, tareas programadas o capacidades de una API, el equipo debe establecer un mapa de propiedad. Para cada dato relevante, responda quién lo crea, quién puede modificarlo, dónde se valida y qué aplicación debe mostrarlo.

1. Identifique el sistema maestro. Es la fuente autorizada cuando hay discrepancias. No tiene que ser el sistema donde se visualiza el dato con más frecuencia.
2. Separe dato maestro y dato operativo. Un ERP puede ser maestro de referencias, impuestos y disponibilidad, mientras que el ecommerce es maestro del canal de compra, del carrito y de la dirección confirmada en el checkout.
3. Defina la necesidad de retorno. Pregunte qué decisión o tarea queda bloqueada si el cambio no vuelve al sistema de origen.
4. Documente las excepciones. Puede haber campos con propietario distinto dentro de una misma entidad. Un equipo comercial quizá actualiza el teléfono en el CRM, mientras que la dirección de entrega válida procede del pedido.

Una señal de alerta aparece cuando la respuesta a “¿quién manda sobre este campo?” es “depende”. No impide la integración, pero exige convertir ese “depende” en una regla verificable: por estado, canal, fecha, tipo de cliente o permiso de usuario.

Cuándo un solo sentido es suficiente y más seguro

La sincronización unidireccional es la opción preferible cuando existe una fuente clara, el destinatario necesita principalmente consumir datos y el retorno no desencadena una acción indispensable. También es adecuada cuando el dato es sensible, altamente regulado internamente o difícil de reconciliar.

Casos frecuentes incluyen catálogo desde ERP hacia ecommerce, segmentos desde CRM hacia una plataforma de comunicaciones, o tickets cerrados hacia un sistema de analítica. En estas situaciones, permitir edición en el sistema receptor crea una promesa difícil de cumplir: que cualquier cambio local se conservará y tendrá sentido fuera de ese contexto.

Señales prácticas para elegir un flujo unidireccional

• Un sistema ejecuta validaciones, aprobaciones o cálculos que el otro no puede reproducir.
• El receptor solo necesita visibilidad, búsqueda, informes o ejecución de una tarea posterior.
• Las modificaciones en el destino son locales, temporales o no deben afectar al registro maestro.
• Un conflicto causaría impacto financiero, legal, operativo o de atención al cliente.
• La información cambia poco o puede actualizarse por lotes sin afectar al proceso.

El principal beneficio no es únicamente técnico. Un flujo de un solo sentido permite explicar con claridad por qué un valor aparece en pantalla y dónde debe corregirse. Si el operador detecta un precio erróneo en el ecommerce, sabe que debe corregirlo en el ERP, no editar una copia que será reemplazada en la siguiente sincronización.

Cuándo la sincronización bidireccional está justificada

La bidireccionalidad está justificada cuando dos equipos trabajan en aplicaciones distintas y ambos deben completar partes legítimas del mismo proceso. Debe existir una necesidad operativa concreta, no solo el deseo de “tener todo actualizado”.

Un ejemplo habitual conecta ecommerce, ERP y atención al cliente. El ecommerce crea el pedido y captura la dirección de envío. El ERP confirma preparación, envío o cancelación. Atención al cliente puede registrar una incidencia o una solicitud de modificación. No obstante, no todos deberían editar lo mismo:

• El ecommerce es maestro de los datos capturados y confirmados durante la compra.
• El ERP es maestro de estados logísticos, documentos operativos y disponibilidad comprometida.
• La aplicación de atención al cliente puede crear un caso y proponer una acción, pero no debería alterar directamente un estado logístico sin pasar por la regla establecida en el ERP.

Este diseño conserva una experiencia coordinada sin convertir tres sistemas en autoridades equivalentes. La bidireccionalidad debe tener límites de escritura, no solo permisos de lectura.

Riesgos de ambos sentidos y reglas para resolver conflictos

Los fallos típicos de una sincronización bidireccional no suelen ser errores aislados de conexión. Son ambigüedades de negocio expresadas como errores de datos. Los más comunes son los bucles de actualización, las sobrescrituras, los duplicados, los cambios que llegan fuera de orden y los estados que no tienen equivalencia entre sistemas.

Un bucle ocurre cuando el sistema A actualiza B, B devuelve el mismo cambio a A y el ciclo continúa. Una sobrescritura aparece cuando dos usuarios modifican un campo desde sitios distintos antes de que la integración propague ambas versiones. Los duplicados surgen si cada plataforma crea registros sin reconocer el identificador de la otra.

Para prevenirlos, defina una política de conflicto antes de construir:

• Precedencia por campo: el ERP gana para stock; el ecommerce gana para dirección de entrega confirmada.
• Precedencia por estado: mientras un pedido está pendiente, puede modificarse en el ecommerce; tras su preparación, los cambios requieren un flujo controlado.
• Última actualización: úsela solo cuando el reloj, la zona horaria y la semántica de la modificación sean fiables. No es una regla universal.
• Revisión manual: envíe los casos de alto impacto a una cola con responsable, motivo y datos comparados.
• Rechazo explícito: no aplique un cambio incompatible; devuelva un error accionable y conserve la evidencia.

También conviene modelar los estados. “Cancelado”, “reembolsado”, “enviado” y “cerrado” no siempre representan lo mismo en cada aplicación. Cree una tabla de correspondencia y determine qué transiciones están permitidas. Si un sistema no admite una transición, no fuerce una equivalencia que oculte una excepción operativa.

Diseño técnico mínimo para una integración operable

La arquitectura debe soportar la política de datos, no sustituirla. Como mínimo, cada registro sincronizado necesita un identificador interno estable y el identificador del sistema externo. No use correo electrónico, nombre o referencia visible como clave única si pueden cambiar o repetirse.

• Marcas de origen: registre qué sistema produjo el cambio para evitar que vuelva a procesarse como uno nuevo.
• Versiones o fechas de modificación: ayudan a detectar eventos atrasados y actualizaciones simultáneas.
• Idempotencia: repetir un mensaje no debe crear un pedido, cliente o ticket adicional.
• Registro trazable: guarde identificadores, dirección del flujo, resultado, error y momento de procesamiento.
• Reintentos controlados: distinga errores temporales de validaciones definitivas y limite los reintentos.

origen: ecommerce
entidad: pedido
id_externo: EC-10452
version: 7
operacion: actualizar_estado
clave_idempotencia: ecommerce-EC-10452-7

Este tipo de información permite investigar por qué un cambio no llegó, llegó dos veces o fue descartado. Sin trazabilidad, el equipo termina comparando pantallas y corrigiendo datos manualmente, una práctica que agrava la divergencia.

Pruebe escenarios de conflicto y apruebe el flujo con una checklist

No valide una integración solo con altas y actualizaciones correctas. Las pruebas deben incluir cambios simultáneos, registros incompletos, eventos duplicados, errores de red, permisos insuficientes y una indisponibilidad prolongada de cualquiera de los sistemas.

Antes de aprobar la salida a producción, confirme lo siguiente:

• Cada entidad y campo importante tiene sistema maestro y responsable de negocio.
• La dirección de cada flujo responde a una necesidad operativa documentada.
• Existen reglas de precedencia, rechazo y revisión manual para conflictos.
• Los identificadores externos, el origen del cambio y la idempotencia están implementados.
• Los estados incompatibles tienen tratamiento explícito, no una conversión implícita.
• Hay alertas y un procedimiento para revisar fallos, reintentos y registros pendientes.
• Los equipos conocen dónde corregir un dato y qué cambios no deben realizar localmente.

La mejor integración no es la que mueve más datos en ambos sentidos. Es la que conserva una fuente de verdad comprensible, entrega la información cuando el proceso la necesita y hace visibles las excepciones antes de que se conviertan en incidencias para el cliente.