Debug your PCFs during development using Fiddler AutoResponder

You might have heard about using Fiddler AutoResponder to debug PCFs. I’ve saw the blogs, videos and webcasts from the brilliant Scott Durow, Natraj Yegnaraman and Ivan Ficko. But at first I thought, that’s more for ocasionally debugging, like troubleshooting on production environment. I thought that for daily debugging during development, it’s not reliable enough. After all, I had the “PCF Debug Harness”. That changed when I’ve started developing a dataset PCF. And now I wouldn’t want to miss it anymore. But first I needed to find out how to use it, in order to feel that it belongs to my development tools.

In case you already use Fiddler, maybe you want to skip the “why”, and go to “requirements” and “how to”. In case you don’t use it already, please let me tell you what it’s good for. Sometimes it doesn’t work in the beginning, and need some time to figure it out. Don’t give up, it’s definitely worth it.

“Debug Harness” – not enough?

When I change to a tool, I need to know why I need it. Beeing cool is not enough, because I try to avoid “surprises” of tools not working till the end, making me loose time with troubleshooting or forcing me to go back and forth between tools.

For debugging field-type PCFs, I was happy with the Debug Harness for a while. It feels confortable to debug directly from VSCode, without having to upload the code. It allows us to change the parameters and the size of the PCF directly there. That’s not easy in the real environment, since for changing the parameters we need to open the form customizing and to publish. Also, it shows clearly what’s the output parameter of the PCF. We are so much faster with the harness.

npm start watch

We can see how the output is changing to 1 and after that to undefined

And you can go pretty far with that. The Debug Harness doesn’t allow requests, but you can mock them and go on. The biggest pain point is styling, since in the harness the styles are not exactly like in the real environment.

But when you start developing dataset PCFs, you cannot really test using with the Harness. In the beginning of the Preview-Phase of the PCFs, the product team responded very fast to our ideas, and they provided a way for the harness to use exported data from a real environment. The exported csv can be provided as a dataset-source for the debug harness. Unfortunatelly there is some metadata missing there. Also you have to choose that file and map the field properties over and over again, so it’s too much time-consuming.

The other option is using pac cli, to upload the debug version

pac pcf push -pp <prefix>

In the beginning it was uploading only the changes and was pretty fast, but lately it always makes a full upload, and it became very time consuming. So that was the point where the pain was big enough, to make me try the Fiddler AutoResponder.

Fiddler Setup

In case you are not familiar with Fiddler AutoResponder: you can define a filter for the resources you develop. When the filter matches, the files won’t be taken from the server, but from a location on your local computer instead.

I won’t go into details about how to install the Fiddler. I can recommend two very good sources:

• The official docs, where Fiddler AutoResponder is recommended for developing WebResources
• Scott Durow’s Blog about using Fiddler AutoResponder for CanvasApps (the “Access-Congtrol-Allow-Origin” header setting, saved me)

The requirements

If I seriously change the development based on Fiddler Autoresponder, I needed to find the answers to following requirements first:

• Bundle and watch mode
  • The bundle should be generated automatically, just like in the debug Harness
• Avoid accidentally messing up controls
  • If I take for instance the “bundle.js” as a rule, this would match for every control. I shouldn’t have to take care that I’ve forgot the AutoResponder running and I accidentally get the bundle for another control.
• Should work for both Canvas and Model-Driven Apps
• No hard refresh after each change
  • Usually in Dynamics the resources are cached. In order to get the resources from local folder, we usually need to clear the cache and make a full reload. That was pretty slow on my computer, so I needed a faster solution
• Should include all kind of resources: javascript bundle, css and images, otherwise it’s not a real replacement of the debug harness.

I’ve heard of Fiddler AutoResponder before, but I didn’t really had to use it until now. In order to find the answers, I’ve researched a little, and even took a Fiddler course on pluralisght.com. You can find all the free links I’ve found at the bottom of this blog.

AutoResponder: “how to”

First we have to upload the PCF at least once in the environment and customize the control on the form/view/subgrid. We can upload the control using the “pac pcf push -pp <prefix>”. Check out to see if the page containing the PCF is loading and the PCF is shown.

1. “npm start watch”

The first step is to start the bundling in watch mode, just like in the development using the Debug Harness. We can close the Debug Harness window, which got started there. We don’t need it anymore. The VSCode Task process is still running; the bundling is still running in watch mode. Each time we make a change, the bundle.js and the other resources will be generated in the “\out\ folder in our PCF project.

2. AutoResponder Filter

Open Fiddler, select the AutoResponder tab and enable the AutoResponder by selecting “Enable rules”. Make sure to check the “Unmatched requests passthrough”, like in the screenshot below.

Then you need to type the rule by typeing the filter (1). I use expressions like this (I’ll explain later why I use this expression).

REGEX:(.*?)(\/css)?(\/|cc_)ORBIS.ColorfulOptionsetGrid.(?'path')

The only part that have to be changed is the yellow one “ORBIS.ColorfulOptionsetGrid”: the namespace and the name of the control. You can take them from your PCF manifest

The second input is the place where we can specify where the PCF files are located on the hard drive (2). It’s exactly the folder where blundle.js is located. Then add “$2\${path}” at the end.

<ProjectPath>\out\controls\<NAME>$2\${path}

Don’t forget to save (3).

Here is a summary. Given the control with the name <NAME> and namespace <NS>:

match:
REGEX:(.*?)(\/css)?(\/|cc_)<NS>.<NAME>.(?’path’)

respond with
<projectFolder>\out\controls\<NAME>$2\${path}

