While Running an eSpace, you are allowed to debug requests by suspending their execution at specific points in the eSpace, and proceeding with the execution, step by step inside Service Studio, so you can determine the location of any semantic errors. While the execution is suspended you can examine eSpace elements and runtime values such as, web screens and flows of actions or processes, and runtime values of variables, parameters, widgets, process activities, etc.

Starting the Debugger

Service Studio starts the Debugger in the following situations:

Learn more on how to Debug in Public and Personal Areas.

You may also debug in scenarios where eSpaces reuse functionality from each others's.

Learn more on how to Debug Reused eSpaces.

Suspending Requests Execution

To suspend the execution of a request at a specific point in the eSpace you must add a Breakpoint to the eSpace element placed at that point. Then Run the eSpace in your browser, navigate to get to the breakpoint, and the execution will be automatically suspended for you:

    1. The focus of your Windows environment goes back to Service Studio;

    2. The flow or screen containing the element with the breakpoint is displayed on the canvas;

    3. The element with the breakpoint is selected and marked with the debug icon;

    4. The Debugger Tab is showed up in Service Studio's Lower Pane;

    5. The suspended request is displayed in the Requests Tab of the Debugger Tab marked with the debug icon.

Requests are also suspended from execution on exceptions whenever the option to Break On All Errors is set - even if no breakpoints exist in the eSpace.

Suspending All Requests Execution

Use the Suspend Current Requests option in the Debug Menu to suspend all your executing requests; an entry is created for each one of them in the Requests Tab. This option may be useful if, for example, you feel that requests are taking longer than you expected and something might be wrong.

This option may not work instantaneously if what is currently being executed is not controlled by the OutSystems Platform, such as a Web Service or a Query. In the latter situation, the query has to reach its end for the request to be suspended.

Debugging Session

In the Debugger Tab you will find a full debug environment to track debugging requests, and to examine eSpace elements and runtime values. There you may analyze your eSpace logic and evaluate variables at will while the execution is suspended. To command the Debugger use the debugger commands available both in the Debugger Toolbar and in the Debug Menu.

Debugging in Public and Personal Areas

When you Run an eSpace, it starts the Debugger and attaches it to both your Personal Area and Public Area. This means that, from the moment you Run your eSpace, you can debug requests executing both in your Personal Area or in the Public Area. Learn more about how to Execute the eSpace.

You are allowed to start de Debugger without having to Run an eSpace. For that, go to the Debugger menu and explicitly select the option to Debug in the Public Area. However, using this option the Debugger will only be attached to the Public Area meaning that, you'll only be able to debug requests of eSpaces executing in the Public Area.

Debugging Multiple Requests in a Debug Session

It is possible for you to have more than one request being debugged at the same time in your eSpace. This is due to the fact that the Debugger is able to suspend from execution all of your incoming requests. Moreover, when debugging requests in the Public Area, the Debugger may also suspend from execution some kind requests generated by other users (see next section). Learn more about Debugging Requests.

You may examine all your requests in the Requests Tab, and the other users' requests in the Users Tab. Both of these tabs are located on the Debugger Tab.

Requests Isolation

The Debugger behaves differently when suspending requests at breakpoints, and it depends on the request kind:

Browser Requests: these requests are originated by some action taken by you on a Web Screen in a browser running in your machine (where you are also using Service Studio to debug the eSpace). These requests are isolated and suspended only at your breakpoints. The same happens for all other users in their machines.

Other Requests: requests like the ones executing Process flows, Timer actions, or Web Services methods, are suspended from execution whenever they run into a breakpoint of a Debug Session started in the Public Area, either yours or of any other user, because they're not isolated. This means that, in this case, you might be debugging not only your requests, but also requests from other users and vice-versa. To overcome this situation you should check in the Users Tab if there are other users debugging the eSpace. If that's the case, each suspended request should have its eSpace elements and runtime values examined by you (in the Scope Tabs) to check whether the suspended request is yours.

See Also

Debugger Tab | Debugger Toolbar | About Requests | About Breakpoints | Analyzing the Scope Tabs | About Watches | Run the eSpace | Execute the eSpace