Skip to Content
Author's profile photo Former Member

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:

  /wp-content/uploads/2014/01/pic1_374455.png

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):

/wp-content/uploads/2014/01/pic2_374456.png

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.

/wp-content/uploads/2014/01/pic3_374457.png

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.

Assigned Tags

      70 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Harish Mistri
      Harish Mistri

      Thanks William to share the information.

      Author's profile photo Jason Scott
      Jason Scott

      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.  😉

      Author's profile photo Sri S
      Sri S

      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,

      Sri

      Author's profile photo Former Member
      Former Member

      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?

      Thanks,

      Jonathan.

      Author's profile photo Former Member
      Former Member

      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.!

       

      Author's profile photo Agasthuri Doss
      Agasthuri Doss

      Thanks Bill, for awesome blog.

      Cheers

      Agasthuri

      Author's profile photo James Wood
      James Wood

      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,

      James

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

      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.

      Regards,

      William Li

      Author's profile photo James Wood
      James Wood

      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?

      Thanks,

      James

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

      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.

      Regards,

      William Li

      Author's profile photo James Wood
      James Wood

      Hi William,

      That's a clever little hack. Thanks for that, it works great.

      Best Regards,

      James

      Author's profile photo Michal Krawczyk
      Michal Krawczyk

      hi Bill,

      just to let you know this config does not seem to work with http_aae

      if soap, rfc it's working,

      Regards,

      Michal Krawczyk

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

      Hi Michal,

      I did not try HTTP, not sure of the a scenario I can use.  For file and JMS, it is also working.

      Oh, I guess you are talking about the receiver side.  I need to find an HTTP service.

      Regards,

      William

      Author's profile photo Rajiv Kurra
      Rajiv Kurra

      Hi William,

      I am trying Asy/Syn in IDOC to REST , but I am getting the below error, could you please confirm if this works for REST receiver.

      rest11.JPG

      n.ConfigException: No sender agreement configured that matches the messages header fields (sender party: "", sender service:

      Author's profile photo Rajiv Kurra
      Rajiv Kurra

      Hi Group

      Can any body help on my above issue.

      Author's profile photo Former Member
      Former Member

      Hi William

      I think its not working with HTTP_AAE adapter. Please let me know if there is any alternative to achieve this.

      Regards

      sandeep

      Author's profile photo Former Member
      Former Member

      Hi, Michal. Do you know, why ResponseOnewayBean still doesn`t work with REST adapter?

      Best regards,

      Sergey.

      Author's profile photo Former Member
      Former Member
      Author's profile photo Former Member
      Former Member

      Nice one...

      Have one basic doubt... not getting why virtual receiver should be selected for second ICO?

      --Divyesh

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

      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.

      Regards,

      William

      Author's profile photo Katan Patel
      Katan Patel

      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.

      Thanks,

      Katan

      Author's profile photo Katan Patel
      Katan Patel

      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.   

      Author's profile photo Former Member
      Former Member

      Hi, Katan

      How do you implement the ICO for fault messages returned from the sync web service? I am stuck on this. Which blog from William are you referring to? Please share the link.

      Thanks,

      Jonathan.

      Author's profile photo Katan Patel
      Katan Patel

      Hi Jonathon,

      Sorry I can't find the blog that I referred too any more. 😳

      Check out steps 7-11 on SAP help here for the settings regarding fault handling.

      http://help.sap.com/saphelp_nw73ehp1/helpdata/en/45/20cc5dc2180733e10000000a155369/content.htm?frameset=/en/45/20c210c20a0732e10000000a155369/frameset.htm&current_toc=/en/45/0ea2de423c2d6be10000000a11466f/plain.htm&node_id=9

      Ultimately you need an ICO configured to handle the fault message that came back from your sync service as an async service call.

      My issue was that the sync service I was invoking, actually could return one of three different faults messages, but you can only configure one here.  To circumvent this I did the following:

      1. Developed a Java Map I used to map the fault messages of different types to a single message type so that I could handle easily handle them in my target system . 
      2. Removed the SC name from my ICO, so no validations occurred on the message, or it would fail process and never get to my mapping. (Williams blog off memory was related to the error message I got, prior to removing this setting)

      Hope that makes sense...

      Cheers,

      Katan


      Author's profile photo Former Member
      Former Member

      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

      Author's profile photo Former Member
      Former Member

      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.

      Thanks,

      Diptee

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

      Hi,

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

      Regards,

      William

      Author's profile photo Former Member
      Former Member

      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?

      Thanks

      Diptee

      Author's profile photo Former Member
      Former Member

      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?

      Thanks

      Dipee

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

      Hi Dipee,

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

      Regards,

      William

      Author's profile photo Former Member
      Former Member

      Hello William,

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

      Message processing failed. Cause: com.sap.engine.interfaces.messaging.api.exception.ConfigException: No sender agreement configured that matches the message's header fields (sender party: "", sender service: "ABCD", interface: "http://123.com/abcd/account/ 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

      Thanks,

      Diptee

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

      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.

      Regards,

      William

      Author's profile photo Former Member
      Former Member

      Hello William,

      We have assigned the virtual receiver in the receiver determination and the sender agreement.

      Receiver Determination.PNG

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

      Hi,

      It is impossible to debug when not be able to see the monitor msgs and everything you have done.

      Sorry,

      William

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

      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.

      Author's profile photo Ankit Mishra
      Ankit Mishra

      It worked for me. Tricking PI felt good. 😀
      Did File -> SOAP -> File scenario, using Standard Web Service.

      Author's profile photo Former Member
      Former Member

      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

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

      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.

      Regards,

      Boill

      Author's profile photo Former Member
      Former Member

      Hi William

      Thanks.

      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

      com.sap.engine.interfaces.messaging.api.exception.RetryControlException:

      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

      Author's profile photo Former Member
      Former Member

      Hi William

      Any updates on this one?

      Thanks

      Ziv Shachar

      Author's profile photo Former Member
      Former Member

      Hi Shachar,

      Did you manage do the bridge with a synchronous store procedure in the receiver side?

      Many thanks,

      Phileas.

      Author's profile photo Former Member
      Former Member

      No - it does not seem to work with JDBC adapter

      Author's profile photo Former Member
      Former Member

      Hi,

      Yes you need to define a dummy response interface. Which means your response message looks for a sender interface which has a receiver name = original sender service interface.

      And after it passes this check, your module paramters come in and divert it into the bridge.

      Thanks

      Mithun

      Author's profile photo Former Member
      Former Member

      Hi Mithun,

      Many thanks for your reply but I still don't understand you. Do you mind explain it in more detail?

      Many thanks.

      Author's profile photo Former Member
      Former Member

      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,

      Phileas.

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

      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?

      Regards,

      William

      Author's profile photo Former Member
      Former Member

      Hi William,

      Many thanks for your quick response.

      The response will trigger the creation of ALEAUD IDOCs,

      Apreciate your help.

      Regards,

      Phileas.

      Author's profile photo Conal Berry
      Conal Berry

      Anyone managed to get this working with http SOAP on AAE?

      Author's profile photo Former Member
      Former Member

      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.

      Thanks

      Mithun

      Author's profile photo Former Member
      Former Member

      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_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.engine.services.ts.exceptions.BaseIllegalStateException: (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 🙂

      Giuseppe

      Author's profile photo Hans Hougaard
      Hans Hougaard

      I'm facing the same issue.

      Did you find a solution ?

      Author's profile photo Former Member
      Former Member

      Hello Giuseppe, hello William Li,

      I am facing the exact same error as Giuseppe Sinatra and Hans Hougaard.

      Is there any solution meanwhile?

      Response from HTTP_AAE Channel Is received successfully and all channels are green.

      But because of the Error the request is sent several times again and again...

      I would really appreciate your hints and help.

      Thank you in advance.

      Author's profile photo Sugata Bagchi Majumder
      Sugata Bagchi Majumder

      please see the SAP note# 2609856 ->

      https://launchpad.support.sap.com/#/notes/ 2609856

      Author's profile photo Former Member
      Former Member

      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.

      Manish

      Author's profile photo Former Member
      Former Member

      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

      Ravijeet

      Author's profile photo Evgeniy Kolmakov
      Evgeniy Kolmakov

      Hi!

      Yes. It can be done. I've just made the working scenario: IDoc (ARTMAS, IDoc_AAE, Async) -> SOAP (Sync) -> IDoc (SYSTAT, IDoc_AAE, Async).

      Author's profile photo ashok kyama
      ashok kyama

      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)

      Author's profile photo Former Member
      Former Member

      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?

      Author's profile photo Haribabu Bandaru
      Haribabu Bandaru

      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.

      Author's profile photo Lakshman konduru
      Lakshman konduru

      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 com.sap.engine.interfaces.messaging.api.exception.ConfigException: 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.

      -Lakshman    

      Author's profile photo Evgeniy Kolmakov
      Evgeniy Kolmakov

      Hi Lakshman!

      Did you set "Sender uses virtual receiver" option in second ICo?

      Author's profile photo Himadri Chakraborty
      Himadri Chakraborty

      This is not working for WS_AAE too .. .

      I posted a question related to this in the forum —  https://answers.sap.com/questions/77354/soap-12-with-ws-security-and-ws-addressing-with-sy.html

      Thanks,
      Himadri

       

      Author's profile photo Vinay Kumar
      Vinay Kumar

      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: com.sap.engine.interfaces.messaging.api.exception.ConfigException:
      No sender agreement configured that matches the messages header fields
      (sender party: "", sender service: "REST_XXX", interface: "http://XXXX.com 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.

      Thanks
      Vinay

      Author's profile photo Younus Mohammed
      Younus Mohammed

      Vinay ,

      Even am facing similar issue . Please refer to the attached SAP Note :

      2212660 - Async/Sync Bridge with REST receiver channel is failing

      Author's profile photo Vinay Kumar
      Vinay Kumar

      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!!

      Thanks
      Vinay

      Author's profile photo Former Member
      Former Member

      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,
      Rajesh

      Author's profile photo Former Member
      Former Member

      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.

       

      Regards,

      Madina

      Author's profile photo Nimrod Gisis
      Nimrod Gisis

      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?

      Author's profile photo Praveen kumar Pokuri
      Praveen kumar Pokuri

      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.

      Thanks,

      Praveen kumar

      Author's profile photo Dileep Reddy
      Dileep Reddy

      Hi sir,

      Could any one share knowledge on File to Rfc Synchronous-Single stack interface PO 7.5

       

      Thanks&Regards

      Dileep