05 runtime.pdf

8/10/2019 05 Runtime.pdf

1/30


2/30

SAP AG 2004, Runtime

Topics

Lecture topics

XI Overview

System Landscape Director y

Integration Repositor y

Integration Director y

Runtime

Runtime Workbench

Adapter Framewor k

Business Process Management

Server Administration

Security

B2B and Industry Standards


3/30


After completing thi s l esson, you will be able to:Explain basic concepts of XI message processing.

Describe the concept of the Integration Engine andthe Pipeline, and detail the dif ference.

Use the message monitor ing capabili ty of the XI.

Explain the XI-SOAP message format.

Describe the caching capabili ties of the IntegrationServer

Runtime Overview: Objectives


4/30


Agenda

XI 3.0 Runtime

XI 3.0 Runtime

Overview and Concepts

Pipeline steps

IS Runt ime Cache


5/30

The Exchange Infrastructure connects application systems using XML messaging andweb standard protocols.

The XI uses an SAP-specific implementation of the SOAP protocol.

SOAP is a protocol that allows a program running in one system to call a programrunning in another system, even when the platforms and technologies of the systemsare different, using XML messaging sent via HTTP. Because it is based on Webstandards (and is itself a web standard), it allows for communication betweenapplications in an intranet or over the Internet.


XI Message Processing

Appl icationSystem A

SOAP-XML

Integration Server

Appl icationSystem B

SOAP-XML

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 processedthrough a defined series of steps called Pipeline Services.

When a message is received at the Integration Server, themessage is examined and all valid configurations (as maintainedin the Integration Directory) for that message are executed.


6/30

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

The SOAP protocol requires a SOAP Envelope element as the root element of aSOAP message. It defines the XML document as a SOAP message. The SOAPenvelope contains an (optional) SOAP Header and a (required) SOAP Body.

The SOAP Header element contains application specific information (likeauthentication, payment, etc) about the SOAP message. If the Header element ispresent, it must be the first child element of the Envelope element.

The SOAP Body element contains the actual SOAP message intended for the ultimate

endpoint of the message.


Example of basic SOAP document over HTTP


7/30


8/30

The slide shows a sample XI-SOAP message (without the payload). For clarity, thevarious header elements (except the Main header) are collapsed.

You can see that the body contains a Manifest element; this in turn contains a Payloadelement that has a hyperlink (href) to the main document.


Sample XI Message


9/30

Technically, an XI message is sent as a multipart-MIME document. MIME is aninternet standard that allows arbitrary digital content to be sent as text over theinternet.


Technical Structure of an XI Message


10/30

XI Messages are passed through a series of processing steps called the XI Pipeline.

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.

All messages that are received at the Integration Server are processed in a consistentway, with a single set of monitoring and management transactions, regardless of theunderlying platform, technology, or vendor of the application systems involved in themessage exchange.

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 applicationserver to function as a sender or receiver of messages in the native XI-SOAP format(via Proxies).


The XI Pipeline

TargetMessage

TargetMessage

Call Adap ter

Call Adap ter

TechnicalRouting

TechnicalRouting

MessageMapping

MessageMapping

MessageSplit

MessageSplit

InterfaceDetermination

InterfaceDetermination

Receiver Identification

Receiver Identification

SourceMessage

SourceMessage


11/30

The Pipeline is accessed via a URL, behind which is an ICF service. The URL forsending a message to the Pipeline is

http://:/sap/xi/engine?type=entry

The is the hostname of the Integration Server; the port is the HTTP listenerport of the Internet Communication Manager.


Pipeline Entry Point

transactionSICF


12/30

Messages are processed through a set of services, each of which performs a specificoperation on the message.

In this way, different configuration steps can be treated as distinct processes. Thisprovides for the maximum flexibility and maximum reusability of objects.


Important Pipeline Steps

Receiver IdentificationReceiver IdentificationDetermine whichDetermine which system(ssystem(s ) should partic ipate in an exchange with the) should parti cipate in an exchange with theincoming message.incoming message.

Interface DeterminationInterface DeterminationFor each receiver sys tem determine whichFor each receiver sys tem determine which interface(sinterface(s ) should receive a) should receive amessage.message.

Message BranchMessage BranchIf mult iple receivers are found, XI will instantiate a new messaIf mult iple receivers are found, XI will instantiate a new messa ge for eachge for eachreceiver.receiver.

Request Message MappingRequest Message MappingCall the mapping program to transform the message structure to tCall the mapping program to transform the message structure to t he receiverhe receiverformat.format.

Outbound BindingOutbound BindingBind a specific destination and protocol to the message.Bind a specific destination and protocol to t he message.

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


13/30

The Adapter Engine provides connectivity to the XI for non-Web AS Interfaces (3rdparty systems).

The Adapter Engine has built in capabilities for message queueing, tracing, logging. Ituses a different runtime mechanism for sending message than an Integration Server;in other words, the adapter engine can formulate and send an XI-SOAP messagewithout requiring an integration engine.


Configurationcache

Adapter Engine

ISRuntime

Adap ter Sender

Adap ter Receiver

Adapter Engine in SAP J2EE

Q

Adm ini str ation

Security

Monitoring

Adap ter-Specific

Component

Services

TracingLogging

Module Processor EIS

Channel

Messaging

Config.cache

End-to-End Monitor ingMessage flow over all XIcomponents / applications

Runtime Workbench Uis for adminstration,

monitoring

Integration Builder / Directory:

... Receiver determination Party->Service->Action

... Channel Definition: Adapter Engine Adapter Type Message Protocol Transport Protocol Security Channel Config uration

(Sender / Receiver Agreement: Party/Service/Action Channel

ConfigurationMaster

System Landscape Directory Holds component description

includin g address data

Adapter Framework

Integration Repository Holds Adapter metadata

Integration Repository Holds Adapter metadata

http://

XI Message

http://

OK / Error


14/30


XI 3.0 Runtime

Agenda

XI 3.0 Runtime


Pipeline steps

IS Runt ime Cache


15/30

The SAP Web Application Server (version 6.20 or higher) has a built-in IntegrationEngine to enable communication with the Integration Server in the native XI-SOAPformat. This enables out-of-the-box integration of SAP applications via proxies.

The Integration Engine must perform different actions in different roles; differentpipeline services are executed depending on the IE role.

Different pipelines with different service chains are defined corresponding to thedifferent IE roles.


Pipeline Definition

Sender

Central

Receiver


16/30

Pipeline services reference ABAP Objects that perform the individual messagehandling steps that route and transform messages.

The pipeline services for a particular pipeline (Central, Sender, Receiver, etc.) arefixed and cannot be changed by the customer.


Pipeline Services


17/30


18/30

You can monitor the messages that have been processed through the pipeline intransaction SXI_MONITOR. This transaction can also be accessed by startingtransaction SXMB_MONI and choosing Monitor fo r Processed XML Messages.

Enter selection criteria, such as the Date/Time the message was processed, theSender or Receiver information, or the message status and choose Execute (F8). Youcan also specify advanced selection criteria.

After entering appropriate selection criteria from the main screen, you will see a list ofall messages that match the criteria.


Transaction SXI_Monitor

Two selection screens(Standard/Advanced)

Selection on:Status GroupStatusExecution FromExecution ToParty/Scheme/Agency/Service (S/R)Interface Name/Namespace (S/R)

PipelineTechnical Inbound ChannelOutbound StatusError Client


19/30

From the list browsing to the following tools is possible:

Display of the Error Information

Idoc/RFC Adapter Monitor

Monitor of Business Process Engine

qRFC Monitor

Detail view of messages for the message itself, its parent, and its original message (in case of anacknowledgment message)

Additionally, the following actions can be invoked:

Restart of a message after an error

Acknowledge an error


XML Message List

Flexible ALVViews Legend


20/30

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

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


Changing the Layout

tecview

bizview

Messages are displayed in an ALV Grid Control.Different layouts are possible:

Default: All attributes of a message are displayedTechnical View: Only the technical attributes are displayedBusiness View: Business-oriented attributes are displayed Acknowledgment View: At tributes important for acknowledgments

are displayed


21/30


22/30

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).

Synchronous messages are not persisted on the Integration Server unless logging isswitched on.


Receiver Local Integration Engine

Message Handling: Synchronous Processing

Synchronous Processing (QoS = BestEffort)

Blocking call of sending application (incl. DB commit)

No message persistance (logging needs to be swiched on)

Sending System XI Integration Server

Sending Appli cation

Outbound Proxy

CentralCentral Integration Engine

HTTP

Receiving System

Sender Local Integration Engine

Receiving Appl ication

Inbound Proxy

HTTP


23/30

Asynchronous messages are queued for processing by the Integration Engine (local orcentral).

Asynchronous messages are processed with Quality of Service Exactly Once(equivalent to tRFC) or Exactly Once In Order (equivalent to qRFC).

Asynchronous messages are persisted on the Integration Server and can be re-sent ifthere is a problem with the initial send.

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.


Message Handling: Asynchronous Processing

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

XIqRFC

Sender qRFC qRFC

Receiver Local Integration

Engine

Sending System XI Integration Server

Sending Application

Outbound Proxy

CentralCentral Integration

Engine

HTTP

Receiving System

Receiving Appl ication

Inbound Proxy

HTTP

XI XI

Local IntegrationEngine

XI processing is asynchronously decoupled (scheduled in qRFC)Hop-to-Hop exactly once protocol -> messages are persisted in databaseEOIO serialization by qRFC queues (no serialization number!)


24/30


XI 3.0 Runtime

Agenda

XI 3.0 Runtime


Pipeline steps

IS Runt ime Cache


25/30

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


XI Runtime Cache

Configuration Settings are cached at theIntegration Server to improve performance.

Cached objects include:Parties

ServicesReceiver Determination

Interface DeterminationSender/Receiver AgreementCommunication Channel

MappingsSoftware ComponentsBusiness Process


26/30

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


Transaction SXI_Cache


27/30


28/30

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.


Adapter Engine Cache

To view the cached addresses of all Adapter Enginesthat are registered at the Integration Server, choose

Goto AE Cache

from the main menu in transaction SXI_CACHE.


29/30

In order to render IDOC-XML from the IDOC, or the IDOC from IDOC-XML, the IDOCadapter must have access to the metadata underneath the IDOC definition. Since theIDOC metadata is stored in the application system, the Integration Server mustretrieve this data via an RFC callback. Transaction IDX1 is used to configure a port touse for retrieving this data.

To improve performance, the IDOC metadata is cached at the Integration Server. TheIDOC cache can be viewed in transaction IDX2.

If the IDOC definition changes in the application system, the metadata must be deletedfrom the cache in IDX2; this can be done by selecting the appropriate system from thelist, drilling down to the affected IDOC type, and choosing Delete.

The next time an IDOC is sent or received, the cache will be refreshed.


IDOC Adapter Cache

TransactionIDX2


30/30


You should now be able to:

Explain basic concepts of XI message processing.

Describe the concept of the Integration Engine andthe Pipeline, and detail the dif ference.

Use the message monitoring capabili ty of the XI.

Explain the XI-SOAP message format.

Describe the caching capabili ties of the Integration

Server

XI Runtime 3.0: Summary

05 runtime.pdf

Documents