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_EVENTS option must be set to Y. 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_EVENTS option defaults to Y. With N, 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:

  1. Record the exact activation error. A 401 or 403 leads to step 2; a successful activation with no events leads to step 4.
  2. 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.
  3. Check the connection user's roles in the Security Console, especially SOAOperator.
  4. Query /soa-infra/PublicEvent/subscriptions and compare endpointURL, filter and state with the active integration.
  5. Query /soa-infra/PublicEvent/catalog to confirm the event exists. If the wizard does not show it, run Refresh Metadata.
  6. Review, with Manage Administrator Profile Values, the profile option that enables the event in the relevant product, and sign in again after changing it.
  7. 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.

///// CONTACT

Facing something similar?

Tell us what you are working on and we will look at it together.

Based in Guatemala City (UTC−6), working with organizations in Central America and the United States during U.S. business hours, in English and Spanish.

CONTACT REQUEST↗

0 / 3000

Your message will be sent to info@xterraengine.com.