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:

Nachrichten

Zur Ausführung des Mustercodes 'Error Handler' werden zwei Eingabenachrichten zur Verfügung gestellt:

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.

Anzeigenerfassung des Hauptnachrichtenflusses.

Im folgenden Diagramm ist der untergeordnete Nachrichtenfluss zur Fehlerbehandlung dargestellt.

Anzeigenerfassung des untergeordneter Nachrichtenflusses zur Fehlerbehandlung.

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.

  1. Im Hauptnachrichtenfluss:
    1. Knoten 'STAFF_IN'. Dieser Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
    2. 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.
  2. Im untergeordneten Nachrichtenfluss:
    1. Knoten 'Start Subflow' Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
    2. 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.
    3. 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.
    4. Knoten 'Back To Main Flow'. Die Nachricht verlässt den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.
  3. Im Hauptnachrichtenfluss:
    1. Knoten 'Check Valid Staff Number '. Da die Personalnummer gültig ist, wird die Nachricht an den Knoten 'Update Staff Database' weitergegeben.
    2. Knoten 'Update Staff Database'. Die Datenbank STAFFDB wird mit den Personaldetails in der Nachricht aktualisiert.
    3. Knoten 'STAFF_OUT'. Dieser Knoten stellt die Nachricht in die Warteschlange STAFF_OUT.
    4. 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.

  1. Im Hauptnachrichtenfluss:
    1. Knoten 'STAFF_IN'. Dieser Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
    2. 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.
  2. Im untergeordneten Nachrichtenfluss:
    1. Knoten 'Start Subflow' Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
    2. 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.
    3. 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.
    4. Knoten 'Back To Main Flow'. Die Nachricht verlässt den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.
  3. Im Hauptnachrichtenfluss:
    1. 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.
    2. 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.
  4. Im untergeordneten Nachrichtenfluss:
    1. 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.
    2. Knoten 'STAFF_UPDATE_ERROR'. Die Nachricht wird an die Warteschlange STAFF_UPDATE_ERROR gesendet.
    3. 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.
  5. Im Hauptnachrichtenfluss:
    1. 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.
    2. 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:

Weitere Informationen finden Sie in der WebSphere Message Broker-Dokumentation im Abschnitt Nachrichtenflusstransaktionen.

Zurück zum Beginn des Mustercodes