Informationen zum Nachrichtenfluss 'XML_CancelReservation'

Der Nachrichtenfluss 'XML_CancelReservation' storniert alle in der Eingabenachricht aufgelisteten Reservierungen und aktualisiert die Benutzerdatenbank dahingehend, dass weniger Reservierungen vorhanden und mehr Sitzplätze verfügbar sind. Der Nachrichtenfluss 'XML_CancelReservation' kann eine Reihe von Reservierungsnummern gleichzeitig verarbeiten, so dass die Reservierungen nicht einzeln storniert werden müssen.

In der nachfolgenden Abbildung wird der Nachrichtenfluss XML_CancelReservation veranschaulicht.

Anzeigenerfassung des Nachrichtenflusses 'XML_CancelReservation'

In der folgenden Tabelle sind die Knotentypen aufgelistet, die im Nachrichtenfluss XML_CancelReservation verwendet werden.

Knotentyp Knotenname
MQEmpfang XML_CANCELRESERVATION_IN
Rechnen DeleteReservation; IncrementSeat
Traceknoten Trace; Trace1; Trace2
MQSenden XML_CANCELRESERVATION_FAIL1_1; XML_CANCELRESERVATION_FAIL1_2; XML_CANCELRESERVATION_FAIL2; XML_CANCELRESERVATION_OUT

Weitere Informationen finden Sie unter Die Knoten im Nachrichtenfluss 'XML_CancelReservation' in der WebSphere Message Broker-Dokumentation. Wie Sie den in diesem Nachrichtenfluss verwendeten ESQL-Code sehen können, ist im Abschnitt Nachrichtenfluss 'XML_CancelReservation' erstellen erklärt.

Der Nachrichtenfluss XML_CancelReservation führt die folgenden Aktionen durch:

  1. Der Knoten XML_CANCELRESERVATION_IN ruft die Eingabenachricht aus der Warteschlange XML_CANCELRESERVATION_IN ab und identifiziert die Eingabenachricht als in der XML-Domäne vorhanden. Der Nachrichtenfluss muss daher die Nachricht unter Verwendung des XML-Parsers syntaktisch analysieren.
  2. Der Knoten XML_CANCELRESERVATION_IN gibt die Nachricht über das Ausgangsterminal an den Knoten 'DeleteReservation' weiter. Wenn die Ausnahmebedingung nachgeschaltet ausgelöst wurde und für die Nachricht eine ROLLBACK-Operation bis hierher ausgeführt wurde, gibt der Knoten XML_CANCELRESERVATION_IN die Nachricht alternativ über das Catch-Terminal an den Knoten XML_CANCLERESERVATION_FAIL1_1 weiter, der die Nachricht in die Warteschlange XML_CANCELRESERVATION_FAIL1 einreiht.
  3. Der Knoten 'DeleteReservation' überprüft die Tabelle XMLPASSENGERTB in der Datenbank RESERVDB, um zu ermitteln, ob die in der Eingabenachricht aufgelisteten Reservierungen tatsächlich existieren.
  4. Wenn die Reservierung vorhanden ist, entfernt der Knoten 'DeleteReservation' die in der Eingabenachricht aufgelisteten Passagiere aus der Tabelle XMLPASSENGERTB. Der Knoten 'DeleteReservation' leitet die Nachricht über das Ausgangsterminal an den Knoten 'Trace1' weiter. Der Knoten 'Trace1' protokolliert den Status der Nachricht, wenn diese den Knoten 'DeleteReservation' (Reservierung löschen) verlässt. Der Traceknoten wird im lokalen Fehlerprotokoll gespeichert; unter Windows ist dies 'Event Viewer', unter Linux 'syslog'. Der Knoten 'Trace1' gibt die Nachricht an den Knoten 'IncrementSeat' weiter.
  5. Wenn die Reservierung nicht vorhanden ist, gibt der Knoten 'DeleteReservation' die Nachricht über das Fehlerterminal an den Traceknoten weiter. Der Traceknoten verfolgt und protokolliert Fehler (wie beispielsweise ein ungültiges XML-Format), aufgrund deren die Nachricht an den Traceknoten gesendet wurde. Der Traceknoten wird im lokalen Fehlerprotokoll gespeichert. Der Traceknoten übergibt anschließend die Nachricht über das Ausgangsterminal an XML_CANCELRESERVATION_FAIL1_2, von wo aus die Nachricht in die Warteschlange XML_CANCELRESERVATION_FAIL1 eingereiht wird.
  6. Der Knoten 'IncrementSeat' aktualisiert die Tabelle XMLFLIGHTTB in der Datenbank RESERVDB, um anzuzeigen, dass vier Sitzplätze (jeweils zwei in einer Klasse) wieder verfügbar sind. Der Knoten 'IncrementSeat' übergibt die Nachricht über das Ausgangsterminal an den Knoten XML_CANCELRESERVATION_OUT, von wo aus die Nachricht in die Warteschlange XML_CANCELRESERVATION_OUT eingereiht wird. Wenn es bei der Aktualisierung von XMLFLIGHTTB Probleme gibt, übergibt der Knoten 'IncrementSeat' die Nachricht an den Knoten 'Trace2'. Der Knoten 'Trace2' verfolgt die Nachricht, wenn sie zwischen dem Knoten 'IncrementSeat' und dem Knoten XML_CANCELRESERVATION_FAIL2 unterwegs ist. Der Traceknoten wird im lokalen Fehlerprotokoll gespeichert. Der Knoten XML_CANCELRESERVATION_FAIL2 reiht die Nachricht in die Warteschlange XML_CANCELRESERVATION_FAIL2 ein.

Der Nachrichtenfluss 'XML_CancelReservation' ist ein Beispiel für asynchrone Nachrichtenübermittlung; bei dieser ist die Zustellung der Nachrichten gesichert. Die MQSendeknoten innerhalb des Nachrichtenflusses dienen nur zu Testzwecken und erfüllen innerhalb der Testanwendung keine Funktion. Der Nachrichtenfluss 'XML_CancelReservation' reiht lediglich eine Kopie der Eingabenachricht in die Warteschlange 'XML_CANCELRESERVATION_OUT' ein, wenn die Verarbeitung der Nachricht abgeschlossen ist. Der Nachrichtenfluss muss die Ankunft der Nachricht an ihrem Ziel nicht bestätigen: Permanente Nachrichten werden immer sicher protokolliert.

Symbol Hauptseite   Zurück zu "Das Beispielprogramm 'Airline Reservations'"