Run and debug workflows in Studio

Run a workflow on your machine, set breakpoints, step through activities, inspect values and read the run logs.

Studio runs and debugs workflows on your machine with the same Workflow Executor that runs them on a Robot. Breakpoints pause the real run, and the debugging panels read values from the paused activity. Prerequisites# Studio installed with the Developer profile of VeloPhex Setup. Runs from Studio go through the VeloPhex Robot on your machine; without it, Studio reports VeloPhex Robot is not installed. See Install Studio. The workflow validates without errors (F8). Errors in the Error List stop a run. Run a workflow# Command Shortcut What it starts Run project Ctrl + F5 The project's main workflow, without debugging Debug project F5 The project's main workflow, with breakpoints Run file Ctrl + F6 The open workflow, without debugging Debug file F6 The open workflow, with breakpoints Open the workflow, or rely on the project's main workflow. Press the shortcut, or use the run button on the Design ribbon tab. Its main half runs the project's default action (Debug file unless you change it in Project settings > Run and debug > Default action); its menu has all four commands. If you have unsaved changes, select Save and run. Runs always use the saved files. If the workflow has In or In/Out arguments, the Run dialog asks for their values. Select Use default to keep an argument's default, then select Run. Studio remembers the values for the rest of the session. Watch Output. The Run channel shows the log lines of the run. To stop, press Stop (F12); the run button also turns into Stop while a run is active. Request stop asks the workflow to end on its own (its Should Stop activity returns true). Force terminate ends the Workflow Executor at once if Stop takes too long. NoteThe first time you use Run file or Debug file on a workflow that is not an entry point, Studio adds it to the entry points in project.json. Set breakpoints# Select an activity on the canvas. Press F9, or select Toggle breakpoint on the Debug ribbon tab. In a Sequence you can also click the gutter next to the activity. To add a condition or a hit count, press Alt + F9 (Breakpoint settings…): Condition: a C# expression; the run pauses only when it is true. Hit count: a whole number. The run pauses once the activity has been reached that many times, and on every hit after that. Leave it empty to pause on every hit. Enabled: turn the breakpoint off without deleting it. Select OK. The Breakpoints panel lists every breakpoint with its activity, file, condition and hit count. You can edit them in the grid, double-click a row to go to the activity, and use the toolbar to enable, disable or delete them all. Breakpoints are saved per user in .velophex/user/breakpoints.json, so they never reach source control or a package. Breakpoints inside a workflow called by Invoke Workflow pause the run too. NoteThe Log message field of a breakpoint is saved, but the breakpoint does not write it to Output yet; it pauses as usual. Step through a workflow# Command Shortcut Effect Continue F5 Run to the next breakpoint Step into F11 Pause at the next activity, going inside containers and invoked workflows Step over F10 Run the current activity and pause at the next one Step out Shift + F11 Run to the end of the current container Run to this activity Ctrl + F10 Continue to the selected activity Break Pause Pause at the activity that runs next Restart Ctrl + Shift + F5 Stop and start the last session again Pressing F10 or F11 while nothing runs starts debugging the open workflow, paused before its first activity. Right-click an activity for more ways to start: Run to this activity: start debugging and pause there. Run from this activity: start debugging paused at this activity, skipping the ones before it (in a Sequence, Try Catch or Retry Scope). Test activity: run only this activity in a temporary one-activity workflow. While paused, the designers are read-only and the paused activity is marked. Focus on the Debug tab brings it into view. The execution trail marks the activities that ran and the one that faulted; Clear run trail removes the marks. Inspect values# Panel Use it to Locals See the arguments, variables, current activity and exception in scope. Select a variable or argument and press F2 (Set value) to change it while paused Watch Add C# expressions and see their values each time the run pauses Immediate Evaluate an expression once while paused Call Stack See where the run is paused, including invoked workflows and parallel branches. Double-click a frame to go to it The Debug workspace shows these panels by default. In the Design workspace, open them from the command palette (Ctrl + Shift + P). Debug options# The Options group on the Debug ribbon tab has these toggles: Slow step: run through every activity at a readable pace without pausing. Select it again for 1x to 4x, then off. Execution trail: mark the activities that ran. Highlight elements: highlight the UI element each UI Automation activity acts on. Log activities: write when each activity starts and ends to Output as Trace lines. Break on exceptions: pause where an activity throws. Then select Retry to run the activity again after fixing the cause, Ignore to skip it, or Continue to let the exception be handled as usual. Continue on exception: the opposite of Break on exceptions. You cannot change these options while a run is active. Settings > Debug > Break on exceptions also offers All, which pauses on exceptions that a Try Catch handles too. Orchestrator activities in local runs# Orchestrator activities (Get Asset, Get Credential, queue, storage and job activities) need the Orchestrator. In a run from Studio they work when: You are signed in. See Sign in to Orchestrator from Studio. A workspace is selected in the status bar (or in Settings > Publishing > Orchestrator workspace). You may start jobs in that workspace. Output then shows Orchestrator activities run as you in this run (design-time run). If something is missing, Output shows a warning and those activities fail with VXORCH-NO-RUNTIME-CONTEXT. UI automation in local runs# UI activities run against your own desktop. Keep the target application open and do not use the mouse or keyboard while a UI step runs. Defaults such as the input method are in Project settings > UI automation. Read the logs# Output has a channel for each source: Run for the workflow's log lines, and General, Packages, Publishing, Validation, Search and Source Control for Studio's own messages. All shows everything. Filter by Errors, Warnings, Information and Trace. Settings > Debug > Run log level sets which lines a run writes. Keep Output after a run keeps the Run channel between runs. Studio's own diagnostic log is in %LOCALAPPDATA%\Velophex\Studio\Logs. Open it with Open logs folder (Ctrl + L) on the Debug tab, or from Home > Help > About and diagnostics. Its level is in Settings > Advanced > Diagnostic log level. Run test cases# Test cases (created with New workflow > Test case) run from the Test Explorer panel. Select Run all in view, or use the Run menu to run or debug selected or failed tests. Next steps# Publish to Orchestrator. Diagnose jobs on Robots with Robot logs and troubleshooting.

Prerequisites

Run a workflow

Set breakpoints

Step through a workflow

Inspect values

Debug options

Orchestrator activities in local runs

UI automation in local runs

Read the logs

Run test cases

Next steps