11). SAP XI ---Security

Why Is Security Necessary?

1.Business processes executed using XI have to be done
in a secure manner. XML messages which contain
confidential business data need to be transported over
a secure connection

2.Security requirements also apply to communicating XI
components- securing information like user names and
passwords.

3.The messaging system has to be sited securely in the
network environment.


􀂄 As the central infrastructure for exchanging business documents, XI has to make
sure that business processes can be executed in a secure manner. Particular
security requirements have to be considered if business partners communicate
over the Internet.
􀂄 XML messages may contain confidential business data. In order to protect them
against eavesdropping and unauthorized access, the communication lines as well
as the storage locations of XML messages need to be made secure.
􀂄 In addition to the business data exchanged using XI, the various components of XI
need to communicate with each other on a technical level in order to keep the
infrastructure running. Security requirements apply to these technical
communications as well, because confidential information such as user names
and passwords may have to be sent or stored or both.
􀂄 The XI must be sited in a secure location, and protected properly on the network.
Sensitive information is stored on the XI and it must not be accessible to
unauthorized access.

Security is everybody’s concern – not just the Systems Administrator. Every IT
professional who comes in contact with the SAP Exchange Infrastructure has a
responsibility to understand the security mechanisms built into the system, and to
insure that they are implemented completely and correctly


All components of XI 3.0 that run on the SAP
Web AS use the underlying infrastructure
provided by the Web AS for the following:
􀂄User management
􀂄Administration
􀂄Authorizations
􀂄Authentication
(The only exception is for the J2SE adapters)


􀂄 For all components of the SAP Exchange Infrastructure that run on the SAP Web
AS, the solutions of the underlying SAP Web AS are used for user management,
administration, authorizations and authentication.
􀂄 An exception to this rule are the J2SE-based adapters which lack the SAP Web
AS infrastructure


User Administration And Authentication

User Store:

􀂄 Standard: Users are maintained in the ABAP user store
􀂄 Can also be integrated with LDAP based user administration

Certificate Store:

􀂄 XI and RNIF protocols support message level security based
on digital signature
􀂄 RNIF protocol also supports encryption
􀂄 The required certificates to be used need to be entered into
the key store of the J2EE engine
􀂄 In the Integration Directory these certificates are referred by
the name of the key store view and the certificate name
􀂄 Recommended to store CA certificates in the TrustedCAs view


􀂄 Each XI component that resides on an SAP Web AS refers to the user
management of the ABAP part of this SAP Web AS. XI Java applications running
on an SAP Web AS authenticate against the users maintained in the ABAP part. If
required, it can be integrated with an LDAP-based user administration. This
applies to both service users and dialog users.
􀂄 The XI and RNIF protocols support message level security by digital signature and
encryption. Message-level security processing is generally done in the Java part
of the SAP Web Application Server (AS). Therefore, the certificates as well as the
CA certificates to be used need to be entered into the key store of the J2EE
Engine that executes the security handling at runtime. In the Integration Builder:
Configuration, these certificates can be referred to by stating the name of the key
store view and the name of the entry for that certificate.
􀂄 SAP recommends that you store CA certificates in the TrustedCAs view. This
allows you to equip service users who send messages with less authorization than
would be necessary otherwise.


Users

With respect to authentication and authorization, we distinguish two
major scenarios:

􀁺 During design and configuration, dialog users communicate
through the Integration Builder with XI.
􀁺At runtime the actors are computer systems rather than humans!

􀂄 Each system is represented by a dedicated service user. All users are SAP
standard users.


Dialog Users


>>Dialog users represent human users that log
on through the various UIs of the Integration
Builder
>>Dialog users are generally maintained in the
ABAP part of the SAP Web AS
>>The roles for the different dialog users are
predefined and shipped with the installation


􀂄 Dialog users represent human users (as opposed to service users) that log on
through the various UIs of the Integration Builder. As with service users, dialog
users are generally maintained in the ABAP part of the SAP Web AS.


Service Users:


>Service users provide dialog free access to XI components
>Service users have the SAP user roles on the ABAP part of the Web
Application Server
>They are made available on the J2EE part as user groups
>>Service users have the required authorizations to access the required
services on the addressed XI components
>>Service users are created during installation
>>Names and passwords can be assigned
during installation


􀂄 Within the Exchange Infrastructure the roles provide you with all the authorizations
required by the respective component for dialog-free access to the other
components of the Exchange Infrastructure. They are therefore also available on
the J2EE side. For accessing the J2EE components, corresponding authorization
assignments (security roles) on the J2EE server are required. These are
automatically performed when the J2EE components are deployed.
􀂄 For the installation, the password XIPASS is specified for these users. Do not
change this password. If you make changes, you have to make them in
transaction SU01 first and then again in the exchange profile.
􀂄 For all J2EE applications (in other words, the Integration Repository, Integration
Directory, Runtime Workbench, System Landscape Directory, and sender Java
applications), password changes to any of the above users will not take effect until
the system is restarted.
􀂄 For sender ABAP applications, any password changes must also be made in the
involved HTTP destinations.


Service Users During Design And Configuration:

􀂄 XIREPUSER – Access the XI Repository for Design
􀂄 XIDIRUSER – Access the XI Directory for Configuration
􀂄 XIISUSER - Get Cache-updates from XI Directory to RuntimeCache
􀂄 XILDUSER - Get Business System Name from System Landscape Directory


