[rules-users] Drool Flow persistence Doubt
Hi Users, I am having a doubt regarding the Drools Workflow in my scenario. I want to integrate Drools Flow in my application and have some doubts regarding the persistence of Workflow process instances. Let suppose I have a workflow running in my application and at point my application crashed or i restart my application. So is their way i can restart the workflow the point it was. If i store the process instance Id in the database, so am I able to start my workflow process from where it had stopped , if it is possible can you tell me the method responsible for the same. Please help me to get through the situation. Thanks Regards Pardeep Ruhil LT Infotech Ltd Mumbai Ph: +919820283884 Larsen Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: LT Infotech Proprietary LT Infotech Confidential LT Infotech Internal Use Only LT Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. _ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Maps in Drools
Andre, The misunderstanding here is that the LHS, except for code blocks like eval, return value expressions and accumulate code blocks, are all Drools Language. When you use the dialect attribute in a rule or package you are telling the compiler what dialect (MVEL or Java) you will use inside these code blocks mentioned previously + the language for the RHS. In other words: Map( this[type] == Point, $x : this[x], size == 5 ) Everything you see in the previous expression is Drools language, does not matter if you set the dialect to java or mvel in the rule. It happens that Drools uses the same map syntax as MVEL (and a lot of other scripting languages). Also, we know, that drools implementation will resolve the first 2 above expressions in MVEL behind the scenes, and the 3rd will be resolved nativelly, but that is not something users should have to worry about, since they are writing it in Drools Language. If they write an eval, THEN they need to differentiate between MVEL and Java according to the chosen dialect. rule xyz dialect mvel when eval( ...here you write MVEL code... ) then // here you write MVEL code end rule xyz2 dialect java when eval( ...here you write JAVA code... ) then // here you write JAVA code end []s Edson 2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de Edson Tirelli schrieb: ooops... correct version: when Map( this[type] == Point, $x : this[x] ) Map( this[type] == Circle, this[x] == $x ) then end Okay, so in the mvel syntax this is possible. Can this also be achieved in the default rule syntax, without mvel? The mvel syntax needs to be interpreted at runtime, so my Clojure lib will have to output rules in Drools' native rule language. What interests me most is that first part: Map( this[type] == Point, $x : this[x] ) André -- Lisp is not dead. It’s just the URL that has changed: http://clojure.org/ ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Maps in Drools
2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de Would there not be an addition to the syntax needed, for the default rule language? For mvel it would not require a change I guess. No, as I mentioned to you, the idea is for the DRL to remain the same, so that the rules author does not have to worry about what the IT guys are doing with the domain model. So, the rules author would write: Customer( name == bob ) The IT guy would simply use a configuration to tell the engine: this object type uses a map format, that one is a POJO, that other is an XML entity, etc. For instance, if he wants to do that in DRL (he could also use API, or conf files), he could do: declare Customer @format( map ) end declare Order @format( pojo ) end So, we have a clear distinction between the technical aspects and the business aspects of the application. Your clojure macro would generate always the same DRL code Customer( name == bob ), but you said yourself that clojure is 100% java compatible, so imagine the enterprise had a domain model implemented as pojos already and as part of the new application some new entities are modeled in clojure. The macro would generate always the same code, but you would configure some entities in the domain as POJOs and other entities as Maps. Hmm, but the MVEL syntax can not magically eliminate the eval. Under the hood the map accesses will still be inside an eval. Marc confirmed that a few days ago. MVEL only hides this from the user. This is what I will also do. But under the hood it will become $a:Map() $b:Map() eval( $a.get(type) == Customer ) eval( $b.get(type) == DailyOrders ) Here I think we have other misunderstanding. I will try to explain, but ideally you need to learn a bit about the Rete algorithm to see the whole picture. There are 2 types of eval(). Inline eval() and top level eval(). What you wrote above is a top level eval, meaning it will become a node in the rete network. So your example above generates an execution plan (making an analogy with SQL) that will get all Maps in the working memory, join them in tuples size 2, and then test each tuple for the 2 evals. So, you see why this will generate C(n,2) partial matches, while C(n,2) as we know is n!/(n-2)!, what is really bad for growing n. Now, the same thing could be written using inline evals as: $a:Map( eval( $a.get(type) == Customer ) ) $b:Map( eval( $b.get(type) == DailyOrders ) ) In this case, the inline eval() will generate an alpha constraint in the network, i.e., it will be applied BEFORE the joins. So, instead of doing all combinaions possible between all maps as above, it will first find all Customer maps and all DailyOrders maps and only after that will make a join between them. So you get Customers * DailyOrders partial matches. The above evals are semantically equivalent as: $a:Map( this[ type ] == Customer ) $b:Map( this[ type ] == DailyOrders ) But currently I am forced to produce this cross product, as there is no direct support for Maps yet. I hope that by the above you see that the problem of the cross products is not a problem with Maps support, but rather a question of how to write better rules. The same way you can write 2 completely different SQL queries that return the same result but one is fast and the other is completely heavy and slow, you can also write good rules and really bad rules. []s Edson ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Extending the validation of rules functionality in Guvnor
Hi, This feature is not in the Guvnor at the moment, but I was planning to add it when I start working on GUVNOR-101. https://jira.jboss.org/jira/browse/GUVNOR-101 Toni Premkumar Stephen wrote: Hello everyone, Currently, the validate functionality ensures that rules have proper syntax. it is possible to extend this functionality so that business use cases might also be validated? Is there an API/examples to do that. For eg, in our domain, an object X can be evaluated for 3 criteria ( a, b, c ) However, we would need to prevent rules written which combine criteria b and c Rules can have the combinations ( a,b,c, ab, ac ). Combinations ( bc and abc ) should not be allowed. Regards, Prem ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Looking for attributes on an element obtained from a Map
Do Items have a UPC? Any reason why you can't insert the Items directly into working memory? Then you could do this: rule “deal finder” when SearchItem($upc : upc != null) Item(onSale == true, upc == $upc) then Buy stuff end --- On Fri, 8/21/09, Pegram, Macon zmpeg...@choosehmc.com wrote: From: Pegram, Macon zmpeg...@choosehmc.com Subject: [rules-users] Looking for attributes on an element obtained from a Map To: Rules Users List rules-users@lists.jboss.org Date: Friday, August 21, 2009, 11:47 AM I was hoping the recent conversation regarding maps this would come up, but so far it hasn’t. How do I check for conditions on the element referenced in the map? So given the following scenario: SearchItem is the item being searched for by the user Item has the attributes: UPC (String) and OnSale (Boolean) StockRoom has an attribute of stock which is Stock = HashMapString, Item (key value is UPC) Now let’s say I want to write a rule that says, “If the provided Item is in Stock, and on Sale .. purchase it” rule “deal finder” when SearchItem($upc : upc != null) // see if a UPC was provided StockRoom($stock : stock) // get a handle to the stock HashMap (this[$upc] != null) from $stock // look for the UPC in stock Item (onSale == true) from $item // Where do I obtain the reference handle that is $item? then // Buy stuff End What I’m trying to understand syntactically is how do I obtain a reference handle to the “Item” found in the HashMap reference (IE: $item) so that I can check additional attributes on that Item. I haven’t found any good examples of how to do this yet. From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 21, 2009 9:16 AM To: Rules Users List Subject: Re: [rules-users] Maps in Drools 2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de Would there not be an addition to the syntax needed, for the default rule language? For mvel it would not require a change I guess. No, as I mentioned to you, the idea is for the DRL to remain the same, so that the rules author does not have to worry about what the IT guys are doing with the domain model. So, the rules author would write: Customer( name == bob ) The IT guy would simply use a configuration to tell the engine: this object type uses a map format, that one is a POJO, that other is an XML entity, etc. For instance, if he wants to do that in DRL (he could also use API, or conf files), he could do: declare Customer @format( map ) end declare Order @format( pojo ) end So, we have a clear distinction between the technical aspects and the business aspects of the application. Your clojure macro would generate always the same DRL code Customer( name == bob ), but you said yourself that clojure is 100% java compatible, so imagine the enterprise had a domain model implemented as pojos already and as part of the new application some new entities are modeled in clojure. The macro would generate always the same code, but you would configure some entities in the domain as POJOs and other entities as Maps. Hmm, but the MVEL syntax can not magically eliminate the eval. Under the hood the map accesses will still be inside an eval. Marc confirmed that a few days ago. MVEL only hides this from the user. This is what I will also do. But under the hood it will become $a:Map() $b:Map() eval( $a.get(type) == Customer ) eval( $b.get(type) == DailyOrders ) Here I think we have other misunderstanding. I will try to explain, but ideally you need to learn a bit about the Rete algorithm to see the whole picture. There are 2 types of eval(). Inline eval() and top level eval(). What you wrote above is a top level eval, meaning it will become a node in the rete network. So your example above generates an execution plan (making an analogy with SQL) that will get all Maps in the working memory, join them in tuples size 2, and then test each tuple for the 2 evals. So, you see why this will generate C(n,2) partial matches, while C(n,2) as we know is n!/(n-2)!, what is really bad for growing n. Now, the same thing could be written using inline evals as: $a:Map( eval( $a.get(type) == Customer ) ) $b:Map( eval( $b.get(type) == DailyOrders ) ) In this case, the inline eval() will generate an alpha constraint in the network, i.e., it will be applied BEFORE the joins. So, instead of doing all combinaions possible between all maps
Re: [rules-users] Looking for attributes on an element obtainedfrom a Map
The example below was a contrived one for the purposes of asking the question. What you've proposed is definitely the right way to do things. I realize accessing items from a map in the manner I'm inquiring about is a little contrary to best practices with Drools. However, I would like to understand the syntax for doing what I inquired about for those edge cases where it is needed. Thanks! -Original Message- From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Greg Barton Sent: Friday, August 21, 2009 2:10 PM To: Rules Users List Subject: Re: [rules-users] Looking for attributes on an element obtainedfrom a Map Do Items have a UPC? Any reason why you can't insert the Items directly into working memory? Then you could do this: rule deal finder when SearchItem($upc : upc != null) Item(onSale == true, upc == $upc) then Buy stuff end --- On Fri, 8/21/09, Pegram, Macon zmpeg...@choosehmc.com wrote: From: Pegram, Macon zmpeg...@choosehmc.com Subject: [rules-users] Looking for attributes on an element obtained from a Map To: Rules Users List rules-users@lists.jboss.org Date: Friday, August 21, 2009, 11:47 AM I was hoping the recent conversation regarding maps this would come up, but so far it hasn't. How do I check for conditions on the element referenced in the map? So given the following scenario: SearchItem is the item being searched for by the user Item has the attributes: UPC (String) and OnSale (Boolean) StockRoom has an attribute of stock which is Stock = HashMapString, Item (key value is UPC) Now let's say I want to write a rule that says, If the provided Item is in Stock, and on Sale .. purchase it rule deal finder when SearchItem($upc : upc != null) // see if a UPC was provided StockRoom($stock : stock) // get a handle to the stock HashMap (this[$upc] != null) from $stock // look for the UPC in stock Item (onSale == true) from $item // Where do I obtain the reference handle that is $item? then // Buy stuff End What I'm trying to understand syntactically is how do I obtain a reference handle to the Item found in the HashMap reference (IE: $item) so that I can check additional attributes on that Item. I haven't found any good examples of how to do this yet. From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 21, 2009 9:16 AM To: Rules Users List Subject: Re: [rules-users] Maps in Drools 2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de Would there not be an addition to the syntax needed, for the default rule language? For mvel it would not require a change I guess. No, as I mentioned to you, the idea is for the DRL to remain the same, so that the rules author does not have to worry about what the IT guys are doing with the domain model. So, the rules author would write: Customer( name == bob ) The IT guy would simply use a configuration to tell the engine: this object type uses a map format, that one is a POJO, that other is an XML entity, etc. For instance, if he wants to do that in DRL (he could also use API, or conf files), he could do: declare Customer @format( map ) end declare Order @format( pojo ) end So, we have a clear distinction between the technical aspects and the business aspects of the application. Your clojure macro would generate always the same DRL code Customer( name == bob ), but you said yourself that clojure is 100% java compatible, so imagine the enterprise had a domain model implemented as pojos already and as part of the new application some new entities are modeled in clojure. The macro would generate always the same code, but you would configure some entities in the domain as POJOs and other entities as Maps. Hmm, but the MVEL syntax can not magically eliminate the eval. Under the hood the map accesses will still be inside an eval. Marc confirmed that a few days ago. MVEL only hides this from the user. This is what I will also do. But under the hood it will become $a:Map() $b:Map() eval( $a.get(type) == Customer ) eval( $b.get(type) == DailyOrders ) Here I think we have other misunderstanding. I will try to explain, but ideally you need to learn a bit about the Rete algorithm to see the whole picture. There are 2 types of eval(). Inline eval() and top level eval(). What you wrote above is a top level eval, meaning it will become a node in the rete network. So your example above
Re: [rules-users] Maps in Drools
Edson Tirelli schrieb: Andre, The misunderstanding here is that the LHS, except for code blocks like eval, return value expressions and accumulate code blocks, are all Drools Language. When you use the dialect attribute in a rule or package you are telling the compiler what dialect (MVEL or Java) you will use inside these code blocks mentioned previously + the language for the RHS. Good that you clear that up, thanks. In other words: Map( this[type] == Point, $x : this[x], size == 5 ) I thought this is only possible when one declares the dialect MVEL. Now I understand that what you just wrote also results in a valid rule, even when MVEL is not set. In your code above you: 1. check if this.get(type).equals(Point) 2. you set $x to the value of this.get(x) 3. check if this.size == 5 where I interpret 3. as calling the size() method of java.util.Map. Was that right so far? Everything you see in the previous expression is Drools language, does not matter if you set the dialect to java or mvel in the rule. It happens that Drools uses the same map syntax as MVEL (and a lot of other scripting languages). Also, we know, that drools implementation will resolve the first 2 above expressions in MVEL behind the scenes, and the 3rd will be resolved nativelly, but that is not something users should have to worry about, since they are writing it in Drools Language. Yes, I understand. Only with the middle part I still have some problems. As you used it, $x : this[x] it works for me. A minor issue I have with this, but we can ignore that for now, is, that this will be interpreted. The real problem for me is: it only works when between the brackets there is a literal string. I however can't do that, because my lib should support the general case, where between the brackets there could be any type of object (which I would pass in via a global var). If they write an eval, THEN they need to differentiate between MVEL and Java according to the chosen dialect. rule xyz dialect mvel when eval( ...here you write MVEL code... ) then // here you write MVEL code end rule xyz2 dialect java when eval( ...here you write JAVA code... ) then // here you write JAVA code end Very good, thanks again for clearing this up. André -- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Maps in Drools
Edson Tirelli schrieb: 2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de mailto:address.good.until.2009.dec...@justmail.de Would there not be an addition to the syntax needed, for the default rule language? For mvel it would not require a change I guess. No, as I mentioned to you, the idea is for the DRL to remain the same, so that the rules author does not have to worry about what the IT guys are doing with the domain model. So, the rules author would write: Customer( name == bob ) The IT guy would simply use a configuration to tell the engine: this object type uses a map format, that one is a POJO, that other is an XML entity, etc. For instance, if he wants to do that in DRL (he could also use API, or conf files), he could do: declare Customer @format( map ) end declare Order @format( pojo ) end So, we have a clear distinction between the technical aspects and the business aspects of the application. Ah okay, that makes sense and sounds very good! So, when Maps become first class not the rules will introduce a new syntax, but intead we would add some declarations. The only two challenges I see with that is: 1. to allow the keys to be any object and not just only strings. 2. differentiate between fields of the Maps and keys Point 1.: Your example Customer( name == bob ) currently is expressed as: $m : Map(eval($m.get(type == Customer)) eval($m.get(name) == bob)) right? In the declaration for Customer above one would probably have to specify that for a Map being a Customer depends on the key type. But what would Customer( name == bob ) look like if name was not a String but some other Object? This info should go into the declare part, yes? Point 2.: in your other reply you gave the example: Map( this[type] == Point, $x : this[x], size == 5 ) Projected on the Customer( name == bob ) example we would need to differentiate, in Java terms, between: map.get(size) == 5and map.size() == 5 So Customer(name==Bob size==5) needs to be clear. Your clojure macro would generate always the same DRL code Customer( name == bob ), but you said yourself that clojure is 100% java compatible, so imagine the enterprise had a domain model implemented as pojos already and as part of the new application some new entities are modeled in clojure. The macro would generate always the same code, but you would configure some entities in the domain as POJOs and other entities as Maps. Yes, it would be similar like that. What I first do is to write a general macro named rule which should be able to express everything that currently is possible in Drools. On top of that macro I will define some more, for exmaple there could be a macro map-rule which is specialized on maps. This can get even more specialized, but in the end all those macros will expand into the general one, and the general one will generate a string S which contains all rules and then do a ResourceFactory.newByteArrayResource(S.getBytes(utf-8)) to get the rules into Drools, which will from then on continue. And the way as you suggest it, to let the Drools syntax always be the same, it may even be easier for me to write my lib. Good :) Hmm, but the MVEL syntax can not magically eliminate the eval. Under the hood the map accesses will still be inside an eval. Marc confirmed that a few days ago. MVEL only hides this from the user. This is what I will also do. But under the hood it will become $a:Map() $b:Map() eval( $a.get(type) == Customer ) eval( $b.get(type) == DailyOrders ) Here I think we have other misunderstanding. I will try to explain, but ideally you need to learn a bit about the Rete algorithm to see the whole picture. Yes, I will read soon (I hope) Chapter 12 of my Drools book, by Michal Bali. There are 2 types of eval(). Inline eval() and top level eval(). Ah, I see, I didn't know that. What you wrote above is a top level eval, meaning it will become a node in the rete network. So your example above generates an execution plan (making an analogy with SQL) that will get all Maps in the working memory, join them in tuples size 2, and then test each tuple for the 2 evals. So, you see why this will generate C(n,2) partial matches, while C(n,2) as we know is n!/(n-2)!, what is really bad for growing n. Very good, now I understand what you mean. Thanks for the sql analogy. Now, the same thing could be written using inline evals as: $a:Map( eval( $a.get(type) == Customer ) ) $b:Map( eval( $b.get(type) == DailyOrders ) ) Excellent, this is very helpful. I just tried this out and was also successful with it. Now I can have my code generating alpha constraints without having to use MVEL. In this case, the inline eval() will generate an alpha constraint in the network, i.e., it will be applied BEFORE the joins. So, instead of doing all
Re: [rules-users] Looking for attributes on an element obtainedfroma Map
Ok.. Think I've answered my own question.. (Just looking for confirmation at this point). Looks like it's: rule deal finder when SearchItem($upc : upc != null) // see if a UPC was provided StockRoom($stock : stock) // get a handle to the stock HashMap ($item : this[$upc] != null) from $stock Item (onSale == true) from $item then // Buy stuff End -Original Message- From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Pegram, Macon Sent: Friday, August 21, 2009 2:15 PM To: Rules Users List Subject: Re: [rules-users] Looking for attributes on an element obtainedfroma Map The example below was a contrived one for the purposes of asking the question. What you've proposed is definitely the right way to do things. I realize accessing items from a map in the manner I'm inquiring about is a little contrary to best practices with Drools. However, I would like to understand the syntax for doing what I inquired about for those edge cases where it is needed. Thanks! -Original Message- From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Greg Barton Sent: Friday, August 21, 2009 2:10 PM To: Rules Users List Subject: Re: [rules-users] Looking for attributes on an element obtainedfrom a Map Do Items have a UPC? Any reason why you can't insert the Items directly into working memory? Then you could do this: rule deal finder when SearchItem($upc : upc != null) Item(onSale == true, upc == $upc) then Buy stuff end --- On Fri, 8/21/09, Pegram, Macon zmpeg...@choosehmc.com wrote: From: Pegram, Macon zmpeg...@choosehmc.com Subject: [rules-users] Looking for attributes on an element obtained from a Map To: Rules Users List rules-users@lists.jboss.org Date: Friday, August 21, 2009, 11:47 AM I was hoping the recent conversation regarding maps this would come up, but so far it hasn't. How do I check for conditions on the element referenced in the map? So given the following scenario: SearchItem is the item being searched for by the user Item has the attributes: UPC (String) and OnSale (Boolean) StockRoom has an attribute of stock which is Stock = HashMapString, Item (key value is UPC) Now let's say I want to write a rule that says, If the provided Item is in Stock, and on Sale .. purchase it rule deal finder when SearchItem($upc : upc != null) // see if a UPC was provided StockRoom($stock : stock) // get a handle to the stock HashMap (this[$upc] != null) from $stock // look for the UPC in stock Item (onSale == true) from $item // Where do I obtain the reference handle that is $item? then // Buy stuff End What I'm trying to understand syntactically is how do I obtain a reference handle to the Item found in the HashMap reference (IE: $item) so that I can check additional attributes on that Item. I haven't found any good examples of how to do this yet. From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 21, 2009 9:16 AM To: Rules Users List Subject: Re: [rules-users] Maps in Drools 2009/8/20 André Thieme address.good.until.2009.dec...@justmail.de Would there not be an addition to the syntax needed, for the default rule language? For mvel it would not require a change I guess. No, as I mentioned to you, the idea is for the DRL to remain the same, so that the rules author does not have to worry about what the IT guys are doing with the domain model. So, the rules author would write: Customer( name == bob ) The IT guy would simply use a configuration to tell the engine: this object type uses a map format, that one is a POJO, that other is an XML entity, etc. For instance, if he wants to do that in DRL (he could also use API, or conf files), he could do: declare Customer @format( map ) end declare Order @format( pojo ) end So, we have a clear distinction between the technical aspects and the business aspects of the application. Your clojure macro would generate always the same DRL code Customer( name == bob ), but you said yourself that clojure is 100% java compatible, so imagine the enterprise had a domain model implemented as pojos already and as part of the new application some new entities are modeled in clojure. The macro would generate always the same code, but you would configure some entities in the domain as POJOs and other entities as Maps. Hmm, but the MVEL syntax can not magically eliminate the eval. Under the
[rules-users] populating global variable in Condition Section?
Hi, Is it possible to populate a global variable in the condition section of the drool rule, and use it later in the condition itself? I currently have a global HashSet variable that I construct before firing the rule, but I would like this code of constructing this global variable to be with the drool rule itself. Any help on this would be much appreciated. Thanks Malay -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] populating global variable in Condition Section?
This is a galactically bad idea. Using a global in this way is inherently unsafe as there's no guarantee that ebtween the time you set the var and when it's used later in the condition that the value is the same. What is your reason for wanting to use a global in this way? You should use a temporary bound variable instead. --- On Fri, 8/21/09, Shah, Malay malay.s...@morganstanley.com wrote: From: Shah, Malay malay.s...@morganstanley.com Subject: [rules-users] populating global variable in Condition Section? To: rules-users@lists.jboss.org Date: Friday, August 21, 2009, 3:19 PM Hi, Is it possible to populate a global variable in the condition section of the drool rule, and use it later in the condition itself? I currently have a global HashSet variable that I construct before firing the rule, but I would like this code of constructing this global variable to be with the drool rule itself. Any help on this would be much appreciated. Thanks Malay NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] populating global variable in Condition Section?
May be I have not put the question right. We have a drool rule that is running extremely slow for large sets of data. The rule is something like: For every object A, perform action if there does not exist an object B such that A.id = B.id. And the corresponding drool rule is as follows: when A() not(exists B(A.id = id)) then action.. The performance is bad because of not exists clause here. We have got OOM exceptions with relatively large amounts of data for this rule. To improve performance, we basically hacked the rule/code into something like this: Create a global variable x that is a HashSet of all ids of object A, and the drool rule now is: global java.util.HashSet x; when B() eval ( ! (x.contains(b.id) ) ) then action. This obviously is performing much better with hashes involved. But, I don't like the fact that we have to write the logic of this rule at two places. I would rather create this variable x (don't care whether it is global or temporarily bound) in the rule itself and use it in the condition to help performance and have all logic for the rule at one place. Is there a way to generate this hashset x in the condition part of the rule itself? Yes, I understand that I am trying to mix up the procedural part of code with drool code. But, I was just wondering if this is possible to keep the java code clean and have the intelligence of information that the rule needs to be evaluated in the rule itself. Hope this clears some doubts. Thanks Malay Shah -Original Message- From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Greg Barton Sent: Friday, August 21, 2009 4:44 PM To: Rules Users List Subject: Re: [rules-users] populating global variable in Condition Section? This is a galactically bad idea. Using a global in this way is inherently unsafe as there's no guarantee that ebtween the time you set the var and when it's used later in the condition that the value is the same. What is your reason for wanting to use a global in this way? You should use a temporary bound variable instead. --- On Fri, 8/21/09, Shah, Malay malay.s...@morganstanley.com wrote: From: Shah, Malay malay.s...@morganstanley.com Subject: [rules-users] populating global variable in Condition Section? To: rules-users@lists.jboss.org Date: Friday, August 21, 2009, 3:19 PM Hi, Is it possible to populate a global variable in the condition section of the drool rule, and use it later in the condition itself? I currently have a global HashSet variable that I construct before firing the rule, but I would like this code of constructing this global variable to be with the drool rule itself. Any help on this would be much appreciated. Thanks Malay NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] populating global variable in Condition Section?
quote It is rather common for people to write something like (not (exists (A))), but this is just a very inefficient way to write (not (A)). /quote Kudos to Ernest Friedman-Hill to put this sentence into the Jess documentation. Maybe I should quote hiom in the Drools Expert doc ;-) -W On Fri, Aug 21, 2009 at 11:11 PM, Shah, Malay malay.s...@morganstanley.comwrote: May be I have not put the question right. We have a drool rule that is running extremely slow for large sets of data. The rule is something like: For every object A, perform action if there does not exist an object B such that A.id = B.id. And the corresponding drool rule is as follows: when A() not(exists B(A.id = id)) then action.. The performance is bad because of not exists clause here. We have got OOM exceptions with relatively large amounts of data for this rule. To improve performance, we basically hacked the rule/code into something like this: Create a global variable x that is a HashSet of all ids of object A, and the drool rule now is: global java.util.HashSet x; when B() eval ( ! (x.contains(b.id) ) ) then action. This obviously is performing much better with hashes involved. But, I don't like the fact that we have to write the logic of this rule at two places. I would rather create this variable x (don't care whether it is global or temporarily bound) in the rule itself and use it in the condition to help performance and have all logic for the rule at one place. Is there a way to generate this hashset x in the condition part of the rule itself? Yes, I understand that I am trying to mix up the procedural part of code with drool code. But, I was just wondering if this is possible to keep the java code clean and have the intelligence of information that the rule needs to be evaluated in the rule itself. Hope this clears some doubts. Thanks Malay Shah -Original Message- From: rules-users-boun...@lists.jboss.org [mailto: rules-users-boun...@lists.jboss.org] On Behalf Of Greg Barton Sent: Friday, August 21, 2009 4:44 PM To: Rules Users List Subject: Re: [rules-users] populating global variable in Condition Section? This is a galactically bad idea. Using a global in this way is inherently unsafe as there's no guarantee that ebtween the time you set the var and when it's used later in the condition that the value is the same. What is your reason for wanting to use a global in this way? You should use a temporary bound variable instead. --- On Fri, 8/21/09, Shah, Malay malay.s...@morganstanley.com wrote: From: Shah, Malay malay.s...@morganstanley.com Subject: [rules-users] populating global variable in Condition Section? To: rules-users@lists.jboss.org Date: Friday, August 21, 2009, 3:19 PM Hi, Is it possible to populate a global variable in the condition section of the drool rule, and use it later in the condition itself? I currently have a global HashSet variable that I construct before firing the rule, but I would like this code of constructing this global variable to be with the drool rule itself. Any help on this would be much appreciated. Thanks Malay NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drool Flow persistence Doubt
All running process instances are always stored persistently after their state has been changed, and they can be reloaded from the database if they are no longer in memory. So whenever the application needs to be restarted, you must restore the session (either creating a new one or reloading it using the unique session id). Execution will then continue as before. For example, if a user then completes a task that was requested by a specific process instance, the engine will automatically know that that user task was related to that specific process instance and reload its previous state from the database. So, as long as you make sure that the session is restarted, all process instances will continue from the state they were at before without you having to do anything. Kris Quoting pardeep.ru...@lntinfotech.com: Hi Users, I am having a doubt regarding the Drools Workflow in my scenario. I want to integrate Drools Flow in my application and have some doubts regarding the persistence of Workflow process instances. Let suppose I have a workflow running in my application and at point my application crashed or i restart my application. So is their way i can restart the workflow the point it was. If i store the process instance Id in the database, so am I able to start my workflow process from where it had stopped , if it is possible can you tell me the method responsible for the same. Please help me to get through the situation. Thanks Regards Pardeep Ruhil LT Infotech Ltd Mumbai Ph: +919820283884 Larsen Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: LT Infotech Proprietary LT Infotech Confidential LT Infotech Internal Use Only LT Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Cannot view Process Definitions in gwt-console
Because the gwt-console does not allow you to specify which knowledge
package should be loaded (yet), it currently uses the default package.
Putting your rule flow in a package called default (and then building
that package in Guvnor) should solve your issue I think. You could also
change the name of the package to load in the changeset.xml file in
drools-gwt-console.
Kris
Quoting rbms r...@hotmail.com:
I am trying to deploy drools-guvnor, gwt-console in Tomcat.
I am using mysql for persistence.
I uploaded the process definitions in drools-guvnor.(I can see them
Packages
-- defaultPackage -- RuleFlows)
However when I try to view them in Processes -- Process Definitions
--
Definition List, I cannot see them.
Following is from tomcat server log.(with debugging statements that
I
added.)
I placed debug statements in
org.drools.guvnor.server.files.PackageDeploymentServlet.doGet method.
This
method calls
org.drools.guvnor.server.files.FileManagerUtils.loadBinaryPackage
method.
//Following is the debug statement that I placed in
org.drools.guvnor.server.files.FileManagerUtils.loadBinaryPackage
method.
public String loadBinaryPackage(String packageName,
String packageVersion,
boolean isLatest,
OutputStream out) throws
IOException {
PackageItem item = null;
if ( isLatest ) {
item = repository.loadPackage( packageName );
System.out.println(FileManagerUtils.loadBinaryPackage() ...);
AssetItemIterator ai = item.queryAssets(drools:format='rf',
false);
for (;ai.hasNext();) {
Object o = ai.next();
System.out.println(FileManagerUtils.loadBinaryPackage item
=
+
o.getClass() +:+o);
System.out.println(*);
}
As you can see the servlet returns the rule flow.
I also placed some debug statements in
org.drools.rule.Package.readExternal
method. As you can see when it comes to this method rule flow is
empty.
Because of this
org.drools.integration.console.DroolsFlowCommandDelegate.getProcesses()
function returns 0 process definitions.
Can somebody help?
[2009:08:231 22:08:625:debug] KnowledgeAgent rebuilding KnowledgeBase
using
ChangeSet
[2009:08:231 22:08:625:debug] KnowledgeAgent building
resource=[UrlResource
path='http://localhost:8081/drools-guvnor/org.drools.guvnor.Guvnor/package/defaultPackage/LATEST']
PackageName: defaultPackage
//org.drools.guvnor.server.files.PackageDeploymentServlet.doGet -
Begin
PackageVersion: LATEST
PackageIsLatest: true
PackageIsSource: false
requestURI:
/drools-guvnor/org.drools.guvnor.Guvnor/package/defaultPackage/LATEST
test:
/drools-guvnor/org.drools.guvnor.Guvnor/package/defaultPackage/LATEST
//org.drools.guvnor.server.files.PackageDeploymentServlet.doGet -
End
FileManagerUtils.loadBinaryPackage() ... //
org.drools.guvnor.server.files.FileManagerUtils.loadBinaryPackage -
Begin
FileManagerUtils.loadBinaryPackage item = class
org.drools.repository.AssetItem:Content of rule item named 'testRF':
Content: ?xml version=1.0 encoding=UTF-8?
process xmlns=http://drools.org/drools-5.0/process;
xmlns:xs=http://www.w3.org/2001/XMLSchema-instance;
xs:schemaLocation=http://drools.org/drools-5.0/process
drools-processes-5.0.xsd
type=RuleFlow name=ProjectApprovalProcess
id=ProjectApprovalProcess package-name=defaultPackage
header
variables
variable name=project
type
name=org.drools.process.core.datatype.impl.type.ObjectDataType
className=com.yesVin.workflow.project.Project /
/variable
variable name=status
type
name=org.drools.process.core.datatype.impl.type.StringDataType /
/variable
/variables
/header
nodes
start id=1 name=Start x=15 y=11 width=80 height=40
/
end id=2 name=End x=206 y=442 width=80 height=40 /
humanTask id=3 name=Review Project x=126 y=12
width=80
height=40
..
...
.
..
//org.drools.guvnor.server.files.FileManagerUtils.loadBinaryPackage
-
End
Package.readExternal isDroolsStream = true //
org.drools.rule.Package.readExternal - Begin
Package.readExternal pkg = null
dialectRuntimeRegistry =
org.drools.rule.dialectruntimeregis...@198046
name = defaultPackage
imports =
{defaultpackage.*=org.drools.rule.importdeclarat...@d75e0360}
staticImports = []
functions = {}
factTemplates = {}
ruleFlows = {}
globals = {}
valid = true
rules = {}
classFieldAccessorStore =
org.drools.base.classfieldaccessorst...@34b350
//org.drools.rule.Package.readExternal - End
--
View this message in context:
http://www.nabble.com/Cannot-view-Process-Definitions-in-gwt-console-tp25056005p25056005.html
Sent from the
Re: [rules-users] populating global variable in Condition Section?
Of course, I had to test that assertion. :) $ java -Xmx128M -server -jar target/DroolsExistence-1.0.jar not.drl 5 25000 2395ms $ java -Xmx1024M -server -jar target/DroolsExistence-1.0.jar not_exists.drl 5 25000 121378ms You ain't kiddin'! 50x slower requiring 9x the memory. --- On Fri, 8/21/09, Wolfgang Laun wolfgang.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] populating global variable in Condition Section? To: Rules Users List rules-users@lists.jboss.org Date: Friday, August 21, 2009, 4:54 PM quote It is rather common for people to write something like (not (exists (A))), but this is just a very inefficient way to write (not (A)). /quote Kudos to Ernest Friedman-Hill to put this sentence into the Jess documentation. Maybe I should quote hiom in the Drools Expert doc ;-) -W On Fri, Aug 21, 2009 at 11:11 PM, Shah, Malay malay.s...@morganstanley.com wrote: May be I have not put the question right. We have a drool rule that is running extremely slow for large sets of data. The rule is something like: For every object A, perform action if there does not exist an object B such that A.id = B.id. And the corresponding drool rule is as follows: when A() not(exists B(A.id = id)) then action.. The performance is bad because of not exists clause here. We have got OOM exceptions with relatively large amounts of data for this rule. To improve performance, we basically hacked the rule/code into something like this: Create a global variable x that is a HashSet of all ids of object A, and the drool rule now is: global java.util.HashSet x; when B() eval ( ! (x.contains(b.id) ) ) then action. This obviously is performing much better with hashes involved. But, I don't like the fact that we have to write the logic of this rule at two places. I would rather create this variable x (don't care whether it is global or temporarily bound) in the rule itself and use it in the condition to help performance and have all logic for the rule at one place. Is there a way to generate this hashset x in the condition part of the rule itself? Yes, I understand that I am trying to mix up the procedural part of code with drool code. But, I was just wondering if this is possible to keep the java code clean and have the intelligence of information that the rule needs to be evaluated in the rule itself. Hope this clears some doubts. Thanks Malay Shah -Original Message- From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Greg Barton Sent: Friday, August 21, 2009 4:44 PM To: Rules Users List Subject: Re: [rules-users] populating global variable in Condition Section? This is a galactically bad idea. Using a global in this way is inherently unsafe as there's no guarantee that ebtween the time you set the var and when it's used later in the condition that the value is the same. What is your reason for wanting to use a global in this way? You should use a temporary bound variable instead. --- On Fri, 8/21/09, Shah, Malay malay.s...@morganstanley.com wrote: From: Shah, Malay malay.s...@morganstanley.com Subject: [rules-users] populating global variable in Condition Section? To: rules-users@lists.jboss.org Date: Friday, August 21, 2009, 3:19 PM Hi, Is it possible to populate a global variable in the condition section of the drool rule, and use it later in the condition itself? I currently have a global HashSet variable that I construct before firing the rule, but I would like this code of constructing this global variable to be with the drool rule itself. Any help on this would be much appreciated. Thanks Malay NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this
