Tag Archives: Web

Squash Those Bugs – LANSA WAMs debugging techniques (Part Five of Five)

2014-10-11 22_19_01-Fiddler Web Debugger

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.

2014-10-11 22_32_54-test WAM

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.

2014-10-11 22_40_01-Fiddler Web Debugger

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.

2014-10-11 22_47_26-fiddler

 

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

2014-10-11 22_52_35-Fiddler Web Debugger

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.

2014-10-11 22_59_19-Fiddler Web Debugger

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

Squash Those Bugs – LANSA WAMs debugging techniques (Part Four of Five)

LANSA WAM Debugging

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part four 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. This installment helps you answer the question “Is my server code correct?”

Is my server code correct?

When working on web pages, to make sites as interactive as possible, you will often need code in at least two places. The server, which in this case would be the LANSA application server running on an iSeries or Windows box, and the client would be a miriad of browser types running HTML and JavaScript. The mixture of HTML (for presentation) and JavaScript (for interactivity) is a very strong match. It gives web applications the power and functionality that is often attributed to windows GUI applications.

RDMLX is the LANSA language that runs on the server. It is originally designed on BASIC structures and over the years has evolved into a very mature language that rivals all the big names like C++, Java, Etc. It is reasonably easy to pick up and be productive quickly, and can be ported to different platforms if required. When running LANSA WAMs websites, RDMLX is the code which is running on the server side. Development of the RDMLX code is done in a modern Visual IDE. This IDE has some great debugging features. The IDE is a window rich client application which runs on the developer’s PC, and allows the developer to “check-out” code from the server, to work on that code, and then to send it back to the server to run. Another great feature of this IDE, is the ability to debug code running on the server. This is the feature that we will explore in this article.

Architecture and Flow

architecture

  1. The debugging process starts at the Browser. A URL is called which tells the server which WAM to run, to run it in debug mode, and where the IDE is that will do the debugging.
  2. The server contacts the IDE, to have a 2 way conversation, passing back and forth the variables and the line which the server is currently executing
  3. Using the IDE, you can set breakpoints, change variables, and step through the code to observe your application behavior.
  4. Once the program has completed it’s tasks, the server sends the resulting HTML page back to the browser.
  • All code actually runs on server
  • All database IO occurs on server

Setup Steps

Some developers do not use this great capability because of the setup steps involved and possible complications. However, once you know what to check, setting up a debug session is a snap. Here are the steps that I always go through….the first time running a debug in a specific environment.

  1. Your WAM needs to be checked-in/compiled with Debug turned on. Shown below is the check-in dialog box.
    checkin
  2. Check the current IP address of your development PC. The IBM I will use this IP address to contact the IDE to do the debugging. The IPCONFIG command can be typed into a dos window. Keep in mind that if you are on a VPN..you will need to be using the IP address from your VPN connection. You should be able to ping your PC from the IBM I.
    ipconfig
  3. Ensure that the debug setting inside the IDE are setup correctly, and on a port which the IBM I can use to connect to the developer PC. This dialog can be found in the IDE menu options/settings/debug.
    -If the debug does not work, you need to make sure that there are no firewalls between the IBM I and the developer PC that may be blocking port 51234 (default)….This includes the windows firewall.
    -When you first start, make sure that the “Break at first executable statement” checkbox is checked (this is to prevent confusion if the debug session never passes your breakpoints). As you get more advanced, you may start running debug from a different point.
    debugdialog
  4. The LANSA Server environment needs to be told that debug can be run. This should only be done only for the development environment. You can leave debug disabled for production. This setup step can be done in the LANSA Web Administrator tool which was used to setup your web environment. In this tool, you go to menu tools/configure systems/data-application server. Under the miscellaneous tab, you need to check the “Allow interactive debugging” checkbox.
    allowinteractive
  5. Setup your breakpoints. These are point which will stop a debug so you can step from that point and inspect variable. Breakpoints can be set by putting the cursor on a line and pressing F9. Breakpoints show as a line highlighted in red.
    setupbreakpoint

Doing the Debug