You can test if the expression matches the url you need to replace. For that you need to copy the url you need to test. For instance use the search on the bottom of the fiddler. Just type ? and the name of your control

“?ColorfulOptionsetGrid”

After pressing enter, the URLs of your PCF are highlighted in blue.

Now copy the URL

Now you can test it

And you get to see if the URL pattern matches (green or red)

3. Avoid caching for PCF files

We can clone the first rule, for a second one. We need the same filter:

But this time we define another rule. Open the drop-down and select *header: Header=NewName

Then change the value to

*header:Cache-Control=no-cache, no-store, must-revalidate

By doing this, we tell the browser not to cache our PCF resources. This way we won’t need to make a hard refresh after each change. The rest of the Dynamics app will be loaded from the cache. Only the PCF resources won’t be cached..

4. Refresh the page

4.1 First refresh (only the first time)

If we did everything right, we need to make a hard refresh just once (Press F12, and then right click on the refresh button, and choose “clear cache and hard reload”.

4.2 Refresh (all the next ones)

If 4.1 worked, every time we make a change in the PCF, the js will be automatically get bundled and we need just an regular “F5” to refresh the page with the new code.

My AutoResponder REGEX

Why did I took the filter above? Let’s see how the URLs of the PCF WebResources are looking like.

JS bundles

Model-Drives Apps: https://ORG_NAME.crm4.dynamics.com/%7b637310294930019857%7d/webresources/cc_ORBIS.ColorfulOptionsetGrid/bundle.js

CanvasApps:
https://docserverpaaprodweu.blob.core.windows.net/<some_id>/ORBIS.ColorfulOptionsetGrid.bundle.js?sv=2017-04-17&sr=c&sig=<some_key>&…

CSS and Images

ModelDriven URL: https://ORG_NAME&#8230;./webresources/cc_ORBIS.ColorfulOptionsetGrid/css/ColorfulOptionsetGrid.css

CanvasApps URL: https://docserverpaaprodweu.blob.core.windows.net/<id>/css/ORBIS.ColorfulOptionsetGrid.ColorfulOptionsetGrid.css?sv=…&sr=c&sig=…&se=…&sp=rl

What I shouldn’t replace

There are also some requests where the name of the control is contained. That ones I don’t want to touch. An example is this:

/api/data/v9.0/GetClientMetadata(ClientMetadataQuery=@ClientMetadataQuery)?@ClientMetadataQuery={%22MetadataType%22%3A%22resourcestring%22,%22MetadataNames%22%3A[%22CC_ReadOnlyGrid_Name%22,%22ORBIS_ColorfulOptionsetGrid%22],%22GetDefault%22%3Afalse,%22ChangedAfter%22%3A%2237467755%22,%22AppId%22%3A%223412c6e1-904f-e811-a954-000d3a38c9b5%22}&umv=37467755&mv=40047445&api-version=9.1

Mix and match

Now we have to compare with the folder structure that I have in my pcfproj Project. I just cheated a little: I have the images in the css folder, as a root for the other resources that I use.

Web Url	Project folder
Model-Driven
/cc_NS.Name/bundle.js	\bundle.js
/cc_NS.Name/css/ColorfulOptionsetGrid.css	\css\ColorfulOptionsetGrid.css
Canvas
/NS.Name.bundle.js	\bundle.js
/css/NS.Name.ColorfulOptionsetGrid.css	\css\ColorfulOptionsetGrid.css

So the regex I’m using
REGEX:(.*?)(\/css)?(\/|cc_)ORBIS.ColorfulOptionsetGrid.(?’path’)
needs to replace everything after “ORBIS.ColorfulOptionsetGrid” (NS.Name) with content generated by bundle, even if it’s in a deeper folder structure. That’s why, for replace I use ${path} (purple).

In ModelDriven the CSS is right after the name, but in Canvas Apps the “css” is before the name, so we need the dedicated part in the regex and the $2\ in the replace part of the rule definition (red).

The yellow part is what will be replaced: NS.Name.

I know I’m not working very exactly, since the “.” in the regular expression is not escaped, which means that would match also a “\” or “_”, but I didn’t wanted to make it less readable that it is already, and tried to match all the cases.

On regex101 we can see that it matches the urls, but not the one about metadata which I don’t need to match

Troubleshoot rule matching

You can check if the AutoResponder found the files, by searching the URL for the PCF and check to see if it’s highlighted with a purple background.

If the URL is highlighted, but the code is not loaded (maybe we see a 404 or 512 response), right click on the URL, and choose “Properties”.

There you can check what file the AutoResponder used, and can figure out what to change.

Organize the rules

We will of course develop more PCF components. We can let all rules be active all the time, but it’s better to have them organized. We can do that by defining groups.

• Right click on a rule, and select “Group”

This will generate a new group. As long there is only one rule in a group, you can rename it.

Then you can set this group to other rules in order to keep them together. This will help, in case you want to deactivate some rules later on.

EDIT: In the meanwhile the process in the PCF docs.

Other resources

• https://www.telerik.com/blogs/feature-highlight-fiddler-autoresponder
• Scott Durow Blog: Debugging Canvas App PCF components with Fiddler
• Natraj Yegnaraman: Easier PCF Debugging with sourcemaps and Fiddler
• Ivan Ficko at 365 Saturday, Developer Edition: “Top 10 PCF Tips & Tricks”
• Roohi Shaikh (Inogic) Blog: Debug Power Apps Component for Model Driven App
• Official Docs: Script web resource development using Fiddler AutoResponder
• A Web Developer’s Guide to Browser Caching