Explaining Asynchronous Communication Pattern

For asynchronous communication, the receiving system does not have to be available at the time a function call is dispatched from the sender system. The receiving system can receive and process the call at a later time.

If a system is, for example, unavailable for a long period of time because of an upgrade, it can still process the data that has been sent in the interim at a later time, and processes in the sending system remain unharmed. Function calls are put in the sender system outbound queue, from where the call is repeated at regular intervals until it can be processed by the receiving system.

If a purchase order is sent to a vendor system, the sender system has no influence over the availability of the receiver system. If the receiving system is not available, the purchase order can be sent repeatedly until the vendor system is available again. Asynchronous communication is not to be used for processes that require an immediate response to the sender system.

With asynchronous methods, on the other hand, the client continues to work after a service call has been submitted - without being blocked while waiting for the answer. There is no answer with asynchronous methods since the OneWay Message Exchange Pattern is used. In this way, the client requires the security that his or her calls arrive on the provider side. Therefore, the transport guarantee is offered for asynchronous methods.

Moreover, calls on the client-side are performed transactionally. This means that all calls for a transaction are collected until the transaction is complete. This prevents parts of a transaction from being retained (data persistence) already on the provider side although the remainder could no longer be transmitted. Since each call is sent separately to the provider, it can happen that message b arrives before message a.

To balance this out, the Web Services Reliable Messaging feature is implemented. A sequence covers all calls of a logical unit of work (LUW) and assigns numbers to them. These are evaluated at the provider-side. In this way, it is ensured that messages in a sequence are processed in the right sequence and that problems do not occur because one action requires another one that has not yet taken place.

1. Import the Outbound Service Interface from the ESR

   Create the Service Interfaces in the Enterprise Services Repository and import the abstract WSDL into the Provider System.

2. Generate Consumer Proxies from the Service Interfaces

   Generate the Input Interface (in the asynchronous case). This happens during the import.

3. Configuration with SOAMANAGER

   Create a Logical Port and configure the Web Service Consumer communication in SOAMANAGER. This allows you to test the entire communication with the service provider in the Web Service Navigator.

4. Create a Consumer Implementation

   Create the consumer implementation which is used to call the consumer proxy.