SAP Exchange

Infrastructure

Runtime

Lecture topics

Topics
XI Overview
System Landscape Directory
Integration Repository
Integration Directory
Runtime
Runtime Workbench
Adapter Framework
Business Process Management
Server Administration
Security
B2B and Industry Standards

SAP AG 2004, Runtime

Runtime Overview: Objectives

After completing this lesson, you will be able to:

z Explain basic concepts of XI message processing.
z Describe the concept of the Integration Engine and
the Pipeline, and detail the difference.
z Use the message monitoring capability of the XI.
z Explain the XI-SOAP message format.
z Describe the caching capabilities of the Integration
Server

SAP AG 2004, Runtime

XI 3.0 Runtime

Agenda
XI 3.0 Runtime
Overview and Concepts
Pipeline steps
IS Runtime Cache

SAP AG 2004, Runtime

XI Message Processing
Integration Server
Application
System A

SOAP-XML

SOAP-XML

Application
System B

XI connects various application systems via XML messaging.

XI uses an SAP-specific implementation of the SOAP protocol.
Messages received at the Integration Server are processed
through a defined series of steps called Pipeline Services.
When a message is received at the Integration Server, the
message is examined and all valid configurations (as maintained
in the Integration Directory) for that message are executed.

SAP AG 2004, Runtime

z The Exchange Infrastructure connects application systems using XML messaging and
web standard protocols.
z The XI uses an SAP-specific implementation of the SOAP protocol.
z SOAP is a protocol that allows a program running in one system to call a program
running in another system, even when the platforms and technologies of the systems
are different, using XML messaging sent via HTTP. Because it is based on Web
standards (and is itself a web standard), it allows for communication between
applications in an intranet or over the Internet.

Example of basic SOAP document over HTTP

SAP AG 2004, Runtime

z A SOAP message is sent in the body of an HTTP Post request.

z The SOAP protocol requires a SOAP Envelope element as the root element of a
SOAP message. It defines the XML document as a SOAP message. The SOAP
envelope contains an (optional) SOAP Header and a (required) SOAP Body.
z The SOAP Header element contains application specific information (like
authentication, payment, etc) about the SOAP message. If the Header element is
present, it must be the first child element of the Envelope element.
z The SOAP Body element contains the actual SOAP message intended for the ultimate
endpoint of the message.

XI Message format: SOAP with attachments

SAP AG 2004, Runtime

z SAP XI uses an SAP-specific implementation of the SOAP protocol: SOAP with

header extensions and Payload(s). By extending the SOAP standard, XI is able to
enhance the basic capabilities of Web Services to include additional, value-added
functionality.
z In this implementation, there are extensions to the basic SOAP Header, such as an
Error Header or Hop List that allow XI to augment the basic functionality offered by
vanilla SOAP systems.
z The SOAP body of an XI message contains only a Manifest element, which points to
the actual document being sent.
z The Main Payload contains the Business Data that is being sent; there are other
payloads as well, such as a trace document that traces the processing of the
message, and optional payloads for sending additional data (if needed).

Sample XI Message

SAP AG 2004, Runtime

z The slide shows a sample XI-SOAP message (without the payload). For clarity, the
various header elements (except the Main header) are collapsed.
z You can see that the body contains a Manifest element; this in turn contains a Payload
element that has a hyperlink (href) to the main document.

Technical Structure of an XI Message

SAP AG 2004, Runtime

z Technically, an XI message is sent as a multipart-MIME document. MIME is an

internet standard that allows arbitrary digital content to be sent as text over the
internet.

The XI Pipeline

Source
Source
Message
Message

Receiver
Receiver
Identification
Identification

Interface
Interface
Determination
Determination

Message
Message
Split
Split

Message
Message
Mapping
Mapping

Technical
Technical
Routing
Routing

Call
Call
Adapter
Adapter

Target
Target
Message
Message

SAP AG 2004, Runtime

