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 your cross-system process. See also: Introduction to Interface Development.

Overview

The following graphic displays the class model for message interfaces in the Integration Builder:

As with all repository objects, message interfaces are organized by using Repository namespaces, which are assigned to a software component version (see also: Organization of Shipment Contents).

You can construct message 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.

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.

· Using fault message types (optional), which enable you to handle application-specific errors.

· Using RFC or IDoc messages as a counterpart to an RFC or IDoc in the SAP system.

· 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.

Prerequisites

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

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

Process Flow

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

...

1. Depending on the communication parties that are involved, proceed as follows (see also: Communication Parties (Case Examples)):

¡ If you create the objects for your interface definition in the Integration Builder:

i. 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 (for example, by using the search help). If necessary, create new data types.

ii. To reference a message yourself (in mapping, for example), you must use a message type that references 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. For synchronous communication you also require a message type for the response message.

iii. 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 and, if necessary, create a new fault message type.

iv. Create a message interface and reference the message type and fault message type that you have created.

¡ If you access definitions from application systems:

...

i. Import your message schemas from external definitions, or RFCs or IDocs from SAP systems. These definitions already contain data types.

ii. Create a message interface and reference the messages of the external definition, or the RFC or IDoc message.

2. To send a message between two systems you always require an interface pair. You can combine message interfaces with any other interfaces. The following table contains some examples:

Communication Parties for Message Interfaces with Interfaces in the Integration Repository

Message Interface Category	Possible Counterpart	Type of Communication
Outbound message interface	Inbound message interface	Proxy-proxy communication
Abstract message interface	(Outbound or inbound message interface)	Proxy-process communication
Message interface (outbound or inbound)	RFC/IDoc interface (inbound or outbound)	Proxy-RFC or proxy-IDoc communication

The communication party of a message interface can also be an interface that cannot be imported into the Integration Repository. See also: Communication Parties (Case Examples).

3. Create the counterpart for communication in the Integration Builder (Design) or import it.

4. Compile documentation for the objects you have 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:

· Create context objects for the fields of your request message that you want to use in processes or for logical routing in conditions.

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

· Use abstract message interfaces in a cross-component integration process to define the process signature.

· Begin designing mappings while simultaneously developing runtime components.

· Reference the message interface while designing integration scenarios.

· Use the option of exporting an XSD or WSDL document as a local file from the Repository (see: Exporting XSD and WSDL Documents).

The graphic in the Object References section shows the relationships between the interface objects and relationships to other design objects.