Designing a Service Interface and its Operations 
A service interface groups entities that belong to a service. One or more operations can be assigned to a service interface. For each operation, you can define one or more parameters.
A service interface is normally first designed on the provider side. This service interface is known as inbound.
A consumer can use the definition of an inbound service interface to define its own service interface. A consumer service interface is also referred to as outbound. The inbound and outbound service interfaces must be identical in order to be compatible. The Enterprise Services Repository ensures that the service interfaces are identical. These service interface pairs are used for point-to-point communication scenarios.
A consumer service interface can also be defined without reference to a provider service interface. This is also supported by the Enterprise Services Repository. Here, however, point-to-point communication is not possible as the structures of the inbound and outbound services interfaces are not identical. Brokering functionality is needed, and this is provided by Process Integration.
Procedure
From the Enterprise Services Builder, open the context menu, then choose New.
A dialog box is displayed.
Open the Interface Objects section and select Service Interface.
Specify a name, the namespace, and the software component version for the service interface.
Choose Create.
In the editor, set the options for the service interface.
For a provider service interface, set inbound.
For a consumer service interface, set outbound. Only consumer proxies can subsequently be generated from an outbound service interface.
Below is an overview of the possible combinations of attributes for interface pattern and operations.
Abstract
Inbound
Outbound
Synchronous
Asynchronous
Stateless
X
(for BPM)
X
X
X
X
Stateless (XI30–compatible)
X
(for BPM)
X
X
X
X
Stateful
X
X
X
(Normal, Commit, Rollback)
TU & C/C (Tentative Update & Confirm / Compensate)
X
X
X
(Normal, Tentative Update)
X
(Normal, Confirm, Compensate)
NoteAbstract: The service interface has no implementation in an application system.
Synchronous: The consumer is blocked until the service call is returned.
Asynchronous: The consumer is not blocked until a response is returned.
Stateless: No state is retained on the provider system between a service's operations calls.
Stateless (XI30–compatible): Only one operation
Stateful: The session state can be retained in memory on the service provider side across multiple service operation calls.
TU & C/C (Tentative Update & Confirm / Compensate): For synchronous communication between applications where changes in the persistent state are required on the provider side. More information: Interface-Pattern and Consuming TU & C/C Web Services.
End of the note.Assign the message types.
For synchronous service interfaces, you will normally need at least two message types: a request message type and a response message type. For asynchronous service interfaces, you will normally need only a request message type.
Save the service interface.
Activate.
Once saved in the Enterprise Services Repository, the service interface(s) need to be activated so that they can be used for proxy generation.
The modeling (design) process in the Enterprise Services Repository is now complete. You have created a model for a service interface, that is, the objects needed to build an executable enterprise service. The service interface will subsequently be used to generate a provider proxy in the ABAP back-end system.