Workflows are usually seen as a way to orchestrate systems. But that is just one of the uses cases. Workflows can be really good at expressing business logic to increase visibility into the logic implemented.

But then the question is how to define workflows?

In many cases, workflows are represented as models e.g. flow charts. That requires modelling tools as well which is not always what developers want to do.

So to help developers enter the world of workflows, Automatiko (an open source toolkit to build services and functions based on workflows) introduced recently a Workflow Java DSL.

This domain specific language (DSL) comes with a handy fluent like API to define workflows. It is very well integrated with any IDE to provide easy entry point for any developer.

Let's have a quick look at the basics of it

@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;
    }
  }

Few important aspects to note here:

• class that is annotated with @Workflows instructs to create an service API for every public method that returns WorkflowBuilder
• splitAndJoin method defines a simple workflow that
  • declares two data objects x and y of type string
  • first thing it logs the values of both data objects
  • then it splits into different paths depending on the value of the data objects
  • then joins it back
  • logs a message
  • and ends the workflow

Based on this workflow definition, Automatiko at build time will generate a fully featured (REST) service API that will expose this workflow as a service.

In addition to that, workflow diagram will also be generated based on above workflow definition.

With just few lines of workflow DSL developers not only gain possibility to define business logic in descriptive way but get out of the box service api and visualisation of the execution for every instance.

This is just very simple introduction to the Workflow Java DSL and more complete getting started guide can be found in Automatiko documentation which I encourage you to have a look and give it a try.

If you have some interesting use cases that could challenge the workflows I would be more than happy to try it out! Let's see how far workflows can be taken to cover business logic.

Lastly, a short video demonstrating Automatiko Workflow Java DSL