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 Connector Architecture (JCA) version 1.0.

Integration

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

In the figure, the Integration Server, Integration Directory, System Landscape Directory, Runtime Workbench, and Enterprise Services 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. 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.

All Adapter Framework APIs can be referenced and called by using AS Java facades. The underlying Adapter Framework services, beans, and libraries are not called directly.

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 AS Java uses the JCA 1.0 Service Programming Interface (SPI) to exchange server-relevant information with the adapter according to JCA 1.0 (1).

The adapter must be a JCA 1.0-compliant resource adapter. JCA 1.0 does not define the communication direction from the adapter to the Adapter Framework (application in the JCA sense). Therefore, the Adapter Framework is called by 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 in the module processor is selected for further processing.

The Adapter Framework contains two default module chains: one for the sender direction and one for the receiver direction. If message processing is to be executed entirely within the adapter, you can use these default module chains for your 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 in the receiver direction, to the connected system.

Message processing in the sender 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 must, should, or can be supported by the adapter.

●      Configuration services (API 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 Enterprise Services 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 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.

An Adapter Framework service registers the adapter with the SLD based on the adapter metadata.

●      Administration services (5)

The Runtime Workbench (RWB) is a central tool for monitoring and administration in Process Integration. Monitoring covers the monitoring of message processing, and the status of communication channels, processes, and components.

Administration covers the scheduling of Jobs (delete and archiving jobs, the periodic starting and stopping of communication channels), the manually starting and stopping of communication channels, and the restarting of messages.

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 Adapter Framework provides various service APIs (Thread Manager, Transaction Manager), which support adapter implementation (6).

●      The Adapter Framework includes a message audit log API (7), which is also used internally by the Adapter Framework components.

Audit log entries can be written to a database table without the database transaction for message processing being involved.

Access to the SAP-wide Process Monitoring Infrastructure (PMI) and simple performance measurements are integrated and can be used.

You can use the API for the technical trace and logging to write trace statements that describe the execution of the code. This logging API is not part of the adapter framework but part of AS Java.

●      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 in the sender system differs from that of the receiver system, the message must be mapped. The message metadata is required to perform the mapping at design time. This data is usually located in the Enterprise Services Repository. Before message exchange, you must load the message metadata to the Enterprise Services Repository manually (8).

Restrictions

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