Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is the final part in a five part series of blog posts that will be highlighting a number of tools and techniques that will help you squash those bugs. If you missed part one, it can be found here. Part two can be found here. Part three can be found here. Part four can be found here. This installment helps you answer the question “Am I passing the correct information back to LANSA?”

As stated on previous articles, there are multiple possible failure points when developing a client server application for the web. We have looked at debugging on the client side (browser), the server side (AS400 or Windows) and we have looked at how browser scripting plays into the equation. There is one final piece of the puzzle which may help if you get into a real difficult situation and need to pull out the big guns. Sometimes you need to analyze the traffic that is flowing between your browser, and the LANSA server.

Introducing Fiddler

Fiddler is one such tool which will allow the developer to view data being sent to the browser and their responses. The tool has many other features and can even allow you to “tweak” the data for testing purposes. It can also show cookies, and headers (which, at times, are both used to transfer data between the browser and the server).

Over the last 15 years, on a number of occasions, I had to reach out to LANSA support to assist with a web development issue, due to some unexpected system behavior. Many of those times, the first thing that support did was load up fiddler and inspect the data movements. It is a very powerful tool!

Fiddler gets installed on the developer’s workstation, and works like a proxy server. it intercepts all traffic initiated by the browser, and forwards it to the server. It also intercepts the responses, and documents the data for you to inspect, and verify.

Sometimes the problem with your application may be as simple as the date coming back is in the wrong format, or a text value coming into your JavaScript is left aligned, when you expected it to be right aligned. Fiddler will come in useful during those type of issues to verify the accuracy of your data.

Firewall issues can also be detected using the fiddler tool as it documents the time it takes for a transaction and it shows the status of the HTTP request.

Make Your Request

Once fiddler is installed, it needs to be running so that it can intercept all browser traffic. Then load your web page using the browser, and step through until you get to your code in question.

As can be seen in the example above, there is data entered and transferred to/from the server.

Breezing Through Traffic

Switch over the Fiddler, to view the transfers.

Fiddler is broken up into 3 sections. The left panel has one entry per HTTP request. You can select which entry you want to inspect here. The top-right panel shows a ton of information about the outbound request from your browser, it shows cookies, headers, form data, URL, etc. The bottom-right panel shows a ton of information about the inbound response including cookies, headers, form data, URL, etc.

Outbound Request

Clicking on the transfer on the top-left, we can then look at that specific transfer. We then look at the top-right panel (shown below). This has a number of tabs. When we click on the headers tab, it shows the URL used (which sometimes has data appended to it), and additional headers and cookies.

 

When we click on the webforms tab (shown below), it shows all the field data being sent to the server.

There are all kinds of data which can be analyzed on the outbound transaction. It even has tabs for properly formatting JSON and XML request.

Inbound Response

When we change our focus to the bottom-right panel, we are looking at the data coming back from the server to the browser (if any). Again it logs, headers, cookies, inbound HTML Etc. If we select the “Textview” tab (shown below), we can find our fields and the data passed by searching for them in the searchbox on the bottom of the page.

Using the techniques shown above the developer can review the data being passed in either direction, and determine if the data integrity is contributing to how well the application is working.

This tool can also be used to help diagnose network based Performance issues as it shows the http response codes. It shows how long it takes for the responses to get back. It shows additional http requests which may have been spawned by the original one to do things like retrieving images. It even has a statistics tab which will estimate response times to other parts of the world.

I encourage you to install the tool, and play around with it. It can give tremendous insight to a developer who needs to verify or validate the integrity of their data as it arrives at the client or the server.

This concludes the series on effectively debugging LANSA WAMs applications. Most times, debugging will not require all the tools that were laid out in these blog postings, but with these tools as part of your debugging arsenal, I would put forth that there are few bugs which will out of your grasp to seek and destroy.

Happy Hunting!

Andy

LinkedIn
https://plus.google.com/+AndyBain
@jandybain