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 /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 Directory’s 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.
Adapter framework is the main building block of the adapter engine.
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 .
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).
Wednesday, October 1, 2008
Subscribe to:
Post Comments (Atom)
Archives
-
▼
2008
(167)
-
▼
October
(145)
- SAP ALE ABAP DETIAL
- SAP ABAP ALE IDOC'S
- SAP - DIFFERENCE BETWEEN CONVERSION AND INTERFACE
- BAPI AND IDOC ALE
- SAP ABAP MESSAGE CONTORL
- SAP IDOC'S IN ABAP INTRODUCTION
- SAP ABAP IDOC'S OUTLOOK
- SAP ABAP IDOC PROCESSING
- SAP ABAP IDOC'S BASIC TOOLS I
- SAP ABAP IDOC'S BASIC TOOLS II
- SAP ABAP IDOC'S INBOUND BASIC TOOLS III
- SAP IDOC OUT BOUND TRIGGERS II
- SAP IDOCS OUTBOUND TRIGGER II
- SAP IDOC'S OUTBOUND TRIGGER III
- SAP Work flow based outbound Idoc's
- SAP ALE Change Pointers
- SAP Dispatching ALE IDocs for Change Pointers
- SAP IDOC design and Processing
- SAP Creation of the IDoc Data
- SAP Developing an Outbound IDoc Function
- SAP Converting Data into IDoc Segment Format
- SAP Partner Profiles and Ports
- SAP Defining the partner profile for ALE IDOC
- SAP Data Ports ( WE21 ) in idoc
- SAP RFC in R/3
- SAP Workflow from Change Documents
- SAP ALE Distribution Scenario
- SAP Useful ALE Transaction Codes
- BAPI Creating IDocs and ALE Interface
- R/3 RFC from MS Office Via Visual Basic
- SD WORK FLOW SCENARIOS I
- SD WORK FLOW SCENARIOS II
- SD WORK FLOW SCENARIOS III
- SD WORK FLOW SCENARIOS IV
- SD WORK FLOW SCENARIOS V
- SD WORK FLOW SCENARIOS VI
- SD WORK FLOW SCENARIOS VII
- MM WORK FLOW SCENORIOS I
- MM WORK FLOW SCENORIOS II
- MM WORK FLOW SCENORIOS III
- MM WORK FLOW SCENORIOS IV
- MM WORK FLOW SCENORIOS V
- MM WORK FLOW SCENORIOS VI
- MM WORK FLOW SCENARIOS VII
- MM WORK FLOW SCENARIOS VIII
- MM WORK FLOW SCENARIOS IX
- MM WORK FLOW SCENARIOS X
- MM WORK FLOW SCENARIOS XI
- WORK FLOW SCENARIOS in SAP ABAP
- SAP ABAP WORK FLOW I
- SAP ABAP WORK FLOW II
- SAP ABAP WORK FLOW III
- SAP ABAP Work Flow IV
- SAP ABAP Workflow Technology
- SAP OPTIMIZATION
- abap type key ward
- PERFORMENCE TIPS
- SAP ABAP INTERNAL TABLES IN BRIEF
- SAP ABAP RUN TIME ANALASIS
- MEMORY In SAP ABAP
- NAVIGATION In SAP ABAP
- WORK BENCH AND TOOLS In SAP ABAP
- DATA OBJECTS AND STATEMENTS In SAP ABAP
- INTERNAL PROGRAM MODULARIZATION In SAP ABAP
- SAP ABAP CONSITENCEY THROUGH INPUT CHECKS
- RUN TIME ENVIRONMENT In SAP ABAP
- SAP ABAP INTER TABLE OPERATIONS
- STATEMENTS In SAP ABAP
- SAP ABAP INTERNAL TABLES
- SAP ABAP SUB ROUTIENS
- SAP ABAP FUNCTION MODULES AND GROUPS
- SAP ABAP QUARY ADMINSTRATION
- SAP ABAP SAVING LISTS AND BACK GROUND PROCESSING
- SAP ABAP PROGRAM INTERFACE
- SAP ABAP LOCK CONCEPT
- SAP ABAP AUTHORISATION CHECKS
- SAP ABAP PERFORMENCE TIPS
- In SAP SYSTEM FIELDS
- SAP ABAP CONTROL BLOCKS
- SAP ABAP BUFFERING
- SAP ABAP MATCH CODE OBJECTS
- SAP ABAP LOCKS
- SAP SAMPLE CODE FOR OUTPUT TO EXCEL AND IN PUT FIL...
- SAP MULTIPLE INTERACTIVE REPORT SAMPLE CODE
- MULTIPLE INTERACTIVE REPORT SAMPLE CODE II
- CALLING PROGRAM AND PASSING DATA
- SAP TECHNIQUES FOR LIST CREATION AND SAP QUARY
- SAP SELECTION SCREENS ABAP REPORT
- SAP ABAP FAQ ON SCRIPTS I
- SAP ABAP FAQ ON SCRIPTS II
- SAP ABAP FAQ ON SCRIPTS III
- IN SAP ABAP TABLE TYPES
- SAP ABAP TYPES OF VIEWS
- SAP ABAP DATA BASE UPDATES COMPLETE
- SAP ABAP LOCK CONCEPT
- SAP ORGANIZING DATABASE UPDATES
- SAP ENHANCEMENTS TO DICTIONERY ELEMENTS
- DATA BASE DIALOG IN ABAP
- ABAP DICTIONARY I
- PERFORMANCE DURING TABLE ACCESS
-
▼
October
(145)
No comments:
Post a Comment