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.
