User task forms and email notifications in Automatiko

 Automatiko 0.4.0 has just been released. I comes with quite some new features among them are 

• user task forms that is provided by user task management addon
• user task notifications that is provided by user task email addon

These two combined provide an excellent support for human actors participating in workflow automation. This article is about to provide some hints behind these two features of Automatiko, so let's dive into them directly.

User task forms

Forms that represent user task (a task assigned to human actors) are a common requirement in the process/workflow automation scenarios. In many cases it is expected that forms will be auto generated by the workflow engine (and some offerings on the market actually do that). But the main problem with that approach is that is is very limited. In many cases it can only support basic forms and what is even more important they are not providing proper business context behind the task. They are usually very generic and expose internal parts of the workflow engine that runs them. 

To give an example -  let's assume we have a simple vacation request approval task assigned to a manager. The auto generated forms are usually going to present it with a checkbox for approval decision and a button to complete the task. The reason for that is the generation of the task form is based on data types of its outputs which will be approved of type boolean and boolean is usually represented as check box. While this will work it does not show the form in expected format - meaning it would show the details of the request and then have two buttons one to approve and another to reject. Taking it even further if the reject button is used the form could ask for additional comment why it was rejected. This can't be done with auto generated forms.

The approach in Automatiko is bit different, it can still show very simple generic form but that is considered as fallback option as sometimes there is just a matter of providing kind of "For your information" type of tasks where the only thing to be done is to acknowledge it. Though for anything that requires input from end user the form should be designed and provided as part of the service.

This is realised with templates for user tasks. Each template is a fully featured HTML page that can use any kind of framework or styles. You can build a really dynamic forms with the use of JavaScript frameworks e.g. JQuery, you can style it with Bootstrap and so on. You own the entire space on how to build your forms, how to layout the forms, if you need to load data from other service to populate fields you can do that without a hassle.

Templates in Automatiko relies on Qute, a server side templating engine from Quarkus. It gives you all the power of the templating and is very well tuned for performance and fast delivery to your clients. Automatiko will give you all the details you need for given task so you can render it and make it very contextual to your users so they will directly know what is expected from them. Plus you can make it to look and feel as any other application in your organisation.

You can read up on the details on how to build your user tasks forms in Automatiko documentation and you can also take a look at vacation request example what makes use of it.

Email notifications

Another important aspect of the user tasks in workflow automation is to notify when a task is assigned. This is very common and almost any user of workflow automation expects this to be out of the box. Automatiko comes with this by a means of addon that will equip your service with this feature.

Emails are expected to serve as a way of notifying about task being assigned and not necessarily about the complete context behind the task. That's why a default template for emails in many cases will be good enough. But it is configurable as well so you can define an email notification template for every task separately. It uses the same approach as the user task forms - templates. 

In addition, tasks can be assigned to individuals and groups so somehow there must be a way to know the email addresses for them. By default Automatiko assumes users are represented as email addresses but that is not always the case. Don't worry, there is a simple way to solve it, by implementing a single interface you can provide your way of resolving user and group identifiers to email addresses. To learn more head to the Automatiko documentation.

At the end I'd like to give you an opportunity to see it in action, have a look at this short video showing both features in action.

If you have any questions or comments feel free to reach out on twitter or mailing list (@automatiko_io) automatiko-dev@googlegroups.com).

Version workflow data with ease

 A common scenario when working with workflows is to handle data objects and their changes. In most of the situations workflow instance will only keep the last value of it and to realise use cases like comparing what was just sent to the instance with what was already in there requires having duplicated data object definitions. This is not the best approach as it makes the workflow definition "corrupted" with details less important from the business goal perspective.

With Automatiko (since version 0.3.0) there is an alternative way to this problem. This is to version data objects by annotating it with data object tag called versioned.

So what happens when you make data object versioned?

Automatiko engine will record every change to the variable as new version. These versions are then available to be accessed as any other variable but will require additional suffix to the variable name

• suffix $ will give access to complete version list of the variable e.g. person$
• suffix $X where X is a number of the version to retrieve it can be a negative (-1) to fetch latest version e.g. person$5 or person$-1

Sometimes referring to versions directly might result in errors like attempting to get the version that does not exist. To make it simpler, Automatiko provides ready to use functions that can be used from 

• script tasks
• gateway conditions

The functions you can use are as follows:

• previousVersion(versions) allows to get latest version of the variable list - previousVersion(person$)
• variableVersion(versions, number) allows to get variable version stored under version number - variableVersion(person$, 4) - note that this one is safe and will return null when given version number does not exist
• isEqual(var1, var2) allows to easily compare two versions of the variable - isEqual(person, previousVersion(person$))

Another aspect is that you can easily create your custom functions by simply implementing io.automatiko.engine.api.Functions interface and implementing public static methods that will become functions and will be available in the workflow definition. You can read up more in Automatiko documentation.

In addition to that Process Management UI also provides quick access to variable versions and allows to also revert to given version of the data object. Once you have process management addon in your service it provides both UI and REST api to interact with versions of the data objects.

Following video shows this in action and the value it brings.

Stay tuned for more updates around Automatiko project. If you have any questions or comments join our community either on mailing list or GitHub discussions.