01 Adapters Overview

8/13/2019 01 Adapters Overview

1/18

1

Adapters OverviewAuthor: Jerome Delune


2/18

2

SAP AG 2002, Adapters Overview, Jerome Delune, 2

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.


3/18

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.


What are adapters?

An XI Adapter enables compat ib il ity 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 essent ial in the vast majority of todays customer

scenarios

One that adapts, such as a device used to effect operative

compatibili ty between different parts of one or more pieces of

apparatus. (Dictionary definition)


4/18

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.


Adapter categories

Adapters can be categorized based on thei r function:

Appl ication adaptersSAP 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

Industry standard adaptersRosettaNet

CIDX

Adapter Engine

SAP System

3rd Party App l.

File/DB/JMS

Marketplaces


5/18

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 Protocol-

based 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 theoutbound 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.


SAP XI Adapter Engine

J2EE-Based Adapter Engine

Home for the majority of XI Adapters

Fully integrated with XI landscape

Configuration

Software logistics

Administ rat ion and moni toring

JCA-Based Adapter Framework

Adapter Engine

Resource

Adapter

Adapter FW

Messaging

Queuing

Security Handling

SAP System

3rd Party App l.

File/DB/JMS

Marketplaces


6/18

6

The Adapter Engine is based on the adapter framework. The adapter framework is based on theSAP J2EE Engine (as part of the SAP Web Application Server) and the J2EE ConnectorArchitecture (JCA). The adapter framework provides interfaces for configuration, management, andmonitoring 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 avai lability, threadmanagement, 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 alladapters.

This slide also explains the benefits of having an adapter framework which is based on the openJCA standard. Te goal is to enable customers and partners to provide their own adapters through aconsistent 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 Javaapplication

JCA enabled Adapter Framework provides defined interfaces to which both our adapters and 3rd party adapterscan 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 includesAdapter Framework Interface Specification, JCA sample adapter (incl. source code), Java Docs, xsd file


JCA-based Adapter framework

Provider of core services

Adapters work as plug-ins to the Adapter

Framework

Adapter Development Kit - customers and

partners can develop adapters

SAP NetWeaver certi fication of 3rd party

adapters based on JCA adapter framework

Reselling of JCA adapters from selectedpartners (iWay, Seeburger)

Adapter Engine

Resource

Adapter

Adapter FW

Messaging

Queuing

Security Handling

SAP System

3rd Party App l.

File/DB/JMS

Marketplaces

Adapter framework is the main building block of the adapter

engine


7/18

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


XI Adapter landscape: the big picture

Integration Server

J2SE

Adapter

Engine

Optional local

Adapter Engine

Central

Adapter Engine

Business Process Engine

Integration Engine

Adapter Framework

Messaging

Queuing

Security Handling

Resource

Adapter

Resource

Adapter

Partner Connectivity

Ki t

Resource

Adapter

Adapter FW

Messaging

Queuing

Security Handling

Adapter FW

Messaging

Queuing

Security Handling

PCK Configuration

and Monitoring

IDoc

Adapter

Adapter

File

DB

JMSSAP

System

SAP System

3rd Party Appl.

File/DB/JMS

Marketplaces

SAP System

3rd Party Appl.

File/DB/JMS

Marketplaces

SAP System

3rd Party App l.

File/DB/JMS

Marketplaces

Integration Repository / Integration Directory / System Landscape Directory


8/18

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


Central and Local Adapter Engine

Integration Server

Integration Engine

Optional localAdapter Engine

CentralAdapter Engine

Adapter Framework

Messaging

Queuing

Security Handling

Resource

Adapter

Resource

Adapter

Adapter FW

Messaging

Queuing

Security Handling

Central adapter engine

Automat ically installed with the Integration Server

Local adapter engine

Proximity to business system

Central configuration, local execution

Distribute adapters across several AE instances


9/18

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 usedby SAP systems to connect to the Integration Engine by using the RFC interface. It supports SAP systems as of version3.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 onJMS.

The file/FTP adapter enables you to exchange data with the Integration Server by means of a file interface or an FTPserver

The JDBC adapter enables you to connect database systems to the Integration Server. The adapter converts databasecontent to XML messages and the other way around.

Database content can be read with any SQL statement. A special XML format is defined for contentcoming from the Integration Engine. This format enables SQL INSERT, UPDATE, SELECT, DELETE, orstored 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 theIntegration 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 exchangedby converting the XI message format to the marketplace format MarketSet Markup Language (MML) and the other wayaround.

The RNIF (RosettaNet Implementation Framework) Adapter supports RosettaNet, a standard used for data communicationin 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 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

Addi tional adapters developed by partners, cer ti fied by SAP


10/18

10

The IDoc adapter comprises two parts, namely an adapter at the Integration Server inboundchannel, and an adapter at the Integration Server outbound channel.

The plain HTTP adapter gives application systems the option of communicating with theIntegration 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 notgo 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 theJ2EE adapter engine, while the IDoc adapter is hosted by the ABAP stack of the Integration

Server.


Adapters not hosted in the J2EE Adapter Engine

These adapters are implemented in ABAP and reside directly on

the Integration Server (ABAP stack)

IDoc adapter

Plain HTTP adapter

Integration Server

Central

Adapter Engine

Integration Engine

Adapter Framework

Messaging

Queuing

Security Handling

Resource

Adapter

IDoc

Adapter

SAPSystem

SAP System

3rd Party App l.

File/DB/JMS

Marketplaces

PlainHTTP

Adapter

HTTPClient/Server


11/18

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.


Adapters vs. proxies

Adapters

Connect exist ing (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


12/18

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.


The XI Use Spectrum

Main focus of (current)

customer projects

Use XI to integrate

applications with proprietary /

existing / legacy technology orsemantics

Overcome existing s tructural

and semantics differences

Mapping

Adapters

Web service enabling

Focus of SAP

Use XI/Web services to

model in tegrated

applicationsbased on open standards

Technical Web service

standards

Industry Standards

Proxies

A Poster ior i Integration Integration by Design


13/18

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 technologyavailable for interfaces

This is still true for most applications based on WebAS 6.20 or above. Indeed most applications still useRFC/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 gainimportance in the future and ultimately this will be the only form of interfaces in/out of SAP applications.


Connectivity with SAP applications

Traditional applications

IDoc, BAPI interfaces

(t)RFC wire protocol Al l appl ications based on Basis 4.6C and below

Most appl ications based on SAP Web AS 6.20 and above

Inside-out development approach

Adapters

New applications

Selected new funct ionality in SAP applications

Native HTTP connectivity

WebAS 6.20 or above

Outside-in development approach

Proxies


14/18

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 highpriority 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, butthey 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


Role of adapters in SAP Busines Packages

Integration

RepositoryIntegration

Directory

Message Interfaces

Business Processes

Mappings

Business Scenarios

Collaboration Profiles

to

Business

Partner

Standard

scenarios

Application

standard

Business

Document

Schema

Business

Partner

Collaboration Agreements

SAP

Industry Solution

(e.g. High Tech)IDoc/

Proxy

3rd Party

Appl ication

Integration Server

Adapter Engine

Business Process Engine

Integration Engine

Resource

Adapter

Messaging

Queuing

Security Handling

Industry

Standard

Adapter

Routing Rules


15/18

15


Adapter Configuration

Adapter independent

parameters

Adapter speci fic

parameters


16/18

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


SAP Partner Connectivity Kit Overview

SAP / 3rd

Party Appl.SAP XI

Smaller Company / Subsid iary

SAP

PCK

SAP

Appl ication

3rd Party

Appl ication

Large Business Partner /Headquarter

Internet

Enablement of smaller companies / subsidiaries to exchange XML

documents with their business partners / headquarters SAP XI

SAP

PCK

Providing a platform for development of own JCA Resource Adapters


17/18

17


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 uti lizes central configurat ion, moni tor ing,

administration


18/18


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.

01 Adapters Overview

Documents

Transcript of 01 Adapters Overview