Nachrichtenheader und -eigenschaften

  • Artikel

In diesem Abschnitt werden Nachrichtenheader und -eigenschaften beschrieben.

Nachrichtenheader

Beim Versand einer Nachricht können Sie nur die folgenden Nachrichteneigenschaften angeben. Beim Versand oder Empfang einzelner Nachrichten können sind diese Eigenschaften im BrokerProperties-HTTP-Header in einem JSON-codierten Format enthalten. Beim Versand eines Stapels von Nachrichten sind diese Eigenschaften Teil des JSON-codierten HTTP-Texts. Weitere Informationen finden Sie unter Senden von Nachrichten und Senden von Nachrichtenbatch.

In der folgenden Tabelle sind die Microsoft.ServiceBus.Messaging.BrokeredMessage-Eigenschaften aufgeführt. Die Eigenschaften können in beliebiger Reihenfolge angegeben werden. Wenn keine Eigenschaft angegeben wird, verwendet Service Bus den Standardwert für diese Eigenschaft. Broker-Eigenschaften mit Ausnahme der aufgelisteten Eigenschaften werden ignoriert. Die akzeptierten Eigenschaften sind unabhängig vom Wert der angegebenen API-Version. Die API-Version-Angabe ist in der HTTP-Anforderung nicht erforderlich.

Wenn sowohl SessionId- als auch PartitionKey-Eigenschaft angegeben sind, müssen beide denselben Wert enthalten.

Ein HTTP-Header namens BrokerProperties enthält alle BrokeredMessage-Header. Die Eigenschaften sind JSON-formatiert. Dies vereinfacht die Erweiterung der BrokeredMessage-Eigenschaften. Außerdem wird das Webprogrammiermodell berücksichtigt, indem das webfreundliche JSON-Format genutzt wird. Auf diese Weise wird das Erstellen und Nutzen von Nachrichteneigenschaften mit weniger Zeichenfolgenanalyse möglich. Im Folgenden sehen Sie ein Beispiel für BrokeredMessage-Header:

