BizTalk Server 2013: Monitor Traffic Using Fiddler2

  • Article

Introduction

Fiddler2 is a Web Debugging Proxy, which logs all the Hyper Text Transfer Protocol (HTTP) or Secure HyperText Transfer Protocol (HTTPS) traffic between your computer and the Internet. Fiddler2 allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Although the tool is intended to use to monitor HTTP(s) traffic for many browsers, it can be useful to monitor incoming and outgoing traffic HTTP(S) of your BizTalk receive locations or send ports configured with any of the HTTP-based adapters:

  • HTTP
  • SOAP
  • WCF-BasicHttp
  • WCF-CustomIsolated
  • WCF-Custom ((based on what binding has been chosen)
  • WCF-WebHttp
  • WCF-WSHttp
  • WCF-BasicHttpRelay
  • WCF-WebHttp

This article is intended to create awareness of how to use the tool to monitor or inspect HTTP(S) traffic (messaging) using Fiddler2 through a basic scenario using the WCF-BasicHttpRelay adapter in BizTalk Server 2013.

Scenario

There a quite a few adapters that involve the HTTP protocol (see the list in the introduction). The scenario for each adapter will be similar when it comes to using Fiddler2. You download and install Fiddler2, you start it and configure it to monitor the HTTP(S) traffic.

In this article the following scenario will be used to demonstrate the use of Fiddler2. A message will be sent from a client (Windows Service Bus Explorer) to an relay endpoint in the Windows Azure Service Bus. The relay endpoint is basically a listener setup by configuring a receive location with the WCF-BasicHttpRelay and enabling it.

Figure 1. Diagram of the scenario.

Set up

To set up the described scenario you need Fiddler2, BizTalk Server 2013 and the Service Bus Explorer Tool.

Fiddler2

To setup and use Fiddler2 is easy. You download the tool and install it on your (BizTalk) machine.

Figure 2. Fiddler2 (click to enlarge).

WCF-BasicHttpRelay

With BizTalk Server 2013 you can easily register an endpoint in the Windows Azure Service Bus. You can create a receive port and within that port you can create one or more receive locations. The receive location can be configured choosing the WCF-BasicHttpRelay. You configure the adapter through a dialog WCF-BasicHttpRelay Transport Properties, see MSDN How to Configure a WCF-BasicHttpRelay Receive Location. By enabling the configured receive location, you will have an HTTP listener in the Windows Azure Service Bus.


Figure 3. Relay endpoint in Windows Azure Service Bus namespace: tnwiki (click to enlarge).

Service Bus Explorer

The Service Bus Explorer is a tool by Paolo Salvatori that enables you to test entities with the Windows Azure Service Bus. You download this tool from the MSDN Code Gallery, open it in Visual Studio 2012, build and run it. You connect to your namespace in Windows Azure containing the entities like queues, topics and relays.

Figure 4. Connect to the Service Bus Namespace using the Service Bus Explorer.

With the Service Bus Namespace explorer you could see the HTTP listener (i.e. relay endpoint) set up through BizTalk Server.

Figure 5. Relay endpoint in the Service Bus Namespace.

Monitor HTTP traffic using Fiddler2

To monitor HTTP traffic from client (Service Bus Explorer) to a HTTP listener a message will be sent using the Service Bus Explorer. You can provide the payload in the Message Text area, select the appropriate binding in Sender Tab and click start to send the message.

Figure 6. Sending a message (payload) using the Service Bus Explorer (click to enlarge).

In Fiddler2 you will the traffic between the Service Bus Explorer and Windows Azure Relay endpoint (i.e. HTTP listener). By selecting the session going to the relay endpoint you can observe the message (payload) going to the relay endpoint:

  1. Select the session to the relay endpoint
  2. Choose Inspectors tab on right hand side
  3. Choose XML (outgoing)
  4. Choose RAW (incoming)

Figure 7. Monitor traffic with Fiddler2 (click to enlarge).

The way it works is that when a message is sent to the relay endpoint the credentials used to connect to namespace are being used to get the necessary token to send a message to the relay endpoint: https://tnwiki.servicebus.windows.net/data/, which is the address specified in the BasicHttpRelay Transport Properties General tab. After the token is obtained a connection will be established with tnwiki.servicebus.windows.net. This is the address of service registry where the endpoint resides. Subsequently as can be observed in figure 7 the message (payload) will be send. The message will be routed to BizTalk through the relay endpoint. BizTalk will in this specific scenario route the message to a file folder.

Figure 8. Message in a file folder (click to enlarge).

Routing to file folder is to illustrate the fact that it is easy to receive messages through a relay endpoint and subsequently process or route them. With Fiddler2 you can monitor the traffic between the client and relay endpoint (i.e. HTTP listener in Windows Azure Service Bus, see Figure 3).

Wrap up

Fiddler2 can be a valuable asset for a BizTalk developer or BizTalk administrator to monitor the in- and outgoing traffic from BizTalk ports that have been configured with HTTP-based adapters. In scenario’s involving SOAP, REST and Windows Azure Service Bus Fiddler can be of value to monitor HTTP(S) traffic for debugging purposes or to inspect what goes over the wire. This article has demonstrated the added value the tool can have with these kind of scenario’s.

The tool is free of charge, supported and innovated by Telerik. It has many features and some of them are useful for us BizTalk professionals. An alternative to Fiddler is WireShark, which is a network protocol analyzer and has similar features on-board yet it’s scope is not limited to just the HTTP protocol. In case you need to monitor a broad spectrum of protocols than WireShark can be more sophisticated tool to do that.

In case you need to monitor traffic between Relay Service endpoint and your BizTalk Service (receive location) than is never HTTP traffic and cannot be monitored by Fiddler2. However, a product like Nevatech’s services virtualization product, Sentinet (Sentinet for Windows Azure) can monitor everything and at any network communication leg (outside or inside the firewall).

As stated previously Fiddler2 has a great feature set and some of it can be used by us BizTalk professionals. This article just scratches the surface of its capabilities. You will find more its capabilities through the resources section.

Resources

You can find the following resources on Fiddler for background information, its feature and other areas where it is used:

See Also

Read suggested related topics:

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.