We are pleased to announce a new release of Automatiko - 0.14.0
Highlights
- Transaction log and automatic recovery
- Workflow defined errors
- Metadata links
- Support for Azure Cosmos DB
- Improved maven archetypes
Transaction log and automatic recovery
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.
Workflow defined errors
Business logic represented as workflows might have various outcomes which might be of two kinds
- successful - that indicates that business goal of that instance has been achieved
- failure - that indicates a failure from the business logic perspective
To express a failure outcomes of the workflow error end events are used. Error events come with following attributes
- error code - an code (usually numeric) that identifies type of the error e.g. 404 not found or 409 conflict
- error name - human readable error name
- error data type - type of the data associated with the error - optional but hightly recommended to always be used
Defined error as failure outcome of the service call.
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).
OpenAPI definition with failure outcome as error.
Have a look at more details about defined errors in Automatiko documentation.
Metadata links
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.
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
- ReST api endpoint of the task to get its data
- Form link to display fully configured web page for that task to allow user to directly work on it
form link is only present when automatiko-user-management-addon is used.
Support for Azure Cosmos DB
This release comes with complete support for Azure Cosmos DB that allows to use Automatiko with Azure Cosmos DB based backend of
- Apache Cassandra
- MongoDB
Improved maven archetypes
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.