FujiForty - Workflow Activity Designer

If you've worked with ServiceNow for more than an hour you're probably already aware of how powerful the graphical workflow engine is. It's also pretty easy to work with due to the pallet of activities that are available for both in-instance process as well as automating process with 3rd party systems. However, the real power comes when you start to build custom workflow activities.

In the pre-Fuji days, this required everything to be done in scripts and could get a little confusing. If you're experienced in JavaScript it doesn't take long to understand the various activity classes before you're automating everything you can think of.

Fuji is attempting to make activity creation easier, to the point where you can build basic custom activities with little to no scripting. The only downside is the new Activity Designer requires the developer as well as the customer receiving the app to install the orchestration plugin (which could have license implications). ServiceNow figures that if you're building custom activities it's probably because of an external integration so they want customers to purchase orchestration.

When I first looked at the activity designer I was a bit confused and overwhelmed by a new UI and a lot of options. I wanted to go running back to a nice clean script box so I could just extend an existing workflow activity handler and get the job done. You can certainly still do this, but you won't be able to deploy the application or activity packs through the store unless you use the designer. 

There's a lot to go into so I'm just going to stick with some highlights. If you're building custom activities already, I recommend that you spend some time working with the designer before you actually need it for a project.

Since I'm currently working on a few PowerShell activities I'll take you through an example. You can also create other common activity types using a similar method. The options will vary slightly depending on the type of activity you select.

 

 

The Input tab replaces the related list of activity input variables. These are the variables that you'll be asked for when dropping the activity into a workflow. Unfortunately you can't add labels or hints like you could before. I'm sure they'll eventually sort that out so we aren't taking a step backwards on usability.

The Pre Processing table is an optional script you use to modify anything before the activity execution occurs. You have access to the input variable as well as the execution parameters. Just click on the links and the correct variable syntax will be pasted into the script. Once the script has been evaluated the core activity runs. In this case an ECC queue payload will be created and picked up by the MID server. 

When the MID server execution is complete and returns the response to the ECC queue the activity starts processing it's output handlers. In the days when you created activities using script includes, this would be the sensor script processing.

The Output tab is where you define variables to be used locally (in post process script) or output variables to pass data to other activities in a workflow. Once you create the variables you can drag them into parsing rules to define where the variable gets it's value from.

Ok, now this is where I really got excited. Once you drag an output variable to a parsing rule you're presented with the parsing form. No more guessing at XPaths and JSON object property parsing, this does the magic for you. Provide a sample payload based on the result data you selected. In this case executionResult.output is an JSON string. Once the sample is parsed you just need to click anywhere in the string and the parsing expression is displayed. You can even test the expression. This works for JSON and XML data. You can also use regex to parse but you won't get any automatic expression builders. However, you still get to test your regex expression. I might just use this for all my regex testing now, even if it's not workflow related.

Once all of your local and output variables are set, the post processing script is evaluated. Here you have access to the local and output variables for reading or writing if you couldn't get values from parsing rules. You also have access to the result object returned to the activity.

Lastly, we need to define our activity conditions. These are the output path components of an activity that you connect other activities to when building a workflow.

 

The confusing part here is that you don't have the default object of "activity.result" to use like you did in the past. You need to create and set an output variable that can be referenced in the condition check. In this case, and most that I've built so far I created an output variable called "result", so it's exposed as "activityOutput.result", and I set the value in the post processing script. If you don't need post processing you would just set the value using a parsing rule.

Ok, now for the second coolest thing I found, a proper replacement for the workflow scratchpad. The scratchpad was very useful but always hidden away in scripts and you'd forget what was supposed to be there and when. A workflow data bus now manages all data passed between activities and it's really easy to map data wherever you need it. Just drag an object from the data bus into any other activity input and the correct syntax will be generated for you. No more guessing what's available in the scratchpad.

 

Now for a little bit of bad news, or at least a point of frustration for me. I had a couple of use cases where I needed a value from an input variable to be referenced in the post processing script. Unfortunately there's no easy way to accomplish this today. It's been reported to the development team and hopefully they will get this added in a future release or patch. As a work-around I ended up sending the input value back from the PowerShell script as a tag so I could access is in post processing. (Thanks Jesse!)