Communication Parties (Case Examples) Introduction to Interface Development

The separation of outbound and inbound interfaces separates the calling and the called application from one another. Theoretically, you can therefore combine any interface types. Some typical examples are described below, which illustrate the necessary steps in interface development. For information about the technical prerequisites, see the Prerequisites section in Introduction to Interface Development.

General

Assigning Interfaces

The case examples focus on interface objects. The generate rule is that outbound interfaces are not assigned to the corresponding inbound interfaces until configuration time (see: Defining Interface Determinations). However, you can model this assignment in an integration scenario in the Integration Repository and use the integration scenario as a starting point for configuration.

In the case examples it is irrelevant whether an interface is on the outbound or the inbound side (for example, whether a proxy is used on the inbound or outbound side of the communication). They apply to both cases.

When communicating with external systems, it is possible that there are no interfaces, that is, interfaces cannot be imported into the Integration Repository. The Communication with Interfaces That Cannot Be Imported section below outlines how to proceed in such cases.

Message Formats

The respective adapter converts the interface call to an XML format supported by the interface. For example, if an RFC is called, the adapter generates RFC XML, which is supported by the Integration Engine. Proxies can process proxy XML and RFC XML or IDoc XML (proxy XML if message types are assigned to the message interface, RFC XML or IDoc XML if an imported RFC message or IDoc message is assigned to the message interface).

Communication Between Proxies

In the simplest case, messages are exchanged between two systems that both support proxy generation. In this case, you can create and reuse data types, (fault) message types, and message interfaces directly in the Integration Repository. Since message interfaces comply with accepted standards, SAP recommends that you use this approach for new developments.

See also: Developing Message Interfaces.

Communication Between Proxies and Imported RFCs or IDocs

If you are connecting an old SAP system to XI using the RFC adapter or the IDoc adapter, proceed as follows:

1. Import the RFC or IDoc interface to the Integration Repository (see: Importing IDocs and RFCs).
2. Create a message interface. The counterpart of an IDoc is always asynchronous, whereas RFCs can be asynchronous or synchronous. Assign the RFC or IDoc message to the output or input message by using the input help.
3. Generate a proxy for your message interface. The RFC or IDoc is already available in the system and can exchange messages with the Integration Server by using the respective adapter.

The message interface and the RFC or IDoc reference the same message schema. Therefore, no mapping is required.

Communication with Interfaces That Cannot Be Imported

SAP XI also supports the connection of interfaces that cannot be imported to the Integration Repository. There are two variants:

· The message schema is contained in a WSDL, XSD, or DTD document and can be processed by proxy generation functions. In this case, you use message interfaces as the counterpart to the interface that cannot be imported.

· The message schema cannot be imported or processed by proxy generation. In this case, you use adapters on the sender and receiver side to enable communication.

Communication Between Proxies and Interfaces That Cannot Be Imported

If your system supports proxy generation and the proxy generation functions can process message schema, proceed as follows:

...

1. Import the WSDL, XSD, or DTD document to the Integration Repository as an external definition.

2. Create a message interface and reference the message(s) of the external definition by using the input help. For external, you can use an abstract message interface since no proxies have to be generated in this case.

3. Generate a proxy for your message interface. The interface that cannot be imported is already available in the system and can exchange messages with the Integration Server by using the respective adapter.

Communication Between Components That Do Not Support Proxies

You can enter interface names in the Integration Builder manually. This enables you to connect systems from which interfaces cannot be imported or whose message schema is not supported by proxy generation.

· For technical reasons, it is only possible to import RFCs and IDocs for SAP systems Release 4.0 or higher. However, the RFC and IDoc adapters can be implemented with SAP systems Release 3.1l and higher. In this case you must enter the interface names manually. For more information about IDoc and RFC interfaces Release 3.1l and higher, call the Interface Repository at the Internet address ifr.sap.com.

· The Adapter Engine supports the connection of external systems that are not necessarily connected by means of an interface (for example, the file adapter). When configuring the inbound adapter, specify instead the ID of the logical sender and receiver by using the respective business system, a namespace, and any interface name. If a mapping is required, you need an interface to be able to specify your mapping program later in the configuration using an interface mapping. For external systems, you can use an abstract message interface since no proxies are to be generated in this case.

Even if the proxy generation functions cannot process the message schema of an external definition, it is still useful to import a used message schema to the Integration Repository for the following reasons:

· The message schema is centrally available.

· You can use the message schema to define a message mapping.

In the case of interfaces that have not been imported, if you have entered the Repository namespace and the interface name correctly during mapping and routing, the Integration Server recognizes the corresponding communication parties (the namespace does not then necessarily have to be available in the Integration Builder).