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:
- Asynchronous outbound request interface from the Sender side
- Asynchronous inbound response interface from the Receiver side
- Synchronous inbound interface to the Receiver
- 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)
- For Operations Mapping, only the request message type needs to be mapped
- 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) :
- The sender communication channel must be an asynchronous sender. In this example, it is an asynchronous SOAP sender communication channel.
- 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.
Thanks William to share the information.
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:
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. 😉
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?
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?
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.!
Thanks Bill, for awesome blog.
Thanks for sharing. I tried this out and found that it works pretty well. However, I have a couple of questions:
Thanks so much in advance for your help.
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.
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?
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.
That's a clever little hack. Thanks for that, it works great.
just to let you know this config does not seem to work with http_aae
if soap, rfc it's working,
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.
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.
n.ConfigException: No sender agreement configured that matches the messages header fields (sender party: "", sender service:
Can any body help on my above issue.
I think its not working with HTTP_AAE adapter. Please let me know if there is any alternative to achieve this.
Hi, Michal. Do you know, why ResponseOnewayBean still doesn`t work with REST adapter?
apply patch it should work for rest
2212660 - Async/Sync Bridge with REST receiver channel is failing
Have one basic doubt... not getting why virtual receiver should be selected for second ICO?
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.
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.
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.
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.
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.
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.
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:
Hope that makes sense...
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,
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.
This should work for PI 7.1 also. For RFC as the sync receiver, please follow the forum discussion above with James Wood.
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?
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?
I have this working using classical configuration without any problem, with RFC as the sync receiver.
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?
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.
We have assigned the virtual receiver in the receiver determination and the sender agreement.
It is impossible to debug when not be able to see the monitor msgs and everything you have done.
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.
It worked for me. Tricking PI felt good. 😀
Did File -> SOAP -> File scenario, using Standard Web Service.
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
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.
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.
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....
Thanks in advance
Any updates on this one?
Did you manage do the bridge with a synchronous store procedure in the receiver side?
No - it does not seem to work with JDBC adapter
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.
Many thanks for your reply but I still don't understand you. Do you mind explain it in more detail?
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?
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?
Many thanks for your quick response.
The response will trigger the creation of ALEAUD IDOCs,
Apreciate your help.
Anyone managed to get this working with http SOAP on AAE?
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.
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 🙂
I'm facing the same issue.
Did you find a solution ?
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.
please see the SAP note# 2609856 ->
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.
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
Yes. It can be done. I've just made the working scenario: IDoc (ARTMAS, IDoc_AAE, Async) -> SOAP (Sync) -> IDoc (SYSTAT, IDoc_AAE, Async).
Can you please share the steps in ESR, ICO.
Created below steps in ESR for (File-SOAP-File)
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?
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.
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.
Thanks in advance and have a nice day.
Did you set "Sender uses virtual receiver" option in second ICo?
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
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.
Even am facing similar issue . Please refer to the attached SAP Note :
2212660 - Async/Sync Bridge with REST receiver channel is failing
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!!
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,
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?
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?
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.
Could any one share knowledge on File to Rfc Synchronous-Single stack interface PO 7.5