In the diagram below the direction of the arrows indicates the flow of a message transfer, i.e. Point of Sale (PoS) sends messages to Custom Relationship Management (CRM) system etc.
Firstly, it is important to define integration use cases and then to analyze how to implement them using EIPs taking into consideration existing requirements:
- For analitical purposes ERP needs hourly a list of specified users with additional data (e.g. amount of money spent in current week).
- ERP upon PoS request generates a report based on the database data, stores it in a file and then sends the information to the specified email address and PoS JMS queue.
- If required PoS makes a request to CRM for information about a particular customer.
- For external systems, PoS provides SOAP based services extracting data from JMS.
It is obvious that not all systems are developed on the same platform and don’t use the same communication protocols. Let’s now explain all the available services:
- CRM provides SOAP based web services,
- PoS is a new system and communicates via JMS,
- ERP is a very old system and does not provide any external interface. The only way to communicate with ERP is inserting data to particular database tables.
So, let’s start with EIP diagrams. FuseSource developed a useful set of Eclipse plugins named Fuse IDE and I’ll use the designer provided with this tool.
Use Case 1
Here is a diagram and camel code that shows integration logic for this case:
As you may note there are a lot of EIP’s and DSL code but don’t be put off and continue reading this article. Most of this code is solely used for technical reasons and is so simple that even a person unfamiliar with Camel will understand it. In the diagram I underlined 5 with thick red line EIP’s which I consider as really important.
First (①) is EveryHourTimer which starts the route every hour. Second (②) is SelectCustomer which executes query, defined in SelectCustomerQuery (this is first strictly technical EIP). Then each of the queried customers needs to be supplemented with additional data. SplitCustomer (③) splits customers and invokes the web services defined in FetchCustomerInfo (④). CustomerProcessor is written in Java and it not only creates a new POJO with JAXB annotation but also adds additional information to existing data resulting from SelectCustomerQuery. Below is the code for this simple processor and Customer POJO:
Web service operation name with its namespace is placed in setHeader markup (another technical EIP).
Last action that needs to be performed is to update customers data in ERP database which is configured in UpdateCustomers (⑤). Of course before executing the updating query we need to extract additional data using XPath (setHeader with xpath markups) and place it in message headers. The same applies to the query itself but in this case “storage” is placed in message body (setBody markup).
I can tell you that this is one of the most complex routes that I have ever written so please try to analyze it thoroughly and I’m sure that you will derive from it a lot of practical information.
Use Case 2
The second use case will be much simpler. As I have already written, ERP is a very old monolithic system which communicates only through database tables. PoS doesn’t have access to this database. Fortunately integration platform has such rights, so the architect decided to create very simple REST service which takes customer and places it in proper database table which acts as a queue. ERP every 5 minutes reads this table, generates the report file and saves file in FTP server. Integration platform is responsible for polling FTP server and sending report to a particular email address and PoS queue.
Processor which sets customerId header.
Use Case 3
Most of web services developed in applications don’t require any mediation. Integration platform serves as a proxy and provides a central point of access to all services. Therefore this example shows HTTP proxy that intercepts the message and sends it forward. All systems need to know only access address to all services.
Use Case 4
This last case is similar to the third one. But this time, this requires the creation of WSDL’s. Service sends the message to a particular JMS queue and waits for the response from queue referred in JMS-ReplyTo. The last action that needs to be performed is to send the message to the web service client.
CXF Web service definition (cxf namespace is defined as xmlns:cxf=http://camel.apache.org/schema/cxf):