Automatiko 0.35.0 released

Workflow Java DSL improvements and more

Posted by Automatiko team on August 14, 2024 · 4 mins read

We are pleased to announce a new release of Automatiko - 0.35.0 and follow up on 0.33.0 and 0.34.0

Highlights

  • Prefix of REST api for workflows
  • Expressions as lambda in Java DSL
  • Disable persistence at runtime
  • Configurable source folders
  • Azure blob store as file storage
  • Deprecation of Serverless Workflow support

Prefix of REST api for workflows

A new built time property (quarkus.automatiko.resource-path-prefix) was introduced to allow to set endpoint prefix for all workflows instead of being bound directly based on process id and version. All workflow related endpoint can be now easily configured to be exposed via common endpoint prefix e.g. /api/workflows which will then be followed by version and process id - /api/workflows/v1/claims

Expressions as lambda in Java DSL

Workflows Java DSL has been significantly improved to provide more Java like usage patterns. The last few releases provide improvements in following areas

  • lambda expression for correlation, message filters
  • lambda expression for data object initial values
  • lambda expression for calculating timer expressions
  • repeat construct allows to handle errors for each item
  • WorkflowBuilder allows to set category to group workflows as part of OpenAPI definition
  • error handling improvements and simplifications

Disable persistence at runtime

In certain situations service built with given persistence might not be started due to missing persistence storage. Like running tests against fully built application but without the database being available. Automatiko 0.35.0 allows to disable persistence at runtime and fallback to in memory storage only. This can be done by setting quarkus.automatiko.persistence.disabled to true value.

Configurable source folder and project paths

Automatiko supports multi module setup which essentially allow to define workflows in different modules than the actual application - where quarkus build plugin is defined. This means that source of the workflows (especially important when using Workflow Java DSL) might be in different location. Automatiko 0.35.0 introduced a property quarkus.automatiko.project-paths that allows to provide relative path to the project where the workflows are defined. Multiple paths can be provided with comma separator.

In addition, quarkus.automatiko.source-folder property was added to allow to change the source path in the project structure. By default it assumes to be stanadard maven project structure and by that it is set to src/main/java but sometimes the structure is different like in Gradle based projects. This feature aims at supporting Gradle as build system.

Azure blob store as file storage

Azure Blob Store has been added as support for file persistence in similar way as S3, Google Cloud Storage, Mongo GridFile system. With this feature, users can store files used within their workflows reliably in Azure Blob Store.

Deprecation of Serverless Workflow support

Serverless Workflow support in Automatiko is being deprecated which means there won't be any development on this workflow definition format any longer. This is done based on the fact that Serverless Workflow does not bring extra value and underdeliver on its original promise to become the de-facto standard for workflows in the cloud. At the same time it proved to be very complex for anything more than trivial hello world workflows.

While it is not yet being removed but is planned to be completely dropped from the code base in 2025.

Photographs by Unsplash.

← Previous Post