􀂄 All these service users are created during the XI installation
􀂄 All these service users must be available on the xi server client during DESIGN
AND CONFIGURATION (TA: SU01)
􀂄 All these service users and passwords are stored in the exchange profile, too.
(http://./exchangeProfile)


XI Service Users In Use During Runtime:


􀂄XILDUSER – Get Business System Name from System Landscape Directory
􀂄XIRWBUSER – Get monitoring information to Runtime Workbench
􀂄XIISUSER – Get Cache-updates from XI Directory to Runtime Cache
􀂄XIAPPLUSER – Access XI Engines for message processing (SAP template)
􀂄XIAFUSER – Access Adapter Framework


XI Server:

􀂄 All these service users are created during the XI installation
􀂄 All these service users must be available on the xi server client during runtime
(TA: SU01)
􀂄 All these service users and passwords are stored in the exchange profile, too.
(http://./exchangeProfile)
􀂄 For application systems based on Web AS version 6.20 or higher with a local XI
engine, the following users must be maintained:
􀂋XILDUSER must be maintained in transaction SLDAPICUST to connect to System Landscape
Directory to read own Business system name
􀂋XIAPPLUSER (or equivalent with correct role) must be maintained to receive messages.


Default Service Users In XI Systems And Their Roles:

􀂄Created automatically at installation time.
􀂄 Referenced in the Exchange Profile.
􀂄 In the future it will be possible to create custom UserIDs at
installation time
must have the role: SAP_XI_IR_SERV_USER
must have the role: SAP_XI_ID_SERV_USER
must have the role: SAP_XI_APPL_SERV_USER
must have the role: SAP_XI_IS_SERV_USER
must have the role: SAP_XI_RWB_SERV_USER
must have the role: SAP_XI_AF_SERV_USER_MAIN
must have the role: SAP_BC_AI_LANDSCAPE_DB_RFC


User Maintenance:

􀂄 Users and roles are maintained via the standard Web AS
ABAP user management (SU01)
􀂄 After a short delay, the updated users are automatically
replicated to the J2EE engine


J2EE User maintenance
􀂄 in Visual Administrator tool 􀃆 Security provider
service
􀂄 UME (User Management Engine) available as part of
J2EE engine


􀂄 For example, if you want a user MILLER to be entitled to define interfaces, you
have to create this user on the ABAP part of the SAP Web Application Server (AS)
on which the Integration Repository is deployed, and assign the role
SAP_XI_DEVELOPER to this user. After logging on to the Integration Builder
(which is implemented in Java), the J2EE part of the SAP Web AS authenticates
user MILLER against the ABAP part.
􀂄 Users for the Java stack can be maintained either in the J2EE Visual
Administration tool (maintain the security provider service) or in the User
Management Engine (UME), an integral part of the SAP Web Application Server
(J2EE engine).

10). SAP XI --- Server Administration

XI 3.0 components in SAP Web AS 6.40:
􀂄 The XI takes advantage of both the Java and ABAP stacks of the SAP Web Application Server.
Components that reside on the J2EE engine include the Integration Builder (Integration Repository,
Integration Directory), the Runtime Workbench, the Mapping Runtime, and the Adapter Engine.
􀂄 The Integration Engine is implemented in ABAP Objects. This provides a robust, flexible, scalable,
manageable, and powerful engine for message exchange.
􀂄 This course is not intended for administrators; in this unit we will take a very high-level view of
administrative tasks and responsibilities in the XI. We will focus on tracing and logging settings
particularly, as these are important to developers as well as administrators.


Web AS 6.40 - key architecture points:

J2EE stack
􀂄SQLJ layer for database connectivity
􀂄All objects stored in database
􀂄SLD is delivered with the J2EE Engine
􀂄UME for user management
Middleware
􀂄JRFC replaces JCo for J2EE to ABAP connectivity
ABAP stack
􀂄Integration Engine is part of BASIS (and corresponding sup.


􀂄 Many XI components are integral components of the SAP Web Application Server version 6.40.
􀂄 The SAP Web AS has both Java and ABAP components, plus integrated middleware to facilitate
communication between the two.
􀂄 Java components that are particularly relevant to the XI include the SQLJ layer; SQLJ is a standard for
using Java and SQL together. It has been developed by a consortium of companies comprising IBM,
Informix, Microsoft, Sun, Sybase and Oracle.
􀂄 Another Java component that is particularly relevant to XI is the SLD, which is now an integral part of the
Web AS.
􀂄 On the ABAP side, the Integration Engine is an integral part of the Web AS; it is configured as a “Central
Integration Engine” in an XI system, and an “Application System” in a mySAP solution based on the Web
AS.


Integration Engine Administration:
Administration:
•Tuning capabilities for queues:
• Special queue for large
messages
• Balancing between parallel
queues
•Schedule Jobs

Configuration:
•Time-controlled message
processing
•“Switch procedure“ for
message deletion
•Pipeline Definition/Settings.


􀂄 Many administration tasks in the XI are performed from transaction SXMB_ADM; this transaction
contains launchers to access administrative functionality.
􀂄 There are two branches in the transaction: Administration and Configuration.
􀂄 Administrative tasks include managing and tuning the queues for message processing; scheduling
archiving and delete jobs; and making error analysis settings (increasing the debug/trace level for certain
interfaces).
􀂄 Configuration includes settings for time-controlled message processing (message sending can be triggered
by a background job), configuring the integration engine and the pipeline, controlling the method for
deleting messages (messages build up in the database and must be deleted regularly; XI 3.0 introduces a
new, faster, “switch” method for deleting messages, and the administrator can choose which method to
use), and setting the retention periods and interfaces for message archiving.


J2EE Engine – Administration overview:

􀂄 The SAP J2EE engine must be configured, managed, and tuned.
􀂄 There are three tools for configuring the J2EE environment of the SAP Web AS; the offline configuration
editor, the configuration tool, and the J2EE Administrator; of the three, the Administrator is used most
often.
􀂄 SAP J2EE engines hosts various services that are used by the XI (for instance, a common logging service).
The J2EE Engine Administrator interface provides a common framework for configuring the services that
are used by the XI.


Tracing and Logging

􀂄 J2EE-based components of XI use standard logging of J2EE Engine
􀂄 Setup via Log Configurator Service in Visual Administrator tool.


􀂄 Using the Log Configurator Service runtime available in the Visual Administrator, you can manage the logging and tracing
configurations of the J2EE Engine components of the XI. To ease the configuration process, two configuration modes are
provided – simple and advanced. Using both modes you can:
􀁹 add, edit and remove log formatters, log destinations, and log controllers.
􀁹 change states of controllers
􀁹 archive logs
􀂄 The Log Viewer provides a runtime control for displaying log messages. These messages assist you to monitor for problems and
search through messages to diagnose problems. It also helps you to tune attributes of applications to optimize processing time, use
of resources, etc.
>>The Log Viewer does the following:

􀁹 Displays application and system logs. The messages in log files provide hints to the cause of problematic application behavior.
􀁹 Displays different logs side by side
􀁹 Gives insight into system problems
􀁹 Helps with debugging
􀁹 Improves performance by providing insights into the inner workings of applications
􀁹 Displays information in a useful form, because Log Viewer understands the information in a log
􀁹 Brings logs together from the J2EE server and related systems in one place (Integrated Log Viewer)
􀁹 Searches logs. You can run a query across many logs with a specific severity level selected, while searching for information in
specific logs.
􀁹 Merges logs that have compatible sequence information across servers, based on time stamps in each record
􀁹 Allows control of the amount of log data created with log severity thresholds
􀁹 Creates CCMS templates so that the logs can be monitored in an SAP system. Alerts are then generated in the CCMS.
􀁹 Can add logs from client and server machines for viewing
􀁹 The SAT logs show execution times for user transactions. The SQL trace provides details on the database interactions through
the OpenSQL interface.


Standalone Log Viewer UI:

􀂄 Connect to any number of WebAS servers (ABAP/J2EE).

􀂄 The standalone version of the Log Viewer server provides the ability to monitor logs in the system when the J2EE engine is not running properly, does not start up at all, or is not available on the system to
monitored.
􀂄 The standalone installation file is located under the J2EE server admin directory and includes both a Log Viewer Server and Client. The client can connect the user to the Log Viewer service via the P4 port on the
J2EE engine, or via the RMI port to the standalone Log Viewer server. Once installed, the client is run using a batch file.


Integrated Log Viewer UI:

􀂄 Accessible via J2EE Visual Administrator tool.

􀂄 The Integrated Log Viewer runs in the SAP Web AS Java. Each time a new log is created the log server is
informed. The Log Viewer client accesses the logs available on the SAP Web AS Java. No separate
configuration is required.


Trace and Log Files for the XI J2EE components:

Under /cluster/server0/log/applications/com.sap.xi

􀂄 Trace and log files are essential for analyzing problems. They are offered for all components of SAP
Exchange Infrastructure.
􀂄 Tracing is not activated by default. In order to activate tracing, perform the following steps:
1. Go to the Log Configurator service.
2. Switch To advanced mode.
3. Choose tab page Location.
4. Select a location.
5. Change the Severity from None to the required value, for example, Debug.
􀂄 Logging is activated by default. In order to change the preset log level, perform the following steps:
1. Go to the Log Configurator service.
2. Choose tab page Categories.
3. Choose Applications → Exchange Infrastructure.
4. Change the Severity to the required value.
􀂄 You can view traces and log files by the Log Viewer service in the Visual Administrator.

Trace and Log Files for the XI J2EE components
>>>Under /cluster/server0/log/applications/com.sap.xi
􀂄 repository.log
􀂄 directory.log
􀂄 mapruntime.log
􀂄 rwb.log
􀂄 xi.log
􀂄 repository.trc
􀂄 directory.trc
􀂄 mapruntime.trc
􀂄 rwb.trc
􀂄 xi.trc

>>>Default trace file for entire J2EE Engine:
/cluster/server0/log/defaultTrace.trc


􀂄 Trace and log files are essential for analyzing problems. They are offered for all components of SAP
Exchange Infrastructure.
􀂄 Tracing is not activated by default. In order to activate tracing, perform the following steps:
1. Go to the Log Configurator service.
2. Switch To advanced mode.
3. Choose tab page Location.
4. Select a location.
5. Change the Severity from None to the required value, for example, Debug.
􀂄 Logging is activated by default. In order to change the preset log level, perform the following steps:
1. Go to the Log Configurator service.
2. Choose tab page Categories.
3. Choose Applications → Exchange Infrastructure.
4. Change the Severity to the required value.
􀂄 You can view traces and log files by the Log Viewer service in the Visual Administrator.


Trace and Log Files in the ABAP Part:

􀂄 The tracing and logging behavior of the SAP XI is controlled inside transaction SXMB_ADM. Form the
main screen, choose Integration Engine Configuration. From the application toolbar, choose Specific
Configuration.
􀂄 Parameter LOGGING: The parameter LOGGING enables you to locally activate the logging of messages
for all pipelines of an Integration Engine.
􀁹 Usage: You set this parameter when you want to analyze message processing as it enables you to
document either individual steps, or all steps in a pipeline.
􀁹 Possible Values: 0 (deactivated) or 1 (activated)
􀂄 Parameter LOGGING_PROPAGATION: The parameter LOGGING_PROPAGATION enables you to set
locally in the Integration Engine whether the logging of a pipeline is passed on to the message.
􀁹 Usage: The parameter is used to pass on the logging settings to a message.
􀁹 Possible Values: 0 (deactivated) or 1 (activated)


􀂄 Parameter TRACE_LEVEL: The parameter TRACE_LEVEL enables you to locally set the trace level for
all pipelines in an Integration Engine. However, the diagnostic header of a message can specify the trace
level at which it is to be processed. Runtime then uses the maximum local trace level and message trace
level.
􀁹 Usage: The parameter is used to pass on the trace level settings to a message.
􀁹 Possible Values:
- 0 No Trace
- 1 Low Trace Level
- 2 Medium Trace Level
- 3 High Trace Level
􀂄 Parameter TRACE_LEVEL_PROPAGATION: The parameter TRACE_LEVEL_PROPAGATION
enables you to set locally in the Integration Engine whether the trace level of a pipeline is passed on to the
message.
􀁹 Usage: The parameter is used to pass on the trace level settings to a message.
􀁹 Possible Values: 0 (deactivated) or 1 (activated)

9). SAP XI -- BPM

8). SAP XI ---Adapter Frame work

