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.
Im folgenden Diagramm ist die Struktur der in diesem Mustercode verwendeten Anwendungsdatentabellen dargestellt:
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 |
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.
Wenn der Fluss die Verarbeitung eines Ereignisses beendet hat, wird die Verarbeitung auf eine der folgenden drei Arten abgeschlossen:
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.
Der DatabaseInput-Nachrichtenfluss greift die an der Datenbank vorgenommenen Änderungen auf, konvertiert sie in ein Ausgabenachrichtenformat und stellt sie in eine WebSphere MQ-Warteschlange:
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.
In diesem Mustercode werden drei SQL-Scripts verwendet:
INSERT INTO DBINPUT_CUSTOMER VALUES ('cust1', 'Fred', 'Flintstone', 'Dev');
UPDATE DBINPUT_CUSTOMER SET FIRSTNAME = 'Barney', LASTNAME = 'Rubble' WHERE PKEY='cust1';
DELETE FROM DBINPUT_CUSTOMER WHERE PKEY='cust1';