It's surprising, but I haven't yet found a sample where the Message received at a subscription could be of different types and the type needs to be known in order to deserialize its content with the right type. This is related but it doesn't contemplate that scenario
I have a publish-subscribers scenario. For the subscriber, to create the Message that can be published with the Azure Service Bus library as per https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions
I need to pass an array of bytes. It does not seem to have anything like custom metadata that I could use to specify the assembly type for the message or similar.
When the subscription receives the message, it must deserialize it, but I cannot know which type the specific message is in order to do a JsonConvert.DeserializeObject<TDestType>(Encoding.UTF8.GetString(message.Body))
Does anybody have any link or sample to achieve this? Or is a recommended practice to use a topic and a topic-subscription just with one type of messages? (I doubt it, but I know MassTransit for example creates a topic for each message behind the scenes..)
UPDATE 1: For now I'll use the ContentType property at the Message to store the EventType so that the suscriptor can use it to deserialize. But if feels "hacky" because this field is supposed to store the format type (json, xml, etc.)
It does not seem to have anything like custom metadata that I could use to specify the assembly type for the message or similar.
Azure Service Bus does offer headers/metadata available as UserProperties with every message. A topic can receive multiple message types and subscribers can peek which ones they'd be handling using subscriptions. A subscription can either be a simple one and leverage the message's ContentType property using correlation filters or have a more advanced SQL filters to provide a more advanced subscription mechanism.
For now I'll use the ContentType property at the Message to store the EventType so that the suscriptor can use it to deserialize. But if feels "hacky" because this field is supposed to store the format type (json, xml, etc.)
You can keep ContentType for serialization and use custom headers for filtering messages for subscribers. Or you can choose to store both in the custom headers. It's your call.
It's surprising, but I haven't yet found a sample where the Message received at a subscription could be of different types and the type needs to be known in order to deserialize its content with the right type.
This is what NServiceBus is doing with Azure Service Bus as a transport. A single receiver (endpoint) can handle different message types. The subscriber creates the filters that check for a custom header value to identify what type the message is.