Debugging
Find out what's going on in Runtime
Last updated
Find out what's going on in Runtime
Last updated
WEM offers some debugging features that are helpful in finding out what a situation in the Runtime is, while you are working in the Modeler. The underlying technology is using Comet channels to exchange information between Modeler and the Runtime about the current Node and the current values in the Session.
The principal use is debugging while in Preview - when you start a Preview Session from the Modeler, the Debugging Pane is automatically started and the comet-channels get connected. It is also possible to start a debugging session with Staging or Live, to enable you to check what happens and what values are available in these Runtimes.
A debugging session can be started for Preview Runtime, Staging Runtime or Live Runtime.
Any Preview Session always automatically starts with a Debugging Session, and you start this either by clicking the [> Preview] button in the Modeler top-menu, to start the Preview Session from the Homepage (starting point for the portal) , or the [> Preview] button in a specific Flowchart to start a Preview Session from that specific flowchart directly.
To start a debugging session for Staging or Live, you need to go to the Project Information Tab and specifically click on the icon in front of the URL.
When a Debugging Session is started, the Debugging Pane is visible at the bottom of the Modeler page. In its title it shows Debugging: [which environment]. You can start a preview and then a staging and then a live debugging session, but only the last started session will be actively connected for the debugging features!
Breakpoints can be used in debug sessions to temporarily stop an application's flow to investigate the situation on that specific point. Breakpoints are "personal": they are linked to the Modeler User that places the breakpoints, and they will only get triggered when that Modeler User starts a Debug Session. For all other users these breakpoints do not exist and will not stop their Runtime Session (not even for other Modeler Users in the same project).
In flowcharts you can add a breakpoint to any node. To set a breakpoint, just select one or more nodes in your flow, and click on the Breakpoint button in the Flowchart Toolbar.
Nodes with a breakpoint get this little red dot in the top-right corner of the node. When a breakpoint is set to a specific node, you can add a condition for when this breakpoint should indeed stop the flow. Click on that little red dot to activate the Breakpoint Condition overlay and put in an expression that will be evaluated when the node is reached in runtime.
When a breakpoint is reached in the Runtime, you'll see a message on top like the image.
If you click on the message, the application will continue. If at this point you switch to the Modeler Tab in your browser, you can click on the [Goto current node] button in the toolbar of the Debugging Pane. This will open the flow and put the specific node into focus. The Debugging Pane also allows to [>Continue] the flow in the Runtime (until the next breakpoint is reached).
If Goto Current Node does not work, or does not seem to bring you to the correct node - it is because the node information is not properly exchanged over the Comet channel, which may indicate that the connection between debugging runtime session and modeler session is no longer in sync. You can still continue with both sessions, but it is recommended to close the debugging runtime session and start a new session from the Modeler.
With the expressions in the Debugging Pane, you can actually find out what certain values are in the Debugging Session. See the examples in the image, where IsPreview() yields yes (because it is running in a Preview session), the count on a list is 0, a setting value is displayed and the children of a Concept is displayed. The values displayed are retrieved from the Runtime Session being debugged.
The 3-dots at the end of each line gives you the option to remove the expression line, or to copy the value it yields to your clipboard.
This way you can see at certain points what the values in Runtime are, to help you understand certain situations (when the application seems to react different as expected).
