Patrones de integración en Oracle Integration 3: cómo elegir el disparador

El mecanismo que inicia una integración determina cómo se comporta cuando el origen se retrasa o el destino falla. Una orden enviada por una aplicación, una extracción nocturna y un archivo entregado por un socio pueden terminar en el mismo sistema, pero exigen controles distintos de disponibilidad, duplicados y recuperación.

Este artículo describe los estilos de integración de Oracle Integration 3 (OIC), explica qué decide cada uno y propone criterios para elegirlos. Al final se incluye una ficha de verificación aplicable a cualquier integración nueva. Los ejemplos son ilustrativos.

Disparador y formato del dato

Oracle Integration 3 clasifica las integraciones en tres estilos: Application, Schedule y Event. Según la guía de estilos de integración, el criterio de clasificación es qué inicia la ejecución: una aplicación, un horario o un evento publicado por otra integración.

El archivo no constituye un cuarto estilo. Es un medio de intercambio que puede recogerse con una integración programada o recibirse por una interfaz de aplicación, según las capacidades del adaptador. Confundir el formato con el disparador es una fuente frecuente de diseños difíciles de operar.

Antes de diseñar el flujo conviene definir por escrito tres elementos: qué significa que el dato esté listo para procesarse, quién comunica esa disponibilidad y qué evidencia queda si la comunicación falla. Esa definición separa la llegada de un documento de la confirmación de que el proceso de negocio terminó.

Integraciones Application: llamadas síncronas y asíncronas

Una integración Application se inicia con un disparador de aplicación y puede ser síncrona o asíncrona. La documentación de integraciones de aplicación vincula esa elección a una pregunta: si el solicitante necesita esperar el resultado del trabajo.

Una consulta de disponibilidad durante una operación interactiva admite una respuesta síncrona, siempre que el recorrido completo quepa en el tiempo permitido. El registro de una solicitud que continúa después de aceptarse requiere, en cambio, una interfaz asíncrona y un mecanismo separado de consulta o notificación.

En un disparador REST asíncrono, el código HTTP 202 indica recepción, no resultado. Oracle documenta esa diferencia en su comparación entre ejecución síncrona y asíncrona. Por eso el consumidor necesita un contrato explícito para conocer el resultado final.

Ese contrato incluye un identificador de operación, los estados posibles y un responsable de las solicitudes pendientes. El identificador cumple además una segunda función: si el consumidor reenvía la orden por falta de respuesta, permite reconocer que se trata del mismo trabajo. La protección contra duplicados depende de ese diseño y de las capacidades del destino.

Integraciones Event: hechos publicados dentro de OIC

Conviene distinguir dos situaciones que suelen confundirse. Una aplicación externa puede emitir un evento a través de su adaptador y disparar una integración Application. Una integración Event, en cambio, se suscribe a un evento definido y publicado dentro de Oracle Integration.

En este segundo mecanismo, el contrato del evento se define con un esquema JSON o XML. Una integración publicadora, de estilo Application o Schedule, usa la acción Publish event, y una o varias integraciones Event se suscriben. Oracle describe el modelo y los filtros por encabezados en About Event Integrations.

El patrón es adecuado cuando varios procesos deben reaccionar a un mismo hecho sin que el publicador coordine cada ejecución. Un ejemplo ilustrativo: el evento «orden aprobada» alimenta una notificación y un proceso de preparación, cada uno con los datos que necesita.

La gobernanza del esquema es la condición de éxito. Debe existir un responsable de sus cambios y una regla de compatibilidad. Como criterio, el evento debe llevar una referencia estable al objeto de negocio y no una copia completa del registro. También debe probarse el comportamiento de cada suscriptor cuando falla mientras los demás continúan.

Integraciones Schedule: ventanas y marcas de avance

El estilo Schedule se inicia con una programación en lugar de un adaptador disparador, y admite ejecuciones bajo demanda, según la guía de integraciones programadas. Corresponde a sistemas que exponen extracción por consulta o que intercambian lotes en horarios acordados.

Su condición de uso es doble: el negocio tolera esperar hasta la siguiente ventana y existe una forma verificable de delimitar lo pendiente. Una extracción de documentos modificados exige definir el inicio y el fin del intervalo consultado y el momento en que el avance se confirma. La consulta «todo lo cambiado desde la ejecución anterior» es ambigua si esa ejecución quedó incompleta.

Recomendamos asociar la marca de avance al trabajo confirmado y no a la hora en que comenzó la integración. Deben definirse también dos reglas: el tratamiento de registros que llegan tarde y el de dos ejecuciones que intentan procesar el mismo periodo. La regla concreta depende del mecanismo de consulta y de las garantías del origen.

La zona horaria de la programación merece una verificación aparte. Cuando las ventanas involucran equipos de Centroamérica y Estados Unidos, el cambio de horario estacional desplaza las horas acordadas. La ejecución manual también debe probarse, para confirmar que no altera el estado que usa la programación habitual.

Archivos: lotes con identidad y evidencia

Para procesar archivos descargados, Oracle Integration ofrece la acción Stage File, que permite leerlos completos o por segmentos según la operación y el formato. La guía de procesamiento de archivos documenta sus restricciones. Los archivos que crea esta acción son visibles sólo dentro de su ámbito y se eliminan al salir de él.

De ese comportamiento se deriva un requisito: cuando el proceso puede necesitar reprocesos, los originales y las evidencias deben guardarse en un almacenamiento duradero. El área temporal de Stage File no es un archivo histórico. Cada lote necesita una identidad y una relación verificable entre sus registros y las operaciones aplicadas en el destino.

Con el emisor debe acordarse cómo se reconoce un archivo completo antes de leerlo, mediante un protocolo que ambos sistemas puedan cumplir. La validación de estructura y de reglas de negocio precede a la confirmación del lote. Si una parte de los registros se acepta y otra se rechaza, el resultado debe permitir corregir sólo lo pendiente, sin reenviar lo ya confirmado.

La lectura por segmentos facilita el procesamiento de archivos grandes, pero no convierte el lote en una transacción. El diseño debe registrar el avance y definir la respuesta ante una falla a mitad del archivo. Los límites de tamaño se consultan en la documentación vigente del adaptador y del servicio.

Ficha de decisión y prueba de aceptación

Recomendamos documentar cada integración en una ficha breve con el disparador elegido y su justificación. La ficha sirve en la revisión técnica y en la entrega al equipo que atenderá incidentes.

• Application: una llamada o un cambio en una aplicación inicia el trabajo y el adaptador lo admite.
• Event: el trabajo responde a un evento publicado por otra integración de Oracle Integration.
• Schedule: un horario o una ejecución bajo demanda inicia una extracción o un lote.
• Archivos: identidad del lote, criterio de archivo completo y evidencia de aceptación por registro o por lote.
• En todos los casos: regla para reconocer duplicados y responsable de confirmar el resultado final.

La prueba de aceptación debe incluir una falla provocada después de una escritura exitosa, para observar qué hace el segundo intento. El operador debe poder localizar el objeto de negocio y distinguir recepción, procesamiento y confirmación. Una integración está lista para operar cuando esas tres fases son observables y el procedimiento de recuperación fue ejecutado al menos una vez.

En Xterra Engine revisamos fichas de integración de este tipo antes de la construcción, cuando corregir el disparador todavía no tiene costo de retrabajo.