Information Technology Reference
In-Depth Information
Per Process Definition Runtime Manager
In the
custom-per-process-runtime-manager
project, we've provided an imple-
mentation of a runtime manager that will store a KIE session for each process definition.
By default, when you use this runtime manager, it will use the same KIE session for all in-
stances of a specific process definition. The implementation is composed of three custom
classes:
•
ProcessDefContext
: This class defines the context key to be the
String
representation of the process definition ID
•
PerProcessDefinitionRuntimeManager
: This class implements
RuntimeManager
to register the KIE session of each process definition
•
CustomRMFactory
: This class provides a factory method to create the specific
runtime manager for us
Other classes are also used, but they are part of the already available implementation. Most
of them are explained through comments in the provided runtime manager implementation
code, and we will learn about them as we get into detail about how this runtime manager
works.
We've based this custom implementation on
PerProcessInstanceRuntimeMan-
ager
, with some modifications on top of it. They work by getting a local or database map-
ping from the specific context ID to a KIE session ID. If the mapping is found, the same
session is reloaded. Otherwise, a new session is created. The mapping is retrieved from an
interface called
Mapper
, which acts as a Data Access Object for the relation between KIE
session IDs and context IDs.
The mapping, however, is not stored immediately after the creation of the KIE session; it is
stored when a process instance is created, if not present. To connect that functionality with
the internal functions of the KIE session, we provide an implementation of the
Pro-
cessEventListener
interface called
MaintainMappingListener
, which stores
the relation before the process instance is created. The overall class structure looks like the
one shown in the following diagram:
