Plataformas y flujos
Interoperabilidad y estándares de datos
Varias organizaciones intercambian datos validados contra un contrato común y pueden cambiar de versión sin romper a quien aún no ha actualizado.
Cuando el intercambio de datos cruza la frontera de una organización, ya no basta con que dos aplicaciones se entiendan hoy. Hay socios que actualizan sus sistemas en momentos distintos, mensajes que llegan dos veces y formatos que cada parte interpreta a su manera. La interoperabilidad consiste en fijar por escrito qué significa cada campo, qué estructura es válida, cómo se identifica un mensaje y qué ocurre al publicar una versión nueva. A veces existe un estándar del sector que conviene adoptar; otras, hay que acordar un modelo canónico propio. En ambos casos el trabajo es parecido: esquemas validables, contratos de API versionados, mapeos documentados y un procesamiento que tolere repeticiones.
- Entrada de datos
- Mensajes XML, JSON o EDI
- Eventos de socios externos
- Validación
- Esquema por versión de contrato
- Identificador único de mensaje
- Procesamiento
- Mapeo al modelo canónico
- Descarte idempotente de repeticiones
- Control humano
- Acuerdo de cambios entre organizaciones
- Calendario de retirada de versiones
- Trazas
- Almacén de mensajes recibidos
- Versión de esquema aplicada
- Sistemas de salida
- Acuse o rechazo motivado
- Registro canónico interno
- Métricas de adopción por versión
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: una comunidad portuaria donde consignatarias, terminales y transportistas notifican escalas y movimientos cada una en su propio formato.
01 · Antes
Cada participante envía ficheros con su propia estructura, las fechas y los códigos se interpretan de forma distinta y los reenvíos generan registros duplicados.
02 · Sistema propuesto
Un catálogo de contratos define el modelo canónico de la escala, cada adaptador valida y traduce los mensajes de su socio y los receptores descartan los ya procesados.
03 · Después
Cada parte recibe un acuse o un rechazo con el motivo concreto, y el coordinador puede ver qué socios usan todavía la versión antigua del contrato.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Definir un modelo canónico que traduzca los formatos de varios socios a un lenguaje común.
- Publicar contratos de API o de eventos con esquemas que cualquier parte puede validar antes de enviar.
- Versionar esos contratos para que una organización pueda evolucionar sin obligar a todas las demás a cambiar a la vez.
- Procesar mensajes de forma idempotente, de modo que un reenvío no genere registros duplicados.
- Rechazar con un motivo claro los mensajes que no cumplen el esquema, en lugar de aceptarlos y fallar después.
Qué no resuelve
- No impone un estándar a socios que no quieren adoptarlo; la interoperabilidad requiere acuerdos además de software.
- No determina qué estándar es obligatorio en tu sector: eso depende de la normativa y de los requisitos de cada intercambio.
- No resuelve diferencias de significado que nadie ha aclarado; si dos partes entienden distinto un campo, hay que acordarlo.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Modelo canónico para varios socios
- Entrada
- Mensajes de pedidos o avisos de envío en formatos distintos según el socio: XML, JSON, CSV o EDI.
- Procesamiento
- Un adaptador por socio valida el mensaje contra su esquema y lo traduce al modelo canónico con un mapeo versionado y documentado.
- Salida
- Registro en formato común para los sistemas internos y acuse de recibo o rechazo motivado al emisor.
02
Contrato de API publicado para terceros
- Entrada
- Necesidad de que organizaciones externas consulten o envíen datos de forma autónoma.
- Procesamiento
- Se redacta la especificación de la API (por ejemplo, en OpenAPI), con esquemas, códigos de error, autenticación y reglas de versionado, y se ofrece un entorno de pruebas.
- Salida
- Documentación navegable, entorno de pruebas y validación automática de que la implementación respeta el contrato.
03
Eventos compartidos entre organizaciones
- Entrada
- Cambios de estado relevantes para varias partes: llegada de una mercancía, cierre de una orden o actualización de un expediente.
- Procesamiento
- Publicación de eventos con identificador único, fecha de origen y versión de esquema; los receptores descartan los que ya han procesado.
- Salida
- Estado coherente en todos los participantes aunque un evento se entregue más de una vez o fuera de orden.
04
Migración a una nueva versión del contrato
- Entrada
- Cambio necesario en el modelo: un campo nuevo, otro que se divide o una regla de validación más estricta.
- Procesamiento
- Se publica la versión nueva conviviendo con la anterior, se informa del calendario de retirada y se mide qué socios siguen usando la antigua.
- Salida
- Transición ordenada, con métricas de adopción y retirada de la versión antigua cuando deja de usarse.
Integración
Cómo se conecta con lo que ya existe
La pieza central es un catálogo de contratos: esquemas, especificaciones de API y eventos, tablas de códigos y mapeos, todos versionados en un repositorio. Alrededor se sitúan los adaptadores de cada socio, la validación en la entrada y un registro de mensajes que permite demostrar qué se recibió, cuándo y con qué resultado. Cuando el sector tiene un estándar reconocido, se evalúa su adopción con quien conoce los requisitos aplicables.
- Especificaciones de API y esquemas de mensajes (JSON Schema, XSD u otros según el estándar)
- Pasarela de API con autenticación por organización y límites de uso
- Bus o broker de eventos para intercambios asíncronos
- Adaptadores por socio con mapeos versionados
- Almacén de mensajes recibidos y enviados para auditoría y reproceso
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Participantes identificados, con un interlocutor técnico por organización y un proceso para acordar cambios.
- Glosario de entidades y campos con su significado, unidades, formatos de fecha y códigos admitidos.
- Política de versionado: qué cambios son compatibles, cuánto tiempo convive una versión antigua y cómo se anuncia su retirada.
- Identificadores únicos de mensaje y de entidad que permitan detectar repeticiones.
- Revisión de los requisitos sectoriales o legales que puedan obligar a un formato concreto, a cargo de quien tenga esa competencia.
Supervisión
Riesgos, límites y mantenimiento
- Un modelo canónico demasiado ambicioso puede tardar más en acordarse que en programarse; conviene empezar por las entidades que más se intercambian.
- Cambiar un contrato sin versionarlo rompe a socios que no han actualizado, a menudo sin que nadie lo detecte de inmediato.
- Los mapeos acumulan excepciones con el tiempo; sin documentación ni pruebas se vuelven imposibles de mantener.
- Compartir datos con otras organizaciones implica acuerdos sobre su uso, conservación y protección que deben resolverse fuera del software.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Preguntas frecuentes
¿Qué diferencia hay entre integrar sistemas e interoperar?
Integrar suele referirse a conectar aplicaciones dentro de una misma empresa, donde se controla todo. Interoperar implica a varias organizaciones con calendarios y sistemas propios, así que los contratos, el versionado y la tolerancia a repeticiones pasan a ser imprescindibles.
¿Tenemos que usar un estándar del sector?
Si existe uno adoptado por tus socios o exigido en tu ámbito, suele compensar. Si no, un modelo propio bien documentado puede ser suficiente. La obligatoriedad de un estándar concreto debe confirmarla quien conoce los requisitos de tu sector.
¿Qué significa que el procesamiento sea idempotente?
Que recibir el mismo mensaje dos veces produce el mismo resultado que recibirlo una. Se consigue con identificadores únicos y comprobando si ya se procesó, y evita duplicados cuando un socio reenvía por un fallo de red.
Cuéntanos con qué organizaciones intercambias datos y en qué formatos
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.