Informationen zum Mustercode 'Security Identity Propagation'
Der Mustercode 'Error Handler' basiert auf einem Szenario, in dem ein Unternehmen, das Transaktionen verarbeitet, eine Routine zur Fehlerbehandlung entwickeln möchte.
Der Mustercode veranschaulicht die Verwendung einiger Funktionen, die in WebSphere Message Broker zur Verfügung stehen.
Für Unternehmen wie beispielsweise Banken ist es wichtig, sicherzustellen, dass Transaktionen verarbeitet werden und zwar nur einmal, und dass etwaige Fehler protokolliert werden.
Im Mustercode 'Error Handler' werden Nachrichten zu Personalnummern
durch einen Nachrichtenfluss gesendet, der eine Datenbank mit diesen Informationen
aktualisiert.
Testen Sie die Funktionsweise der Fehlerbehandlungsroutine, indem Sie eine Nachricht mit einer ungültigen Personalnummer senden.
Im Mustercode 'Error Handler' werden folgende Tasks veranschaulicht:
- Die Verwendung einer Fehlerbehandlungsroutine zum Erfassen von Fehlerinformationen und Speichern der Informationen in einer WebSphere MQ-Warteschlange.
Bei der im Mustercode verwendeten Fehlerbehandlungsroutine handelt es sich um einen untergeordneten Nachrichtenfluss, der unverändert jedem beliebigen Nachrichtenfluss zugeordnet werden kann.
- Die Konfiguration von Nachrichtenflüssen zur Steuerung der Transaktionalität.
Der Mustercode veranschaulicht insbesondere die Verwendung von global koordinierten Transaktionen zur Sicherstellung der allgemeinen Datenintegrität, dem Standardbetriebsmodus unter z/OS.
Auf verteilten Plattformen ist für die globale Koordination die Durchführung von bestimmten Konfigurationsschritten erforderlich und die Implementierung erfolgt unter Verwendung von XA-Protokollen.
In diesem Mustercode aktualisiert der Hauptnachrichtenfluss im Mustercode eine Datenbank mit Informationen zu Personalnummern.
Der untergeordnete Nachrichtenfluss zur Fehlerbehandlung gibt alle Nachrichten, bei denen Verarbeitungsfehler aufgetreten sind, in einer Warteschlange aus.
Die Datenbankaktualisierung im Hauptfluss wird transaktional gesteuert, sodass die
Datenbankaktualisierung bezüglich der Personalnummer bei Auftreten eines Fehlers rückgängig gemacht
und
nicht festgeschrieben wird, und die Nachricht vom untergeordneten Nachrichtenfluss zur Fehlerbehandlung verarbeitet wird.
Die Warteschlangenaktualisierung im untergeordneten Nachrichtenfluss zur Fehlerbehandlung wird nicht
transaktional gesteuert, um sicherzustellen, dass Informationen zu Fehlern nicht rückgängig
gemacht werden, sondern als Fehlerprotokoll festgeschrieben werden.
Nachrichten
Zur Ausführung des Mustercodes 'Error Handler' werden zwei Eingabenachrichten zur Verfügung gestellt:
- eine Nachricht, die eine gültige Personalnummer enthält
- eine Nachricht, die eine ungültige Personalnummer enthält
Die gültige Personalnachricht wird im folgenden XML-Code dargestellt:
<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>
Die ungültige Personalnachricht wird im folgenden XML-Code dargestellt:
<Staff>
<StaffNumber>99</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>
Die Nachrichtenflüsse
Im folgenden Diagramm ist der Hauptnachrichtenfluss dargestellt.

