Show TOC Start of Content Area

Background documentationService 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 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.

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:

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

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 and context objects are referred to as interface objects.

Features

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.

More information: Interface Pattern

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

Security Profile

Stateless

Normal Operation

Synchronous or Asynchronous

No

Low

Medium

High

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

Stateless (XI 3.0 compatible)

Note: This interface pattern will be available only if you have the SAP NetWeaver PI installation in your landscape.

Normal operation

Synchronous or asynchronous

Basic

Strong

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.

Mode and Messages

Mode

 

Asynchronous

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

Synchronous

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.

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.

Whenever 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

 

 

 

End of Content Area