Introduction
Our consultancy company is currently involved in many SAP XI implementations and audits. In our opinion implementations often suffer from too much ABAP expertise, but too little experience in specific integration issues and concepts. To improve this, we initiated the Dutch XI Experts, D-XIE, as an initiative to share gained knowledge amongst customer XI experts and colleague consultancy companies in the Netherlands.
We have planned to write a series of blogs for the SDN community to share our knowledge. In this first one we will describe different integration scenarios that XI supports. Just to set the basics for future blogs. We hope this D-XIE soap will be a good starting point for new and experienced XI developers.
Point-to-point Scenario
Many integration Projects start with building Point-to-Point Scenario’s. In this scenario every sending application has one receiving application.
Figure 1, generic point-to-point scenario
You don’t exactly need SAP XI in the middle, but there are advantages to do so. We could use XI to standardize interface definitions and mapping. XI as integration repository, and perhaps, when properly designed, as a starting point to re-use interfaces for other scenarios. Also the monitoring options of XI and the System Landscape Directory are very usefull new tools to keep in control of your integration administration and processes.
Figure 2, point-to-point with xi in the middle
XI can also be used as a protocol switch. To integrate legacy systems, webservices, or systems that only communicate through propriety protocols. For this, XI supports the integration of a wide range of adapters provided by many third parties.
Figure 3, point-to-point with protocol switch
XI as a protocol switch can even decouple asynchronous and synchronous scenarios, and integrate them altogether! This is done with the so-called synchronous-asynchronous bridge, which is supported in XI from 3.0 by using BPM (Business Process Modeling).
Figure 4, synchronous-asynchronous bridge
Hub and Spoke Scenario
A next step could be to collect and distribute messages and services through a hub and spoke configuration. In this scenario one sender application has one or more receiving applications. The integration hub, in our case XI, decides at runtime on certain rules and conditions which applications apply to the message. Options are to translate the original messages using mapping programs, or to include protocol switching.
Figure 5, Hub and Spoke
By mapping the Sender and Receiver messages to common interface definition makes it easier to add Sender and Receiver applications. This principle will be explained in the up coming blogs. Doing this, to let senders and receivers follow these standard, you can quite easily connect new applications without having to implement a whole new interface on both sides. This makes a hub very flexible. Hub and spoke in this form is the basic integration scenario that XI supports.
Publish and Subscribe Scenario
The Hub and Spoke can be also be implemented as a Publish and Subscribe mechanism. Now, the sender does not care anymore who ever want to listen to the message he has sent. He only knows the hub. In his opinion, there can be zero to any receivers. Any receiver can subscribe to the message type, and will receive such directly when connected.
Figure 6, Publish and Subscribe, receivers subscribe to hub
Figure 7, Sender sends message to hub and hub publish messages directly to subscribed receivers.
XI does not support this scenario in this dynamic form, so called Publish and Subscribe. XI does support the static subscription (Hub and Spoke scenario) by registration the receivers manually in the Integration Directory. So XI can monitor the message flow from adapter to adapter (and anything in between). But if needed, you have the possibility to write you own adapter or use an XI proxy to support the Publish and Subscribe scenario.
Caching Scenario
In this scenario the sender publishes a message into the hub that stores the data in a cache. Any receiving or target application may call the hub to get data of the publish message, at any time. The sender can refresh this data. This scenario is mostly used in scenario’s where many receivers ask for the same information and / or when then the generation of the Sender messages takes a lot of system performance. This scenario is not standard supported by XI, but can be implemented quite easily using BPM or local XI database.
Figure 8, Caching Scenario, sender puts data into the cache
Figure 9, Caching Scenario, a synchronous receiver call receives data out of the SAP XI cache.
Reverse Caching Scenario
In this scenario, the receiving application will also call the hub for cached data. When this is available (and actual) the hub will send back the data directly, but if not, the hub will ask the source application to provide the (refreshed) data to the hub. This scenario is not standard supported in XI but again can be easily implemented using BPM or Shared Memory.
Figure 10 Reverse Caching Scenario
Coming next in the D-XIE soap:
Design decisions for synchronous or asynchronous messaging. Meet you next time in the D-XIE soap … Thanks to all D-XIE members, especial Hans GM and Alwin v.d. Put for helping me writing this weblog.
1 Comment
