Aegis Workflow 101 – Debug Mode

Aegis Workflow 101 – Debug Mode

Welcome to Part 8 and the final topic on Aegis 101.  A line had to be drawn as to what would make it into 101 and it ends here with a topic I've had a love/hate relationship with since its arrival, but I am now finally (almost) a convert! Debug mode.

Simply put, Debug Mode allows you to test workflows from the workflow designer without having to create new revision => edit => save => put in production => switch to web console and test. So it definitely simplifies things - which might make you wonder why I tended to ignore it for so long - I'll get to that later!

In the workflow designer, click on the Debug tab to get to the Debug Mode configuration options screen.

m2

You can simply ignore all options (which I find is the most likely scenario) and just click on 'Start Debugging'.  Now if you have only a Manual Trigger on the start of workflow, the workitem will start almost immediately

m3

If your workflow is started by an event, it will sit waiting for the trigger criteria to be met before starting the workflow.

m4


If you have a mix of Manual and Event Triggers then you will be asked which method you would like to use to start the workflow.

Debug mode also uses a different Correlation 'container' which means that events consumed by debug mode are still available to production workflows.  Although developing workflows in a live environment is always a big no no.

You'll see that at any time during the execution of a workflow in Debug mode ou have the option to 'Stop Debugging' which takes you out of Debug mode, or Terminate Workflow which stops the workflow but stays in Debug mode.

m5

While a workflow is running or ended you can look at the activity inputs and outputs as you would in the Web Console.  When the workflow ends you can either exit debugging or restart debugging.

Now most of the time this is pretty much all you'll do or even need to do with Debug mode, but if you want to actually Debug the workflow, then you can use Break-Points.  Break Points can be set on connectors and activities.

m2

I prefer to set breakpoints on connectors rather than activities.  If you are used to Debugging in programming, you'll be familiar that when you set a breakpoint on a line of code you can see the status of values at that code.  When you set a breakpoint on an activity the activity won't have run yet, so I set the breakpoint on the outgoing connector.

Once a breakpoint is hit, you also get to use the 'Perform Single Step' option which moves onto the next activity.  You also toggle breakpoints on any activity.

So all good with Debug Mode!

Ok so here is why I'm still not a convert to Debug mode - None of these reasons may matter to you!

  1. When you are in debug mode you cannot edit the workflow.  You can either be debugging or editing.  When you run the workflow in the webconsole you can be editing the next revision while you wait for a trigger to fire or the workflow to progress to the part you are testing.  This allows faster workflow development, at least in my opinion.

  2. Using debug mode you miss out on using many revisions.  I like being able to use a revision and test it and if necessary revert to a previous revision if I find an alternative method was more efficient.  When you use Debug mode you are less likely to have many revisions so it can be a lot harder to re-create a scenario.

  3. Workflows run in debug mode do not show up in the webconsole so once you exit the debugger you have to re-run it to see the inputs and outputs.

  4. Debug doesn't work as expected on parallel operations.  If you are debugging parallel flows in a workflow unfortunately a breakpoint stop everything.  Many times I've had to examine workflows where logic in parallel flows caused workflow to misbehave, and you can't really find out whats happening using debug mode.


 

Traditional debug mode is what existed before debug mode - and well I use use it in Debug mode and Webconsole.  So how is it done?  Empty Input-Forms!  Drop an input form along your flow and the flow will stop as expected at that activity and all other running flows will continue to run - the original breakpoints!  This means you have more control over the workflow in letting it run as it wants to.  The input form will work as normal, just click on the OK button to let the workflow continue.  Like I said I tend to use the input forms as breakpoints in Debug mode when debugging workflows with parallel flows.

So that is it for Debug mode and Aegis 101 !

 

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2016-05-04 00:06
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.