Enhanced KIE Server Router and Workbench integration

After KIE Server Router introduction there was quite interesting feedback especially regarding integration with workbench. Main point identified was the extra management needed when KIE Servers run in managed mode. This extra management was to setup (or more configure as router self register itself in the controller) to deal with all possible containers that backend KIE Servers could use.

So to put it straight, let's look at one scenario:

• single KIE Server Router
• two KIE Servers with unique server ids (pointing to different server templates in workbench)
• hiring
• hosting hiring container
• evaluation
• hosting evaluation container
• single workbench with KIE Server controller

So with this setup, upon start KIE Server router will self register it in the controller but the servlet template will not have any containers defined. What impact does it produce? It means that workbench integration with KIE Server will not know how to construct data objects when interacting with it. In most of the cases it will simply say - no way to connect to KIE Server.

So to solve that, administrator would have to manually define all containers in the KIE Server Router's server template that are behind the router. This might work for simple cases where number of containers does not change too often but if the environment is much more dynamic it becomes quite an issue...

To address this out of the box, KIE Server Router is now equipped with logic to notify the controller about containers from the backend KIE Servers. This is done automatically whenever KIE Server deploys or undeploys a container. That is then directly registered in server template and can be used right of in workbench.

Here is how it actually works

Thanks to this integration between router and controller, there is no more manual intervention needed from the administrator side whenever new KIE Servers or new containers are added to be managed by the router.

Another (related to this) feature was added as well, this time to the integration between KIE Server and the Router. Till know KIE Server was only attempting to notify router when it starts. Though when at that time router was not available KIE Server didn't retry to notify it. That could lead into situations where server was up but router was not aware of it. Enhanced integration is that KIE Server will schedule retries (with default 10 seconds interval) to constantly try to notify router. This way as soon as router comes up it will receive notification from KIE Server and then register it (and its containers) in workbench.

Small features but makes the integration much easier and reliable.

Special thanks goes to Karel who lead the QE test day for KIE Server, well done Karel and the team!

Linked process instance images

In one of the previous posts I described how to retrieve images of process instance from the runtime environment. Now I'd like to share small but helpful improvement in that area. Links between process instances that follow parent child relationship. To put it more in BPMN2 context those processes that use reusable subprocess (call activity).

This very simple process uses call activity to invoke another process instance that is linked to this one. In runtime after "test" activity is invoked there will be two process instances:

• parent process instance that consists of call activity node

• child process instance that was initiated by the call activity 

So this is what you could do already, so where is the improvement? It's this small '+' sign that allows to link between these two process instances. And this does work for both active and completed process instances.

A more complete showcase can be seen below

Short article but nice feature :)

jBPM 7 - case management security

Case management puts additional requirements on business automation. In many cases it's much more domain specific than business process management and thus will then have different (or better would be to say - extended) needs. This is no different when it comes to security.

Cases come with so called case roles. These are generic participants that will be involved in case handling. These roles can be assigned to user tasks or used as contact references. Though they are not defined in cases as concrete users or groups of users. Case roles are on case definition level to make the case definition independent of the actual actors involved in given case instance.

Case instances in turn, are those that are focused on individuals that will actually do the work as part of case handling. To provide this required flexibility case management in jBPM comes with case role assignments that allow to provide actual actors or groups for given role. Case role assignment can be given at the time case instance is started or can be set on already active case instance.

Note: Case role assignment can be modified at any time as long as case instance is active though it will not have effect on tasks already created based on previous role assignment.

General recommendation is to always start with case role assignments when starting a case instance as this will prevent situations of assigning tasks to not the correct owners.

How does it work?

By default case instance security is enabled. It does protect each case instance from being seen by users who do not belong to a case in anyway. In other words, if you are not part of case role assignment (either assigned as user or a group member) then you won't be able to get access to the case instance.  This applies to:

• access to individual case instance 
• access to case instance details like
• case file
• case stages
• case milestones
• queries for case instances

There is one situation when the case instance security will not take any effect - it is where there are no case roles defined at all. That essentially disables the security as there is no information to base authorisation on. 

Authorisation can also be turned off by system property: org.jbpm.cases.auth.enabled when set to false.

Above access is just one part of the security for case instances. In addition, there is case instance operations that can be restricted to case roles. Here is the list of currently supported case instance operations that can be configured:

• CANCEL_CASE
• DESTROY_CASE
• REOPEN_CASE
• ADD_TASK_TO_CASE
• ADD_PROCESS_TO_CASE
• ADD_DATA
• REMOVE_DATA
• MODIFY_ROLE_ASSIGNMENT
• MODIFY_COMMENT

by default three of these operations:

• CANCEL_CASE
• DESTROY_CASE
• REOPEN_CASE

are protected with following roles:

• owner
• admin

again, these are case roles so based on case role assignments can differ between case instances. Thus allowing maximum flexibility in how to utilise them.

security for case operations is configurable via simple property file called case-authorization.properties that should be available at root of the class path upon start of the case application. Format of this file is extremely simple:

OPERATION=role1,role2,roleN

Some might say that it's too generic to have single config file for all possible case definitions but that's a way of promoting thinking about case management as domain specific and to build tailored application where single configuration for case role security is certainly enough. Moreover (as everything in jBPM) AuthorizationManager for case security is pluggable so if you need any specific handling you can just put your own piece of code to do so.

And at the end, let's see this working in Order IT hardware application, in particular how can we easily restrict access to only involved people or certain actions.

That's it folks, stay tuned and share your feedback!