The next few posts are for those who saw me speaking at the most recent CRMUG UK Chapter meeting about Fiddler2 and wanted to know more (and as a thank you to those who voted for me in X(rm) factor!). I've been using Fiddler for web debugging for as long as I can remember and I can honestly say that I could not live without it when Developing Dynamics CRM extensions as well as supporting and diagnosing issues with existing solutions. I first blogged about it in connection with SparkleXRM development but this post elaborates further on the super powers it gives you!
What is a Web Debugger?
Fiddler2 is a Web Debugger which basically means that it sits between your browser and the server just like any normal proxy, but the difference is that it shows you all the HTTP traffic going back and forwards, allows you to visualise it in an easy to read format as well as allowing you to 'Fiddler' with it – hence the name.
You can easily install fiddler for free by downloading it from http://www.telerik.com/fiddler.
The following posts describe the superpowers that Fiddler can give you whilst you are developing solutions or supporting your end users.
X-Ray Vision
When you perform any actions in your browser whilst Fiddler is running then each and every request/response is being logged for your viewing pleasure. This log is incredibly useful when you need to see what requests your JavaScript or Silverlight is sending to the server. It shows you the error details even when the user interface may simply report that an 'Error has occurred' without any details. The prize for the most unhelpful error goes to Silverlight with its 'Not Found' message – the actual error can only be discovered with a tool like Fiddler2 by examining the response from the server to see the true exception that is hidden by Silverlight. The HTTP error code is your starting point and Fiddler makes it easy to see these at a glance by its colour coding of request status codes - the most important of which are HTTP 500 requests that are coloured red. For any solution you are developing, the bare minimum you should look at is for any 404 or 500 responses.
If you wanted to diagnose a problem that a user was having with CRM that could not reproduce then try following these steps:
- Ask the user experiencing the issue to install Fiddler2 (this may require administrator privileges if their workstation is locked down).
- Get to the point where they can reproduce the problem – just before they click the button or run the query, or whatever!
- Start Fiddler
- Ask the user to reproduce the issue
- Ask the user to click File->Save->All Sessions and send you the file.
- Once you've got the file you can load it into your own copy of Fiddler to diagnose the issue.
If the user has IE9 or above and they are not using the outlook client then the really neat thing about the latest version of Fiddler is that it can import the F12 Network trace. This allows you to capture a trace without installing anything on the client and then inspect it using Fiddlers user interface. To capture the network traffic using IE:
- Get to the point where they are about to reproduce the issue
- Press F12
- Press Ctrl-4
- Press F5 (to start the trace)
- Reproduce the issue
- Switch back to the F12 debugger window by selecting it
- Press Shift-F5 to stop the trace
- Click the 'Export Captured Traffic' button and send you the file
Now you can load this file into fiddler using File->Import Sessions->IE's F12 NetXML format file.
Once you found the requests that you are interested in you can then use the inspectors to review the contents – the request is shown on the top and the response is shown on the bottom half of the right panel. Both the request and response inspectors gives you a number of tabs to visualise in different ways depending on the content type. If you are looking at JavaScript, HTML or XML your best bet is the SyntaxView tab that even has a 'Format Xml' and 'Format Script/JSON' option on the context menu. This is great to looking at SOAP requests and responses that are sent from JavaScript to make sure they are correctly formatted.
The following screen shows a soap request from JavaScript and inspectors in syntax view with 'Format Xml' selected.
This technique is going to save you lots of time when trying to work out what is going on over the phone to your users!
Next up is Invisibility!
@ScottDurow