Why three separate rules?

tkilshaw

In the Library application the OutgoingEmail object has three rules, each of which starts with the same condition:

If OutgoingEmail.State WAS CHANGED TO 'Sent' Then

then they do different things:

OutgoingEmail.SentToAddress=OutgoingEmail.Correspondent.EmailAddress
OutgoingEmail.ContactTime=CURRENT_TIMESTAMP
PROTECT OutgoingEmail.SentToAddress FROM ALL

Traditional programming would make this one rule with three Actions in the order shown.

Why three separate rules?

Is that considered better Aware coding?

thanks,

Terry

aware_support

In this particular case the difference is rather theoretical and conceptual. The end result is the same.

Aware IM treats all rules as independent and self-contained entities. The sequence of their execution is undefined. When you specify several actions in one rule, on the other hand, you imply rigid sequence - actions are executed one by one in exactly the order they are specified.

Now in this case all three actions are independent of each other - it does not matter in which order they are executed - therefore, we have 3 different rules. So, yes, this is better Aware IM configuration style.

Best Regards

aware_support2

Each rule in Aware IM is supposed to represent a self-contained piece of business logic independent from other rules. From this point of view the emphasis is on the rule action, not on the condition. The three rules mentioned above just happen to have the same condition, but are otherwise independent from each other. If conditions for any of these rules need to be adjusted, it could be done for the particular rule without affecting the others.

Even semantically it would be difficult to come up with a name for the rule that would combine all three actions. With separate rules, each rule has a clear label reflecting the purpose of the rule.

Also keep in mind that there is a lot of rule-based processing done behind the scenes where the system analyzes both the conditions and actions of each rule when certain events take place. For example, when an object is changed the system considers all affected rules on related objects. Another example is rules with PROTECT action, which system considers to dynamically determine if entry fields on object forms need to be disabled. From this point of view it is also best that unrelated actions are not mixed together in one rule.