SAP Exchange Infrastructure (SAP XI): Purpose and Overview

By Binu Joy
July 2005

=============================================================== Page 1 of 14

Table of Contents XI- A Platform for application Integration3 SAP XI: Features & Functions4 SAP XI: Business Benefits.........................6 Overview of Exchange Infrastructure.6 Integration Server (IS) .8 Integration Adapters (IA) 8 Integration Engine9 Integration Builder.10 Integration Repository.10 Integration Directory.................10 System Landscape Directory..11 XI Runtime Environment.11 Central Monitoring and Runtime Workbench.12 Proxy Framework.12 Value Added Web-Services through XI12 Some Examples of Integrated Business Scenario..13

=============================================================== Page 2 of 14

XI..A platform for application integration

Driving integrated business processes across heterogeneous and highly dynamic system landscapes is the daily routine in many enterprises. The frictionless collaboration of SAP applications, legacy, and third-party systems is sustained by SAPs Exchange Infrastructure. Application integration is not merely a technical problem! First of all, it is necessary to address the challenge from a business process perspective. Second, enterprises must recognize the need for a common, cohesive, and standards-based infrastructure. Then the flexibility can be achieved, necessary for long-term success on the application integration front. This is precisely what SAP has done with its new Exchange Infrastructure. Application integration takes place on many layers of the application stack. The Exchange Infrastructure was built from the ground up to capture application semantics at design time, and to ensure that participating applications thoroughly understand these semantics. In many instances, SAP has already captured this information, by delivering shared collaboration knowledge the information that is needed to integrate applications along with the Exchange Infrastructure. New applications, like the recently announced mySAP SRM (Supplier Relationship Management) product, are based on and take advantage of the SAP Exchange Infrastructure in this way. Moreover existing applications like BAPIs, RFCs, and IDocs are supported, and new Web services can be added at any time. Looking forward, new mySAP solutions (e.g., SRM) will be built on the SAP Exchange Infrastructure. In the long term, the Exchange Infrastructure will replace other SAP integration solutions as SAP moves toward offering a single, homogeneous integration solution for all SAP and non-SAP integration challenges. It should be noted that the SAP Exchange Infrastructure can work with other integration solutions as well. For example, integration with MQSeries or other messaging systems is possible via the JMS Adapter, supporting the Java messaging standard. The goal of the Exchange Infrastructure is to provide a single point of integration for all systems, SAP and non-SAP, inside and outside the corporate boundary. Hence SAP XI abandons the point-to-point integration approach, favoring instead a model that features loosely coupled applications communicating via XML/SOAP/HTTP. SAP NetWeaver is the integration and application platform for mySAP solutions wherein XI represents the Process Integration Layer of the NetWeaver stack and is a crucial element of the Enterprise Services Architecture (ESA) as is evident from the following graphic.

=============================================================== Page 3 of 14

The basic idea behind the concept is to provide a runtime infrastructure which allows heterogeneous systems to be tied together with fewer connections and at the same time, in order to connect those applications and let messages flow from one application to the other have a centralized storage of the integration knowledge. XI is open and flexible; it uses web standards such as Web Services Description Language (WSDL), XML Schema Definition Language (XSD), and SOAP Messaging for describing objects and communicating with other system. The SAP applications making use of SAP Exchange Infrastructure involve xApps, MDM, CRM, BI etc. SAP Exchange Infrastructure: Features & Functions SAP Exchange Infrastructure is a robust, high-performance solution. It supports multiple communication approaches - including central hubs and peer-to-peer connections. And it provides the reliability and scalability that private marketplaces and application integration scenarios require. Features & functions include: Standards-based process integration -- SAP Exchange Infrastructure enables the integration of collaborative processes across multiple application components within and beyond enterprise boundaries. Processes are integrated using standards-based XML messaging, and all related information is modeled using Web services standards. Integration knowledge management -- Integration knowledge ranging from design time to configuration time is stored and managed in a central

=============================================================== Page 4 of 14

