We are pleased to announce a new release of Automatiko - 0.8.0
Service invocation is one of the most common operation performed by workflows. Till now, it was always expected to be synchronous or to put it in other words, blocking. It is not always desired to block the executing thread to wait for response of the service call. This is even more important when the service is a remote service such as ReST service.
With 0.8.0 release it is now possible to use the non blocking approach to improve the overall execution of the service.
To make use of non blocking service invocation your service needs to be one of the following:
Uni?mode=asyncHave a look at Automatiko documentation for more information about non blocking service invocation.
Sometimes there is a need to have workflow instance variables that are required for execution but at the same time should not be stored. In addition, there should be no additional work required from the workflow developer to keep track of such variables and clean them manually.
Transient variables have been introduced to address exactly this need. By tagging data object (aka variable) with
transient tag, it will make the variable to keep its value until workflow instance
is persisted. The value will never be attempted to be persisted and thus on reload the value of the variable will be
null. That simple, no need to keep track of it any more, all handled automatically.
Monitoring of Automatiko has been moved to Micrometer to take advantage of new features. As part of this work
there were also additional improvements that brings several new metrics
Messages
automatiko.process.messages.received.count - conter for all messages receivedautomatiko.process.messages.consumed.count - counter for all messages that were received and consumedautomatiko.process.messages.missed.count - counter for all messages that were received and not consumedautomatiko.process.messages.failed.count - counter for all messages that were received but failed to be consumedautomatiko.process.messages.produced.count - all messages that were producedautomatiko.process.signals.count - all signals that where received and processed by workflow instanceWorking with workflows in secured environment (when access to the service interface requires at least authentication) in many situations requires to gain access to information about identity of the current request. For example, to be able to check if given request belongs to a user who is a member of given group, or to be able to assign user task based on the caller's identity.
With 0.8.0, there are several functions (that can be directly used in your worklfow definition) that simplify access to identity information
identityName() - returns identity name if found otherwise nullidentityName(String whenNotFound) - returns identity name if found otherwise the given valueidentityProperty(String property) - returns property associated with identity e.g. emailidentityProperty(String property, String defaultValue) - returns property associated with identity e.g. email or defaultValue if no such property is foundidentityHasRole() - verifies if identity has given roleidentityHasAnyRole(String...roles) - verifies if identity has any of the given rolesidentityHasAllRoles(String...roles) - verifies if identity has all of the given rolesGraphQL service interface has been introduced in 0.7.0 and it required non automatiko dependency to be specified. To make things easier, a dedicated GraphQL addon module has been introduced. It's now as easy as adding following dependency to your project to enable GraphQL service interface generation.
<dependency>
<groupId>io.automatiko.addons</groupId>
<artifactId>automatiko-graphql-addon</artifactId>
</dependency>
As part of the dedicated addon for GraphQL, there has been as well improved support for subscription that now covers following events
Photographs by Unsplash.