Debugging with Fiddler

You may use any web debugging proxy tool that you are familiar with to inspect the traffic between the client-side of an installable cloud application and PowerServer. Telerik Fiddler is one of the options. This section uses Fiddler as the example to explain the relevant techniques.

Installing Fiddler

Please install Fiddler on the computer that you plan to run and test the installable cloud app deployed from a PowerServer project.

  1. In the web browser, navigate to: https://www.telerik.com/download/fiddler

  2. Fill the form, accept the license, download and install.

Alternatively, you can download directly from here too:

https://telerik-fiddler.s3.amazonaws.com/fiddler/FiddlerSetup.exe

Configuring Fiddler

The first time you run Fiddler, make sure to enable logging for HTTPS traffic with the following steps:

  1. Click Tools > Fiddler Options > HTTPS.

  2. Click the Decrypt HTTPS Traffic box.

  3. In the popup dialog that asks you whether you trust the Fiddler Root certificate, click Yes.

By default, Fiddler does not capture and decrypt secure HTTPS traffic. To capture data sent through HTTPS, the HTTPS traffic decryption must be enabled.

For more configuration settings on Fiddler, you may refer to: https://docs.telerik.com/fiddler/.

Configuring the PowerServer project

To enable that Fiddler can successfully capture the traffic, make sure that the Web API URL setting of the PowerServer project uses the actual IP address, not "localhost".

Running the PowerServer Web APIs and then Fiddler

Be sure to run the PowerServer Web APIs before you start Fiddler (or any other Web debugging proxy tool). Otherwise, the PowerServer Web APIs will fail to start.

Reason is Fiddler (as well as any other Web debugging proxy tool) works by adding itself as a proxy instead of using your current proxy settings; therefore it will change your proxy settings on startup and reverts them back to what they were when Fiddler is closed. If the PowerServer Web APIs connect with the NuGet site and Appeon site through a proxy server, it may fail to start.

Capture HTTP(S) with Fiddler

Open up your favorite browser, and simply navigate to the URL of the installable cloud app. You'll see the requests sent to PowerServer in the section containing list of sessions, (the left pane)

After selecting one of those sessions, click on Inspectors tab, then the TextView tabs to view the request sent to the server and also the response returned from the server.

If the response body is encoded, click to decode:

Filtering the results

It is daunting task to check through hundreds of requests, therefore you may use filters to filter the results.

For example, you can:

  • Hide success (2xx) — This rule will remove all of the successful web requests. (An HTTP status code of 200 means success). Usually you do not want to have to look through all of the successes to find the missing files, content expiration intervals that are not properly set, etc.

  • Hide Image Requests — There is rarely debugging that can be done on how images are downloaded, you can hide the image requests.

Inspecting results

Based on what is reported in Fiddler, you will get what is the next step to take to debug failures in the application.

  1. Result: 502

    Result “502” means that Fiddler's request for a web page was blocked (or request delayed) by the site's web server or firewall or load balancer, causing the request to timeout. When it happens, please check whether the connection from the current computer to PowerServer can be successful or not.

  2. Result: 404

    Result “404” means that the requested item is not found. If it occurs, please check whether the file exists on the web server.

  3. Database related SqlCode and SqlErrorText

    In the TextView of the requests, if you find an error with SQLCode or SqlErrorText, it must be something wrong with the database operations. In this case, please further check the relevant code or .cs file behind the request, to see if there is something wrong with the code or the .NET DataStore model (converted from the PowerBuilder DataWindow), or the SnapObjects Runtime.

  4. Data retrieval

    You can view the composition of the DataWindow that is performing the data retrieval, and check into possible retrieval errors.

  5. Data type mappings

    Pay attention to the data types used in the deployment application or returned by PowerServer when executing SyntaxFromSQL. If the data type is different from what's specified in Data type mapping tables, you may need to make the necessary adjustments to the model .cs file, or possibly in the original SQL.