Developing Message Interfaces 

Purpose

By using platform-independent message interfaces you can define the type of communication and the data to be exchanged before you actually implement the cross-system process. Also see: Introduction to Interface Development.

Overview

The following illustration displays the class model for interface objects in the Integration Builder:

As with all repository objects, interfaces are organized by using namespaces that are assigned to a software component version. Imported interfaces (not shown in the class model) are assigned to a namespace belonging to an interface type, however you can create new namespaces for message interfaces (see also:  Organization of Shipment Contents).

Message interfaces comprise message types and data types. This two-layer structure uses WSDL (Web Service Description Language) and is oriented towards maximum reusability.  Fault message types are a special kind of message type that you use to handle application-specific errors. Message interfaces, message types, fault message types and data types are all commonly referred to as interface objects.

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.

Prerequisites

Before you can develop message interfaces in the Integration Builder, you must import a software component version and create one or more namespaces for it (see: Displaying/Changing Software Component Versions).

For more information about system prerequisites, see the Prerequisites section in Introduction to Interface Development.

Process Flow

The process flow outlined here only covers the technical side of message interface development and not general guidelines for designing interfaces and data types.

...

        1.      To define the contents of the messages to be exchanged you require data types. Establish whether data types already exist for the interfaces you require. If necessary, create new data types. Also note that when you import an interface, no data types are created for the counterpart (outbound or inbound) interface (also see: Communication Partners).

        2.      To reference a message yourself (in mapping, for example), you must use a message type that links to a data type. Check whether a corresponding message type already exists and, if necessary, create a new message type. In the simplest case, you require a message type for the request message and for synchronous communication you also require a message type for the response message.

        3.      Optionally, you can use fault messages to handle application-specific errors that occur on the inbound side. Check whether a corresponding fault message type already exists and, if necessary, create a new fault message type.

        4.      To send a message between two systems you always require an interface pair, namely an outbound interface and an inbound interface:

¡        To send messages using a communication partner on the inbound side, you must create an outbound message interface.

¡        To implement a service on the inbound side that can receive messages, you must create an inbound message interface.

The communication partner of a message interface does not necessarily have to be a message interface. You can also connect message interfaces with senders or receiver that are connected to SAP Exchange Infrastructure by means of an adapter.

        5.      Compile documentation for the objects you created.

Result

The Integration Builder saves the message interface with the referenced message types and data types in the Integration Repository. You can now do the following:

·        Use proxy generation to generate a Java or ABAP proxy from a message interface.

·        Begin designing mappings while simultaneously developing runtime components.

·        Reference the message interface while designing business scenarios.

·        Optionally export an XSD or WSDL document as a local file from the repository (see: Exporting XSD and WSDL Documents).

You can then configure the contents in the Integration Directory.