Show TOC

Procedure documentationDeveloping Point-to-Point-Services Outside-In Locate this document in the navigation structure

 

You want to exchange point-to-point messages between two systems using Web Service runtime. To do this, you create data types, (fault) message types, and service interfaces directly in the ES Repository and therefore they are available centrally. Since service interfaces comply with accepted standards, we recommend that you use this approach for new developments.

The procedure described here concentrates on the necessary technical steps of development and does not take design guidelines into account.

Prerequisites

You have two applications and you want to use the outside-in approach to enable them to exchange messages. The service interfaces are in different products and different software component versions. We will refer to them as CONSUMER and PROVIDER.

More information: Organization of ESR Content

Procedure

1. Model the Inbound Service Interface

First model the objects of the service that is to be called at the provider.

  1. Create an inbound service interface in the software component version PROVIDER. Select the interface pattern appropriate to the usage.

    Note Note

    Point-to-point scenarios using the Web Service runtime support the interface patterns Stateless (XI 3.0-Compatible), Stateless, Stateful and TU&C/C.

    End of the note.

  2. Create the operations required for your service at the inbound service interface. Service interfaces with the interface pattern Stateless (XI 3.0-Compatible) only support one operation.

  3. First determine whether message types and data types already exist for the operations you have created (for example, by using the search help). If necessary, create new message types and data types in the software component version PROVIDER.

  4. Reference from the operations to the respective message type and from the message type to the data type.

  5. To handle application-specific errors that occur on the inbound side, you can use fault messages (optional). Check whether a corresponding fault message type already exists; if necessary, create a new fault message type in the software component version PROVIDER and reference it from the related operations.

  6. You can assign classifications to inbound service interfaces. These classifications enable you to search for the service interfaces easily. You can classify the service interfaces based on industry, application name, deployment unit, and so on.

2. Model the Outbound Service Interface

Service interfaces can only be delivered as a whole (that is, including all referenced objects). Because of this, the operations of the required outbound service interface in the software component version CONSUMER cannot reference the interface objects of the software component version PROVIDER. Therefore, you must copy the objects.

  1. Copy the inbound service interface from the software component version PROVIDER to the software component version CONSUMER with all dependent objects.

  2. Reclassify the inbound service interface in the software component version CONSUMER as an outbound service interface.

  3. Make sure that the XML namespace of the respective (fault) message type that is referenced by the respective operation of the outbound service interface matches the XML namespace of the corresponding (fault) message type of the inbound service interface. More information: XML Namespaces.

  4. To be able to configure the exchange of messages later, enter the inbound service interface that you copied in step 6 on the Matching Service Interfaces tab page of the oubound service interface.

    More information: Matching Service Interfaces for Point-to-Point Communication

More information: Service Interface

Result

You have created an outbound service interface and an inbound service interface, each with one or more operations. By using proxy generation, you can generate proxy objects in ABAP or Java to implement the communication between these two interfaces using the proxy objects.