z XI Messages are passed through a series of processing steps called the XI Pipeline.
z An XI pipeline is a configured series of Pipeline Services; A Pipeline Service is an
ABAP Objects class that performs a particular processing step on a message.
z All messages that are received at the Integration Server are processed in a consistent
way, with a single set of monitoring and management transactions, regardless of the
underlying platform, technology, or vendor of the application systems involved in the
message exchange.
z mySAP applications based on SAP Web Application Server version 6.20 or higher
have their own local instance of the Integration Engine. This allows the application
server to function as a sender or receiver of messages in the native XI-SOAP format
(via Proxies).

Pipeline Entry Point

transaction
SICF
SAP AG 2004, Runtime

z The Pipeline is accessed via a URL, behind which is an ICF service. The URL for
sending a message to the Pipeline is
http://<host>:<port>/sap/xi/engine?type=entry
z The <host> is the hostname of the Integration Server; the port is the HTTP listener
port of the Internet Communication Manager.

Important Pipeline Steps

Receiver Identification
Determine which system(s)
system(s) should participate in an exchange with the
incoming message.

Interface Determination
For each receiver system determine which interface(s)
interface(s) should receive a
message.

Message Branch
If multiple receivers are found, XI will instantiate a new message
message for each
receiver.

Request Message Mapping

Call the mapping program to transform the message structure to the
the receiver
format.

Outbound Binding
Bind a specific destination and protocol to the message.

Call Adapter
Send the transformed message to the adapter or proxy.

SAP AG 2004, Runtime

z Messages are processed through a set of services, each of which performs a specific
operation on the message.
z In this way, different configuration steps can be treated as distinct processes. This
provides for the maximum flexibility and maximum reusability of objects.

Adapter Engine
http://<IntegrationServerURL>

IS
Runtime

System Landscape Directory

Holds component description
including address data

Config.
cache

Adapter
Framework

XI Message
OK / Error

Adapter Engine in SAP J2EE

Integration
IntegrationRepository
Repository
Holds
Holds Adapter
Adaptermetadata
metadata

Adapter
Sender

Module Processor

http://<AdapterEngineURL>
Channel

Q
Integration Builder / Directory:

Adapter
Receiver

E
I
S

Messaging

... Receiver determination

Party->Service->Action

Configuration
cache

... Channel Definition:

Adapter Engine
Adapter Type
Message Protocol
Transport Protocol
Security
Channel Configuration

Tracing
Logging

AdapterSpecific
Component
Services

Security
Monitoring

Administration

Configuration
Master

