Problem solve Get help with specific problems with your technologies, process and projects.

Introduction to the SAP XI (Exchange Infrastructure) - part one

This is the first in a two part series on the SAP XI (Exchange Infrastructure). The basic conceptual framework of SAP XI is covered here.

SAP NetWeaver is gaining traction in the marketplace as customers realize what a powerful application and integration...

platform it offers. This has resulted in tremendous interest in the Process Integration layer of the NetWeaver stack, implemented by the SAP Exchange Infrastructure, also known as SAP XI.

In this article I will describe the basic conceptual framework of the Exchange Infrastructure; in a subsequent article, I will detail the specific components of the XI architecture.

A good place to start is to consider the integration landscape that exists in most data centers today. Interfaces that connect different systems are generally peer-to-peer, custom-coded, and expensive to maintain. Furthermore, if one were to ask, "where is the information about a particular interface to be found," the answer would be generally hazy at best: it would be a few lines of comment at the front of a custom program, some document in some dusty binder on some forgotten shelf, or somewhere in the mind of the developer.

Perhaps the current landscape also has, in addition to custom interfaces, a host of middleware solutions from various vendors, each requiring its own expertise and maintenance. And this is just for integrating systems within our own enterprise boundary; the situation becomes worse when we consider the demands of B2B scenarios with a mixture of standards like EDI, EDIINT/AS2, RosettaNet, etc. And then, of course, there may be Business Process Management or Workflow engines from various vendors. We typically end up with what is frequently called the "integration spider web," or, with perhaps a better metaphor, the "integration hairball."

The XI straightens out the integration landscape using interface-based, SOAP-XML messaging. It offers transparency into the integration landscape via central repositories of shared collaboration knowledge. It provides unified message handling for both A2A and B2B scenarios. The XI allows SAP applications to communicate natively in the XI message format via proxies. It incorporates adapters for communication with RFC, IDOC, and non-SAP systems (which may be, for example, flat files, JMS queues, plain HTTP, applications from other vendors, or industry standards). It defines all integration objects using web standards such as WSDL, XSD, BPEL4WS, etc. And it is built on the robust, scalable, reliable, and powerful architecture of the SAP Web Application Server.

Let's look closely at this idea of interface-based message processing. When we think of interfaces, we generally think about the connection between two systems. In the XI, however, we define the interfaces for a given system independently of the interfaces to which they will eventually be connected. Message Interfaces are platform- and language-independent objects defined in Web Services Description Language (WSDL). Message Interfaces include Message Types and Data Types (both defined in XSD) for maximum reusability. Message Interfaces have two important attributes: mode (synchronous or asynchronous) and direction (inbound or outbound).

To implement an integration scenario, we simply identify the interfaces that participate in the exchange and provide the mapping program(s), which can be generated out of a graphical mapping tool to mediate between the source and target interfaces. If a given interface is to be re-used in another scenario, we need only provide the new mapping program(s). This is what is meant by loose coupling of systems.

Interface objects, including Business Scenarios, Business Processes (more on these later), Message Interfaces, Message Types, Data Types, Message Mappings, and Interface Mappings, are stored in a central repository of design-time objects called the Integration Repository. Part of what makes the XI such an attractive integration platform for SAP customers is that the content of the Integration Repository can, to a large extent, be delivered by SAP and other vendors. This greatly reduces the amount of work that an integration developer has to do; it also insures high-quality content.

Furthermore, while Business Scenarios are used to describe and document the Integration Scenarios implemented through the XI, they can be extended via the integrated Business Process Engine to implement cross-component Business Process Management, or ccBPM. Think "workflow on steroids".

Once the developers have designed the integration scenario, Technical Integrators, working in the so-called Integration Directory, configure the scenario by correlating sender and receiver systems for the defined interface objects. This includes defining the Receiver Determination, in which one or more business systems are selected as the targets of a message (perhaps based on the specific contents of the incoming message); the Interface Determination, in which a target interface is selected (for instance, we might choose, on the SAP side, either a BAPI or an IDOC as the target interface); and Technical Routing, where we create a binding to a specific protocol for a specific destination.

The configuration created in the Integration Directory is executed at runtime by the Integration Server. The Integration Server hosts the XI Pipeline, a sequence of processing services through which all messages are passed (thereby insuring that all messages are processed in a consistent way). When a message is received at the Integration Server, the SOAP header is examined for information on the message sender and interface. Based on these routing keys, all eligible configurations defined in the Integration Directory are executed. The capabilities of the Integration Server include sending to multiple receivers; splitting of a message into multiple messages; content-based routing; and Best Effort, Exactly Once, and Exactly Once In Order message processing (analogous to sRFC, tRFC, and qRFC, respectively). If one of the participants in a scenario is a Business Process, then a workflow is instantiated on the Web Application Server.

The next 'SAP Higher Education' tip will detail the components of the Exchange Infrastructure and describe more fully the process of implementing a scenario in XI.

SAP Education offers training for development and technical integrators who need to learn the Exchange Infrastructure. To learn more about training for the Exchange Infrastructure, check out the SAP Education Web Site. This site is constantly updated with new offerings. To speak to a SAP Education Representative, please contact the SAP Education Help Desk at 1-877-876-7271.


Dig Deeper on SAP Cloud Platform