Oracle HRMS

Immersion
Workshop
11.5.10 Technical Review
Oracle Approvals Management

Todd Morley
AME Architect

Part I

AME Patches

Copyright 2003, Oracle. All rights reserved.

AME Patches

1-3

The stub patch has no dependency on per_jobs.

The full-install patch depends on per_jobs (which HR introduced in
its 11.5.4 family pack).
AMEs first patchset will
be based on 11.5.10.
be released right after 11.5.10.
be labeled AME.A (see bug 3277250).
depend on per_jobs and Workflow Directory Services.

Copyright 2003, Oracle. All rights reserved.

Part II

New Functionality

Copyright 2003, Oracle. All rights reserved.

Overview
AME 11.5.10 introduces these new features:

Generalized approver types

Generalized subordinate approval processes
Parallel approval processes
Approver categories
Various action-type enhancements
Various new approver statuses.

New-feature availability depends on integration of

AME 11.5.10 into originating applications.

1-5

Copyright 2003, Oracle. All rights reserved.

Generalized Approver Types (GAT)

AME 11.5.10 supports Workflow Directory Services;
all approvers are now in the wf_roles view.
A data-migration script converts HR persons and
FND users to wf_roles entries.
AME 11.5.10 supports HR positions.
Contact AME development to request support for
other approver types in Directory Services.
The related ame_util.approverRecord2 fields are
name
orig_system
orig_system_id
display_name.
1-6

Copyright 2003, Oracle. All rights reserved.

Generalized Subordinate Approval

Processes (GSAP)
An item class is a set of things that can have
attribute values and approver lists.
An item-class usage includes a query that returns
the list of item IDs for the item class, for a given
transaction in a given transaction type.
Attributes are now assigned to an item class. An
attribute has one value per item in its item class, per
transaction.

1-7

Copyright 2003, Oracle. All rights reserved.

GSAP (II)

1-8

Rules are also assigned to an item class. A rules

item class determines which item class approver
lists it helps generate.
Header-level rules can reference conditions
defined on attributes of at most one subordinate
item class, as well as on header-level attributes.
Subordinate-item-class level rules can reference
conditions defined on header-level attributes, and
on attributes defined on the rules subordinate
item class.

Copyright 2003, Oracle. All rights reserved.

GSAP (III)

The seeded item classes are

The related ame_util.approverRecord2 fields are

1-9

header
line item
cost center.
item_class
item_id.

The item_class field contains the name of the item

class.
The item_id field contains an item ID generated by
the item-class usages item-ID query.

Copyright 2003, Oracle. All rights reserved.

Parallel Approval Processes (PA)

A transactions approver list now has a tree

structure with six levels:

1-10

item class
item
sub-list
action type
approval group or chain of authority
group or chain member.

AME now assigns an order number for each level

to each approver, in an order-number six-tuple.
You can view an approvers six-tuple on the test
tabs approver-details pop-up window.
Copyright 2003, Oracle. All rights reserved.

PA (II)

1-11

The UI lets you assign a non-unique order number,

or an ordering mode, to objects at each level of the
approver-list tree.
Order numbers are for static sets.
Ordering modes are typically for dynamic sets.
Approval-group and action-type voting can affect
group-member order numbers.
AME orders a transactions approvers according to
the lexicographic ordering of their six-tuples.

Copyright 2003, Oracle. All rights reserved.

PA (III)

The related ame_util.approverRecord2 fields are

1-12

item_class_order_number
item_order_number
sub_list_order_number
action_type_order_number
group_or_chain_order_number
member_order_number
approver_order_number.

The lexicographic ordering on the first six of these

determines the value of the seventh (the
approver_order_number field).

Copyright 2003, Oracle. All rights reserved.

Action Types

Multiple actions per rule are now possible.

A production is an uninterpreted name/value pair.
The production action type enables two types of
productions (fetched via AMEs API):
per approver (the production action is associated
with an approver-generating action in a single rule)
per transaction (the action is not so associated).

1-13

Approval reverts to action.

Dynamic pre- and post-approver actions have
been migrated to normal pre- and post-approver
actions using dynamic approval groups.

Copyright 2003, Oracle. All rights reserved.

Approver Categories

An approvers approver category indicates

whether they receive a notification requesting
approval or an FYI notification.
The related ame_util.approverRecord2 field is
approver_category.
The allowed values for this field are
ame_util.approvalApproverCategory
ame_util.fyiApproverCategory.

1-14

Copyright 2003, Oracle. All rights reserved.

New Approval Statuses

The ame_util.approverRecord2 approval_status

field has four new allowed values:

1-15

ame_util.notifiedStatus
ame_util.beatByFirstResponderStatus
ame_util.suppressedStatus
ame_util.repeatedStatus.

The notified status indicates that an approver has

been notified (and, if the approver must approve,
that the approver has not yet responded.)
The beat-by-first-responder status indicates that
an approver in a group or chain subject to firstresponder-wins voting was not the first responder.
Copyright 2003, Oracle. All rights reserved.

New Approval Statuses (II)

1-16

The suppressed status indicates that an approver

was suppressed (previously, deleted) by an API
call.
The repeated status indicates that an occurrence
of an approver will be ignored because the
approver occurs more often in the transactions
approver list than the repeatedApprovers
configuration variable requires.

Copyright 2003, Oracle. All rights reserved.

Part III

The AME Implementation Cycle

Copyright 2003, Oracle. All rights reserved.

