Custom logic in BPMN

Blog: Drools & jBPM Blog

There are several ways to add additional custom logic to the Business Process. This article provides a review of different possibilities and their pros and cons.

Embedded Code

The easiest way, but not the most comfortable, is to use Script Task and its Script field.

When you work with a Script Task, all you need to do is add the node to the process, and you are ready to write Java/JavaScript/MVEL code using the Script property of the task:

NOTE: JavaScript is deprecated and can be removed in the following releases

This way of adding custom logic to the process is very fast. Also, there are no performance issues since all scripts are processed just once with Java code and other assets during the project compile phase. However, this way is not very convenient in the long term due to hard maintainability.

Why use Script fields

No configuration is needed, just write your code!
As fast as any Java logic
During process model time, there is no need to understand implementation differences between task types

Downsides of Script fields

It is not possible to debug this code
Code block has limited syntax highlight and autocompletes features
It’s hard to track changes using version control systems
The use of fully qualified names (FQNs) to use classes. As an alternative import the class for the whole process
Code can be removed unintentionally by morphing Script Task to any other task type

NOTE: for jBPM there is also an additional option to write quick snippets of code with the same benefits and downsides as for Script fields: On Entry and On Exit Actions for different types of activities. This functionality is not present today in Kogito but it will be available very soon

Custom Task

Custom Tasks is a powerful feature. You can predefine the node’s different visual and runtime properties on the canvas. An example can be predefined input and output parameters, as well as a custom task icon, task name, documentation, and other task parameters. Also, using Custom Task, you can specify the custom LifeCycle of the task, which can be used to create a unique experience for the new BPMN node. Custom Tasks explained in detail in another article before. Below are the pros and cons of this type of activity:

Why use Custom Task

It’s possible to debug Custom Task’s logic
All code will be edited directly in VS Code with all perks like syntax highlight and autocomplete
It’s possible to write unit tests for the Task’s logic
It’s easy to track changes using version control systems
It’s possible to predefine different parameters such as Data Input/Outputs
It is possible to predefine some visual parameters as well, like icon and task name
Custom Task can be used as a good template to reuse similar tasks parameters for the whole project

Downsides of Custom Task

You need to use a specific task structure and interface, which makes logic a bit harder to reuse between different task types
During the process model, the user should orient in implementation details. Instead of the small number of well-defined tasks (Manual, Automated, Rules) user will see a big amount of different tasks
If you are using different flavors of BPMN Designer like VS Code, browser plugin, standalone editor, desktop version, and so on, you need to take care to support the WID file between all those editor’s versions.
It is not possible to simply share BPMN files between two and more people. To do so, WID files should be shared and correctly used as well.
All task properties configurations use strict notation on MVEL language and configuration files should be located correctly.

Service Task

Service Task is a compromise between simplicity of Script Task and features of Custom Task and usually suitable for most of the use cases. Service task usage doesn’t need additional knowledge about implementation for Business Analysts, no need for additional files. Also not tied to any interface and don’t need any registration as Custom tasks do.

NOTE: In jBPM, Service Tasks can’t be placed inside of normal Java application life cycle which means it is not possible to use features like Java Annotations or CDI in Service Task if the project will run in jBPM. That’s why Custom Tasks can be preferable for jBPM projects. However, if the project will run under Kogito all features from the Java life cycle are available and Service Task can be a preferable choice.

How to use Service Task on Kogito

To use the Service task, you will need a Java bean located in your project or project dependencies and mark it with CDI annotation.

package com.github.hasys;

import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class TestService {

    public String greetUser(String name, Integer age) {
        System.out.println(String.format("Hello %s with age %o", name, age));

        return String.format("User %s greeted.", name);
    }
}

To configure Service Task to use this Java bean, its FQN should be used as Interface property and method name as Operation.

Assignments are used to send data to and get data from the Service Task. The output will always have the name Result for jBPM and can be any for Kogito. Inputs should be the same as the method’s parameters for both jBPM and Kogito:

You can check examples in detail in our kogito-examples repository.

Why use Service Task

It’s possible to debug Custom Task’s logic
All code will be edited directly in VS Code with all perks like syntax highlight and autocomplete
It’s possible to write unit tests for the Task’s logic
It’s easy to track changes using version control systems
The process can be shared with Business Analysts without additional files and configurations in different flavors of BPMN Editor
During process model time, there is no need to understand implementation differences between tasks
For service tasks, plain Java bean classes used, which makes business logic flexible and reusable

Downsides of Service Task

Not possible to predefine different Task parameters
Java bean should be linked for each Service Task separately

Conclusion

There are several possibilities for how to add custom logic to your Process. All of them have their benefits and limitations to fill needs for any use cases.

The post Custom logic in BPMN appeared first on KIE Community.