[Service Bus] ServiceBusMessage to expose all AMQP details
See original GitHub issueMotivation for this change:
A desire to allow reading and writing of the different parts of an AMQP message as described by the AMQP spec. This gives us the interopability feature when one uses a different client that does support writing to these parts, but then uses our libraries to read the message. See “Message Format” in section 3.2 of the AMQP spec
Guiding factors for the proposal:
- Existing users used to accessing either AMQP properties like
messageId
or AMQP message annotations likepartitionKey
or AMQP message header likedeliveryCount
should continue to have these as top level entities - All inner details of AMQP message should be accessible to the advanced user. Since these do not matter to the most of the user segment, these details need not be at the top level. Therefore, we would like to hide the details (header, footer, message annotations, deliver annotations, properties) in a nested field. This model can be replicated in Event Hubs in the future
- We do not want to introduce any new AMQP message detail as a top level entity at this moment in time to avoid increasing the surface area and potential confusion due to introduction of new elements. If the service team determines that an AMQP message detail from header/footer/message annotations/delivery annotations deserves to get a spot on the top level, it should be do-able incrementally in a non breaking fashion
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (7 by maintainers)
Top Results From Across the Web
[Service Bus] ServiceBusMessage to expose all AMQP detail ...
In #10957, we added a new field to hold all the inner AMQP details of the message when it is received. This allows...
Read more >AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide
Protocol guide to expressions and description of AMQP 1.0 in Azure Service Bus and Event Hubs.
Read more >Sending Message to Azure Service Bus works locally, but not ...
The following code works to send the message to an Azure Service Bus Queue when I run my service locally. The service is...
Read more >Azure Service Bus client library for .NET
Use the client library for Azure Service Bus to: Transfer business data: leverage messaging for durable exchange of information, such as sales or...
Read more >Azure.Messaging.ServiceBus 7.8.0-beta.1 - NuGet
Use the client library for Azure Service Bus to: Transfer business data: leverage messaging for durable exchange of information, such as sales or...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m a fan of approach 2, personally. Although, since ReceivedMessage is a subtype of ServiceBusMessage, it would be nice if their names are related similarly. ReceivedServiceBusMessage seems pedantically correct but maybe too long. Open to other suggestions, or keeping the current names if no alternatives are palatable.
@hemanttanwar The problem is… we can’t stop a user from constructing a message object with two different "body"s in JS, which is not a problem in Java or .NET.