We are pleased to announce a new release of Automatiko - 0.14.0
There are situations that can cause a crash of the service at the time it was serving requests. That means that the in-flight request(s) might not be completely finished and by that not save into the data store. In such situation service consumers might need to retry the operation which is not always possible.
0.14.0 release comes with opt in feature that allows to enable
transaction log. This transaction log will record all operations
that the service does and save it locally as sort of snapshots to avoid duplicated execution or what is even worse, lost requests. An important aspect of
this feature is that it offloads service consumers from a need to retry from the beginning as the crash might have happened in the last step of the workflow.
A great thing about transaction log is that it comes with automatic recovery on next start of the service and by that will bring your service to the state as nothing crashed (or very close to that). It also blocks the start of the service until the recovery is completed to avoid corrupted instances being accessed.
A video demonstrating transaction log in Kubernetes environment can be watched below.
Have a look at more details about transaction log in Automatiko documentation.
Business logic represented as workflows might have various outcomes which might be of two kinds
To express a failure outcomes of the workflow
error end events are used. Error events come with following attributes
Such errors are then automatically included in the service interface as potential outcomes of service calls. An example below that shows errors defined in the OpenAPI definition of the service (visualized by Swagger UI).
Have a look at more details about defined errors in Automatiko documentation.
Automatiko comes with automatically created service interface (either ReST or GraphQL) that allows to fetch metadata of the instance being executed.
These metadata has been described here and with 0.14.0 release there is additional metadata added -
Links correspond to tasks that are directly available after request has been finished to the user who made the call. A perfect example of this
is an use case where user triggers an action and there might be additional steps that should follow.
Such use case is usually reffered as
next action and is rather common in workflow automation. Instead of making a call to get tasks,
user is already provided with links to
formlink is only present when
This release comes with complete support for Azure Cosmos DB that allows to use Automatiko with Azure Cosmos DB based backend of
Maven Archetypes has been slightly improved especially in context of native image generation to be more efficient. In addition to that,
a new profile has been added
kubernetes-native that is tailored for Kubernetes based target environments as it
automatically adds health checks and can also generate kubernetes manifest files.
Photographs by Unsplash.