End-to-End Monitoring
(Sender / Receiver Agreement:
Party/Service/Action <-> Channel

Message flow over all XI

components / applications

Runtime Workbench
Uis for adminstration,
monitoring

SAP AG 2004, Runtime

z The Adapter Engine provides connectivity to the XI for non-Web AS Interfaces (3rd
party systems).
z The Adapter Engine has built in capabilities for message queueing, tracing, logging. It
uses a different runtime mechanism for sending message than an Integration Server;
in other words, the adapter engine can formulate and send an XI-SOAP message
without requiring an integration engine.

XI 3.0 Runtime

Agenda
XI 3.0 Runtime
Overview and Concepts
Pipeline steps
IS Runtime Cache

SAP AG 2004, Runtime

Pipeline Definition

Sender
Central
Receiver
SAP AG 2004, Runtime

z The SAP Web Application Server (version 6.20 or higher) has a built-in Integration
Engine to enable communication with the Integration Server in the native XI-SOAP
format. This enables out-of-the-box integration of SAP applications via proxies.
z The Integration Engine must perform different actions in different roles; different
pipeline services are executed depending on the IE role.
z Different pipelines with different service chains are defined corresponding to the
different IE roles.

Pipeline Services

SAP AG 2004, Runtime

z Pipeline services reference ABAP Objects that perform the individual message
handling steps that route and transform messages.
z The pipeline services for a particular pipeline (Central, Sender, Receiver, etc.) are
fixed and cannot be changed by the customer.

Pipeline Processing

Message
Received in
the Pipeline

Message
After
Receiver
Identification

SAP AG 2004, Runtime

z When a message is received at the Integration Server, the XI runtime examines the
SOAP header. The three fields Sender (Party or Service), Sender Interface, and
Sender Interface Namespace must have values in them, or the pipeline will put the
message in an error state and persist it for monitoring.
z These three fields are keys for the routing configuration. The Integration Server uses
these to find all valid configurations (from the Integration Directory) for the message.
z As each pipeline service is executed, the message is altered; the header is altered for
all steps, and in message mapping the payload itself is altered to the message format
of the receiving application. For instance, In Receiver Identification, A Party or
Service header element is added (containing the name of the Receiver); in Interface
Determination, an Interface element with a namespace attribute is added and
populated.

Transaction SXI_Monitor

Two selection screens

(Standard/Advanced)
Selection on:
z Status Group
z Status
z Execution From
z Execution To
z Party/Scheme/Agency/Service (S/R)
z Interface Name/Namespace (S/R)
z Pipeline
z Technical Inbound Channel
z Outbound Status
z Error
z Client

SAP AG 2004, Runtime

z You can monitor the messages that have been processed through the pipeline in
transaction SXI_MONITOR. This transaction can also be accessed by starting
transaction SXMB_MONI and choosing Monitor for Processed XML Messages.
z Enter selection criteria, such as the Date/Time the message was processed, the
Sender or Receiver information, or the message status and choose Execute (F8). You
can also specify advanced selection criteria.
z After entering appropriate selection criteria from the main screen, you will see a list of
all messages that match the criteria.

XML Message List

Flexible
ALV
Views

Legend

SAP AG 2004, Runtime

z From the list browsing to the following tools is possible:

y Display of the Error Information
y Idoc/RFC Adapter Monitor
y Monitor of Business Process Engine
y qRFC Monitor
y Detail view of messages for the message itself, its parent, and its original message (in case of an
acknowledgment message)

z Additionally, the following actions can be invoked:

y Restart of a message after an error
y Acknowledge an error

Changing the Layout

tecview

Messages are displayed in an ALV Grid Control.

Different layouts are possible:
Default: All attributes of a message are displayed
Technical View: Only the technical attributes are displayed
Business View: Business-oriented attributes are displayed
Acknowledgment View: Attributes important for acknowledgments
are displayed

bizview

SAP AG 2004, Runtime

z It is also possible to create customized, user-specific views

z You can select which view is the default view for your user.

Display Message Contents

Steps in Pipeline

Display and download of the content

Compare
versions

SAP AG 2004, Runtime

z From the XML message list, you can select and view the contents (header and
payload[s]) of a message.
z Each pipeline processing step is shown on the left-hand side of the screen; for each
processing step, the message parts are listed in drill-down. Placing a message (part)
in a window shows the state of the message after the selected pipeline step has run.
z All versions of the selected message are shown in the detail view; there are two
windows arranged one atop the other that let you view two message parts, or two
versions of the same part, simultaneously.
z This allows you to track exactly how a message changed as it passed through the
various pipeline processing steps.
z If the message is in an error state, an error message will pinpoint exactly where the
message processing failed.

Message Handling: Synchronous Processing

Synchronous Processing (QoS = BestEffort)

Sending System

XI Integration Server

Receiving System

Sending Application

Receiving Application

Outbound Proxy

Inbound Proxy

Sender

Receiver

Central
Central Integration Engine

Local Integration Engine

HTTP

Local Integration Engine

HTTP

Blocking call of sending application (incl. DB commit)

No message persistance (logging needs to be swiched on)

SAP AG 2004, Runtime

z Synchronous messages are flagged with Quality of Service Best Effort; in this case,
further processing in the sending application is blocked until a response is received
(just like RFC).
z Synchronous messages are not persisted on the Integration Server unless logging is
switched on.

Message Handling: Asynchronous Processing

Asynchronous Processing
(QoS = Exactly Once/Exactly Once In Order)
Sending System

XI Integration Server

Receiving System

Sending Application

Receiving Application

Outbound Proxy

XI

qRFC

Inbound Proxy

XI

Sender

XI

qRFC

Receiver

Central

Local Integration
Engine

Central Integration
Engine
HTTP

qRFC
Local Integration
Engine

HTTP

XI processing is asynchronously decoupled (scheduled in qRFC)

Hop-to-Hop exactly once protocol -> messages are persisted in database
EOIO serialization by qRFC queues (no serialization number!)

SAP AG 2004, Runtime

z Asynchronous messages are queued for processing by the Integration Engine (local or
central).
z Asynchronous messages are processed with Quality of Service Exactly Once
(equivalent to tRFC) or Exactly Once In Order (equivalent to qRFC).
z Asynchronous messages are persisted on the Integration Server and can be re-sent if
there is a problem with the initial send.
z In order to keep the DB tables from filling up, periodic delete jobs must be run
(possibly in conjunction with Archiving) to remove asynchronous messages.

XI 3.0 Runtime

Agenda
XI 3.0 Runtime
Overview and Concepts
Pipeline steps
IS Runtime Cache

SAP AG 2004, Runtime

XI Runtime Cache

Configuration Settings are cached at the

Integration Server to improve performance.
Cached objects include:
Parties
Services
Receiver Determination
Interface Determination
Sender/Receiver Agreement
Communication Channel
Mappings
Software Components
Business Process

SAP AG 2004, Runtime

z When objects are activated in the Integration Directory, they are cached at the
Integration Server; the cache refresh is automatic.

Transaction SXI_Cache

SAP AG 2004, Runtime

z You can view all cached objects by running transaction SXI_CACHE. Here you can
see whether the cache is up-to-date or not. You can view all cached data and start a
manual cache refresh from here.

Manual Cache Refresh

SAP AG 2004, Runtime

z If you suspect that a change in the Integration Directory has not be replicated to the
runtime cache, you can refresh the cache manually. To refresh the cache in
SXI_CACHE, from the menu choose XI Runtime Cache.
z You can refresh your view of the runtime cache by selecting Refresh Display. If the
transaction screen has been open for some time, the view of the cache may be
obsolete, and the objects may already be in cache.
z You can start a complete or a delta cache refresh. You can also view any errors that
occur during cache refresh.

Adapter Engine Cache

To view the cached addresses of all Adapter Engines

that are registered at the Integration Server, choose
Goto AE Cache
from the main menu in transaction SXI_CACHE.
SAP AG 2004, Runtime

z The Adapter Engine cache holds information (e.g., the name and URL) of all registered
Adapter Engines. This allows for fast address resolution on adapter calls.

IDOC Adapter Cache

Transaction
IDX2
SAP AG 2004, Runtime

z In order to render IDOC-XML from the IDOC, or the IDOC from IDOC-XML, the IDOC
adapter must have access to the metadata underneath the IDOC definition. Since the
IDOC metadata is stored in the application system, the Integration Server must
retrieve this data via an RFC callback. Transaction IDX1 is used to configure a port to
use for retrieving this data.
z To improve performance, the IDOC metadata is cached at the Integration Server. The
IDOC cache can be viewed in transaction IDX2.
z If the IDOC definition changes in the application system, the metadata must be deleted
from the cache in IDX2; this can be done by selecting the appropriate system from the
list, drilling down to the affected IDOC type, and choosing Delete.
z The next time an IDOC is sent or received, the cache will be refreshed.

XI Runtime 3.0: Summary

You should now be able to:

z Explain basic concepts of XI message processing.
z Describe the concept of the Integration Engine and
the Pipeline, and detail the difference.
z Use the message monitoring capability of the XI.
z Explain the XI-SOAP message format.
z Describe the caching capabilities of the Integration
Server

SAP AG 2004, Runtime