Now that your environment is setup, you can step through the server side code of any WAM application. To start a debug, your WAM has to be compiled (with debug on) and checked-in to the server. Then you go to the design tab on your IDE, and press the magnifying glass.
magnify
If the setup is correct, you should get a debug session loaded in your IDE. You should be able to step through your code using F8 (step into). You can also use F5 to run until the code encounters a breakpoint. Inside the IDE, the yellow lines indicate what line in your program is about to be run, and variable values can be inspected on the left of the interface. Variable can also be changed…for testing purposes.

StepDebug2

Remember to recompile your WAM with debug turned off once you have completed your work. Debug adds about 40% to the size of the code, and will likely make the code run slower.

This type of debugging can be a huge time saver when finding those nasty hard to find bugs. It allows the developer to notice any piece of code where the logic goes in the wrong direction, where unexpected values come out of files, or some typo causes your application to go down in flames. This is a tool which every Web developer should have in their arsenal.

In my next and final blog posts on this topic, I will be highlighting another tool and techniques to help answer the following questions:

  • Am I passing the correct information between LANSA and the web page?

Andy

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

Squash Those Bugs – LANSA WAMs debugging techniques (Part Three of Five)

Squash those bugs

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part three 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. This installment helps you answer the question “Are my values stored in JavaScript correctly?”

Are my values stored in JavaScript correctly?

When working on web pages, to make sites as interactive as possible, you will often need code in at least two places. The server, which in this case would be the LANSA application server running on an iSeries or Windows box, and the client would be a miriad of browser types running HTML and JavaScript. The mixture of HTML (for presentation) and JavaScript (for interactivity) is a very strong match. It gives web applications the power and functionality that is often attributed to windows GUI applications.

JavaScript is a very power language, but often the code can get quite complex (depending on the business requirements) and debugging can be difficult. As always when debugging difficult JavaScript, I turn to some of my time tested trusty tools. Firefox, jQuery, and Firebug. These tools allow me to step through the code and review the state of element values and change them if necessary.

In the first couple of installments we looked at inspecting objects and stepping through code. What we are looking at this time will be values stored in variables elements.

Steps

The first priority is to make sure that all fields (or at least the ones in question) have a “Handle” that you can use to interrogate it’s value. HTML allows a developer to attach these handles in the form of ID and Class parameters. Classes allow accessing multiple elements at the same time and are heavily used for presentation by Cascading Style Sheets. What we are interested in here are ID’s. LANSA automatically assigns an ID to every element that needs to carry data back to the server. However, if you manually add HTML in the IDE, I recommend that you add an ID tag to input/checkbox/radio/dropdowns, etc.

For fields in tables, the format that LANSA uses is <LISTNAME>.<ROWNUMBER>.<FIELDNAME> E.g. LSSKILLS.0001.SKILLDESC


<input id="LSSKILLS.0001.SKILLDESC" class="utext" value="RDMLX" name="LSSKILLS.0001.SKILLDESC" size="60" maxlength="80" onchange="return isValidText(this, ' ')">

For single fields, the default ID is the field name. E.g. STD_DESC


<input id="STD_DESC" class="text" value="" name="STD_DESC" size="30" maxlength="30" onchange="return isValidText(this, ' ')">

The next step is to ensure that you have included Jquery as part of your includes in your HTML HEAD tag. Here is an example;

<script charset="iso-8859-1" type="text/javascript" src="/images/jquery/1.7.2/jquery.min.js">

The final step is to load your page into the browser and start Firebug Console mode. Inside this console you can use jQuery syntax to interrogate your fields. See image below.
Squash Those Bugs

