Functional

In this article you will understand the basic concept of AME. This article will lay the foundation of some of the AME examples in iRecruitment and SSHR that will be covered in Apps2Fusion.

What is AME?
AME by definition is a Approval Management Engine that Builds a list of approvers for a specific transaction using business rules. However in simple words, AME is a "IF THEN....ELSE....END IF" condition - wrapped into an API.
That's exactly what AME is. It is a IF THEN ELSE CONDITION wrapped up into a lets say Function Call to produce a list of approvers. The complexities are taken care of by the Approval Management Engine itself. However this "IF CONDITION" definition holds true when talking about the simplest possible definition of AME. Therefore if you can understand "IF Condition", then you can understand AME. Further to that, if you know how to write IF Conditions and how to write SQL, then you will be able to implement most of the AME Business requirements with ease. Lets have a look into IF CONDITION from another perspective.

The example below is for explanation purpose only, not the exact definition of AME.
Imagine there is a FUNCTION that returns the approver
FUNCTION get_requisition_approver_id (transaction_id IN INTEGER )  RETURN INTEGER IS
BEGIN
IF get_requisition_amount(transaction_id) < 1000000 THEN
   return 1000 ;-- calculated from person_id from the supervisor_id of the person that created requisition
ELSE
   return 1001,1003 ; --person_id from a static approver group that contains list of people, like Director followed by a CEO to approve orders over 1Million
END IF ;
END get_requisition_approver_id ;

The above function builds a list of approvers for a specific transaction using business rules, and returns one of more approvers.


Understanding the basic building blocks of AME
To understand the building blocks of AME, in the above example, consider the complete FUNCTION definition get_requisition_approver_id as "AME Transaction Type". Let us discuss the basic building blocks of AME using the Function get_requisition_approver_id as listed above.

To this "AME Transaction Type" a parameter named Transaction Id is passed that helps identification of the underlying business transaction, for example this could be requisition_header_id from po_requisition_headers_all.
Consider the IF Statement as "AME CONDITION"

The IF statement will rely upon some variables. Consider that these variables are "AME ATTRIBUTES" for the transaction types. The value for these attributes can be calculated by executing some SQL Statements. Alternately the AME Attribute can be defined with a static value too. In AME Terminology, for a  variable to be used in IF condition you must ensure that its corresponding AME Attribute is registered against the AME Transaction Type. [Note - Some AME Attributes used by AME Engine are globally available to all AME Transaction Types]. The value of the AME ATTRIBUTE can either be static value or dynamic when derived by firing a SQL Statement.

The return statement in above function is nothing but an "AME Action". As per the example above, the "AME Action Type" will return the Supervisor of the person if Requisition amount is less than USD 1 Million. However, the "AME Action Type" will return the person_id of Directory followed by the CEO of the company when requisition amount is greater than USD 1 Million.

The Combination of the IF CONDITION and the RETURN Statement is called "AME Rule". In other words each AME rule is a condition with a result returned.
However it must be noted that you can define an "AME Rule" without any condition. At the time of creating the "AME Rule" you will get a option to wrap a condition around it. You may decide to skip the step of attaching a condition to the rule. Fictitiously if all the Requisitions must be approved by the CEO, then you simply define a AME Rule without any "IF Condition".

The entire return statement i.e. "return 1000" may be deemed as AME Action Type, however the value 1000 or 1001 or 1003 is derived from something known as "AME Approval Group". As you might have guessed, the "AME Approval Group" can either be a static list of people or a dynamically calculated list of people. The dynamic list is of course generated using the results of a SQL Statement.

Therefore "AME Transaction Type" is the encapsulation of the approval business rules relating to a business transaction like Requisition.
You can have as many IF Conditions as you desire to build the logic for approval. Therefore "One AME Transaction Type" can consist of many "AME Rules". In other words "One AME Transaction Type" can consist of various "IF THEN ELSE Statements" and their corresponding actions.


Therefore, by reading the above function based example, it is clear that AME consists of certain building blocks that are
Profile option "AME:Installed" must be set to Yes, at application level to the calling application to be able to use AME.. For example, to make iExpenses use AME, you should set profile to Yes for "Payables" Application.

The "AME Transaction Type" can be defined using a responsibility named "Approvals Management Administrator".
Remainder of the building blocks can be defined and configured using responsibility named "Approvals Management Business Analyst". Oracle eBusiness suite comes seeded with

Given that AME is configurable, you may want to rollout AME to your Super Users or Support Staff. For example, you may have one support team for HRMS product and another support team for Procurement product. In such cases, you do not want the HRMS Support team to modify Approval Rules of Procurement. To achieve this security, AME uses RBAC.
In one of the future articles we will see how to configure RBAC in AME in one of the future articles.

In Next article we will browse through these AME Building blocks in a video demo, in the context of Self Service HRMS.

Add comment

Name (required)

E-mail (required, but will not display)

Website

Notify me of follow-up comments

Refresh

Send

Cancel