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 <dean(a)basys.com>:
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
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users