Sending Messages from Integration Processes Asynchronously 

Use

To send a message asynchronously from within an integration process, you use a send step in Asynchronous mode.

When a message is sent asynchronously, the send step does not wait for a reply message from the receiver after the message is sent. However, you can specify that the send step must wait for a confirmation of receipt from the receiver, in the form of an acknowledgment.

Processing Acknowledgments

The Business Process Engine supports Acknowledgments when sending asynchronously as follows:

Acknowledgment	Processing of Send Step
Receiver system does not support requested acknowledgments	Send step completed successfully
Positive acknowledgment	Send step completed successfully
Permanent negative acknowledgment	Send step triggers system error for which you can define a specific exception handling.
Temporary (transient) negative acknowledgment	Send step continues to wait because the temporary acknowledgment can still change to a permanent or negative acknowledgment. This can occur in the IDoc environment in particular, for example, when a user intervenes. Exception or error handling within the integration process is not possible. However, using message monitoring you can determine whether the acknowledgment is temporary or not.
Acknowledgment with multiple receivers	A message sent from a send step can have multiple receivers. In this case, the system duplicates the message accordingly. Acknowledgments returned from the respective receivers are ignored and the send step continues to wait. If multiple receivers are possible and you want to evaluate the individual acknowledgments, you must define the integration process accordingly. To do this, determine the receivers in a receiver determination step and send the message to the individual receivers in a loop.

 

For more information about acknowledgments, in particular how they are used in the adapter environment, see SAP Note 837285.

Procedure

Define Basic Data

       1.      Insert the send step at the required position in the process definition and select Asynchronous in the Mode field.

       2.      Specify whether the system is to create a new transaction for the send step.

You can improve system performance if you define that the system is not to create a new transaction for the send step. Note, however, that all messages to be sent are collected and not sent until the end of the relevant transaction. This is of particular importance for transactions that take a long time to execute.

If the send step must send an acknowledgment because the receiver has requested one, the system must create a new transaction for the send step.

More information: Transactional Behavior of an Integration Process

       3.      In the object area, define the container element that references the message to be sent.

More information: Defining the Data for a Process in Containers

       4.      Select this container element in the Message field in the properties area of the send step.

Wait for Acknowledgement

       5.      Specify whether the send step is to wait for an acknowledgement.

To receive an acknowledgement in the send step, the receiver (adapter, business system, and so on) must send the corresponding acknowledgment.

○       None (Default Setting)

The step is complete when the message has been successfully sent to the Integration Server pipeline.

○       Transport

Specifies that the message was received successfully.

○       Application

Specifies that the message was processed successfully by the receiver application (for example, ‘posted’).

Specify Receiver Determination

       6.      Specify how the system determines the receivers of the message.

More information: Sending a Message - Specifying Receiver Determination

Set Conversation ID

       7.      Set a conversation ID, if required.

You can use the conversation ID to flag messages that belong together semantically. All messages with the same conversation ID in the message header semantically belong to the same business process. You can use this mechanism to represent more complex communication models that extend beyond basic request/response relationships.

                            a.      In the object area, define a container element for the conversation ID with data type xsd:string.

                            b.      Select this container element in the Conversation ID field in the properties area.

If you use the conversation ID in a correlation, note the following:

○       The conversation ID must already be set when the correlation is activated.

○       The correlation must describe the corresponding message uniquely. The conversation ID is generally not sufficient to do this.

Define Quality of Service (EOIO)

       8.      Specify EOIO (Exactly Once in Order) as the quality of service, as required.

Messages are then delivered in the same sequence that they are sent in by the integration process.

                            a.      Specify a queue in the Queue Name field.

You can choose the name of the queue yourself.

Max. length: 16 characters

Permitted characters are alphanumeric characters and the following special characters:

/ (slash)

_ (underscore)

- (hyphen)

All send steps that have the same queue name are delivered in the sequence that they are sent in by the integration process. 

Specify Exception

       9.      If the system is to trigger an exception when a system error (permanent error) occurs, specify this exception in the System Error field.

More information: Exception Handling

Activate Correlation

   10.      Specify whether the send step is to activate a correlation.

This is required, for example, if the send step within a block with a ParForEach sends a message and the integration process is to receive a separate message in each parallel instance of the block.

More information: Correlation: Defining Assignment of Messages to Process Instances