Integraciones con eventos de Fusion que no se reactivan después de actualizar Oracle Integration

Una actualización de Oracle Integration suele obligar a desactivar y reactivar integraciones. En las que se suscriben a eventos de Oracle Fusion Applications aparecen entonces dos síntomas: la activación falla con un error de autorización, o la integración queda activa y deja de recibir eventos.

Ambos síntomas tienen pocas causas documentadas y se pueden revisar en orden. Este artículo las recorre con los pasos que Oracle publica para cada una: red y control de acceso, estado de la suscripción, rol del usuario de integración y perfiles que habilitan los eventos en Fusion. Al terminar, el lector podrá ubicar la causa con evidencia antes de abrir una solicitud de soporte.

Cómo se registra un evento de Fusion en Oracle Integration

Cuando una integración usa el adaptador de Oracle ERP Cloud como disparador de un evento de negocio, su activación registra una suscripción en Fusion. La suscripción indica a Fusion qué evento enviar y a qué dirección de Oracle Integration. Si el registro falla, la activación falla; si la suscripción se borra o apunta a otro lugar, la integración queda activa pero no recibe nada.

Por eso una reactivación no es un paso neutro en estas integraciones. Intervienen la conectividad de Oracle Integration hacia Fusion, los permisos del usuario de la conexión y la configuración de eventos del lado de Fusion.

Direcciones IP nuevas y control de acceso por ubicación

La actualización a Oracle Integration 3 cambia las direcciones IP de la instancia. Oracle documenta que las nuevas direcciones aparecen en la página de actualización unas dos semanas antes, separadas en IP de diseño, de ejecución y de salida. Recomienda agregarlas a las listas de acceso antes de la actualización y retirar las anteriores sólo cuando termine.

Si Fusion tiene habilitado el control de acceso por ubicación (LBAC, Location-Based Access Control), las llamadas desde una IP no autorizada se rechazan. Según los requisitos del adaptador, en ese caso se recibe un error 401 Access Denied o 403 Forbidden de Fusion. Un error de autorización justo después de la actualización apunta primero a esta causa, antes que a las credenciales.

La comprobación consiste en confirmar si LBAC está habilitado y si la IP de salida actual de Oracle Integration figura en la lista permitida. Conviene revisar también otros filtros de red de la organización que se hayan configurado con las direcciones anteriores.

La suscripción del evento al desactivar y reactivar

Al desactivar una integración con suscripción a eventos, Oracle Integration pregunta si se debe borrar la suscripción. La guía de problemas de eventos describe las dos consecuencias. Si no se borra, los eventos se reenvían cuando la integración se reactiva dentro de las seis horas siguientes. Si se borra, la integración no recibe eventos después de reactivarse.

Durante una actualización, varias personas pueden desactivar integraciones con criterios distintos. Como criterio, conviene decidir antes quién responde a esa pregunta y con qué respuesta, y registrar qué integraciones se desactivaron y a qué hora.

El estado real de la suscripción se consulta en Fusion con GET https://<fusion>/soa-infra/PublicEvent/subscriptions. En la respuesta deben coincidir endpointURL con la instancia actual de Oracle Integration, filter con el filtro esperado y state con true. Oracle documenta además el caso inverso: un ambiente de prueba de Fusion con una suscripción activa hacia producción. Ese registro se elimina con DELETE sobre /soa-infra/PublicEvent/subscriptions/{id}.

Rol del usuario de integración

El usuario de la conexión necesita roles específicos para registrar y recibir eventos. La lista de roles del adaptador incluye Integration Specialist, los roles de acceso a datos de los objetos integrados, FND_MANAGE_CATALOG_SERVICE_PRIV para el catálogo de servicios y SOAOperator, que Oracle señala como requerido para recibir eventos de negocio de ERP.

Un cambio de usuario de conexión durante la actualización, o una revisión de seguridad que retire roles, produce el mismo síntoma que un problema de red. Los roles se revisan en la Consola de Seguridad de Fusion, en Herramientas, sobre el usuario exacto que usa la conexión.

Eventos habilitados por perfil en Fusion

Oracle indica que la mayoría de los eventos públicos de negocio no se generan por omisión y deben habilitarse según la guía de cada producto. Varios se habilitan con una opción de perfil (profile option): un parámetro de configuración de Fusion con un valor por sitio o por usuario.

Dos ejemplos documentados:

• Facturas de Payables: la opción ORA_AP_ENABLE_BUSINESS_EVENTS debe tener el valor Y. Oracle remite a la nota 2650773.1 de My Oracle Support.
• Objetos de CX Sales y servicio, como cuentas, contactos, oportunidades o solicitudes de servicio: la opción ZCA_PUBLIC_BUSINESS_EVENTS vale Y por omisión. Con N, los eventos de creación, actualización y borrado se suprimen.

Los valores se revisan en Configuración y mantenimiento con la tarea Manage Administrator Profile Values, que da acceso a todas las opciones de perfil, buscando por el código. Según Oracle, el nivel sitio admite una sola fila y los cambios surten efecto la próxima vez que el usuario inicia sesión. En la práctica, conviene volver a iniciar sesión con el usuario de integración antes de repetir la prueba.

Si el asistente del adaptador muestra «Failed to fetch Business Events from Public Event Catalog» o no lista el evento, la guía de Oracle indica ejecutar Refresh Metadata en la conexión. El catálogo vigente se consulta con GET https://<fusion>/soa-infra/PublicEvent/catalog.

Orden de diagnóstico y comprobación

El siguiente procedimiento separa las causas con evidencia, de la más frecuente después de una actualización a la más específica:

1. Registrar el error exacto de la activación. Un 401 o 403 lleva al paso 2; una activación correcta sin eventos lleva al paso 4.
2. Confirmar si LBAC está habilitado en Fusion y si la IP de salida actual de Oracle Integration está permitida. Revisar otras listas de acceso configuradas con las direcciones anteriores.
3. Verificar en la Consola de Seguridad los roles del usuario de la conexión, en especial SOAOperator.
4. Consultar /soa-infra/PublicEvent/subscriptions y comparar endpointURL, filter y state con la integración activa.
5. Consultar /soa-infra/PublicEvent/catalog para confirmar que el evento existe. Si el asistente no lo muestra, ejecutar Refresh Metadata.
6. Revisar con Manage Administrator Profile Values la opción de perfil que habilita el evento en el producto correspondiente, y volver a iniciar sesión después de cambiarla.
7. Generar un evento de prueba y verificar en Oracle Integration, en Observabilidad y Fusion Applications, si Fusion intentó enviarlo.

Si los siete pasos dan resultado correcto y el evento sigue sin llegar, la evidencia reunida es la que solicita el soporte de Oracle para continuar: respuesta de suscripciones, catálogo, roles y valores de perfil.

Xterra Engine revisa integraciones de Oracle Integration con eventos de Fusion antes y después de cada actualización, con el inventario de suscripciones y la prueba de cada evento.