Interface Pattern
You assign each service interface an interface pattern, which describes the type of the communication to be executed. Before we describe the interface patterns Stateless (XI 3.0-Compatible), Stateless, Stateful, and TU&C/C, it is necessary to clarify the terms stateless and Stateful:
- 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.
- 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.
Note that the messaging runtime can explicitly support or not support such a procedure. If the messaging runtime supports stateful communication, the application programmer can use the corresponding methods of the messaging runtime.
Furthermore, in the interface patterns of a service interface, these terms relate to the state at the provider and not on the Integration Server (in the case of enhanced communication). Therefore, when selecting a stateless interface pattern you can enhance the communication using the Integration Server to include execution of a stateful integration process that permits message correlation. More information: Integration Processes
This interface pattern is relevant only if you have SAP NetWeaver Process Integration installed in your landscape.
With this interface pattern, you can continue to use all existing protocols (up to SAP NetWeaver 2004s) in the back end that were developed on the basis of message interfaces. Message interfaces from the Integration Repository of SAP NetWeaver 2004s are migrated to service interfaces in the Enterprise Services Repository and are assigned this interface pattern. The interface pattern only allows one operation.
The following table gives an overview of the programming models that you select implicitly with this interface pattern. Since development starts with service interfaces, the table only applies to the outside-in approach.
Supported Modes Depending on Back End and Type of Communication
| Back End(SAP NetWeaver 2007) | Point-to-Point | Enhanced Communication Using the Integration Server |
|---|---|---|
|
AS ABAP |
Synchronous communication using the Web service runtime with the help of the programming model of SAP NetWeaver 2004s. We recommend using the interface pattern stateless for new developments. |
Synchronous and asynchronous communication using the XI runtime and the XI adapter with the help of the programming model of SAP NetWeaver 2004s. |
|
AS Java |
Not supported for SAP NetWeaver 2004s. Use the interface pattern Stateless. |
Synchronous and asynchronous communication using the Java proxy runtime (JPR) and the XI adapter with the help of the programming model of SAP NetWeaver 2004s. |
In SAP NetWeaver 2004s, point-to-point scenarios were realized exclusively with the help of the Web service runtime and enhanced scenarios (Integration Server) using the XI runtime and the XI adapter. As of SAP NetWeaver 2007, the Integration Server supports message exchange with the Web service runtime using the Web service adapter. The next section describes the related interface patterns.
If you select the following interface pattern, you are choosing communication using the Web service runtime:
- Stateless
For this interface pattern, the Web service runtime supports point-to-point communication using Web services as well as communication using the Integration Server with the help of the Web service adapter.
- Stateful
Successive calls use a state at the provider. 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.
- TU&C/C
An interface pattern that is based on the existing protocols for synchronous and asynchronous communication and enables cross-system ROLLBACKs (see below). This interface pattern supports both point-to-point communication using Web services and communication using the Integration Server with the help of the Web service adapter.
The selected interface pattern determines how an application developer programs communication in the back end. If you change the interface pattern, the application program in the back end must also be changed. This applies if the interface pattern is changed from Stateless (XI 3.0-Compatible) to Stateless, and for any other changes.
For cross-system updates, it is better to work with synchronous communication, because the quality of service Exactly Once (In Order) (EOIO) guarantees that a message is delivered once (in the case of EOIO in the correct order), even after a system crash.
However, if the continuance of a transaction depends on the results of a service call, you can work with a synchronous call. In this case, calls within a component are unproblematic: When the called service updates changes in the system, these updates are part of the calling transaction. The caller determines for the whole transaction whether the system writes the changes to the database (COMMIT) or not (ROLLBACK). There is no such automatism for cross-system service calls. Instead, you can ensure the consistency of the data by using the TU&C/C protocol.
The TU&C/C protocol ensures that data can be updated consistently at the receiver in spite of synchronous calls. The basic procedure is as follows:
- The consumer uses a synchronous tentative update operation to call a service at the provider for updating data. However, as the name of the operation implies, the provider does not update the data just yet. Instead, the provider makes a note of the changes. A flag shows that the data still has to be updated.
- Further calls by synchronous tentative update operations are possible. If the corresponding transaction ID is transferred, the provider can assign the collected changes to a transaction.
An application that uses the TU&C/C protocol must transfer the transaction ID itself. Therefore, application developers must model a field for the transaction ID during modeling of the data type that is to be used for the message type for communication.
- The consumer then calls an asynchronous compensate operation or an asynchronous confirm operation:
- The consumer uses the compensate operation to declare all previous tentative update operations of a transaction as invalid. The provider does not update them and can delete the temporary entries.
- The consumer uses the confirm operation to declare that all previous tentative update operations of a transaction are to be updated. The provider writes the data to the database.
This mechanism is based on guaranteed processing of asynchronous messages and only functions under the following conditions, which are often referred to as the contract between the consumer and the provider:
- The consumer system sends either a confirm message or a compensate message as soon as the running transaction ends, not only if this is as the result of an explicit COMMIT or ROLLBACK, but also if the transaction is canceled due to a system error.
- The provider system makes sure that the provisional changes of the tentative update operations are written to the database as soon as a confirm message is received, or that they are rejected as soon as a compensate message is received. This happens regardless of a provider system failure or similar errors. This guarantee also applies to changes that the provider saved provisionally in addition to the changes of the tentative update messages.
The provider ignores the compensate message if a tentative update message has not yet been received.
Messaging runtime makes sure that the compensate message is sent in all error or failure situations. To do this, it registers a compensate message before the first call of a tentative update operation. If the system crashes, the system can find and send the message upon restart. If the transaction is completed successfully, the system replaces the compensate message with a confirm message, to inform the provider.
Since the TU&C/C protocol requires agreement between the consumer and provider, it is only suitable for scenarios within a system landscape and not for cross-company scenarios such as communication with anonymous users using the Internet.