I have a client who wants to track all outgoing messaging from all of their K2 applications to assist in troubleshooting if someone says they didn’t receive a notification.
Normally, no big deal; create a database table or two, a database view and an insert and a list proc, turn those procs into methods in a SmO and call it from a SmartObject event after each of the email events in the workflow. Good to go, right?
But all outgoing messaging includes escalation e-mails… trickier, but I’ve got a slick little trick up my sleeve.
I freaked out a little in my first look at K2 blackpearl 4.6.9 — I didn’t see the Environment Fields node in the Object Browser.
Oh no! Why would they take away the environment fields? I RAVE about these things, and for good reason — they allow for string values to be injected into a process at runtime. I use this magic in the form of e-mail text and other data the business might want to tweak at will, because it saves me from having to recompile and redeploy the solution — a workflow process will grab the value when it needs it.
Fortunately, one of my team members was able to talk me down from the ledge: Environment Fields are still very much a part of blackpearl — the folder just won’t exist until you create an environment field.
Here’s how: Open your blackpearl project, and navigate to the object browser. Right-click on any of the existing nodes, and click on Add new field… .
You should see the familiar Add New Field dialog appear. Here’s the key: Select Miscellaneous Field in the Item Type drop down list. Name your field and give it a value. Fill in the Field Description field for extra credit and click the black OK button in the dialog’s lower right corner.
The Object Browser should refresh. A wild Fields node appears!
It’s super effective!
By the way, if you remove the single Environment Field you just created, the Fields node will disappear again.
Let’s say a person actions a Process Instance in your workflow, but the item seems to “disappear” unexpectedly — routed to a special queue for workflow administrators because of an error condition. It would certainly be nice if the “actioner” was notified about the problem too, right?
K2 blackpearl has a nice way to automatically escalate activities. Say you have an activity which contains a SmartForms Client Event. Because events are fired sequentially within an activity, client events bring a process instance to a standstill until the client event is completed. (The example below contains four events, which are called sequentially. The green backgrounds indicate events which have completed; the blue background indicates the Get Approval Client Event is in progress, and the white indicates the Call Review event has yet to be called.)
K2 was clever to bake in some simple escalations, which can be based on an arbitrary value for elapsed time. If your approver hasn’t taken action in a timely manner, you can have K2 do things like send the process instance to a separate activity, or to nag the approver with reminder messages.
Recently, I was asked if we could shut off the escalation for a specific activity. Several hundred people were about to receive reminders about their applications when the delay was actually on our side, not theirs. Sadly, because the process instances were tied to a specific version of the workflow, deploying a new version with the escalation action deleted or modified would only affect processes instantiated after the new version was deployed. It wasn’t going to do anything to help with the current situation.
The conundrum led me to think about how we could handle a situation like this in the future, and at will. Here’s what I came up with.