Azure BizTalk Services (formerly called Windows Azure BizTalk Services or WABS) is general available now as a service within Microsoft Azure. 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 offer 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).

During provisioning of a BizTalk Service you need to specify tracking database (Azure SQL Database), and a storage account for monitoring and archiving.

Figure 1. Tracking, Monitoring and Archiving BizTalk Services.

The tracking data can be useful for diagnostic purposes and to monitor what messages goes through BizTalk Service. The Tracking Database can be extended to meet your own tracking requirements, see Azure BizTalk Services EAI Bridges – Diagnostics. You can also use the tracking data for troubleshooting combined with the debug logs stored in your storage account.

The Scope of this article is to provide insight how to troubleshoot a BizTalk Service Bridge.

Storage account

Provisioning of a BizTalk Service includes a step, where you specify a storage account. In the final tab called Specify monitoring/archiving settings you specify the storage account. You either create a new or use an existing storage account to store monitoring and archiving data. Note that this storage account can be used by only one BizTalk Service!

During provisioning the following will happen:

  • A storage account will be created in case an existing storage account has not been assigned,
  • Blob containers (blobs, tables) will be created.

Figure 2. Azure Storage Blob Containers.

After provisioning you could access what’s available in these containers using the server explorer. Within Visual Studio, navigate to Microsoft Azure in the Server Explorer, select Storage. You subsequently need to log in and then you can navigate to your storage account.

Figure 3. Storage Account Explorer.

You can view what's inside the blobs and tables. By right clicking on the blobs you can see what is inside.

Figure 4. View Blob-container contents.

By right clicking on the tables you can view the contents.

Figure 5. View Table Content.


Each message send to a BizTalk Service, for instance to a bridge endpoint a response will be sent back. Regardless if it is successful or a failure. The header of the response includes a tracking ID. This ID can be used in the Tracking Messages feature in Azure BizTalk Services Portal to troubleshoot.

You can use the BizTalk Service explorer to send a message to a bridge and see what the tracking id is.

Figure 6. BizTalk Service Explorer sending a message.

In the Microsoft Azure Portal under Tracking you can see the information regarding the message being sent to the Bridge Endpoint.

Figure 7. Tracking part in the BizTalk Service Portal.

You can select the event and click Details in the lower pane of the portal.

Figure 8.
Detail of Tracking Event.

This metadata is retrieved from the database residing in Azure SQL Database.

Figure 9. Data from the Pipeline and source tracking view in SQL Azure database.

You can view more details through debug logs, which are available in the WADLogsTable. You can select the details from the table and paste it in excel. Below you see the what is under the message column, which can be interesting to see what's in this case happens in the bridge.

Figure 10. Data dump of messages column of each row in the WADSLogTable.

The debug logs in the table contain the following information:

  • Loading an assembly
  • Adding or updating an artifact, like a Transform
  • Adding, updating, or deleting Bridge Configuration
  • Message submitted to the Bridge pipeline
  • Bridge stages, including their Begin Execute and End Execute events
  • Faults

Note: The debug logs are only available during the development process.

In each row under you will this kind of data:

Partition Key column


Row Key



12/29/2013 3:14:52 PM



Deployment ID



IntegrationRole IntegrationRole_IN_0







Message column

Stage validator execute called.

RequestId                           =             f3d60453-a63a-44e9-811a-7ac47e1b111d.

TrackId                               =             f3d60453-a63a-44e9-811a-7ac47e1b111d.

ServiceNamespace            =             default.

RuntimeUrl                        =             /xmlrequestreplybridge1.; TraceSource 'Microsoft-Integration-PipelineService' event

Wrap up

This article provided some insight how to troubleshoot a BizTalk Service Bridge. There are two main sources, where you can find data for troubleshooting. That is, through tracking database in the Azure SQL Database, which contains the data that is visible in tracking messages feature of the BizTalk Services Portal. And the storage account that has blobs and tables. The WADLogsTable contains debug logs you can access to have a clear view of what is going inside the bridge.

See Also

For documentation on BizTalk Services see Azure BizTalk Services documentation.

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.