Explanation
This diagram reflects the IoT scenario:
We encountered an issue in Logic Apps, the moment we tried to parse the message into a JSON object. After some investigation, we realized that the ServiceBus message wasn’t actually a JSON message. It was preceded by string serialization “overhead”.
Thanks to our favourite search engine, we came across this blog that nicely explains the cause of the issue. The problem is situated at the sender of the message. The issue is caused, because the BrokeredMessage is created with a string object:
If you control the sender side code, you can resolve the problem by passing a stream object instead.
Solution
Unfortunately we cannot change the way Azure Stream Analytics behaves, so we need to deal with it at receiver side. I’ve found several blogs and forum answers, suggesting to clean up the “serialization garbage” with an Azure Function. Although this is a valuable solution, I always tend to avoid additional components if not really needed. Introducing Azure Functions comes with additional cost, storage, deployment complexity, maintenance, etc…
As this is actually pure string manipulation, I had a look at the available string functions in the Logic Apps Workflow Definition Language. The following expression removes the unwanted “serialization overhead”:
If you use this, in combination with the Parse JSON action, you have a user-friendly way to extract data from the JSON in the next steps of the Logic App. In the sample below, I just used the Terminate action for testing purpose. You can now easily use SensorId, Temperature, etc…
Conclusion
It’s a pity that Azure Stream Analytics doesn’t behave as expected when sending messages to Azure Service Bus. Luckely, we were able to fix it easily in the Logic App. Before reaching out to Azure Functions, as an extensibility option, it’s advised to have an in-depth look at the available Logic Apps Workflow Definition Language functions.
Hope this was a timesaver!
Cheers,
Toon
Subscribe to our RSS feed