Tips

  • The jQuery syntax for displaying the value of an input field in the console is $(“#NAME”); Where NAME is the value inside the element id.
  • All jQuery commands can be run inside the console. Refer to jquery.com for more command syntax
  • When dealing with List Fields, there will be periods in the ID. E.g. LSSKILLS.0001.SKILLDESC. These periods will need to be escaped with a double backslash. E.g. LSSKILLS\\.0001\\.SKILLDESC
  • Firebug can you used to set breakpoints so that you can stop the code at a certain point to interrogate these fields, or you can step through the JavaScript as it’s being performed.

In my next two Blog posts I will be highlighting a number of tools and techniques to help answer the following questions:

  • Is my server code correct?
  • Am I passing the correct information between LANSA and the web page?

Andy

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

Squash Those Bugs – LANSA WAMs debugging techniques (Part Two of Five)

javascriptDebugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part two 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. This installment helps you answer the question “Is my client code correct”.

Is my client code correct?

Often when building a web application, your LANSA code is just part of the picture. Many times JavaScript is used as a client side language to augment and make your HTML more interactive. JavaScript can allow the web page to react to the users mouse movements, it can real-time reach out to the server for more information without submitting back the full page (AJAX). It can even move objects around the screen and fade elements in and out. The problem is that JavaScript can be tricky to debug. I highly recommend using the jQuery framework when doing any JavaScript development as it simplifies the syntax, and the procedures.
There are a few techniques which I use to determine if my code is correct:

Display key data using dialog boxes

Ahhh…the humble alert(). JavaScript is shipped with a command to display a simple text message in a dialog box on the screen. This command can be placed anywhere inside your JavaScript code and as the JS interpreter is stepping through the JS code, if it hits your alert(), it will popup a message. This is flawless and works in every browser. It’s the fallback if other methods do not work. I use it to a) show what pieces of code are executed, and b) what data is held in my variables at that time.

The example below demonstrates the simplicity of showing the traveled program path and the values at each stage.

var myField = 'abcdef';

alert('hello world');

alert('start of program - value:' + myField);

if (myField == 'qqqq') {
alert('inside first if statement - value:' + myField);
}

myField = myField + 'x';
alert('after first if statement - value:' + myField);

alert
Tip: Be careful to remember to remove all these alerts() from your code before promoting to production, or you may get a surprise or two. :)

Console logging

If you are using Firefox (with Firebug) or another browser that supports console logging, then you need to experiment with this feature. It is far superior to the alert() command as it doesn’t stop the program flow, It doesn’t impact the blur and focus events of your elements, and it supports logging of hyperlinks, multiple arguments, printf strings, color coding, types of messages (debug/info/warn/error) and more. You can find more information here.

Merely insert the command console.log(‘My message here’); into various places in your JS code, and it the messages will output to the console window in firebug, as the JavaScript code is running.

The example below demonstrates the use of console logging.
consolehtmlconsoleoutput

Simplify and externalize

When you are working with hundreds of lines of complicated JavaScript code, and are having difficulty figuring out a bug, it is often best to reduce the issue to a simple case and test it inside a workbench designed for the task. JSfiddle is a website which offers this type of workbench. It has areas to paste in your HTML, JavaScript and CSS and then it will show the results in an output window. It’s an awesome quick way of isolating your small code snippets and making sure that the syntax works correctly. You do not have to save anything to the server, it just works right there in the browser. I used this technique recently to debug timing events inside JavaScript and realized that the firing order of the keypress event will not give you the full contents of the cell which fired the event. This issue stumped me for quite a while, until I did some tests inside JSfiddle. Now I use the keyup event instead. Here is the fiddle that I ended up with. http://jsfiddle.net/4Mekq/3/

jsfiddle

Step through the code

Of course there are time where you just need to step through the JavaScript code line by line. I almost always use Firebug for this also. For the most part, when I get the JavaScript code running in Firebug, it will work in the other browsers that I test.

In Firebug, 1) Click on the Script tab. This will show all your JS that your web page accesses (even external JS). 2) Click in the left margin where you want to set breakpoints. 3) You can step through or run-to-breakpoint your JS code as you are testing your web page. 4) On the right side (in the Watch tab), you can setup variables that you want to keep an eye on as you step through the code, or you can simply interrogate the webpage object heirarchy.

firebugdebug

Some additional tips:

  • Be aware of the timing of Javascript events. They are not always as obvious as they seem. A simple event firing in an unexpected order can mean hours of debugging on your part.
  • ***My Opinion only*** Don’t use the keypress event when retrieving the value of the field which is triggering the event (it doesn’t get full field with the new key) or blur (this gets the wrong field). Instead, use the keyup event.

In my next three Blog posts I will be highlighting a number of tools and techniques to help answer the following questions:

  • Are my values stored in JavaScript correctly?
  • Is my server code correct?
  • Am I passing the correct information between LANSA and the web page?

Andy

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

Squash Those Bugs – LANSA WAMs debugging techniques (Part One of Five)

Debugging LANSA WAMs
Debugging LANSA WAMs

Many Layers

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. A web application encompasses multiple environments (E.g. server language, TCP connectivity, HTML, JavaScript, jQuery, etc.) and each one may require a different skill-set to deal with. This compounds the possibilities of errors. To make matters worse, browser standards have always differed from one browser to the next.

The LANSA language goes a long way towards simplifying the different layers but there are still times where some bug has ended up in your application and needs to be found and eradicated. Over the years of developing LANSA web sites, I have found that there are some tools and techniques which are invaluable to finding and squashing those bugs.

Break it down

I find that the easiest way to find and remove those bugs in LANSA WAM applications is to break down the areas of focus into five areas. Ask yourself these five questions.
1) Are my client side objects what I think they are?
2) Is my client code correct?
3) Are my values stored in JavaScript correctly?
4) Is my server code correct?
5) Am I passing the correct information between LANSA and the web page?

These questions are not in any particular order, just start with the one which you think is most likely the area which is malfunctioning. Often you will know right away which one is most likely causing you issues. Answering each of these questions requires a different approach.

Are my client side objects what I think they are?

When working with web applications, we often have to reference elements inside of your HTML document. E.g. you may need to grab a value from a TD element in a table or a value from an input field. However, one of the more difficult tasks is knowing that your Javascript/jQuery is referencing the correct object. If you are not already using jQuery to do your Javascript work, you have to start now! It tremendously simplifies your Javascript coding and makes your client side code very powerful. There are other Javascript frameworks around, but this is the one that I am most familiar with. Always try to reference your target fields via ID or Classes. This makes your jQuery code simpler. You can find information about jQuery here.
The tool of choice for me here is Firebug. If you are building a public website, you should be testing for multiple browsers. Likely Firefox will be one of those browsers. Firebug is a plugin for firefox, and makes interrogation of webpage elements and Javascript much easier. You can find information about Firebug here.
Start up Firefox and click on the firebug logo in the top right toolbar and select “On for All Web Pages”
Debugging with firebugNow load up your page and you should see a firebug panel at the bottom of your page. You can right-click on any element on your page and select “Inspect Element with Firebug” to review the HTML. It also allows you to review the JavaScript and will show any JavaScript error on the Console panel.
Our objective in this step is to ensure that your JavaScript is referencing to correct objects in your web page. E.g. you are not getting the output that you expect, and you think that your object is not being populated properly. 1) Click on the Console tab. This will allow you to see any JavaScript errors and your output from the next steps. 2) Type in a string that allows you to view your object. This is where the magic happens….when you are building your site, assign as many ID’s as you can to your HTML objects E.g. button’s and fields. If you cannot assign an ID, at least attach a class and make sure that it’s unique on the page (the exception is for repeating table entries). Once these objects have ID’s or Classes, you can reference them using the jQuery selectors. Type in the jQuery syntax (E.g. $(‘.myClass’) for a class or $(‘#myID’) for an ID) to select an object, and then you can use other jQuery commands on this object to make sure that the element that you are looking for in your web site code is the correct one. My example below shows the “Type” attribute on a button that has the class of “submit_button”, but I could have just as easily shown the value of a hidden text element. 3) Press the Run button, your output will be shown in the lower left window.
Use this technique to make sure that your onClick handler is attached to the right button, or that your handler is pulling the desired data from the right field, Etc.

Debugging with firebug

Some additional Tips:

  • You can use .parent(), .children(), .next(), .prev() to navigate around the HTML document….this is very useful in a table. E.g. $(‘input#name’).parent().next().html()
  • Straight Javascript code can be used and run in the bottom right window. This can be used to interrogate an array or any type of Javascript object.

In my next four Blog posts I will be highlighting a number of tools and techniques to help answer the following questions:

  • Is my client code correct?
  • Are my values stored in JavaScript correctly?
  • Is my server code correct?
  • Am I passing the correct information between LANSA and the web page?

Andy

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