There are sometimes circumstances (ahem, ServiceDesk) which require that we open a published Workflow file. By deleting or otherwise adjusting the “project.deployed” file name that sits in the published project directory, we are able to “unlock” that project for editing in the Workflow designer.
Workflow Basics
“Object reference not set…” – Salvaging a Busted Project
It’s been a while since the last post – I’ve been busy with an Endpoint Summit (I’ll post the likely embarrassing video after Symantec does) and several customers, and my free time has been consumed with family and Dark Souls II. So it’s past time that I post something.
During a working session with a customer two weeks back, I ran into something I haven’t seen in a while. After making some major changes with data types and mapping in the project, I attempted to spool the debugger, and got this:
Now, once upon a time, this error meant to me that “oh crap, there goes an hour’s worth of unsaved progress”, because this problem prevents saving the project as well. While I don’t have a sincere diagnosis for the problem, I certainly figured out the hammer as a solution.
Workflow Short – Personalizing Workflow Component Defaults
I use the Embedded Rule Model a lot. Excessively so. Although configuring it takes only a few actions, after personalizing the component, all I need to do is drag and drop and it’s ready to use.
In my environment, I’ve done the same for the Hanging Path Trigger component, among others.
Workflow Short – Validating Whether Values Exists
Whether this is a great, or extensible, or lazy, or short-sighted solution is likely quite debatable. However, I use this method for nearly every variable evaluation, and have never had a terrible issue with it.
Let’s set up a situation — say you’re doing a search for a set of values in a SQL table. The results need to be mapped to another variable, but if there are no results (null), the mapping component fails. We need to verify that a value exists prior to leading the data to the mapping component.
Keeping a Tidy Workflow Canvas
Have a look at two examples of sprawling processes, and imagine trying to make sense of them. The first I can take credit for; the second, I can only take credit for grabbing a screenshot when I saw it.
Let’s take a look at how to keep a readable, usable Workflow canvas, and untangle that spaghetti.
Workflow Basics – Modular Workflows
After I gained a bit of experience with Workflow, I began to attempt to tackle more complex processes. While developing these, I ended up with a sprawling mess of a canvas, duplicate evaluations and actions, and path lines jumping all over the place and each other. It was at that point that another, more experienced Workflow developer showed me the importance of modular processes, how to configure them, when to use them, and the difference between model types.
First helpful rule: if using the “fit to screen” zoom button renders the Workflow tiny and indecipherable, then you could likely benefit from some linked or embedded models. We’ll go over the different types shortly.
Second helpful rule: the easiest way to simplify the sprawl of a workflow is to group components into Embedded Rule Model components. Embedded Rule Models are like using folders to sort a stack of random documents on your desk into a nice, neat filing system.
Workflow Basics – Form Validation
So you’ve built a form, and you want to validate the user’s input? I decided a long time ago that I’m not satisfied with Workflow’s use of the standard window.alert dialog:
In this article, I’m going to go over the methods I use for Workflow popup boxes, and in particular, validation error messages. An example of a validation error message box:
