SharePoint 2013 Workflow - Advanced Workflow Debugging with Fiddler

 

来自：Andrew Connell [MVP SharePoint]   |  时间：2012-07-18 19:26:30 

原文链接： http://www.andrewconnell.com/blog/archive/2012/07/18/sharepoint-2013-workflow-advanced-workflow-debugging-with-fiddler.aspx

In previous posts I've talked about what's new with workflow in SharePoint 2013 as well as the very cool new DynamicValue data type which comes in supremely helpful when working with Odata services or anything service that speaks JSON. With this new architecture you'll see there's a lot of chatter between SharePoint & the Windows Azure Workflow (WAW) farm over the wire. In addition, now that our workflows can not only call web services but also we're advised to stop putting custom code in the workflow but rather stuff it in services and call these services with the new HTTP activities, there's even more over-the-wire communication going on.

Wouldn't it be nice to debug this or watch all this go on? Well you can thanks to Fiddler . The trick is you just need to know how to intercept the calls from SharePoint & WAW so you can see everything in the Fiddler trace. There are just a few steps to do:

Tweak the .NET Framework Config

Open the two machine.config files for the framework and add the following to the bottom of each, just before the closing </configuration>. Oh... Please back them up first so you can't go all "oh AC broke my dev box" on me…

<system.net>
<defaultProxy enabled="true">
<proxy bypassonlocal="false" usesystemdefault="true" />
</defaultProxy>
</system.net>

• %systemdrive%\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
• %systemdrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config:

Configure Fiddler to Intercept HTTP(s) Traffic

Now configure Fiddler to intercept the traffic coming from SharePoint and WAW. If you are using a HOSTS file for your DNS stuff… err cheating… make sure you import that:

1. Fiddler > Tools > Hosts
2. Click the Import Windows Hosts File link

Next up, setup the connections in the options dialog:

1. Fiddler > Tools > Fiddler Options > Connections [tab]
2. Make sure the following are checked, anything not mentioned here should be unchecked:
   1. Reuse client connections
   2. Reuse connections to servers
   3. Act as system proxy on startup
   1. Monitor all connections

Configure SharePoint to Trust Traffic from Fiddler

Fiddler not only is a HTTP debugging proxy used to see what's going on, but it is also going to forward the calls along to the intended target. There's one catch here from using Fiddler in normal debugging practices. Because SharePoint & WAW talk to each other over SSL, you have to tell them to trust Fiddlers cert which is used to re-encrypt the traffic after debugging it. In order to let SharePoint & WAW continue to work while debugging, you need to install the Fiddler certificate as a trusted root on the box.

First, tell Fiddler to decrypt the traffic and export it's certificate:

1. Fiddler > Tools > Fiddler Options > HTTPS [tab]
2. Check Capture HTTPS Traffic
3. Check Decrypt HTTPS Traffic

4. Click the button Export Root Certificate to Desktop and then click Yes to confirm.

5. You'll get yet another confirmation prompt about installing the cert from a CA with something like "DO NOT TRUST" in the dialog… but you can trust me.. Just click YES :)

6. Last up, click the Ignore server certificate errors.

Last step is to install the certificate you just exported to the desktop. Launch theSharePoint Management PowerShell Console as an administrator and type the following:

• certUtil.exe -addstore -enterprise -f -v root [path to desktop]\FiddlerRoot.cer
• $trustCert = Get-PfxCertificate [path to desktop]\FiddlerRoot.cer
• New-SPTrustedRootAuthority -Name "Fiddler" -Certificate $trustCert
• IISRESET

Now Test Away!

Now you're all configured… the last thing is to actually check it out. The most important thing here is to start things up as the right user and in the right order.

1. First, login to the machine(s) where you have SharePoint & WAW installed as the user that you are using as the service account for each product. For me on my dev box, I run them under the same service account on the same box so this is easy. You must login as the user that you're using as the service account to see the traffic.
2. From that login, launch Fiddler.
3. Now, in order for Fiddler to catch the traffic both apps need to be restarted so when they start up, Fiddler will be able to step between them.
   1. Recycle the web server by using the IISRESET command from a command prompt. Yes, you have to do this again AFTER you have Fiddler running.
   2. Recycle the WAW server by finding the service called WorkflowBackendService… I think that's the name… writing this from memory.

That's it! Now you can login to your dev machine as your developer account and test a workflow. You should be catching the traffic and watch all the client side object model (CSOM) chatter going on from WAW > SharePoint and SharePoint calling WAW… pretty neat stuff!