Design Best Practices

Create Schedule Integrations Mindfully

When there are too many schedule integrations configured, instances can become backlogged waiting for resources to become available or previous integration runs to complete. This can cause processing delays where some instances are in a waiting state longer than they must be and schedules may not start at the scheduled time.

As a best practice, do not create too many schedule integrations that are scheduled to run at the same time. Where possible:

Use an asynchronous REST Adapter trigger instead of a scheduled trigger when an active schedule is not absolutely required.
Do not create any long-running schedule integrations (a schedule integration that takes longer than one hour, for example, to complete). This blocks scheduler resources impacting other scheduled runs.
Spread schedules out over time to avoid schedule clusters.

You can convert a schedule integration to a REST Adapter trigger-based application integration. See Convert a Schedule Integration to a REST Adapter-Triggered, Application Integration.

If you absolutely require a large number of schedule integrations, and you encounter the previously described issue, the following design changes as a solution are recommended:

For each schedule integration, convert it to a REST Adapter trigger-based application integration. See Convert a Schedule Integration to a REST Adapter-Triggered, Application Integration.
Create a new schedule integration that only performs an asynchronous invoke of the application integration you converted in step 1 above.
This solution enables the schedule integration to start at the scheduled time, invoke the REST Adapter trigger-based child integration asynchronously, and complete within milliseconds. This approach reduces the backlog and contention surrounding scheduler resources.
If you have a large number of schedule integrations to convert, a staged approach starting with the following integrations is recommended.
- Longest-running schedule integrations.
- Schedule integrations configured with the shortest frequency (for example, integrations that run every 10 minutes or less).
Design any new schedule integrations with the design practices described above.

See Schedule Integrations Are Not Running on Time and When a Schedule Integration Instance Gets Terminated.

Follow Guidelines for Synchronous Integrations

Note the following best practices when designing a synchronous integration.

A synchronous integration calling any asynchronous request response service:
- Calling asynchronous fire and forget (one-way) is acceptable.
- Oracle Integration does not currently allow modeling an asynchronous request response service. However, all schedule integrations internally use an asynchronous request response. Therefore, a synchronous integration using a schedule integration is an antipattern.
A synchronous integration calling multiple services that span more than five minutes is reported as a stuck thread.

Design Long-Running Integrations as Asynchronous

Note the following best practice when designing long-running or time-consuming integrations.

Do not expose long-running or time-consuming integrations as synchronous flows. This action can lead to client applications (including other integrations) timing out. Synchronous integrations also have a server-side timeout. Instead, model any synchronous integration taking more than two minutes as an asynchronous flow.

Understand Timeouts in Synchronous Integrations

You may have scenarios in which synchronous invocations from Oracle Integration (including calls to other integrations) are blocking calls and must complete within 300 seconds.

Because the call may involve one or more proxies, each of the proxies may have a similar timeout. For instance, the default proxy on Oracle Public Cloud has a timeout value of 120 seconds. If the call is to an on-premises service is behind a fire wall, the proxy configured may also have its own timeout value.

In case timeouts are defined at multiple layers, the service invocation fails at the first timeout.

Send Data to Third-Party Systems Efficiently

While there is no specific integration design to automatically enable an outbound integration to send data to different third party systems in parallel, there are integration design approaches that allow this scenario, including using parallel processing in outbound integrations.

Separate the integration into multiple integrations:

Create a main parent integration that only receives/processes the data.
Create separate child integrations to perform the individual outbound REST invocations.

The interface between the main and separate child integrations can follow these approaches:

Consist of dummy REST calls, but it must be asynchronous. Essentially, the asynchronous calls are not blocked by the response and the fire-and-forget design enables available threads to work on child integration processing in parallel, within the available system resources. This type of design is recommended because if all synchronous REST calls are done in the same integration, a timeout error may occur if the sum of time taken for each synchronous call exceeds five minutes.
Follow a publish/subscribe design approach (for example, putting the data events in a queue, having each child flow subscribe from the queue, and so on).