We are pleased to announce a new release of Automatiko - 0.10.0
Workflow as function flow has been significantly improved to provide support for subprocesses that act as functions. So users can use more advanced constructs to allow use of process composition for function flows as well.
In addition, workflow as a function flow is now fully version aware meaning it will use version number of the workflow to include in the Cloud Event type attribute so events sent are versioned in the same way as workflow itself.
Lastly, workflow as a function flow allows to use message events (both catch and throw) to publish events that will be consumed by other services or functions. For catching messages that are used for receiving messages allow to have two types of correlation:
correlationExpression defined on the message to find which workflow instances should consume the messageHave a look at Automatiko documentation for more information about fault workflow as a function flow.
Workflow as a function has also been improved especially in terms of deployment options. Archetype for workflow as a function flow comes with preconfigured maven profiles for
azuregcplambdaA brand new example User registration function example has been provided that illustrates workflow as a function in action that can be deployed to Azure Functions or Google Cloud Functions.
Have a look at Automatiko documentation for more information about workflow as a function.
Until version 0.10.0 Automatiko allowed to use only local (existing in the project resources) workflow definitions. That caused rather hard limit on reuse of workflow definitions so users were forced to always copy workflow definitions between projects. With this release you can take advantage of multi module projects which allows to simply rely on dependencies to include in the project and main (top level) project will be the one that will have access to all workflow definitions.
Have a look at sample project using this approach.
Following video shows this feature in action.
Service interface (REST or GraphQL) exposes workflow data but do not allow to get access to some workflow instance metadata such as
id - unique identifier in UUID formatbusinessKey - optional alternate key that is more domain specificdescription - description of the workflow instancestate - state of the workflow instance (active, completed, etc)tags - workflow instance tags that can be used for correlationThis is quite useful to know when interacting with service interface and to provide more context information on the client. For instance building list of instances thatcan be easily annotated with tags the workflow instance has. This is now possible and can be controlled on individual request level.
Metadata is disabled by default and requires to be explicitly asked for. REST api allows to simply enable it via
metadata=true query parameter and this will attach metadata attribute to the response.
Automatiko 0.9.0 introduced support for files stored in external locations (like file system, Amazon S3, Google Storage) but that feature was not supported for importing and exporting of workflow instances. 0.10.0 release fills this gap and properly handles files stored in external locations to
Photographs by Unsplash.