This page provides details to implement the Azure Service Bus Message Schema. The properties have been extracted from the official Microsoft Azure Source.
Data Contracts are common during message interchange between systems. A data contract is a formal agreement between a Sender and a Receiver which describes the data and any associated metadata to be exchanged. This removes any impedance mismatch because both the Sender and Receiver have agreed on the message format.
A typical message will consist of three parts; Header, Parameters and Body. Protocols such as HTTP, AMQP, and SOAP will construct messages differently and use these properties during message exchange.
A message during an exchange can fall into the following categories: Command, Event, Query & Document. More information is available here.
A Schema Registry is a registry that holds a catalogue of message formats. These schemas can be used by the Sender during message construction to create the message object. Because the message schema defines the properties of the message, the Sender must strictly adhere to the schema. The Receiver will then use the same schema registry during message transformation; i.e. taking an existing serialised message and then de-serialising it to a message that is meaningful to the Receiver.
Azure Service Bus Schema Definition
|Describes the payload of the message for example,
|Enables an application to specify a context for the message for the purposes of correlation; for example, reflecting the MessageId of a message that is being replied to.
|This property enables the application to indicate the purpose of the message to the receiver in a standardized fashion, similar to an email subject line.
|The message identifier is an application-defined value that uniquely identifies the message and its payload. The identifier is a free-form string and can reflect a GUID or an identifier derived from the application context. If enabled, the duplicate detection feature identifies and removes second and further submissions of messages with the same MessageId.
|This optional and application-defined value is a standard way to express a reply path to the receiver of the message. When a sender expects a reply, it sets the value to the absolute or relative path of the queue or topic it expects the reply to be sent to.
|This value augments the ReplyTo information and specifies which SessionId should be set for the reply when sent to the reply entity.
|The sequence number is a unique 64-bit integer assigned to a message as it is accepted and stored by the broker and functions as its true identifier. For partitioned entities, the topmost 16 bits reflect the partition identifier. Sequence numbers monotonically increase and are gapless. They roll over to 0 when the 48-64 bit range is exhausted. This property is read-only.
|For session-aware entities, this application-defined value specifies the session affiliation of the message. Messages with the same session identifier are subject to summary locking and enable exact in-order processing and demultiplexing. For entities that are not session-aware, this value is ignored.
|This value is the relative duration after which the message expires, starting from the instant the message has been accepted and stored by the broker, as captured in EnqueueTimeUtc. When not set explicitly, the assumed value is the DefaultTimeToLive for the respective queue or topic. A message-level TimeToLive value can’t be longer than the entity’s DefaultTimeToLive setting. If it is longer, it is silently adjusted.
|If a message is sent via a transfer queue in the scope of a transaction, this value selects the transfer queue partition.
ServiceBusSender sender = client.CreateSender(queue);
ServiceBusMessage message = new ServiceBusMessage
MessageId = new Guid().ToString(),
Subject = "Order 2007463",
ContentType = "application/json",
CorrelationId = new Guid().ToString(),
TimeToLive = TimeSpan.FromSeconds(600)