Aufbau des Adapter-Framework 

Einsatzmöglichkeiten

Das Adapter-Framework ist Bestandteil der Adapter-Engine und des PCK. Es stellt Interfaces zur Konfiguration, Verwaltung und Überwachung von Adaptern zur Verfügung. Über das Adapter-Framework wird die Verbindung eines beliebigen externen Systems zum Integration Server hergestellt.

Einführungshinweise

Das Adapter-Framework basiert auf der der Laufzeitumgebung des AS Java und der J2EE Connector Architecture (JCA).

Integration

Das Adapter-Framework ist für die Kommunikation des Integration Server mit beliebigen SAP und Nicht-SAP-Systemen verantwortlich.

Auf der Grafik sind die Komponenten Integration Server, Integration Directory, System Landscape Directory, Runtime Workbench, Integration Repository links abgebildet. In der Mitte steht das Adapter-Framework mit seinen Bausteinen und rechts ist ein anzuschließendes externes System abgebildet. Beispiele für externe Systeme sind:

●     Ein ERP System wie Peoplesoft

●     Ein CRM System wie Siebel

●     Ein Datenpool wie UCCnet

●     Ein Web Service

●     Ein EDI Subsystem.

Alle SAP-Komponenten sind grau dargestellt. Die Komponenten, die Sie im Rahmen der Adapter-Entwicklung bereitstellen müssen bzw. sollten und das anzuschließende externe System sind orange dargestellt.

Funktionsumfang

...

Das Adapter-Framework kommuniziert über JCA 1.0-Verbindungen (2) und das JCA 1.0 Common Client Interface (CCI) mit einem Adapter. Der JCA 1.0 Container des SAP J2EE Server verwendet das JCA 1.0 Service Programming Interface (SPI), um mit dem Adapter gemäß JCA 1.0 die Server-relevanten Informationen auszutauschen (1). Daher wird gefordert, dass der Adapter ein JCA 1.0 konformer Resource Adapter ist .Da JCA 1.0 nicht die Kommunikationsrichtung vom Adapter zum Adapter-Framework (Anwendung im Sinne von JCA) definiert, wird das Adapter-Framework vom Adapter mit einem Standard Enterprise JavaBeans 2.0 Session-Bean aufgerufen.

Eine Message, die vom Integration Server kommt, wird im Adapter-Framework vom Messaging Service entgegengenommen. Aufgrund der Empfängerinformationen wird die entsprechende Modulkette im Modul-Prozessor zur weiteren Verarbeitung ausgewählt.

Das Adapter-Framework enthält zwei Standardmodulketten, eine für die Sender-/Inbound-Richtung, eine für die Empfänger-/Outbound-Richtung. Sie können diese Standardmodulketten für Ihren Adapter verwenden, wenn die gesamte Message-Verarbeitung innerhalb des Adapters durchgeführt wird.

Die Standardmodulketten können durch kundenspezifische Module ergänzt werden. Der Modul-Prozessor kontrolliert die Schritte in der Modulkette durch den Aufruf von generischen und, falls solche definiert sind, adapterspezifischen Modulen (3). Das letzte Modul in der Modulkette leitet die Message über JCA CCI (2) an den Adapter weiter. Der Adapter übergibt die Message an das angeschlossene System.

Die Message-Verarbeitung in Sender-/Inbound-Richtung verläuft ähnlich. Hier ruft der Adapter den Modul-Prozessor in Form einer Enterprise JavaBeans 2.0 Local-Session-Bean und übergibt das Message-Objekt entweder als XI-Message oder in einem eigenen Format. Im letzten Fall muss anschließend die Konvertierung in eine XI-Message in einem adapterspezifischen Modul erfolgen.

Über den Message-Austausch hinaus stellt das Adapter-Framework weitere Interfaces bereit, die der Adapter entweder unterstützen muss oder sollte oder könnte.

●     Konfigrations-Services (J2EE-Service und Adaptermetadaten-xsd) (4)

