Using Visual Debug

Generate, Deploy & Test with WebRatio Platform
382 views Published on May 22, 2014 | Time 28 min
Applies to: 7.2 or higher

Debugging is a fundamental tool for developing a reliable Web application. In the standard debugging approach, every time a problem arises or whenever you want to investigate the behavior of your application, you can easily debug it by placing breakpoints in your lines of code. Debugging with WebRatio Platform is simple! Suppose you are modeling an operation chain inside an action but, instead of the operation completing successfully, an error is thrown for no apparent reason. As you would do with standard code debug, you can activate WebRatio Platform's visual debug by placing a breakpoint over the Action instance in the Site View (or any other model element). By doing this, you can stop and inspect the natural execution of the application to check parameter propagation, and maybe find out that a parameter was missing.

Transcript

Table of contents

Debugging with WR Debug

In order to Visually Debug a Web application, we first need to go through a few preparatory steps. To start with, we need to properly configure the Web Server hosting the application. Then we need to create a debug configuration in WebRatio Platform. Finally, we must add breakpoints to the Web Model wherever needed. When the Debug Configuration is executed, WebRatio Platform connects to the Web Server and, when a breakpoint is met, the visual debug stops the execution at the breakpoint, enabling step-by-step execution and parameter inspection.

Step 1 - Configuring a Web Server for debugging

The version of Tomcat installed in bundle with WebRatio Platform is already configured for Visual Debug. However, any Web Server that publishes Web applications developed with WebRatio Platform can provide support for debugging. This is done by ensuring that the shown Java system property is added to the JVM command line used to start the Web Server. For instance, the Tomcat Web Server can be configured by adding a line at the beginning of the catalina scripts that can be found in the "bin" folder under the Tomcat installation. The boxes show the line to add, depending on your operating system. It's important to note that for performance and security reasons Web Servers used in production must not be used for visual debug.

Step 2 - Create a Debug Configuration

A Debug Configuration is an element that allows WebRatio Platform to connect to a Web Server for Web Application debugging.

To create a Debug Configuration, you need to click on Run -> Debug Configurations from WebRatio Platform's menu. In the opened dialog, select "Web Application" in the left-hand list of launch configuration types, and press the "New launch configuration" button in the toolbar. This will create a new debug configuration for a Web application.

The control panel on the right-hand side allows you to control specific aspects of the debug. In the "Project" field, select the Web Project to debug. The specific properties you can set include "Host", "Port", "Application Name", and "Debug Port" of your Web application. If the "Use Custom Connection Properties" checkbox is not selected, default values will be used for these settings. If you want to enforce specific values that differ from the default ones, you should select the checkbox so as to specify custom values.

In particular, in the "Host" field, type the "IP Address" or "Domain Name" of the Host where the Web application is running. If the program is running on the same machine as the WebRatio Platform IDE, type localhost. In the "Port" field, type the port where the Web Server is accepting HTTP connections. Generally this port is specified in the configuration file of the Web Server (such as the server.xml file in Tomcat).

In the "Application Name" field, type the context path under which the Web application is deployed. If that field is empty, the context path is extracted from the "Output Path" property of the selected Web Project.

In the "Debug Port" field, type a specific port number to be used for sending and receiving debug information. If that field is empty, a random port will be used. Note that the abovementioned "HTTP Port" and the "Debug Port" are not the same: the former is used to establish the very first connection whereas the latter is used throughout the entire debug session.

Step 3 - Define Breakpoints

A Breakpoint suspends the execution of a Web application at the location where the breakpoint is set.

To add a breakpoint, simply right-click on the model element where you want to add the breakpoint, select Breakpoints and then one of the available breakpoint types. A new Breakpoint marker appears on the left boundary of the element where you added the breakpoint.

You can enable and disable breakpoints via the context menu in the Breakpoints View. An enabled breakpoint causes a thread to suspend whenever the breakpoint is encountered. A disabled breakpoint will not cause threads to suspend. Disabled breakpoints are drawn with a white circle.

