Another alternative (in addition to what Michael wrote) would be the implementation of a new parameterized operator. Assuming that you need (String) equals and not equals for a limited number of substrings, known beforehand, this isn't too difficult to implement (and I can provide an example).
This means that you could write, e.g., for the "code" in (4:7) Claim( status eq[code] 1324,... ) or, for another substring Claim( status not eq[priority] "A",... ) You could also define indivdual operators (codeEq, priorityEq,...) but this seems excessive. Maintenance is not as bad as it might appear; the class implementing the operator can access properties defining the parameter names, offsets and lengths; so it is easy to adjust for future development. As Michael wrote, all of this can be layered by a Domain Specific Language, but that's not the key issue here. -W 2010/10/20 Dean Whisnant <[email protected]>: > Hello, > > > > In designing our rules system to allow users and analysts to create and edit > rules (through Guvnor) we have a requirement that some of the fields be able > to be evaluated for specific characters in specific positions of the > string. See the following examples: > > > > Example 1: The string named “claimStatus” contains various flags all pushed > together in a string. It might look like “ABS1324BB7”. Together this field > means about nothing, but position 4-7 (1324) is an important code that they > want to evaluate. A business rule for this would be if position 4-7 in > claimStatus = “1324” then we categorize that claims for some reason. > > > > In loose java syntax I would likely use ‘if claimStatus.substring(3,4) = > “1324” then do something. > > > > I could have the user program a formula using the substring method, but that > would be quite inefficient and a lot of information for them to figure out. > > > > I could have the user say claimStatus matches ^.{4}1324.{0,} but this > regular expression is quite cryptic. > > > > While at Rulesfest I ran the topic by a couple folks there and they thought > that posing it to the community might be a good idea. Is there another way > you could see doing this? Is there a DSL format that might get us to where > we want? > > > > Ideas that have been thought of included creating a variable that is already > just the 4 characters we are after, but there are dozens of fields that > could hold this info and that would increase our data model which is already > quite verbose. We also looked at allowing them to create a variable when > they need it and then just reuse that in rules, but I’m not certain how we > would do this with as many fields. > > > > To add to it, the regular expression I listed is for one of the fields in > these streams, we also have needs to pull out other positions as well. > > > > Your thoughts and ideas on this are appreciated. > > > > Thank you! > > > > Dean Whisnant > > basys, inc. > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
