Automatiko 0.21.0 released

We are pleased to announce a new release of Automatiko - 0.21.0

Highlights

• Automatic error recovery
• Sorting of workflow instances
• Locking support on data store level

Automatic error recovery

Automatiko tracks execution of activities for each workflow instance. In case of execution errors, workflow instance is put into an error state and by that stays in the activity that failed. There are two ways to resume execution from an error state:

• retry the failed node
• skip the failed node

Either way there is a need to perform the action manually. With 0.21.0 release, a new addon has been released. io.automatiko.addons:automatiko-error-management-addon. This addon tracks failures of the workflow instances and performs auto retry. No need to manually retrigger errored instances to recover from temporary issues.

Though this addon does not cover all possible scenarios for failures as there might be a need to adjust the data handled by the instance as that can be the root cause of the error. For that it is possible to alter the data via service api.

To learn more about automatic error recovery, read dedicated section in Automatiko documentation

Sorting of workflow instances

Workflow instances expose service interfaces to be able to interact with them. There are two service interface types

• REST - default and always included
• GraphQL - optional provided via addon

One of the most commonly used feature of that service interface is to list (fetch) workflow instances. Being able to order the result set is yet another common feature.

0.21.0 comes with sorting support sort by and sort direction (ascending or descending) via both service interfaces - REST and GraphQL. Important to note that sorting is supported only for following persistence addons

• file system
• mongodb
• db (RDBMS)

The main reason that neither cassandra or dynamodb based persistence does not support sorting is caused by the architectural choices of these data stores.

Standard fields that workflow instances can be sorted are:

• id - unique (UUID like) instance identifier
• description - custom description of the instance if set
• businessKey - business key of the instance if set
• startDate - start date of the instance
• endDate - end date of the workflow instance - only applicable when end on instance strategy is set to KEEP

Worth noting is, that for mongodb and db there is also an option to sort by custom fields that comes from the data. For example for mongodb users can cort by person's age by using following variables.person.name

Locking support on data store level

Data correctness is really important and depending on use case it might become critical. On the other hand a lot of issues might arise due to concurrency, especially in highly scalable environments. This release of Automatiko introduces workflow instance level locking on data store. This sort of works like pessimistic locking to make sure that before it executes action on given instance it ensures that it will be the only one doing that.

Main motivation for being pessimistic on the way locking happens is to avoid repeated execution due to concurency issues. Imagine scenario where there are two requests working on the same instance and one of them will call external service. Later on, this instance will be rejected due to concurrency issue - optimistic lock - version mismatch. So it will be retried, and by that same external service will be called again. In some cases it might not be an issue (indepotent calls) but it is not always the case.

With the pessimistic locking it will only allow to work on given instance by single client regardless of how many replicas of the service are available. Again, this is only available for following persistence addons:

• file system
• mongodb
• db (RDBMS)

The main reason that neither cassandra or dynamodb based persistence does not support sorting is caused by the architectural choices of these data stores.

Photographs by Unsplash.

---