Interface-Based Message Processing 

 Exchange Infrastructure messages are based on XML. How can an application send a message of this type to a receiver? The idea is similar to a Remote Function Call (RFC): Communication with another system is encapsulated in an interface; the parameters of this interface are compiled in a message. The following graphic illustrates schematically how a message is sent to a receiver using a sender interface:

Multiple receivers can exist, the principle remains the same.

The graphic illustrates that for an interface A in a sender system, there is an assigned interface B in the receiver system:

·        For example, interface B gives you access to a service that determines and returns customer data for a request.

·        The task of interface A is simply to generate a message using values transferred to the interface; this message is then sent to an assigned receiver interface using the Integration Server.

The application does not need to implement anything to transfer the parameters to the message. This is the task of the Proxy Framework, which forwards or receives the message. To send a message, simply call interface A and transfer the parameters for the request message. You must also implement the receiver processing of interface B on the receiver side.  

Interface Types

Of course, the question is where do both interfaces originate from. There are two different types of interfaces:

·        Message Interfaces: You create these initially in an Integration Repository as XML-based, platform-independent descriptions (see Design Time). You can use this description to generate interface proxies in one or more systems (on different platforms). The interfaces in the previous graphic were generated using message interfaces.

·        Imported Interfaces: You import these into the Integration Repository using interfaces in SAP systems. You can include imported interfaces in the Exchange Infrastructure by using adapters. In this case, the adapter takes over the Proxy Framework’s task of generating the message and forwarding it to the Integration Engine. The previous graphic therefore illustrates the communication between two IR-defined interfaces.

The difference between message interfaces and imported interfaces also leads to different program models. For message interfaces you use a platform-independent description to provide interfaces in a system. For imported interfaces, however, you access the system externally. Therefore, the first approach is called Outside-In and the second approach is called Inside-Out. In both cases, the description of an interface in the Integration Repository is separated from the implementation, which has the following advantages:

·        Interface information is centrally accessible

·        You can use the interface description for application development in the systems and simultaneously for the design of Business Scenarios and mappings

Outbound and Inbound

Interface A and interface B complement themselves in that interface B receives the message that was sent by interface A. To emphasize this difference, interfaces that send messages are called Outbound Interfaces and interfaces that receive messages and implement a service are called Inbound Interfaces. As indicated by the broken arrows, communication can only be regarded as the transfer of a message, depending on whether the communication is synchronous or asynchronous (also see: Communication Parameters).

Outbound and inbound interfaces are also used to separate (potential) senders and receivers. The interface parameters do not need to match (a mapping is then required at runtime). This enables various senders and receivers to communicate with each other. In particular, this loose link also enables you to assign interfaces of this type to each other, for which one side of the communication must not, or cannot be changed.

Discussion

Using XML technology has, among others, the following advantages:

·        XML is the standard exchange format in the Internet.  Before this standard was created, there were practically no open exchange formats, which made communication in heterogeneous landscapes very difficult.

·        Further standards and tools now exist that make working with XML even easier, examples being XML Schema, XSLT and Xpath. XSLT (eXtensible Stylesheet Language for Transformations), for example, enables you to define mappings required to map message structures. Xpath expressions enable conditions to be evaluated depending on values in the XML message. Evaluations of this type are required for receiver identification in logical routing.

·        As a standardized format, XML also enables you to connect to external systems. If the data from the external system can be converted to XML using an adapter, then the step to convert the data to other XML formats for receivers is a small one.