I have a question
about rule storage and referencing with the JBRMS. Mostly this is directed to
Michael Neale (since I believe this is his baby), but since I cant catch him on
IRC I'll post it to here to see if others have this similar concern.
A little history
before I get to the question. We have been using drools since 2.x (still on 2.x)
and have developed much around the core engine. The way we currently store rules is in a
database, at runtime we pull them out and write an xml file. What this allows is
rule referencing back to the authoring source. We translate from DB->XML so
the "then" returns the ID. We also use it to create unique names for rules. In
our editor we have notes, versions and the complete rule code, similar
to the new JBRMS. When a rule fires in our system the purpose may be to
show an error or change a price. Either way sometimes people ask why did this
fire, or further, they dispute the rule all together. So in each message or
price change we track the ID of the rule being fired/applied.
From that we have
developed 2 tools, one to lookup a rule and see a great deal of info about that
rule (whats/whys), the other is an Override tool that allows you, given
authority, to associate a rule ID to a transaction and have coded so when the
engine fires this rule, it will be ignored by the system. Obviously how we
override is not something I expect you to solve, but giving me the ability by
having a unique ID would be.
I would think the
desire to "Track" and "Override" a rule is pretty high for most people using a
rule system in an enterprise. What makes this possible is exposing a unique
identifier in the storage of rules (think database and editor) as well as the
execution of rules (as they fire). I setup the MR2 of the JBRMS and tried to
look at the storage system to see if a rule had some unique identifier that we
could use, and found none. Seems like a rulebase is a blob, though maybe I'm
just looking at it wrong.
So my question
and/or request is there a way to have each rule have a unique identifier (by
version is fine) in the JBRMS storage system. I think this is the first step,
the second is harder but make the system associate the ID to a rule at execution
("then"). Similar to the option of expiring a rule at X
date.
While this may not
seem huge, and is definitely not as cool as changing semantics in
MVEL, it is a huge barrier of adopting this new very feature rich
JBRMS.
Thanks,
Michael
Rhoden