Setting up AME (Approval Management) in R12

I am working with a customer for upgrading there HCM to R12 from 11.5.10 . R12 include lot of technology changes and one of them includes AME. Newer version of AME, AME.B is also available in latest 11i releases.
AME.A was built in mod PL/SQL and AME.B is developed in OA Framework. Another major change in AME is that it uses RBAC (Role Based Access Control) mechanism to assign responsibilities to a user.

So if you open AME Approvals function with old responsibilities you might get one of the following errors.

The requested URL /pls/VIS/OracleSSWA.Execute was not found on this server.
OR
Can not access function AME_WEB_APPROVALS. This installation does not manage mode pl/sql. Please contact your System Administrator.

Both the errors saying that mod PL/SQL is not available (OracleSSWA is a program that executes the PL/SQL Package to generate the html output for pages).

Following are the steps to implement AME in R12 instance.
1. Login with SYSADMIN User.
2. Go to User Management Responsibility.
3. Click on Users and query for the username to which you want to assign AME Responsibilities.
4. One you query the User, Update the User from search results region and then click on Assign Roles.
5. Assign following Roles to the User
a) Approval Management Administrator
b) Approval Management System Administrator
c) Approval Management Process Owner
d) Approval Management System Viewer
e) Approval Management Business Analyst

Once finished with the Roles we will grant a permission set to the user from Functional Administrator Responsibility. Following are the steps for that

6. Go to Functional Administrator Responsibility => Security => Grants => Create Grant.
7. Enter Name of the "Grant" and effective start date. In Security Context select Grantee Type as Specific User and enter the User name whom you want to assign AME Responsibilities (Same user to which we assigned AME Roles).
8. Select Object as AME Transaction Types and Press Next.
9. Select Data Context as All Rows and assign "AME Calling Applications" permission set and Save the Information.

We need to set the AME: Installed Profile option as well to make it work. Set this profile option to Yes at application level (Human Resources).

Try to login with the user and you can see the following responsibilities listed there
Approvals Management Administrator
Approvals Management Business Analyst

What should existing AME Users do to make it work ?
It is pretty easy. Oracle provides a concurrent program "Approvals Management Post Upgrade Process". Run this program and thats all.

Drop a comment if you have any question regarding the above article. Hope this will help.

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

Building Block Name	Purpose
AME Transaction Type	Think of this to be the entire Approval Business Process for a specific transaction type, for example PO Approval or iRecruitment Vacancy Approval. Of course a business process will consist of various rules.
AME Attributes	Think of these as global variables whose values can either be static or derived from SQL Statements. The SQL Statements can reference the transaction id, which for example could be "requisition header id" or "vacancy_id". These Attributes can be used for building the AME Conditions.
AME Conditions	These are IF Conditions that use variables, i.e. AME Attributes
AME Action Type	Action type defines how the action is taken to calculate the result. For example- the action be to use a specific Approval Group based on static list of employees. Alternately the action can be to use a dynamically built list of Approvers.
AME Approval Groups	Approval groups are used to build the list of approvers, either from Static list or from SQL Statements. Calls to Approval Groups are made from "AME Action Type".
AME Rules	Combines the "AME Condition" and "AME Approval Groups". Indirectly though it references all the building blocks of AME. You can say that every piece of AME building block is glued together in an "AME Rule".

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.