AME My Notes
AME My Notes
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/395-ame
Note: Setup and Application Screenshots at the end
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.
Purpose
AME Attributes
Attributes are variables used to hold business facts of interest for the
transaction in progress. Most attributes are dynamic, meaning they will be
evaluated at run time, thus, they can change for each transaction. Oracle
provides over 50 seeded attributes for SSHR which can be used directly or
as the basis of creating the users own. These Attributes can be used for
building the AME Conditions.
AME Conditions
Action Types provide two important aspects of the generated approval chain.
Action Types, by their nature, indicate HOW approvers are generated, i.e.,
whether by utilizing an existing hierarchy, or by a user specified list of
persons.
The second aspect is regarding the order in which approvers are notified.
Pre-chain Action Types will be triggered before Chain of Authority action
Actions
Actions are combinations of Action Types and Approver Groups, and are the
THEN statement of a rule. Actions are automatically generated for Pre- and
Post-chain Action Types. For example, if an Approver Group of HR
personnel, named MUSS Benefit Specialists is created, Oracle
automatically creates Actions called Require pre-approval from MUSS
Benefit Specialists and Require post-approval from MUSS Benefit
Specialists.
Many seeded Actions for Chain of Authority Action Types are available. For
the Action Type supervisor_level, Actions exist to specify from 1- to 10-up
supervisor levels. Other chain actions involve job or position hierarchies
again, information that should already be recorded in your database.
AME Rules
There are six different types of Rules. The most commonly used ones would
include List-Creation (based on Chains of Authority Actions), Pre-List
Approver Group, and Post-List Approver Group. Substitution Rules are used
to replace a specific approver, however generated, with another person. A
Combination Rule can be used to combine pre-chain, chain, and post-chain
actions as long as conditions and the rule category are the same
Profile option "AME:Installed" must be set to Yes, at application level to the calling application to be able to use AME.
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".
AME Concepts.pdf
Well there is no official explanation from Oracle for usage of a workflow to drive the flow of the screens. However
prior to using OA Framework in Self Service HRMS, SSHR was built using PL/SQL Web Cartridges and latter AK
Developer was included. Those days OA Framework did not exist in the current form. When the very first version of
SSHR was built by Oracle, back then the methodology of transaction state management of web based applications
was not standardised across e-Business Suite modules. Use this link to understand how OA Framework evolved.
Therefore Oracle HRMS Product Development team decided to use a "Workflow process" to keep all the loose bits of
screens tied together into one single transaction. If you open the HR [HRSSA] workflow, you will notice that there are
many Workflow Activities that are mapped to PL/SQL Function named HR_WORKFLOW_SERVICE.BLOCK. These
activity/steps in workflow correspond to a screen. This is how user navigation from one screen to other is controller in
Self Service HRMS.
The image shown above uses a workflow process named Person Information. However, for each distinct menu item
in Self Service HRMS, there exists a corresponding Workflow Process. Thus there are numerous processes within
this HRSSA workflow. For example there is another workflow process that starts when user navigates to "Extra
Information Types" screen
How does Oracle know which workflow process to initiate when a user enters "Person Information" screen in
SSHR
When user clicks on SSHR Menu Item, the name of the workflow process is passed as a parameter to the form
function. Therefore, the sequence of events are
This Form Function invokes AK Region HR_CREATE_PROCESS_TOP_SS [See Web HTML of Form
Function HR_PERINFO_SS]
Parameter pProcessName is read and the Workflow Process named "Personal Information" is initiated
How does Oracle know which AME Transaction Type to use for that screen
As shown in image above, two parameters named pAMETranType and pAMEAppId are passed as parameter to the
Form Function. This tells which AME Transaction Type will be used by the SSHR screen. However the decesion of
whether AME is switched ON or OFF is decided by a Wokflow Activity named "Review Page". Every SSHR Workflow
Process as a step named "Review Page". As shown in image below, when you double click on activity Review Page
you will notice that this Workflow Function is passed a parameter named HR_APPROVAL_REQ_FLAG. If this WF
Activity parameter is Yes or "Yes - Dynamic Approval" then the AME is called for Approval processing. To change the
standard Approval processing in Oracle Self Service HRMS, you can customize this property to enable or disable the
Approval Processing for specific screen in HRMS.
Further details of how you can implement differing AME logic for different SSHR screens will be covered in a future
article.
Note- It is in Self Service HR [HRMS] that the AME Trx Type is passed as passed as parameter to the screen
function. Every calling module can have its own specific way using which the AME Trx Type to be used is configured.
For example, in iRecruitment we have the following profile options that dictate the AME Transaction Type being used
IRC: Vacancy Approval Transaction Type
-Identifies the vacancy approvals transaction type to be is used.
IRC: Offer Details Approval Transaction Type -Offer Details Approval Transaction Type
IRC: Extend Offer Duration Transaction Type -Extend Offer Duration Transaction Type
Do we directly customize the Workflow Process to change the AME behaviour for a screen?
Not really. You will copy the existing workflow process and create a new workflow process. For example a new
workflow process named XX will be created. The review page property within this workflow process will be modified
to use/remove AME. Thereafter you will create a new custom Form Function and attach that Custom Form Function
to the Menu. This Custom Form function will be passed in the parameter pProcessName with Custom Workflow
Process Name. This function must also be included within the menu named
"HR_GLOBAL_SS_FUNCTIONS_CUSTOM". This will facilitate usage of the custom Form Function in SSHR.
2.
No functions will however be visible when accessed through the responsibilities. This is resolved using RBAC
(Role Based Access Control)
Go to User Management Users Search for SUBSINGH Update
Click on Assign Role. Search for Roles with name %Approval% and assign all the roles found to
SUBSINGH.
Apply Changes. Now the functions will be visible. However NO DATA will be visible as of yet.
For data to be visible go to Functional Administrator Create Grant.
Grantee Type = Single User and then enter SUBSINGH as user. Select Object = AME Transaction Type.
Click Next. Select All Rows as context type. Click Next. Set = AME Calling Applications.
Save the Grant. Clear cache to see DATA.
3.
4.
5.
6.
7.
8.
9.
Right click on the Workflow Process that you wish to customize and click "Copy" as shown below
For the "Review Page 4.0" activity, set the HR Approval required property to "Yes - Dynamic Approval"
Preserve_Customizat
ions_in_Oracle_Workflow.ppt
2. How does Self Service HRMS decide whether the in-transit transaction data goes into XML CLOB
HR_API_TRANSACTIONS.TRANSACTION_DOCUMENT or into HR_API_TRANSACTION_VALUES.
In the old version of Self Service HRMS, all the temporary information is captured in the following tables.
HR_API_TRANSACTIONS
HR_API_TRANSACTION_STEPS
HR_API_TRANSACTION_VALUES
3. How is this temporary data used by AME
Inside AME, you usually write SQL statements against AME Attributes and AME Approval Groups. In
those SQL statements, you can reference HR_API_TRANSACTIONS.TRANSACTION_ID by using convention
:transactionId
4. How is the data transferred from temporary tables to base tables in HRMS.
Oracle executes an API named hr_transaction_swi.commit_transaction which takes the transaction_id as parameter.
This transfers the data from temporary tables to the base tables.
DECLARE
v_trans_api_result VARCHAR2(1);
BEGIN
v_trans_api_result :=
hr_transaction_swi.commit_transaction
(
p_transaction_id => n_hr_api_transaction_id --pass the transaction_id here
,p_validate
=> hr_api.g_false_num
While the Approval is in progression, the data remains in temporary tables named
HR_API_TRANSACTION_VALUES [in case of SIT. Some other screens use XML CLOB in
hr_api_transactions.transaction_document]. Therefore if your custom logic within the AME wants to access the
original transaction data, that can be done by either querying HR_API_TRANSACTION_VALUES or by parsing the
XML within the CLOB column.
The primary key for table HR_API_TRANSACTIONS is Transaction_id. This Transaction Id is passed as a parameter
to the AME Engine for SSHR AME Transaction Type. Therefore AME Trx Type will be passed the TransactionId using
which it can get the handle to contents of HR_API_TRANSACTIONS
How do we know which AME Transaction Type will be called by our Custom Screen?
If you revisit Part-2 of this article, you will notice that the AME Transaciton Type and AME Trx Type ApplicationId are
passed as parameters to the AOL Form Function.
The parameters field in AOL Function definition contains AMETranType=SSHRMS&pAMEAppId=800
How do we build the logic for our solution?
We will be building a logic in AME that is similar to below
IF WORKFLOW_PROCESS_NAME='XXFT_HR_SIT_JSP_PRC'
THEN
Return Approver Name from AME Attribute XXFT_MANAGERS_BOSS_GROUP
END IF ;
What is XXFT_MANAGERS_BOSS_GROUP?
XXFT_MANAGERS_BOSS_GROUP will be a custom defined AME Approval Group that you can define. To this AME
Approver Group, you can attach the following SQL Statement. This SQL statement returns the FND_USER.USER_ID
of the Manager's manager for the employee that created a record in "Holiday Rejection Complaint" screen.
hat,
per_all_assignments_f
paaf,
per_all_assignments_f
paaf2,
PER_ASSIGNMENT_STATUS_TYPES past,
PER_ASSIGNMENT_STATUS_TYPES past2,
fnd_user
fu
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/424-ame
See Presentation
3.
Define the approval rules (AME Rule) - Approval Rules determine the approvers or FYI notification recipients
required for a business transaction.
Test Workbench - Define test cases or test real transactions to verify the approval setup, rules and
associated approvers.
4.
5.
Attributes Screen
It can be any package.function in the query with transactionId being the parameter. This transaction ID is from the
table HR_API_TRANSACTIONS. Against the transactionId we can get several other values like person_id etc.
Condition Screen
Actions within Chain of Authority action type are Require approvals up to the first superior, at most, Require
approvals up to the first two superiors, at most etc.
Actions within approval-group chain of authority action type are Require approval from XXHR First Approver where
XXHR First Approver is the Approver Group created.
Step 3: Add Action. Select action type as Chains of authority or approval-group chain of authority and add the
appropriate action.
Test Screen
Screen 1: Landing Page. Create a new test case here.