Der Konfigurations-Service greift auf die Konfigurationsdaten des Adapters und die Informationen aus dem System Landscape Directory (SLD) zu.

○     Die Konfigurationsdaten für den Adapter werden im Integration Directory verwaltet. Sie enthalten technische Daten des Adapters und Kollaborationsvereinbarungen für B2B-Scenarios. Die Konfigurationsdaten werden mit dem Adapter-Framework synchronisiert. Dazu verwaltet es einen eigenen verteilten Konfigurations-Cache (CPA-Cache). Adapter können ihre Konfigurationsdaten pollen oder sich auf Änderungen der Daten subskribieren.

Um einen neuen Adaptertyp zu nutzen, muss der Adapter zunächst in Form von Adaptermetadaten beschrieben werden, die dann in das Integration Repository geladen werden. Erst dann kann der Adapter verwendet werden.

○     Das System Landscape Directory (SLD) verwaltet und speichert Daten von allen (auch Nicht-SAP)-Komponenten, die ein Kunde in seiner Systemlandschaft hat. SAP Business-Systeme, der Integration Server, Adapter und andere Systeme können hier beschrieben werden. Die Synchronisation mit dem SLD wird hauptsächlich im Konfigurations-Service durchgeführt. Der jeweilige Adapter muss nicht in der Lage sein, mit dem SLD zu kommunizieren.

●     Administrations-Services (5)

Die Runtime Workbench (RWB) ist ein zentrales Werkzeug zur Überwachung der Message-Verarbeitung, zum Monitoring (auch der Adapter), und zum Testen einzelner Komponenten. Während die RWB zur Überwachung der Message-Bearbeitung auf das Adapter-Framework Audit-Protokoll zurückgreift, gibt es ein speziellen Dienst, der über eine definierte Schnittstelle den Status eines Adapters abfragt. Zusätzlich werden Schnittstellen angeboten, die den Adapter über das Starten und Stoppen der Adapterinstanz informieren, wofür es in JCA 1.0 im Gegensatz zu JCA 1.5 keine Standardlösung gibt. Die Administrationsdienste sind teilweise als J2EE Service und teilweise als Enterprise JavaBeans implementiert.

●     Das Adapter-Framework stellt unterschiedliche Service-APIs (Thread Manager, Transaction Manager) zur Verfügung, die die Implementierung von Adaptern unterstützen (6).

●     Das Adapter-Framework enthält ein allgemeines Logging-API, das auch von den Adaper-Framework-Komponenten intern verwendet wird. Es erlaubt Adaptern, die datei- und datenbankbasierten SAP J2EE Log- und Trace-Mechanismen zu nutzen. Es können außerdem Audit-Protokolleinträge in eine Datenbanktabelle geschrieben werden. Der Zugriff auf die SAP-weite Process Monitoring Infrastructure (PMI) und einfache Performance-Messungen sind integriert und können genutzt werden. Im Gegensatz zu allen anderen Interfaces ist das Logging-API (7) eine J2SE-Bibliothek und nicht ein JCA CCI oder ein Message-Inflow-Interface.

●     Messages, die durch das Adapter-Framework transportiert werden, enthalten das Business-Dokument in einem XML-kodierten Format. Die beschreibenden xsd, dtd und WSDL-Dokumente (Message-Metadaten) sind an das sendende Business-System gebunden. Wenn die Struktur des Dokuments vom Sendersystem von der des Empfängersystems abweicht, dann muss die Message gemappt werden, bevor die Message an das Empfänger-System weitergeleitet wird. Um das Mapping zur Design-Zeit durchzuführen, werden die Message-Metadaten benötigt. Üblicherweise befinden sich diese Daten im Integration Repository. Vor dem Message-Austausch müssen die Message-Metadaten von Hand in das Integration Repository geladen werden (8).

Einschränkungen

Die Grafik zeigt nicht eventuelle Deployment-Varianten wie z.B. die Verteilung der Komponenten in der SAP J2EE-Serverlandschaft.