K2Five: (Process) Escalations

K2Five’s new workflow designer is a great improvement over the old designers. Improvement and innovation can’t always be made on top of legacy supported systems. This means that some features change and/or might not be available at this time of first release. The new designer is a big change and i’d like to highlight some changes here with regards to process and activity escalations.

One element that the new workflow designer currently does not have is Process Escalations. For those who don’t know, escalations were used in K2’s workflow designers to do things after a certain amount of time. In reality there were 3 types: Event Escalations, Activity Escalations and Process Escalations. Event and Activity escalations were roughly the same. It allowed you to send an e-mail, redirect a task or expire a activity after a certain amount of time after it’s start time. Process escalations did the same. It allowed you to do something after a certain amount of time of the process starting.

With the new workflow designer there are no escalations anymore. They are renamed into Deadlines and Reminders and only exist on the step level. There is no process deadline/reminder/escalation anymore at this time.

Reminders

Reminders can be used to send a reminder e-mail or redirect the task to somebody else.  A combination of both can also be made. A reminder can also be repeated (click the small reload icon on the left bottom of the e-mail reminder). The redirect can not be repeated as that doesn’t make a lot of sense (you’d redirect to the same person). You can set a reminder on a specific date/time, after a number or days, hours, minutes or seconds (the hours/min/seconds can be moved left right – not shown in screenshot as it’s mouse-over) and you can set them a certain amount of time before the deadline.

Deadlines

A deadline is used to expire the process step. There’s again the configuration of an On Date deadline or after a number of hours/minutes. This is also where working hours come in. Once you select either option, you’ll get to specify what the default behaviour would be. This means you’ll need to model the expiration into the workflow as seen below. This is very different than what we were used to in the old designers, but for me this seems more correct: You want to be clear that the task itself was ‘automatically completed’.

No Code

One element of the K2Five workflow designer is that it has no code. An option that we had with K2 for visual studio was to run a bit of code on an escalation. This was sometimes used to (for example) update some data like a KPI item. This is no longer available and there is currently a feature request to execute a SmartObject when a Deadline occurs. For the process level this can be easily solved (read on).

Process Escalations

The K2Five workflow designer does not have the ability to do process escalations anymore. There is now a good way of implementing process escalations using timers inside the workflow. You then have the process escalation clearly modeled in the workflow. I guess one can argue if this correct or not. I believe the below workflow is very clear for everybody and indicates better what is happening with the workflow than before. It is also better that we can now do the work using real process steps, whereas in the past calling an SmartObject (like below) would need to happen in code, which wasn’t great.

Roadmap

The above shows a good way of modelling timer based events into your process. You might like it or not, that’s up to you. The product team is however constantly improving and there is currently still an item on the roadmap to add Process Reminders to K2. For the process steps we’ll see what the future brings.

Conclusion

K2 Process Escalations may no longer exist in the K2Five workflow designer, but this blogpost shows that there is a very good way of modeling timer based process events into the workflow. One could argue that this is even better than we had before as it is now clearly visible.

 

K2Five: Creating an asynchronous event

With the new release of K2 five and it’s workflow designer, we do not have the capability to write custom code in our workflow anymore. For some, this is a shocker and unbelievable. Having no code in your workflow has been a best practice for some organizations for years and as a low-code platform, it’s a nobrainer. However, there are requirements that always required code in the past, one of those Asynchronous server events.

What is an asynchrous server event?

Server Events in K2 all the event wizards that do something in the workflow but do not have any interaction with end users. These events (by default) run in a synchronous mode. This means that they execute and then continue with the workflow (to the next step, or next event). Asynchronous server events will simply not continue with the next step, until an outside source has told the K2 server to do so. This outside component would use the K2 client API.

What should it be used for?

Of course, one doesn’t want a server event to normally wait for some outside trigger. So what is this used for? There are scenario’s where you might want to off-load some work from the K2 server to another system or where you have to wait for another system to complete some task. A common example is integration with a physical mail system where K2 has to wait until a scanning solution has received back a response my snail. A lot of designers will resort to (what we call) a “polling workflow”. It is simply a workflow that runs in a loop and checks if the external system has completed it’s work based on some status field. This is a bad design and should be avoided. Of course, if you can’t do a loop and poll the external system, then how should the k2 workflow know that the external system has completed it’s work? That’s exactly where asynchronous server events come in. The idea is to tell the external system that something must be done, and that the workflow waits until the external system tells K2 that the workflow can continue.

How did we do it in the past?

Pre K2 five, you simply used a Code Server Event and used the line “K2.Synchronous = true;” to make the workflow wait. You would also have some code to call the external system and provide that external system with a SerialNumber. In K2 five, there’s no option for code, so how is this done now?

SmartObject events!

