1. Using Integrations in Oracle Integration 3
  2. Best Practices
  3. Avoid Common Integration Pattern Pitfalls

Avoid Common Integration Pattern Pitfalls

Designing integrations correctly from the start can save you a tremendous amount of rework. This section describes common integration pattern pitfalls (known as antipatterns) and best practices for avoiding these pitfalls.

Chatty Integrations

Use Case: Synchronize records in a file or large data set with an external system (for example, synchronize journal transactions or upload employee records into Oracle HCM Cloud).

Antipattern Why an Antipattern? Best Practice
Use an invoke activity within a looping construct to call external APIs for every record.
  • Downstream applications are receiving a large number of atomic requests. This puts the entire system under duress.
  • A usage-based pricing model translates to high costs.
  • Leverage application capabilities to accept multiple records in a single request:
    • Salesforce: 200 records, Oracle Engagement Cloud/Oracle ERP Cloud: 100 records, Oracle Service Cloud: 1000 records
  • Leverage adapter capabilities to send a large data set as attachments/files.
    • Salesforce Adapter: 10,000 records/10 MB files, Oracle ERP Cloud Adapter supports FBDI files.
  • Use a stage file action (the append to file option) to send the file to the destination at the end.

Scheduled Job that Never Stops Trying to Process

Use Case: Process records within a set of files with a tight service level agreement (SLA) (for example, synchronize employee records into Active Directory from Oracle HCM Cloud or send benefits information).

Antipattern Why an Antipattern? Best Practice
The schedule integration looks for all files to process and loops over all to sequentially process until no files remain.
  • If a large number of files exist, one run of a scheduled job processes for a long time and starves other jobs and may get terminated by the framework.
  • Processing tied to a single server: this does not leverage multiple nodes in a cluster.
  • Limit the number of files to process in a single scheduled run.
    • Limit results from the list file.
  • Use schedule parameters to remember the last processed file for the next run.
  • Invoke the run now command from the same integration to trigger processing of the next file if waiting for the next scheduled run is not feasible.

Import an Externally Updated IAR File

Use Case: Need to leverage advanced XSL constructs that may not be available in the mapper.

Antipattern Why an Antipattern? Best Practice
Update the IAR file externally and then import it into Oracle Integration.
  • This can lead to metadata inconsistency and validation failures.
  • Activation failures may occur.
  • Use the import map feature in Oracle Integration.
    • Keeps metadata consistent and leverages validation.
    • The mapper can show an imported map and allow it to be edited.

Synchronous Integration Doing Too Much

Use Case: A request triggers complex processing involving enrichment and updates across multiple systems.

Antipattern Why an Antipattern? Best Practice
  • Huge synchronous integrations designed with a large number of invokes /conditional logic.
  • Synchronous integrations with invokes within a loop with a large number of iterations.
  • Susceptible to timeouts. Any marginal slowdown adds up.
  • Blocking call. Holds resources and starves other integrations.
  • Consider moving completely to an asynchronous integration (fire and forget, asynchronous response).
    • The integration platform provides an acknowledgment to clients upon receiving the message.
    • The integration platform ensures guaranteed processing and also supports resubmission of failures.
  • Split into a synchronous integration containing mandatory processing before sending out a response and triggering separate asynchronous fire and forget integrations for other processing logic.
  • Optimize synchronous processing with a coarse-grained external API to replace multiple chatty calls.

Too Many Connections in an Integration

Use Case: When developers create integrations, they define their own connections pointing to the same application. This leads to many duplicate connections.

Antipattern Why an Antipattern? Best Practice
Every developer creates their own connection using a different set of configurations/credentials.
  • A high number of connections make manageability painful, especially when you need to update the endpoint, credentials, configuration, and so on.
  • Impact analysis is complicated when there is an application upgrade or metadata/coordinate change.
  • Have a custodian create needed connections and ensure that duplicate connections of the same types are not created.
    • Build a best practice for naming conventions and maintaining a set of configurations.
  • Use the Configuration Editor to edit/replace the connection in an integration.

Read Files with Many Records

Use Case: Read a file with a large number of records and process individual records.

Antipattern Why an Antipattern? Best Practice
Read the entire file in memory using the read file option and process it record by record.
  • Large amounts of memory are consumed and other system processing is impacted.
  • Sequential processing does not leverage built-in map reduction capabilities.
  • Download the file to the staged location using the download file option.
    • Stage files are secured and deleted at the completion of the instance.
  • Use the read file with segments option.
    • You can still model record level processing inside the segment processing.
    • The platform automatically processes segments in parallel.
    • The platform brings in only portions of the file to memory, when needed.

Integrations Running Unchanged Despite Changing Business Needs

Use Case: Integrations/schedules created during the initial implementation continue to run even though your business requirements have changed over time.

Antipattern Why an Antipattern? Best Practice
  • Integrations and scheduled jobs created during the initial product implementation are never re-evaluated against changing business needs.
  • A proliferation of integrations occurs without looking at existing integrations.
  • Unnecessary runs of jobs that handle no work.
  • Unoptimized invocations of multiple integrations with similar functionality.
  • Clutter with dead integrations, lifecycle management (LCM) overhead, and developer confusion.
  • Periodically analyze existing integrations/schedules against current business needs.
    • Look at monitoring data for historical runs.
  • Consolidate integrations that are very similar.
    • Integrations A and B subscribing to the Customer Created event in Oracle Engagement Cloud: integration A for invoking endpoint A and integration B for invoking endpoint B.
  • Deactivate nonrelevant integrations.
    • An integration for generating a file meant for partner consumption becomes irrelevant when the partner no longer needs it.
  • Adjust the schedules for integrations that need lesser frequency and delete schedules no longer required.
    • Files generated monthly have schedules run every few minutes.
    • Changes in business needs can make certain schedules completely unnecessary.