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.