WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Ereignisgesteuerte Datenbankintegration

Verwenden Sie zur Reaktion auf Ereignisse in einer Datenbank einen DatabaseInput-Knoten. Der Broker kann beispielsweise ein externes System mit einer Datenbank synchron halten, indem er dem Zielsystem Aktualisierungen zusendet, sobald sich Daten in der Datenbank ändern.

Die Datenbank muss die Tatsache, dass sich Daten geändert haben, in einem Ereignisspeicher, in der Regel einer Datenbanktabelle, aufzeichnen. Der Inhalt des Ereignisspeichers ist nicht identisch mit den Anwendungsdaten. Folgendes Diagramm zeigt die Interaktion zwischen der Datenbank, dem Ereignisspeicher und dem Broker:

Diese Abbildung wird im nachfolgenden Text näher beschrieben.
  1. Eine Datenbankanwendung ändert eine Datenbanktabelle.
  2. Das Datenbankmanagementsystem (DBMS) zeichnet die Änderung im Ereignisspeicher auf.
  3. Der Broker fragt den Ereignisspeicher in dem in der Konfigurationseinstellung Abfrageintervall angegebenen Intervall ab.
  4. WebSphere Message Broker ruft die neuen oder geänderten Daten ab und aktualisiert den Ereignisspeicher, um sicherzustellen, dass die Daten nur einmal verarbeitet werden.
  5. WebSphere Message Broker verarbeitet die Daten und zeigt sie schließlich in der Zielanwendung, zum Beispiel in SAP, Web-Services oder CICS Transaction Server for z/OS an. Die Daten können bei Bedarf in einem anderen logischen und physischen Format dargestellt werden.

Implementierung

Die Implementierung dieses Szenarios umfasst die folgenden Schritte:
  1. Datenbank für die Aufzeichnung von Ereignissen konfigurieren
  2. Format festlegen, in dem das Zielsystem die Daten dieser neuen Ereignisse empfangen muss
  3. Broker mit dem DatabaseInput-Knoten für die Erkennung dieser Ereignisse konfigurieren (Informationen zur Konfiguration des DatabaseInput-Knotens finden Sie im Abschnitt DatabaseInput-Knoten konfigurieren)
  4. Den Rest des Nachrichtenflusses so konfigurieren, dass die Daten auf dem Zielsystem im richtigen Format dargestellt werden

Der DatabaseInput-Knoten

Folgendes Diagramm zeigt die Funktionsweise des DatabaseInput-Knotens.

Beim Start des Prozesses überprüft ReadEvents den Ereignisspeicher auf neue Ereignisse, die von BuildMessage zur Erstellung der Nachricht verwendet werden. Diese Nachricht wird an den Nachrichtenfluss weitergegeben. EndEvent aktualisiert daraufhin den Ereignisspeicher, um sicherzustellen, dass das Ereignis nicht noch einmal verarbeitet wird.

Beim Start des Prozesses überprüft ReadEvents den Ereignisspeicher auf neue Ereignisse, die von BuildMessage zur Erstellung der Nachricht verwendet werden. Diese Nachricht wird an den Nachrichtenfluss weitergegeben. EndEvent aktualisiert daraufhin den Ereignisspeicher, um sicherzustellen, dass das Ereignis nicht noch einmal verarbeitet wird. Wenn alle Ereignisse verarbeitet sind, ruft der Broker erneut ReadEvents auf, um alle Ereignisse abzurufen, die seit der letzten Prüfung hinzugekommen sind. Wenn der Ereignisspeicher leer ist, wartet der Broker bis zum Ablauf des Abfrageintervalls und ruft ReadEvents dann erneut auf. Zur Vermeidung von Konflikten erfolgt die Überprüfung des Ereignisspeichers in einem Thread.

BuildMessage erstellt für jedes von ReadEvents gelesene Ereignis eine Nachricht, die an den Nachrichtenfluss übergeben wird. Zur Erstellung der Nachricht werden die erforderlichen Daten in der Regel anhand der Ereignisdaten in der Anwendungstabelle gesucht. Aus den Daten der Anwendungstabelle wird dann die Nachricht erstellt. Nach Beendigung von BuildMessage wird die Nachricht automatisch an den Nachrichtenfluss weitergegeben. Daraufhin startet der Broker alle nachfolgenden Knoten, die zur Verarbeitung der Nachricht erforderlich sind.

Nach der Weitergabe der Nachricht an den Nachrichtenfluss aktualisiert EndEvent den Ereignisspeicher, um sicherzustellen, dass das eben verarbeitete Ereignis nicht noch einmal verarbeitet wird.

Die Aktionen von ReadEvents, BuildMessage und EndEvent werden durch ESQL-Code gesteuert. Hierfür enthält der DatabaseInput-Knoten ein ESQL-Modul mit Mustercode und Kommentaren, die Sie an Ihre Anforderungen anpassen können. Informationen zur Bearbeitung des ESQL-Codes finden Sie im Abschnitt DatabaseInput-Knoten konfigurieren.

Transaktionen und Skalierung

Die vom DatabaseInput-Knoten ausgeführten Prozesse sind auf mehrere Transaktionen aufgeteilt. Beim Start von ReadEvents wird eine neue Transaktion gestartet. Bei der Beendigung von ReadEvents wird diese Transaktion festgeschrieben und neue Ereignisse werden zur Verarbeitung gekennzeichnet. Durch die Festschreibung dieser Transaktion werden sämtliche Datenbanksperren freigegeben, die durch den von ReadEvents ausgeführten ESQL-Code gesetzt wurden. Danach wird für jedes Ereignis, das bei BuildMessage eingeht, eine neue Transaktion gestartet. Diese neue Transaktion wird festgeschrieben, nachdem EndEvent abgeschlossen ist.

Zur Skalierung eines DatabaseInput-Knotens für mehrere Ereignisse müssen Sie die Eigenschaft Zusätzliche Instanzen auf der Registerkarte Instanzen auf die benötigte Anzahl an Instanzen setzen (der Standardwert ist 0). Wenn Sie mehrere Instanzen einsetzen, muss die Datenbank so konfiguriert werden, dass mehrere Anwendungen gleichzeitig verschiedene Zeilen aus der Anwendungstabelle lesen können. Zur Vermeidung von Datenbankkonflikten wird ReadEvents immer, selbst bei Verwendung zusätzlicher Instanzen, im Single-Thread-Modus ausgeführt. Zur Steigerung der Leistung kann ReadEvents bei jeder Ausführung mehrere Ereignisse lesen und diese Ereignisse können von mehreren BuildMessage-Instanzen gleichzeitig verarbeitet werden. Der Ereignisspeicher muss über einen Primärschlüssel verfügen, den ReadEvents zur Kennzeichnung der Ereignisse verwendet, die zur Zeit verarbeitet werden. Sie brauchen also für ReadEvents keinen ESQL-Code zu schreiben, der die zur Zeit vom Nachrichtenfluss verarbeiteten Ereignisse herausfiltert.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:22:40


KonzeptthemaKonzeptthema | Version 8.0.0.5 | bc34040_