publish: Content from Server

AMPS returns a publish message to a client when a new message is published to AMPS that matches one of the subscriptions requested by the client. There are two ways that AMPS can generate publish messages:

• Single-origin Messages - For subscriptions to topics where AMPS can identify a single source for a publish message, AMPS provides information from that publish message to the subscriber.

  This applies to subscriptions to unpersisted topics, SOW topics, and conflated topic replicas. This does not include subscriptions to views (or conflated topics based on views), since views provide the ability to join multiple topics and aggregate over multiple messages. For conflated topics, the header information provided is the information provided with the message published to the subscriber. For messages produced by delta publish, AMPS will use the information provided on the delta publish except as noted in the table below.

• Synthetic Messages - In some cases, AMPS must provide a message that is constructed by the server. This happens for views, and for status messages from AMPS.

AMPS provides different values in the header fields depending on the origin of the publish message. For synthetic messages, AMPS does not provide information on the origin of the message, since there may be multiple sources of the message or, in the case of status messages, no external source. Likewise, AMPS does not provide a CorrelationId, since that header is set by the publisher for a specific message.

Header Fields

The following table contains the header fields returned in a publish message:

Field	Description
Command	Type of message. Always publish, as encoded by the protocol.
Topic	The topic the message was published to.
CorrelationId	A publisher-provided string that is passed, verbatim, to subscribers. If this header is not present, or the message is a synthetic message as described above, subscribers receive no value for the CorrelationId. The contents of this header must consist of characters that are legal in Base64 encoding. For delta publishes, AMPS uses the CorrelationId of the delta publish if one is present. If no CorrelationId is present on the publish, AMPS uses the CorrelationId of the existing message, if one is present. If there is no CorrelationId on the publish, and there is no CorrelationId for the existing message, AMPS does not provide a CorrelationId.
UserId	The UserId of the client that published the message. An authentication module may choose whether to allow subscribers to receive this information.
SubIds	The set of subscription IDs that produced this message. When a message matches multiple subscriptions, AMPS may produce a list of subscription IDs for all matching subscriptions. This header is provided by AMPS. The AMPS Clients process this list and provide a single SubscriptionID for each message provided to message handlers.
Bookmark	The bookmark assigned to this message, if the message was persisted to a transaction log.
TransmissionTime	An ISO-8601 datetime that notes the time the message was processed by this instance of AMPS. The header is included if the client requested a timestamp for the subscription.
LeasePeriod	For messages received from a queue, the ISO-8601 datetime that indicates when the lease expires.
SowKey	If the message was from a topic that uses a SOW, the message includes the SowKey that AMPS uses to uniquely identify the message within the SOW.