Debugging Scripts
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.
Writing to the Console
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.
Debugging Scripts in Your Web Browser's Development Tools
To view the scripts you wrote in your story, run the story and open the web browser's development tools.
- Select the Sources tab.
- On the top level of the file tree, search for the entry that starts with sandbox.worker.main.
- Under AnalyticApplication, find the folder with your story's name.
- 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:
| Key | Description |
|---|---|
| STORY_NAME | The name that you set for your story when you saved it |
| WIDGET_NAME | The name of the widget or element in your story |
| FUNCTION_NAME | The name of the function or event handler that holds the script you wrote |
For example, if you define a script for the onInitialization event of Page_1, then the WIDGET_NAME automatically sets to Page_1.
URL for Debug Mode
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.
Note
If the debug parameter receives a different value to true or no value at all, it's ignored and the debug mode isn't enabled.Script in Debug Mode
To show that the current displayed script is the one in debugging mode, the appendix "-dbg" is added to the script name.
Debugging Mode Options
In the figure below, you can see:
- A manual breakpoint
- The Resume Script Execution button
- Local script variables
Breakpoints
In debugging, you can add manual breakpoints. Follow these steps to set a breakpoint in your script:
- 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.
- 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.
Using debugger;
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.
Where to Find Script Variable Values
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.