Im folgenden Diagramm ist der untergeordnete Nachrichtenfluss zur Fehlerbehandlung dargestellt.
In der folgenden Tabelle sind die Knotentypen aufgelistet, die im Mustercode 'Error Handler' verwendet werden.
Der untergeordnete Nachrichtenflussknoten ist streng genommen kein Knoten und steht daher auch nicht in der Knotenpalette zur Verfügung; er stellt dar, an welcher Stelle der untergeordnete Nachrichtenfluss (Error_Handler.msgflow) im Hauptnachrichtenfluss aufgerufen wird.
Knotentyp |
Knotenname |
MQInput |
STAFF_IN |
MQOutput |
STAFF_FAIL; STAFF_OUT; STAFF_UPDATE_ERROR |
Rechnen |
Copy Message; Create Message for Output |
Filter |
Check Valid Staff Number; Check Backout Count |
Throw |
Throw; Throw to Complete Rollback |
TryCatch |
TryCatch |
Untergeordneter Fluss |
Error_Handler |
Weitere Informationen hierzu finden Sie in der WebSphere Message Broker-Dokumentation unter Integrierte Knoten und
Untergeordnete Nachrichtenflüsse verwenden
.
Die Route, die von der gültigen Personalnachricht genommen wird
Wenn Sie die gültige Personalnachricht in die Eingabewarteschlange stellen, wird die Nachricht durch die Knoten geleitet.
Wenn eine der Warteschlangen inaktiviert ist, kann die Nachricht dieser Route nicht folgen.
- Im Hauptnachrichtenfluss:
- Knoten 'STAFF_IN'. Dieser Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
- Knoten 'Error_Handler'. Dieser Knoten stellt den untergeordneten Nachrichtenfluss zur Fehlerbehandlung dar.
Die Nachricht verlässt den Hauptnachrichtenfluss und wird durch den untergeordneten Nachrichtenfluss gesendet.
- Im untergeordneten Nachrichtenfluss:
- Knoten 'Start Subflow' Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
- Knoten 'Check Backout Count'. Dieser Knoten prüft, ob der Zurücksetzungszähler auf null gesetzt ist.
Da die Eingabenachricht diesen Knoten das erste Mal passiert, ist der aktuelle Zählerstand gleich null und die Nachricht wird an den nächsten Knoten weitergeleitet.
Wenn der Zählerstand ungleich null ist, wird die Nachricht verworfen.
- TryCatch-Knoten. Da die Personalnummer gültig ist, wird die Nachricht an den Knoten 'Back To Main Flow ' weitergegeben.
Wenn die Personalnummer in der Nachricht jedoch ungültig ist und die Ungültigkeit dieser Personalnummer
festgestellt wird, wird die Nachricht an den Knoten 'Copy Message' und STAFF_UPDATE_ERROR weitergegeben.
- Knoten 'Back To Main Flow'. Die Nachricht verlässt den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.
- Im Hauptnachrichtenfluss:
- Knoten 'Check Valid Staff Number '. Da die Personalnummer gültig ist, wird die Nachricht an den Knoten 'Update Staff Database' weitergegeben.
- Knoten 'Update Staff Database'. Die Datenbank STAFFDB wird mit den Personaldetails in der Nachricht aktualisiert.
- Knoten 'STAFF_OUT'. Dieser Knoten stellt die Nachricht in die Warteschlange STAFF_OUT.
- Auch wenn Sie über keine Datenbank verfügen, wird die Nachricht durch das Fehlerterminal in die Warteschlange eingereiht.
Dieses Szenario veranschaulicht diesen Mustercode ohne Verwendung einer Datenbank. Es darf nicht in der tatsächlichen Produktion zum Einsatz kommen.
Die Route, die von der ungültigen Personalnachricht genommen wird
Wenn Sie die ungültige Personalnachricht in die Eingabewarteschlange stellen, wird die Nachricht wie weiter unten in diesem Abschnitt beschrieben durch die Knoten geleitet.
Wenn eine der Warteschlangen inaktiviert ist, kann die Nachricht dieser Route nicht folgen.
Weitere Informationen zu den Funktionen der einzelnen Knoten finden Sie
in der WebSphere Message Broker-Dokumentation unter
Integrierte Knoten.
- Im Hauptnachrichtenfluss:
- Knoten 'STAFF_IN'. Dieser Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
- Knoten 'Error_Handler'. Dieser Knoten stellt den untergeordneten Nachrichtenfluss zur Fehlerbehandlung dar.
Die Nachricht verlässt den Hauptnachrichtenfluss und wird durch den untergeordneten Nachrichtenfluss gesendet.
- Im untergeordneten Nachrichtenfluss:
- Knoten 'Start Subflow' Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
- Knoten 'Check Backout Count'. Dieser Knoten prüft, ob der Zurücksetzungszähler auf null gesetzt ist.
Da die Eingabenachricht diesen Knoten das erste Mal passiert, ist der aktuelle Zählerstand gleich null und die Nachricht wird an den nächsten Knoten weitergeleitet.
Siehe Schritt 5b weiter unten in diesem Abschnitt.
- TryCatch-Knoten. Die Personalnummer in der Nachricht ist ungültig, dies ist jedoch bisher nicht festgestellt worden.
Aus diesem Grund wird die Eingabenachricht an den Knoten 'Back To Main Flow' und nicht an den Knoten 'STAFF_UPDATE_ERROR' übergeben.
- Knoten 'Back To Main Flow'. Die Nachricht verlässt den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.
- Im Hauptnachrichtenfluss:
- Knoten 'Check Valid Staff Number '. Da die Personalnummer ungültig ist, wird die Nachricht an den Throw-Knoten und nicht an den Knoten 'Update Staff Database' weitergegeben.
- Throw-Knoten. Dieser Knoten stoppt die Verarbeitung der Nachricht und fügt die Fehlernummer "3001" und den Fehlertext "Ungültige Personalnummer" in die Nachricht ein.
Die Nachricht wird zurückgesetzt, d. h., die Nachricht wird an den Steuerungspunkt zurückgegeben. In diesem Fall ist dies der TryCatch-Knoten im untergeordneten Nachrichtenfluss.
- Im untergeordneten Nachrichtenfluss:
- TryCatch-Knoten. Dieser Knoten erkennt, dass bei der Verarbeitung der Nachricht eine Ausnahmebedingung aufgetreten ist, und gibt die Nachricht an den Knoten 'STAFF_UPDATE_ERROR' weiter.
- Knoten 'STAFF_UPDATE_ERROR'. Die Nachricht wird an die Warteschlange STAFF_UPDATE_ERROR gesendet.
- Knoten 'Throw To Complete Rollback'. Der Knoten stoppt die Verarbeitung der Nachricht und protokolliert die Nummer "3002" und den Text "Aus Nachrichtenfluss 'Error_Handler'" im Nachrichteninhalt. Die Nachricht wird nun an den Steuerungspunkt zurückgegeben. In diesem Fall ist dies der Knoten STAFF_IN im Hauptnachrichtenfluss.
Dies ist die letzte Stufe der Catch-Verarbeitung.
Dies bedeutet, dass die gesamte Transaktion einschließlich der Datenbankaktualisierungen unter transaktionaler Steuerung (d. h. die Aktualisierung der Datenbank STAFFDB im Hauptnachrichtenfluss) im ursprünglichen Try-Pfad rückgängig gemacht wird.
Die Aktualisierung der Datenbank STAFF_UPDATE_ERROR, die nicht transaktional gesteuert wird, wird jedoch festgeschrieben.
- Im Hauptnachrichtenfluss:
- Knoten 'STAFF_IN'. Da bei der Verarbeitung der Nachricht eine Ausnahmebedingung aufgetreten ist, wird die Nachricht an den Knoten STAFF_FAIL übergeben und nicht erneut durch den Nachrichtenfluss gesendet.
- Knoten 'STAFF_FAIL'. Der Knoten stellt die Nachricht in die Warteschlange STAFF_FAIL.
Wenn die Nachrichtenschlange STAFF_FAIL inaktiv ist, wird die Nachricht dennoch weitergegeben.
Die Nachricht wird zunächst an den Knoten STAFF_IN zurückgegeben und anschließend an den untergeordneten Nachrichtenfluss übergeben.
Die Nachricht erreicht anschließend den Knoten 'Check Backout Count', der prüft, ob der Zurücksetzungszähler gleich null ist.
Da die Nachricht diesen Knoten schon einmal passiert hat, ist der Zählerstand ungleich null und die Nachricht wird verworfen. Die Nachricht wird verworfen, um zu verhindern, dass die Nachricht wiederholt durch den Nachrichtenfluss gesendet wird, wenn die Warteschlange STAFF_FAIL inaktiv ist. Vergleichen Sie diesen Schritt mit Schritt 2b.
Wenn Sie einen TryCatch-Knoten verwenden oder dem Catch-Terminal eines MQInput-Knoten Knoten zuordnen, gehen Sie möglicherweise davon aus, dass sämtliche Prozesse, die im Try-Pfad verarbeitet werden, bei ordnungsgemäßer Konfiguration der Knoten nicht festgeschrieben werden, wenn der Catch-Pfad aufgerufen wird.
Diese Annahme ist nicht korrekt.
Wenn beispielsweise eine Datenbank im Try-Pfad unter transaktionaler Steuerung aktualisiert wird und der Catch-Pfad aufgerufen und normal ausgeführt wird, wird die Datenbankaktualisierung festgeschrieben.
In diesem Beispiel muss eine Nachricht gelesen, eine Datenbank aktualisiert und die Nachricht in eine andere Warteschlange geschrieben werden.
Bei Auftreten eines Fehlers wird die Datenbankaktualisierung rückgängig gemacht.
Die Catch-Verarbeitung aktualisiert die Fehlerdatenbank mit den Fehlerdetails und schreibt die Originalnachricht in die Fehlerwarteschlange.
Im folgenden Beispiel sind die Programmierschritte dargestellt, die ausgeführt werden:
BEGIN ('Äußere' Arbeitseinheit starten)
MQGET (Nachricht aus Eingabewarteschlange abrufen)
TRY
BEGIN ('Innere' Arbeitseinheit starten)
Update database
MQPUT (Nachricht in die Ausgabewarteschlange einreihen)
IF ERROR
ROLLBACK inner unit-of-work GO TO CATCH
ELSE
COMMIT inner and outer unit-of-work as one unit-of-work
END IF
CATCH
Send message to STAFF_UPDATE_ERROR queue
MQPUT (Nachricht in Fehlerwarteschlange einreihen)
COMMIT outer unit-of-work
Zwei Arbeitseinheitsebenen in derselben Anwendung werden vom XA-Transaktionsmanager und WebSphere MQ jedoch nicht unterstützt.
Folglich verwendet der Mustercode 'Error Handler' die folgenden Strukturen:
- Die Aktualisierung der Datenbank STAFFDB im Try-Pfad wird transaktional gesteuert.
- Die Aktualisierung der Datenbank STAFF_UPDATE_ERROR im Catch-Pfad wird nicht transaktional gesteuert.
- Das Fehlerterminal des MQInput-Knotens ist einem MQOutput-Knoten zugeordnet, der auf eine Fehlerwarteschlange zeigt.
- Zuletzt wird bei der Catch-Verarbeitung unter Verwendung eines Ausnahmeknotens erneut ein Fehler erzeugt.
- Die Nachricht wird über den Fehlerpfad zurück an den MQInput-Knoten geleitet und von dort an die Fehlerwarteschlange.
Weitere Informationen finden Sie in der WebSphere Message
Broker-Dokumentation im Abschnitt Nachrichtenflusstransaktionen.
Zurück zum Beginn des
Mustercodes