Informationen zum Beispielprogramm 'Error Handler'

Das Beispielprogramm 'Error Handler' basiert aus einem Szenario, in dem ein Unternehmen, das Transaktionen verarbeitet, eine Routine zur Fehlerbehandlung entwickeln möchte. Das Beispielprogramm 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 Beispielprogramm '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 Beispielprogramm 'Error Handler' werden folgende Tasks veranschaulicht:

Die Nachrichten

Zur Ausführung des Beispielprogramms 'Error Handler' werden zwei Eingabenachrichten zur Verfügung gestellt: eine Nachricht, die eine gültige Personalnummer enthält, und eine Nachricht, die eine ungültige Personalnummer enthält.

Die gültige Personalnachricht wird in XML wie folgt übergeben:

<Staff>
   <StaffNumber>1</StaffNumber>
   <NameInfo>
      <LastName>Smith</LastName>
      <FirstName>Jack</FirstName>
   </NameInfo>
</Staff>

 

Die ungültige Personalnachricht wird in XML wie folgt übergeben:

<Staff>
   <StaffNumber>99</StaffNumber>
   <NameInfo>
      <LastName>Doe</LastName>
      <FirstName>Jane</FirstName>
   </NameInfo>
</Staff>

 

Die Nachrichtenflüsse

In der folgenden Abbildung ist der Hauptnachrichtenfluss dargestellt.

Anzeigenerfassung des Hauptnachrichtenflusses.

In der folgenden Abbildung ist der untergeordnete Nachrichtenfluss für die Fehlerbehandlung dargestellt.

Anzeigenerfassung des untergeordneter Nachrichtenflusses zur Fehlerbehandlung.

In der folgenden Tabelle sind die Knotentypen aufgelistet, die im Beispielprogramm 'Error Handler' verwendet werden. Der untergeordneter Nachrichtenflussknoten ist streng genommen kein Knoten und steht daher auch nicht in der Knotenpalette zur Verfügung; er stellt lediglich dar, an welcher Stelle der untergeordnete Nachrichtenfluss (Error_Handler.msgflow) im Hauptnachrichtenfluss aufgerufen wird.

Knotentyp Knotenname
MQEmpfang STAFF_IN
MQSenden STAFF_FAIL; STAFF_OUT
Database Knoten 'Personaldatenbank aktualisieren'; Knoten 'Fehlerdatenbank aktualisieren'
Filter Knoten 'Personalnummer auf Gültigkeit überprüfen'; Knoten 'Rücksetzungszähler überprüfen'
Ausnahme Ausnahmeknoten; Ausnahmeknoten für vollständiges Rollback
Abfangversuchsknoten Abfangversuchsknoten
Untergeordneter Fluss Error_Handler

Weitere Informationen finden Sie unter Die Knoten in den Nachrichtenflüssen des Beispielprogramms 'Error Handler' in der WebSphere Message Broker-Dokumentation.

Die Route, die von der gültigen Personalnachricht genommen wird

Wenn Sie die gültige Personalnachricht in die Eingabewarteschlange stellen, wird die Nachricht wie im Folgenden beschrieben durch die Knoten gesendet. Wenn eine der Warteschlangen deaktiviert wurde, kann die Nachricht dieser Route nicht folgen.

Im Hauptnachrichtenfluss:

  1. STAFF_IN. Der Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
  2. Error_Handler-Knoten. Dieser Knoten stellt den untergeordneten Nachrichtenfluss für die Fehlerbehandlung dar. Die Nachricht verlässt den Hauptnachrichtenfluss und wird durch den untergeordneten Nachrichtenfluss gesendet.

Im untergeordneten Nachrichtenfluss:

  1. Knoten 'Untergeordneten Nachrichtenfluss starten'. Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
  2. Check Backout count-Knoten. Der Knoten prüft, ob der Rü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. Versuchs-/Abfangknoten. Da die Personalnummer gültig ist, wird die Nachricht an den Knoten 'Zurück zum Hauptfluss' weitergegeben. Wenn die Personalnummer in der Nachricht jedoch ungültig ist und die Ungültigkeit der Nachricht festgestellt wird, wird die Nachricht an den Knoten 'Fehlerdatenbank aktualisieren' weitergegeben.
  4. Knoten 'Zurück zum Hauptfluss'. Die Nachricht verlässt nun den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.

Im Hauptnachrichtenfluss:

  1. Knoten 'Personalnummer auf Gültigkeit überprüfen'. Da die Personalnummer gültig ist, wird die Nachricht an den Knoten 'Personaldatenbank aktualisieren' weitergegeben.
  2. Knoten 'Personaldatenbank aktualisieren'. Die Datenbank STAFFDB wird mit den Personaldetails in der Nachricht aktualisiert.
  3. STAFF_OUT. Der Knoten stellt die Nachricht in die Warteschlange STAFF_OUT.

Die Route, die von der ungültigen Personalnachricht genommen wird

Wenn Sie die ungültige Personalnachricht in die Eingabewarteschlange stellen, wird die Nachricht wie im Folgenden beschrieben durch die Knoten geleitet. Wenn eine der Warteschlangen deaktiviert wurde, kann die Nachricht dieser Route nicht folgen. Wenn Sie weitere Informationen zur Funktion der einzelnen Knoten benötigen, klicken Sie auf den entsprechenden Knoten im Hauptthema.

