Introduction to Service Interfaces
A service interface (SI) is used to describe operations that are required later for an implementation in the application, independent of platform or programming language.
Depending on the category of a service interface, the following use cases are possible:
Inbound (Provider Role)
A service in an application system, which can be called by a user.
Outbound (Consumer Role)
A call from a service of a provider is required. To do so, you require the outbound service interface that matches the inbound service interface.
In the application system, a proxy generation is used to generate development objects for implementation based on the service interfaces.
Proxy generation generates the following objects automatically:
- Proxy objects (for example, classes, methods, and data types).
- A service definition for communication using the Web service runtime.
Note
In the case of the stateless (XI 3.0 compatible) interface pattern, a service definition is only created if the operation is a synchronous operation.In general, the interface pattern in the Enterprise Service Repository (ESR) is used to determine which protocol is used by the service interface. As with all design objects, service interfaces are organized using Repository namespaces, which are assigned to a software component version.
You can construct service interfaces using the following methods:
- Through message types and data types
This two-layer structure uses WSDL (Web Service Description Language) and is oriented towards maximum reusability. Customers can also use data type enhancements to add their own fields to a message. To handle application specific errors, you have the option of using fault message types.
- Through RFC or IDoc messages as counterparts for an RFC or IDoc in the SAP system for A2A or B2B integration
- Through external WSDL, XSD, and DTD definitions, and the message schemas contained in them
These objects, as well as business objects and context objects, are referred to as interface objects.
Note
The introduction of an intermediate message type layer seems at first glance unnecessary; however it is required in XML so that a message can be handled as a separate instance. Data types in XML schema do not yet define an instance of this type because a data type does not yet define an element.Building a Service Interface
In general, service interfaces are built in a service interface editor. In the editor you can switch between the design and the source (code) tabs.
Category and Interface Pattern
The interface pattern determines the type of communication. Service interfaces of the categories outbound or inbound are used for the implementation of communication in the application system. In this case you can select all interface patterns. Service interfaces of the category abstract are intended for communication with an integration process on the Integration Server. In this case you can only use the interface patterns stateless and stateless (XI 3.0 compatible).
Interface Patterns and Operations
Each service interface can have multiple operations. Depending on the interface pattern, the service interface editor provides you with appropriate operation patterns and modes from which to select.
Service Interface Operations
| Interface Pattern | Operation Pattern | Mode of Operations Available | Security Profile |
|---|---|---|---|
| stateless | normal operation | Synchronous and Asynchronous | No Low Medium High |
| stateless (XI 3.0 compatible) | normal operation | Synchronous and Asynchronous | Basic Strong |
| stateful | normal operation | Synchronous | No Low Medium High |
| commit operation | Synchronous | ||
| rollback operation | Synchronous | ||
| TU@C/C | normal operation | Synchronous and Asynchronous | No Low Medium High |
| tentative-update operation | Synchronous | ||
| confirm operation | Asynchronous | ||
| compensate operation | Asynchronous |
Note
Data may be lost if you change the interface pattern of a service interface, because not every operation pattern is available in every interface pattern. Furthermore, the change may require you to make a change to an existing implementation. You must therefore commit to one interface pattern at the start.The structure of the data to be exchanged is defined by the reference to a message schema. Depending on the mode, in the service interface editor you can reference message types, RFC messages, IDoc messages (for requests only), or external messages for the relevant direction of message exchange.
Mode and Message Types
Mode | Messages |
|---|---|
Asynchronous | Request, fault (optional and only for inbound service interfaces) |
Synchronous | Request, Response, Fault (optional) |
From the ES Repository release of 7.31 SP11 and 7.4 SP06 onwards, it is also possible to model services based on mode Asynchronous Best Effort. Services modeled using this mode cannot be used in Process Integration for BPM use cases.
Note
For more details, refer to SAP note 1928204.If you want to handle application-specific errors or persist them in monitoring, assign corresponding fault message types to the operation. Fault messages transfer errors on the receiver side to the sender or to monitoring. For this reason, it is not possible to define fault messages for asynchronous operations of abstract service interfaces or for asynchronous operations of outbound service interfaces.
Security Profile
You can assign security levels to the service interfaces in the ESR. These values form the metadata descriptions which influence the behavior during implementation of this service definition. This feature is applicable only for point to point communication. You can assign different sets of values to security profiles. Depending on the type of interface pattern selected, you can choose from a different set of values for the security profile.
If you select the interface pattern as Stateless (XI 3.0 compatible), you can choose from the following values:
Security Profiles for Stateless (XI 3.0 compatible) Interface Pattern are:
- Basic
- Basic Authentication using user ID and password and no transport security.
- Strong
- Strong Authentication (SSL or SSO) and transport security.
If you select the interface pattern as Stateful, Stateless, or TU&C/C, you can choose from the following values:
No
No Authentication and no transport security.
Low
Basic Authentication using user ID and password and no transport security.
Medium
Basic Authentication using user ID and password and transport security.
High
Strong Authentication (SSL or SSO) and transport security.
Note
The Security Profile field is available only if you select the Point-to-Point Enabled checkbox.
