About Building Resilient Asynchronous Integrations

You may sometimes find that your integrations are brittle, unable to handle even brief or temporary interruptions. You need your asynchronous integration to scale efficiently, and you need options for developing and testing such integrations to ensure it will work as expected in production. This solution playbook presents suggested approaches for building asynchronous integrations that are resilient to the realities of the modern networks and infrastructures.

For example, when you're creating entities on a financial cloud using the REST APIs, temporary interruptions may occur during creation of expense reports, bank accounts, or other entities. To dynamically throttle such requests hitting Financial Cloud, the parking lot pattern is discussed in this playbook. With the parking lot pattern, you can store the data in an intermediate stage before processing the data to avoid processing challenges like batch, complex message correlation/flows, and throttling.

About Integrations in Oracle Integration

Integrations are the main ingredient of Oracle Integration. An integration includes at the least a trigger (source) connection (for requests sent to Oracle Integration) and invoke (target) connection (for requests sent from Oracle Integration to the target) and the field mapping between those two connections.

When you create your integrations, you build on the connections you already created by defining how to process the data for the trigger (source) and invoke (target) connections. This can include defining the type of operations to perform on the data, the business objects and fields against which to perform those operations, required schemas, and so on. To make this easier, the most complex configuration tasks are handled by Oracle Integration. Once your trigger (source) and invoke (target) connections are configured, the mappers between the two are enabled so you can define how the information is transferred between the trigger (source) and invoke (target) data structures for both the request and response messages.

About Parking Lot Pattern

In the parking lot pattern, data is stored in an intermediary stage prior to complete processing the data from the intermediate stage to the end system.

Here are some of the possible alternatives for storing the actual data within the parking lot. Each option has different properties that need to be considered:

The simplest approach is to store data as a CLOB in XML form. This method adds some additional overhead writing and reading the CLOB as well as transforming between the XML and the CLOB.
You can store data separately in other tables with fully realized columns. This method is most appropriate if within the application the de-batching process is already copying the input payload to a tabular format in the database table. So that the data format could be leveraged for the parking lot.
Combine the table with the parking lot itself. While this solution might prove to be the most performant, it can only work for simple data structures in the parking lot.

About Resiliency

Before diving into what will make your environment resilient, you first need to define what resiliency means to you and your business.

In other words, what is the cost associated with an outage of your integration processes. For some customers, an outage of a few minutes is perfectly acceptable and will only partially delay a batch process that runs well within its processing window. For others, even a few seconds of outage result in financial losses that have a direct impact on the business.

From that perspective, it is important to look at the following elements:

What is the duration of an acceptable outage in your environment? Here you should define the cost to the business in case of an outage, and outline how that outage evolves with the duration of the outage.
What technologies are used and how can they deliver on the expected SLA? Are you taking a real-time or batch approach? Or a combination of the two? How much data are you processing?