Using Fiddler for viewing exchanged messages with BizTalk

I was trying to view the SOAP messages and headers that were actually exchanged with a certain webservice.
To do so, I used Fiddler2… available from http://fiddler2.com/.

Fiddler2 will allow you to monitor traffic when using HTTP, SOAP or WCF ports in BizTalk. However, Fiddler will not trace any messages sent to endpoints by BizTalk by default as it does not use WinInet. To overcome this issue, you’ll need to configure a proxy to allow Fiddler to intercept the messages.
Note that these proxy settings will need to be removed when Fiddler is not running. Because otherwise all traffic through this proxy will not be received by anything.

In the send port of BizTalk go to the Configuration settings. Open the tab ‘Proxy’ to configure the necessary settings. Now you should change following settings:

  • Server: 127.0.0.1
  • Port: 8888

ProxySettingsInBTS

That’s is all you need to do. Now open fiddler2 and process a message.
If all is configured correctly, you should see the exchanged messages coming through fiddler.
Fiddler

BizTalk360 v6.0: new features explained

BizTalk360 released the brand new version v6.0 on March 8th, bringing several new features to the product.
In this blog post, we’ll address most of these new features that has been added in short.

A full overview of the new features can be found here.

1. Search and Action on Artifacts

This feature allows you to search for certain BizTalk artifacts, which can become really useful in large BizTalk applications.

searchArtifacts

You can search on these types of artifacts:

  • Applications
  • Orchestrations
  • Receive Ports
  • Receive Locations
  • Send Ports
  • Send Port Groups
  • Schemas
  • Pipelines
  • Transforms (BizTalk maps)

More details can be found on this BizTalk360 blog post.

2. Custom SQL query

This isn’t exactly a new feature in this version, it is however completely renewed.
Below screenshot will show you the difference between both versions. On the left side is a screenshot of version 5.0, while on the right side is version 6.0.

CustomSQLDiff

As you can see, there are some new functionalities added in the latest version.

First of all you can now export the query results to a CSV file.
Also, now there is the possibility to easily edit the query and execute the edited query again (using the link ‘Edit query’ as shown in the screenshot).

Another major new feature for these custom queries, is not shown in this screenshot but can be found in the ‘Monitor and Notify’ tab on the portal. The new version gives you the ability to create alerting on custom database queries that return a scalar result. A warning and error threshold level can be defined for this alert.
I think this gives BizTalk360 a lot of new possibilities to expand their active monitoring. One of these possibilities we were really missing in the previous version is for example some threshold alerting on the BizTalk Spool size, like explained in this BizTalk360 blog post.

3. SQL Job Outcome monitoring

In the previous version you only had the possibility to monitor if SQL jobs still had the desired status (enabled/disabled).
One of the useful new features is to also have alerting on the SQL Job outcome… So not only the job status can be monitored, but also alerts can be send when a job has failed.

I think this is a huge monitoring improvement, as in the previous version we tried to monitor the BizTalk sql jobs outcome using the MessageBox viewer report (integrated in the BizTalk360 platform).

SQLJobOutcome

4. Threshold monitoring window

The alarm settings have been expanded with the ability to restrict the threshold monitoring to certain days and timings.

AlarmSettings

5. Scheduled monitoring downtime

In the last version you were able to completely stop the alerting when doing some maintenance. You could configure this maintenance window for a certain time period.

With the latest version, the ability to schedule this maintenance window is also possible. You can define the maintenance window for a certain time period, but now you can also configure when this maintenance window will start.

MaintenanceSchedule

6. Monitoring dashboard

The monitoring dashboard has been updated and will also show the health status of the background monitoring service.

In the previous version we had to go to the settings window and choose ‘Monitoring Services’ under the BizTalk360 Health subcategory to have an overview of the health status of the background monitoring service. In our case for example, this posed the problem that the user we had defined to view the monitoring dashboard didn’t had the rights to check the health status of the monitoring service.

With Version 6.0 there still is the possibility to check the health of all monitoring services in the settings window… But the health status of the overall monitoring service will now also be visible in the monitoring dashboard. Which will be useful as this monitoring dashboard is displayed at a monitoring screen in our company, and now also shows the monitoring health status. While in the previous version it didn’t even had the rights to do so.

MonitoringDB

7. User Access Policy enhancements

The security settings has been expanded quite some bit. There are numerous new possibilities you can define rights to for the users.

In the below screenshot, you can see both the user access policies for version 5.0 (left screenshot) and version 6.0 (right screenshot).

SecuritySettings

As you can see in the screenshots, several access rights have been added in this new version. You can now also define separate rights for users on these features:

  • Monitoring Dashboard
  • Throttling analyser
  • Backup/DR visualizer
  • More advanced SQL query permissions (edit permission, list of queries etc) => when clicked on the link ‘Advanced’

These are only some of the features I found most useful… of course there are some more new features added as stated in the BizTalk360 blog post mentioned earlier.

Conclusion

BizTalk360 gives us huge benefits in monitoring all our environments. And these features will certainly improve our monitoring.
Still, there are some functionalities we think are missing and hope to see in one of the next versions:

  • Ability to save queries (message box, tracking, event viewer): queries need to be build all over again each time now
  • BizTalk query building enhancements: still missing the ability to ‘group by’ and increase the number of max matches to a self defined number
  • Alerting on throttling
  • Monitoring dashboards switching between defined alarms: this would be useful for the monitoring screen that we have set up
  • Layout changes in monitoring dashboard will reset on each refresh cycle: in the monitoring dashboard, you have the ability to move around all items as you want them to be (or zoom in/out)… however, on each refresh cycle (or on switching between alarms) the layout will reset to its default

How do you handle the BizTalk deployment?

For the deployment of BizTalk applications we use a custom made tool within our company. We were curious to have some feedback from the community on the deployment of BizTalk applications. How do you handle the biztalk deployments at your company?

Our deployment manager tool is based on the idea to store all used objects in a database model (BizTalk artifacts, but also stuff like MSMQ, file locations, SQL objects, etc. …). Most of these objects are added using auto discovery of the BizTalk databases, so manually adding of objects is reduced to a minimum. Above all, BizTalk artifacts can have a different configuration (binding) defined per environment (test, dev, prod, …).
It also allows you to define all dependencies. Again most of these dependencies will be defined by the tool automatically.
This way of working makes it possible for the tool to define which actions need to be taken to deploy a certain application (or just a part of the application or only some objects). The deployment manager tool will define which objects need to be removed and redeployed (also unenlisting/disabling and starting/enabling artifacts will be done by itself). As a result, using the tool will allow us to deploy much faster, because the objects to redeploy are reduced to an absolute minimum and no complete redeploy is needed (like BizTalk Deployment framework does for example).

Another very useful and much used functionality is the possibility to define complete business/functional flows, including some generic components. This makes sure you can also deploy or redeploy a complete (new) flow (like an order flow for example) by itself, including all necessary objects (receive and send ports, file locations, etc. …).

The deployment can be done cross BizTalk applications. So the separation in applications is no longer deployment dependent.

The most important part is to set the database model correct and keep it this way… this will guarantee a much easier and faster deployment, where each environment has its own version of the current deployed objects.

 

Please answer following questions:

  1.      Is your BizTalk deployment automated (BizTalk deployment framework, custom scripting with MSBuild or BTSTask, powershell scripts, etc. …), or do you just do manual deployment using MSI and binding files?
  2.        Which deployment tools or scripts are you using, or have you used before? And what are your thoughts of these tools (benefits and complaints)?
  3.        What do you think of a tool like our custom deployment manager tool (using autodiscovery, etc. …)?

Thanks for your replies.