Today’s guest blogger is Blake Scarlavai, a Senior CRM Developer at Sonoma Partners.
Fiddler can be extremely helpful in troubleshooting CRM issues and also great for testing web requests before deploying. In this post I will go over some of the helpful and maybe not-so-obvious features of Fiddler.
First things first, you can find Fiddler here - http://fiddler2.com/fiddler2/version.asp. Also to get started we first need to turn on a few settings.
If you are using HTTPS then go into Tools – Fiddler Options -> HTTPS Tab and check the following options:
- Capture HTTPS CONNECTs
- Decrypt HTTPS traffic
- Ignore server certificate errors
Next, click on the Composer tab on the right side panel of Fiddler. Then click on the Options sub-tab and select Automatically Authenticate
With these settings turned on, we can now perform the following techniques.
The main feature of Fiddler is being able to log and inspect web requests being made from the client machine. In CRM this is very helpful for debugging any requests that are failing and it also can be used to see how much traffic there is and how long each request takes. If you have ever seen a “Not Found” error coming from a Silverlight web request then usually Fiddler can be used to spot the failing request and uncover a more helpful detailed error.
To get started logging traffic. Make sure the bottom left corner of Fiddler says “Capturing” and if not click the empty box to enable logging.
Once logging is enabled, browse to CRM and navigate to the area that makes the failing web request. You should see a request on the left pane in red which indicates that there was an issue.
If we click on the red web request we can then use the Inspectors tab on the right side pane to inspect the web request. The top pane will show information about the request and the bottom pane will show information about the response. For my specific example, I can use the bottom pane to see the response and notice that there is a more detailed error being returned. Fiddler is telling me that “‘SystemUser’ entity does not contain attribute with Name ‘new_test’.”. I know that this attribute doesn’t exist in my Organization and I can check the top pane to view the request and see that a query for SystemUser is being made and trying to return the non-existent ‘new_test’ attribute.
For performance tuning on a CRM form, we can clear out all the existing web requests using Ctrl-X and then stop capturing until we are ready to pull up the form. Once we are ready to pull up the form, click the box at the bottom left to start capturing traffic again. Now open the CRM form and when it is finished loading, click the box again to stop traffic. Now highlight all the web requests in the left pane and in the right pane, click the Statistics tab at the top. This will display some helpful information such as how many requests were made, the bytes sent and received, and the amount of time the requests took. In my example below, there were very few requests made and it took about 1.5 seconds to complete.
We can see a chronological view by highlighting all of the web requests again and selecting the Timeline tab on the right. This will show a breakdown of how long each request took.
A very helpful feature in Fiddler is the Composer feature. If we go back to the very first example where a query for SystemUser is being made with a non-existent column, we can use the Composer tab to fix the very same web request. To fix this we can go to CRM where the failing web request happens. Capture that web request using fiddler and now click on the Composer tab on the top right pane. Then drag the web request from the left pane over to the right pane. This will auto-populate values in the Composer tab and allow us to edit the Request Body at the bottom of the right pane.
In my example I can remove the problem attribute in the Request Body highlighted above. Then I can recreate the web request without the problem attribute by clicking Execute at the top right. This will perform the new web request and log it in fiddler as well. As shown below using the Inspectors tab, my new web request was executed without the problem attribute and data was successfully returned in the Response pane at the bottom.
We can take the above example with the Composer feature even further. First grab the TextView of the Response body above (the working web request) and copy and paste it into notepad. Save that file as XML. Now highlight the problem web request in the left pane and click the AutoResponder tab at the top of the right pane. In the AutoResponder pane first check Enable automatic responses and Unmatched requests passthrough. Now click Add at the top right to create a new rule. At the very bottom, use the second drop down to select the XML file that was saved in the first step. Then click Save. What this does is create a rule that says “If a request URI matches this specific URI, then respond with the selected XML”. In our scenario this will look for any requests that match the URI of our problem request and return the XML of our working web request.
With this AutoResponder rule setup we can now test our fix for the problem web request by navigating to it again in CRM and it should work as if there isn’t a bug in our query and respond with the correct data.
By using the above techniques we can troubleshoot our web request issues to uncover a helpful error, test our fix to the problem web request and see it in action without deploying any code updates. Now that we have our fix, we can make our code changes and deploy it for testing.