STOMP für das Nachrichtenmanagement verwenden

Überblick

STOMP ist ein offenes Messagingprotokoll, um Effizienz von Produktion und Verbrauch zu steigern, weil die Authentifizierung einmal pro Verbindung und nicht einmal pro Anforderung ausgeführt wird. Der Queue-Service unterstützt die STOMP-Spezifikationen 1.0, 1.1 und 1.2 Sie können Nachrichten in einer Queue sowohl mit STOMP als auch mit REST veröffentlichen und konsumieren.

In den folgenden Abschnitten wird beschrieben, wie Queue STOMP unterstützt:

• Verbindung und Authentifizierung
• Senden
• ABONNIEREN
• ABONNEMENT AUFHEBEN
• BESTÄTIGEN/NICHT BESTÄTIGEN
• NACHRICHT
• EINGANG
• VERBINDUNG TRENNEN
• FEHLER

Verbindung und Authentifizierung

Clients können den CONNECT- oder STOMP-Frame verwenden, um über den Nachrichtenendpunkt in Port 61613 eine Verbindung zum Queue-Service herzustellen. Detaillierte Anweisungen zum Suchen des Nachrichtenendpunkts einer Queue finden Sie unter Nachrichtenendpunkt.

Bei der Authentifizierung mit dem STOMP-Protokoll werden Authentifizierungstoken verwendet. Authentifizierungstoken müssen Base64-codiert sein. Sie können Token in der Konsole auf der Seite "Benutzerdetails" generieren. Weitere Informationen finden Sie unter Mit Authentifizierungstoken arbeiten.

SEND

Verwenden Sie den SEND-Frame, um Nachrichten zu erzeugen. Sie können die folgenden Header in den SEND-Frame aufnehmen:

• destination: (Erforderlich) Die OCID (Oracle Cloud-ID) der Queue, in der die Nachrichten veröffentlicht werden. Optional können Sie eine Kanal-ID für die Veröffentlichung im angegebenen Kanal angeben. Beispiele:

  <queue_OCID>/<channel_ID>

• receipt: (Optional) Wenn der SEND-Frame einen receipt-Header enthält, sendet Queue bei erfolgreicher Veröffentlichung einen RECEIPT-Frame oder bei einem Fehler einen ERROR-Frame an den Client.
  Hinweis
  
  Wenn der receipt-Header fehlt, sendet der Queueservice keinen RECEIPT-Frame. Möglicherweise wird bei einem Fehler trotzdem ein ERROR-Frame gesendet.

Der transaction-Header und benutzerdefinierte Header werden nicht unterstützt. Queue sendet einen ERROR-Frame und schließt die Verbindung, wenn nicht unterstützte Header enthalten sind.

SUBSCRIBE

Verwenden Sie den SUBSCRIBE-Frame, um Nachrichten zu konsumieren. Der SUBSCRIBE-Frame entspricht einer Lange Polling-Anforderung GetMessages. Alle auf dem abonnierten Ziel empfangenen Nachrichten werden dem Client als MESSAGE-Frames von der Queue zugestellt. Sie können die folgenden Header in den SUBSCRIBE-Frame aufnehmen:

• destination: (Erforderlich) Die OCID (Oracle Cloud-ID) der Queue, aus der Nachrichten konsumiert werden. Optional können Sie einen Kanalfilter einschließen, der aus dem angegebenen Kanal oder den angegebenen Kanälen konsumiert werden soll. Beispiele:

  <queue_OCID>/<channel_ID_filter>

  Hinweis
  
  Weitere Informationen zum Filtern finden Sie unter Nachrichtenauswahl.
• id: (Erforderlich) Gibt das Abonnement an. Um das Konsumieren von Nachrichten zu stoppen, muss diese ID vom Client in einem UNSUBSCRIBE-Frame übergeben werden.
• ack: (Erforderlich) Nur der Wert client-individual wird unterstützt. Das heißt, dass ein ACK-Frame nur die im ACK-Frame identifizierte Nachricht löscht und nicht alle zuvor zugestellten Nachrichten.
• visibility: (Optional) Gibt an, wie lange die konsumierten Nachrichten nur für den Client sichtbar sind, der die Anforderung stellt. Wird der Header ausgelassen, verwendet der Queue-Service den Standardsichtbarkeitstimeout der Queue.

Bei einem Fehler gibt der Queue-Service einen ERROR-Frame zurück und schließt die Verbindung.

UNSUBSCRIBE

Verwenden Sie den UNSUBSCRIBE-Frame, um das Empfangen von Nachrichten aus der Queue durch den STOMP-Client zu stoppen. Fügen Sie den folgenden Header in den Frame ein:

• id: (Erforderlich) Gibt an, welches Abonnement gestoppt werden soll. Diese ID wurde im entsprechenden SUBSCRIBE-Frame verwendet.

ACK/NACK

Mit dem ACK-Frame können Sie eine Nachricht löschen, nachdem sie empfangen und verarbeitet wurde. Ein ACK-Frame löscht nur die Nachricht, die durch den id-Header identifiziert wird.

Mit dem NACK-Frame können Sie Queue benachrichtigen, dass die Nachricht nicht erfolgreich verarbeitet wurde. Mit dem NACK-Frame wird die Sichtbarkeit der Nachricht aktualisiert, damit sie für andere Consumers sofort sichtbar wird.

Beide Frames akzeptieren je nach Protokollversion den folgenden Header:

• id: (Für STOMP v1.2 erforderlich) Die ID der Nachricht, die gelöscht oder aktualisiert werden soll.
• message-id: (Erforderlich für STOMP v1.1 oder 1.0) Die ID der Nachricht, die gelöscht oder aktualisiert werden soll.

MESSAGE

Der MESSAGE-Frame leitet Nachrichten von Abonnements an den STOMP-Client weiter. Ein MESSAGE-Frame enthält die folgenden Header:

• message-id:
  • Für STOMP v1.2: Eine eindeutige, interne ID für die Nachricht. Wird nur für Debuggingzwecke verwendet.
  • Für STOMP v1.1 und v1.0: Der Nachrichtenempfang, der mit den Frames ACK und NACK verwendet werden soll.
• subscription: Die im SUBSCRIBE-Frame verwendete ID.
• destination: Die OCID (Oracle Cloud-ID) der Queue mit den Nachrichten und einer optionalen Kanal-ID für die Veröffentlichung in einem angegebenen Kanal. Beispiele:

  <queue_OCID>/<channel_ID>

• ack: Nur für STOMP v.1.2: der Nachrichtenempfang.
• content-type: Der Payload-Typ, in diesem Fall plain/text.
• content-length: Die Länge der Payload oder Nachricht.
• expire-after: Die Nachrichtenablaufzeit in Millisekunden seit Epoch.
• visible-after: Die Nachrichtensichtbarkeitszeit in Millisekunden seit Epoch.
• delivery-count: Gibt an, wie oft diese Nachricht zugestellt wurde.
• oci-message-id : Eine interne Nachrichten-ID.

Ein MESSAGE-Frame enthält die Payload der Nachricht als Body des Frames.

RECEIPT

Der Queue-Service sendet einen RECEIPT-Frame an den STOMP-Client, nachdem der Service einen SEND-Frame erfolgreich verarbeitet hat, der einen Empfang angefordert hat. Ein RECEIPT-Frame enthält einen receipt-id-Header mit einem Wert, der mit dem Empfangsheader im SEND-Frame übereinstimmt.

Ein RECEIPT-Frame ist eine Bestätigung, dass der entsprechende Client-Frame vom Server verarbeitet wurde. Da STOMP strombasiert ist, ist der Empfang auch eine kumulative Bestätigung, dass alle vorherigen Frames vom Server empfangen wurden. Allerdings sind die vorherigen Frames unter Umständen noch nicht vollständig verarbeitet. Wenn der Client die Verbindung trennt, werden zuvor empfangene Frames weiterhin vom Server verarbeitet.

DISCONNECT

Verwenden Sie den DISCONNECT-Frame, um die Verbindung zu trennen oder die Verbindung zum Queue-Service zu schließen. Alle mit der Verbindung verknüpften Abonnements werden gestoppt. Sie können den folgenden Header in den Frame aufnehmen:

• receipt: (Optional) Queue sendet einen RECEIPT-Frame an den STOMP-Client, nachdem alle vorherigen Frames mit einem receipt-Header erfolgreich verarbeitet wurden. Verwenden Sie den receipt-Header, um Verbindungen ordnungsgemäß zu trennen.

ERROR

Queue kann ERROR-Frames senden, wenn ein Fehler auftritt. Nachdem Sie den ERROR-Frame gesendet haben, schließt Queue die Verbindung. Der ERROR-Frame kann die folgenden Header enthalten:

• message: Eine kurze Beschreibung des Fehlers. Der Body enthält detailliertere Informationen.
• receipt-id: Der Wert des receipt-Headers, wenn der Frame, der den Fehler verursacht hat, einen receipt-Header enthält.
• content-type: Der Typ der Payload, wenn der Text weitere Details der Fehlermeldung enthält.
• content-length: Die Länge der Payload oder Fehlermeldungsdetails.

Der ERROR-Framebody enthält detaillierte Informationen zum Fehler.