To enable and disable breakpoints, open the Debug perspective. Breakpoints are displayed in the left boundary of model elements and in the Breakpoints view, visible in the Debug perspective. To disable a breakpoint in the Breakpoints View, open the breakpoint's context menu and select "Disable", or deselect the breakpoint's checkbox. The breakpoint image will change to a white circle (gray on the model element) and its checkbox will be empty. To re-enable the breakpoint in the Breakpoints View, open the breakpoint's context menu and select "Enable", or select the breakpoint's checkbox. The breakpoint image will change back to a green circle, and its checkbox will be checked.

To remove a breakpoint, simply double-click on it. You can also remove breakpoints in the Breakpoints View. Select the breakpoint(s) to be removed and, from the context menu, select "Remove". All breakpoints can be removed from the workbench using the "Remove All" action in the context menu of the Breakpoints View.

Step 4 - Debugging

Once the Web Server, Debug Configuration, and breakpoints in the Web Model are correctly configured, you can debug the Web application. As soon as the action is triggered, the navigation stops, thereby activating the debug in WebRatio Platform.

We can now control the execution of the Web application step by step.

With the "Step Into" button, the next expression on the currently selected step to be executed is invoked, and execution suspends at the next inner executable step. In this case, since we stopped at an action, the next inner executable step regards the action definition.

With the "Step Over" button in the View Toolbar, the currently selected step is executed and suspends on the next executable step. In this case, the execution was suspended on the "Begin of Execution" breakpoint of the action, so the next executable step is the "End of Execution" of the action.

If we want to step out of the inner execution, we just hit the "Step Return" button, and execution resumes until the next external step is reached. In this case, since we stepped into the action definition, with one click on "Step Return" we will first step back to the end part of the execution of the action definition. A second click on "Step Return" will take us to the end part of the action in the site view.

"Step Into" and "Step Return" are very useful for inspecting the inner execution of actions and modules.

How to Debug an Action Execution

Let's debug the execution of an action. Right-click on the action in the site view and select "Breakpoints" -> "Begin of Execution". You should choose "End of Execution" if you only need to check the result of the execution right after the execution of the action.

Now launch the Debug Configuration.

With the "Step Into" button, the next inner executable step regards the action definition. At this point, clicking once more on the "Step Into" button will move the debugger to the Input Port within the action definition.

In addition, you can also check the input and output parameters of every single element. Let us now step over to the next executable step. Now the component results have been populated with values that we can easily inspect by expanding the tree structure available in the "Variables View". If you need to, you can also change the values of the parameters and check the result.

If we want to step out of the inner execution, we just hit the "Step Return" button, and execution resumes until the next external step is reached. In this case, since we stepped into the action definition, with one click on "Step Return" we will first step back to the end part of the execution of the action definition. A second click on "Step Return" will take us to the end part of the action in the site view.

How to Debug an Action Definition Execution

Let's now Debug the execution of an action definition. Right-click on the input port to set a breakpoint. Let us now Debug the Application. Just enter a new company in the browser to trigger the action.

The execution stops at the Breakpoint.

We are at the "Begin Execution" part of the input port. Let’s now step over the next execution point. This will take us to the "End Execution" part of the Input Port. We can easily walk through the execution of the entire Action by stepping over all the execution steps. For each step, we will first traverse its "Begin" part, and then its "End" part. The next step is to check the OK Flow going to "Is Not Null" control flow operation, which is used to transmit the bound parameter. After that, we are traversing the Data Flow to the "Create Company" operation, then the Data Flow to the "Modify Company" operation, also used to transmit their bound parameters. After these steps, the OK Flow is actually traversed to the "Is Not Null" control flow operation, and the outgoing KO Flow is taken, since the "Result Code" of the is-not-null test is an error. This takes us to the "Create Company" operation, which succeeds, following the corresponding OK Flow to the OK Port.