Azure Scheduler and Azure Service Bus

Question

I'm using Azure Scheduler to place a message in a topic in Azure Service Bus. In Azure Scheduler I have entered the following information in the "Message" property:

{"StartTid":null,"Id":"c594eab8-382c-49ec-ba9c-2db0aaf5e167","CreationDate":"2018-02-11T17:42:42.9823622Z","TenantId":null}

When retrieving the message from my app, using this code:

var messageData = Encoding.UTF8.GetString(message.Body);

The message I get looks like this:

@string3http://schemas.microsoft.com/2003/10/Serialization/�{{"StartTid":null,"Id":"c594eab8-382c-49ec-ba9c-2db0aaf5e167","CreationDate":"2018-02-11T17:42:42.9823622Z","TenantId":null}

It seems like Azure Scheduler is adding information to the message.

What is the correct way to retrieve only the message I entered in Azure Schedulers Message property without get all the garbage?

score 0 · Answer 1 · answered Feb 12 '18 at 08:19

var messageData = Encoding.UTF8.GetString(message.Body);

Based on your code, I assumed that you are using the Azure Service Bus .NET Standard Client SDK.

@string3http://schemas.microsoft.com/2003/10/Serialization/�{{"StartTid":null,"Id":"c594eab8-382c-49ec-ba9c-2db0aaf5e167","CreationDate":"2018-02-11T17:42:42.9823622Z","TenantId":null}

Per my testing, the Message property for the Service Bus action on Azure Portal is treated as set the string message. If you use the WindowsAzure.ServiceBus package, you could leverage the following code to retrieve your message:

var messageData = message.GetBody<string>();

And I assumed that Azure side use the approach as WindowsAzure.ServiceBus to send the message as follows:

myTopicClient.Send(new BrokeredMessage("<the-value-of-the-Message-property-you-set>"));

For your issue, you could use the approach for receiving the message by using the WindowsAzure.ServiceBus. I just de-compiled the WindowsAzure.ServiceBus library, you could use the following code:

var mySerializer = new DataContractSerializer(typeof(string));
var obj = mySerializer.ReadObject(XmlDictionaryReader.CreateBinaryReader(new MemoryStream(message.Body), XmlDictionaryReaderQuotas.Max));
Console.WriteLine($"message received: {obj}");

TEST:

Thanks you for your reply. The code I am using is from MS reference architecture: https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.cs. I'll try your code later today and see if it fixes the problem :) — Per B, Feb 12 '18 at 08:44
Where you able to figure out why Azure Scheduler adds characters to the message? — Per B, Feb 12 '18 at 09:30
I encountered the similar issue before when I send message(s) via the WindowsAzure.ServiceBus package, it would use `DataContractSerializer` and `XmlDictionaryWriter` to serialize your message by default. In general, we need to use the relevant client library to send/receive message. The above code could help you solve this issue? — Bruce Chen, Feb 12 '18 at 09:41

score 0 · Accepted Answer · answered Feb 12 '18 at 23:20

0

Azure Service Bus .NET Standard Client deals with streams only. When the old client is used and data is not sent using a stream, the receiving code based on Azure Service Bus .NET Standard Client has to perform de-serialization as was outlined in the other answer. There's a Broken Wire Compatability issue that was closed by the messaging team that has the details.

The good news is that you don't need the serializer code in your code base. The new client has an interop extension method for Message so you don't have to deal with data contract deserialization. For example, in your case you'd be able to write

var message = await messageReceiver.ReceiveAsync();
var data = message.GetBody<string>();

answered Feb 12 '18 at 23:20

Sean Feldman

23,443
7
55
80

Is there a method that can retrive the body as a string, no mather if it's the old or new client that has send it to the bus? – Per B Feb 13 '18 at 18:44
No. There's no such method. That's why I pointed you to the Broken Wire Compatability issue. The ASB team assumed that as a receiver of a message you know where it's coming from and therefore can decide how to handle it. I.e. with or w/o interoperability extension method. The only way you could get it working is if your sender would send a `stream` and not a string. The moment it's anything other than a `stream`, data serialization kicks in on the old client, forcing the new client to perform the deserialization. – Sean Feldman Feb 13 '18 at 19:55
Per my understanding, the interop extension just handles the de-serialization against the serialized message for you. The internal processing may be similar as the code in my answer. – Bruce Chen Feb 14 '18 at 03:45
Correct. The interop extension method removes the need in de-serializarion code. – Sean Feldman Feb 14 '18 at 04:10

Azure Scheduler and Azure Service Bus

2 Answers2