SAP XI 3.0 Architecture:

􀂄 Applications based on SAP Web Application Server version 6.20 or higher can
communicate with the XI in the native XI-SOAP format via proxies. All other
applications, including “legacy” SAP systems (those on Basis releases lower than
Version 6.20), communicate with the XI via adapters. SAP provides an Adapter
Framework and Adapter Engine for effecting this communication.
􀂄 XI 3.0 introduces a new, J2EE-based adapter architecture. The adapter engine is
installed centrally on the Integration Server; it can also be installed locally (close to
the Business system), but still be configured, managed, and monitored centrally.
􀂄 Additionally, the Partner Connectivity Kit, the toolset for enabling small partners or
subsidiaries with no native XML messaging capabilities to communicate with the
XI, is based on the Adapter Engine


Adapter Framework based on SAP J2EE Engine:

>>The Adapter Framework provides common functionality for both the
Adapter Engine and SAP Partner Connectivity Kit.
>>Adapter Framework is based on SAP J2EE Engine as part of SAP Web AS

􀂄 Adapter Framework inherits properties and features such as
scalability, clustering, high availability, thread management, etc.

Adapter Framework provides its own queuing and logging services
Temporary stand-alone operation without connection to an Integration Server is
possible, while still providing e. g. guaranteed exactly once messaging to and
from connected application system.

􀂄 The J2EE-based Adapter Framework (AF) offers a unified interface and toolset for
configuring adapters of various types, as well as the Partner Connectivity Kit
(PCK).
􀂄 Because the AF queues messages locally, guaranteed one-time execution is
supported even if the connection to the Integration Server is temporarily lost.


JCA enabled Adapter Framework:

Adapter Framework supports J2EE Connector
Architecture (JCA).

􀂄 JCA is standard architecture for connecting the
J2EE platform to Enterprise Information Systems
(EIS) - e. g. ERP, DBMS, etc.
􀂄 A Resource Adapter plugs into an application
server, providing connectivity between the EIS and a
Java application
􀂄 JCA enabled Adapter Framework provides defined
interfaces to which both our adapters and 3rd party
adapters can conform
􀂄 JCA is a widely accepted standard that 3rd party
adapter providers are already familiar with.


Adapter Engine:

􀂄 The Adapter Engine provides connectivity between the XI runtime and Enterprise
Information Systems (EIS) such as databases, application systems, etc.
􀂄 The XI, and the Adapter Engine, support Synchronous and Asynchronous
delivery; in XI terms, these are described with a Quality of Service (QoS)
descriptor. The XI supports QoS Best Effort (BE), Exactly-once (EO), and
Exactly-once-in-order (EOIO). These are equivalent to RFC types Synchronous
RFC (sRFC), Transactional RFC (tRFC), and Queued RFC (qRFC), respectively.
􀂄 EO and EOIO are both guaranteed delivery protocols; this provides protection
against transitory failures by retrying failed calls and insuring one-time execution
of each interface call. The message queue and the message store of the Adapter
Engine provide support for guaranteed delivery.
􀂄 There are interfaces for configuring and administering the adapter engine, and
built-in security features.
􀂄 The Adapter Framework includes a module processor; modules are included for
all supported adapter types, but customer modules can be plugged into the
processor to extend the basic functionality.


Full integration of Adapter Engine in SAP XI landscape:

Adapter Engine is based on Adapter Framework
Adapter Engine fully integrated with the SAP XI landscape.

􀂄Central configuration of connections to application systems
(through appropriate adapters) in Integration Directory
􀂄Reuse of Integration Directory’s existing versioning and
transport capabilities
􀂄Central administration and monitoring over adapters,
Integration Server, Integration Engine through Runtime
Workbench.

􀂄 Adapters are configured directly in the Integration Directory now (instead of in a
separate adapter UI, as in the J2SE adapter engine).


Adapters hosted in Adapter Engine:

In addition to Adapter Framework, the Adapter Engine hosts a set of
adapters:
>>>SAP Adapters
􀂋File / FTP
􀂋JDBC (Database)
􀂋JMS (MQSeries, SonicMQ, …)
􀂋RFC
􀂋SOAP
􀂋SMTP
􀂋SAP BC (header extension for support of Quality of Service)
􀂋SAP Marketplace Adapter
􀂋RosettaNet (RNIF 2.0) Adapter
􀂋CDIX (RNIF 1.1) Adapter.

>>>3rd Party Adapters
􀂋iWay: UCCnet, more to come …
􀂋Optional: Adapters developed by partners, certificated by SAP.

SAP XI Adapter Partner System:

SAP relies on a system of partners to provide adapters for other
applications and certain industry standards
Adapter Reseller Agreement
􀂄iWay Software
􀂋UCCnet Adapter
􀂋Oracle, Siebel, PeopleSoft
􀂄SEEBURGER AG
􀂋EDI Adapters
􀂄 WebMethods
􀂋Applications (Oracle, Siebel, PeopleSoft, Baan, …)
􀂋Industry Standards (RosettaNet, CDIX) 􀃅 SAP XI 3.0


􀂄 By using the open standard JCA, SAP makes it easy for third parties to provide
additional adapter functionality. This further reduces the amount of integration
work that needs to be done by the customer.
􀂄 This list may be out of date by the time you read it; check the SAP Service
Marketplace for the latest information (see next slide).


Adapter Configuration:

􀂄 Configuration of an adapter is done in the Integration Directory; In the Integration
Directory, an adapter is configured as a Communication Channel.
􀂄 For each adapter Communication Channel that uses an adapter, there are
Adapter-independent and Adapter-specific parameters that need to be set.
Exactly what the parameters are depends, of course, on the type of adapter and
the mode of its employment.
􀂄 What kind of configuration needs to be done for an adapter? Consider the
inbound (sender) File adapter; this adapter reads a file from a file system or via
FTP, packages it as an XI message and sends it to the Integration Server.
Therefore, we need to configure:
>>What is the file name and where is the file located (either on the file system/share, or via
FTP connection parameters).
>>How to process the file, for instance how often to look for new files.
>>How do we convert the file structure to the XML structure of the XI message payload.


SAP Partner Connectivity Kit (PCK) Overview (1):

>SAP Partner Connectivity Kit is based on the Adapter Framework
The PCK enables XML document exchange between SAP XI and
business partners not using SAP XI.
>PCK provides connectivity options to access SAP Adapters:
􀂋File/FTP
􀂋JDBC (Database)
􀂋JMS
􀂋SOAP
􀂋RFC


􀂄 The PCK architecture is based on the Adapter Framework; a PCK is in fact an
instance of the Framework, configured as a PCK.
􀂄 The PCK adapts the native message interface of the partner system to the XI
messaging format and provides HTTP connectivity to the URL of the central
Integration Server.
􀂄 As an instance of the AF, the PCK provides connectivity to the same kinds of
back-end systems that the Adapter Engine does.


The PCK is deployed on a standalone SAP J2EE Engine
(part of SAP Web AS) within business partner’s landscape.


Configuration, administration, and
monitoring are done locally on the
PCK itself without the need for an
Integration Directory.


Technical Adapters in Detail:

􀂄 In general, a technical adapter does one of the following:
>>Take a message in the source format, convert it to XML and place it in the payload of an XISOAP
message, and post it to the Integration Server pipeline via HTTP(S), or
>>Receive an XI-SOAP message, extract the XML payload, convert it to the target format and
write it to the technical system.
􀂄 Details for different adapter types are in the following slides.

1.RFC Adapter:

􀂄 The RFC Adapter runs as a service in the J2EE environment of the Adapter Engine (i.e. also
central configuration)
􀂄 The RFC adapter is also part of the PCK.
􀂄 The RFC Adapter provides support for sRFC and tRFC
􀂄 The RFC Adapter uses JRFC (through the use additional parameters in the communication
channel configuration – use “Advanced mode” in the channel configuration and enter the
parameters according to the documentation.)
􀂄 The RFC Adapter supports connections through SAPRouter.
􀂄 Currently, to refresh Adapter Metadata:
- activate/deactivate communication channel
- restart the adapter service
􀂄 Only receiver communication channel configuration is necessary.
>>> Current Limitations:
􀂋No Call-Back, no RFC-GUI-Debug, no qRFC, no SNC.
􀂋Just one payload/attachment per message.
􀂋Digital signatures are not supported.
􀂋Not released for external system (in test; dedicated RFC-gateway necessary, i.e. this will not be delivered
with the J2EE Service)
􀂋Only one function call with one TID/within one LUW (this is also a change to XI 2.0; J2EEparameter
maxTransactionSizeOfLUW = 1)


2.IDOC Adapter:

􀂄 Any IDOCS received at the Integration Server (via tRFC) are handled by the
Inbound IDOC Adapter and treated as interfaces; if you want to distribute data to
the Integration Server via the ALE Layer (for example, to use Central User
Administration), you must maintain the IDOC types in an exception table
􀂄 In order to correctly construct the XML representation of the incoming IDOC, the
IDOC Adapter requires the metadata description of the IDOC. It retrieves this
information from the sending system (or a reference system in the case of an EDI
subsystem).
􀂄 Transaction IDX1 is used to configure the port for retrieving the metadata; the
cached metadata can be viewed in transaction IDX2.
􀂄 The case for the outbound IDOC adapter is similar, but is not shown here;
metadata, retrieved from the target application system, is used to construct the
IDOC to send to the SAP System (or EDI system).


3.File Adapter:

􀂄 The file/FTP adapter enables you to exchange data with the Integration Server by means of a file
interface or an FTP server. The file contents can be sent to the Integration Server unaltered. If the
data contains Comma Separated Values (CSV), then it can first be converted into a simple XML
message. This XML message is then forwarded to the Integration Server. Conversely, data coming
from the Integration Server can be put unaltered into a file or converted from XML into CSV format.
Text files that are to be processed by the Integration Server must be based on the codepage UTF-
8. The file/adapter can use every codepage that is installed in the Java runtime environment for
conversion purposes (for example, for converting foreign sets).
􀂄 The File adapter is configured as part of the Communication Channel configuration in the
Integration Directory. Exactly what parameters are set depends on the direction of the adapter and
the nature of the file to be processed (the illustrations above are for inbound file adapter
parameters).
>>>Broadly speaking, configuring the inbound adapter involves:
􀂋Where to find the file to be processed (file name/path, FTP server, etc.).
􀂋How to convert the file structure to XML, if necessary.
􀂋Processing instructions for dealing with the file (for instance, how often to poll the source directory).
>>>Configuring the outbound adapter involves:
􀂋Where to place the processed file (file name/path, FTP server, etc.).
􀂋How to convert the XI payload to a structured file, if necessary.
􀂋Processing instructions for the file (for instance, append new messages to an existing file, overwrite the
existing file, etc.).
􀂄 For the specifics, read the documentation for each direction.


4.JDBC/JMS Adapter:

􀂄 The JDBC and JMS adapters require drivers from the vendor. These must be
loaded and configured according to the documentation.
>>>JMS Adapter:
>>JMS Adapter Modules
􀁺 localejbs/sap.com/com.sap.aii.af.jmsadapter/ConvertJMSMessageToBinary
􀁺 localejbs/sap.com/com.sap.aii.af.jmsadapter/ConvertBinaryToXMBMessage
􀁺 localejbs/sap.com/com.sap.aii.af.adapter.
􀁺 caller/CallAdapterWithMessageBean
>>JMS Adapter Configuration Parameters
􀁺 XMB.InterfaceNamespace
􀁺 XMB.Interface
􀁺XMB.SenderService
􀁺XMB.SenderParty
>>> The JDBC adapter enables you to connect database systems to the Integration
Server. The adapter converts database content to XML messages and vice versa.


5.Plain HTTP Adapter:

􀂄 The plain HTTP adapter is used by external systems to connect to the Integration
Engine using the native HTTP interface (HTTP payload without SOAP envelope).
These systems are connected using the Internet communication framework of the
SAP Web Application Server. For this purpose, the Integration Engine HTTP
inbound channel contains an http Service delivered by SAP, called
/sap/xi/adapter_plain.
􀂄 The plain HTTP adapter is part of the Integration Engine. It comprises two parts,
namely an adapter at the Integration Engine inbound channel and an adapter at
the Integration Engine outbound channel.
􀂄 The adapter at the inbound channel is located before the Integration Engine
pipeline and calls this pipeline. The adapter at the outbound channel is called by
the pipeline, and can therefore be regarded as part of the pipeline. It requires a
corresponding communication channel from the technical routing for each logical
receiver.
􀂄 In other words, to use the sender channel for the plain HTTP adapter does not
require a communication channel in the Integration Directory; however, the
receiver HTTP adapter does.


6.Plain SOAP Adapter:

􀂄 The SOAP adapter enables you to exchange SOAP messages between remote
clients or Web service servers and the Integration Server.
􀂄 To configure the Sender SOAP adapter (to call an interface through the Integration
Server as a web service) specify the Interface name and namespace and the
Processing Mode (BE, EO, EOIO), and conversion parameters for the incoming
SOAP headers.
􀂄 To configure the Receiver SOAP adapter (to call a web service through the
Integration Server) specify the target URL of the SOAP service and the conversion
parameters for the XI SOAP headers. If the URL must be accessed via a proxy
server, you must also specify the proxy server settings.

7).SAP XI -- RunTime Workbench

Runtime Workbench overview:

Central point of access: XI Runtime
Workbench
Smooth integration with CCMS
Easy Configuration
􀂄Exploiting System Landscape Directory
􀂄Consistent look-and-feel in UI
Improved Error Handling
􀂄Errors classified by error cause.


􀂄 The Runtime Workbench is a tool for monitoring the XI, and all of its components, processes, and
messages, centrally through a java-based interface.
􀂄 The Runtime Workbench unifies many of the monitoring architectures available in SAP solutions into a
single, coherent, web-based interface.The Runtime Workbench offers a central view of all components
and processes.
􀂄 The Runtime Workbench provides for Component Monitoring, Message Monitoring, End-to-End
Monitoring, and Performance Monitoring.
􀂄 There is also an interface for Monitoring and Alert configuration.
􀂄 It integrates with CCMS; for instance, CCMS alerts relevant to the XI can be viewed from the RWB.


Monitoring – Message Monitoring:
􀂄 Message monitoring can be used to find and diagnose errors with specific XI messages.
􀂄 Capabilities are similar to transaction SXI_MONITOR.
􀂄 The message monitoring infrastructure is also used by the end-to-end monitor.
􀂄 Of course, message monitoring is only available for asynchronous messages, unless the XI Pipeline is
configured to persist synchronous (Best Effort) messages.



Monitoring – Component Monitoring:

􀂄 The Runtime Workbench gives you a view of the availability and status of all XI components, including
de-central adapter engines.
􀂄 Allows to monitor ABAP and Java components from a unified UI.


Monitoring – Performance Analysis:


􀂄 The Runtime Workbench Performance Analysis Tool shows performance statistics for user-defined
selection criteria.
􀂄 Allows to see the latency as well as the throughput. This is important for ongoing sizing of the XI.


Monitoring - Alerting:

􀂄 Message alerting allows to set conditions for triggering alerts. This allows for notification of the correct
parties for specific classes of errors.


RWB – Component Monitoring:

Component Monitoring:
>>Monitoring of ABAP and Java
components
>>Central viewing of component‘s
connection status in a specific
domain.
>>Ping of system and sending of
messages to components via a
self-test area.

>>>You use component monitoring in the following cases:
􀁹 If you want to get an overview of the status of the individual components of SAP Exchange
Infrastructure (XI).
􀁹 If you want to call the configuration data of individual XI components.
􀁹 If you want to use test messages to check whether XI runtime is functioning correctly

>>> Use the Component Monitoring in the Runtime Workbench to display and monitor the following XI
components:
􀁹 The Integration Engines
􀁹 The Adapter Engines
􀁹 The Integration Directory
􀁹 The Integration Repository
􀁹 The Runtime Workbench itself.

􀂄 Use the CCMS status to limit the number of components that are displayed. This means that the system
only displays those components with the selected status (all, red, red & yellow).
􀂄 The CCMS status is based on information from the SAP Computing Center Management System
(CCMS). It is displayed by means of a symbol, which can be red, yellow, green, or gray.


Component Monitoring features:

􀂄 Component monitoring provides two views for displaying the components. When you choose Display, the
default view is the table view. This view displays all the XI components maintained in the System
Landscape Directory, their current CCMS status, and the name and type of the component.
􀂄 The system can only display those XI components that are correctly maintained in the System Landscape
Directory.
􀂄 To switch to the tree view, choose Display as Tree. This view sorts the components by component type.
You can select a component from those displayed and do the following:
􀁹 Call information on the current status of the component
􀁹 Call information on the configuration of the component
􀂄 You can also do the following, irrespective of which components are selected:
􀁹 Check that the XI runtime is functioning correctly.


Sending Test Messages:

􀂄 You use this function to send test messages to the Integration Server, irrespective of the XI components
you have selected. To do this, you must specify the necessary data for the message header on the Test
Message tab page, and provide a message payload. After you have specified and sent the test message, the
following result is returned:
􀁹 The message status in the form of a green symbol (OK), or a red symbol (error) with error status.
􀁹 An option to navigate to the message monitoring of the Runtime Workbench.
􀂄 You can persist the header and payload of a test message in the database and call them from there at a later
point in time


RWB – Message Monitoring:

Harmonization of different message monitors
􀂄Integration Engine
􀂄Adapter Framework (J2EE).
All message monitoring centrally accessible
through RWB.
Monitoring locally available as well
􀂄at least for partner connectivity kit.


>>>You use message monitoring in the following cases:
􀁹 To track the status of messages
􀁹 To find errors that have occurred and establish what caused them.

>>>Message monitoring enables you to use the following functions:
􀁹 Display and manage messages
􀁹 Filter the displayed messages by specific criteria
􀁹 Configure the message display.

􀂄 To display the messages for the selected component, choose Display.
􀂄 To update the message display, choose Update.
􀂄 To display all available information for a specific message in the form of a table, choose Details.


RWB – End-to-End Monitoring/Configuration:


>>You use end-to-end monitoring in the following cases:
􀁹 If you want to monitor message processing steps in a number of components (to be configured).
􀁹 If you want to monitor the path of individual messages through these components, from start to end.
􀁹 The central tool for end-to-end monitoring is the Runtime Workbench, which you call from the initial
screen of SAP Exchange Infrastructure (XI).

􀂄 The Runtime Workbench receives the data for end-to-end monitoring from the Process Monitoring
Infrastructure (PMI), which is an SAP monitoring tool for monitoring end-to-end technical processes
involving multiple components.
􀂄 If you want to run end-to-end monitoring, proceed as follows:
1. Select and configure the components that are relevant for monitoring.
2. Send the messages whose processing you want to monitor from start to end.
3. Choose End-to-End Monitoring on the initial screen of the Runtime Workbench.
4. Choose Display.


End-To-End Monitoring at a glance:

>>>End-to-end monitoring has two views for displaying the data delivered from PMI for the individual
processing steps (technical process steps) of the messages in the configured components:
􀁹 The process overview: The process overview displays the total number of processed messages and the
number of messages with errors for each component involved. If the number of messages with errors is
greater than zero, the status of the component changes from green to red. The process overview is the
initial screen of process monitoring and contains a graphical representation of the components involved
in the process. You can open these components and display the process steps involved.
􀁹 The instance view: The instance view displays the path of a specific message through the components
involved. Detailed data is available for each individual processing step in every instance. The instance
view contains a graphical representation of all components involved in the process. It displays the status
for each of the components that the instance passes through. You can open the components to display a
view of the process steps involved with the corresponding data.


End-To-End Monitoring – Prerequisites and configuration:

Activate the Process Monitoring Infrastructure Monitoring by
setting respective configuration parameter in TC SXMB_ADM.


􀂄 To configure End-to-End Monitoring:
1. On the initial screen of the Runtime Workbench, select the Configuration tab page.
2. Enter the logon data for the monitoring server.
3. Choose Display.
4. The system displays the components of your current domain. The Integration Server is selected as the
default.
5. Select the other components that you want to use and configure them as sender or receiver, or both,
depending on the component type.
6. Select the monitoring level that you want to use for each of the selected components.
7. The monitoring level determines which tracking agents are activated for the respective component and
which monitoring data an active agent delivers.
8. Choose Save Configuration.


Performance Monitoring:

Measured data:
􀂄Throughput
􀂄Latency (“processing time”)
Selection and Aggregation by:
􀂄XI component (Integration Server, Adapter Engine)
􀂄Time range
􀂄Message attributes: Sender, receiver, message type

>>You use performance monitoring to display statistical data on the performance of message processing. The
data comes from the Integration Server (IS) or the Process Monitoring Infrastructure (PMI).
>> Use selection criteria to restrict the data that is displayed. For example, you can restrict the data to:
􀁹 The data source
􀁹 A specific component
􀁹 A message processing mode
􀁹 A specific time interval.

>>The system only displays messages that are processed successfully within the specified time interval. You can also choose Extended Search to restrict the displayed messages by using sender and receiver criteria.
If you want to display aggregated data, you must specify an aggregation interval. If you want to display detailed data, you must specify a unique sender and unique receiver.

>>> Use performance monitoring to display the following data:
􀁹 Aggregated throughput data for message processing
􀁹 Aggregated detailed data for message processing performance
􀁹 Individual detailed data for message processing performance


Alert Configuration:

􀂄 Available as of XI 3.0 SP1.
􀂄 When there is some type of failure in the system, you generate an alert; based on this alert, you can send an email,
SMS, fax, email, etc. to notify the proper person.
􀂄 The alerting capability of the Exchange Infrastructure takes advantage of the alerting infrastructure (CCMS) of the
Web Application Server, with the added capability of configuring message-oriented alerts.
􀂄 The Alert Framework provides an interface from the Basis (Web AS) Alert Framework. You use transaction
ALRTCATDEF to define the text, the priority, number of delivery, etc. for the alert.


􀂄 To configure your alerts, proceed as follows:
􀁹 To define an alert category, choose Create Alert Category.
􀁹 You can also create the alert category directly by calling transaction ALRTCATDEF. In both cases you require
the authorizations of the role SAP_XI_ADMINISTRATOR.
􀁹 Enter the following values:
- The receiver of the alert
- The title of the alert
- The text of the alert, including container variables that are filled at runtime.
- You must use the available container variables to create the required container elements. Enter the name of the
container element and the name of the ABAP Dictionary data type from the container variable. All other
entries are optional. To see the available Alert Container Variables, refer to the documentation.
- The follow-up activity: Specify the URL of the required follow-up activity. At runtime, the link address of endto-
end monitoring is always entered as the standard follow-up activity.

􀂄 Create a rule in which you use a defined alert category. To do this, proceed as follows:
􀁹 Give the rule a name.
􀁹 Select the alert category that you want to use by clicking the corresponding category in the alert
category table.
􀁹 Select the required error category and error code.
􀁹 If necessary, specify additional message attributes for the sender or receiver, or both.
􀁹 To add the new rule to the list of alert rules, choose Add Rule.
􀁹 If the check box Rule Activated is selected (default setting), the rule is automatically activated when you
add it and is displayed as active.


RWB – Cache Monitoring:

>>Cache monitoring enables you to display representations from the value mapping table that are currentlylocated in the runtime cache of the Integration Engine or Adapter Engine.
>> The following information is displayed for each representation:
􀁹 Context
􀁹 Issuing agency
􀁹 Identification schemes
􀁹 Value
􀁹 You can restrict the number of hits displayed

6). SAP XI ----Runtime

􀁺 The Exchange Infrastructure connects application systems using XML messaging and
web 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 program
running in another system, even when the platforms and technologies of the systems
aredifferent, 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


􀁺 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 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.
􀁺 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.
􀁺 The SOAP Body element contains the actual SOAP message intended for the ultimate
endpoint of the message


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.
􀁺 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.
􀁺 The SOAP body of an XI message contains only a Manifest element, which points to
the actual document being sent.
􀁺 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).


The slide shows a sample XI-SOAP message (without the payload). For clarity, the
various header elements (except the Main header) are collapsed.
􀁺 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


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.


XI Pipeline


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


􀁺 The Pipeline is accessed via a URL, behind which is an ICF service. The URL for
sending 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 listener
port of the Internet Communication Manager.


􀁺 Messages are processed through a set of services, each of which performs a specific
operation on the message.
􀁺 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


􀁺 The Adapter Engine provides connectivity to the XI for non-Web AS Interfaces (3rd
party systems).
􀁺 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.

5).SAP XI --Integration Directory

The Integration Builder is a central java-based tool that contains the Integration Repository and the Integration Directory. Within this chapter we will focus on the Directory and its makeup. Here, the design time work done previously in the Repository is built further upon and finalized to complete the logical / technical routing details for an incoming message.

The Directory is made of the following main components:
1. Collaboration Profile
--Party
--Service without Party
--Channel
2.Collaboration Agreement
--Sender Agreement
--Receiver Agreement
3.Logical Routing
--Interface Determination
--Receiver Determination
4. Scenarios
--server

Collaboration Profile

A Collaboration Profile documents the technical options available to communication partners. Here the potential senders / receivers and the technical communication paths are specified. As seen in the Roadmap, the primary building blocks are Parties, Services, and Channels

. From Repository we have simply defined the interfaces, their relationships, mappings and structures. In the Collaboration Profile true senders and receivers are created along with the technical details of how to communicate with them.

Parties are defined to represent a business or company unit. Within a Party, Services can be defined / associated to represent technical or business sub-units. For cross-company processes, entire company units can then be specified as sender / receiver providing many services for communicating with other companies.

To create a Party, follow these steps:

1. Traverse the navigation tree within the Directory down to the Party
2. Highlight the Party row and right click. Select ‘New’
3. Enter the name and description of the Party. Alternatively, also enter the Scenario
name
4. (Optional) Associate / create the necessary Alternative Identifiers for the Party
5. Associate / create the necessary Services

Service without Party

Services define the true senders and recipients of messages within XI. As stated above, they can be associated to higher level Parties or by themselves should a Party not be available for association. They are broken into the following three sub-categories:

1. Business Service – Used in cross-company processes where the Party cannot be fully defined. They represent business or technical sub-units

