Integration Patterns and Methodologies
In today’s digital world, businesses use many different systems and applications to run their operations – but these systems often don’t communicate with each other by default. That’s where integration comes in—it helps connect everything so data can flow smoothly between systems. To do this effectively, developers and architects use specific integration patterns and methodologies. These are tried-and-tested ways to solve common integration problems. Whether it’s sending data in real-time, handling large batches, or syncing between cloud and on-premise systems, understanding these patterns helps build smarter and more reliable solutions. 
In this blog, we’ll explore the various practical ways to connect with different systems and process the data efficiently and why we need to follow a proper integration pattern.
Method 1: Publish – Subscribe:
The Publish-Subscribe (Pub-Sub) pattern is an integration model where one system (called the Publisher) sends data or events without knowing who will receive it, and other systems (called Subscribers) listen for and react to that data or event. Instead of sending data directly from one system to another, the data is sent to a messaging channel (like a queue, topic or event bus), and multiple subscribers can independently receive and process it.
Example:
Recently, I worked on an integration scenario where a customer needed to share Oracle Sales Order data in near real-time with a third-party system, specifically Microsoft Dynamics 365. The challenge? Ensure the data is shared in a scalable, loosely coupled, and real-time manner. That’s where the Publish-Subscribe pattern truly shines.
In this setup:
- OIC acts as the Publisher:
Sends (publishes) messages or data to a central channel (topic) after processing incoming events like Sales Order Notifications - Azure Service Bus serves as the Message Broker:
A cloud-based messaging service that receives messages from publishers and reliably routes them to subscribers. - Dynamics 365 is the Subscriber.
Listens to the topic and consumes the published messages to update its records or trigger business processes.
Let me walk you through how we approached it using Oracle Integration Cloud (OIC) and Azure Service Bus.
1. The Trigger: Sales Order Event in Oracle ERP Cloud
Everything begins when a sales order is created or updated in Oracle ERP Cloud. The SalesOrderNotification event, which is part of the Order Management module, gets triggered. We ensured this event was activated through the right business event configurations—this is essential because it forms the heartbeat of the integration.
2. OIC Picks It Up Instantly
Once the event is fired, OIC (Oracle Integration Cloud) immediately springs into action. It has a listener flow configured specifically for this event, and as soon as the notification hits, the integration is triggered.
3. Fetching the Sales Order Data
The next step is all about data retrieval. We used the SOAP Adapter in OIC to call a BIP report inside Oracle ERP Cloud. This report was pre-built to extract the exact fields the downstream system required—nothing more, nothing less. Keeping the payload lean and relevant was key to performance.
4. Data Transformation: Making It JSON-Ready
Once we got the data, the next challenge was formatting. Oracle ERP outputs data in XML, but the consuming system (in our case, Dynamics 365) expected JSON. We handled this transformation smoothly using its built-in mapper. This step is crucial for system compatibility and ensures that data flows seamlessly.
5. Publishing to Azure Service Bus
Here’s where the publish part kicks in. OIC used the Azure Service Bus Adapter to push the transformed JSON message to a specific topic named salesorders-upsert. We made sure the adapter was configured to handle the structure securely, and ensured retry logic was in place for reliability.
6. Real-Time Consumption by Dynamics 365
Now comes the subscribe part. Microsoft Dynamics 365 is subscribed to the salesorders-upsert topic. The moment the message is published by OIC, Dynamics picks it up in real-time, processes the order data, and performs the necessary updates on its end—whether it’s creating a new record, updating an existing one, or triggering downstream workflows.
What made this pattern so effective was decoupling. OIC doesn’t need to know who’s consuming the message or how many systems are subscribing. This makes it highly scalable—tomorrow, if another system needs to consume sales order data, it can simply subscribe to the same topic without modifying the existing integration.
Method 2: Batch Processing:
Batch processing is a method of handling a large volume of data together at once, instead of processing it record by record in real time. We use this method of integration for the data sync where we don’t need the real-time results or process data accumulated over a specific period at once. In this following example, it explains Oracle inbound using FBDI (File Based Data Import) which is one of the most commonly used methods or formats to perform bulk imports to oracle Cloud. This method of processing is widely used in case of data loads where source and target system support bulk data handling.
Example:
One of the most common yet business-critical use cases I’ve handled is automating the import of General Ledger (GL) data from a file server into Oracle ERP Cloud. A customer had been doing this manually, uploading FBDI templates, triggering ESS jobs, and waiting for results. Not only was it time-consuming, but prone to errors and delays. They wanted to automate the entire process — and this is where the file-based integration pattern with Oracle Integration Cloud (OIC) came into play.
In this setup:
- File Server is the Source system: A system that stores and shares files over a network for multiple users to access.
- OIC (Oracle Integration Cloud) is the Middleware:
A cloud-based platform that connects applications and automates business processes across systems. - Oracle ERP is the Target System:
A suite of cloud-based enterprise resource planning applications that manage business functions like finance, procurement, and supply chain.
Let me walk you through how we approached it:
1. Scheduled Trigger in OIC
We set up a scheduled integration in OIC to kick off the process every night at midnight. This ensured the data was always up-to-date by the time finance teams started their day. No more manual starts, no dependencies on human action.
2. Retrieving the GL File from File Server
OIC then connects to the File server, using File server Action then downloads and reads the source CSV file with GL data.
3. Transforming Data to FBDI Format
Now comes the transformation piece. The CSV data couldn’t go into ERP as-is. OIC maps and converts the data into Oracle’s FBDI format for journals. This mapping was crucial because Oracle expects a very specific structure in the FBDI template for it to be processed successfully.
4. Creating a ZIP Archive
Oracle ERP requires the FBDI template to be zipped along with a properties file. So OIC generated both — the transformed .csv file and a .properties file containing metadata like job name, import parameters, and more. These were then packaged into a ZIP archive, ready for upload.
5. Uploading to Oracle ERP Cloud
Next, OIC uses the ERP Cloud adapter to upload this ZIP file to Oracle’s UCM (Universal Content Management) server. This part ensures the ERP system has the files ready and stored securely before import.
6. Triggering the Import Job
Once uploaded, OIC called the “Load Interface File for Import” ESS job inside Oracle ERP Cloud. We specified the job Import Journals — to instruct Oracle to begin processing the uploaded file and load it into the GL interface tables.
7. Monitoring and Call-back Handling
No integration is complete without monitoring. Once complete, it uses a call-back mechanism to capture the result — whether it was successful or failed. In case of errors, the integration sends out alerts with clear logs so the finance team could take corrective action quickly.
This integration pattern saved the customer hours of manual effort, reduced human error, and brought predictability and traceability to a critical financial process. What’s powerful here is how OIC orchestrated multiple steps seamlessly — file pickup, transformation, compression, upload, job execution, and monitoring — all without manual intervention.
Method 3: Event Driven Real-time Integration:
Real-time integration refers to the immediate and continuous exchange of data between different systems, applications, or devices. This means that when an event or change occurs in one system, it’s instantly reflected in another, ensuring that all connected systems have the most up-to-date information without noticeable delays. This approach is crucial for scenarios where timely data is essential, such as financial transactions, inventory management, or customer interactions.
Example:
Consider a Scenario where a company uses Oracle ERP Cloud for order management and a third-party logistics system for shipping.
One of my recent implementations involved real-time synchronization between Oracle ERP Cloud and a third-party logistics platform—streamlining the entire order-to-ship process. Previously, orders sat in ERP until someone manually kicked off the logistics workflow. Inefficient, error-prone, and not acceptable at scale.
This is where an event-driven integration pattern with Oracle Integration Cloud (OIC) saved the day.
In this setup:
- Oracle ERP is the Source System:
- A suite of cloud-based enterprise resource planning applications that manage business functions like finance, procurement, and supply chain.
- OIC (Oracle Integration Cloud) is the Middleware:
- A cloud-based platform that connects applications and automates business processes across systems.
- Logistics system is the Target System:
- A system that manages the planning, execution, and tracking of the movement and storage of goods across the supply chain.
Let me walk you through how we tackled it:
1. Order Created in Oracle ERP Cloud
Sales teams enters a new order—complete with customer info, item list, quantities—directly in ERP.
2. Event Trigger Fires Immediately
We configured ERP to emit an Order Header Status Update event as soon as the order was saved. This automatic trigger kicks off the flow—no polling, no delays.
3. OIC Picks Up the Event
OIC’s ERP adapter catches the event in real time. We built the flow to parse the payload, handle any required transformations—mapping fields, converting timestamps — to align precisely with the partner’s API schema.
4. Transformations & Data Enrichment
We ensured the payload was enriched cleanly. We mapped ERP order fields directly to the logistics format, applying business rules as needed.
5. API Call to Logistics System
Once the data was prepped, OIC called the third-party logistics platform’s REST API in an asynchronous, fire-and-forget fashion.
6. Shipment Processing Begins Immediately
As soon as the logistics system got the call, it kicks off picking, packing, and scheduling. No spreadsheet handoffs or Excel exercises—just clean, real-time handoffs.
This real-time integration ensures seamless communication between systems, reducing manual interventions and improving operational efficiency.
Choosing the right integration pattern or methodology is like picking the best route for a journey—it makes sure data flows smoothly, systems work in sync, and results arrive on time. Whether it’s real-time, event-driven, or batch, the right approach ensures efficiency, reliability, and better business outcomes.Apps Associates has more than twenty years experience with Oracle technologies and excels at complex integration structures. Our team of integration specialists can help you choose and implement the right strategy for your business – uniting your disparate systems and creating tech harmony.
