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 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
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
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
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
