Introduction
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.
Synchronous
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
Asynchronous
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.
Conclusion
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.
3 Comments
