We are pleased to announce a new release of Automatiko - 0.18.0
Highlights
- Java Workflow DSL
- Customize email body and subject for user task notifications
- Ability to look through history of subprocesses
- Process management UI enlarge workflow definition image
- Metadata links include signal endpoints
Java Workflow DSL
Workflows can be expressed in various formats. The primary one in Automatiko is BPMN but it also supports Servlerless Workflow specification. In both of these formats, workflow definition is expressed as separate file - that is either hand written or modeled in graphical way. They have one thing in common - they are based on specification which defines possible constructs. In many cases this can be referred as Domain Specific Language.
0.18.0 release introduces Java DSL for workflow definition. It aims at making workflows easy to be written as Java code. To the extent where most of the features of both Java and Automatko can be used.
Basic workflow defined with Java DSL
@Workflows
public class MyWorkflows {
public WorkflowBuilder splitAndJoin() {
WorkflowBuilder builder = WorkflowBuilder.newWorkflow("splitAndJoin", "Sample workflow with exclusive split and join");
String x = builder.dataObject(String.class, "x");
String y = builder.dataObject(String.class, "y");
SplitNodeBuilder split = builder.start("start here").then()
.log("log values", "X is {} and Y is {}", "x", "y")
.thenSplit("split");
JoinNodeBuilder join = split.when(() -> x != null).log("first branch", "first branch").thenJoin("join");
split.when(() -> y != null).log("second branch", "second branch").thenJoin("join");
join.then().log("after join", "joined").then().end("done");
return builder;
}
}
Workflows defined in code (as Java DSL), or modeled as BPMN have exactly the same capabilities. They will have service interface (REST and/or GraphQL) created, integrates with messaging (e.g. Apache Kafka or MQTT), persistence and so on. There is no decrese in the feature set provided regardless which format of workflow definition is used. Even more, you can mix all of them in single project.
Worth to mention that workflow definition image is also created for workflows defined with Java DSL
Workflow definition image for Java DSL.
NOTE: This is the first release of Workflow Java DSL and is focused on basic use cases and will be further enhanced in the next releases.
Have a look at more details about getting started with Workflow Java DSL in Automatiko documentation.
Customize email body and subject for user task notifications
User task notifications are powerful way of informing users about work waiting for thier input. Up to this release, the email body had to be included in the service as part of build time. On its own, it's not a big problem as in many cases that was enough. But there are use cases where the application is built by one team and then deployed and used by other.
In such situation the other team could not customize the email body any longer. This release allows to provide email templates
at runtime via a folder with .html files which follows the same naming convention. Such templates are then loaded and
registered at startup to enable customization of the email notifications.
In addition to that, email subject can also be customized on user task level. Each user task can add EmailSubject
data input and if such data input is present it will be used as the email subject of the notification.
Have a look at more details about user task notification in Automatiko documentation.
Ability to look through history of subprocesses
Workflows can invoke sub workflows to take advantage of a good practice called process composition. This at the same time makes the workflow execution history split into various instances. There are situations where the complete visibility to history is required, and that includes the sub workflows.
This release comes with capability to load sub workflow instances based on their status. By default it will only
take into consideration active instances as completed ones are removed from the data store. Though this can be altered
by enabling to keep completed instances in the data store by setting quarkus.automatiko.on-instance-end to true. This
will allow to have complete history over entire hierarchy of workflow instances regardless of their status (active or completed).
Process management UI enlarge workflow definition image
Process management UI shows available workflow definition as tiles. Each tile is equipped with an image that represents its workflow definition. In situation where the workflow is quite complex (with many activities) it can be hard to see the details. To address this, an option to enlarge the image has been introduced. As simple as clicking on the image in the tile, will bring a popup with the image enlarged to make it easy to read.
Workflow definition image enlarged.
Metadata links include signal endpoints
Metadata can be returned for most of the REST/GraphQL calls to get the details behind the execution, instead of just the data. The metadata include (among other things) links to resources that are currently active. That can be a user task that should be worked on.
In this release, links also include the endpoints to signal based resources which become really important when using event based subprocesses as this enables a smooth transiton to ensure all work is done in timely manner.
Photographs by Unsplash.