Post Date: October 16, 2012
Posted By: Nick Wellinghoff
Previously, I discussed a console command that can be used to test rules. But what if you're writing a custom workflow?
Workflows present the same problems as Rules, they have a complicated syntax that needs to be validated, and they have assumptions about the execution environment. They are also time consuming to test by going through the motions in the real IdentityIQ web application. They're actually much harder than rules because they can be littered with little fragments of BeanShell in embedded <Script> elements or in "scriptlet" attribtue values. Since these BeanShell fragments don't have names you can't just call them with the "rule" command.
There are two options for checking workflow scripts, the first is the "validate" command:
> validate "My Custom Workflow"
What this command does is load the Workflow object into memory, walks over it looking at all the places that might contain embedded scripts
or scriptlets, then compiles and executes the script. Like "rule" this can print out a lot of stack traces as problems are detected, but it also accumulates them and at the end prints out a more concise description of the problems it found:
> validate "Do Manual Actions"
(...)
VALIDATION ERRORS
Variable:identityDisplayName/Scriptlet
--> Undefined argument: identityName : at Line: 1
Step:Manual Actions/action/Approval:0,0/send/return/mode/owner/Scriptlet
--> Typed variable declaration : Attempt to resolve method: getUnmanagedPlan() on undefined variable or class name: project : at Line: 21
Step:Manual Actions/action/Approval:0,0/send/return/mode/owner/validator/description/afterScript/Script
--> Typed variable declaration : Attempt to resolve method: get() on undefined variable or class name: item : at Line: 13
We really need to omit the exception trace during processing and just print the summary at the end.
If you had basic syntax errors you could see them here and correct them. But like rules the problems being displayed aren't syntax errors, they are missing expected input objects. So where do those come from?
Like "rule" you can supply an arguments map:
> validate "Do Manual Actions" args.xml
Unfortunately having said all that, this command doesn't get a lot of attention and I'm noticing it doesn't support some relatively recent features like workflow rule libraries. That should be fixed. But the command I actually use most of the time is "workflow".
> workflow "My Custom Workflow" args.xml
This isn't just a validator, it will actually launch the named workflow using the args file as the initial input variables. If you have <Variable name='trace' initializer='true'/> you'll see workflow trace in the console and if you hit a BeanShell error you'll see the exception dump that would ordinarily be in the Tomcat logs. We absolutely need to clean this up to make it more readable, but what
I like about this is that it's happening in the same window that is being used to import the changes and launch the workflow. Fix the workflow use "!i" to import it and "!w" to run it again. No Tomcat is
necessary.
While we're here, I'd like to point out a console feature that is often missed. Similar to a Unix shell, as you enter commands in the console they are are remembered in a history list and you can recall them with the exclamation point:
> import myworkflow.xml
Once you do this you can do this to import the file again:
> !i
The characters after the ! are the command line prefix, we look backward in the history for the first one that matches and execute that instead.
If there are no approvals or forms I'll use this approach to debug the entire workflow end-to-end. If there are approvals it's more complicated but I still use this approach to get the ball rolling. Rather than logging in as MJ Johnson and assigning the same role to Babs Wilson over and over and over just to get to my custom approval form, I'll do it once, capture the WorkflowCase input variables, put them in the args.xml file and now the approval can be set up instantly from the console rather than in minutes from the UI.
More on approvals in the next installment.
Jeff
