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:

async_sync_2_rwb_cc_file_snd_log1 async_sync_2_rwb_cc_file_snd_log2 async_sync_2_rwb_cc_file_snd_log30


Message log for CC_FILE_RCV:

async_sync_2_rwb_cc_file_rcv_log1 async_sync_2_rwb_cc_file_rcv_log2

Thanks for viewing. Give comment if you see something is not correct on my setup above. Thanks.

ASync/Sync Bridge File-RFC-File using Modules at Receiver Adapter
Tagged on:             

5 thoughts on “ASync/Sync Bridge File-RFC-File using Modules at Receiver Adapter

  • September 15, 2015 at 11:34 pm

    Nice article with screen shots. It really helped me to configure AyncSync bridge. Thanks a lot.

  • December 9, 2015 at 6:14 am

    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.

    • April 27, 2016 at 11:13 am

      Thanks Divya. 🙂


Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.