Una integración puede cumplir el esquema técnico y entregar un dato equivocado para quien lo utiliza. Un importe conserva su tipo numérico aunque cambie de euros a céntimos; una fecha sigue siendo válida aunque deje de representar el evento que esperaba el informe.
Un contrato de datos hace explícitas las condiciones de intercambio entre quien produce un conjunto de datos y quien lo consume. Su utilidad está en convertir expectativas discutibles en acuerdos que se puedan comprobar y mantener.
La conversación que debe ocurrir antes de conectar
Imagina un intercambio ficticio de pedidos entre ventas y operaciones. El equipo productor entiende por «pedido activo» cualquier pedido no eliminado. El consumidor interpreta que todos esos pedidos están aceptados y listos para preparar.
Ambos pueden creer que la integración funciona porque reciben filas a diario. El problema aparece cuando el almacén prepara pedidos todavía pendientes de validación. Ninguna comprobación de tipo de dato detectará esa diferencia de significado.
Antes de definir el formato del archivo o la API, acuerda qué evento representa cada registro y para qué usos es válido. Añade ejemplos y exclusiones: un caso concreto suele aclarar más que una definición extensa.
Una ficha mínima para revisar juntos
| Bloque | Decisión que debe quedar escrita |
|---|---|
| Identidad y propósito | Qué conjunto es, para qué sirve y qué usos quedan fuera |
| Grano y claves | Qué representa una fila y cómo se identifica de forma estable |
| Semántica | Qué significan estados, importes, unidades y fechas |
| Calidad | Qué reglas deben cumplirse y cómo se tratan excepciones |
| Entrega | Cuándo estará disponible y cómo se detecta una carga incompleta |
| Responsabilidad | Quién comunica cambios y quién investiga incidencias |
El Open Data Contract Standard descrito por Data Contract CLI organiza aspectos como estructura, semántica, calidad, propiedad y localización del dato en un documento versionable. Adoptar un formato existente puede ayudar a automatizar verificaciones; no sustituye el acuerdo entre equipos.
Escribe condiciones observables
«Datos actualizados» no permite determinar si una entrega es correcta. Una condición útil identifica el evento de origen, el periodo que cubre la entrega y el momento en que debe estar disponible según el servicio acordado.
«Sin duplicados» también necesita contexto. En una tabla de líneas de pedido, repetir el identificador del pedido es normal; repetir la combinación de pedido y línea puede ser un error. En una tabla de eventos, dos cambios del mismo pedido son registros diferentes.
Para cada regla, especifica qué pasa si falla: detener la publicación, aislar registros, emitir una advertencia o solicitar revisión. Todas las excepciones no deben producir la misma respuesta.
Prueba el contrato con una muestra conflictiva
Prepara registros que incluyan una clave repetida, un estado desconocido, una fecha ausente y una corrección posterior a la entrega original. Pide a productor y consumidor que describan el resultado esperado.
La prueba descubre si las reglas están completas y si existe acuerdo sobre su aplicación. Conserva esos ejemplos como casos de aceptación; después podrán automatizarse en la herramienta elegida.
No confíes únicamente en validaciones de formato. Comprobar que un campo pertenece a una enumeración no demuestra que la transición de estado sea válida para ese pedido.
Define cómo cambiará el acuerdo
Un contrato inmóvil acaba separado de la realidad. Establece cómo se propone un cambio, qué consumidores deben revisar su impacto y cómo convivirán las versiones durante una transición.
Distingue cambios de representación y cambios de significado. Añadir un campo opcional puede ser compatible para un consumidor y romper otro que valide estrictamente la respuesta. Cambiar la interpretación de una columna sin cambiar su nombre requiere especial atención.
El cierre de la revisión debe identificar una versión, los responsables y las pruebas aceptadas. Si nadie puede explicar qué versión utiliza un informe, faltará una pieza para investigar diferencias futuras.
Los contratos forman parte de una integración de datos mantenible. Para revisar un intercambio con Nexeus Big Data, prepara una muestra sin información sensible y las preguntas que cada equipo necesita responder con ella.