Options

Fluent Builder API

To create simple BPMN processes we provide a fluent builder API. With this API you can easily create basic
processes in a few lines of code. In the generate process fluent api quickstart we
demonstrate how to create a rather complex process with 5 tasks and 2 gateways within less than 50 lines of code.

The fluent builder API is not nearly complete but provides you with the following basic elements:

process

start event

exclusive gateway

parallel gateway

script task

service task

user task

signal event definition

end event

subprocess

Create a Process With the Fluent Builder API

To create an empty model instance with a new process the method Bpmn.createProcess() is used. After this,
you can add as many tasks and gateways as you like. At the end you must call done() to return the generated
model instance. For example, a simple process with one user task can be created like this:

As you can see, a sequential process is really simple and straightforward to model, but often you want
branches and a parallel execution path, which is also possible with the fluent builder API. Just add
a parallel or exclusive gateway and model the first path till an end event or another gateway. After that,
call the moveToLastGateway() method and you return to the last gateway and can model the next path.

If you want to use the moveToLastGateway() method but have multiple incoming
sequence flows at your current position, you have to use the generic
moveToNode method with the id of the gateway. This could for example happen
if you add a join gateway to your process. For this purpose and for loops, we
added the connectTo(elementId) method.

This example creates a process with three parallel execution paths which all
join in the second gateway. Notice that the first call of moveToNode is not
necessary, because at this point the joining gateway only has one incoming sequence
flow, but was used for consistency.

The example below shows how to create a throwing signal event definition and define the payload that this signal will contain. By using the camundaIn methods, it is possible to define which process variables will be included in the signal payload, define an expression that will be resolved in the signal-catching process instances, or declare that all of the process variables in the signal-throwing process instance should be passed. It is also possible to define a business key that will be assigned to the signal-catching process instances.

Another use case is to insert new tasks between existing elements. Imagine a process
containing a user task with the id task1 which is followed by a service task. And now
you want to add a script task and a user task between these two.

The default behavior is that each newly added flow element will be placed next to the previous flow element.

When flow elements are added to an embedded subprocess, then the subprocess is resized when the subprocess border is reached. Therefore,
it is recommended to first add all new elements to the subprocess and to then create the following elements. Otherwise it could lead to
overlapping elements in the diagram.

Branches of gateways are placed one below the other. Auto layout is not provided, therefore the elements of different branches may overlap.