Enhance Azure Service Bus destination configuration

[leggetter]

Moving from original PR #437 and capturing as a feature issue so we can release with Service Bus support:

---

From @alexluong :

Whether it's publishing to Topic or Queue, the Publisher needs to send an Azure's Message. Here's the full Golang SDK Message struct:

// Message is a message with a body and commonly used properties.
// Properties that are pointers are optional.
type Message struct {
  // ApplicationProperties can be used to store custom metadata for a message.
	ApplicationProperties map[string]any

	// Body corresponds to the first []byte array in the Data section of an AMQP message.
	Body []byte

	// ContentType describes the payload of the message, with a descriptor following
	// the format of Content-Type, specified by RFC2045 (ex: "application/json").
	ContentType *string

	// CorrelationID allows 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.
	CorrelationID *string

	// MessageID is an application-defined value that uniquely identifies
	// the message and its payload. The identifier is a free-form string.
	//
	// If enabled, the duplicate detection feature identifies and removes further submissions
	// of messages with the same MessageId.
	MessageID *string

	// PartitionKey is used with a partitioned entity and enables assigning related messages
	// to the same internal partition. This ensures that the submission sequence order is correctly
	// recorded. The partition is chosen by a hash function in Service Bus and cannot be chosen
	// directly.
	//
	// For session-aware entities, the ReceivedMessage.SessionID overrides this value.
	PartitionKey *string

	// ReplyTo is an application-defined value specify 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.
	ReplyTo *string

	// ReplyToSessionID augments the ReplyTo information and specifies which SessionId should
	// be set for the reply when sent to the reply entity.
	ReplyToSessionID *string

	// ScheduledEnqueueTime specifies a time when a message will be enqueued. The message is transferred
	// to the broker but will not available until the scheduled time.
	ScheduledEnqueueTime *time.Time

	// SessionID is used with session-aware entities and associates a message with an application-defined
	// session ID. Note that an empty string is a valid session identifier.
	// Messages with the same session identifier are subject to summary locking and enable
	// exact in-order processing and demultiplexing. For session-unaware entities, this value is ignored.
	SessionID *string

	// Subject enables an application to indicate the purpose of the message, similar to an email subject line.
	Subject *string

	// TimeToLive is the duration after which the message expires, starting from the instant the
	// message has been accepted and stored by the broker, found in the ReceivedMessage.EnqueuedTime
	// property.
	//
	// When not set explicitly, the assumed value is the DefaultTimeToLive for the queue or topic.
	// A message's TimeToLive cannot be longer than the entity's DefaultTimeToLive is silently
	// adjusted if it does.
	TimeToLive *time.Duration

	// To is reserved for future use in routing scenarios but is not currently used by Service Bus.
	// Applications can use this value to indicate the logical destination of the message.
	To *string
}

Here are a few notable configuration, especially on the destination level that we may want to support:

• MessageID --> MessageIDTemplate, similar to AWS Kinesis Parition Key approach

• CorrelationID --> CorrelationIDTemplate, similar to AWS Kinesis Parition Key approach

• PartitionKey --> PartitionKeyTemplate, similar to AWS Kinesis Parition Key approach

• ScheduledEnqueueTime

• TimeToLive

The current implementation doesn't support any of these. So when create destination, it's super straightforward:

type Config struct {
  Name string
}

If we want to support these, we can either add them to Config, such as Config.TTL, or we can also add a suffix like Config.MessageTTL to specify that these config would apply to the Message.

Feedback from @leggetter :

Let's be consistent across destinations.

Let's also be explicit in our naming so it's clear where the configuration is applied.

[alexluong]

Let's be consistent across destinations.
Let's also be explicit in our naming so it's clear where the configuration is applied.

Can you elaborate on this a bit more? It's not super clear to me how we can be more consistent in this case.

[leggetter]

@alexluong you wrote:

MessageID --> MessageIDTemplate, similar to AWS Kinesis Parition Key approach

CorrelationID --> CorrelationIDTemplate, similar to AWS Kinesis Parition Key approach

PartitionKey --> PartitionKeyTemplate, similar to AWS Kinesis Parition Key approach

If we support templates elsewhere for similar configuration values, we should also support them with Azure Service Bus.

Are there other similar config variables for destinations that support templates? If so, let's be consistent with our support of templates across destination config.

You also wrote:

If we want to support these, we can either add them to Config, such as Config.TTL, or we can also add a suffix like Config.MessageTTL to specify that these config would apply to the Message.

What I mean here is that Config.MessageTTL explicitly tells us what the TTL is for.

Hope that clarifies things.