integration repository and integration directory. This includes information about interface schema, required mappings, business scenarios, and business processes. An integrated toolset lets you maintain, store, and change this information, which is then used to drive the integration of processes at run time. Prepackaged integration content -- SAP solutions based on SAP NetWeaver use SAP Exchange Infrastructure to model cross-component business processes and scenarios. Interface schema and required mappings are defined along the way. The accumulated integration knowledge is provided with SAP solutions through SAP Exchange Infrastructure, and offers standards-based flexibility for integrating solutions in a heterogeneous application landscape. Cross-component business process management -- SAP Exchange Infrastructure drives and controls complex business processes across business applications and enterprise boundaries. It covers the full process life cycle, including design, automation, execution, monitoring, analysis, and optimization. It orchestrates messaging between systems and business partners by using stateful interactions. Cross-component Business Processes (Integration Processes) are executable processes that allow for stateful interactions between loosely-coupled systems. Integration Processes are built sing the web-standard Business Process Execution Language for Web Services (BPEL). Heterogeneous landscape connectivity -- Adapters allow connectivity with all kinds of applications in a heterogeneous landscape. SAP provides a range of adapters with SAP Exchange Infrastructure to integrate not only existing SAP solutions through IDocs and BAPI interfaces, but also non-SAP systems through file, messaging, or Web service interfaces. An adapter framework allows the use of partner adapters to extend connectivity options. B2B integration -- B2B integration requires the ability to maintain partner information and communicate with partners through an agreed protocol. SAP Exchange Infrastructure stores collaboration partner profiles centrally in the integration directory, and communication with partners is based on this data. A partner connectivity kit allows the integration of partners that don't use SAP Exchange Infrastructure or another integration solution. Support for industrystandard protocols such as RosettaNet is provided through an adapter and corresponding mappings. In order to enable B2B scenarios, XI includes security features such as message encryption, digital signatures and non-repudiation. Additionally, the Partner Connectivity Kit allows smaller partners or subsidiaries with no native B2B messaging capabilities to communicate with XI. The Integration directory includes Collaboration Profiles and Collaboration Agreements for enabling B2B communication.

=============================================================== Page 5 of 14

SAP Exchange Infrastructure: Business Benefits SAP Exchange Infrastructure reduces integration complexity by providing an open integration platform that drives collaborative business processes. Business benefits include: Lower total cost of ownership -- SAP Exchange Infrastructure reduces the cost of integration and enables the reuse of existing components. It protects investments by seamlessly integrating components from both SAP and thirdparty vendors. Easy integration of existing processes -- SAP Exchange Infrastructure allows you to integrate processes within and across organizational and technical boundaries. Its integration model reflects SAP's extensive knowledge of business processes and the need to capture and share collaborative knowledge during the entire software life cycle. Easy assembly of new processes -- SAP Exchange Infrastructure offers an integrated tool set to help you assemble existing software in a new way to support new business processes. It provides the messaging interfaces, mappings, and routing rules needed to connect application components or create collaborative processes. Improved process management, automation, and execution -- SAP Exchange Infrastructure can orchestrate the message flow individually for each business process. So you can automate processes according to unique needs across heterogeneous systems and beyond enterprise boundaries. Flexibility to embrace new industry standards -- SAP Exchange Infrastructure supports current industry standards and has built-in flexibility to support future standards. Enhanced life-cycle management -- SAP Exchange Infrastructure supports all the life-cycle management functions of SAP NetWeaver, including versioning, transport management, and user authorization for objects. A consistent approach to all integration tasks -- SAP Exchange Infrastructure can handle all tasks involved in process integration and automation. You have a single tool set to integrate applications and manage business processes that span various application components.

Overview of Exchange Infrastructure The XI is not a single component but rather a collection of components that work together flexibly to implement Integration Scenarios. The architecture includes components to be used at design time, components to be used at configuration time and components to be used at runtime. The implementation of a collaborative process using SAP XI is split into three phases: During the design phase, you document the entire collaborative process and determine which interfaces are required. You can either define new systemindependent interfaces to implement at a later point in time (outside-in development) or work with functions that already exist in the systems (insideout development). In this phase you design the logical collaborative process by describing in a specific role the message exchange between the application

=============================================================== Page 6 of 14

components. This description is still not specific to any particular installed system. During the configuration phase, you configure your collaborative process for a specific system landscape. For example, you define conditions for the message flow and select design objects that meet your requirements. The configuration data is evaluated at runtime and controls communication. You can monitor the message flow by using a central monitoring.

This three-stage process is reflected in the architecture of SAP XI:

Design time and configuration time each have a central data storage point providing an overview of all data that is relevant to the cross-component process: the Integration Repository and the Integration Directory respectively. To edit this data, you use a single tool, the Integration Builder. The content of the Integration Repository and Integration Directory is known as collaboration knowledge. The Integration Server is the central distribution engine for messages in SAP Exchange Infrastructure at runtime. All systems that use SAP Exchange Infrastructure to communicate use this server to exchange messages. These systems are referred to as business systems at a logical level; within a specific system landscape they are called technical systems or communication parties. Using the configuration data from the Integration Directory, the Integration Server decides to which receiver or receivers it must send the message and whether a mapping needs to be executed beforehand.

The graphic that follows shows the components that make up the SAP Exchange Infrastructure as well as some applications that are integrated through the exchange. The applications comprise SAP applications as well as 3rd party applications. The integration is achieved by exchanging XML based message objects through the Integration Server. To adopt different application Systems the Integration Server does comprehensive routing and mapping using specific

=============================================================== Page 7 of 14

integration data out of the Integration Directory and Integration Repository as well as system specific data of the System Landscape Directory. The SAP Exchange Infrastructure consists of the following components: System Landscape Directory Integration Repository Integration Directory Integration Server o Integration Adapters Integration Clients

Applications need the following proxy components to use the SAP Exchange Infrastructure directly and without adapters. Proxy Framework o Proxy Generator o Proxy Runtime

Integration Server (IS)

The Integration Server is the central part of the SAP Exchange Infrastructure. It receives messages from the sender applications and then applies routing and mapping rules to these messages and finally sends them to the receiving application. Each SAP Web Application Server has the Integration Server Software built in but it is the specific configuration that activates its role as a central Integration Server. The Integration client can access the Integration Server using the standard SAP Gui frontend.
Integration Adapters (IA)

Certain Adapters are needed in cases where the Integration Server is to exchange messages with an R/3 system based on a basis kernel lower than 6.20(RFC Adapter, IDoc Adapter) , or in order to connect to a specific market place (depending on the marketplace product).There are no additional adapters needed , when the Integration Server connects to a new mySAP solution which is based on the SAP WAS 6.20,as the components of these solution carry themselves a small Integration Engine-those systems can directly interact and communicate with the Integration Server to exchange XML messages. Integration Adapters are used to convert various protocols and data formats into the Integration Servers XML based message objects and vice versa. The Integration Server comes with some built in adapters but most adapters are additional components.

=============================================================== Page 8 of 14

SAP XI includes the Adapter framework for developing Adapters to non-SAP systems that can be executed by the Adapter Engine. The Adapter framework is a JCACompliant framework for developing connectors to the XI.
Integration Engine

This product is to be used at runtime, at customer site and it relies on the content of the Integration Directory. It is a highly scalable infrastructure for local and central execution of integration logic needed for component integration. The integration infrastructure provides an integrated error-handling and monitoring of integration processes across the entire landscape. As a central and critical functionality in the entire system landscape, integration services need to be highly available and centrally managed. The architecture allows peer to peer connectivity (still centrally controlled) to avoid additional points of failures. Adapter Engine is a Java Connector Architecture compliant (JCA) compliant adaptor engine for connecting backend systems to the XI. The XI Adapter Engine is based on

=============================================================== Page 9 of 14

the integrated J2EE engine of the SAP Web AS; it allows for central configuration and monitoring of all Adapters, even those that are installed de-centrally (close to the backend system).The Adapter Engine includes its own security, message processing and message queuing functionality.
Integration Builder