Documenting a Transaction Type

The AME implementation cycle has three basic

steps:
1. Document the transaction type.
2. Input into AME a representation of the transaction
types business logic.
3. Test and debug the transaction type.

Each transaction type should have its own

implementation document.
Each document should have three sections:
1. business cases
2. AME representation of business logic
3. test cases.

1-18

Copyright 2003, Oracle. All rights reserved.

Business Cases

1-19

The obvious type of business case is transactions

requiring similarly structured approvals.
There should be one business case for repeated
approvers.
There should be eight special forwarding cases
(one for each case governed by the
forwardingBehaviors configuration variable).
There should be six PA cases (one for each level of
the approver-list tree).

Copyright 2003, Oracle. All rights reserved.

AME Representation of Business Cases

Specify (and input) a transaction types

representation of the business cases in the
following order:
1.
2.
3.
4.
5.
6.

1-20

configuration variables
item-class usages
mandatory-attribute usages
approval groups
rules
rule usages.

Copyright 2003, Oracle. All rights reserved.

AME Representation of Business Cases (II)

There are four basic ways to document a set of

rules:

rule lists
approval matrixes
decision trees
directed graphs.

Which approach is best depends on

1-21

the size of the set of rules

the rules structure
whether the transaction type enables rule priorities
whether the transaction has multiple, datedependent rule usages for the same rule.
Copyright 2003, Oracle. All rights reserved.

Rule Lists
Rule lists suffice for simple sets of rules.

1-22

Copyright 2003, Oracle. All rights reserved.

Approval Matrixes

1-23

Approval matrixes are good when all of the rules

(or all of the rules of a given rule type) use
conditions defined on the same set of attributes.
Approval matrixes can account for rule priorities
and multiple usages per rule.

Copyright 2003, Oracle. All rights reserved.

Decision Trees

1-24

Decision trees can be used for the first case where

approval matrixes are useful.
Decision trees can represent rules whose
conditions are defined on diverse sets of
attributes.
We have so far not discovered how to use decision
trees to account for rule priorities; if you do,
please let us know!

Copyright 2003, Oracle. All rights reserved.

Directed Graphs

1-25

Directed graphs impose one more layer of nodes

on a decision tree, linking all of the trees leaf
nodes having the same label to a single new node
with that label.
The purpose of the new layer is to identify
explicitly the subset of rules having the same
outcome.

Copyright 2003, Oracle. All rights reserved.

Guidelines for Constructing Rules

1-26

Capture all of your business cases in the rules.

Avoid conflicting conditions within a rule.
Where possible, avoid conflicting outcomes
between rules that might apply to the same
transaction.
Minimize the mean number of applicable rules per
transaction.
Minimize the total number of rules.

Copyright 2003, Oracle. All rights reserved.

Testing a Transaction Type

In a test environment, create test transactions in the
originating application.
Relate test-transaction IDs to the test cases in your
implementation document.
Compare the following data on the test tab and in the
originating application:
attribute values
productions
approver lists.

1-27

Copyright 2003, Oracle. All rights reserved.

Testing a Transaction Type (II)

Step through the approval process to observe
1. the transactions attribute values
2. the list of applicable rules before priorities
3. the list of applicable rules after priorities
4. transaction-level productions
5. the default approver list
6. #5 with insertions and surrogates
7. #6 accounting for API suppressions
8. #7 accounting for repeated approvers
9. #8 with approver order numbers (the final list).

1-28

Copyright 2003, Oracle. All rights reserved.

Testing a Transaction Type (III)

On the approver-list pages, use the approver-details
window to observe user-friendly versions of most
fields in the approvers ame_util.approverRecord2. In
particular, this window displays the approvers
approver category
order-number six-tuple
per-approver productions.

1-29

Copyright 2003, Oracle. All rights reserved.

Debugging

1-30

Execute item-class usages, attribute usages, and

dynamic-approval-group queries from the
command line; compare results there with those in
AMEs UI and the originating application.
Execute test scripts calling the AME API from the
command line. Compare results there with those
in the test tab and the originating application.
Check the AME exception log to see whether
exceptions appearing in Workflow or the
originating application were first raised by AME.

Copyright 2003, Oracle. All rights reserved.

Debugging (II)

To find an AME file version, query user_source for

the related package (or package body) name,
looking for a line with the substring $Header:.
For example,
select text
from user_source
where
name = 'AME_UTIL' and
type = 'PACKAGE' and
text like '%$Header:%';

1-31

To find an AME patch version (11.5.10 onward),

use OAM.

Copyright 2003, Oracle. All rights reserved.

Part IV

Integrating AME into an Application

Copyright 2003, Oracle. All rights reserved.

The AME-Integration Process

1. Decide how many transaction types to create for
the originating application.
2. Define each transaction types seed data (optional
data in parentheses):

(attribute names)
attribute usages
(item-class usages)
(conditions)
(approval groups)
(rules)
(rule usages).

3. Call AMEs APIs from the applications workflow.

1-33

Copyright 2003, Oracle. All rights reserved.

Part V

Conclusion

Copyright 2003, Oracle. All rights reserved.

How to Get Help on AME

AME-development mailing list: apps_hrd_ame_uk

Oracle-internal AME users: ame_users_ww
Intranet sites:
http://ame.uk.oracle.com (formal documentation)
http://www-apps.us.oracle.com:1100/~tmorley (draft
documentation)

1-35

Copyright 2003, Oracle. All rights reserved.