Doce patrones de integración para Oracle Integration 3, con ejemplos reales

Un consultor de integración ha publicado un catálogo de doce patrones para Oracle Integration 3, la plataforma iPaaS de Oracle. Cada entrada lleva un caso real —la mayoría de seguros y sanidad—, una vista de arquitectura y un diagrama de secuencia. El objetivo declarado no es documentar funciones del producto, sino que el lector reconozca el patrón y lo compare antes de aplicarlo.

De la llamada síncrona al bus de eventos

El primero es el clásico de petición y respuesta: el disparador REST o SOAP valida y mapea, invoca una o varias aplicaciones y devuelve una respuesta consolidada. El autor avisa de que el flujo debe ser corto, porque la conexión del cliente sigue abierta. Su ejemplo: un portal de proveedores lanza una consulta de elegibilidad y la plataforma llama a la API de la aseguradora para devolver cobertura, copago y deducible en la misma interacción.

La fachada API y la mediación de protocolo colocan a OIC entre el consumidor y una interfaz heredada o SaaS para esconder diferencias de protocolo, esquema y autenticación. El caso típico: una aplicación móvil de siniestros envía JSON por REST y la plataforma lo traduce al contrato SOAP/XML del sistema antiguo, y hace el camino inverso a la vuelta.

A partir de ahí el catálogo cubre terrenos conocidos por quien monta integraciones. Enrutado por contenido con ramas condicionales y una ruta por defecto, para que un valor inesperado se vea en lugar de desaparecer. Orquestación y agregación de varios pasos, con ámbitos de manejo de errores local. Reparto en paralelo y recogida, que obliga a decidir de antemano cómo se reportan los fallos parciales. Cesión asíncrona que responde un 202 con identificador de seguimiento. Publicación y suscripción con suscriptores idempotentes. Disparo por evento en vez de sondeo. Sondeo programado con marca de agua que solo avanza cuando el proceso termina bien. Transferencia masiva por ficheros —SFTP, Object Storage, comprimir, cifrar, trocear— en lugar de llamadas registro a registro. Pasarela B2B/EDI con acuerdos de socio, X12 837 sobre AS2 y acuses de recibo.

Lo que de verdad se juega en producción

El último patrón es el que suele decidir si el sistema aguanta: entrega fiable con reintentos. Se envuelven las invocaciones volátiles en ámbitos, se clasifican los fallos y solo se reintentan los transitorios, con retroceso controlado. Lo que se agota o es un error de datos acaba en un almacén persistente con carga útil, error e identificador de correlación, desde donde operaciones puede corregir y reenviar. El ejemplo: si la API del proveedor expira, OIC reintenta; después guarda la petición en Oracle Autonomous Transaction Processing y avisa al equipo.

El texto insiste en que no son plantillas aisladas. Una solución real combina fachada API, orquestación, cesión asíncrona y almacén de fallos. Quien vaya a tocar una integración en OIC 3 tiene aquí una taxonomía razonable para discutir un diseño, aunque el valor esté en las decisiones sobre fallos y no en los diagramas.