I tried adding modify() and modify(account), both are failing, can someone help me fix this. -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com.

How do I let the Drools know the changes made so the next rule has the changes. Can I use update function, can you share some links where I can I read on this. -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com.

Does update(account) causes all rules to be rerun? I don't want that, at the same time I don't want to use modify as it's not very easy to use, I have several rules that I will hve to change I like the option of coding like the following and then one function call that will notify the rule engine that this object is modified so next rule has latest changes. account.setSomeField('xxxx); account.setStatus('ssss'); account.setExpiry(xyxCalss.getExpiryDate()); NOW call a function to notify that account is changed. How can I do it? -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com.

This is a list for support of the drools product, but there is some expectation that you will figure out some basic functionality by reading the docs and putting some thought into it. :) In general, though, the "next rule" is whatever rule matches the objects currently in working memory.  If you don't want a given rule to fire you should make sure that the objects altered no longer match it after they are changed.  In your original example the Account object matched in Rule1 has no conditions on it at all, meaning any Account in working memory will be matched, so it's no wonder that it's being matched repeatedly. Also, I'm puzzled by your calls to StringUtils.equals() in the rule conditions.  Did you not try this? account : Account(accountStatus == "NEW") Again, in the docs, this is the recommended way to test object properties. ________________________________ From: kina06 <reachkn6(a)gmail.com&gt; To: rules-users(a)lists.jboss.org Sent: Tuesday, October 30, 2012 10:12 AM Subject: Re: [rules-users] Field value is different when and then section, very strange. Is it mvel vs java issue This looks like such a basic functionality and I'm not getting any help. I can't seem to understand why update function keep calling the function, is there no way to let drools know that I modifed an object values so it gives me the updated object in next rule. Please help, this is such a basic step without which I cna't proceed any further. -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Identify the requirements for changing your data. For instance, what *exactly* is the state of an Account fact x when it should be subject to x.setAccountStatus( "PENDING" ); Any value of accountStatus? All values *except* PENDING? null? ...? Make sure to constrain Account() in this and any other rule by adding the correct boolean expression between the parens. modify( x ){ set...(...), set...(...) } is the preferred way of notifying the Drools Engine that a fact has changed and all rules potentially referring to this fact need to be reconsidered; the fact's history is irrelevant. x.set...(...); x.set...(...); update( x ); is essentially the same. Using salience is (usually) the wrong approach, as is no-loop, which will avoid only on-the-spot reactivation - you can still loop over two or more rules. -W On 30 October 2012 17:39, kina06 <reachkn6(a)gmail.com&gt; wrote:

When an object is insert in the working memory, it will be matched against all rules: some of them will become active, because the logic expressed in there applies to your fact, some others will not. So, Wolfgang has pointed out an important detail: make sure that there is a strong logic correlation (implication) between the conditions in the LHS and the actions in the RHS, so that you don't execute unwanted actions. Given the fact that evaluation and execution take place in two different stages (see Esteban's email for details), a change in the object's status MAY invalidate the conditions, but the engine needs to know about that: by the time a rule is executed, it won't go back and double-check the conditions unless told so. So (citing Greg this time): if your logic is sound, and you apply modify appropriately, you should not get into a loop - or, if you do get into a loop, it's because it's "necessarily" imposed by the application logic (I'm assuming that there are other external ways to control the loop termination), for example: rule "controlled loop" when $x : X( $n : val < 10 ) then modify ($x) { setVal( $n + 1 ); } end as opposed to: rule "loop" when $x : X( $n : val ) then modify ($x) { setVal( $n + 1 ); } end rule "breaker" salience 10 when $x : X( val > 10 ) then retract( $x ); end This said, there are cases when your same fact is shared between two separate contexts: rule "One of rules dealing with age" when $p : Person( $a : age ) $b : Birthday( person == $p ) then modify ($p) { setAge( $a+1 ); } .... end rule "One of rules dealing with salary" when $p : Person( $s : salary < 100 ) then modify ($p) { setAge( $a+1 ); } .... end Here, it's not so evident which conditions should be added to prevent unwanted interaction. Or, even if you could, it would not be the best approach to mix the two business logics... In this case, there is a feature called *@propertyReactive* which I strongly invite you to look up in the manual AFTER you're feeling completely comfortable with the basic behaviour. Best Davide p.a. drools.halt is only used in combination with fireUnitlHalt(), which means that the engine will not wait for an explicit command to fire the active rules. It's a global behaviour that "shuts down" the engine, so it's not recommended for loop control. -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com.

You can stop the recursive firing by 1) having conditions in the rules that stop recursion, (similar to a stop condition in a for loop) and 2) using update or modify to tell the rules engine that the properties have changed.   ________________________________ From: kina06 <reachkn6(a)gmail.com&gt; To: rules-users(a)lists.jboss.org Sent: Tuesday, October 30, 2012 11:39 AM Subject: Re: [rules-users] Field value is different when and then section, very strange. Is it mvel vs java issue Yes I tried account : Account(accountStatus == "NEW") In above posts it's mentioned that I have to use modify or update, when use that it fires rules recursively without stopping. Will it possible to test my code, I can provide the Account class code as well it's just two fields in it. -- View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

See the "Expert" manual: modify, update, no-loop - it's all there... -W On 30/10/2012, kina06 <reachkn6(a)gmail.com&gt; wrote: