Structure of the Adapter Framework 

Purpose

The Adapter Framework is part of the Adapter Engine and the PCK. It provides interfaces for configuring, managing, and monitoring adapters. The Adapter Framework is used to connect any external system to the Integration Server.

Implementation Considerations

The Adapter Framework is based on the AS Java runtime environment and the J2EE Connector Architecture (JCA).

Integration

The Adapter Framework is responsible for communication between the Integration Server and any SAP or non-SAP systems.

In the figure, the components Integration Server, Integration Directory, System Landscape Directory, Runtime Workbench, and Integration Repository are shown on the left. The Adapter Framework and its modules are shown in the middle and the external system to be connected is on the right. The following are examples of external systems:

●     An ERP system such as Peoplesoft

●     A CRM system such as Siebel

●     A data pool such as UCCnet

●     A Web service

●     An EDI subsystem

All SAP components are shown in gray. The components that you must or should provide for adapter development are shown in orange, as is the external system to be connected.

Features

...

The Adapter Framework communicates using JCA 1.0 connections (2) and the JCA 1.0 Common Client Interface (CCI) with an adapter. The JCA 1.0 container of the SAP J2EE server uses the JCA 1.0 Service Programming Interface (SPI) to exchange server-relevant information with the adapter according to JCA 1.0 (1). Therefore, the adapter must be a JCA 1.0-compliant resource adapter. Since JCA 1.0 does not define the communication direction from the adapter to the Adapter Framework (application in the JCA sense), the Adapter Framework is called from the adapter with a standard Enterprise JavaBean 2.0 session bean.

A message from the Integration Server is received in the Adapter Framework by the messaging service. Based on the receiver information, the corresponding module chain is selected in the module processor for further processing.

The Adapter Framework contains two default module chains: one for the sender/inbound direction and one for the receiver/outbound direction. You can use these default module chains for your adapter if the entire message processing is executed within the adapter.

You can enhance the default module chains with customer-specific modules. The module processor controls the steps in the module chain by calling generic and, if defined, adapter-specific modules (3). The last module in the module chain forwards the message to the adapter using JCA CCI (2). The adapter transfers the message to the connected system.

Message processing in the sender/inbound direction proceeds in a similar way. In this case, the adapter calls the module processor in the form of an Enterprise JavaBean 2.0 local session bean and transfers the message object either as an XI message or in its own format. In the latter case, conversion to an XI message must then take place in an adapter-specific module.

In addition to message exchange, the Adapter Framework provides other interfaces that either must, should, or can be supported by the adapter.

●     Configuration services (J2EE service and adapter metadata xsd) (4)

The configuration service accesses the configuration data of the adapter and the information from the System Landscape Directory (SLD).

○     The configuration data for the adapter is managed in the Integration Directory. It contains technical data for the adapter and collaboration agreements for B2B scenarios. The configuration data is synchronized with the Adapter Framework. To do this, it manages a separate distributed configuration cache (CPA cache). Adapters can poll their configuration data or subscribe to data changes.

To use a new adapter type, the adapter must first be described in the form of adapter metadata, which is then loaded into the Integration Repository. This must be done before the adapter can be used.

○     The System Landscape Directory (SLD) manages and saves data from all (including non-SAP) components that a customer has in its system landscape. SAP business systems, the XI Integration Server, adapters, and other systems can be described here. The synchronization with the SLD is executed principally in the configuration service. The respective adapter does not have to be able to communicate with the SLD.

●     Administration services (5)

The Runtime Workbench (RWB) is a central tool for monitoring message processing, monitoring (including the adapters), and testing individual components. Whereas the RWB accesses the Adapter Framework audit log to monitor message processing, there is a special service that queries the status of an adapter using a defined interface. Interfaces are also provided that inform the adapter when the adapter instance is started and stopped. Unlike in JCA 1.5, JCA 1.0 does not have a standard solution for this. The administration services are implemented partly as J2EE services and partly as Enterprise JavaBeans.

●     The Adapter Framework provides various service APIs (Thread Manager, Transaction Manager), which support adapter implementation (6).

●     The Adapter Framework contains a general logging API, which is also used internally by the Adapter Framework components. It enables adapters to use the file- and database-based SAP J2EE logging and tracing mechanisms. Moreover, it enables audit log entries to be written to a database table. Access to the SAP-wide Process Monitoring Infrastructure (PMI) and simple performance measurements are integrated and can be used. The logging API (7) is different to all other interfaces in that it is a J2SE library and not a JCA CCI or a message inflow interface.

●     Messages that are transported through the Adapter Framework contain the business document in an XML-encoded format. The describing xsd, dtd, and WSDL documents (message metadata) are related to the sender business system. If the structure of the document from the sender system is different to that of the receiver system, the message must be mapped before it is forwarded to the receiver system. To execute the mapping at design time, the message metadata is required. This data is usually located in the Integration Repository. Before message exchange, you must load the message metadata to the Integration Repository manually (8).

Constraints

The figure does not show possible deployment variants, such as the distribution of components in the SAP J2EE server landscape.