Complex Rule will not execute correctly

here is 1 rule in a process. it gets tmplots passed in via Context.
Its pretty simple... the Type field can be L, S, or B. And LotNum either has a value or not.
The logger output is insane - there's no way to follow/trace 1 iteration thru the rule (soooo complex).
All I know is the result is not correct.

IF tmpLots.Type='L' AND tmpLots.LotNum IS DEFINED 	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF tmpLots.Type='L' AND tmpLots.LotNum IS UNDEFINED 	THEN 
		tmpLots.msg=`<span class='tmp2'>error: Lot # missing</span>`
ELSE

IF tmpLots.Type='S' AND tmpLots.SerialNum IS DEFINED 	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF tmpLots.Type='S' AND tmpLots.SerialNum IS UNDEFINED 	THEN 
		tmpLots.msg=`<span class='tmp2'>error: Needs Serial #</span>`
ELSE

IF tmpLots.Type='B' AND (tmpLots.LotNum IS DEFINED AND tmpLots.SerialNum IS DEFINED)	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF tmpLots.Type='B' AND (tmpLots.LotNum IS UNDEFINED OR tmpLots.SerialNum IS UNDEFINED)	THEN
		tmpLots.msg=`<span class='tmp2'>error: BOTH Lots # and Serial required</span>`

I made a simple change (see pic) and have them as 3 separate IF rules and it worked correctly first time.

Only problem is execution time, because if Rule 1 (of 3) was the one that executed, there's no way to "BREAK" out of the Process (a wishlist item of mine) so it continues to UNNECESSARILY test Rule 2 and Rule 3. This is why I tried it in 1 rule and you'd think that after 1 IF was found true, it wouldn't continue to evaluate all the following conditions (which again, would be unnecessary). But that didn't work, so 3 rules is where I end up.

FYI

I would change the first rule to be very simple

IF tmpLots.Type='L' THEN SubprocessL ELSE
IF tmpLots.Type='S' THEN SubprocessS ELSE
IF tmpLots.Type='B' THEN SubprocessB 

SubprocessL:

IF tmpLots.LotNum IS DEFINED 	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF tmpLots.LotNum IS UNDEFINED 	THEN 
		tmpLots.msg=`<span class='tmp2'>error: Lot # missing</span>`

SubprocessS:

IF  tmpLots.SerialNum IS DEFINED 	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF tmpLots.SerialNum IS UNDEFINED 	THEN 
		tmpLots.msg=`<span class='tmp2'>error: Needs Serial #</span>`

SubprocessB:

IF  (tmpLots.LotNum IS DEFINED AND tmpLots.SerialNum IS DEFINED)	THEN 
		tmpLots.OKtoPostYN ='Yes'
		tmpLots.msg=`<span class='fa fa-check w3-icongreen'></span>`
ELSE
IF (tmpLots.LotNum IS UNDEFINED OR tmpLots.SerialNum IS UNDEFINED)	THEN
		tmpLots.msg=`<span class='tmp2'>error: BOTH Lots # and Serial required</span>`

That way the minimum number of rules are being checked at any time.

yes, thats better - tho I hate to do 3 MORE processes.

but don't you think Aware should be able to handle the original "combined" IF/THEN?
Is that a deficiency, bug, limitation?
Almost any other language could handle that easily... 6 IF/THEN/ELSEs

Jaymer wrote

yes, thats better - tho I hate to do 3 MORE processes.

but don't you think Aware should be able to handle the original "combined" IF/THEN?
Is that a deficiency, bug, limitation?
Almost any other language could handle that easily... 6 IF/THEN/ELSEs

I don't see it as a bug, it is consistent of a rules based model as opposed to linear programming language. If you make the rule too long then the time to check the rule increases.

I used to work for a company that sold a similar rules engine, in that tool we always advised client that they wanted to strip down rules to the smallest data sets as quickly as possible. In your case if you have 1000 records to test then those 1000 records are going to go through the whole rule matrix every time. In your case that is 6 rules with minimum of 2 comparisons per rule. 6 IF branches *1000 records *2 condition checks =12,000 steps and checks (I'm averaging down to two IF X and Y Then conditions (Rough metric - it's probably worse as there are OR statements in there)

AIM allows you to build a decision tree with each If statement being a branch the end of the branch being an action. The faster you can get to an action the better. The fastest way is to filter the data to the action you want to occur rather than checking every condition.

With the sub process route you have minimised it to 3 rule steps each and have reduced the number of conditions being tested by 1 because you've pre-filtered to only L, S or B records. 3 IF Branches *1000 records *1 IF X condition=3000

Simplicity is your friend in rules engines and I tend to feel that if there are more than 5 rules in a process or sub process then I have made it too complicated.

I've had this before- wasted a lot of time on it. Seems more than 3 ELSE IF statements and the ones further down the line get ignored. If you change up the order of your ELSE IFs then you should see that the top few will trigger.

To me this is a bug, just never got to posting it.

idpSteve wrote

I've had this before- wasted a lot of time on it. Seems more than 3 ELSE IF statements and the ones further down the line get ignored. If you change up the order of your ELSE IFs then you should see that the top few will trigger.

To me this is a bug, just never got to posting it.

I have processes of up to 11 IF/ELSE statements (those are my longest but I am sure I could go further). I have kept them simple and done the minimum comparisons required to pass to the next process where the meat of the processing has been done.