SCRIPT FOR TRAINING SESSION:
Introduction:
Welcome, everyone! This is Deeba Umar and Today, we’re diving into Enterprise Integration
Patterns or EIP. First things first, if you have any questions during the session, feel free to
drop them in the chat. Amir Bhai or I will address them at the end to keep the flow smooth.
These patterns help different systems talk to each other efficiently. Have you ever worked
on a project where two applications needed to share data, but the process was messy?
That’s where EIP comes in. By the end of this session, you'll understand key patterns, real-
world applications, and best practices to use them effectively.
Define:
"So, what is enterprise integration? Simply put, it’s the process of making different
applications within an organization to work together seamlessly. Imagine you run an online
store. You need to connect your website, payment gateway, inventory system, and shipping
service. Each of these uses different technologies and data formats, making integration
challenging."
"Some common challenges we face are:"
Different data formats – JSON, XML, CSV
Different protocols – HTTP, FTP, TCP
Synchronous vs. asynchronous communication – Real-time updates vs. batch
processing
Enterprise Integration Patterns provide structured solutions to these problems.
Main Explanation:
"I’ve categorized some common integration scenarios here and we’ll explore how
organizations synchronize data between applications (A2A) and businesses (B2B) using
API-led integration. We’ll focus on a Cloud-to-On-Premises scenario, breaking down key
integration patterns, challenges, and real-world examples.”
1. Application-to-Application (A2A)
"This is when different internal applications need to communicate with each other. A great
example is integrating an ERP system with a CRM to sync customer and order data. Tools
like Azure Logic Apps, Power Automate, APIs, and Service Bus make this possible.
2. Business-to-Business (B2B)
"This is when companies exchange data with external partners, like suppliers, distributors,
or logistics providers.
A common use case is a retail company exchanging order data with suppliers using EDI
(Electronic Data Interchange).
B2B, on the other hand, connects different businesses—imagine a supplier and a retailer
exchanging purchase orders. Data synchronization ensures that information remains
consistent across these systems, reducing errors and improving efficiency.
3. Data Synchronization Across Systems
"Here, we deal with keeping data in sync across multiple platforms. A typical example is
syncing HR data from Workday to Active Directory to automate employee onboarding.
4. API-Led Integration
As you can see from the figure, there are three kinds of APIs that are working together.
I’ll explain these with an example:
Imagine a retailer using APIs at different levels: System APIs fetch inventory data from the
database, Process APIs validate and process orders, and Experience APIs expose this
information to customers through a mobile app. This layered approach simplifies
integration and ensures scalability.
5. Cloud-to-On-Premises Integration
You must be aware that many enterprises run a mix of cloud and on-premises systems. For
example, an on-prem ERP like SAP sending inventory updates to an Azure-based
eCommerce site.
One of the biggest challenges in integrating cloud applications with on-premises systems is
security. For example, your ERP running on-premises might be behind a firewall, making it
difficult for a cloud-based CRM to access customer data. Additionally, latency and data
consistency must be managed—should data sync in real-time or batch mode? Handling
different protocols like REST APIs in the cloud and SOAP APIs in legacy systems is another
hurdle.
There are several ways to integrate cloud and on-premises systems. The simplest approach
is using Direct API Calls, where an API gateway secures access to on-premises services. A
more robust method is using a Hybrid Integration Platform like MuleSoft or Azure
Integration Services. For event-driven synchronization, Message Queues like Kafka or Azure
Service Bus enable async processing. Lastly, batch-based integration using ETL tools like
SSIS ensures periodic synchronization for reporting and analytics.
A retail chain faced a challenge: Their sales team used Salesforce to manage leads and
opportunities, while finance relied on an on-premises SAP system for billing and inventory.
The disconnect led to delays and errors in invoicing. The solution? Using Azure API
Management, they securely exposed SAP’s APIs to Salesforce, allowing seamless real-time
synchronization of sales orders and inventory. This improved accuracy and streamlined
operations
Let’s explore some key patterns now:
1. Request-Response Pattern
"First up, we have the Request-Response Pattern. It’s simple: one system sends a request,
and another system sends a response. Think of it like ordering coffee at a café—you place
an order, and the barista gives you your drink.”
Example: Let’s say a customer wants to check their order status using a chatbot. The
chatbot sends a request to the Order Service, and the service responds with the order
details. This is a direct, synchronous interaction."
When NOT to use it? When speed is critical, or you don’t need an immediate response.
A better approach might be event-driven messaging.
Example Tools: REST APIs, gRPC
Now we’ll discuss two powerful event-driven patterns used in enterprise integration:
**Event-Driven Architecture (EDA)** and **Event Sourcing**. Both use events but serve
different purposes. Let’s explore them with real-world examples!"
Event-Driven Architecture (EDA)
"Systems react to events instead of waiting for requests."
Example: Now, think about fraud detection in banking. Every time a high-value
transaction occurs, an event is triggered. The Fraud Detection Service listens to this event
and runs security checks. If something seems suspicious, it alerts the Security Team
immediately.
When NOT to use it? If you need strict ordering of transactions.
Example Tools: AWS EventBridge, Azure Event Grid
*"Imagine you run an e-commerce store. When a customer places an order, multiple
services need to react. Instead of directly calling each service, we publish an **Order
Placed** event. The Inventory Service updates stock, the Payment Service processes the
transaction, and the Shipping Service schedules delivery. This ensures our system is
scalable and loosely coupled."*
**Explaining Event Sourcing:**
*"Now, think about a banking system. If we store only the final balance of an account, we
lose history. Instead, using Event Sourcing, every transaction is stored as an event. This
means we can always reconstruct the account’s history, replay events for debugging, and
recover from failures without data loss."*
**Key Differences:**
*"EDA is about **real-time reactions** between services, while Event Sourcing is about
**storing and replaying events** to maintain system state. Together, they create powerful,
resilient enterprise systems."*
**Final Thoughts:**
*"By using both patterns, businesses can achieve **high availability, auditability, and
scalability**, making integration smoother across cloud and on-premises systems."*
4. Publish/Subscribe Pattern
"With the Publish/Subscribe model, one system publishes a message, and multiple
subscribers receive it. Think of it like subscribing to a YouTube channel—whenever a new
video is posted, all subscribers get notified."
Example: Imagine an e-commerce system where an order is placed. The Order Service
publishes an event, and multiple services subscribe to it: Inventory Service updates stock,
Billing Service processes the payment, and Shipping Service schedules delivery. None of
these services need to know about each other, making the system scalable and flexible
When NOT to use it? If you only need one recipient, a direct request-response model is
more efficient.
Example Tools: Kafka, RabbitMQ, Azure Service Bus
Now you must be thinking about why we need Event Driven architecture when there’s PUB-
SUB available. Well, the main difference between them is that EDA is a full architectural
style while the pub-sub is messaging model, it only decouples the sender and receivers. It
does not enforce events.
And the pub/sub is only a sort of part of EDA, it also does event processing and routing.
2. Saga Pattern for Distributed Transactions
What it does is that breaks down a process into multiple smaller steps.
"In a distributed system, transactions don’t always happen in one go. If one step fails, you
need a way to roll back the changes. That’s where the Saga Pattern comes in. Instead of a
single transaction, we have a series of smaller transactions, each with a rollback
mechanism."
The actions followed by the failure are known as Compensation transactions.
Example: Think of booking a flight. The system first reserves a seat, then charges the
payment, and finally updates the loyalty points. But what if the payment fails? The system
must roll back the reservation. This is where the Saga Pattern helps—it ensures that multi-
step transactions are either fully completed or properly undone.
When NOT to use it? If your system requires strict ACID transactions (Atomicity,
Consistency, Isolation, Durability), a database transaction might be better.
Difference between Choreography and Orchestration:
There are two kinds of saga patterns:
Choreography is the type of pattern in which a service task is dependent on the response of
the previous service. The services interact with each other directly.
While in the orchestration pattern, there’s an orchestrator service that decides what
service to call and it also handles the compensating actions.
Orchestration is preferred when there’s cycling dependency or complex integration it
provides the benefit of uni-dependency and easy testing, but there’s an added task of
creating the orchestrator service.
Example Tools: [Link], Kafka-based Choreography
3.
The next three patterns fall under Execution Triggers. How a task is executed.
The first one is Scheduled execution pattern, you can guess from the name in this a task
has to be scheduled. Some integrations don’t need real-time updates. Instead, they run at
scheduled intervals, like a nightly data sync. Like a recurrence which will execute task on
the pre-determined time.
Example: Payroll systems run salary calculations automatically at the end of the
month. This is an example of scheduled execution."
When NOT to use it? If real-time updates are required, an event-driven approach is
better.
Example Tools: CRON jobs, Azure Functions Timer Trigger
The other is manual, Sometimes, human intervention is required. in this the user has to
execute the tasks manually by calling APIs or through UI.
Example: In HR systems, managers manually approve leave requests before they are
processed. The system waits for human intervention."
When NOT to use it? When automation can improve efficiency and reduce human
errors.
Example Tools: SharePoint Workflows, Power Automate
The last is customized execution. Not all integration needs to fit a standard pattern.
Sometimes, a business requires a fully customized solution. I’ll explain this through the
example:
For example: "An e-commerce platform applies discounts based on customer
purchase history. The trigger is custom business logic, not a fixed schedule or event."
Example Tools: Drools, Azure Logic Apps
When NOT to use it? When existing patterns can offer a more maintainable and
scalable solution.
Tools & Technologies
"To implement these patterns, we use technologies like:"
🛠 Message Brokers: Kafka, RabbitMQ, Azure Service Bus
🛠 Enterprise Service Bus (ESB): MuleSoft, Apache Camel
🛠 Integration Platforms: AWS Step Functions, Spring Integration
This slide provides a comparison of different architectural patterns using Azure and AWS
services. Each pattern represents a common integration or execution strategy used in
cloud applications.
You can explore these tools in detail.
Moving on, we’re going to talk about how Azure Integration Services help us connect
different systems and automate business processes.
Let’s start from the left side of the diagram. A customer submits an order through a web
application. Once the order is placed, the web app sends a message to Azure Service Bus.
This is a message-based integration pattern. Now, the order message reaches Service Bus,
which acts as a queue. This means that even if our backend systems are slow, we won’t
lose the order request. This follows the Pub/Sub pattern. Once the message arrives on
Service Bus, an event is generated in Event Grid. Think of Event Grid as a notification
system that lets other services know when something important happens. Event grid is
used for EDA. Event Grid triggers Logic Apps, which orchestrate what happens next. Logic
Apps are workflows that automate tasks, like updating inventory, sending confirmation
emails, or notifying the warehouse to ship the product. Some parts of our system may need
to expose APIs for communication. That’s where Azure API Management comes in. It acts
as a gateway to control access between our cloud and on-premises systems. This covers
the API-led integration scenario. Now, let’s talk about how we connect cloud applications
with on-premises systems. Logic Apps use built-in connectors to update customer
information in CRM (Salesforce/Dynamics 365) and send order details to an SAP ERP
system. This covers A2A and B2B. So, what did we learn? Azure Integration Services help us
connect different systems using multiple patterns.
Now that we’ve seen how Azure Integration Services work, let’s quickly compare them with
AWS equivalents. While the names are different, the core functionality remains the same.
In short, AWS offers similar services with slightly different names and implementations.
Conclusion & Q/A
"That wraps up our session! We’ve covered key Enterprise Integration Patterns, their real-
world applications, and when to use or avoid them. Understanding these will help you build
scalable, efficient systems. I think we do have some time so let’s go through the questions
one by one! Amir bhai over to you. "