Fusion event integrations that will not reactivate after an Oracle Integration update
After an Oracle Integration update, an integration that subscribes to Oracle Fusion events can fail to reactivate, or stay active and receive nothing. The causes Oracle documents and the order to diagnose them.
An Oracle Integration update usually means deactivating and reactivating integrations. Integrations that subscribe to Oracle Fusion Applications events then show one of two symptoms: activation fails with an authorization error, or the integration becomes active and stops receiving events.
Both symptoms have a small set of documented causes that can be checked in order. This article walks through them with the steps Oracle publishes for each one: network and access control, the state of the subscription, the integration user's role and the profile options that enable events in Fusion. By the end, the reader can locate the cause with evidence before opening a support request.
How a Fusion event is registered in Oracle Integration
When an integration uses the Oracle ERP Cloud Adapter as a business event trigger, activating it registers a subscription in Fusion. The subscription tells Fusion which event to send and to which Oracle Integration address. If registration fails, activation fails; if the subscription is deleted or points elsewhere, the integration stays active but receives nothing.
That is why reactivation is not a neutral step for these integrations. It depends on connectivity from Oracle Integration to Fusion, on the permissions of the connection user and on the event configuration in Fusion.
New IP addresses and location-based access control
Upgrading to Oracle Integration 3 changes the instance's IP addresses. Oracle documents that the new addresses appear on the upgrade page about two weeks in advance, split into design-time, runtime and outbound IPs. It recommends adding them to allowlists before the upgrade and removing the old ones only after it finishes.
If Fusion has location-based access control (LBAC) enabled, calls from an IP that is not allowed are rejected. According to the adapter prerequisites, Fusion then returns a 401 Access Denied or 403 Forbidden error. An authorization error right after the update points to this cause first, before credentials.
The check is to confirm whether LBAC is enabled and whether the current Oracle Integration outbound IP is on the allowed list. Other network filters in the organization that were configured with the old addresses deserve the same review.
The event subscription on deactivation and reactivation
When an integration with an event subscription is deactivated, Oracle Integration asks whether to delete the subscription. The business event troubleshooting guide describes both outcomes. If it is kept, events are resent when the integration is reactivated within six hours. If it is deleted, the integration receives no events after reactivation.
During an update, several people may deactivate integrations with different criteria. As a design criterion, it helps to decide beforehand who answers that prompt and how, and to record which integrations were deactivated and when.
The actual state of the subscription is queried in Fusion with GET https://<fusion>/soa-infra/PublicEvent/subscriptions. In the response, endpointURL must match the current Oracle Integration instance, filter the expected filter and state must be true. Oracle also documents the reverse case: a Fusion test environment with an active subscription pointing to production. That record is removed with DELETE on /soa-infra/PublicEvent/subscriptions/{id}.
The integration user's role
The connection user needs specific roles to register and receive events. The adapter's role list includes Integration Specialist, data access roles for the integrated objects, FND_MANAGE_CATALOG_SERVICE_PRIV for the service catalog and SOAOperator, which Oracle marks as required to receive ERP business events.
A change of connection user during the update, or a security review that removes roles, produces the same symptom as a network problem. Roles are checked in the Fusion Security Console, under Tools, for the exact user the connection uses.
Events enabled by profile options in Fusion
Oracle states that most public business events are not generated by default and must be enabled according to each product's guide. Several are enabled through a profile option: a Fusion configuration setting with a value at site or user level.
Two documented examples:
- Payables invoices: the
ORA_AP_ENABLE_BUSINESS_EVENTSoption must be set toY. Oracle refers to My Oracle Support note 2650773.1. - CX Sales and service objects such as accounts, contacts, opportunities or service requests: the
ZCA_PUBLIC_BUSINESS_EVENTSoption defaults toY. WithN, create, update and delete events are suppressed.
Values are reviewed in Setup and Maintenance with the Manage Administrator Profile Values task, which gives access to all profile options, by searching for the code. According to Oracle, the site level allows a single row and changes take effect the next time the user signs in. In practice, it is worth signing in again as the integration user before repeating the test.
If the adapter wizard shows "Failed to fetch Business Events from Public Event Catalog" or does not list the event, Oracle's guide says to run Refresh Metadata on the connection. The current catalog is queried with GET https://<fusion>/soa-infra/PublicEvent/catalog.
Diagnostic order and verification
The following procedure separates the causes with evidence, from the most frequent after an update to the most specific:
- Record the exact activation error. A 401 or 403 leads to step 2; a successful activation with no events leads to step 4.
- Confirm whether LBAC is enabled in Fusion and whether the current Oracle Integration outbound IP is allowed. Review other allowlists configured with the old addresses.
- Check the connection user's roles in the Security Console, especially
SOAOperator. - Query
/soa-infra/PublicEvent/subscriptionsand compareendpointURL,filterandstatewith the active integration. - Query
/soa-infra/PublicEvent/catalogto confirm the event exists. If the wizard does not show it, run Refresh Metadata. - Review, with Manage Administrator Profile Values, the profile option that enables the event in the relevant product, and sign in again after changing it.
- Raise a test event and check in Oracle Integration, under Observability and Fusion Applications, whether Fusion attempted to send it.
If all seven steps come back correct and the event still does not arrive, the evidence gathered is what Oracle Support asks for to continue: the subscriptions response, the catalog, the roles and the profile values.
Xterra Engine reviews Oracle Integration integrations with Fusion events before and after each update, with an inventory of subscriptions and a test of every event.