You can debug your application logic by suspending the execution at specific points in a module (called breakpoints) and proceeding with the execution step-by-step inside Service Studio, so you can find any issues in your logic design.
In the Debugger Tab you can find relevant data like variable and runtime values while the execution is suspended, as well as the current debugging context (current thread, event name, UI flow, screen and action, when applicable).
To command the debugger use the debugger commands available both in the Debugger Toolbar and in the Debugger menu.
The debugging process can be outlined in the following steps:
The user sets one or more breakpoints in the module to be debugged;
The user starts the debugger. When debugging a mobile app, Service Studio launches a special Chrome browser instance that must be used for debugging it;
The user performs one or more tasks in the module being debugged up to a point when the execution is suspended when it runs into a breakpoint;
The Service Studio window flashes on the taskbar, warning the user that the execution has stopped at a breakpoint;
When the user switches to the Service Studio window, the flow or screen containing the element with the breakpoint is displayed on the canvas;
The element with the breakpoint is selected and marked with the debug icon;
The Service Studio lower pane displays the Debugger Tab;
The execution context is displayed in the Threads Tab of the Debugger Tab marked with the current thread icon, showing the current execution stack of module elements. The rest of the Debugger Tab is filled in with debug information on module elements and runtime values;
After analyzing the runtime values at that execution point, the user can proceed with the execution in one of the following manners:
Selecting one of the commands available for advancing the execution of the application logic: Continue, Step Over, Step Into or Step Out. The execution point will advance according to the selected command behavior;
Right-clicking on an element on the canvas (or in the module tree) and selecting the Continue To Here option in the pop-up menu. The execution will continue until it reaches that element on the canvas.
Any modifications made to a module while debugging it will not take effect until the module is published again through "1-Click Publish". For any modified elements, the element version that is going to be debugged is the one that was already published, not the locally modified one.
In some scenarios you might need to debug some functionality exposed by another module (called a producer module). Learn how to it in Debugging Producer Modules.
Start the Debugger
To start the debugger, select "Debug in the Public Area" in the Debugger menu, or click on the button available in the Debugger Toolbar.
You will then be able to debug the last published version of the module. Note that by using this option you will only be able to debug threads of modules executing in the Public Area.
While developing web applications you can also debug modules in your Personal Area. This allows you to test your changes separately from other developer's changes in the same module.
Check the Public and Personal Areas topic to learn more about the differences between these two areas.
Articles in this Section
- Breakpoints are used to suspend the execution of your application while troubleshooting and debugging issues.
- Use watches to examine module elements while debugging threads in your module.
- Learn more about threads in OutSystems.
- Public and Personal Areas
- Learn more about the two areas where modules can be executed and debugged.
- Debugging Producer Modules
- Check how to debug functionality exposed by a producer module being consumed in a different module.
- Debugger Tab Reference
- UI reference for the Debugger Tab in Service Studio.