Its a client-server framework for accessing and editing two stores of shared collaboration knowledge. The Integration Builder is the common tool framework for design and configuration time activities. It allows you to work with objects in both repositories in a consistent way, with a consistent interface and a common look-andfeel. By separating design time activities from configuration time activities, SAP can ship content for the Integration Repository, which each customer can implement for their specific landscape in the Integration directory. The goal is to reduce the problem of developing interfaces to the simpler task of configuring interfaces. It is a Java application. On the client side it provides the user Interface for working with XI objects. On the server side it offers services for authentication, lock management, import and export of Interface objects, internationalization, versioning and change management. Since the client applications (IR and ID) are fat clients, Java Web start is required. JWS is caching application for Java clients (download once and store locally). Integration Builder provides the editors for each object type in the Integration Repository. All XI objects are described using web standards: Web Services Description Language (WSDL) for interfaces, XML Schema Definition Language (XSD) for messages and data types, XPath for slicing and dicing data in XML documents, and Business Process Execution Language (BPEL) for Integration Processes (Business Processes).
Integration Repository (IR)

The Integration Repository provides collaboration knowledge available at design /development time at SAP, partner and customer site, to be shipped along with content. For example: mappings, interfaces, and components. It is built in Java and follows Java 2 Enterprise Edition (J2EE) standards. The information in the Integration Repository is used by the Integration Directory, which adds configuration-specific information that is needed for execution.
Integration Directory (ID)

The Integration Directory contains detailed collaboration knowledge about the current system landscape around the SAP Integration Server. It is a description of routing rules, active services, executable mappings and the specific system landscape. The Integration Directory details the information from the Integration Repository that is specific to the configuration required at the customer site. Its contents are partially derivable from Integration Repository by configuration tools. Once Integration content has been created in the Integration Repository, scenarios are configured in the Integration Directory. In the directory we specify the actual systems that will be exchanging messages and configure the details of the message exchange (security, transport protocol etc.)

=============================================================== Page 10 of 14

With respect to the Integration Client, the Integration Repository and Directory require specific Java client software which is stored on the Integration Server and will be automatically installed on the client side using Java Web Start. This client software can be used during design time to develop new interfaces and mappings and to configure services, routings and mappings.
System Landscape Directory (SLD)

A central repository of information about software and systems in the data centre, It is composed of the Component Repository and the Landscape Directory. The Component Repository includes a description of all SAP Components whereas the Landscape Directory includes a complete description of the actually installed SAP system landscape. SLD describes concrete system landscape of customer installation like what component is actively available on which machine/instance/client etc, information about domain contained, i.e. in which network environment (local/remote) are components accessible, any type of component (SAP, Partner products, other packages, legacy systems.) The SLD is a server application; the XI is technically a client of the SLD. The SLD adheres to the Common Information Model (CIM), a standard proposed by the Distributed Management Task Force (DMTF).The Integration client can access the SLD using a standard internet browser.
XI Runtime Environment

At runtime the Integration Scenarios that have been developed in the Integration Repository and configured in the Integration Directory are executed by the Integration Server. It includes engines for executing Integration Processes (Business Processes), processing messages and connecting to backend systems. At run time, the integration engine is based on the solid architecture of the SAP Web Application Server leveraging the power, scalability and manageability of the platform. SAP XI favors a model that features loosely coupled applications communicating via XML/SOAP/HTTP. A message is received at the Integration Server and is examined by the runtime environment; based on the configuration for the particular message type and content, the message is routed to the appropriate receiver(s),perhaps undergoing a mapping to the partner format along the way. Regarding the functionality of the XI Runtime Environment, 1. It allows both synchronous and asynchronous communication. It also supports retry mechanism and acknowledgement for asynchronous communication, supports error handling. 2. It involves transport of (XML) messages based on HTTP and HTTPS. The SOAP messages with attachments are sent as wire formats, messaging protocol based on SOAP envelope with header extensions.

=============================================================== Page 11 of 14

Central Monitoring and Runtime Workbench:

The central monitoring of SAP XI offers the option of executing various monitoring activities. Runtime Workbench forms an XI component that offers a central monitoring view of all XI components and processes at runtime. In other words, it is the central tool for accessing XI monitoring. It includes Graphical end-to-end monitoring of Integration Scenarios. The Runtime Workbench gives us the option of navigating to the monitoring functions of the Integration Engine, as well as integration with the Computing Center Management System (CCMS), and the Process Monitoring Infrastructure (PMI) of SAP. Central XI monitoring can be used for component monitoring, message monitoring, end-to-end monitoring, performance monitoring, alert configuration and cache monitoring. The Runtime Workbench provides access to all these monitoring activities.
Proxy Framework

