Adapters Overview

Author: Jerome Delune

Objectives
After completing this session, you will be able to:
Understand the basic concepts of Adapters
Understand the concepts of the Adapter Engine
Understand the difference between Adapter Engine, Adapter
Framework and PCK.

SAP AG 2002, Adapters Overview, Jerome Delune, 2

What are adapters?

One that adapts, such as a device used to effect operative
compatibility between different parts of one or more pieces of
apparatus. (Dictionary definition)

An XI Adapter enables compatibility between the XI Integration

Server and an application system
As such, the use of the XI Integration Server in conjunction with
selected adapters enables the compatibility between heterogeneous
business systems
Adapters are essential in the vast majority of todays customer
scenarios

SAP AG 2002, Adapters Overview, Jerome Delune, 3

Adapters are at the core of any integration scenario. Any customer scenario where external
applications are present is a use-case for adapters.
Adapters converts messages from the XI Protocol (SOAP with attachments over HTTP) to the
respective protocol spoken by the application system, and vice-versa.
The XI Integration Server itself would have very little purpose if the surrounding adapters were
not present (unless all application systems are based on SAP WebAS 6.20 or above, and use
proxy interfaces to communicate which is not yet a reality in customer landscapes).
The key premise of XI is its very nature to integrate heterogeneous systems, and the adapters
are the enabling technology to do this.

Adapter categories
Adapters can be categorized based on their function:
Application adapters
SAP applications
Siebel, Oracle, PeopleSoft applications

Technical adapters
File systems (File/FTP)
RDBMS systems (JDBC)
Messaging systems (JMS)
Web Services (SOAP)
Mail servers (SMTP)
SAP Business Connector (SAPBC)
Marketplaces

Adapter Engine

Industry standard adapters

RosettaNet
CIDX

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP AG 2002, Adapters Overview, Jerome Delune, 4

Some use cases of application system connectivity. This represents a wide array
of heterogeneous systems in a typical IT landscape. The individual adapters will
be explained later.
The list is not exhaustive
Application adapters provide the connectivity to vendor-specific application
systems
Technical adapters provide the low-level connectivity but typically they are just a
gateway to an application system.
Industry standards are span semantics, connectivity and business process. Hence
the adapter alone is not sufficient. The concept of Business Package will be
explored later.

SAP XI Adapter Engine

J2EE-Based Adapter Engine

Home for the majority of XI Adapters
Fully integrated with XI landscape
Configuration

Adapter Engine

Software logistics
Adapter FW
Messaging
Queuing
Security Handling

JCA-Based Adapter Framework

Resource
Adapter

Administration and monitoring

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP AG 2002, Adapters Overview, Jerome Delune, 5

The J2EE-based Adapter Engine provides you with various adapters that you can use to connect
external systems to your Integration Engine. You can use these adapters to convert XI Protocolbased messages (SOAP w/attachments over HTTP) to the specific protocols and formats of the
respective external systems and the other way around.
Besides the J2EE-based Adapter Engine, you can also use the plain J2SE-based Adapter Engine.
Most XI adapters reside on the J2EE adapter engine. The only 2 exceptions are the plain HTTP
adapter and IDoc adapter, which both reside within the Integration Server (ABAP)
The AE is fully integrated with the XI landscape
All adapters (including IDoc and HTTP) are configured centrally in the Integration Directory. There you
can specify whether an adapter is to be located at the inbound channel (sender adapter) or at the
outbound channel (receiver adapter) of an Integration Engine

Reuse of Integration Directorys existing versioning and transport capabilities

Central administration and monitoring over adapters, Integration Server, Integration Engine
through Runtime Workbench
Adapters can be hosted separately, possible on another host
The J2EE adapter engine is based on the open JCA architecture. This is part of the J2EE standard.
As such, each individual adapter is referred to as a resource adapter. The JCA architecture allows
to plug in resource adapters, written by third-party vendors, SAP partners or customers.

JCA-based Adapter framework

Adapter framework is the main building block of the adapter
engine
Provider of core services
Adapters work as plug-ins to the Adapter
Framework
Adapter Engine
Adapter FW
Messaging
Queuing
Security Handling

Resource
Adapter

Adapter Development Kit - customers and

partners can develop adapters
SAP NetWeaver certification of 3rd party
adapters based on JCA adapter framework
Reselling of JCA adapters from selected
partners (iWay, Seeburger)

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP AG 2002, Adapters Overview, Jerome Delune, 6

The Adapter Engine is based on the adapter framework. The adapter framework is based on the
SAP J2EE Engine (as part of the SAP Web Application Server) and the J2EE Connector
Architecture (JCA). The adapter framework provides interfaces for configuration, management, and
monitoring of adapters.
Adapter Framework provides common functionality for Adapter Engine and SAP Partner Connectivity Kit

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 Adapter framework is at the core of the adapter engine. It provides the core services which are
common to all adapters: messaging, queuing and security handling. This is really the runtime of all
adapters.
This slide also explains the benefits of having an adapter framework which is based on the open
JCA standard. Te goal is to enable customers and partners to provide their own adapters through a
consistent architecture and certification process.
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 familiar with
Adapter Software Development Kit (ASDK) based SAP XI Adapter Framework (as SAP PCK) and includes
Adapter Framework Interface Specification, JCA sample adapter (incl. source code), Java Docs, xsd file

XI Adapter landscape: the big picture

Integration Repository / Integration Directory / System Landscape Directory

Integration Server
Business Process Engine
Integration Engine

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

and Monitoring
Adapter FW
Messaging
Queuing
Security Handling

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP AG 2002, Adapters Overview, Jerome Delune, 7

The adapter engine can be deployed centrally or locally.

When the Integration Server is installed, the central AE is automatically installed
as well.
Optionally the customer can deploy any number of local adapter engines. This can
be done for several reasons (see next slide)
The PCK is based on adapter framework and is intended for business partners
who do not have a full XI system. The PCK will be detailed later on.
Note that the IDoc adapter is not part of the J2EE adapter engine and resides
directly on the Integration Server host (ABAP stack). Same for the plain HTTP
adapter which is not pictured here.
The J2SE adapter engine was the main solution for XI 2.0. It is still provided with
XI 3.0 mainly for those customers who have already invested into it in the context
of their XI 2.0 project. The J2SE adapter engine provides a limited set of technical
adapters (File, JDBC, JMS, SOAP).

Resource
Adapter

SAP
System

Adapter FW
Messaging
Queuing
Security Handling

Resource
Adapter

Adapter Framework
Messaging
Queuing
Security Handling

Resource
Adapter

Adapter

File
DB
JMS

Optional local
Adapter Engine

Central
Adapter Engine
IDoc
Adapter

J2SE
Adapter
Engine

Partner Connectivity
Kit PCK Configuration

Central and Local Adapter Engine

Integration Server
Integration Engine
Optional local
Adapter Engine

Central
Adapter Engine

Adapter FW
Messaging
Queuing
Security Handling

Resource
Adapter

Resource
Adapter

Adapter Framework
Messaging
Queuing
Security Handling

Central adapter engine

Automatically installed with the Integration Server

Local adapter engine

Proximity to business system
Central configuration, local execution
Distribute adapters across several AE instances
SAP AG 2002, Adapters Overview, Jerome Delune, 8

Central AE is installed by default.

Any number of local AEs can be installed. The local AE needs its own instance of
the J2EE engine. The local AE can reside on any remote hosts, and several local
AEs can even coexist on the same host (even on the Integration Server host).
Many factors come into play when making a decision to use the central or local AE
The primary reason for using a local AE is the proximity to the business system. This may be
by choice (in order to optimize the performance) or because of miscellaneous technical /
networking issues (e.g. Operating system dependencies or Firewalls)
Even when the AE is deployed locally, the configuration and monitoring is done centrally via
the Integration Directory and Runtime Workbench, respectively. (as explained in one of the
previous slides)
Technical benefits of using one or several local adapter engines:
mitigate the risks of having a single point of failure (SPOF). Indeed if the central AE is used exclusively, it
becomes a SPOF (so is the Integration Server J2EE stack)
Distribute the load of the adapters

Adapters hosted in the J2EE Adapter Engine

Adapters developed by SAP
File / FTP
JDBC (Database)
JMS (WebSphere MQSeries, SonicMQ, )
RFC
SOAP
Mail
Business Connector (B2B protocol)
Marketplace Adapter
RosettaNet (RNIF 2.0) Adapter
CIDX (RNIF 1.1) Adapter

3rd Party Adapters

iWay: UCCnet, more to come
Additional adapters developed by partners, certified by SAP
SAP AG 2002, Adapters Overview, Jerome Delune, 9

All R/3 systems 4.6C and under can communicate using RFC and IDoc only. Therefore the RFC/IDoc adapter is necessary to integrate these systems with XI
Even SAP systems based on WebAS 6.20 and above, still rely heavily on RFC/IDoc interfaces and therefore the adapter is necessary

The RFC adapter enables you to use the functions of the Integration Engine in existing SAP system landscapes. It is used
by SAP systems to connect to the Integration Engine by using the RFC interface. It supports SAP systems as of version
3.1x.
Many Mainframe applications interface via flat files over FTP or at the OS level. Some rely on a messaging tool such as IBM MQSeries (WebSphereMQ), based on
JMS.

The file/FTP adapter enables you to exchange data with the Integration Server by means of a file interface or an FTP
server
The JDBC adapter enables you to connect database systems to the Integration Server. The adapter converts database
content to XML messages and the other way around.

Database content can be read with any SQL statement. A special XML format is defined for content
coming from the Integration Engine. This format enables SQL INSERT, UPDATE, SELECT, DELETE, or
stored procedure statements to be processed. A message is always processed in exactly one database
transaction.
The JDBC adapter connects to databases directly by handling SQL statements or procedures. Therefore it is not appropriate lets say
to connect to the database underlying an R/3 system

The JMS adapter enables you to connect messaging systems to the Integration Engine.
JMS adapter is typically used to connect to a JMS provider such as IBM WebSphere MQ (MQSeries) or Sonic MQ.

The SOAP adapter enables you to exchange SOAP messages between remote clients or Web service servers and the
Integration Server
Any interface which is exposed as a web service can be accessed via the SOAP adapter

You use the marketplace adapter to connect the Integration Server to marketplaces. It enables messages to be exchanged
by converting the XI message format to the marketplace format MarketSet Markup Language (MML) and the other way
around.
The RNIF (RosettaNet Implementation Framework) Adapter supports RosettaNet, a standard used for data communication
in the High-Tech industry.

The RNIF Adapter is based on the RosettaNet Implementation Framework (RNIF) version 2.0.
SMTP (simple mail transfer protocol) is used to interface with most mail servers by sending and receiving emails.
The SAPBC adapter enables the coexistence of the SAP Business Connector and SAP XI

Adapters not hosted in the J2EE Adapter Engine

These adapters are implemented in ABAP and reside directly on
the Integration Server (ABAP stack)

Integration Server
Integration Engine

IDoc adapter

Central
Adapter Engine

SAP
System

Adapter Framework
Messaging
Queuing
Security Handling

Resource
Adapter

HTTP
Client/
Server

IDoc
Adapter

Plain HTTP
Adapter

Plain HTTP adapter

SAP System
3rd Party Appl.
File/DB/JMS
Marketplaces

SAP AG 2002, Adapters Overview, Jerome Delune, 10

The IDoc adapter comprises two parts, namely an adapter at the Integration Server inbound
channel, and an adapter at the Integration Server outbound channel.
The plain HTTP adapter gives application systems the option of communicating with the
Integration Engine and exchanging business data using a plain HTTP connection. Depending
on the receiver system, outbound messages can be enhanced with certain information.
Their configuration is done centrally in the ID (as for all adapters) but the monitoring does not
go through the RWB. There are specific ABAP transactions to monitor these adapters.
Regarding the connectivity to SAP systems please note that the RFC adapter is hosted by the
J2EE adapter engine, while the IDoc adapter is hosted by the ABAP stack of the Integration
Server.

10

Adapters vs. proxies

Adapters
Connect existing (legacy) systems to XI
Specific wire protocol
Interface semantics externally pre-defined
Inside-out development approach

Proxies
Connect new SAP applications to XI
Native connectivity to Application system (adapter-less)
Interfaces designed centrally in Integration Repository
Outside-in development approach

SAP AG 2002, Adapters Overview, Jerome Delune, 11

It is important to understand that proxies and adapters are the 2 alternatives for connecting XI to an
application system
Typically for an existing system (any external system or even traditional SAP systems that only
communicate via RFC and IDoc), the interface semantics cannot be changed. Also in many cases
a specific, proprietary wire protocol must be used. This is exactly the scope of adapters. This is
also the premise of outside-in integration or a posteriori integration (cf next slide)
In the case of new SAP applications (ABAP or Java) the interface development process has
changed. The interface is designed centrally in the Integration Repository. From the interface
definition a proxy is generated in ABAP or Java. The proxy is deployed on the application system,
and the business application is built around it. This is the premise of inside-out integration
(integration by design).
A proxy is a fragment of code in ABAP or Java which serves 2 purposes:
Convert the data structures (ABAP or Java) into XML messages and vice-versa
Establish connectivity with the XI Integration Server

A proxy hides such technical details from the application developer.

It is important to note that for proxy communication, no specific adapter configuration is required.
However from the technical aspect, the proxy runtime itself resides on the adapter framework. The
point is that there is no protocol conversion necessary for communicating with XI using proxies.
For more information using proxies please refer to the XI fundamentals course or online
documentation.

11

The XI Use Spectrum

Integration by Design

A Posteriori Integration
Main focus of (current)
customer projects

Focus of SAP

Use XI to integrate
applications with proprietary /
existing / legacy technology or
semantics

Use XI/Web services to

model integrated
applications
based on open standards
Technical Web service
standards

Overcome existing structural

and semantics differences
Mapping

Industry Standards

Adapters

Proxies

Web service enabling

SAP AG 2002, Adapters Overview, Jerome Delune, 12

This slide illustrates the outside-in vs. inside-out approach.

The reality is that the vast majority of customer landscapes fall in the first
category. Hence the adapters play a key role in most customer projects.

12

Connectivity with SAP applications

Traditional applications
IDoc, BAPI interfaces
(t)RFC wire protocol
All applications based on Basis 4.6C and below
Most applications based on SAP Web AS 6.20 and above
Inside-out development approach

Adapters

New applications
Selected new functionality in SAP applications
Native HTTP connectivity
WebAS 6.20 or above
Outside-in development approach

Proxies
SAP AG 2002, Adapters Overview, Jerome Delune, 13

The choice of adapters vs proxies comes into play when connecting SAP applications
Before WebAS 6.20 the only connectivity option in/out of the SAP system is RFC/BAPI/IDoc
Starting with the WebAS 6.10 the native HTTP connectivity has been added to the basis layer
Starting with the WebAS 6.20, each application system has its own local integration engine and is
therefore able to connect to XI via proxies over HTTP / SOAP with attachments (XI protocol)
At the present time, the vast majority of SAP applications still fall in the first category (IDoc or
RFC/BAPI based)
This is true for all applications based on 4.6C and below. Since RFC/IDoc is the only technology
available for interfaces
This is still true for most applications based on WebAS 6.20 or above. Indeed most applications still use
RFC/BAPIs and IDocs

Newer applications are starting to emerge, which are based on the outside-in methodology
(proxies, native connectivity, no adapters).
At this point in time this is only a small set of SAP applications
As this is the long-term development strategy (towards ESA approach), this form of connectivity will gain
importance in the future and ultimately this will be the only form of interfaces in/out of SAP applications.

13

Role of adapters in SAP Busines Packages

Standard
scenarios

Integration
Repository

Integration
Directory

Business Scenarios
Application

standard
Business
Document
Schema

Routing Rules

Business Processes
Mappings

Collaboration Agreements

Message Interfaces

Collaboration Profiles

Business
Partner

Integration Server

SAP
Industry Solution
(e.g. High Tech)

Business Process Engine

IDoc/
Proxy

Integration Engine
Adapter Engine

3rd Party
Application

Resource
Adapter

Messaging
Queuing
Security Handling

Industry
Standard
Adapter

to
Business
Partner

SAP AG 2002, Adapters Overview, Jerome Delune, 14

SAP Business Packages for Industry Standards

Provides Solution Kits for specific industries and delivers mappings for RosettaNet, CIDX

Application adoption
Enhance business applications like mySAP CRM or mySAP SCM to support SAP Business Packages for high
priority processes

Mapping
Including message sets for the industries according their priority
Support mappings: versions, upgrade, maintenance

Process Integration
SAP Business Packages message protocol implementation (such as RNIF 2.0 and RNIF 1.1 for CIDX)
Provision of Collaboration Agreements

In the case of Industry standards support, the adapters play a key role in the SAP Business Packages, but
they are only part of the picture.
The idea of an SAP Business Package is to provide all levels of support for a given Industry Standards
Semantic level (mappings, interfaces)
Process level (BPM)
Application level (R/3, CRM, SCM,...)
Connectivity (adapters)

Adapter mappings and adapter metadata are stored in the Integration Repository
Centralized Integration Repository contains all relevant information for collaborative processes
All content adheres to open standards
Adapters provide technical connectivity

14

Adapter Configuration

Adapter independent
parameters

Adapter specific
parameters

SAP AG 2002, Adapters Overview, Jerome Delune, 15

15

SAP Partner Connectivity Kit Overview

Enablement of smaller companies / subsidiaries to exchange XML
documents with their business partners / headquarters SAP XI
Large Business Partner /
Headquarter

Smaller Company / Subsidiary

SAP
Application
SAP / 3rd
Party Appl.

SAP
PCK

Internet

SAP XI
3rd Party
Application

Providing a platform for development of own JCA Resource Adapters

SAP
PCK

SAP AG 2002, Adapters Overview, Jerome Delune, 16

The PCK will be detailed in one of the following units.

As already established the PCK is also based on the adapter framework.
PCK does not inherit central configuration data from the Integration Directory
PCK has its own user interface (which is a subset of the Integration Directory) for configuration
of individual adapters.

SAP Partner Connectivity Kit (PCK) is based on Adapter Framework

SAP PCKs objective is to enable XML document exchange between SAP XI and
business partner not using SAP XI
SAP PCK also provides an extensible platform for developing and running
individual JCA Resource adapters
Communication between SAP XI and SAP PCK is via SAP XI messaging protocol
SAP PCK Includes the following adapters: File/FTP, JDBC, JMS, SOAP, RFC,
IDoc (once available for SAP PCK)
Optionally SAP PCK can host further adapters that are available from SAP or 3rd
party adapter providers

16

Summary
Adapter Framework runs on J2EE Stack of SAP Web AS
Adapter Framework is platform for Adapter Engine and SAP PCK
Adapter Framework provides an extensible platform for
developing and running adapters in SAP XI environment
Adapter Engine utilizes central configuration, monitoring,
administration

SAP AG 2002, Adapters Overview, Jerome Delune, 17

17

Summary
You are now able to:
Understand the basic concepts of Adapters
Understand the concepts of the Adapter Engine
Understand the difference between Adapter Engine, Adapter
Framework and PCK.

SAP AG 2002, Adapters Overview, Jerome Delune, 18

18