Elige una dirección por dato
Determina qué sistema controla cada dato: cliente, precio, estado de pedido o factura. La sincronización bidireccional necesita reglas cuando ambos cambian el mismo campo. Documenta qué dato gana y por qué. Un diagrama con dos flechas no resuelve conflictos ni establece responsabilidades.
Diseña la repetición segura
Incluye identificadores de negocio que permitan reconocer una operación ya procesada. Prueba un evento duplicado y una respuesta tardía. Decide qué acciones pueden repetirse automáticamente y cuáles necesitan revisión. El objetivo es evitar que un reintento cree dos pedidos o marque como completada una operación todavía incierta.
Haz visibles los fallos
Registra estado, hora, entidad y causa útil del error, evitando información sensible innecesaria. Define quién recibe el aviso y cómo reanuda el proceso. Diferencia fallo permanente de indisponibilidad temporal. Un panel que solo muestra éxitos deja al equipo sin explicación cuando faltan registros.
Acuerda la reconciliación
Además de eventos individuales, compara periódicamente conjuntos y totales entre sistemas. Define tolerancias y excepciones de negocio. Prueba una desconexión y la recuperación posterior con datos de prueba. El contrato de integración debe incluir la frecuencia esperada y reconocer los límites reales de las fuentes.
Ejemplo: un pedido con respuesta tardía
Supongamos que el CRM envía un pedido aprobado al ERP con una referencia de negocio estable. La conexión expira antes de recibir confirmación. Hay dos posibilidades: el ERP no lo creó, o lo creó y la respuesta se perdió. El conector consulta por esa referencia o utiliza el mecanismo de repetición segura que permita la API. Solo después decide si reintenta. Si no puede comprobarlo, marca el resultado como incierto y solicita revisión; no genera un segundo pedido a ciegas. El operador debe ver referencia, estado, último intento y acción propuesta. Este ejemplo describe un requisito de diseño; la implementación concreta depende de las capacidades verificadas de cada API.
Pruebas que debe superar el conector
Utiliza un conjunto con pedido nuevo, duplicado, cancelado, incompleto y rechazado por reglas de negocio. Añade pérdida de conexión antes y después de una posible creación. Verifica que los duplicados no producen registros adicionales, que el estado incierto es visible y que una corrección puede reprocesarse de forma controlada. Compara al final las referencias de ambos sistemas, no solo sus totales. Comprueba también permisos revocados, límites de uso y protección de credenciales. Documenta qué se recupera automáticamente y qué requiere una persona. El escenario no está aceptado si solo funciona cuando todas las respuestas llegan a tiempo.
Puntos clave
- La recuperación forma parte de la integración, no es un extra posterior.