The people at K2 have considered the scenario and the pattern is always that an external system needs to be informed first before K2 start to wait. Integration with other system should be done via a SmartObject. So, the SmartObject wizard now has a simple checkbox to indicate that after the SmartObject was executed, the workflow should wait for the external event.

Workflow REST API

K2 five also hosts a new workflow REST API and this REST API has the option to complete these server events. So, all the external system needs to do is call this REST service. Of course, the old fashioned .NET client API would still work too.

Enabling these new REST API’s is super easy and can be done in the K2 management site:

How is everything connected?

Just like the tasks that K2 provides via the worklists, the Asynchronous Server Event also has a Serial Number (SN). This means that in your call of the SmartObject, you can use the SN and pass this unique number to the external system. This external system needs to store it. Configuration could look something like this:

In the above example, I just created a simple SmartObject with a few properties like ID, SN, Folio and Status.
Testing the REST API
The REST API also has a swagger definition file which allows one to test via the browser. So, testing this becomes super easy:

Conclusion

The new K2 workflow designer is a new approach to building workflows. The design team has analyzed how some features were used and found easier and quicker ways to implement the same functionality in the new designer. The above is a nice example of how concepts that required code and more customizations in the old workflow designers, now needs no code anymore and has become a lot easier. It provides a great way to integrate K2 with other systems.

 

K2’s 4.6.11 – For Each Wizard

With the release of K2 4.6.11 a new wizard has been added to the k2 blackpearl software. It’s the For Each wizard, which might surprise you. How can a workflow engine like K2 not have a For Each option? It’s quite simple once you understand how the K2 workflow engine works.

Activities and line rules determine the flow of the process. Questions like ‘Does your workflow have branch and merge options?’ never really applied to K2 due to the easy structure of Activities and Line Rules. Every line rule is evaluated after the activity is completed and the line is followed once the line rule evaluates to True. A loop becomes a simple line back to the same activity with a line rule evaluating to True. A branch is just an activity with two lines that evaluate to True and a Merge is an activity with two lines rules going into it that both evaluate to True, with a preceding rule that checks if the activity should start. If a loop is just a line back to the same activity with some line rules, why add a For Each wizard?

The reason is simple, continuous improvements on ease of use and usability.

Before the For Each wizard we had to use a difficult-to-explain option called a destination set configured as “Plan per slot (no destination)” to loop over a set of items. It’s a destination with no destination – yeah, not very clear. It also didn’t show up very well in View Flow, which is the live graphical report for what’s going on with a particular instance of a workflow. If you wanted to do more advanced activities in that loop, you would have to use an IPC event. This means a sub-process per item in the loop which is also not always the best approach visually as well as for performance.

The For Each wizards solves these with an easy way to loop through a list of items.

How does it work?

K2 Studio and K2 for Visual Studio

Let’s first see how it works in the K2 Studio and/or Visual Studio designers:

For Each event in K2 for Visual Studio

Drag and drop the For Each wizard onto the canvas and you’ll need to specify a list of items to loop through in the Source field. You can loop over various items, like:

  • List Item Reference
  • SmartObject List method
  • Comma separated list

ForEach - Object browser

The wizard also asks for the field Reference and Index. The reference becomes the name of the Item Reference for the items in the list. The index is used for two Data Fields. In the example, the Data Fields are ItemIndex and ItemIndex Result. The Item Index is simply the count of the loop, while the ItemIndex Result tells you if there is a next item or not. You will most likely use the item reference created. The item reference refers to the current item in the loop. If you’ve used a list item reference (created with the Create List Reference), then this would be the full reference to that item and not just a reference with a single variable in it. The For Each wizard add its own item reference, so if you use an item reference in the For Each wizard, you will have two item references, which technically might be a consideration as References are stored as a bit of XML and this impacts performance and database growth slightly. If you’ve used a SmartObject than it would contain the property that you selected in the Source field of the For Each loop. If performance really is key, we would use a SmartObject directly in the For Each wizard and not create an Item Reference first. Obviously working with an item reference (for example, looping over list items) can make life a lot easier for you when designing your workflow.

Once you’ve placed the For Each wizard, you get two lines out of the activity. You must create the activities to which these lines need to go yourself, and when you’re done you create a line back to the For Each activity. The final result would looks something like this:

K2 Designer

Within the K2 Designer, it all works similar to the full client, except that it looks a little different:

What can be confusing is that the K2 Designer most likely already has an item reference associated with the process. The reason is because this designer always has context of an item. In the screenshot, I’ve made my workflow on a custom list in SharePoint called Emails. I initially thought that I could use that, but that is just an item reference, so it’s not a list of items. Within the K2 Designer there is a lot more benefit from a design perspective to first create a reference!

The final result would like this:

Conclusion

The For Each wizard is a nice addition to the K2 platform and allows an easier design of the workflow. It’s quite easy to use (especially in combination with the Create Reference wizard), which is exactly the aim of the wizard.