Skip to Content

Generic PI Async-Sync Bridge Configuration for Any Adapters

PI provides async-sync bridge for the JMS adapter.  The configuration is well documented in SAP Help and various blogs and documents on SCN. The configuration involves JMS specific parameters, e.g. JMS correlation id.  These parameters are not valid or available for other types of adapters that can process asynchronous messages, e.g. File, JDBC, Mail, IDoc.

In this blog, we will take a look at another configuration option that can use the async-sync bridge, but without any JMS-type of dependencies.  The configuration is generic; therefore, we can use any asynchronous communication channels without any other changes.  This means for JMS, we will not have to deal with all the special JMS async-sync bridge configurations; you will only need to configure JMS communication channel as a “normal” configuration.

Below denotes the basic integration flows:


The following interfaces are needed:

  1. Asynchronous outbound request interface from the Sender side
  2. Asynchronous inbound response interface from the Receiver side
  3. Synchronous inbound interface to the Receiver
  4. Asynchronous outbound response interface from the Receiver  (this interface should be based on the response message of the synchronous interface in #3)

The following Integrated Configurations (or iFlows) are needed:

  • Asynchronous outbound request interface (#1) –> Synchronous inbound interface (#3)
    1. For Operations Mapping, only the request message type needs to be mapped
    2. The synchronous Receiver Communication Channel needs to have the following module configurations added (example of a SOAP web service):


Please note the processing sequence.  They must be in the order as above.  The 2 additional modules are:

      • AF_Modules/RequestResponseBean  (Module Key: RequestResponseBean)
      • AF_Modules/ResponseOnewayBean  (Module Key: ResponseOnewayBean module)
      • The Module Key can be any name you want.  Here is just an example.

The Module Key’s Parameter Names and Values are:

      • RequestResponseBean:  passThrough = true
      • ResponseOnewayBean module:  interface = interface name for #4 above
      • ResponseOnewayBean module:  interfaceNamespace = interface namespace for #4 above
      • ResponseOnewayBean module:  replaceInterface = true

Note:  The rest of the configurations are the same as the standard configurations.

  • Asynchronous outbound response interface of the receiver (#4) –> Asynchronous inbound response interface (#2) :
    1. The sender communication channel must be an asynchronous sender.  In this example, it is an asynchronous SOAP sender communication channel.
    2. When creating the ICO (or iFlow), you must specify a receiver.  The receiver is the business system/component to receive the response.


Note:  All other configurations are the same as the standard configurations.

For my testing, I used (on the sender side) a File sender communication channel and a File receiver communication channel.  Then I replace the File communication channels with JMS communication channels. Everything worked just as well without making any other changes.

You must be Logged on to comment or reply to a post.
  • Hi William, we've actually been using this method for quite some time. Its worked for ages even though the documentation only mentioned it with reference to the JMS adapter.

    Something to note is that if your sync service can respond with soap-faults then you have to configure "another" iflow to handle that separately as well.

    So you would have 3 iflows:

    1. Main iflow to async send you data from sender to sync receiver
    2. Reponse iflow to receive response data
    3. SoapFault iflow to receive any soap faults.

    Iflows 2 and 3 are mandatory which is a shame as it would be good to not have them if you did not want the response data. iflow 3 is only mandatory if your service can ever generate soap faults.

    I just wish SAP would make this all more transparent. It should be just a couple of checkboxes on each channel to enable async/sync bridging so that you don't need this mess of Iflows.  😉

    • Hi Jason,

      I ran into similar case where I need to handle my synchronous response from the receiving system has fault messages too(response or fault).When I try to follow this approach I have no option of getting the fault message structure from #3 to #4 interface in the above steps explained as outbound Asynchronous messages cannot take fault message type like inbound interfaces Asynchronous.

      can you please let me know,how this has been implemented in your case? any thoughts please?

      thank you,


    • Hi, Jason

      I haven't found a way to implement the iflow number 3 you mentioned to capture the fault message returned from the sync web service. Can you share some screenshots?



    • Hi Jason


      I have a scenario where a sender JDBC adapter is going to call SOAP webservice to create/update/delete user and receive SOAP response data that is to be fed in the same table synchronously using JDBC receiver adapter


      any help is appreciated.!


  • Hi Bill,

    Thanks for sharing. I tried this out and found that it works pretty well. However, I have a couple of questions:

    1. In the screenshot you have for the integrated configuration in the second leg of the exchange, I see that you have the asynchronous placeholder interface as the sender interface. When I tried this on a PI 7.1 and 7.3 system, I found that the AAE could not resolve the response from the synchronous request (I called a BAPI via the RFC adapter) unless I proposed the synchronous interface as the sender. This approach is consistent with this document: Async/Sync and Sync/Async Bridge Scenarios: Configuring Async/Sync Bridge and Sync/Async Bridge without BPM. Am I missing something here?
    2. Based on #1, I feel like there might be a gap in the way that response messages are processed. If I propose the synchronous interface as the sender, then the Integration Builder tool is unable to find an operation mapping to transform the response payload from the synchronous service into a schema type that can be accepted from the host.

    Thanks so much in advance for your help.

    Best Regards,


    • Hi James,

      I tried an RFC also, and encountered the same error.  I think it has to do with the RFC adapter, since other adapters did not experience the same problem.  However, I did find a work-around.  For the 2nd iFlow, I used the synchronous RFC inbound interface as the outbound interface when creating the iFlow.  Of course, this does not make much sense, and you actually have to manually enter the inbound interface as the outbound during the create.

      When I looked at the error, it was looking for a sender agreement with the RFC inbound interface, so that is reason I tried it.


      William Li

      • Hi William,

        Thanks so much for taking the time to respond to this. A follow-up question if I may. So if you use the synchronous RFC inbound interface as the outbound interface on the 2nd iFlow, is there a way to introduce an operation mapping into the scenario? Here, I basically need to transform the response payload from the RFC into a different schema type before I send it back to the sender. In the prototype I created, I couldn't come up with a way to do this.

        If you try and define the operation mapping in terms of the synchronous RFC interface, then it looks for mappings based on the request message of the RFC, not the response. I also tried to model the operation mapping in terms of the 'placebo' interface pointed to by the adapter modules. In either case, the Integrated Configuration tool couldn't locate an operation mapping. And, unfortunately, I'm not aware of a mechanism for forcefully injecting an operation mapping in this case (which I think might work if we could get it into the cache).

        Short of a mapping workaround, I'm thinking that I might have to land the response somewhere (e.g. a JMS queue) and then spawn another iFlow to pick up the response, transform it, and then send it on to the original sender. What do you think?



        • Hi James:

          Yes, this can be done.  You will have to trick PI.

          1.  In Oper Mapping, assign source to the RFC sync inbound and target to the async inbound interface you want.

          2.  During the assignment of mapping, you should only see the request mapping assignment because the target is async.  When selecting the mapping to use, for the source message, click on the assigned/default msg type and changed it to -Any-.  You should now see all the mappings to the target msg type.  Select the one you want.

          3.  At this point, if you activate the Oper Mapping, you will get an error indicating that the source and target interfaces do not match.  You will not be able to activate it.

          4.  Go to the aysnc inbound interface used in #1.  Change it to sync interface and assign any msg type to the response; you can just use the same as the request msg type.  Activate it by itself, do not include any other artifacts to be activated.

          5.  Now, activate the Oper Mapping.  Do not make any changes to it.  You will get a warning, but it will activate.

          6.  Go to iFlow or Integration Directory and assign the Oper Mapping.

          Hope this works for you.


          William Li

    • In a "normal" configuration, the receiver is determined during runtime.  But, in this case, with sync interface, the sync response must know the receiver ahead of time.  The virtual receiver is how the sync interface can know where to send the response.



  • Hi Guys,

    I have setup an interface similar to scenario 1. 

    I have an outbound proxy -> HTTP Axis (synchronous request) -> inbound proxy. 

    In my receiver comm channel for the synchronous request, I configured the two beans at the beginning and the end of the module chain respectively and had all my AXIS modules in between. 

    Conf 1.PNG

    Conf 2.PNG

    When testing I find that the sender interface is not replaced and this results in PI not finding the sender agreement for the response asyc interface. I get this error after the call to the ResponseOnewayBean in the logs.

    EXCP 1.PNG

    I am pretty sure this should work with AXIS just like a standard SOAP scenario, but I just can't get these values to change. 

    Any help would be hugely appreciated and sorry for hijacking such a great blog.



    • I should point out that I got this issue because my SOAP service call was returning a SOAP fault. I learnt this using the XPI Inspector tool (which is invaluable when working with AXIS) and then updated the config to handle this. Incidentally if your service call returns multiple fault message types.  You can only configure for one ICO to handle the fault in the Response One Way Bean.  To get around this you can however remove the SC in the sender agreement of the ICO for the Fault Message (as I discovered in one of Williams other blogs). This stops PI from performing a schema vaildation of the message and allows the message to proceed to the operation mapping, where I could handle the multiple fault message types in a Java Mapping.   

    • Hi Katan,

      I am getting same issue when i configure the modules in receiver adapter Could you please let me know how you resolved the issue .It will help if you can respond ASAP.

      Thanks and Regards,
      Rajesh Naidu

  • Hello William,

    We are facing the same issue as Katan; however we are on PI7.1 and are using the configuration in your blog for an Idoc to SOAP scenario.

    Please confirm if the config in the blog would work in PI 7.1 for our scenario.



    • Hi,

      This should work for PI 7.1 also.  For RFC as the sync receiver, please follow the forum discussion above with James Wood.



      • hello William,

        I tried the same already to no avail, we still have the same error. Also we have a idoc to SOAP to idoc scenario hence we are unable to use an ICO, should this add any constraints?



      • Hello William,

        The config works only with an ICO and not with classical configuration. When I recreated the second leg of the scenario with a dummy ICO it worked fine. Any idea why this doesn't work with classical config?



        • Hi Dipee,

          I have this working using classical configuration without any problem, with RFC as the sync receiver.



          • Hello William,

            We tried using RFC sync receiver too, but we are still facing the sender agreement not found error.

            Message processing failed. Cause: No sender agreement configured that matches the message's header fields (sender party: "", sender service: "ABCD", interface: " SI_IS_WS", receiver party: "", receiver service: "HIJK")

            Also below are the details of our PI system config, could these be an issue?

            Sys details.PNG



            Sys details.PNG
          • Don't know what you are doing wrong.  I have no problem with my async-sync scenario using the RFC or web service as receiver.  I've used ICO and classical configurations without problem.

            Sounds like you did not assign a virtual receiver to your Receiver Determination for the response.



          • /
            Receiver Determination.PNG
  • Using RFC as sync receiver.

    There has been a few questions and, possibly, confusions on using RFC as the receiver.

    Using the scenario above, when using RFC, the #3 and #4 interfaces will both use the imported RFC.

    In the Operations Mapping from #4 to #2, you must override the request mapping with the response mapping.  The steps are described in the discussion above and listed here again:

    1.  In Oper Mapping, assign source to the RFC interface and target to the async inbound interface you want.

    2.  During the assignment of mapping, you should only see the request mapping assignment because the target is async.  When selecting the mapping to use, for the source message (which is RFC), click on the assigned/default msg type and changed it to -Any-.  You should now see all the mappings to the target msg type.  Select the response mapping you want.

    3.  At this point, if you activate the Oper Mapping, you will get warning indicating that the source and target interfaces do not match.  But, it will still activate.

    4. Go to iFlow or Integration Directory and assign the Oper Mapping.

    Also, do not forget to use the RFC interface and namespace in the Module processing configuration of the RFC receiver comm chan.

  • Hi William

    Reharding the bridge - if the massage is failed due to system not available, password in jdbc adapter not correct.... does the messages left in the queue of the sender interface and you can rerun them? or they are fault?

    As we want to retry them after some time if the target system is down and the sync interface failed

    Thanks in advance

    Ziv Shachar

    • Hi,

      Yes, since the sender interface is async, the msg will be queued and can be re-started.

      I actually tried this by using a wrong userid for the RFC comm chan.  The msg went into error with log indicating logon error.  Then, after fixing the userid and resent the msg, the msg was delivered successfully.



      • Hi William


        We have made the scenario for SOAP and it worked perferct

        However for the real scenario we need:

        SAP ECC PROXY SENDER ASYNC- > PI -> JDBC Stored procedure ( SYNC ) -> PI > FILE ASYNC

        We need to use the bridge in the receiver JDBC adapter.

        We have tried to build the scenario and it operates the Stored procedure but fails right afterwards while running the module ResponseOneWayBean.

        Than it fails with the exception :

        exception caught with cause

        Receiver Determination did not find any receivers at all

        This did not happen when we used a soap....

        Please advise

        Thanks in advance

        Ziv Shachar

  • Hi William,

    We would like to use this bridge in a IDOC to SOAP scenario but using 1..N mapping so for each inbound message we are going to call N times the sync soap receiver channel. Should it work as well?

    Many  thanks,


    • Hi Phileas,

      To be honest, I have not tried it.  I don't know if it will work.  Seems it should, since the sender service (IDOC) is async.

      Who will receive the response from the SOAP service?



      • Hi William,

        Many thanks for your quick response.

        The response will trigger the creation of ALEAUD IDOCs,

        Apreciate your help.



  • Hi,

    I have a NWBPM(SOAP-Async)->PO<->Application(AXIS-SYNC-NTLM-DIME Attachement)

    then PO<->Application(AXIS-SYNC-NTLM-DIME Attachement)<->ESB->File.

    It is a Async to Sync bridge and I tried what is explained above and it does not work.

    Does the bridge work with DIME attachments with NTLM/Kerbros authentication in PO 7.4.



  • Hi Guys,

    My scenario is:

    1. File 2 HTTP_AAE (using RequestResponseBean and ResponseOnewayBean)

    2. Bridge Synch/Async (SOAP 2 Mail) to forward back the response from HTTP call

    Everything looks working and I'm able to receive back the response. But the HTTP_AAE is not able to close the loop raising followin error:

    Transmitting the message to endpoint using connection File_ failed, due to: (Failed in component: tc~bl~txmanager~plb, BC-JAS-TRH) Thread is not associated with any transaction context.

    This is strange, because I receive the response successfully and communication channels are all green! But I can see the receiver request message in error form MessagingSystem.

    One more time, all the channels involved are green.

    Do you have any idea??

    Thanks a lot for your answers 🙂


  • Hi William,

    As you mentioned that we have to use RFC inbound synchronous interface (#3) instead of interface #4 in the sender agreement then does it even required to create the interface #4 in ESR?

    Also, if this makes sense then what value need to be put in the interface parameter under RFC receiver communication channel module parameter interface? Is it then #3?

    Please guide me here.

    Thanks in advance for your help.


  • Hi William,

    I am trying to do a IDOC - SAP PI - SOAP ( Sync) then map the SOAP response to a separate IDOC. Can this be achieved by this configuration.

    Thanks in advance


      • Hi Evgeniy,


        Can you please share the steps in ESR, ICO.

        Created below steps in ESR for (File-SOAP-File)

        • 2 data types(file req/resp)
        • webservice
        • 4 service interfaces(Outbound async(1), Inbound sync(3), Outbound async(4), Inbound async(2))
        • 2 message mappings(1: file req to soap req, 2: soap resp to file resp)
        • 2 operational mappings( 1: Outbound async(1) - file req to soap req - Inbound sync(3) , 2: Outbound async(4) - soap resp to file resp - Inbound async(2) )

        Activated in ESR

        Created BC(2 communication channels(one file sender, one soap sync receiver))

        Trying to create ICO, cannot see service interfaces to assign to BC)

  • Hi and thanks for the Blog!

    I got this working but I would like to send the response to a receiver system determined in the receiver tab of the second ICO. This is because I have 40 legacy systems that will use the same integration so I would like to use a common incoming MQ queue but send the response to 40 different queues. The MQ ID from the request message must be set as Correlation ID in the response message.

    Is there a way to do this?

  • Hi William,

    Thanks for the nice blog, It was very helpful.

    I have the following scenario: Please let me know whats the best way to achieve this.

    RFC -> PI -> JDBC , need to see the jdbc receiver response before sending the same file  with different mapping as another interface to the same server.

  • Hi William

    We are in 7.1,we have scenario proxy->SOAP->File. my requirement is that need to store the response in file. so i have configured the scenario as given, but after ResponseOnewayBean we are getting error. We are using SOAP HTTP.

    Information MP: processing local module localejbs/AF_Modules/ResponseOnewayBean  15.03.2016 16:02:30.624 Error MP: exception caught with cause No sender agreement configured that matches the message's header fields.

    Is there any reason that it will not work for SOAP Http.

    Please advice.

    Thanks in advance and have a nice day.


  • This is not working for WS_AAE too .. .

    I posted a question related to this in the forum —



  • I am working on SOAP(Async) ---> REST(SYNC) ---> File(Async) and Interface is failing while calling from the bridge to second interface. Below is the error
    error during processing:
    No sender agreement configured that matches the messages header fields
    (sender party: "", sender service: "REST_XXX", interface: " XXX_REST_ASYNC", receiver party: "", receiver service: "SOAP_XXBC")
    As error show receiver service "SOAP_XXBC" which is incorrect(this is sender service) but REST Sync call treating as receiver service not the service mentioned in the bridge module parameter.

    Appreciate any help or suggestions.


  • Younus,
    We are at version 7.50 SP2 and SAP Note is for below version 7.5 SP000.
    My interface is SOAP(Async)---->REST(Sync)---->FILE(Async).
    It is failing because of receiver service: “SOAP_XXBC (which is coming from SOAP header) is kept in REST response and I am not able to override with FILE Receiver Service(Even I am passing it thru ResponseOnewayBean). Any other way??
    Appreciate any suggestions!!


    • Hello Vinay,

      I am facing the same error in receiver adapter when i configured modules in the receiver SOAP adapter we are on PO 7.5 SP2 we tried to configure Proxy (Async)---SOAP(Sync)-->Proxy (Async) and facing issue when we try to configure the modules in receiver adapter and aslo in sender adapter.Please let me know if your issue has been resolved.I will keep you posted.

      Thanks and Regards,

  • Hi William!


    Does this work for File (Async) -> SOAP (Sync) -> SOAP (Async) scenario? We tried but we are failing...


    Also, can you kindly clarify which Communication Component is being referenced for IFLOW 2?


    Thank you.




  • Hi Guys,

    In my case I have an Async message need to  consume two  Sync web service one after the other (based on return result).

    I have configured a ccBPM and a Async Send step to the SOAP end point (using the requestReponseBean as mentioned in the blog) than using correlation between MessageID an conversationID to link the Sync response.

    This all works well except to the fact that the ResponseOnewayBean module:  interface I return seems like beeing send imidiatly with the mandatory values being filled by the XI and not with the actual reponse from the serivce.

    Does it make sense?

    Any ideas?

  • Hi guys,

    Can anyone post clear end to end of Async-sync scenario for REST->RFC->REST with BPM & without BPM with respective screenshots please.

    Quick Help and Suggestions will be appreciated.


    Praveen kumar