Today's common BPM trend is to centralize BPM execution across the entire company or within a large department of the company. This means that a single BPM server (cluster) runs many process definitions across the company. The challenge in this approach is that, while the BPM engine (including JBPM) provides authorization for mission access, they generally do not support the authorization of these features: process-defined viewing and deletion, process instance initiation, completion, viewing, and deletion. In this article, we will describe how to extend the JBPM engine (based on jbpm 4.3) to implement this functionality.
Overall Implementation method
The entire implementation is fairly straightforward when--for each process definition, introduce a set of authorized user/user groups (similar to task definitions) for the history of definitions, instances, and given processes. In addition, we want to support multiple authorization levels for a given user/user group--currently we intend to introduce 2 roles: "Starter" and "user". The "starter" here is a role that allows any action on the process definition/instance/history, and the "user" role is limited to query process/history.
The implementation of this approach requires the following modifications to the JBPM:
Process definition
Add process access to process definition
Process deployment
Extend the current process deployer, increase the process authorization definition and generate the process access list
Introduce additional class/database tables to store the access rights defined by each process
Process Execution (Execution)
Introduce an authorized command (Authorized command)-a command that requires a user to be authorized to execute
To modify the existing jbpm, we expect the portion of the authorization to be based on the current user certificate. This includes starting, ending, and deleting process instances, as well as deleting deployment definitions.
Modify an existing JBPM query to consider the certificate of an existing user. This includes deployment and process definition queries, process instance queries, and queries for historical process instances, activities, and details.
In addition to the above changes, we also want to extend the process instance query so that users can narrow the query results by specifying the values of some process variables. A common scenario for this kind of search is to query the "started by me" process. To ensure that this query is always available, we have changed the implementation of the START process Instance command, explicitly adding the current user ID to the collection of process variable values.
Finally, to support a variety of user authentication methods, we have implemented a custom identity session that supports the use of programs to set up and access the current user's credentials. The aim is to isolate the use of user certificates (IDs and participating groups) and the JBPM runtime for this information.
Our implementation leverages the very powerful and flexible configuration mechanism of JBPM 4, which allows us to:
By extending the existing JBPM class, you minimize the number of custom code, only the extra functionality we need to extend
Implement our extension as a separate jar package that can be used with the JBPM 4 class library without any changes to the existing libraries.
Before we dive into the details of our implementation, let's start with a discussion of the JBPM 4 configuration we use heavily.