BrokerProperties:  { “SessionId”: “{27729E1-B37B-4D29-AA0A-E367906C206E}”, “MessageId”: “{701332E1-B37B-4D29-AA0A-E367906C206E}”, “TimeToLive” : 90, “CorrelationId”: “{701332F3-B37B-4D29-AA0A-E367906C206E}”, “SequenceNumber“ : 12345, “DeliveryCount“ : 2, “To“ : "http://contoso.com“, “ReplyTo“ : "http://fabrikam.com“,  "EnqueuedTimeUtc“ : " Sun, 06 Nov 1994 08:49:37 GMT“, "ScheduledEnqueueTimeUtc“ : " Sun, 06 Nov 1994 08:49:37 GMT“}

Die folgende Tabelle zeigt, wie BrokeredMessage-Eigenschaften HTTP-Headern zugeordnet werden.

BrokeredMessage-Bestandteile (SBMP) type HTTP-Header Zugriff HTTP Req/Res
ContentType Zeichenfolge Content-Type get, set Req, Res
CorrelationId Zeichenfolge BrokerProperties{KorrelationsID} get, set Req, Res
SessionID Zeichenfolge BrokerProperties{SitzungsID} get, set Req, Res
DeliveryCount INT BrokerProperties{Übermittlungsanzahl} get Res
LockedUntilUtc Datetime BrokerProperties{GesperrtBis} get Res
LockToken Guid BrokerProperties{Sperrtoken} get Res
MessageId Zeichenfolge BrokerProperties{NachrichtenID} get, set Res
Bezeichnung Zeichenfolge BrokerProperties {Bezeichnung} get, set Req, Res
ReplyTo Zeichenfolge BrokerProperties{Antworten} get, set Req, Res
EnqueuedTimeUtc Datetime Date get Res
SequenceNumber long BrokerProperties{Sequenznummer} get Res
timeToLive TimeSpan BrokerProperties-Auflistung {TimeToLive} get, set Req, Res
Beschreibung Zeichenfolge BrokerProperties{An} get, set Req, Res
ScheduledEnqueueTimeUtc Datetime BrokerProperties{GeplanteWarteschlangenzeitUTC} get, set Req, Res
ReplyToSessionId Zeichenfolge BrokerProperties{AntwortAnSitzungsID} get, set Req, Res
PartitionKey Zeichenfolge BrokerProperties {PartitionKey} get, set Req, Res

Zusätzlich zu diesen Eigenschaften können Sie auch benutzerdefinierte Eigenschaften angeben. Beim Versand oder Empfang einzelner Nachrichten wird jede benutzerdefinierte Eigenschaft in einem eigenen HTTP-Header angegeben. Beim Versand eines Stapels von Nachrichten sind benutzerdefinierte Eigenschaften Teil des JSON-codierten HTTP-Texts. Weitere Informationen finden Sie unter Senden von Nachrichten und Senden von Nachrichtenbatch.

Hinweise

  • DateTime Header werden wie von RFC2616 definiert formatiert: https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3. Z. B. "Sun, 06 Nov 1994 08:49:37 GMT".

  • BrokerProperties {TimeToLive} ist die Anzahl der Sekunden von TimeSpan (double).

  • ExpiresAtUtc verfügt nicht über einen entsprechenden HTTP-Header, da er von Date und BrokerProperties {TimeToLive}abgeleitet werden kann.

  • Nachrichtenheader mit einem get-Accessor können nur in der HTTP-Antwort (z. B. einer empfangenen Nachricht) auftreten. Wenn diese Header in der HTTP-Anforderung (der gesendeten Nachricht) vorhanden sind, werden sie einfach ignoriert. Nicht erkannte HTTP-Header werden ebenfalls ignoriert.

  • Wenn dieser Wert falsch formatiert ist, wird ein entsprechender HTTP-Statuscode an den Client zurückgegeben.

Nachrichteneigenschaften

Nachrichteneigenschaften sind vom Benutzer definierte Schlüssel-Wert-Paare, die in message.Properties enthalten sind. Für den SBMP-Thick Client sind diese Werte auf byte, sbyte, char, short, ushort, int, uint, long, ulong, float, double, decimal, bool, Guid, string, Uri, DateTime, DateTimeOffset und TimeSpan eingeschränkt.

Für REST/HTTP werden Uri und DateTimeOffset nicht unterstützt (wenn sie in der BrokeredMessage enthalten sind, sind sie nicht in den HTTP-Headern enthalten). GUID-Typen werden in Zeichenfolgen konvertiert und TimeSpan-Typen in "Sekunden gesamt". Aufgrund dieser Konvertierungen geht die Typgenauigkeit verloren. Jeder Eigenschaftenname, der dem eingeschränkten HTTP-Header entspricht (beispielsweise Connection, Expect usw.), ist ebenfalls ausgeschlossen.

Jedes Schlüssel/Wert-Paar in message.Properties wird einem HTTP-Header im folgenden Format zugeordnet. prop ist der Schlüsselname und value die Zeichenfolgendarstellung des Werts:

prop_name: value

Der Typ des Werts wird abgeleitet. Wenn er in doppelte Anführungszeichen eingeschlossen ist, gilt Folgendes:

  • Wenn der Inhalt das Format einer RFC2616-Datums-/Uhrzeitangabe aufweist, wird er vom Broker als System.DateTime behandelt.

  • Andernfalls entfernt der Broker die Anführungszeichen und behandelt den Inhalt als System.String.

Wenn er nicht in doppelte Anführungszeichen eingeschlossen ist, gilt Folgendes:

  1. Wenn der Inhalt "true" oder "false" (Unterscheidung von Groß- und Kleinschreibung!) ist, behandelt der Broker ihn als System.Boolean mit dem entsprechenden Wert.

  2. Wenn der Inhalt als ganze Zahl analysiert werden kann, wird er vom Broker als System.Int64 behandelt.

  3. Wenn der Inhalt als Gleitkommazahl analysiert werden kann, wird er vom Broker als System.Double behandelt.

  4. Andernfalls weist der Broker die Nachricht zurück.

Beispiel:

product: Windows 7 Ultimate  
price: 299.98  
order-time: Fri, 04 Mar 2011 08:49:37 GMT

Nachrichtentext

Zwischen dem HTTP-Anforderungsantwort-Textdatenstrom und dem BrokerMessage.BodyStream werden keine Konvertierungen ausgeführt. Außerdem wird der Content-Type-Header aus der HTTP-Anforderung beibehalten und an den Nachrichtenempfänger zurückgegeben, damit die Anwendung die Bytes im Nachrichtentext richtig interpretieren kann.

Wenn die Nachricht mit dem SBMP-Thick Client ohne benutzerdefinierte XML-Objektserialisierung erstellt wird, wird für den Inhaltstyp standardmäßig "application/msbin1" verwendet (dies ist DataContractBinarySerializer), wenn die Anwendung den Typ nicht explizit ändert (Beispiel: message.ContectType=”application/mytype”), nachdem die Nachricht erstellt wurde. Dieser Inhaltstypwert wird an den HTTP-Consumer zurückgegeben. Die Entscheidung, wie die Bytes im Nachrichtentext deserialisiert werden sollen, liegt in der Verantwortung der Anwendung.

Die WCF Service Bus-Bindung legt den ContentType auf den -Nachrichtenencoder fest ContentType. Wenn z. B. ein Textnachrichtencodierer verwendet wird, ist “application/soap+xml” der erwartete Content-Type.

Nachrichtenkonvertierung

Die Konvertierung zwischen einer HTTP-Anforderungsantwort und einer Nachricht wird beim Anbieter des HTTP-Messaginglaufzeitmoduls ausgeführt. Die Konvertierungsmethoden werden so augmentiert, dass sie die Zuordnung der Header/Eigenschaften aus der Tabelle weiter oben in diesem Abschnitt enthalten und den Inhaltstyp der Nachricht beibehalten.