Aufbau des Adapter-Framework

Der JCA 1.0 Container des AS Java verwendet das JCA 1.0 Service Programming Interface (SPI), um mit dem Adapter gemäß JCA 1.0 die Server-relevanten Informationen auszutauschen (1).

Der Adapter muss ein JCA 1.0 konformer Resource Adapter sein. JCA 1.0 definiert nicht die Kommunikationsrichtung vom Adapter zum Adapter-Framework (Anwendung im Sinne von JCA). Daher wird das Adapter-Framework vom Adapter mit einem Standard Enterprise JavaBeans 2.0 Session-Bean aufgerufen.

Das Adapter-Framework kommuniziert über JCA 1.0-Verbindungen (2) und das JCA 1.0 Common Client Interface (CCI) mit einem Adapter.

Eine Message, die in einem Dual-Stack PI System vom Integration Server oder in der Advanced Adapter Engine Extended von einem externen System 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 Senderrichtung, eine für die Empfängerrichtung. Wird die gesamte Message-Verarbeitung innerhalb des Adapters durchgeführt, können Sie diese Standardmodulketten für Ihren Adapter verwenden.

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 in Empfängerrichtung an das angeschlossene System.

Die Message-Verarbeitung in Senderrichtung 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.

• Konfigurations-Services (API 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 in Form von Adaptermetadaten beschrieben werden, die in das Enterprise Services Repository geladen werden. Erst dann kann der Adapter verwendet werden.

  • Das 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.

    Die Registrierung des Adapters am SLD übernimmt ein Adapter-Framework Service auf Basis der Adaptermetadaten.

• Administrations-Services (5)

  Runtime Workbench (RWB) und der SAP NetWeaver Administrator sind Werkzeuge der Process Integration zur Überwachung und Administration. Das Monitoring umfasst die Überwachung der Message-Verarbeitung, den Zustand der Kommunikationskanäle, der Prozesse und Komponenten.

  Die Administration umfasst die Einplanung von Jobs (Lösch- und Archivierungs-Jobs, das periodische Starten und Stoppen von Kommunikationskanälen), das manuelle Starten und Stoppen von Kommunikationskanälen und das wiederholte Starten von Messages.

  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.

• 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 stellt ein Message-Audit-Log-API (7) bereit, das auch von den Adaper-Framework-Komponenten intern verwendet wird.

  Es können Audit-Protokolleinträge in eine Datenbanktabelle geschrieben werden, ohne an der Datenbanktransaktion der Message-Verarbeitung teilzunehmen.

  Der Zugriff auf die SAP-weite Process Monitoring Infrastructure (PMI) und einfache Performance-Messungen sind integriert und können genutzt werden.

  Mit dem API für den technischen Trace und das Logging können Sie Trace-Anweisungen schreiben, die die Ausführung des Codes beschreiben. Dieses Logging-API ist nicht Teil vom Adapter-Framework, sondern Teil vom AS Java.

• 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. Weicht die Struktur des Dokuments im Sendersystem von der des Empfängersystems ab, muss die Message gemappt werden. Um das Mapping zur Design-Zeit durchzuführen, werden die Message-Metadaten benötigt. Üblicherweise befinden sich diese Daten im Enterprise Services Repository. Vor dem Message-Austausch müssen die Message-Metadaten von Hand in das Enterprise Services Repository geladen werden (8).

Die Grafik zeigt nicht eventuelle Deployment-Varianten wie beispielsweise die Verteilung der Komponenten in der AS Java-Server-Landschaft.