Steven,
In a quick look over your rules, I would say you have an infinite
loop in action conflic rule. You would need to do at least the shown
above to avoid it:
a: ActionEvent(status == "UNKNOWN");
After changing that, if the problem persist, can you send us a self
contained example we can run, or at least details about the facts you
are asserting and the result you are getting?
[]s
Edson
Steven Davy wrote:
Hi,
I am trying to develop algorithms to detect conflicting rules that are
application specific, but i am getting strange (or normal depending on my little
understanding) results from drools 3.
The scenario is as follows..
A user is set asserted into working memory..
assert(new User("username"))
I have a rule as follows..
rule "User Policy"
when
u: User(name = "username")
then
assert(new Permit(u, "doSomeAction"));
assert(new Deny(u, "doSomeAction"));
end
Above is a "policy" for username with a conflict as in he is both permitted and
denyed to perform an action..
further rules..
//A very simple conflict detection algorithm
rule "ModalityConflict"
salience 10;
when
p: Permit($user:user, $action:action);
d: Deny (user == $user, action == $action);
//there exists a permit and deny where the user and action are the same
then
Conflict conflict = new Conflict(p,d);
assert(conflict);
end
rule "ActionConflict"
salience 5;
//Set Action Request to Conflict
when
a: ActionEvent();
c: Conflict();
//test to see if action event triggers the found conflict
eval(c.triggeredBy(a));
then
a.setStatus("CONFLICT");
modify(a);
end
rule "ActionAllowed"
//Set Action Request to Allowed
when
a: ActionEvent($user:user, $action:action, status == "UNKNOWN");
p: Permit(user == $user, action == $action);
then
a.setStatus("ALLOWED");
modify(a);
end
rule "ActionDisallowed"
//Set Action Request to Disallowed
when
a: ActionEvent($user:user, $action:action, status == "UNKNOWN");
d: Deny(user == $user, action == $action);
then
a.setStatus("DISALLOWED");
modify(a);
end
Initially when the customer is asserted, their "Policies" are asserted into
memory, also triggering some conflict detection among these policies as in the
"modality conflict rule" A conflict is then asserted into memory awaiting to be
triggered as in "ActionConflict".
Aa ActionEvents are asserted their status is assigned "ALLOWED", "DISALLOWED",
or "CONFLICT".
My question is, when an ActionEvent is asserted, three rules are satisfied, The
permit case, the deny case and the conflict case. As conflict has a higher
priority it will be executed first setting the status of ActionEvent to
"CONFLICT" upon which the subsequent rules are canceled. This is because the
ActionEvent is not "UNKNOWN" anymore. Is this a valid assumption, i have tested
this for a single ActionEvent assertion and works great, where the status of the
ActionEvent is ultimately set to "CONFLICT".
However when i assert more then one ActionEvent, for the last ActionEvent
asserted all three rules are executed, as in it seems to ignore the modification
of its status, but when i observe execution with breakpoints, the status is
actually changed from conflict to allow to disallow ? I'm starting to think it
is a bug in the software.
Any Comments or suggestions of alternative approaches ?
Steven
