Start of Content Area

Function documentation Service Interface  Locate the document in its SAP Library structure


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.

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.


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.


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

This graphic is explained in the accompanying text

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.


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.


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

This graphic is explained in the accompanying text


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 Operation


normal operation

synchronous or asynchronous

stateless (XI 3.0 compatible)

normal operation

synchronous or asynchronous


normal operation


commit operation


rollback operation



normal operation

synchronous or asynchronous

tentative-update operation


confirm operation


compensate operation



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




Request, fault (optional and only for inbound service interfaces)


Request, Response, Fault (optional)

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.



       1.      Create a service interface (more information: Creating an Object).


Together with the service interface, the service interface editor creates an operation with the same name as the service interface. You can change the name of the operation up until you save the service interface for the first time. To change the name after this point, you must delete the operation and create it again.

       2.      Define the category and interface pattern of the service interface.

       3.      Depending on the interface pattern, you require one or more operations. Use the operation list to create new operations. You can continue to change the name of the operation until you save the service interface for the first time.

       4.      Define the operation pattern and mode for each operation. Depending on the interface pattern, the service interface editor provides you with different operation patterns and modes to select from (see above).

       5.      Using the input help, assign each operation a message schema for the request message and, if applicable, response and fault messages. The corresponding interface objects must be in the same software component version as the service interface, or in an underlying software component version.

       6.      In enhanced communication, you can simplify access to the message payload by using context objects for logical routing. In the service interface editor, you can assign a request message context objects from the same software component version or from an underlying software component version (more information: Context Objects).

       7.      Save your changes.


You have created a service interface and can generate development objects for it in the application system by using proxy generation.






End of Content Area