Defining Message Processing Types and Quality of Services (QoS)

Synchronous processing contains the following properties:

• A sender system sends a request and waits for a response.
• The sender process is blocked until the response or error is received.
• The service interface consists of at least two message types, one for the request and one for the response (and a fault message type, if necessary).
• In case of connection failures, it is not known whether the data record was fully processed at the target.
• The sender is responsible for dealing with errors (not SAP Process Integration (PI)).

Examples of synchronous processing scenarios are as follows:

• A direct answer is necessary to decide something online (user interaction).
• A direct answer is necessary, for example, to find out the key for the recreation of an object.

In SAP PI, the QoS for synchronous processing is called Best Effort (BE). In the Remote Function Call (RFC) technology, this is comparable with synchronous RFC (sRFC).

Asynchronous processing contains the following properties:

• The sender system sends a data record and does not wait for a direct response.
• The sender can continue working, separated from the processing of the message by the receiver.
• As long as SAP PI is selected as the agent, the receiver does not have to be available when the message is sent.

In this case, a globally unique identifier (GUID) is attached to the data. This GUID is stored together with the data.

The receiver system can tell from the GUID whether the data record was processed before the connection was interrupted.

The sender and receiver have to support the renewed start.

Asynchronous behavior is possible with transactional RFC (tRFC) using the transaction ID (t-ID) or in SAP PI with QoS Exactly Once (EO) and a message ID.

The processing sequence can also be important in asynchronous scenarios. This can also refer to the content dependence of data records as well as aspects of performance. The performance can increase if data records are not sent at the same time. To achieve a serialization of messages, the data records are put into queues. While working with SAP PI, the QoS is always Exactly Once in Order (EOIO). In RFC scenarios, the queued RFC (qRFC), which is a special tRFC, is used.

The following interface patterns use the Web service runtime:

• Stateless (XI 3.0-compatible)
• Stateless
• Stateful
• Tentative Update & Confirm/Compensate (TUCC)

The interface pattern determines how an application developer needs to structure communication in the receiver system. This means that if the interface pattern of a service interface is changed, the user must also change the related application program.

The concept of the interface pattern was primarily introduced due to the Web service and service-oriented architecture (SOA). For this reason, this section focuses only on the part that is relevant for process integration processing, on the stateless (XI 3.0-compatible) and stateless interface pattern. This lesson does not provide instructions on how to use the other two interface patterns.

The stateless (XI 3.0-compatible) interface pattern can only be used in connection with process integration. In contrast, the service interface type stateless or TUCC can be implemented using either the process integration or point-to-point connection. The stateful interface pattern can be implemented only in connection with point-to-point connections.

The applications and properties of the stateless (XI 3.0-compatible) interface pattern are as follows:

• The stateless interface pattern is used for message interfaces in SAP 7.0 and earlier releases.
• The stateless interface pattern is used in classic process integration scenarios where adapters are involved (aside from the SOAP adapter).
• The stateless interface pattern allows only one operation. The name of the service interface and operation must be identical.

The difference between the stateless (XI 3.0-compatible) and stateless interface patterns is that the stateless interface pattern uses Web service technology, which also makes point-to-point connections without process integration possible. Furthermore, stateless service interfaces can define several operations that lead to several methods of the proxy classes with the Web service proxies in the back-end system.

The following conditions apply while requesting acknowledgments:

• Specify the requested type of acknowledgment in the proxy method call (application or system, positive or negative, or alternatively or complete).
• Determine the message ID of the message that was sent using a method call.
• Use the message ID and check whether a message has been returned directly in the program that is running.
• Buffer the message ID and check any acknowledgments received later on by actively using the message ID.

The following information applies to confirming acknowledgments:

• Server proxies create the requested acknowledgment automatically. A positive system acknowledgment is produced when the message has reached the target system; a positive application acknowledgment is created when no exceptions occur during the execution of the server proxy method.

  Negative acknowledgments are sent when the acknowledgment conditions mentioned above are not met.

  Caution

  If necessary, an exception class is created for a fault message type for asynchronous inbound service interfaces. In this case, a negative message is created only when this special exception class was used for implementing the server proxy.
• Receiver adapters running on the adapter engine support system acknowledgments when they are requested by the sender. These acknowledgments are triggered if the message is successfully processed by the adapter or if an error occurs during processing.

  Receiver adapters do not support any application acknowledgments.

  Note

  RosettaNet Implementation Framework (RNIF) and Chemical Industry Data Exchange (CDIX) adapters are exceptions to this, because, depending on the scenario, they also support application acknowledgments.
• The plain HTTP adapter does not support any application acknowledgments.
• If a target system receives Intermediate Documents (IDocs) and is set in the Application Link Enabling (ALE) to send an ALEAUDIT IDoc containing processing information back to the sender, the ALEAUDIT IDoc counts as an application acknowledgment.

IDoc is also the only technology where positive acknowledgments can also contain data. These are returned when the sender system is an IDoc system. Otherwise, the data is discarded.