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:
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 log for CC_FILE_SND and CC_RFC_ER1_RCV:
Message log for CC_FILE_RCV:
Thanks for viewing. Give comment if you see something is not correct on my setup above. Thanks.