Research spike: Drools & business rules interface #262
Comments
We're using jBPM 5.4, which is old and which maps to Drools 5.5. They're pretty coupled; we get Drools by way of jBPM. In a later release, Drools, Guvnor (the visual rules creation/management interface), and jBPM get combined into "Knowledge is Everything". Thus I'm looking at this guidance for KIE 7 and related documentation to understand what we need to do in order to get Guvnor, or its successor the "Drools Workbench.... a full featured web application for the visual composition of custom business rules and processes" which can be embedded into another web app. |
We currently use jBPM embedded rather than standalone and I'm not clear what the advantages of either approach are, and whether we should switch (database considerations?). Per the jBPM 6.0.1 release notes and this Stack Overflow answer, if we move up a version to jBPM 6.x then we will get into the world of KIE. "With the Drools and jBPM (KIE) 6 series came a new workbench" (I'm not clear on how this relates to this console). jBPM 7.0 includes an upgrade to WildFly 10, which is the version of WildFly we use. |
Looking a little deeper at our existing Drools files:
So the main Drools ruleset that we need to preserve or port is the screening ruleset. And since the structure of our rules is not going to change as often as the content, the boxes-and-arrows flowchart maker that Workbench provides isn't going to be very user friendly. A UI that optimizes for flexibility doesn't help the user here. Instead we should provide an interface that has more in common with the filter rules interfaces of an email application or a shopping site. We should reduce the number of choices administrators need to make by giving them dropdowns and checkboxes and so on, to help them make contextually constrained filtering rules, as GMail does in its filter settings. Even though Workbench promises us an already-built UI, UberFire (another component of KIE) gives us a framework to build our own. So we can use that. |
@brainwane thank you for this! Can you leave us a link to UberFire / an example of it in use? |
As @brainwane mentioned, we have hundreds of rules checked in to the repository as text files. These rules files are included by the build in the artifact that is deployed to the application server. We have a few options around how we can suggest states change these rules:
I started looking at upgrading jBPM earlier this week (see #267 for some of the supporting work). The short version is that it's non-trivial. There have been significant API changes; some of the APIs we're using now are deprecated, and seem to have been removed. For now, I will continue to work on upgrading jBPM. |
@cecilia-donnelly This is UberFire -- I spoke with Jason yesterday and the Guvnor approach is probably more sensible. Jason and I spent a little time yesterday thinking about whether we need to be using a rules engine; towards that end, I noted some categories that the existing rules fall into. Screening:
The validation rules include stuff that should probably be validated at some other layer, like "birthdate should not be in future", but also:
We concluded that yeah, probably we do want to do these as business rules rather than in some other layer. |
We've now done that, so I'm going to close this issue. If anyone would like to open new issues more specifically focused on the jBPM upgrade, Guvnor usage, or something else, please go ahead and feel free to link to/copy from this issue history as is useful. |
We need to get a better handle on the Drools interface for the PSM. Right now the only way to edit the validation and screening rules is for a programmer to edit
cms.validation.drl
andcms.screening.drl
inpsm-app/cms-business-process/src/main/resources/
. We need to make it so service admins can change enrollment assessment rules/workflow without having to be programmers. James & Jason have looked a little bit at this, but we need a better sense of what it is we're aiming for when we make it configurable. What should the interface be, allow, do?This issue is for me to document the current state of affairs and propose aspirations for the business rules interface for the MVP.
The text was updated successfully, but these errors were encountered: