Twelve reusable patterns, real-world examples, and implementation guidance for Oracle Integration 3
About this field guide
I wrote this guide to connect Oracle Integration features with the architecture decisions we make on real projects. It presents twelve practical patterns, each supported by an enterprise or healthcare example, an architecture view and a sequence diagram. The aim is to make the patterns easy to recognize, compare and apply - not simply describe product features.
How to read this guide
These patterns are building blocks rather than isolated templates. A
production solution may combine an API facade, orchestration, asynchronous hand-off, and a parking lot. Start with the business interaction, then use the diagrams to understand how OIC and the participating systems work together.
- *Synchronous request–reply Pattern * Use when the caller needs an immediate business response. A REST/SOAP trigger validates and maps the request, invokes one or more applications, and returns a consolidated response. Keep the flow short because the client connection remains open.
Example. A provider portal submits an eligibility inquiry. OIC calls a payer eligibility API and returns coverage, copay and deductible in the same interaction.
- *API facade and protocol mediation Pattern * Place OIC between consumers and a legacy or SaaS interface to hide protocol, schema, and authentication differences. The facade exposes a stable contract while mappings and adapters absorb downstream change.
Example. A mobile claims app sends JSON/REST. OIC transforms it to the SOAP/XML contract required by a legacy claims platform, then converts the response back to JSON.
- *Content-based routing Pattern * Inspect payload or header values and use switch branches to send each message to the correct target. Centralize routing rules and define a default path so unexpected values are observable rather than silently discarded.
Example. A claim is routed to the commercial, Medicare, or Medicaid pricing service according to line of business and state.
4.Orchestration and aggregation Pattern
Coordinate a multi-step business transaction, including sequential invokes, enrichment, decisions, and response assembly. Use scopes for local fault handling; avoid holding a synchronous caller through long-running work.
Example. Member onboarding creates the member in CRM, validates identity, enrolls benefits, and combines the generated identifiers into one completion record.
5.*Parallel fan-out and gather Pattern *
Invoke independent services concurrently and aggregate their results. This reduces elapsed time when branches do not depend on one another. Define how partial failures are reported and whether every branch is mandatory.
Example. Before claim adjudication, OIC obtains eligibility, provider status, and authorization in parallel, then builds a single validation result.
6.*Asynchronous hand-off Pattern *
Acknowledge quickly, then perform slow or high-volume processing outside the original request. Use a queue, event service, or one-way invocation, and carry a correlation ID for status and callbacks.
Example. A hospital submits a large encounter batch and receives HTTP 202 with a tracking ID. OIC processes records asynchronously and later posts completion status.
7.*Publish–subscribe Pattern *
Publish one canonical business event and let multiple subscriber integrations react independently. This reduces point-to-point coupling and allows new consumers without changing the publisher. Design subscribers to be idempotent.
Example. A Patient Update event independently updates CRM, analytics and care-management systems through Oracle Integration Messaging or an external event backbone.
8.*Event-driven integration Pattern *
Trigger processing when a business or cloud event occurs instead of polling. Events may originate in SaaS applications, OCI Events, streaming, or messaging services. Include filtering, deduplication, and replay strategy.
Example. An object-created event for a remittance file starts validation and posting immediately after the file lands in OCI Object Storage.
9.*Scheduled polling and incremental synchronization Pattern *
Run on a defined schedule when the source cannot emit events. Query records changed since a stored high-water mark, process bounded pages, and advanced the watermark only after successful completion.
Example. Every 15 minutes OIC reads newly changed provider records from an on-premises database through the connectivity agent and upserts them into Oracle Fusion Cloud.
10.*Bulk data and file transfer Pattern *
Move large datasets through files rather than chatty record-level calls. OIC can use FTP/SFTP, File Adapter, Object Storage and Stage File actions to list, read, write, zip, unzip, encrypt or decrypt content. Stream or segment large files.
Example. A nightly enrollment CSV is collected from SFTP, decrypted, split into manageable batches, transformed and loaded into the benefits platform. Rejected records go to a separate file.
- *B2B / EDI gateway Pattern * Use trading partner agreements, document definitions, and transport settings to exchange X12 or EDIFACT. Translate between EDI and canonical application messages, validate envelopes, track acknowledgements, and retain business-level visibility.
Example. A health plan receives X12 837 claims over AS2, validates and translates them, submits canonical claims internally, and returns the appropriate acknowledgement.
- *Reliable delivery, retry and parking lot Pattern * Wrap volatile invokes in scopes, classify faults and retry only transient failures with controlled backoff. Persist exhausted or data-related failures in a parking-lot store with payload, error and correlation data for correction and replay.
Example. If a provider API times out, OIC retries. After the limit, it stores the request in ATP, alerts operations and allows for safe resubmission after correction.
*Choosing and combining patterns *
Start with the interaction contract.
Use synchronous request–reply only when the answer is fast and required immediately.
Use asynchronous hand-off for long running or bursty work.
Prefer events or publish–subscribe when several consumers should evolve independently.
Use scheduling only when the source cannot notify OIC and protect scheduled extraction with watermarks and paging.
Use files for genuine bulk payloads and B2B when partner agreements, EDI validation, and acknowledgements matter.
Across every choice, design idempotency, correlation, security, observability, fault classification and replay from the beginning.
*Architecture guardrails *
Keep canonical messages business focused. Do not expose one application’s schema as the enterprise contract.
Separate real-time APIs from long-running work, and do not chain many synchronous dependencies.
Track a business identifier and correlation ID across every hop and never rely only on an OIC instance ID.
Make consumers and replay operations idempotent, especially for events, retries and file reprocessing.
Use the connectivity agent for private endpoints and keep secrets in managed connection/security policies.
Define operational ownership, alert thresholds, retry limits, parking-lot triage, retention, and recovery objectives.
*Oracle references *
Understand Integration Styles
Publish and Subscribe with Oracle Integration Messaging
Create Scheduled Integrations
Stage File Processing
Parallel Processing
OIC Design Best Practices
Top comments (0)