Skip to Content

The D-XIE Soap part 2: XI design decisions for synchronous or asynchronous messaging


The Dutch XI Experts, a group of customer XI experts and colleague consultancy companies in the Netherlands have planned to write a series of blogs for the SDN community to share their knowledge.

In all integration scenarios you will have the possibility to exchange messages synchronous or asynchronous. Mostly XI developers choose interfaces based on technical availability and not about specific functional requirements. This blog is all about the matter of synchronous and asynchronous, seen from the point of view of the message, and not from the technique. Let this blog help you to make your own design decisions.


Most important about synchronous interfacing is that the sender is in full control of the process. Therefore, a synchronous receiving interface must provide a business relevant answer, so that the sender can fulfill its task properly.

The message request is arrived in the receiving application, processed, and a response is returned to the sender system. Most BAPI, RFC and web services are synchronous implemented. Commonly, when the sender needs a direct business relevant answer to fulfill a series of other tasks, for instance an on-line application where the logic applies to several different systems that interact somehow to each other. You can think of an online shopping scenario, where the available to promise is to be checked in several warehouses.

Figure 1, Synchronous Business Request with Business Response and technical confirmation


Messages can also be sending using asynchronous interfaces. In this case the message is stored at the receiving application. The business processing will start directly or delayed (perhaps in batch) depending on business needs, but no business relevant response will be send back immediately. That means that the sender simply cannot be in real-time and full control of the process. The sender leaves that to the receiver.

However, the receiving application mostly does respond with a technical answer after receiving and storing the message. Now, we are talking about asynchronous with technical confirmation. Be aware such case, that error handling of a technical confirmation is still the responsibility of sending system. It indicates that somehow the transmission or processing on the receiving side failed in such a way, that the receiver could not pick up the pieces to process it. If the technical acknowledgement does not happen at all, there also might be some reason for the sender to think that something went wrong.

Next error handling of the business processing however is the strict responsibility of the receiving system. Also the quality of information will be a responsibility of the receiving partner. Note that the receiving system already has accepted the message as being Ok. Or otherwise the receiver could inform the sender separately that the message, however received properly, could not be processed. Now, within the rules of sync/async messaging for the returning negative acknowledgement, this leaves the sender of the original message with nothing but taking a new initiative.

Figure 2, Asynchronous Business Request with technical confirmation

Figure 3, Process of asynchronous business request

Figure 4, Asynchronous business response + technical confirmation of original sending system

Asynchronous message exchange with technical confirmation is mostly used when the receiver wants to be in business control, or when the process on the receiving side might be that instable that there is no way to give the sender full technical control. To give an example for that last one; when manual steps in the business process of the receiver might be involved, you can generally speak of asynchronous messaging as your only option. You could synchronously confirm a request identifier, but not the outcome of the business process itself.

Figure 5, Asynchronous business request without technical confirmation

Also asynchronous interface without technical confirmation is possible. You might assume that in this case processing the inbound message may not be a showstopper for integration process. Mostly this kind of interfaces is used for logging or informing.

In XI there is a difference between synchronous and asynchronous interfaces. The technical confirmation is depending of the used adapter. The fault message is used for technical confirmation and is implemented into the adapter.


Depending on specific business needs in terms of having both control and responsibility, you have to make a decision on message integration: synchronous or asynchronous with or without sending a technical confirmation.

If the business process has manual steps or the receiver wants to be in control, asynchronous message exchange is the only option. If the sender needs a direct business answer, you might go for the synchronous interface. Always keep in mind who is responsible of the quality of information of your request, and if synchronous, to define a returning message profound enough for the sender to deal with.

Coming next in the D-XIE soap:

Determine the Software Component Version of standard SAP IDocs and Remote Function Modules! See you next time in de D-XIE soap …

Thanks to all D-XIE members, especial Hans GM for helping me writing this weblog.
You must be Logged on to comment or reply to a post.
  • hi Robert,

    if you want to post a weblogs on standard EAI
    patterns (like messaging types and + the one about
    basic principles with XI in the middle)
    you should have a look at

    sync, async: 
    link Interlude: Composed Messaging

    you’ll find all of them described
    as these are not nor SOAP nor XI specific
    but they apply to most interface scenarios
    (software & protocol independent)

    there’s even also a whole book about it
    to which you could probably refer 🙂

    my point is that it’s good to know
    about those patterns but you do you think
    you should include SOAP protocol or XI
    with it?


    • Hi Michal,

      It is not our intention to write blogs about EAI patterns. Most XI consultants in the Netherlands (and we expect also in other countries) are formally ABAP consultants with little EAI experience. They will follow a SAP XI course and will be the XI integration expert of the implementation partner!!! They will be the success or failure of XI implementations.

      With our blogs we want to trigger these beginning XI Consultants to make the right decision and that they have think about there solution. Also your tip about the EAI patterns can help them to become a better Integration Consultant.

      In our opinion sharing knowledge, not only technically, but also needed expertise and skills will be the success factor of SDN and future SAP implementations. For you and me this knowledge is common sense but we have to help the beginning XI consultants too.

      With regards,

      Robert Eijpe

      • Hi Robert,

        >>>It is not our intention to write blogs about EAI patterns.

        I understand but you do:)
        my points is not: don’t write weblogs
        but rather: why include SOAP or even XI in the topic?
        since it’s for correct for most message flows
        + most of the middleware software
        it’s common integration knowlegde

        >>>>In our opinion sharing knowledge, not only technically, but also needed expertise and skills will be the success factor of SDN and future SAP implementations.

        Robert…no one can disagree with that 🙂

        >>>>Most XI consultants in the Netherlands (and we expect also in other countries) are formally ABAP consultants with little EAI experience

        didn’t know that – in my company they worked
        with other EAI tools before (business connector mainly)