Service Interface

Use

A service interface enables you to describe - independently of a platform or programming language - operations that you require later for an implementation in the application system at a later stage. Depending on the category of a service interface, the following use cases are possible:

Inbound (Provider Role): You want to implement a service in an application system, which can be called by a user.
Outbound (Consumer Role) You want to call a service of a provider. To do so, you require the outbound service interface that matches your inbound service interface.
Abstract In enhanced communication using the Integration Server, you want to exchange messages with a buffered integration process (more information: Process Signature ).

In the application system, you use proxy generation 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.

You use the interface pattern in the ES Repository to determine which protocol you want to use.

Integration

The following figure shows a simplified class model for service interfaces in the ES Builder:

As with all design objects, service interfaces are organized by using Repository namespaces , which are assigned to a software component version (see also: Organization of Shipment Content ).

You can construct service interfaces in the following way:

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

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.
By using RFC or IDoc messages as counterparts for an RFC or IDoc in the SAP system (not shown in the figure above) for A2A or B2B integration.
Using external WSDL, XSD, and DTD definitions, and the message schemas that they contain.

These objects, as well as business objects and context objects are referred to as interface objects .

Features

The service interface editor looks as follows ( Definition tab page):

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

More information: Interface Patterns

Abstract Service Interfaces

Abstract service interfaces are required for the execution of cross-system integration processes. The execution of such processes enhances communication using the Integration Server as follows: an integration process on the Integration Server can relate messages to each other according to a specified model (also known as orchestration ). An integration process is therefore executed after a message has been sent and before it has been received by a receiver. An integration process receives and sends messages by using abstract service interfaces . In an integration process, a service interface in this category can take on the role of an inbound or outbound service interface depending on whether it is used for sending or receiving a message. For this reason, no direction is specified during definition. In integration processes, you can use the same abstract interface to receive and send a message. Abstract service interfaces generally receive the message from an outbound interface of a sender system and send it to an inbound interface of a receiver system, thus performing a complementary role.

More information: Integration Processes

You also use abstract service interfaces for particular adapters. You cannot generate proxies for service interfaces of this category since abstract interfaces are not designed to be implemented in an application system.

More information: Combining Different Development Approaches

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 to select from:

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 or Asynchronous	No Low Medium High
tentative-update operation	Synchronous
confirm operation	Asynchronous
compensate operation	Asynchronous

Caution

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 (compare with the information under Overview in the mapping section).

Mode and Messages

Mode	Messages
Asynchronous	Request , fault (optional and only for inbound service interfaces)
Synchronous	Request , Response , Fault (optional)

Note 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. For more details, please refer to SAP note 1928204 Information published on SAP site

. Services modeled using this mode cannot be used in Process Integration or BPM use cases.

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 ES Repository. 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 set of values to security profiles. Depending on the type of interface pattern selected, you can choose from different set of values for the security profile.

If you select the interface pattern as Stateless (XI30-compatible) , you can choose from the following values:
- Basic - Basic Authentication using user ID and password and no transport security.
- Strong - 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.
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

When the service interface is transported from an ES Repository of release lower than 7.11 to an ES Repository of release 7.11 or higher, the security profile is set to a default value. For the Interface Pattern XI30-compatible, the default value is Basic and for all other interface patterns the default value is Low.

When a service interface is transported from an ES Repository of release 7.11 or higher to an ES Repository of release lower than 7.11, the security profile value gets lost. After an upgrade the value will be the default value.

Idempotency

Idempotence describes the property of operations, which yield the same result after the operation is applied multiple times.

When an error occurs in the communication between consumer and provider, the consumer tries to send the same message again. If the service is implemented on the provider with the idempotency functionality, then the provider can handle the message correctly. For example, if the provider has already sent a response and the error occurred after sending the response, the provider does not handle the request the second time, but just sends the stored message again.

The Idempotent field is available for inbound service interface, with mode of operation as synchronous. This field is available for all the interface pattern except TU&C/C.

Note

When service interfaces are transported from an ES Repository of release 7.11 or higher to an ES Repository of lower release, the idempotency value is lost.

When the upgrade is done again from the ES Repository of release lower than 7.11 to an ES Repository of release 7.11 or higher the idempotency value is not set by default. To set the idempotency value, select the Idempotent checkbox.

More Information

Creating a Service Interface