BizTalk Migration To Azure (BAM)
Besides the MessageBox Functionality, the BizTalk Message and Routing we need some monitoring as well.
In BizTalk I would use a static tracking profile with 10 date fields to store information that is important to the Business user. There are more fields but they are all standard BizTalk fields. I use this to create a kind of track and trace for every received message.This log is readable for the Business user and has no technical data at all. It’s just a kind of track and trace for each received message. A sample of this is below.
?
So this is indeed standard logging but specifically targeted to the business user. The business user understands what happened to his message and can see if anything went wrong in the process. For me this is crucial functionality because it keeps a lot of people away from my desk. All this data can be viewed in a portal where business users can find what they need.
For sure this is functionality we need in Azure as well. Sure, Azure is logging a lot as well. But none of that logging is designed with the business user in mind. It’s all technical logging. If a business user would ask me what happened to Invoice1 and I pointed him to the standard logs that Azure provides he still knows nothing.
领英推荐
And furthermore if you have multiple integrations implemented, where would the logging be?, and how would it look?, that would probably depend on the person who implemented the integration. I don’t want to bother the business user with that kind of problems.
So how would we implement track and trace in the Azure scenario……
Well for starters we have a Claim with all the data in it (the BizTalk Message equivalent), if we write this claim to Log Analytics on regular intervals, we could create a useful track and trace for the business user. Furthermore we could use the awesome power of KQL to extract whatever data we want. So a track and trace should be doable.
I implemented the functionality to push the claim to the Log Analytics REST API.
Then in the OnRamp router I write the full claim to Log Analytics just before the message is written to the Queue of the routing endpoint.
And BAM, there we have it, full, uniform track and trace information for every message that is being processed.
I think is a very good approach. With this RESt API will be possible to enrich to cover all business requirements. Good work!!!.