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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users