Skip to Content
Author's profile photo Former Member

Bridges Construction Site (3/3): SAP PI bridges – “exotic” and recommendations.

Previous posts:

Bridges Construction Site (1/3): Asynchronous – synchronous bridge.

Bridges Construction Site (2/3): Synchronous – asynchronous bridge.



Hello again, colleagues!

Let’s finish to review solutions for the problem of integration in heterogeneous interfaces landscape using SAP PI bridges.


4. Using System Acknowledgement in Async-Sync bridges (from PI version 7.3).

Starting from version SAP PI 7.3  a couple of new modules were added to the bridges construction pool – for sending a technical delivery confirmation to the initial system. The fact is that in “normal”(not bridges) interfaces, communication channel returns technical confirmation message automatically if initial system requested a technical confirmation. This confirmation called System Acknowledgement.

In the case of asynchronous-synchronous bridge,an automatic sending of such confirmation does not work.

To send this confirmation in SAP PI 7.3 you need to use following modules:

  • SendAckBean – used to send system acknowledgement to the initial system. This module must be the last in the chain of modules. You must also use CloneMessageBean.
  • CloneMessageBean – used to replace the original message with a copy. All further chain modules will work with a copy, leaving the original message intact. This module must be used only with SendAckBean in context of asynchronous-synchronous bridge.

So first module will save the initial message intact (technical header is the most important), second module will use this saved message to create a System Acknowledgement.

For using these modules in the Communication Channel you should go to the tab «Module» and enter the following values:

Module name Type Module key
AF_Modules/CloneMessageBean Local Enterprise Bean key1
….. Local Enterprise Bean all other modules
AF_Modules/SendAckBean Local Enterprise Bean key2

«Module Key» can be anything. These modules do not have any settings.

5. Async-Sync bridge via mapping lookup.

I would also like to mention the possibility to create an asynchronous-synchronous bridge via mapping look-up functionality.

It is not “real” bridge, but it’s really looks like it. 🙂

Diagram of look-up bridge:



  • Convenient for a small amount of data.
  • Starting with SAP PI 7.1 RFC and JDBC lookups included into standard mapping functions of Message Mapping editor and do not require knowledge of Java.


  • Requires knowledge of Java (for RFC and JDBC in PI versions up to 7.0, and for any PI version if you need other adapters)
  • Performance strongly depends on the volume data.
  • Mixing message mapping and transport / routing in one Message Mapping object.
  • Since you using Java, it is a custom development.

I must mention again that the main purpose of lookups is to obtain additional data from the external system in the process of mapping messages. Lookup was not developed for bridges initially.

You need to create following objects to build a bridge:/wp-content/uploads/2014/07/bridge23_502590.jpg

Configured RFC Lookup in the mapping looks like this:


You need to configure a standard asynchronous interface with all communication channels and routing rules in the Integration Directory. Additionally, you need to create one more communication channel (which will be used for RFC-lookup call) and use this communication channel in the Interface Determination settings.

If everything is configured correctly, then RFC-call will be executed during the mapping and results will be seen in the target message.

More details about the look-up can be found here:

Usage of SOAP Lookup and RFC Lookup in a Single Mapping Program

Adding Lookups to Mapping Programs

6. Recommendations for choosing a bridge variant.

So, what kind a bridge to choose for your special interface? This question is very creative, but I’ll try to give some recommendations:

  • At first, let’s look at the interface and try to understand – is it possible to go without the bridge? Yes, it’s the main question. It might be easier to change the logic of one of connected systems before start of using modules and increasing the complexity of the interface.

       This is one of the “golden” rules for working with PI: the simpler interface working faster and more reliable.

  • Look at the source system and understand the type of bridge: asynchronous-synchronous or  synchronous-asynchronous.
  • Choose the “main” communication channel to build a bridge. In general – it is preferable to use receiver communication channel. In this variant, the message is processed in the PI in normal mode and changes its properties in one place only  – just before the adapter for the target system. But it can be not possible in some situations – for example, the communication channel configured already and it is used in conjunction with multiple interfaces. Or there is no way to add the necessary modules to the adapter (safety rules, adapter loaded with tons of modules already, etc). In such circumstances, use Sender Communication channel for all bridge modules.
  • Check the amount and complexity of information passing through the asynchronous-synchronous bridge. If you need to get values of one or two fields from ERP, database or web-service – use mapping lookup. If you need more complex information – you need a full bridge.
  • Do we need a mapping? If yes – one side or both sides? Then check the possibility to use this kind of mapping in the selected bridge variant.

And the main recommendation – no fear and go experimenting, you will get what you need! 😎

7. Additional information.

Official information about bridges with modules on (SAP Netweaver 7.4):
Configuring Async/Sync and Sync/Async Bridge in the JMS Adapter

Step-by-step instruction and example from SAP Official on SDN:
«Async/Sync and Sync/Async Bridge Scenarios Configuring Async/Sync Bridge and Sync/Async Bridge
without BPM»


So, this is all that I have about bridges now.  I hope these posts will help you to build best integration in SAP world.

Links to previous posts:

Bridges Construction Site (1/3): Asynchronous – synchronous bridge.

Bridges Construction Site (2/3): Synchronous – asynchronous bridge.

With best regards,

Alexey Petrov

Freelance Integration Expert

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Carlos Andres Gonzalez
      Carlos Andres Gonzalez

      Hello Alexei,

      Excellent work.  If I have a SOAP to IDOC_AAE (PO 7.4) scenario... I can use SendAckBean in IDOC_AAE Receiver cannel ?   This integration is an Activity inside a new BPM model

      What is your advice about this?  Thank u for your attention.


      Carlos Andres.

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Carlos,

      thanks. 🙂

      Regarding the SendAckBean in SOAP-IDoc.. it seems that SOAP adapter will send system ack automatically - you don't need to use the module.

      From help:

      "If the sender has requested a system acknowledgement, normally a sender (receiver) adapter channel triggers the ack (acknowledgement). In case of Async-Sync ..."

      So you need this module only in Async-Sync bridge.

      If you speaking about application acknowledgement - that's another story, because IDoc use ALEAUD for this and you can't just send it back to the sender directly.

      There were a lot of topics and posts on SDN about it, for example How to Handle Acknowledgments for IDoc (NW7.0)

      Hope this will help you.

      With best regards,


      Author's profile photo Carlos Andres Gonzalez
      Carlos Andres Gonzalez

      Hello Alexey, thank u for your response.

      If I use SOAP to IDOC from soapUI and put AF_Modules/RequestOnewayBean in my sender SOAP cannel, all works fine (asynchronous).  But when I use the same from BPM, the BPM remains waiting for a kind of response.

      I will read the document about handle akcnowledgments and will tell you the results on my scenario.

      Thanks again, regards

      Carlos Andres.