Skip to Content
Technical Articles
Author's profile photo Leona Niro

Sync/Async Bridge Using Only One (1) ICO


Most of the sync/async implementations using the adapter modules that you can find are using two ICOs. One ICO will send request to the intended receiver system and at the same time writes a file with the message id as the filename to be used for correlation. Another ICO will pick up the file and use the filename as correlation id to match the response to the request message and send the response back to the sender system. The response time will depend on the polling interval value that you use in the file sender adapter of the second ICO. It would be helpful for you to read some examples below:


In this blog you will learn to use just one ICO and that the response message will instantly go back to the sender system using only standard adapter modules.


How it works?

  • The scenario will use three (3) adapters
    • Sender SOAP adapter – will send the request message
    • Receiver IDoc adapter – will send the idoc to ECC
    • Receiver file adapter – will notify the sender and return the response message
  • Two mappings will be used
    • Transform request to idoc format
    • Transform request to response
  • SOAP adapter will send the request to two receivers
    • The first receiver will use a mapping to transform the request message to idoc format and then the idoc receiver adapter will send it to ECC.
    • The second receiver will use a mapping to transform the request to a response message and will use the file receiver adapter to notify the sender and will also send the response back to the sender



Create Data Types and import the IDoc:

  • DT_Request
  • DT Response – similar to request but it has an extra Message segment
  • WMTOCO.WMTCID01 – standard Transfer Order confirmation idoc
  • Create message types and service interfaces for the request and response types

Create Message and Operation mappings

  • Message mapping – request to idoc
  • Message mapping – request to response mapping is basically one-to-one and below table define the mappings for fields under Message segment
  • Create operation mapping for each message mappings.

Create the three (3) adapters

  • SOAP Sender
  • Important information about the module configuration of AF_Modules/DynamicConfigurationBean
  • File Receiver
  • IDoc Receiver – usual idoc receiver

Create the ICO


  • We will only use SOAP UI to test it
  • Dynamic Configuration – the read operation retrieve the message from the header and write it in the dynamic configuration
  • PI message header – the write operation retrieve the message id from the dynamic configuration and write it in the header as conversation id (correlation id)
  • Verify the IDoc in ECC

It is plain and simple but it would really help to improve performance as it send the response back without the need for second ICO and the response time is instant. Give it a try!



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Akhil Kumar
      Akhil Kumar

      Very well articulated.  Thanks

      Author's profile photo Arnaud CAMELIERE
      Arnaud CAMELIERE

      Hello, nice solution 🙂

      I have a question, does it work if the IDOC part is in 0..unbounded ?

      Thx in advance,


      Author's profile photo Leona Niro
      Leona Niro
      Blog Post Author

      Yes it will work as the adapters modules that handles the synch/asyc bridge have nothing to do with the mapping you will define for idoc with 0..unbounded cardinality. As long as you correctly defined your mapping then it should be good. 🙂

      Author's profile photo Abhishek Roy
      Abhishek Roy


      What happens if there is an error in IDOC processing?In that case response will come or not?

      Author's profile photo Evgeniy Kolmakov
      Evgeniy Kolmakov


      As I could see from above screenshots, you'll get response regardless to IDoc processing status.

      You could also use one receiver with two interfaces and set "Maintain Order at Runtime" option in interface determination. In this case second operation mapping (response to sender) will be called only if the first message is processed successfully. Otherwise you'll get timeout error.

      Regards, Evgeniy.

      Author's profile photo Abhishek Roy
      Abhishek Roy

      Hi Evgeniy,

      Thanks for clarification.Indeed we will get response irrespective of IDOC processing status.

      I have checked "Maintain order at runtime " based on your suggestion to overcome the issue.