Академический Документы
Профессиональный Документы
Культура Документы
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
XI 3.0 Runtime
Agenda
XI 3.0 Runtime
Overview and Concepts
Pipeline steps
IS Runtime Cache
XI Message Processing
Integration Server
Application
System A
SOAP-XML
SOAP-XML
Application
System B
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.
Sample XI Message
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.
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
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).
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.
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.
Outbound Binding
Bind a specific destination and protocol to the message.
Call Adapter
Send the transformed message to the adapter or proxy.
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
Config.
cache
Adapter
Framework
XI Message
OK / Error
Adapter
Sender
Module Processor
http://<AdapterEngineURL>
Channel
Q
Integration Builder / Directory:
Adapter
Receiver
E
I
S
Messaging
Configuration
cache
Tracing
Logging
AdapterSpecific
Component
Services
Security
Monitoring
Administration
Configuration
Master
End-to-End Monitoring
(Sender / Receiver Agreement:
Party/Service/Action <-> Channel
Runtime Workbench
Uis for adminstration,
monitoring
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
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
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
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
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.
Flexible
ALV
Views
Legend
bizview
Steps in Pipeline
Compare
versions
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.
XI Integration Server
Receiving System
Sending Application
Receiving Application
Outbound Proxy
Inbound Proxy
Sender
Receiver
Central
Central Integration Engine
HTTP
HTTP
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.
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
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
XI Runtime Cache
z When objects are activated in the Integration Directory, they are cached at the
Integration Server; the cache refresh is automatic.
Transaction SXI_Cache
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.
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.
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.
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.