I've been thinking about this since Jaymer asked about a complex rule and have drawn on my prior life working for an advanced rules engine supplier. Prior versions of (up to V7, I think) attempted to build a rules matrix for the business rules that you created. It very quickly became complicated, but it was good for showing you the route through your business rules. Unlike linear programming it appears that AIM checks records against all the permutations of the rule checking whether both the rule and the inverse are true (based on looking at what happens in the logger). If you consider the rules engine as trying to filter a record through various options the aim should be to get that record to the action required as fast as possible. If you have any experience with writing SQL queries that check against multiple tables there is a fast way and a slow way to write a query to get the same result. A rules engine is the same. Redundancy in rules is your enemy. [code]IF BO.Att=1 AND BO.OthAtt='xyx' THEN Do Stuff ELSE IF BO.Att=1 AND Bo.OthAtt='abc' THEN Do More Stuff ELSE IF BO.Att=2 AND BO.OthAtt='pqr' THEN Something Different ELSE IF BO.Att=2 AND BO.OthAtt='lmn' THEN The Other Different Thing[/code] The above example creates a matrix of 4 rules and 2 conditions and in each of the rules the same thing is being asked multiple times. 4x2 In the above example by streaming out the rule based on BO.Att value you reduce the size of the matrix to two rules and one condition. [code]IF BO.Att=1 THEN DoTheChecksOn1 ELSE IF BO.Att=2 THEN DoTheChecksOn2[/code] If you stream records where BO.Att=1 to another sub process you then reduce the matrix at this sub process level to 2 x 1, does Att= 1? Yes or No, does Att=2? Yes or No. You then need to do the subsequent checking in a sub process that receives only the BO.Att=1 records so DoTheChecksOn1 looks like: [code]IF BO.OthAtt='xyz' THEN Do stuff ELSE IF BO.OthAtt='abc' THEN Do mores stuff[/code] Another 2x1 matrix with simple choices. You are also asking the questions once and will have less difficulty maintaining this; in the event that another test for BO.Att=1 and BO.OthAtt='efg' requires one line of code in one sub process making the matrices 2x1 + 3x1 instead of one larger process where the matrix grows from 4x2 to 5x2 The process maps for your processes will also become easier to read and a bit more useful.

[quote="Jaymer"]... and the inability to "BREAK" out of a Rule doesn't help (

Rules and Redundancy

PointsWell

I've been thinking about this since Jaymer asked about a complex rule and have drawn on my prior life working for an advanced rules engine supplier.

Prior versions of (up to V7, I think) attempted to build a rules matrix for the business rules that you created. It very quickly became complicated, but it was good for showing you the route through your business rules. Unlike linear programming it appears that AIM checks records against all the permutations of the rule checking whether both the rule and the inverse are true (based on looking at what happens in the logger).

If you consider the rules engine as trying to filter a record through various options the aim should be to get that record to the action required as fast as possible. If you have any experience with writing SQL queries that check against multiple tables there is a fast way and a slow way to write a query to get the same result. A rules engine is the same.

Redundancy in rules is your enemy.

IF BO.Att=1 AND BO.OthAtt='xyx' THEN Do Stuff ELSE
IF BO.Att=1 AND Bo.OthAtt='abc' THEN Do More Stuff ELSE
IF BO.Att=2 AND BO.OthAtt='pqr' THEN Something Different ELSE
IF BO.Att=2 AND BO.OthAtt='lmn' THEN The Other Different Thing

The above example creates a matrix of 4 rules and 2 conditions and in each of the rules the same thing is being asked multiple times. 4x2

In the above example by streaming out the rule based on BO.Att value you reduce the size of the matrix to two rules and one condition.

IF BO.Att=1 THEN DoTheChecksOn1 ELSE
IF BO.Att=2 THEN DoTheChecksOn2

If you stream records where BO.Att=1 to another sub process you then reduce the matrix at this sub process level to 2 x 1, does Att= 1? Yes or No, does Att=2? Yes or No.

You then need to do the subsequent checking in a sub process that receives only the BO.Att=1 records so DoTheChecksOn1 looks like:

IF BO.OthAtt='xyz' THEN Do stuff ELSE
IF BO.OthAtt='abc' THEN Do mores stuff

Another 2x1 matrix with simple choices.

You are also asking the questions once and will have less difficulty maintaining this; in the event that another test for BO.Att=1 and BO.OthAtt='efg' requires one line of code in one sub process making the matrices 2x1 + 3x1 instead of one larger process where the matrix grows from 4x2 to 5x2

The process maps for your processes will also become easier to read and a bit more useful.

Jaymer

k, I accept that.

The Limitation in Aware of having only 1 IF/THEN/ELSE per Rule is a pain.
... and the inability to "BREAK" out of a Rule doesn't help (

PointsWell

Jaymer wrote
... and the inability to "BREAK" out of a Rule doesn't help (

PointsWell

===Post your testing update===

I think a more representative test would be to use your complex query versus two simplified tests. The point of the two process method is simplification, which isn't being tested by doing two simple tests but with different processes. The reason I say that is because the SQL is only half of the workload, the missing bit is what AIM is doing.

For example it may require more database reads, but unless you are on a different network with latency issues or heavy traffic then these costs are not necessarily significant in the event that the AIM server is chewing up memory to formulate the complex query.

There is also the issue that the server is getting confused with too complex and repetitive business rule tests.

customaware

Probably a little off topic but this is always a concern....

I have a Time Range between 22:00 and 06:00am the following day

People normally work 18:00 to 06:00 the following day.
I need to calc the number of hours they work between the Range Hours which is obviously normally 8 hours.

