Introduction

Azure BizTalk Services (formerly called Windows Azure BizTalk Services or WABS) is general available since mid-November 2013. This brand new service in Microsoft Azure is meant to provide EAI or B2B services through the cloud. The EAI Service enables you to exchange data through different protocols and transform it to and from different formats. Similar to what the on premise BizTalk offers through mapping and routing. The B2B services offers Businesses to exchange data between their partners. You can view it as a new way of EDI data exchange other than a value added network (VAN).

Azure BizTalk Services offers a portal, which gives you the ability to setup EDI solution and means to monitor your EAI Bridges.

Now monitoring of BizTalk Services is twofold.

  1. Microsoft Azure Portal (HTML 5)
  2. Azure BizTalk Services Portal (Silverlight)

Microsoft Azure Portal (HTML 5)

One, you have the Microsoft Azure Portal (HTML 5) that gives you a view of metrics like CPU Usage, Failures At Source and so on. You can add a few more yourself as screenshot below indicates.

Azure BizTalk Services Portal (Silverlight)

Two there is the Azure BizTalk Services Portal (Silverlight) provisioned for you after creating a BizTalk Service through Microsoft Azure Portal. This portal shows your partners, agreements, bridges, resources, tracking and settings.

 

You can use both of these portals for diagnostic purposes. Yet both will not give you the full story on what is going on in your bridge.

 

For tracking purposes a Azure SQL Database is provisioned for you during the creation of your BizTalk Service. This database contains your tracking data for bridges and EDI agreements. This tracking solely persists meta/context data of messages following through the BizTalk Service. To get a better comprehensive view of what is going through your bridge you can build a custom solution.

This article is intended to provide means or guidance to roll your own custom diagnostic solution for BizTalk Services Bridges, which is building a custom solution for monitoring messages going in and out of a bridge.

Custom solution

Microsoft has many technologies available that enables you to build custom diagnostic solution for WABS EAI Bridge. For instance you could build a website or form applications and the data you need comes from the provisioned tracking database. To persist the messages flowing through the bridge you need to do some customizations.

The way to persist messages going in and out of a bridge you need to do two things. One is to include custom code within your BizTalk Services Bridge. Two is defining a new table to contain your message data you want to persist.

A new table in Azure SQL Database

As described earlier when you provision a BizTalk Service through the Microsoft Azure Portal a database in Azure SQL Database service will be created for you. During configuration of your BizTalk Service you will specify details for this database. After the provision of the service you can manage this database through the Microsoft Azure Portal.

To manage your database you connect to it and end up in a Silverlight portal. Here you can manage your database. So you can execute the following SQL statement to create a table to persist the message data.

CREATE TABLE [dbo].[TrackRecordMessageBody]
(
 [Id] BIGINT NOT NULL PRIMARY KEY IDENTITY,
    [MessageId] NVARCHAR(50) NULL,
    [MessageBody] NVARCHAR(MAX) NULL
)

After addition of the table you will have the following tables in your tracking database in Azure SQL Database.

 

Custom Code

Within your Visual Studio BizTalk Service solution you add a C# library project. This project needs a reference to the Microsoft.BizTalk.Services.dll. This assembly can be found at <install path>\Program Files\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\Windows Azure BizTalk Services SDK.  In the c# class you include the Microsoft.BizTalk.Services namespace. Next step is to implement the IMessageInspector interface.

public Task Execute(IMessage message, IMessageInspectorContext context)
        {
            return Task.Factory.StartNew( () => {
                StoreMessage(message.Data, context);
            });
        }

After creating the class you build it and add a reference to it from the BizTalk Service project. The created assembly must be deployed along with the BizTalk Service project. The CopyLocal property has be set to True.

Now that the custom code is ready, build and referenced in your BizTalk Services project you can use in any bridge configuration stage that exposes the On Enter Inspector and On Exit Inspector properties.

In these properties you provide the assembly-qualified name of the type as part of the property. To get the fully qualified name you can use a tool that can be found on MSDN Code Gallery.

Note: From MSDN BizTalk Services Documentation: How to Include Custom Code in Bridges (http://msdn.microsoft.com/en-us/library/windowsazure/dn232389.aspx)

If you want to include the custom code before the message enters a specific stage, you must include the assembly-qualified name for the On Enter Inspector property. Similarly, if you want to include the custom code after the message exits a specific stage, include the assembly-qualified name for the On Exit Inspector property. If you have used configuration properties in your custom code, you can also specify the values for those properties here.

After you have included the custom in the required stages you can build and deploy your bridge.

 

Test the custom solution

To test your custom tracking solution you can send a message to your bridge.

Look at the tracking data.

Subsequently you can then look at the message data available in the database table.

 

Wrap up

This article showed a part of a complete solution you can build for the purpose of diagnosis and/or monitoring your bridges in Azure BizTalk Services. The content of messages (the body) flowing through your bridge cannot be viewed with the out-of the box feature set. Yet by inserting custom code into your bridge you can as demonstrated in this article. You can acquire additional information about the messages going in and out by access the Azure SQL Database and build filters on top of that.

See Also

For custom code in Azure BizTalk Services you can look at the following resources:

Another important place to find a huge amount of Azure BizTalk Services related articles is the TechNet Wiki itself. The best entry point is Azure BizTalk Services resources on the TechNet Wiki.

If you are also looking for BizTalk Server related articles, the best entry point is BizTalk Server Resources on the TechNet Wiki.