Im Hauptnachrichtenfluss:

  1. STAFF_IN. Der Knoten ruft die Eingabenachricht aus der Eingabewarteschlange ab.
  2. Error_Handler-Knoten. Dieser Knoten stellt den untergeordneten Nachrichtenfluss für die Fehlerbehandlung dar. Die Nachricht verlässt den Hauptnachrichtenfluss und wird durch den untergeordneten Nachrichtenfluss gesendet.

Im untergeordneten Nachrichtenfluss:

  1. Knoten 'Untergeordneten Nachrichtenfluss starten'. Die Nachricht wird an den nächsten Knoten im Nachrichtenfluss übergeben.
  2. Knoten 'Rücksetzungszähler überprüfen'. Der Knoten prüft, ob der Rü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 13 unten.
  3. Versuchs-/Abfangknoten. Die Personalnummer ist ungültig, dies ist jedoch bisher nicht festgestellt worden. Aus diesem Grund wird die Eingabenachricht an den Knoten 'Zurück zum Hauptfluss', und nicht an den Knoten 'Fehlerdatenbank aktualisieren' übergeben.
  4. Knoten 'Zurück zum Hauptfluss'. Die Nachricht verlässt nun den untergeordneten Nachrichtenfluss und kehrt zum Hauptnachrichtenfluss zurück.

Im Hauptnachrichtenfluss:

  1. Knoten 'Personalnummer auf Gültigkeit überprüfen'. Da die Personalnummer ungültig ist, wird die Nachricht an den Knoten 'Ausnahmebedingung angeben' und nicht an den Knoten 'Personaldatenbank aktualisieren' weitergegeben.
  2. Knoten 'Ausnahmebedingung angeben'. Der 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ückgewiesen', d. h., dass die Nachricht an den Steuerungspunkt zurückgegeben wird. In diesem Fall ist dies der Versuchs-/Abfangknoten im untergeordneten Nachrichtenfluss.

Im untergeordneten Nachrichtenfluss:

  1. Versuchs-/Abfangknoten. Der Knoten erkennt, dass bei der Verarbeitung eine Ausnahmebedingung aufgetreten ist, und gibt die Nachricht an den Knoten 'Fehlerdatenbank aktualisieren' weiter.
  2. Knoten 'Fehlerdatenbank aktualisieren'. Die Datenbank ERRORDB wird mit den Fehlerdetails aktualisiert, die vom Knoten 'Fehlerbedingung ausgeben' ausgegeben wurden (Schritt 8).
  3. Ausnahmeknoten für vollständiges Rollback. Der Knoten stoppt die Verarbeitung der Nachricht und protokolliert die Nummer "3002" und den Text "Aus Nachrichtenfluss 'Error_Handler'. In der Datenbank ERRORDB sind weitere Informationen enthalten". 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 ERRORDB, die nicht transaktional gesteuert wird, wird jedoch festgeschrieben.

Im Hauptnachrichtenfluss:

  1. 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. STAFF_FAIL-Knoten. Der Knoten stellt die Nachricht in die Warteschlange STAFF_FAIL. Wenn die Nachrichtenschlange STAFF_FAIL inaktiv ist, wird die Nachricht dennoch weitergegeben. Sie 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 'Rücksetzungszähler überprüfen'. Der Knoten prüft, ob der Rücksetzungszähler auf null gesetzt 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. Siehe Schritt 4 oben.

Wenn Sie einen Versuchs-/Abfangknoten verwenden oder dem Catch-Terminal eines MQEmpfangsknoten 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. Dies ist jedoch nicht der Fall. 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. Folgende Programmierschritte werden ausgeführt:

BEGIN ('Äußere' Arbeitseinheit starten.)
MQAbruf(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
   Update error database
   MQPUT (Nachricht in die 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 das Beispielprogramm 'Error Handler' die folgenden Strukturen:

In diesem Beispiel ist nicht nur eine Datenbank, sondern zwei Datenbanken enthalten, da es in WebSphere MQ nicht möglich ist, dieselbe Datenbankverbindung sowohl für koordinierte als auch für nicht koordinierte Transaktionen im selben Nachrichtenfluss zu verwenden. Im Beispielprogramm 'Error Handler' wird die Datenbankaktualisierung im Hauptnachrichtenfluss transaktional gesteuert, so dass die Datenbankaktualisierung bei Auftreten eines Fehlers rückgängig gemacht und nicht festgeschrieben wird. Die Datenbankaktualisierung im untergeordneten Datenfluss wird nicht transaktional gesteuert, so dass die Aktualisierung stets festgeschrieben wird. Aus diesem Grund werden für das Beispielprogramm 'Error Handler' zwei separate Datenbanken benötigt.

Weitere Informationen finden Sie in der Dokumentation von WebSphere Message Broker unter dem Abschnitt über die Koordination von Transaktionen in Nachrichtenflüssen.

Symbol für die Hauptseite   Zurück zum Beginn des Beispielprogramms