Are AME Rules combined as an ‘AND’ or an ‘OR’ clause?

A friend of mine recently asked this question and I thought it might make a good post. The question was, How does AME behave when you have setup multiples rules for a transaction type. How does the end approval hierarchy look in such a scenario and how do you control it.

In such cases the result depends on whether the various rules that you have configured are mutually exclusive or if more than one rule can be true for an transaction. For any transaction, AME evaluates all rules defined in the functional area and merges the out of all rules into a final approver lists according to an preset rule. So the answer to the question is that the rules will result in an AND. However, if the rules have conditions which ensures that only one rule applies for an transaction then the output results in an OR.

Many a time, you would need to code complicated attributes to achieve the OR conditions. Well if design the rules carefully the desired output can be achieved by using the Priority Processing Mode. AME allows you to define relative or absolute priorities for each of the rules. When the rules are evaluated, AME automatically collapses the rule as per priority settings and generates the end approval hierarchy as per your requirement.

AME - Approvals Made Easy

One of my most interesting module that I have implemented in the recent past is AME. Its a small module but extremely powerful. It simplifies the approval process for self service based transactions. When AME is enabled SSHR uses it to route the transactions untill no approvers are found. In this note I will try to explain AME the way I think it works

AME setup comprises of 4 components called atributes, conditions, actions and rules. You setup attributes, conditions, actions and tie them together using a rule. Actually speaking, the setup is nothing but a mathematical equation, which can be expressed as

When attribute A has a value B then the approver should be C
........... --------------
............ Attribute
........... ------------------------.......................... ---------------------------
....................Condition...............................................Action
...........-----------------------------------------------------------------------
........................................................ Rule

This various componets of the equation are

• Attributes: A is a property of the transaction that dictates how AME should behave e.g. name of the workflow process involved
• Condition: When attribute A has a value B. e.g. When the workflow process name is HR_NEW_HIRE_PRC_JSP
• Action: Approver should be C. This identifies who should perform the action. e.g. The approver should be person's supervisor
• Rule: Conditions and Actions are tied together in a rule that is evaluated by AME. When all the conditions defined in a rule are met then AME notifies every person in the Action list before the transaction is approved.
  

When AME is invoked it evaluates all the rules that are defined for the product. It then combine the result (approver set) of all the rules and builds the final list of approvers.

So you can see that AME is very easy to setup. It simple maths.. Happy implementation