Informationen zum Mustercode 'DatabaseInput Node'

Mit einem DatabaseInput-Knoten können Sie Nachrichtenflüsse erstellen, die schnell auf Änderungen der Anwendungsdaten in Datenbanken reagieren. Der Knoten ruft aktualisierte Daten direkt aus der Datenbank ab.

Im folgenden Diagramm ist die Ereignisfolge dargestellt. Sobald eine Änderung an der Anwendungsdatentabelle stattfindet, wird ein Auslöser gestartet. Die Ereignistabelle wird dann mit so vielen Informationen gefüllt, dass die Ermittlung der geänderten Zeilen möglich ist.

Struktur der Implementierung eines DatabaseInput-Knotens

Im folgenden Diagramm ist die Struktur der in diesem Mustercode verwendeten Anwendungsdatentabellen dargestellt:

Anwendungsdatentabellen des Mustercodes mit Kunden- und Adressdatensätzen

Wird beispielsweise ein Eintrag in eine Kundentabelle eingefügt, entsprechen die eingefügten Zeilen in den Kunden- und Ereignistabellen ungefähr der folgenden Tabelle.

PKEY FIRSTNAME LASTNAME CCODE
cust1 Joe Bloggs sales

Ereignistabelle

Bei der Ereignistabelle handelt es sich um eine vom Benutzer erstellte Datenbanktabelle, die sich für gewöhnlich innerhalb desselben Schemas wie die Anwendungstabelle oder die Tabellen befindet, für die sie Ereignisse speichert. Die Ereignistabelle beschreibt die Art der Änderung, die an einer Anwendungstabelle vorgenommen wurde, und eine Kennung für die geänderte Zeile. In der folgenden Tabelle werden einige typische Spalten in einer Ereignistabelle genannt und die Gründe, die für deren Aufnahme sprechen.

Spaltenname Spaltenfunktion Beispielwert
EVENT_ID Erforderlich. Der Primärschlüssel, der angibt, welches Ereignis zu einem bestimmten Zeitpunkt verarbeitet wird. 1
OBJECT_KEY Erforderlich. Das identifizierende Element der geänderten Zeile in der Anwendungstabelle, für gewöhnlich das Element der Zeile in der Primärschlüsselspalte. cust1
OBJECT_VERB Optional. Die vorgenommene Änderung, für gewöhnlich entweder CREATE, UPDATE oder DELETE. Mit diesem Ereignis lässt sich ein DELETE-Ereignis abgrenzen, da die Anwendungstabelle in diesem Fall bei der Erstellung der Nachricht für den Fluss keine abzurufende Zeile enthält. CREATE
OBJECT_NAME Optional. Der Name der Anwendungstabelle, die geändert wurde. Diese Spalte ist erforderlich, wenn der DatabaseInput-Knoten genutzt wird, um Aktualisierungen an mehreren Anwendungstabellen zu unterstützen. customer
EVENT_PRIORITY Optional. Die Priorität des Ereignisses, mit 'ir' kann beispielsweise sichergestellt werden, dass Transaktionen hoher Priorität vor dem niedrigeren Wert berechnet werden. 1
EVENT_TIME Optional. Die Uhrzeit, zu der die Operation ausgeführt wurde. Wird für gewöhnlich zur Protokollierung oder Leistungsüberwachung des Flusses genutzt. 2010-10-19T17:10:00
EVENT_STATUS Optional. Damit wird ermittelt, ob das Ereignis bereits verarbeitet wurde. Erforderlich, wenn die Ereignisse nach der Verarbeitung nicht gelöscht oder archiviert werden sollen. 0
EVENT_COMMENT Optional. Unformatiertes Feld, es kann beispielsweise zum Speichern des Ergebnisses der Nachrichtenverarbeitung genutzt werden, wenn das Ereignis nach der Verarbeitung nicht gelöscht wurde. Mit Ausnahmebedingungen verarbeitet

Hinweis:

Das folgende Beispiel enthält eine sehr einfache Ereignistabelle mit nur drei Spalten. Eine Ergänzung der Anwendungstabelle führt zu der folgenden neuen Zeile in der Ereignistabelle:

EVENT_ID OBJECT_KEY OBJECT_VERB
1 cust1 Create

Ein neuer Kunde wurde mit dem Primärschlüssel cust1 erstellt. Der DatabaseInput-Knoten reagiert auf die Änderung und verarbeitet die neue Zeile in einem Nachrichtenfluss.

Verarbeitungsoptionen bei Abschluss

Wenn der Fluss die Verarbeitung eines Ereignisses beendet hat, wird die Verarbeitung auf eine der folgenden drei Arten abgeschlossen:

  1. Löschen Sie das Ereignis. Entscheiden Sie sich für diese Möglichkeit, wenn Sie das Ereignis nicht zur künftigen Referenz speichern möchten.
  2. Aktualisieren Sie die Statusspalte. Nutzen Sie diese Möglichkeit, wenn Sie die verarbeiteten Ereignisse festhalten möchten und Ihre Ereignistabelle eine Statusspalte (EVENT_STATUS) enthält.
  3. Archivieren Sie das Ereignis in einer separaten Ereignistabelle. Nutzen Sie diese Möglichkeit, wenn Sie die Ereignisse festhalten und die Ereignistabelle auf eine minimal Größe beschränken möchten.

Dieser Mustercode nutzt die erste Option und löscht die Ereignisse nach der erfolgreichen Ausführung.

Die Details des Nachrichtenflusses und die von ihm ausgeführte Verarbeitung werden im folgenden Abschnitt näher erläutert.

Nachrichtenfluss 'DatabaseInput'

Der DatabaseInput-Nachrichtenfluss greift die an der Datenbank vorgenommenen Änderungen auf, konvertiert sie in ein Ausgabenachrichtenformat und stellt sie in eine WebSphere MQ-Warteschlange:

Screenshot des Nachrichtenflusses 'DatabaseInput'.

Beachten Sie, dass der Fluss einen zweiten MQOutput-Knoten enthält, mit dem eventuell aufgetretene Ausnahmebedingungen abgefangen werden. Durch diese Aktion werden unnötige Neuversuche und die wiederholte Verarbeitung fehlerhaften ESQL-Codes oder einer falsch eingerichteten Datenbank oder Tabelle vermieden.

Testscripts

In diesem Mustercode werden drei SQL-Scripts verwendet:

Script zum Einfügen einer Zeile in die Datenbank

INSERT INTO DBINPUT_CUSTOMER
      VALUES ('cust1', 'Fred', 'Flintstone', 'Dev');

Script zum Aktualisieren einer Zeile in der Datenbank

UPDATE DBINPUT_CUSTOMER SET FIRSTNAME = 'Barney', LASTNAME = 'Rubble' WHERE PKEY='cust1';

Script zum Löschen einer Zeile in der Datenbank

DELETE FROM DBINPUT_CUSTOMER WHERE PKEY='cust1';

Zurück zum Beginn des Mustercodes