The Proxy Framework consists of the Proxy Generator and the Proxy Runtime. The Proxy Framework for ABAP (generator and runtime) is part of the SAP Web Application Server and no specific installation is needed.
Proxy Generator for Java

The Proxy Generator for Java is used to generate proxies (Java Classes) for application programming. It makes use of the Integration Repository which contains all interface definitions.
Java Proxy Runtime

The Proxy Runtime for Java is mandatory for all Java programs to exchange messages with the SAP Integration Server. In doing so the proxy runtime converts the used java classes into XML messages. These XML messages are sent to the Integration Server using http protocol. Value-Added Web Services through XI: The SAP Web Application Server includes native XML messaging capability, and the ability to provide web services based on the SOAP Protocol. Because of the enhancements to the basic SOAP protocol used by the XI, it is possible to implement value-added web services through the XI. XI allows to include additional payloads to a message, and to implement additional functionality through enhanced SOAP headers.

=============================================================== Page 12 of 14

Some examples of integrated business scenarios Consider a simple landscape consisting of two existing R/3 systems, a legacy system (e.g., a homegrown warehouse management system), and a third-party system that handles materials management. 1. Integrating legacy and third-party systems: assume the case of an enterprise that collects inventory changes (e.g., materials movement) with a barcode reader and transfers the data in the format of a data file. Currently, most customers would use an individual, hard-coded piece of software to transform the data from the legacy system into the right format, and then call some routines to provide this information to the third-party system. With the Exchange Infrastructure, the first step is to re-route this file-based communication between the legacy system and the third-party system. To perform this change, it would be necessary to configure the right integration information like mapping, routing, and interfaces in the exchange infrastructure. With this approach, the operater gains central monitoring capabilities on every message that is transferred through the Integration Server. Depending on the effort, put into the existing hard-coded transfer program, the stability of the connection may be increased, since the Exchange Infrastructure provides reliable, exactly-once file transfer. 2. Integrating legacy and R/3 systems: Now that the third-party and legacy systems communicate through the SAP Integration Server, the scope of the Exchange Infrastructure may easily be expanded. Some of the data collected from the materials movement in the warehouse system (legacy) might also be valuable input for an existing R/3 4.6C system. In that case the information can easily be transformed to feed it into the R/3 system. In consequence the complexity of the overall landscape is reduced and the future maintainability is made easier. Whats more, data consistency across systems is improved by distributing the same data to multiple recipients all at once, in contrast to multiple point-to-point connections in several steps over different systems. To extend integration further, adapters allow technical connectivity to database systems or messaging products, and applicationspecific adapters provide connectivity to other packaged software products. Because it adheres to XML and open standards, the Exchange Infrastructure can easily connect to any products that also conform to these same standards. 3. Integrating a new mySAP solution into the landscape: Another scenario is the integration of a new mySAP solution (e.g., SRM) into this landscape. These mySAP solutions will be built on top of the new Exchange Infrastructure, and therefore separate integration-relevant elements from the application code itself. If mySAP SRM is integrated into the landscape specifically, into a business scenario dealing with operational sourcing, the Exchange Infrastructure automatically handles, for example, mapping a demand in one system (e.g. SAP Enterprise Buyer Professional) to the RFQ that must be created in the second system (e.g., the Dynamic Bidding component). The Exchange Infrastructure is designed so that mapping and routing information is not buried within each participating application. It is centrally stored as shared collaboration knowledge, and is therefore easy to be seen, extended, and replaced if necessary with the SAP Exchange Infrastructure. In addressing the challenges of increasingly complex, heterogeneous and often expensive system landscapes, the Exchange Infrastructure offers not only a

=============================================================== Page 13 of 14

powerful integration solution, but also a unique approach to designing new applications to run more easily and efficiently in a heterogeneous world. To summarize, SAP XI addresses integration Challenges as it 1. is an A2A and B2B integration solution 2. is an industry standard support 3. supports the whole process integration lifecycle 4. comes with pre-delivered content 5. is suited for heterogeneous integration landscapes 6. is interoperable based on open standards Also it offers one platform for implementing messaging and integration processes through cross-component BPM.

=============================================================== Page 14 of 14