2. Business Process – As a Business Process defined in the Repository are recipients of messages (for process step triggering) or can send them, they are considered a Service and modeled here

3. Business System – Business Systems as defined in the SLD (specific application system in the system landscape) are represented here in the Directory Business Systems can NOT be created in the Directory, but must exist from the SLD
Given the most popular option for basic messaging will be Business Systems (and the similarities across all three), this section will focus on that option from here forward.

To create a Business System (Service), follow these steps:

1. Traverse the navigation tree within the Directory down to the Service Without Party -> Business System
2. Highlight the Business System row and right click. Select ‘Assign Business System’
3. This will open the Business System Assistant
4. (Optional) Associate the Party for the Service and ‘Continue’
5. Select the Business System from the list Only Business Systems not yet assigned are available
6. (Optional) Select the checkbox to pre-generate related Communication Channels
that are most common. These are then shown in the Communication Channels window. Channels created are: HTTP, XI, IDoc, and RFC and are created for the Receiver only. They still require configuration to be valid.
7. In the Business System Editor, the Sender and Receiver tabs show the outbound and inbound (respectively) Message Interfaces defined in the Repository and are available to the Business System. These lists cannot be modified here.
8. In the Business System Editor, the Software Components tab shows the software components defined in the SLD related to the Business System. This list cannot be modified here.

Channel

Communication Channels define the necessary technical communication details for messages (associated adapter type, transport / message protocols, login info for receivers, etc). A Communication Channel can be defined / used for either inbound (from a sender) or outbound processing (from a receiver). It is also where the related adapter type is configured and indicates to the Integration server how to transform the message from the sender so it can be processed by the receiver (whether a system or the Integration Server). It is here that all the different sender / receiver Communication Channels for a given service are identified.

Communication Channels must be associated to a Service and assigned as a sender or receiver. In the following Collaboration Agreement configurations, these Services are configured as either senders or receivers in a message transfer, and the assigned channels have the role of either sender / receiver channels as they were defined.
Sender and Receiver Channels have significant overlap in configuration requirements. As such the steps below cover both with an indication for those items that are specific to one vs. the other.

To create a Communication Channel (sender or receiver), follow these steps:
1. Traverse the navigation tree within the Directory down to the Communication Channel under the Service of interest
2. Highlight the Communication Channel row and right click. Select ‘New’
3. (Optional) Associate the Party for the Service
4. Enter the Service
5. Enter the Communication Channel name and description
6. (Optional) Associate this to a Scenario
7. On the following Edit Communication Channel window the following tabs are available. As the Parameters tab is the most critical, it will be further described in detail below:
a. Parameters – Adapter configuration
b. Identification – Selection of alternative identifiers for the sender / receiver parties
c. Module – Defines the Module Processor, which allows the specification of generic modules that equip the adapters with additional functions
8. On the Parameters tab
a. General Configuration section – Shared across all adapter types
i. Select the Adapter Type. Each adapter type has its own unique settings available as defined below in the Specific Configuration section
ii. Set the radio button to assign the channel direction as a sender or receiver for this Service If http or IDoc is selected as the adapter type, the direction is already set to receiver. No configuration needs to be done for sender processing as the SAP Web AS settings have already been configured.
iii. Assign the Transport Protocol from the sender or to the receiver (varies with adapter type and direction selected). Only a single value may be available
iv. Assign the Message Protocol from the sender or for the receiver (varies with adapter type and direction selected). Only a single value may be available
v. Associate the Adapter Engine
b. Specific Configuration section – Unique to the adapter type and direction specified
i. Fields with an ‘*’ are required for configuration
ii. Given the number of adapter types multiplied by a sender / receiver pairing, the specific configuration requirements will not be covered in detail here. See the chapter on Adapters for more information.
9. Once complete, ‘Save’

Collaboration Agreement

Collaboration Agreements define the technical details for message processing (ex. Adapter configuration) and security settings for sender / receiver partners. The primary building blocks are Sender Agreements and Receiver Agreements.

Sender Agreement
A Sender Agreement is used to transform an incoming message so it can be processed by the Integration Engine. This allows the Integration to understand the protocol of the incoming message (via the associated Channel) to processes it as needed. Further the security settings will allow the checking of the signature of the incoming message, check the data integrity, or authorize the sender of the message. A Sender Agreement is not always required based on the Adapter Type selected Ex. XI.

To create a Sender Agreement, follow these steps:
1. Traverse the navigation tree within the Directory down to the Sender Agreement row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Specify if the sender uses a Virtual Receiver
6. Enter the description
7. (Optional) Associate this to a Scenario
8. On the following editor window, select the sender Communication Channel
9. (Optional) If the Communication Channel associated is of type XI, security settings can be configured as described above

Receiver Agreement

A Receiver Agreement is used to transform an outgoing message so it can be processed by the receiver. It is here the sender service is linked to a unique receiver service / inbound Message Interface via a Communication Channel. To put it simply, the Integration Engine now knows for a message being sent to a given receiver the technical details of how to send it that partner (via the associated Channel). Further the security settings will allow the signing of a message or check the data integrity.
To create a Receiver Agreement, follow these steps:

1. Traverse the navigation tree within the Directory down to the Receiver Agreement row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. (Optional) Associate the receiver Party for the Service
5. Enter the receiver Service
6. Select the inbound Message Interface and related Namespace
7. Enter the description
8. (Optional) Associate this to a Scenario
9. On the following editor window, select the receiver Communication Channel.
10. (Optional) In the Header Mapping section you can change the sender / receiver address fields in the message header are transformed when the message is sent to the receiver, either by fixed value or from the message payload. This can either
relate to the XI message header or to the IDoc control record (overriding the sending / receiving partner number) if the control record is generated from the IDoc Adapter.
11. (Optional) If the Communication Channel associated is of type XI, security settings can be configured as described above

Logical Routing

Logical Routing relates the previously defined Message Interfaces in the Repository to potential receivers and ultimately which Message Interfaces are specifically shared
between partners. As seen in the Roadmap, the primary building blocks are Interface
Determination and Receiver Determination.

Interface Determination

An Interface Determination allows the association of an outbound Message Interface from a sender to one or more inbound Message Interfaces of a single receiver (and the related Interface Mapping). Whereas a Receiver Determination will link all available recipients of an outbound Message Interface from a unique sender Service, the Interface Determination focuses on a single sender / receiver pair for that same outbound Message Interface and all the related inbound Message Interfaces.

To create an Interface Determination, follow these steps:
1. Traverse the navigation tree within the Directory down to the Interface Determination row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Enter the receiver Party
6. Enter the receiver Service
7. Enter the description
8. (Optional) Associate this to a Scenario
9. On the following editor window, select the Inbound Message Interface and Interface Mapping

Multiple inbound Message Interfaces can be associated by using the green ‘+’ button. If more than one exists, a ‘Condition’ column appears that allows specifying under what conditions a message is forwarded to the inbound interface (via the Condition Editor)

Receiver Determination

A Receiver Determination is the final step in establishing a logical routing for a message. It allows the association of an outbound Message Interface from a sender to 1 or more receivers. Further a condition can be defined for each receiver that, based on data values in the message itself, will allow / prevent the forwarding of a message to that receiver. A Receiver Determination, then, specifies for an incoming message from a given sender all the potential receivers of that message – as well as under what conditions they will receive it.

To create a Receiver Determination, follow these steps:
1. Traverse the navigation tree within the Directory down to the Receiver Determination row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Specify if the sender uses a Virtual Receiver
6. Enter the description
7. (Optional) Associate this to a Scenario
8. On the following editor window, configure the Condition (in the Condition
Editor), receiver Party (optional), and receiver Service
Multiple Condition / Party / Services can be associated by using the green ‘+’ button

A Final Check

Once all items are fully configured, the Configuration Overview for Receiver Determination displays the overall status. After ‘refreshing’ the related status for Interface Determination / Receiver agreement for each receiver Service is displayed. Items in red indicate invalid / missing objects to be corrected. This, however, does not ensure that the configurations for these objects are complete / correct.

4).SAP XI -----System Landscape Directory

System landscapes consist of multiple distributed software components, on different platforms, and supporting unique interfaces. The SLD provides a central repository where comprehensive information about all the systems that can be and are connected with the XI system landscape. The SLD is the first step in setting up the XI landscape and is used as input into the Integration Builder.
The SLD is made of the following main components:

1. Component Repository
2. Landscape Directory

The component repository describes the building blocks of solutions and their possible combinations and dependencies. As seen in the Roadmap, the primary building blocks are
Products (such as SAP R/3), Software (such as MDM, or SD), and their respective versions (such as 1.2, etc). The creation and relationship between these building blocks gives a central overview of the items that exist in the network environment along with their respective versions (for upgrade or connectivity purposes). These blocks are then associated to logical / physical systems to build the network environment within XI.
SAP products / software are readily available and only require association with the proper technical systems. 3rd party systems require creating the products / software as well as the system association.

