Debugging Scripts in an Enhanced Story

This demonstration will show you the debugging process from start to finish using one of the scenarios used in this course. After the video, you will see that we have summarized the key topics and the theory covered in the video for you.

In case you want to know which part of your code is processed or which value a variable holds, you can use the console.log(argument); command in design time. The argument can be any data type from a simple string to a complex array.

In runtime, you open the browser developer toolbar and check the Console tab. Use the filter functionality to concentrate on the Info type entries.

When your script executes, it writes the arguments to the console log.

This approach might be useful for small scenarios. However, on a larger scale, the approach becomes cumbersome – especially as you should remove unneeded console logs when going productive with your story.

To view the scripts you wrote in your story, run the story and open the web browser's development tools.

1. Select the Sources tab.
2. On the top level of the file tree, search for the entry that starts with sandbox.worker.main.
3. Under AnalyticApplication, find the folder with your story's name.
4. The executed scripts in the story are in this folder (scripts need to be run at least once to appear in the list).

The script names follow a specific scheme: <WIDGET_NAME>.<FUNCTION_NAME>.js. The scripts are grouped in a folder named <STORY_NAME>.

The elements of the scripts' names have the following meaning:

For example, if you define a script for the onInitialization event of Page_1, then the WIDGET_NAME automatically sets to Page_1.

A valid URL of a story at runtime with enabled debug mode looks like this: http://<HOST>:<PORT>/sap/fpa/ui/app.html?tenant=<TENANT_NAME>#;mode=present;view_id=appBuilding;appId=<APPLICATION_ID>&debug=true.

To show that the current displayed script is the one in debugging mode, the appendix "-dbg" is added to the script name.

In the figure below, you can see:

1. A manual breakpoint
2. The Resume Script Execution button
3. Local script variables

In debugging, you can add manual breakpoints. Follow these steps to set a breakpoint in your script:

1. Open the script you want to pause during its execution and, on the left side of the opened script in the development tools, click the line number where you want the script to pause.

   A blue marker appears that highlights the line number. This indicates that the script is paused here the next time it executes.

2. Optional: Add more breakpoints in the same script to pause the script at different points during its runtime.

To reset a breakpoint, click on the marker you want to remove. The script's execution doesn't stop at this point the next time the script runs.

In debug mode, you can use the debugger; statement in your scripts.

This statement emulates the creation of a breakpoint in your script. You need not explicitly set a breakpoint in a script that must be debugged, but the script automatically halts its execution as soon as the debugger; statement in your script is interpreted.

This lets you check at design time the points at which your script must be paused during runtime.

When the debugger pauses in a breakpoint, you find all local script variables together in the Sources tab in the Local section.

The global script variables can be added to the Console tab. You must manually type in the ones you want to see. The syntax follows the rule: this.$$.NAMEOFVARIABLE.