[rules-users] Any API accessing to the rule logic instead of only Facts

[Sean Su]

well said, Steve. I actually have warned the stake holder here too :)

We would not do this if we can avoid the "requirement" in other ways.

Thanks for the input.

Sean


On Tue, Jul 30, 2013 at 10:35 AM, Stephen Masters <stephen.masters at me.com>wrote:

> It's a good idea to start thinking of the rules in Guvnor as source code,
> just the same as the rest of the application. Every time a rule is saved in
> Guvnor, a version is created automatically. You don't need business users
> to do any special tasks for this. Given that source code doesn't change
> every time you make a call to it, there's no benefit to logging the source
> code on every call. And there's definitely a level of performance
> degradation if you do.
>
> If you want to automate reconciling rule activations against the rules,
> then I would recommend setting up a process to store a snapshot of the
> knowledge base source being used, when the knowledge base is built or
> updated. It could use the REST interface to download the source. That way,
> if you have logged the names of rules which have activated and the time at
> which they activated, then you could build an automated reconciliation tool
> to quickly show what the source of a rule was at the time it was called.
>
> And I would emphasise that you need the source of all packages used to
> build the knowledge base, not just the source of the activated rule. Very
> often (in my experience, most of the time) you need to know why a specific
> rule *didn't* activate. As you build up the knowledge base, you will find
> that it's very rare for a single rule to be responsible for a decision.
> It's not unusual for there to be hundreds of rule activations for every
> call to a decision service. In fact, you may find that just logging
> activation names has a significant impact on your application's
> performance, even if you do use async logging, and your log files may reach
> multiple gigabytes in hours.
>
> You have been warned! ;)
>
> Steve
>
>
> On 30 Jul 2013, at 15:00, Sean Su <sean.x.su at gmail.com> wrote:
>
> Not the actual source code, but as Java developers, we do log some precise
> information in term of what is happening. When it comes to rules,
> especially the rules built using Guvnor, we do not want the rule author
> (business users) to manually add these "logs" as they are not technical
> staff. This is why there is a need to build these log information
> automatically by accessing "rule LHS" through API.
>
> Visiting rules and their histories after the rule name has been logged is
> always an option for this process. However it takes time and manual process.
>
>
> On Mon, Jul 29, 2013 at 2:21 PM, Stephen Masters <stephen.masters at me.com>wrote:
>
>> Do your other applications log the source code of the application every
>> time a call is made to it?
>>
>> It may be better to look at what Guvnor has to offer. For instance, it
>> provides version history of the rules, so that if you know the name of a
>> rule (which you get from the activation details), then for audit purposes
>> you should be able to see what that rule looked like on a particular time
>> and date.
>>
>> Steve
>>
>>
>> On 29 Jul 2013, at 19:01, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>
>> > There is no *stable* API to obtain details about the LHS from the rule
>> > in a knowledge base. Validator does access LHS patterns and
>> > constraints for analysis, but this is rather tricky unless your rules
>> > are very simple.
>> >
>> > You can obtain the rule name from the activation. It's probably easier
>> > to associate rule names with rule texts, even though such a lookup
>> > isn't in the API.
>> >
>> > -W
>> >
>> > On 29/07/2013, Sean Su <sean.x.su at gmail.com> wrote:
>> >> Does anyone know a public Drools API that we can use to access to the
>> >> actual rule logic in a structured way? Current we can use
>> >> AgendaEventListener and WorkingMemoryEventListener to access the facts
>> >> using in LHS and the objects used in RHS. But my project has some
>> special
>> >> requirements which need to access the actual rule logic on LHS for
>> auditing
>> >> and justification purpose.
>> >>
>> >> For example, if a rule is like this:
>> >>
>> >> when fact.list contains "123"
>> >> then do something.
>> >>
>> >> When this rule is fired, not only do I need to know what the fact
>> object
>> >> is, I also need to know the condition of this rule is involved a
>> "contains"
>> >> API, with value "123".
>> >>
>> >> Thanks in advance.
>> >>
>> >> Sean
>> >>
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> 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/20130730/380f1137/attachment.html