Product
Products are a unit that can be delivered, is visible to the customer, and that is installable and renewable. As mentioned before, the SAP Products are readily available (i.e., SAP APO, SAP Automotive, etc). To create a 3rd Party Product, follow these steps:

1. Navigate to the Component Registry (a.k.a. ‘Software Catalog’) within the SLD
2. Choose ‘Products’ from the Software Type drop down to view available Products
3. Choose the ‘New Product’ option to create a new Product
4. Enter the Vendor, Product Name and Version and ‘Create’
5. If prompted, the Software Component name and version can be added here or in the next step

Software
Software Components represent the reusable modules of a product. As mentioned before, SAP Software is readily available (i.e., Adobe Document, CRM Mobile Client, etc).

To create a 3rd Party Software, follow these steps:

1. Navigate to the Component Registry (a.k.a. ‘Software Catalog’) within the SLD
2. Choose ‘Software Components’ from the Software Type drop down to view available Software Components
3. Choose the ‘New Component’ option to create a new Software Component
4. Select the Product from the previous step and ‘Create’
Associating Software Components to a Product does not mean these are installed or active for this product, rather that they are simply available as part of the product suite. For example, this could be a SAP Product but only SD and MM are actually active / installed.

Landscape Directory
The landscape directory provides an exact picture of the elements installed in the system landscape as well as the connections between the systems. These elements are built on top of the products and components defined in the Component Repository of the SLD. As seen in the Roadmap, the primary building blocks are Technical Systems (can normally be thought of as a physical system, such as a SAP server) and Business Systems (derived from the related technical system, such as a specific SAP client used for a particular business purpose). The combination of these two provides the landscape to which XI will have connectivity with.

Technical System
Technical Systems in XI are the conceptual representation of a physical system, such as a physical SAP server with a number of Software Components installed.

To create a Technical System, follow these steps:

1. Navigate to the Technical Landscape within the SLD
2. Choose the ‘New Technical System’ option to create a new Technical System
3. Choose the system type (Web Application Server ABAP, Third Party, etc.) then ‘Next’
4. Enter the Details for the system. For a SAP Web AS this would be the SID, Installation Number, DB Hostname, or associated Web AS ABAP, etc. For a 3rd party this may be the System and Host Name
5. Associate the system to the correct Product(s) that are installed on that system and

Business System

Business Systems in XI are the conceptual representation of a logical system, such as a specific client on a SAP server or a 3rd Party payroll application. Business Systems in the Integration Builder become the partners that exchange message information.

To create a Business System, follow these steps:
1. Navigate to the Business Landscape within the SLD
2. Choose the ‘New Business System’ option to create a new Business System
3. Choose the system type (Web Application Server ABAP, Third Party, etc.) as was done for the Technical System then choose ‘Next’
4. Select the related Technical System
5. Associate the system to the installed Product and ‘Finish’
The field ‘Logical System Name’ is MANDATORY for a system that will either send or receive IDocs. It must match the logical system name as defined in the SAP sending / receiving client for the proper resolution with the IDoc control record.

3).Integration Builder (Repository) Overview

The Integration Builder is a central java-based tool that contains the Integration Repository and the Integration Directory. Within this chapter we will focus on the Repository and its makeup. Here, the design time work for interface creation is done defining and associating the message structure, defining mappings, and allocating these to business scenarios. Downstream during configuration time the Directory will utilize the objects created within the Repository.

The Repository is made of the following main components:

1. Interface Objects

2. Mapping Objects

3.Business Scenarios and Processes

4. Adapter Objects

Some basic features of the Repository:

Versioning
• Handles all versions of a software component in one system
• Version history maintained for different versions of an object
• Documentation maintainable for all objects listed above
• Usability
• Drag and Drop between objects in a navigation tree and fields of content frame (message mapping)
• Dock and Undock of windows
• Object History

Getting Started: Adding Software Components to the Repository:

A number of items in the Repository are built on objects built earlier in the SLD. At the very top of the navigation tree are Software Components followed by Software Component Versions (SWCV). Development objects in the Repository must be associated under a Software Component / Version (as well as namespace) in order to be created. Here are the steps to Import these items from the SLD:

1. Navigate to the Repository and select menu items Tools -> Transfer from System Landscape Directory -> Import Software Component Versions
2. Select the Software Component and ‘Import’
3. These Software Components will now appear in the navigation tree
4. Navigate to and double click the SWCV
5. Select whether this SWCV allows import of RFC / IDoc Interfaces (structure metadata from SAP)
6. Enter the ‘Connection Data for Import from SAP System’ and ‘Save’ The System field refers to Business Systems maintained in the SLD. To determine Group, access the normal SAP logon for this system, choose groups, enter the system ID and message server, and ‘Create List’

7. (Optional) Update the Object Attributes to indicate if objects located here are original or modifiable (useful for turning off in a QA or Prod environment)

: Adding Namespaces

In the Adding Software Component we discussed adding a Software Component and SWCV into the Repository. A further distinction under the SWCV is the Namespace. Namespaces are essentially logical areas for categorization of development. These are free-form and can be used in a number of ways, with anything from conventions similar to SAP Development Classes to landscape environments (Simulation, Development, Quality Assurance, and Production). To create a new Namespace follow these steps:

1. Navigate to the Repository and highlight the SWCV and right click. Select ‘Namespace’
2. In the bottom Namespaces section press the green ‘+’ to add a line and enter the Namespaces. Select ‘Save’ when done
• Namespaces in the Repository are NOT related to namespaces in the SLD
• A SWCV can have many namespaces associated to it
• Once a Namespace is defined, XI Automatically creates the Business Scenario,
Interface Object, Mapping Object, Adapter Object, and Imported Object folders automatically!
• Follow the Namespace Conventions link for more detail

Interface Objects

Interface Objects are the low level building blocks of interfaces. As seen in the Roadmap, the primary building blocks are Data Types, Message Types, and Message Interfaces.
The creation and relationship between these building blocks defines the various message structures and the message interfaces they are associated to.

Data Types

Data Types are the field element structure of a message. In the case of an IDoc or RFC, these can be imported directly from a SAP system and do not need to be created manually. Another alternative is to ‘Import’ the structure from a XSD (Use the Tools -> Import XSD from the Data Type sub-window). Lastly is to create the data type by hand.

To create a Data Type, follow these steps:

1. Traverse the navigation tree within the Repository down to the Data Type object under the proper Namespace / Software Component
2. Highlight the Data Type row and right click. Select ‘New’
3. Enter the Data Type name, description, and ‘Create’
4. Use the green ‘+’ buttons to add elements and sub-elements. Note the Category column reflects hierarchy
a. Provide a name to the element
b. (Optional) Assign a type (string, integer, etc). If assigned it is assumed this is a data element level
c. (Optional) Determine a min and max occurs for the element
d. (Optional) Associate any Details (length, minimum length, pattern, white Space, etc). These are referred to as ‘Facets’
e. (Optional) Assign a Default value
f. (Optional) Add a Description5. (Optional) Click the XSD tab to view the Data Type in XSD representation
6. Repeat as needed and ‘Save’ when done

Data Types can be created then referenced in other Data Types as ‘nested’ objects within the same SWCV. Simply select them under “Search Help” under the “Type” drop down menu on the Data Type creation screen

Message Types

Message Types are assigned to a single Data Type and function similar to a Message Type -> Idoc Type relationship in SAP i.e. a business usage of the lower level data structure. It is not directional specific and can be associated to numerous MessageInterfaces for inbound and outbound messages

To create a Message Type follow these steps:

1. Traverse the navigation tree within the Repository down to the Message Type object under the proper Namespace / Software Component
2. Highlight the Message Type row and right click. Select ‘New’
3. Enter the Message Type name, description, and ‘Create’
4. In the Data Type Used section, associate the Data Type either via drop down, copy/insert, or drag and drop
5. (Optional) Click the XSD tab to view the Message Type in XSD representation
6. Repeat as needed and ‘Save’ when done
A Message Type is identified by a name and namespace. This becomes an root element tag in the XML of the message payload (more on this topic in the Runtime chapter).

Message Interfaces

Message Interfaces are XML based, platform independent descriptions of message transfer requirements. They consist of 0 to 1 inbound message types, 0 to 1 outbound message types, and 0 to many fault message types.

Message Interfaces can be created manually, or imported in the case of SAP interfaces
(RFC / IDOC). Once the Message Interface exists (in the case of non RFC / IDOC scenarios) it determines which proxy objects can be generated (Proxy Objects to be covered in a later chapter). Message Interfaces are used to describe the inbound / outbound messages routed through XI. A given message interface can be paired to another message interface, imported interface, or an interface configured by an adapter to define an overall inbound / outbound message flow.

To create a Message Interface follow these steps:

1. Traverse the navigation tree within the Repository down to the Message Interface object under the proper Namespace / Software Component
2. Highlight the Message Interface row and right click. Select ‘New’
3. Enter the Message Interface name, description, and ‘Create’
4. Enter the Message Interface Attributes
5. Associate the applicable message type(s) either via drop down, copy/insert, or drag and drop
The message types available (input, output and fault) relate to the configuration of the Attributes. Fault types can be optionally assigned to allow handling of application specific errors or persist them in monitoring.
6. (Optional) Click the WSDL tab to view the Message interface in WSDL representation
7. ‘Save’ when done

Optional Context Objects can be associated on the related tab on the Message Interface screen.

Mapping Objects

Mapping Objects are only required if the message structures for an outbound / inbound pairing are not identical and are built on top of the Interface Objects created / imported. As seen in the Roadmap, the primary building blocks are Message Mapping and Interface
Mapping. To this point we have simply defined the structure for messages and associated them to a various, unconnected message interfaces. These will now ‘coupled’ together to make a logical message exchange as well as to define how mappings are done between the input / output message structures.

Message Mapping

Message Mappings consist of two types of mappings:

1. Structure mappings: Transform entire message structures
2. Value Mapping: Transform values within messages
The same message could have numerous mappings created for it, to accommodate numerous transformation requirements for recipient system(s), and executed in parallel or serial as defined in the Interface Mapping. Message Mappings can be created in some of the following ways:
1. From the standard graphical mapping editor, which generates the underlying java code. This uses a queue based model for handling very large documents.
2. Imported external java mappings (no tool support in XI)
3. Imported external XSLT (Extensible Stylesheet Language Transformations) mapping (no tool support in XI)
4. ABAP mapping programs for parsing / rendering the XML
To create a Message Mapping, follow these steps:
1. Traverse the navigation tree within the Repository down to the Message Mapping object under the proper Namespace / Software Component
2. Highlight the Message Mapping row and right click. Select ‘New’
3. Enter the Message Mapping name, description, and ‘Create’
4. In the Structure Overview section, add both the Source and Target Message Type
either via drop down, copy/insert, drag and drop, or import
5. Associate the source / target fields as required per business requirements or field
color requirements by drag and drop or double clicking a source / target pair
6. (Optional) Assign functions between source / target fields for value mapping in the Data-Flow Editor by adding the function and connecting the source output / target input arrows to the small rectangles for input and output values on the function
7. (Optional) Click the Test tab to run a test XML message through your mapping.
8. Repeat as needed and ‘Save’ when done

Interface Mapping

Interface Mappings associate a Message Mapping to an outbound and inbound MessageInterface. This now begins to create the association needed for the Integration Directory to ultimately route an incoming message to the correct mapping and target system.

To create an Interface Mapping, follow these steps:

1. Traverse the navigation tree within the Repository down to the Interface Mapping object under the proper Namespace / Software Component
2. Highlight the Interface Mapping row and right click. Select ‘New’
3. In the Source Interface window select the source Message Interface, the related Namespace and SWCV via the drop downs The Namespace and SWCV will default when the Message Interface is chosen
4. Repeat the above in the Target Interface window for the target Message Interface
5. Press the ‘Read Interfaces’ button to automatically populate the Source and Target Message sections in the bottom Request / Response window and read their properties
6. Select the Mapping type (Message Mapping, java, XSL) and the Message Map and ‘Save’ Multiple Message maps can be associated in the Request window, and are executed against the incoming message in the sequence listed

7. If the Message Interfaces chosen are synchronous, a ‘Response’ tab will be visible next to the ‘Request’ tab on the bottom window. The preceding step of Message Map association would also need to be done for the response message in that case
8. (Optional) The ‘Test’ tab allow testing of the Message Mapping.

2).Understanding the importance of Exchange Infrastructure

XI is an Integration technology and Platform

For integrating SAP systems with Non SAP systems
For integrating A2A and B2B applications
For synchronous and asynchronous exchange of messages
For cross component Business Process Management


Need for Middleware

Common definition is that middleware is the "glue" between software components or between software and the network or it is the slash in Client/Server.

• This is about those forms of middleware that are used to connect applications to other applications. We generally refer to the use of this type of middleware as Enterprise Application Integration or EAI. EAI middleware mediates between applications in a number of ways, but most commonly we think in terms of the transformation and routing of data and the orchestration of business process flows.
• There is the implication here that these applications reside in a heterogeneous world--different operating platforms, disparate data models and data stores, and heterogeneous network and communications protocols.

Overview of XI

Success of XI over Other Commercial EAI tools:

• Reduced maintenance costs: As the client replaced multiple integration technologies with SAP XI, it gained immediate cost savings by reducing associated maintenance costs. Additionally, the client gained the capability to utilize its manpower more effectively.

• Enhanced message monitoring functionality: As SAP XI provides auto handling of persistence of messages, it has enabled the client to monitor and restart failed messages. This has also eliminated the possibility of redundant/duplicate data into the system along with related efforts to identify the same. As all messaging is routed through one system, the client needs to monitor only SAP XI instead of having to monitor four systems: (Web Application system, XML parser application, VB based application) in the existing set up

• Enhanced flexibility: The ability to modify applications and add new functionalities without impacting other systems and businesses gave the client tremendous flexibility in reacting to dynamic changes in the market.

• Standardizes on the technology integration layer that would be used for connectivity between all systems

• Eliminate the need for “point-to-point” connectivity between systems

• Achieve a central monitoring of message flow, instead of having to monitor several systems

Enterprise IT motto

• Yesterday
Most conventional or traditional enterprise applications were custom built to address a specific business need.

• Today
The present advanced enterprise application’s addresses multiple business tasks, with each landscape having a higher degree of heterogeneous complexity.

• Difference in picture : Middleware/EAI
Integration solutions enable many applications/companies to create a ‘single view’ of all their enterprise data and an infrastructure ensuring that applications can exchange and update business central data, no matter where it resides.

Evolution of SAP

At first a single database integration in a single centralized data model: In one system with several applications one database, (e.g. an R/3 system with MM, SD, CO, FI, HR, …) with the applications having access to the data structures across the components. Integration in this case is and was fairly easy.

Then SAP and 3rd party vendors provided other solutions as e.g. CRM. SRM,.. These solutions and their respective systems needed to be integrated to the ERP environment (e.g. an R/3 backend system). This brought added complexity and the beginning of many individual point-to-point connections.

With the SAP Exchange Infrastructure and collaborative business, SAP approaches the integration challenge from a different angle. The basic idea is to provided 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 message flow from one application to the other, have a centralized storage of the integration knowledge.

Business drivers of Integration Projects:

· New Systems haven’t replaced the existing legacy systems
· Necessity to consolidate and globalize the business
· Search for increased productivity
· Raised expectations from Web applications/experiences

Types of Integration Solutions:

• Data Coordination
Mainly deals with transactional data between applications.

• Business Process Management/Orchestration
Mainly focuses on modeling and orchestrating the workflow between individual functions and applications.

• Business Activity Monitoring
Goal is to provide management with immediate awareness of changing business events across the enterprise.

• Composite Application Development
Combines the data and functionality of an enterprise’s existing ones with new business process logic, custom code and user -facing front ends.

Middleware flow:

Component view of XI

XI is not a single component, but rather a collection of components that work together flexibly to implement integration scenarios.

Integration Builder: A client-server framework for accessing and editing two stores of Shared Collaboration knowledge. It has two parts, which are fat clients to SLD where we can import the objects and use them locally. The basic reason for separating Integration Repository from Integration Directory is because by separating design time activities from configuration time activities, SAP can ship content from the Integration Repository, which each customer can implement for their specific landscape in the Integration Directory.

Integration Repository: It is used for the design and development of interface, Process and Mapping objects that are used to implement Integration Scenarios. Usually they contain static objects, which can be used for different landscapes by defining the routing rules in Integration Directory.

Integration Directory: They contain dynamic objects where in we configure scenarios using the objects from Integration Repository and route the messages between systems.
Integration Server: This component provides run time for XI. This is central processing engine of XI.

Business Process Engine: Business Process Engine enables SAP Netweaver with BPM capability by processing integration processes at runtime. BPE uses functions of the workflow engine and generates workflow from integration process at runtime.

Integration Engine: Integration engine enables processing of XML messages that are exchanged between applications in heterogeneous system landscapes. Using adapters such as IDoc, http, it can process IDocs(Intermediate documents), http requests and Remote Function Calls. It is runtime environment of SAP Exchange Infrastructure, which has the task of receiving, processing and forwarding XML messages. Processing is done with the evaluation of Collaboration agreements, by determination of receivers and execution of mapping programs.
Adapter Engine: Adapter engine is used to connect Integration Engine to SAP systems and external systems. Various types of adapters are provided to convert XML and HTTP based messages to the specific message protocol and format required by the partner systems and vice-versa. It is based on adapter framework, in turn based on SAP J2EE Engine (as part of the SAP Web Application Server) and J2EE Connector Architecture (JCA).