But need to consider the alternatives...for example
Start at 22:00 and Finish at 03:00 ..... 5 Hours
Start at 03:00 and Finish at 06:00 ..... 3 Hours
Start at 02:00 and Finish at 05:00 ----- 2 Hours

So....using 4 distinct Rules works...

Rule 1: WS <= RS AND WE >= RE
If
TestBO.WorkTimeStart>=TestBO.HourRangeStart AND
TestBO.WorkTimeStart<TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd<=TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd>TestBO.HourRangeStart
Then
TestBO.HoursInRange=TestBO.WorkTimeEnd-TestBO.WorkTimeStart

Rule 2: WS <= RS AND WE > RS AND WE <= RE
If
TestBO.WorkTimeStart<=TestBO.HourRangeStart AND
TestBO.WorkTimeEnd>TestBO.HourRangeStart AND
TestBO.WorkTimeEnd<=TestBO.HourRangeEnd
Then
TestBO.HoursInRange=TestBO.WorkTimeEnd-TestBO.HourRangeStart

Rule 3: WS >= RS AND WS < RE AND WE >= RE
If
TestBO.WorkTimeStart>=TestBO.HourRangeStart AND
TestBO.WorkTimeStart<TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd>=TestBO.HourRangeEnd
Then
TestBO.HoursInRange=TestBO.HourRangeEnd-TestBO.WorkTimeStart

Rule 4: WS >= RS AND WS < RE AND WE <= RE AND WE > RS
If
TestBO.WorkTimeStart>=TestBO.HourRangeStart AND
TestBO.WorkTimeStart<TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd<=TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd>TestBO.HourRangeStart
Then
TestBO.HoursInRange=TestBO.WorkTimeEnd-TestBO.WorkTimeStart

Now... if I combine all into a single Rule........ the 3rd expression fails.

Rule: Combined

IF
TestBO.WorkTimeStart<=TestBO.HourRangeStart AND
TestBO.WorkTimeEnd>=TestBO.HourRangeEnd
THEN
TestBO.HoursInRange=TestBO.HourRangeEnd-TestBO.HourRangeStart

ELSE

If
TestBO.WorkTimeStart<=TestBO.HourRangeStart AND
TestBO.WorkTimeEnd>TestBO.HourRangeStart AND
TestBO.WorkTimeEnd<=TestBO.HourRangeEnd
THEN
TestBO.HoursInRange=TestBO.WorkTimeEnd-TestBO.HourRangeStart

ELSE

If
TestBO.WorkTimeStart>=TestBO.HourRangeStart AND
TestBO.WorkTimeStart<TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd>=TestBO.HourRangeEnd
THEN
TestBO.HoursInRange=TestBO.HourRangeEnd-TestBO.WorkTimeStart

ELSE

If
TestBO.WorkTimeStart>=TestBO.HourRangeStart AND
TestBO.WorkTimeStart<TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd<=TestBO.HourRangeEnd AND
TestBO.WorkTimeEnd>TestBO.HourRangeStart
THEN
TestBO.HoursInRange=TestBO.WorkTimeEnd-TestBO.WorkTimeStart

So, I am pretty sure I don't have an error in there (But it is a real possibility) but I have seen this behavior on the odd occasion before so tend to use separate rules now to be on the safe side.

PointsWell

Mark's current rules (as above) look like this: I copied and pasted this from the individual rules and it highlighted an error, as the same test is being carried out twice (the last column is identical to the first). I colour coded the steps to highlight where the same condition is being tested redundantly in multiple rules.

These can be broken down like this:

At the moment each record is being individually against all conditions, which means each record is being tested 4 times.

Inside Range Start & Inside Range End
Inside Range Start & Outside Range End
Outside Range Start & Inside Range End
Outside Range Start & Outside Range End

But this is highly redundant testing, testing Inside Range Start twice, and Outside Range Start twice. It also makes the tests more complex than they need to be, resulting in this case with 4 complex tests. The complexity becomes exponential the more possible options through the matrix.

If a decision tree approach is taken, streaming the second layer of the tree to one of two sub process, then only two tests are ever being run

The tests then become

IF Inside Range Start Then CheckEndForInsideStart  ELSE
IF Outside Range Start Then CheckEndForOutsideStart

CheckEndForInsideStart:

IF Inside Range End then WE-WS ELSE
IF Outside Range End then RE-WS

CheckEndForOutsideStart:

IF Inside Range End then WE-RS ELSE
IF Outside Range End then RE-WS

Then the processes become simpler, and every test that is run is efficient, that is to say you are not redundantly testing records against unnecessary tests and all testing ends with an outcome. There's no need for "break" code because there is only one route through the decision tree and zero redundancy.

It will also make your log files easier to read.

tford

Excellent analysis & documentation of applying your framework to Mark's example, PointWell !!

I'm curious to hear your thoughts on this, Mark.

customaware

Sean did an excellent job and certainly gave me something to think about, not so much for my exact circumstance but definitely for others in the future.

For example...and here is where I am most likely to be looking at using that thinking next.

Imagine you needed to apply a different rule for each day of a month... 1-31

IF D=1 .....
IF D=2......
IF D=3......
.
.
.
IF D=31....

Hence, 31 Rules which all have to be tested.

Sean's logic, although not precisely... a bit like a divide and conquer solution... Why test if you don't need to.

So D<=15 Go Subprocess ... then keep splitting while it makes sense
D>15 Fo Subprocess ... then keep splitting while it makes sense

Then Split again and if necessary again, whereby you reduce the number of tests down to maybe 5 rather than 31. Obviously there is a little overhead calling the subprocess but still faster than doing all the tests.

Additionally, you need to consider if the need for speed is worth the effort and if that place in your app warrants the effort.

PointsWell

I'd probably not go down that route as D=1 .. D=31 are unique rules and low complexity.