In previous post Async/Sync bridge is established via modules at sender file adapter. This post will perform Async/Sync bridge via modules at receiver RFC adapter.
The high level overview still the same:
Detailed overview:
Now the modules is configured at receiver RFC communication channel.
Explanation on above flow with focus on CC_RFC_ER1_RCV:
a) First module RequestResponseBean change the message type from asynchronous to synchronous by changing the message header.
c) The ReqRespBean parameter “passThrough” value “true” will pass the message to next module chain, which is RfcAFBean.
d) RFC synchronous call to get RFC response and return to third module ResponseOnewayBean.
f) Module ResponseOnewayBean change the message type from synchronous back to asynchronous.
g) Module ResponseOnewayBean also have parameter “interface” and “interfaceNamespace” and “replaceInterface”. So far tested on RFC receiver adapter, the interface seem is not replaced to “SI_FULLNAME_OUT_ASYNC”. The sender agreement at second scenario still required to use interface “SI_FNAME_LNAME_IN_SYNC”. However end result is working fine, able to translated to target MT and generate output file. See the sender agreement below for workaround solution.
h) Finally, the message go through second OM, mapped to MT_FULLNAME and output to receiver file.
Module configuration at CC_RFC_ER1_RCV:
List of ESR objects:
Imported RFC function module:
List of ID objects:
Enterprise Service Repository Objects:
Operation Mapping (FILE2RFC):
Operation Mapping (RFC2FILE):
For both message mapping and imported RFC is same like previous post. Please refer previous post.
Service Interface (1 of 4) for first OM, Outbound Async from File
Service Interface (2 of 4) for first OM, Inbound Sync to RFC and Sync from RFC
Service Interface (3 of 4) for second OM, Outbound ASync from RFC
Service Interface (4 of 4) for second OM, Inbound Async to File.
Integration Directory Objects:
CS for first scenario from FILE2RFC:
CS for second scenario from RFC2FILE:
ID objects for first scenario from FILE2RFC:
ID objects for second scenario from RFC2FILE:
CC_DUMMY_BRIDGE_FILE_SND is just an empty File adapter, not used. Tried if I deactivate this adapter, still working fine.
Logically the interface should be SI_FULLNAME_OUT_ASYNC, but the module processing will try to find matching “SI_FNAME_LNAME_IN_SYNC” at sender agreement step. As a workaround, I changed to “SI_FNAME_LNAME_IN_SYNC”. Need maintain virtual receiver using original sender from first scenario which is “BC_Sender”, the sender agreement is try to find matching “BC_Sender” and will failed if it is not “BC_Sender”.
Here specify the actual receiver “BC_Receiver”:
Map RFC message to MT_FULLNAME:
Write to output file at CC_FILE_RCV:
Message monitoring:
Message log for CC_FILE_SND and CC_RFC_ER1_RCV:
0
Message log for CC_FILE_RCV:
Thanks for viewing. Give comment if you see something is not correct on my setup above. Thanks.
Nice article with screen shots. It really helped me to configure AyncSync bridge. Thanks a lot.
HI Yeeloonkhoo,
First of all I would like to thank you for writting the below blog
,this is very very useful,I was trying to follow your blog to do my
IDOC to REST Asy/Sync, like you mentioned in your blog for some reason
in REST receiver it was not replacing module Interface parameter name
,as per your blog you mentioned to use Synchronous Interface name (as
used in 1st scenario), but when I am using Synchronous Interfacename
in sender agreeemnt ,in interface determination its not identifying
operation mapping , I thought to take some advise from you on this.
Hi Rajiv,
“but when I am using Synchronous Interfacename in sender agreeemnt ,in interface determination its not identifying operation mapping”
For sender agreement:
So you have same behavior with mine. Recently i tried Async/Sync bridge with Sync REST adapter is not working. This blog from Alexey Pitroff also mentioned Async/Sync bridge with Sync RFC will not work, in stead need use module at sender adapter. See comment under Figure 26 in his blog. http://scn.sap.com/community/pi-and-soa-middleware/blog/2014/03/27/bridges-construction-site-part-13-asynchronous–synchronous-bridge
For Interface determination:
In this 2nd flow for OM_RFC2FILE, i’m using the Sync interface from 1st flow to determine the OM, you should able to achieve similar result using this way. Check your OM again.
http://saprainbow.com/wordpress/wp-content/uploads/2015/07/async_sync_2_id2_interface_determination.jpg
Merry Christmas!! 🙂
Regards,
Yee Loon
Awesome… detail explanation
Thanks Divya. 🙂