Skip to main content

Enterprise integration with WSO2 ESB + WSO2 MB and WSO2 DSS in a production environment with guaranteed delivery


Requirement
Customer has a SAP system from which he wants to send IDOCs to their respective endpoints and at the end of the day endpoints will send reports to the SAP system back. Here is the architecture of the deployment which customer is going to deploy in his production environment.
architecture
Basically customer want to send the information in the SAP system to the BE databases in a reliable and efficient manner without interacting in between.
Solution
In this solution we have used the following resources to achieve the requirement.
02 WSO2 Enterprise Service Bus
01 WSO2 Data Services Server
01 WSO2 Message Broker
Functionality
ESB01 – This ESB receives the IDOC message from the SAP server and save those documents in the WSO2 MB using message queues. Here we handle the high load of messages by saving them to the Cassandra data base  which is installed in a separate server. This will ensure that the high load of incoming messages are saved in the message queues without loosing any of the message.
ESB02 – This ESB consumes the saved messages from the message queues and apply the required transformation like changes and save the messages in a different set of queues. This will guarantee that the server is performing the transformations without bothering about receiving and saving the messages in the queues.
Message Broker – This will save the messages when they are receiving as a high load and guarantee that every message is successfully saved within the Cassandra database.
Data Services Server – This will push the messages from the message queues and load them back to the databases in the BE servers of the user. This will ensure that the every message saved in the message queues are automatically picked up by the data service and load them back to the databases in the BE.
Advantages
This setup will ensure that the messages are delivered without loosing any data in any kind of high load scenario (Guaranteed Delivery)
Isolation of the operation to different servers make it easy to maintain different parts of the operation.

Comments

  1. Have the detail setting and scripts?

    ReplyDelete
  2. You can find the settings and scripts from here http://soatutorials.blogspot.com/2013/09/building-in-order-reliable-messaging.html

    ReplyDelete
  3. This was an insightful explanation of enterprise integration with WSO2 ESB. I liked how the article breaks down the integration flow and makes a complex topic easier to understand. Even today, the concepts are highly relevant because many organizations rely on enterprise data services to connect applications, streamline data exchange, and improve operational efficiency across different systems. I'm wondering, how would you compare WSO2 ESB with today's API-first and event-driven integration platforms for building scalable enterprise architectures?

    ReplyDelete

Post a Comment

Popular posts from this blog

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...

WSO2 ESB usage of get-property function

What are Properties? WSO2 has a huge set of mediators but property mediator is mostly used mediator for writing any proxy service or API. Property mediator is used to store any value or xml fragment temporarily during life cycle of a thread for any service or API. We can compare “Property” mediator with “Variable” in any other traditional programming languages (Like: C, C++, Java, .Net etc). There are few properties those are used/maintained by ESB itself and on the other hand few properties can be defined by users (programmers). In other words, we can say that properties can be define in below 2 categories: ESB Defined Properties User Defined Properties. These properties can be stored/defined in different scopes, like: Transport Synapse or Default Axis2 Registry System Operation Generally, these properties are read by get-properties() function. This function can be invoked with below 2 variations. get-property(String propertyName) get-property(String scop...