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, sodass die Reservierungen nicht einzeln storniert werden müssen.

Im nachfolgenden Diagramm 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
MQInput XML_CANCELRESERVATION_IN
Rechnen DeleteReservation; IncrementSeat
Trace Trace; Trace1; Trace2
MQOutput XML_CANCELRESERVATION_FAIL1_1; XML_CANCELRESERVATION_FAIL1_2; XML_CANCELRESERVATION_FAIL2; XML_CANCELRESERVATION_OUT

Weitere Informationen zu den Knoten in diesem Mustercode finden Sie in der WebSphere Message Broker-Dokumentation unter Integrierte Knoten. 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 XMLNSC-Domäne vorhanden. Der Nachrichtenfluss muss die Nachricht daher unter Verwendung des XMLNSC-Parsers analysieren.
  2. Der Knoten XML_CANCELRESERVATION_IN gibt die Nachricht über das Ausgangsterminal an den Knoten 'DeleteReservation' weiter. Wenn die Ausnahmebedingung nachgeschaltet erzeugt 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 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 die Fehler (wie beispielsweise ein ungültiges XML-Format), die dazu geführt haben, dass die Nachricht an ihn gesendet wurde. Der Trace 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 Trace 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 MQOutput-Knoten innerhalb des Nachrichtenflusses dienen nur zu Testzwecken und erfüllen innerhalb der Testanwendung keine Funktion. Der Nachrichtenfluss 'XML_CancelReservation' reiht 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.

Zurück zu den Informationen zum Mustercode 'Airline Reservations'