We are pleased to announce a new release of Automatiko - 0.21.0
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:
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
Workflow instances expose service interfaces to be able to interact with them. There are two service interface types
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
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
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:
Photographs by Unsplash.