QAnywhere-Nachrichten haben einheitliche Felder in den Headern. Headerfelder enthalten Werte, mit denen Clients und Provider Nachrichten identifizieren und weiterleiten.
Die folgenden Nachrichtenheader sind vordefiniert: Wie Sie diese Felder verwenden, richtet sich nach dem Typ der verwendeten Clientanwendung.
Nachricht-ID Schreibgeschützt. Die Nachricht-ID der neuen Nachricht. Dieser Header erhält erst nach dem Absenden einen Eintrag. Weitere Hinweise finden Sie unter:
Zeitstempel der Nachrichtenerstellung Schreibgeschützt. Das Timestamp-Headerfeld enthält die Uhrzeit, zu der eine Nachricht erstellt wurde. Sie gibt die koordinierte Universalzeit (UTC) an. Das ist nicht der Zeitpunkt, an dem die Nachricht übermittelt wurde, weil sich das tatsächliche Versenden aufgrund von Transaktionen oder anderen clientseitigen Nachrichtenwarteschlangen später ereignen kann. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Antwortadresse Lese-/Schreibzugriff. Die Antwortadresse als VARCHAR(128) oder NULL, wenn eine solche nicht vorhanden ist. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Nachrichtenadresse Schreibgeschützt. Die QAnywhere-Nachrichtenadresse als VARCHAR(128). QAnywhere-Nachrichtenadressen haben das Format ID\Warteschlangenname. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Status der Neuzustellung der Nachricht Schreibgeschützt. Der Neuzustellungswert als BIT. Der Wert 1 gibt an, dass es sich um eine Neuzustellung der Nachricht handelt, 0 gibt an, dass die Nachricht nicht neu zugestellt wurde.
Eine Nachricht kann neuzugestellt werden, wenn sie vorher empfangen, aber nicht bestätigt wurde. Beispiel: Die Nachricht wurde empfangen, aber die empfangende Anwendung konnte die Nachrichtenverarbeitung vor einem Systemabsturz nicht abschließen. In diesen Fällen markiert QAnywhere die Nachricht als neuzugestellt, um den Empfänger darauf aufmerksam zu machen, dass die Nachricht teilweise bereits verarbeitet sein könnte.
Beispiel: Angenommen, der Empfang einer Nachricht erfolgt in drei Schritten:
Eine Anwendung, die einen nichttransaktionalen QAnywhere-Manager benutzt, empfängt die Nachricht.
Die Anwendung schreibt den Inhalt der Nachricht und die Nachricht-ID in eine Datenbanktabelle T1 und schreibt die Änderung fest.
Die Anwendung bestätigt die Nachricht.
Wenn die Anwendung zwischen Schritt 1 und 2 oder zwischen Schritt 2 und 3 abstürzt, wird die Nachricht beim Neustart der Anwendung neuzugestellt.
Falls der Fehler zwischen den Schritten 1 und 2 auftritt, sollten Sie die neu zugestellte Nachricht mit den Schritten 2 und 3 verarbeiten. Falls der Fehler zwischen den Schritten 2 und 3 auftritt, wurde die Nachricht bereits verarbeitet und muss nur noch bestätigt werden.
Um den Status bis zum Absturz der Anwendung zu ermitteln, kann die Anwendung ml_qa_getredelivered aufrufen, um zu prüfen, ob die Nachricht bereit vorher neuzugestellt wurde. Nur neuzugestellte Nachrichten müssen in der Tabelle T1 geprüft werden. Da es wahrscheinlich nur selten zu einem Absturz der Anwendung kommt, ist diese Vorgehensweise effizienter als der Zugriff der Anwendung auf die Nachricht-ID der empfangenen Nachricht, um zu prüfen, ob die Nachricht in der Tabelle T1 eingetragen wurde.
Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr.
Weitere Hinweise finden Sie unter:
Ablauf der Nachricht Schreibgeschützt ausgenommen in der SQL-API, wo der Eintrag für Lese-/Schreibzugriff verfügbar ist. Die Ablaufzeit als TIMESTAMP. Gibt NULL zurück, wenn keine Ablaufzeit vorhanden ist. Eine Nachricht läuft ab, wenn sie vom vorgesehenen Empfänger nicht bis zum Ablaufzeitpunkt abgeholt wurde. Die Nachricht kann dann mit den Standardlöschregeln von QAnywhere gelöscht werden. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Priorität der Nachricht Lese-/Schreibzugriff. Die QAnywhere-API definiert zehn Stufen von Prioritätswerten, wobei 0 die niedrigste und 9 die höchste Priorität darstellt. Clients sollten die Prioritäten 0-4 als Abstufungen üblicher Priorität und die Prioritäten 5-9 als Abstufungen besonderer Priorität bewerten. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Nachricht-ID einer Nachricht, auf die diese Nachricht antwortet Lese-/Schreibzugriff. Die Antwort-auf-ID als VARCHAR(128) Ein Client kann das InReplyToID-Headerfeld verwenden, um Nachrichten miteinander zu verknüpfen. Eine typische Verwendung wäre, eine Antwortnachricht mit ihrer Anforderungsnachricht zu verknüpfen. Die Antwort-auf-ID ist die ID der Nachricht, die mit dieser Nachricht beantwortet wird. Sie können diesen Header lesen, nachdem eine Nachricht empfangen wurde und bis ein Zurücksetzen oder ein Festschreiben erfolgt, danach nicht mehr. Weitere Hinweise finden Sie unter:
Einige Nachrichtenheader können in Übertragungsregeln verwendet werden. Weitere Hinweise finden Sie unter Von der Regel-Engine definierte Variable.
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |