Information Technology Reference
In-Depth Information
Creating your own runtime manager
The provided runtime manager implementations are enough to start working with jBPM6
without going into the details of how components are created. However, several organiza-
tions reach a point where they need to define specific sharing between processes in a
simple way to allow special process instance collaborations through rules. One example of
this would be writing monitoring rules that count how many process instances of a specific
domain are being created within the last hour that are not yet finished, and take actions
when that number reaches high values. This is something that can be easily written in the
internal
Drools Rule Language
(
DRL
), as shown in the following DRL code:
rule "too many processes"
when
$n: Number(intValue > 1000) from accumulate(
$p: WorkflowProcessInstance() over window:time(1h)
eval($p.getVariable("domainXProcess") != null)
)
then
externalService.sendWarning("Too many processes created
in the last hour: " + $n);
end
In order for this rule to work, all process instances that have the
domainXProcess
vari-
able assigned should reside in the same working memory, and therefore, in the same KIE
session.
Also, they might need specific levels of isolation determined by external policies. For ex-
ample, a company working on legal processes might want to make sure that all rules and
processes that make legal decisions for a specific client remain isolated with respect to the
client. Since the runtime manager is the one that creates the KIE session and the Human
task service, it is the perfect place to decide whether to share an existing session or create a
new one, based on context information.
The main components that we will need to provide to create our own runtime manager are
as follows:
• A
RuntimeManager
interface implementation
• A
Context
interface implementation to pass the domain key we will use
