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 SmartObject Services – Configuration update, static endpoint

After the release of K2 1370, there have been some small updates to the K2HostServer.config file for your SmartObject Services configuration.

The basics is pretty simple, KB1370 added the ability to change binding and binding configuration on the REST and WCF endpoints separately. Because the binding configuration also defines the authentication mechanism, this means that REST endpoints could use basicHttpBinding with Basic authentication, while the WCF endpoint uses wsHttpBinding with Windows authentication. It also allows us to run either one endpoint on HTTPS while the other is not.

In my previous post on the K2 Services I showed you how to create a static endpoint, this simplifies the URL and allows you to rename or update the SMO without the endpoint changing. The configuration sections shown in those posts are now outdated and won’t work anymore. Since the KB article describing the change doesn’t have all the parameters, this post is also a note-to-self.

Continue reading “K2 SmartObject Services – Configuration update, static endpoint”