SOA Integration - Modernizing

Modernizing—Integration with SOA

The main objective of the modernization process, from a business perspective, is the realtime integration of orders.

From a technical standpoint, there are other objectives, including the continued use of the batch mode through file connections. This means that the new solution must completely replace the old one, and the two solutions should not be left running in parallel. A further technical objective is that of improved support as a result of the introduction of a suitable infrastructure.

On the basis of these considerations, a new SOA-based integration architecture was proposed and implemented, as shown in the following diagram:

Trigger:

Each new order is published to a queue in the ERP database, using the change data capture functionality of the ERP system.

Flow:

1. The business event is consumed from the queue by an event-driven consumer building block in the ESB. The corresponding AQ adapter is used for this purpose.
   .
2. A new BPEL process instance is started for the integration process. This instance is responsible for orchestrating all the integration tasks for each individual order.
   .
3. First, the important order information concerning the products and the customer must be gathered, as the ERP system only sends the primary key for the new order in the business event. A service is called on the ESB that uses a database adapter to read the data directly from the ERP database, and compiles it into a message in canonical format.
   .
4. A decision is made about the system to which the order should be sent, and about whether feedback on the order is expected.
   .
5. In the right-hand branch, the message is placed in the existing output queue (send). A message translator building block converts the order from the canonical format, to the message format used so far, before it is sent. The AQ adapter supports the process of sending the message. The BPEL process instance will be paused until the callback from the external applications is received.
   .
6. The message is processed by the external application in the same way as before. The message is retrieved, the order is processed and, at a specified time, a feedback message is sent to the feedback queue (receive).
   .
7. The paused BPEL process instance is reactivated and consumes the message from the feedback queue.
   .
8. An invoke command is used to call another service on the ESB, which modifies the status of the ERP system in a similar way to the current solution. This involves a database adapter making direct modifications to a table or record in the ERP database.
   .
9. In the other case, which is shown in the branch on the left, only a message is sent to the external systems. Another service is called on the ESB for this purpose, which determines the target system and the target format based on some information passed in the header of the message.
   .
10. The ESB uses a header-based router to support the content-based forwarding of the message.
    .
11. Depending on the target system, the information is converted from the canonical format to the correct target format.
    .
12. The UK app already has a web service, which can be used to pass the order to the system. For this reason, this system is connected via a SOAP adapter.
    .
13. The two other systems continue to use the file-based interface. Therefore, an FTP adapter creates and sends the files through FTP in XML or CSV format.
    .
14. In order to ensure that the external application (labeled GE app in the diagram) still receives the information in batch mode, with several orders combined in one file, an aggregator building block is used. This collects the individual messages over a specific period of time, and then sends them together in the form of one large message to the target system via the FTP adapter.
    .
15. An aggregation process is not needed for the interface to the other external application (labeled CH app in the image), as this system can also process a large number of small files.

Evaluation of the new solution

An evaluation of the new solution shows the following benefits:

• The orchestration is standardized and uses only one technology.
  .
• One BPEL instance is responsible for one order throughout the entire integration process.
  • This simplifies the monitoring process, because the instance continues running until the order is completed; in other words, in one of the two cases until the feedback message from the external system has been processed.
    .
• The orchestration is based only on the canonical format. The target system formats are generated at the last possible moment in the mediation layer.
  • Additional distribution channels can easily be added on the ESB, without having to modify the orchestration process. 
    .
  • The solution can easily support other protocols or formats that are not yet known, simply by adding an extra translator building block.

Where to buy this book

You can buy Service-Oriented Architecture— An Integration Blueprint from the Packt Publishing website: http://www.packtpub.com/service-oriented-architecture-an-integration-blueprint/book

Free shipping to the US, UK, Europe and selected Asian countries. For more information, please read our shipping policy.

Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet book retailers.