Show TOC

Procedure documentationAssigning Service Interfaces to Each Other Locate this document in the navigation structure

 

If you develop a point-to-point communication using Web Service runtime with the outside-in approach, first create service interfaces in the Enterprise Services Repository. For P2P communication you need an outbound service interface for the call at the consumer and an inbound service interface for implementing the service at the provider. During design in the ES Repository it is already known which pair of service interfaces belong together. You can assign the service interfaces to each other in the ES Repository. It is not obligatory to assign them, it just makes configuration easier to execute later on:

  • In the backend system when configuring the logical port (interface pattern: Stateless (XI3.0 compatible)).

  • In the Integration Directory when configuring a Direct Connection (all other interface patterns).

More information: Point-to-Point Communication Using Web Services, Interface Pattern.

Prerequisites

You can assign another service interface to a service interface in the service interface editor if one of the two service interfaces (outbound or inbound) are changeable.

When Do Service Interfaces Match?

In the simplest case, the service interfaces are identical apart from name and category (inbound or outbound), that is, if the outbound service interface and all interface objects, are referenced by this service interface, are copies of the corresponding objects of an inbound service interfaces. If, however, the consumer only wants to call one operation of the inbound service interface, for example, it is not necessary to create the other inbound service interface operations in the outbound service interface as well.

Simply put, the operations and corresponding outbound service interface data structures can be a subset of the operations and corresponding data structures of the inbound interface referenced. The service interface editor provides a check for the service interface pairs to determine the compatibility of the inbound and outbound service interface. This check is performed in multiple steps to determine compatibility (starting service interfaces, across operations and down to data types). The following section describes the steps to be able to estimate for a service interface assignment whether two service interfaces match.

Matching Service Interfaces

Two service interfaces match each other if the following conditions are fulfilled:

  • One service interface is of the outboundcategory and the other service interface if of the inbound category. Neither of the service interfaces can be abstract.

  • Both of the service interfaces have the same interface pattern.

  • There is a matching operation in the inbound service interface for each of the operations in the outbound service interface (see below).

Matching Operations

An inbound service interface operation matches an outbound service interface operation (and the other way around) if the following conditions are met:

  • Both operations must have the name mode (asynchronous or synchronous).

  • Both operations must have the same Operation Pattern.

  • The message type for the request, which must be referenced by each operation, must have the same name and same XML Namespace. The names of the operations may differ. The same applies for the response with synchronous communication.

  • If the inbound service interface operation references a fault message type, the outbound service interface operation must also reference a fault message type with the same name and XML Namespace.

  • The data types of the message types, which the outbound service interface for the request message references (and, if necessary, for the response and fault message) must be compatible with the corresponding inbound service interface data types (see below).

Matching Data Types

The check whether the corresponding data types are compatible with each other is sufficient until the comparison of theFacets of an XSD type. The data types are compared using the same method as other objects: The structures are compatible if they contain the same fields (elements and attributes) and if these fields have compatible types, frequencies, details, and default values. There are however a few restraints, for example the target structure can contain attributes or elements that do not appear in the outbound structure, but if these are not required and where the frequency is optional or prohibited (attributes) or minOccurs=0 (elements). (Which structure is the outbound structure and which is the target structure is the same as the direction of the message exchange, compare the Overview for the mapping design).

Caution Caution

The check cannot check the entire XSD schema language. The check does not necessarily report an error for service interfaces whose operations reference external messages if the data structures are incompatible. There are the following restrictions in particular:

End of the caution.

  • The data structures compared must both be correct. For example, not all correct facets are skipped or considered in the compatibility check.

  • Some XSD schema language elements that can appear in a reference to an external message in the data structure are not supported. Therefore, the elements redefine and any, for example, as well as the attributes blockDefault, finalDefault, and substitutionGroup.

  • The comparison of structures is, for example, restricted to the following:

    • The detailswhiteSpace and pattern are not checked

    • If the facet pattern is used for the outbound structure field, all the other details are not checked.

    • If the order of subelements if different between the outbound and target field, a warning is displayed.

Procedure

You can enter the following references for the service interfaces depending on which service interface can be changed:

  • If the outbound service interface can be changed, you can enter one of multiple matching inbound service interfaces there. The outbound service interface is shown as an unchangeable entry for each inbound service interface (even when the inbound service interface is in processing).

  • If the inbound service interface can be changed, you can enter one of multiple matching outbound service interfaces there. The inbound service interface is shown as an unchangeable entry for each outbound service interface (even when the outbound service interface is in processing).

Mutual entries are possible but are not required.

  1. Call the service interface editor for the changeable service interface.

  2. Go to the Matching Service Interfaces tab.

  3. For each service that you want to reference enter a row in the table and reference each of the matching service interfaces using the search help, for example.

    Note Note

    Due to the large volume of data in the ES Repository the ES Builder cannot check during the search if the service interfaces match or not. Therefore non-matching service interfaces are also offered in the search help.

    End of the note.

  4. Check your assignments using theCheck Assignment of Matching Service Interfaces (Check Assignment of Matching Service Interfaces) function).

Result

  • The service interface editor identifies the entries you made in the service interfaces table with a blue arrow that points to the right (Defines Current Object (Defines Current Object)).

  • The entries that were entered into the service interface table automatically and that you have referenced are identified by the service interface editor with a blue arrow that points to the left (Defines Service Interface <Name and Namespace> (Defines Service Interface <Name and Namespace>)). You cannot edit or delete these entries here.