We are using jBPM, the Java Business Process Model, in the PSM. We should remove it and replace it with something simpler. (We should continue to use our rules engine, Drools.)
jBPM is a large, powerful, and flexible framework. It offers the ability to have many workflows, called business processes, which it manages on behalf of the application. These workflows are supposed to be easy to modify or replace, so as to custom-fit a particular deployment of the client application without a lot of custom code. jBPM also offers the capability of providing a user interface to handle steps in the business process that require user interaction.
The way the PSM uses jBPM makes it difficult for us to benefit from the features and benefits of jBPM, while still imposing the overhead and complexity of a heavyweight framework. The PSM has a single business process, and the jump between native Java code and the jBPM-specific code makes it more difficult for developers to understand how the application works. Our experience of attempting to modify that single business process has been time-consuming and required both a higher level of expertise and more custom Java code than we’d hoped. The UI that jBPM offers does not look like the rest of the PSM, and so instead we have our own custom UI, written in Java and JSPs like the rest of the application. Finally, the way that the PSM integrates with jBPM makes it nearly impossible to upgrade jBPM to a more modern, supported version.
These problems have already had negative consequences in our development, in the form of seemingly simple changes requiring extensive work. We've tried three times to upgrade the version of jBPM we're using, and each time been unable to do so in the time we were willing to spend on it. Even small changes, like switching an input field from "EFT Vendor Number" to "Do you accept EFT? [ ] Yes [ ] No" radio buttons (#531), ended up taking longer and being more difficult than it sounds like it should be, due largely to the design decisions imposed upon the project by the integration with jBPM. Most notably, upgrading our external rules server (#385) is blocked until we remove jBPM.
Our single business process is pretty straightforward. There are essentially two parts: 1. new enrollment application submitted -> run automatic screenings -> run screening Drools rules, and 2. enrollment application approved -> make sure screening Drools rules pass -> do approval post-processing. Each of these can be done with plain Java code.
I suggest that we work backwards from the terminal nodes of the workflow, and switch those jBPM work item handlers into plain Java code, one-by-one. After switching all the work item handlers over, we can remove jBPM.
An important aspect of this plan is that the PSM remains in a working state throughout the development process. If our priorities shift, we will be able to pause development on removing jBPM, with only the cost of context-switching. Our work can be merged as we go, using our usual review process, rather than having a giant, potentially problematic switchover all at once.
This was originally proposed on the psm-dev mailing list. Since then, we have learned that jBPM does not background its work (one of the few benefits we thought we were getting from it), tried a third time to upgrade Drools and jBPM, removed the unused and unimplemented steps of the business process, and learned enough about the remaining steps to believe they should be plain Java code instead of message-driven event handlers. This issue reflects those changes.
We are using jBPM, the Java Business Process Model, in the PSM. We should remove it and replace it with something simpler. (We should continue to use our rules engine, Drools.)
jBPM is a large, powerful, and flexible framework. It offers the ability to have many workflows, called business processes, which it manages on behalf of the application. These workflows are supposed to be easy to modify or replace, so as to custom-fit a particular deployment of the client application without a lot of custom code. jBPM also offers the capability of providing a user interface to handle steps in the business process that require user interaction.
The way the PSM uses jBPM makes it difficult for us to benefit from the features and benefits of jBPM, while still imposing the overhead and complexity of a heavyweight framework. The PSM has a single business process, and the jump between native Java code and the jBPM-specific code makes it more difficult for developers to understand how the application works. Our experience of attempting to modify that single business process has been time-consuming and required both a higher level of expertise and more custom Java code than we’d hoped. The UI that jBPM offers does not look like the rest of the PSM, and so instead we have our own custom UI, written in Java and JSPs like the rest of the application. Finally, the way that the PSM integrates with jBPM makes it nearly impossible to upgrade jBPM to a more modern, supported version.
These problems have already had negative consequences in our development, in the form of seemingly simple changes requiring extensive work. We've tried three times to upgrade the version of jBPM we're using, and each time been unable to do so in the time we were willing to spend on it. Even small changes, like switching an input field from "EFT Vendor Number" to "Do you accept EFT? [ ] Yes [ ] No" radio buttons (#531), ended up taking longer and being more difficult than it sounds like it should be, due largely to the design decisions imposed upon the project by the integration with jBPM. Most notably, upgrading our external rules server (#385) is blocked until we remove jBPM.
Our single business process is pretty straightforward. There are essentially two parts: 1. new enrollment application submitted -> run automatic screenings -> run screening Drools rules, and 2. enrollment application approved -> make sure screening Drools rules pass -> do approval post-processing. Each of these can be done with plain Java code.
I suggest that we work backwards from the terminal nodes of the workflow, and switch those jBPM work item handlers into plain Java code, one-by-one. After switching all the work item handlers over, we can remove jBPM.
An important aspect of this plan is that the PSM remains in a working state throughout the development process. If our priorities shift, we will be able to pause development on removing jBPM, with only the cost of context-switching. Our work can be merged as we go, using our usual review process, rather than having a giant, potentially problematic switchover all at once.
This was originally proposed on the psm-dev mailing list. Since then, we have learned that jBPM does not background its work (one of the few benefits we thought we were getting from it), tried a third time to upgrade Drools and jBPM, removed the unused and unimplemented steps of the business process, and learned enough about the remaining steps to believe they should be plain Java code instead of message-driven event handlers. This issue reflects those changes.