In today's blog we want to take a look at how to implement a loopback interface on the SAP PI / PO. Before we start with the implementation, let's take a look at what distinguishes a loopback interface and what its uses are.
By a loopback interface I mean an interface that does not have a receiver system, but instead transmits the sent (and optionally transformed) message back to the sender.
In the past I've seen only solutions which involved a receiver system with a small dummy server, that responded with the request sent to it. In opposite to this, our loopback interface will work without any receiver system and thus keep its footprint as small as possible.
I basically see two uses for a loopback interface:
If you recognize more / other use cases, please write a comment below this blog.
First let us setup Enterprise Service Repository (ESR) content: Data- and message types, service interfaces and message- and operation mapping.
At first let's create the request and response data types. For our example we build two minimalistic datatypes with just one string field.
Next create two message types and connect them with the data types created right before.
Now we can create the Service Interfaces. Since we expect a result from our loopback interface, we will create them as "synchronous" interfaces.
Attention: For the outbound interface we use our request message type as request and the response message type as response. For the inbound interface we use the response message type as request and response! (That's because we just want to return the message after we mapped it once.)
In the next step, we will create the Operation Mapping as also the Message Mapping. Use the Service Interfaces created one step before to define the Operation Mapping. Then add a new Message Mapping as "Request Mapping".
For the Message Mapping, we implement a small "Hello X"-logic. It's nothing special but should be enough to show in the later tests, that our interface works.
Save and activate all objects you've newly created. Then open the Integration Builder.
Let's start with the communication channels. Create two SOAP channels - a sender and a receiver one. The sender channel is a regular SOAP sender channel. For now you just have to ensure, that its "Quality of Service" is set to "Best effort" (synchronous mode).
For the receiver channel we play the same game. Just create a standard SOAP receiver channel. Since we have no real receiver system, but have to provide a target url, we enter "http://nowhere.de" as url.
Create a new Integration Configuration now by using the Service Interfaces, Operation Mapping and Communication Channels we created in this tutorial. (Click image to enlarge!)
Save and activate the Integrated Configuration.
Now let's go back to the communication channels. So far we have created an interface, which is not guaranteed to work. Finally, a "receiver system" is still missing in the receiver channel. Or not?
Through the targeted use of various adapter modules, we will teach SAP PI that as soon as a message arrives at the receiver channel, it is immediately sent back to the sender. In principle, we configure a kind of "sync async bridge" (as described here, for example), only that we work without a receiver system. So we are building a "sync nobody bridge".
Let's start with the sender channel. Open the channel object and switch to the "Module" tab. Then add three new module (in the order as shown in the screenshot below).
The modules itself shall be configured as shown in the following table:
The most important point here is the DynamicConfigurationBean, which we use to remember the message id of the incoming message. (We need this in the receiver channel right away.)
Save and activate the sender channel and open the receiver channel. In the receiver channel we will remove the main module of the adapter itself and add two new modules instead.
By removing the channels own module ("sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean") we prevent the channel from running (and trying to send the message to ...nowhere.de).
The modules itself shall be configured as shown in the following table:
As first thing we read back the recorded own message id and set it as correlation id. (Clear text: We claim that the message correlates to itself.) Then the NotifyResponseBean is called. This bean looks for the message matching the correlationId and setting to "waiting" state (via WaitResponseBean). And what does it find? Our request message, we set to waiting state in the sender channel.
That way we created a loopback interface which works fully without any target system/server. A quick test in SoapUI approves the functionality of our interface.
Due to the many pictures, the article looks longer than it actually is. I'm saying it, because to build a loopback interface, all you need is a few simple steps and cleverly used adapter modules. It's not that hard than it may look like.
Finally, I have two questions for you:
I look forward to your comments and a lively discussion. And now - have fun building it!
Table of contents
- What is a loopback interface?
- When to use a loopback interface?
- How to build a loopback interface
- Enterprise Service Repository Objects
- Integration Directory Objects
- Loopback Module configuration (this is where the magic happens!)
- Conclusion
What is a loopback interface?
By a loopback interface I mean an interface that does not have a receiver system, but instead transmits the sent (and optionally transformed) message back to the sender.
In the past I've seen only solutions which involved a receiver system with a small dummy server, that responded with the request sent to it. In opposite to this, our loopback interface will work without any receiver system and thus keep its footprint as small as possible.
When to use a loopback interface?
I basically see two uses for a loopback interface:
- Implementation of a mapping-only service.
If you want to carry out a complicated data transformation and at the same time want to maintain flexibility, you can outsource the mapping to a loopback interface and call it up from your application using a "lookup". - Implementation of a service / monitoring interface.
For example, if you want to provide system parameters such as CPU, hard disk space or database consumption (or whatever you read out using Java mapping / UDF) via an interface as an API.
If you recognize more / other use cases, please write a comment below this blog.
How to build a loopback interface
First let us setup Enterprise Service Repository (ESR) content: Data- and message types, service interfaces and message- and operation mapping.
At first let's create the request and response data types. For our example we build two minimalistic datatypes with just one string field.
Enterprise Service Repository Objects
Next create two message types and connect them with the data types created right before.
Now we can create the Service Interfaces. Since we expect a result from our loopback interface, we will create them as "synchronous" interfaces.
Attention: For the outbound interface we use our request message type as request and the response message type as response. For the inbound interface we use the response message type as request and response! (That's because we just want to return the message after we mapped it once.)
In the next step, we will create the Operation Mapping as also the Message Mapping. Use the Service Interfaces created one step before to define the Operation Mapping. Then add a new Message Mapping as "Request Mapping".
For the Message Mapping, we implement a small "Hello X"-logic. It's nothing special but should be enough to show in the later tests, that our interface works.
Save and activate all objects you've newly created. Then open the Integration Builder.
Integration Directory Objects
Let's start with the communication channels. Create two SOAP channels - a sender and a receiver one. The sender channel is a regular SOAP sender channel. For now you just have to ensure, that its "Quality of Service" is set to "Best effort" (synchronous mode).
For the receiver channel we play the same game. Just create a standard SOAP receiver channel. Since we have no real receiver system, but have to provide a target url, we enter "http://nowhere.de" as url.
Create a new Integration Configuration now by using the Service Interfaces, Operation Mapping and Communication Channels we created in this tutorial. (Click image to enlarge!)
Save and activate the Integrated Configuration.
Loopback Module configuration
Now let's go back to the communication channels. So far we have created an interface, which is not guaranteed to work. Finally, a "receiver system" is still missing in the receiver channel. Or not?
Through the targeted use of various adapter modules, we will teach SAP PI that as soon as a message arrives at the receiver channel, it is immediately sent back to the sender. In principle, we configure a kind of "sync async bridge" (as described here, for example), only that we work without a receiver system. So we are building a "sync nobody bridge".
Let's start with the sender channel. Open the channel object and switch to the "Module" tab. Then add three new module (in the order as shown in the screenshot below).
- AF_Modules/RequestOnewayBean
- AF_Modules/DynamicConfigurationBean
- AF_Modules/WaitResponseBean
The modules itself shall be configured as shown in the following table:
| Module Key | Parameter Name | Parameter Value |
| dynConf | key.0 | read http://sap.com/xi/XI/System/Messaging messageId |
| dynConf | value.0 | message.messageId |
| rob | passThrough | true |
| wrb | timeout | 30000 |
The most important point here is the DynamicConfigurationBean, which we use to remember the message id of the incoming message. (We need this in the receiver channel right away.)
Save and activate the sender channel and open the receiver channel. In the receiver channel we will remove the main module of the adapter itself and add two new modules instead.
- AF_Modules/DynamicConfigurationBean
- AF_Modules/NotifyResponseBean
By removing the channels own module ("sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean") we prevent the channel from running (and trying to send the message to ...nowhere.de).
The modules itself shall be configured as shown in the following table:
| Module Key | Parameter Name | Parameter Value |
| dynConf | key.1 | write http://sap.com/xi/XI/System/Messaging messageId |
| dynConf | value.1 | message.correlationId |
| nrb | timeout | 30000 |
As first thing we read back the recorded own message id and set it as correlation id. (Clear text: We claim that the message correlates to itself.) Then the NotifyResponseBean is called. This bean looks for the message matching the correlationId and setting to "waiting" state (via WaitResponseBean). And what does it find? Our request message, we set to waiting state in the sender channel.
That way we created a loopback interface which works fully without any target system/server. A quick test in SoapUI approves the functionality of our interface.
Conclusion
Due to the many pictures, the article looks longer than it actually is. I'm saying it, because to build a loopback interface, all you need is a few simple steps and cleverly used adapter modules. It's not that hard than it may look like.
Finally, I have two questions for you:
- Have you already built a loopback interface? (And if so, how did you implement it?)
- What uses do you see for loopback interfaces? (Or do you think it's completely unnecessary?)
I look forward to your comments and a lively discussion. And now - have fun building it!
- SAP Managed Tags:
22 Comments
