Windows Azure BizTalk Services (WABS) is general available now as a service within Windows Azure. To test or debug your Windows Azure BizTalk Service Bridge you can rely on using the BizTalk Service Explorer. This explorer is similar to another Visual Studio add-in like the Service Bus or Windows Azure Storage.
The BizTalk Service explorer offers the following features:
- Browsing artifacts in you BizTalk Service
- Explore tracked events within your bridge
- Upload and download artifacts
- Restarting the BizTalk service
- Test and debug bridges
The explorer for WABS can be added within Visual Studio via extensions and updates, where you can search for in the Visual Studio Gallery. To add this explorer you need to go to Tools within Visual Studio. Subsequently you go to Extensions and updates… You then search in the Visual Studio Gallery online.
You can now add a BizTalk Service(s) you have provisioned in Windows Azure. By simple right clicking the Windows Azure BizTalk Services you can select Add BizTalk Service … A dialog will appear where you have to fill in service name of your BizTalk Service, the namespace and issuer secret (obtained through Access Control Services).
After clicking OK you will see the specified BizTalk Service appear in the BizTalk Service Explorer.
The BizTalk Service explorer offers several features. In the next couple of paragraphs each feature will be discussed by means of a sample bridge. This bridge is a two-way bridge that will receive a message, transform it to required format to be send to a back-end SQL database, and the response will be routed back to the caller through the bridge.
The BizTalk Service Explorer offers the ability to browse through the BizTalk Service. You can see the assemblies, bridges, certificates, schemas and transforms that have been deployed to your BizTalk Service.
By expanding the artifact nodes you can browse through them.
Previous paragraph showed how to browse through the BizTalk Service artifacts. In case messages are send to a bridge than these will be tracked that is metadata like tracking id, track point and timestamps are always tracked. This also accounts for fault information of failed messages. The level of tracking can be specified in the bridge with Visual Studio. You can either track message processing events and/or all message properties.
By selecting a Bridge you can expand the tracking events to browse through tracked events.
BizTalk Service offer the ability to upload a new artifact. In case you right click on the Assemblies, Bridges, Certificates, Schemas or Transforms node you will see a dialog with the option Upload New…
In case you want to download an artifact then you have to select a certain artifact within Assemblies, Bridges, Certificates, Schemas or Transforms.
The BizTalk Service can be restarted through the BizTalk Services Explorer. By right clicking the desired BizTalk Service you have the option available.
The most interesting feature of the BizTalk Service Explorer for a developer is the test and debug feature.
The test feature gives the developer the ability to send a test message to the bridge. By right clicking a specific bridge you have the option Send Test Message …
A dialog will appear. Here you can load a test message.
Subsequently you hit the Send button and the message will be send to the bridge endpoint:
The response will be appear in the right pane.
As you can also see the tracking id is presented. This id can be used to browse in tracked events and access the particular event.
To debug a bridge you need to do some configuration on the BizTalk Service. By right clicking the BizTalk Service and select properties you can specify debug properties i.e. debugging credentials. Credentials depend on Access Control Namespace of your Relay.
To debug a bridge you select the bridge you want to debug. You right click the bridge and choose the option Debug. A dialog will appear.
You load a test message similar to send a test message to a bridge and click Send Message.
You can now step through the process by clicking Continue.
You can continue doing this examining each step until the end.
Like sending a test message you see an id i.e. request id that you can use to browse through the tracked events.
Debugging a bridge gives the developer the ability to have a clear view on what is happening inside the bridge. When a bridge is in debug mode all messages going through the bridge can be viewed. Therefore debugging bridges in production environment is not advisable (Sam Vanhoutte – Introduction Step by step debugging of bridges in Windows Azure BizTalk Services ).
BizTalk Services Explorer is a welcome addition to building a BizTalk Service solution (a bridge). The feature provide features that enhance developer productivity. A developer doesn’t need to build a client to test a bridge and has the ability to test the bridge in run-time. Other feature aid in the deployment aspect. A developer doesn’t have to deploy his complete solution to the BizTalk Service if you he/she makes a change to a certain artifact. The BizTalk Service explorer available now is a first version (alpha) and you can expect that it will be enhanced and updated in the future.