The interface patterns: stateless (XI 3.0 compatible), stateless, stateful, and TU&C/C assign the type of communication to be performed to each service interface.
The figure illustrates the screen in which the relevant configuration takes place.
Stateless
Stateless communication means that the messaging runtime does not support the saving of a status at the provider once the messaging runtime has completed the message exchange successfully.
Stateless (XI 3.0 Compatible)
With this interface pattern, you can continue to use all existing protocols up to SAP NetWeaver 7.0 in the back end that were developed based on message interfaces. Message interfaces from the Integration Repository of SAP NetWeaver 7.0 are migrated to service interfaces in the Enterprise Services Repository and are assigned this interface pattern. The interface pattern only allows one operation.
Stateful
Stateful communication means that the messaging runtime supports the saving of a status at the provider once the messaging runtime has completed the message exchange successfully.
This interface pattern is only needed for a few special technical scenarios. It does not guarantee a common update of data at the receiver.
You cannot use this interface pattern for enhanced communication using the Integration Server. Only synchronous stateful communication is supported.
Note
Stateful interface patterns can only be used with synchronous communication.
The RFC calls can use a status on the provider side.
Tentative Update & Confirm or Compensate (TU&CC)
In a TU&CC scenario, several operations are required: at least one operation that undertakes the changes in the target system, an operation that confirms the changes if, for example, an order has definitely been placed, and an operation that triggers a rollback if a change has not been confirmed. Beforehand, an operation can be executed that does not makes any changes in the target system, but merely reads the values.
A TU&CC scenario could look like this:
The consumer sends requests to the server. The client then first performs the changes in his or her system. Only when an order, for example, has definitely been made on the client side will the changes be retained in the database. If there is any error, the changes will be rolled back. This type of communication requires special procedures in the application.
Note
This interface pattern makes it possible to process several synchronous update calls (database updates) in a transactional context (logical unit of work).
Synchronous update calls are initially only collected (a tentative update) until the sender sends a COMMIT (confirm) or ROLLBACK (compensate). Only then can the database updates be made or discarded by the receiver.
This interface pattern can be used only for A2A scenarios and not for B2B scenarios.
Quality of Service (QoS)
The Quality of Service (QoS) refers to the processing mode of a process integration XML message. The sender uses the different types of QoS to specify how a message should be delivered. You differentiate between synchronous and asynchronous processing
Quality of Services:
- Best Effort (BE)
You send messages synchronously by the sender system. The sender waits or a response, before it continuous processing. This it the default Quality of Service for synchronous interfaces, such as RFCs, BAPIs, synchronous ABAP proxies, or Web Services.
- Exactly Once (EO)
You send the message asynchronously. The sender doesn't wait for a response. The Quality of Service Exactly Once guarantees that the message is sent and processed exactly once. You normally select this QoS for most asynchronous interfaces, such as IDoc, synchronous ABAP Proxies, Web Service, etc.
- Exactly Once In Order (EOIO)
Similar to the QoS Exactly Once, you send the messages asynchronously using Exactly Once In Order. However, in this case messages are delivered in the same order as they were sent from the sender system. Use this QoS for Web Service Reliable Messaging (WS-RM).