[rules-users] JBRMS - Rule IDs/Referencing

[Michael Rhoden]

Be happy to help, it just takes a bit to understand your coding
environment and standards. My first goal is to point out the need for
exposed Rule IDs and try to understand the system the way it sits.
 
As a side note, I found a feature to "export to a zip file" under the
Admin->Manage Backups. It doesn't seem to work or maybe it just writes
the file to some default location. I did search my hard drive for any
new Zips so I guess it just doesn't work atm.
 
Thanks,
Michael Rhoden

 
 
 

  _____  

From: rules-users-bounces at lists.jboss.org
[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Mark Proctor
Sent: Friday, June 15, 2007 10:29 AM
To: Rules Users List
Subject: Re: [rules-users] JBRMS - Rule IDs/Referencing


The system is an "asset managemnt system", every item is an asset from
the rule to the package configuration. You can reference any item using
a unique name + package name +  version, each item also has a UUID
(provided by the JCR node). However we don't have any remoting/ws api
access to this info - you would have to build ontop of the programmatic
api provided in drools-repository. The versioning is multi dimensional
too - i.e. a Package configuration  is itself versioned against specific
versions of rules, if you want to update the Package to a new version of
a Rule, you must create a new version of the Package Configuration.

So it sounds like it doesn't do what you want now, but the foundations
are there and you can get involved with us and help us change that.

Mark


Michael Rhoden wrote: 

   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 
   
  _____  


   _______________________________________________
   rules-users mailing list
   rules-users at lists.jboss.org
   https://lists.jboss.org/mailman/listinfo/rules-users
     



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070615/33eb2b5c/attachment.html