The Administrator Dashboard is available only to users with the Application Administrator responsibility. You can use this dashboard to maintain AME's configuration variables and transaction types. Additionally, you can view and analyze AME's runtime exceptions.
An AME application administrator has many tasks. As an application administrator, you can perform the following application and transaction-type administrative tasks:
Set the configuration variables' default values (application-wide values)
Set the transaction type's configuration variables' values
Create a transaction type
Update a transaction type
Delete a transaction type
View the exception log
Clear the exception log
Run the Setup report
Add approver types
In AME, a transaction type represents a set of transactions generated by a given application, for which AME maintains a single set of approval rules. A single application can have several transaction types. For example, the Web Expenses self-service application represents one of several possible transaction types for Accounts Payable.
In AME, transaction type administration concerns the following tasks that affect your current transaction type, without deleting it:
Setting the transaction type's configuration variables' values.
Viewing the transaction type's exception log.
Clearing the transaction type's exception log.
Viewing a specific transaction's exception log.
Clearing a specific transaction's exception log.
Editing and adding item classes to the transaction type.
Updating the mandatory attributes for the transaction type.
This topic explains what each configuration variable means, and whether a configuration variable can have a transaction-type-specific value. Additionally, it indicates in each case whether a transaction type can override the default value.
The adminApprover variable identifies the person or user account that AME identifies as a transaction's next required approver to the application requesting the approver's identity, when AME encounters an exception while generating the transaction's approver list. A transaction type can override this variable's default value.
A widget is provided to select the person or the user who is the adminApprover.
The allowAllApproverTypes configuration variable is boolean value. When its value is 'yes' for a given transaction type, the transaction type can use rules that use all approver types known to AME. When the variable's value is 'no', the transaction type can only use rules that use the HR person (employee) and FND (Oracle Applications) user approver types.
When you select the allowAllApproverTypes variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a 'yes' and 'no list . Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The allowAllItemClassRules configuration variable is boolean valued. When its value is 'yes' for a given transaction type, the transaction type can use rules pertaining to any item class. When the value is 'no', the transaction type can only use header-level rules.
When you select the allowAllItemClassRules variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a select list with the possible values 'yes' and 'no'. Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The allowFyiNotifications variable is boolean valued. When its value is 'yes' for a given transaction type, the transaction type can have a rule use that generate FYI notifications. When its value is 'no', the transaction type can only have a rule use that generate requests for approval.
When you select the allowFyiNotifications variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a select list with the possible values 'yes' and 'no'. Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The currencyConversionWindow variable identifies how many days AME should look back , at most, to find the a currency conversion rate. The default value is set to 120 days. AME uses the GL Daily Rates table and associated routines to perform currency conversions.
When you select the currencyConversionWindow variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a form that lets you enter the variable's value. Enter the value, and then select the 'Submit Changes' button to update the variable's default value.
The distributedEnvironment variable indicates whether AME has been installed in a distributed-database environment. It has two possible values: 'yes' and 'no'. A transaction type cannot override this variable's default value.
AME has its own exception log, and in most cases it logs runtime transactions to that log. If the application that owns a given transaction type calls AME from within a workflow, AME also logs exceptions to Workflow (see Runtime Exceptions: page 116 for details); and it uses an autonomous transaction to commit exception data to its own log, to avoid interfering with Workflow's transaction management.
If however AME is installed in a distributed-database environment, and is called from within a workflow, it cannot initiate an autonomous transaction, because such transactions are not yet possible in a distributed environment. In this case it must query Workflow directly (where possible) for a record of AME exceptions. This log is less robust than AME's own log, and so AME avoids using it where possible.
In short, the distributedEnvironment variable is necessary to make sure AME logs exceptions internally whenever possible, while avoiding autonomous transactions where they would produce runtime errors.
The forwardingBehaviors screen defines a set of constants, which determines how AME handles forwarding in a number of special cases.
The behavior for forwarding to someone not already in the list is always the same: the forwardee is inserted as an approver of the same type, immediately after the forwarder. When the forwarder and forwardee are chain of authority approvers, and the forwarder lacks final authority, AME extends the chain of authority starting from the forwarder until it finds someone with final authority. (This would normally be the typical case.).
AME predefines default values that are expected to be the normal use for each forward type. Oracle Application teams seeding transaction types can override these defaults to ones more suitable for the particular business process.
There are a number of different types of forwarding scenario that might occur during the approval process. For each of the listed scenario below, the AME engine can be instructed to amend the approver list in a pre-defined way. Not all possible outcomes are applicable for each forwarding scenario, these all indicated below.
A chain of authority approver forwards to a previous approver in the same chain of authority.
A chain of authority approver approves and forwards to a previous approver in the same chain of authority.
A chain of authority approver forwards to a subordinate in the same approver hierarchy, but not in the same chain of authority.
A chain of authority approver approves and forwards to a subordinate in the same approver hierarchy, but not in the same chain of authority.
A chain of authority approver forwards to another approver already in the approver list, but not in the same hierarchy.
A chain of authority approver approves and forwards to another approver already in the approver list, but not in the same hierarchy.
An ad-hoc approver forwards to an approver already in the approver list.
An ad-hoc approver approves and forwards to an approver already in the approver list.
Depending on the case, the allowed sub-values may include any of the following:
ignore: Ignore the forwarding (treat it as an approval).
forwardee only: Just add the forwardee to the approver list.
forwardee then forwarder: Add the forwardee and the forwarder to the approver list.
skip forwarder: Extend the chain of authority starting with the forwardee, but skip the forwarder in the extended chain.
repeat fowarder: Extend the chain of authority starting with the forwardee, and include the forwarder in the extended chain.
remand: Add to the approver list all approvers between the forwardee and the forwarder including the forwarder.
When you select the forwardingBehaviors variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents eight select lists, one for each special case. Select a sub-value on each select list, and then select the 'Submit Changes' button to update the variable's default sub-values.
The productionFunctionality variable indicates which kinds of productions are allowed within a given transaction type. The possible values are as follows:
All production rules
Per-approver production rules
No production rules
Per-item production rules
When you select the productionFunctionality variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a radio-button input with these options. Select the one you want, and then select the 'Submit Changes' button to save the value. (Note that when you cannot edit this variable's value for a specific transaction type; you can only edit the default value.)
The purgeFrequency variable indicates how many days AME should preserve temporary data before purging it from AME's database tables. The value must be a positive integer.
When a transaction's temporary data is purged, its approval process starts over, as if no approver had approved the transaction. Therefore, the purgeFrequency variable's value should be high enough so that no transaction will require this many days to be approved by all of its approvers. At the same time, the purge frequency should be sufficiently low to avoid unnecessary growth in the size of AME's temporary-data tables.
A transaction type can override this variable's default value. When a transaction type overrides purgeFrequency, AME preserves that transaction type's temporary data only for the overriding value. This enables you to set the purge frequency differently for each transaction type, adjusting its value for each to a reasonable upper limit on the number of days required for a transaction of that type to complete its approval process.
Indicates how many times to require an approver's approval in the absence of forwarding. An approver may appear many times within the overall approval list. This can be due to a number of factors such as the approver exists as a pre/post approver as well as appearing within a chain of authority. In these circumstances it may be desirable to restrict so that the approver is only required to approve once in the following circumstances.
One of the following options should be selected:
Once per transaction
Once per item class
Once per item
Once per sublist
Once per action type
Once per group or chain
Each occurrence
Thus, you can choose to make an approver occur at most once within any given subtree of the approver-list tree.
Note: AME considers an approver as repeated only if the approver exists in the approver list with matching approval category. If the approver exists in the approver list twice with approval category as 'FYI' and 'Approval', then the approver will not be marked as repeated.
The rulePriorityModes variable has a set of sub-values for each rule type. A rule type's rulePriorityModes values determine whether AME allows rule use priorities for the rule type, within a given transaction type. The values also determine how AME handles priorities, when they are enabled.
There are two sub-values for each rule type. The priority mode indicates whether priorities are allowed, and if so, how AME interprets them. The modes that enable priorities use a numerical threshold. If the mode is disabled, AME does not allow the transaction type to use rule use priorities for the rule type. If the mode is absolute, rules whose conditions are satisfied, and which have rule use priorities that do not exceed the threshold, apply.
The relative priority mode is very useful, but it takes more explaining. In general, suppose the threshold is t, and a given transaction satisfies k rules' conditions. Let P be the set containing the t numerically lowest distinct priorities among the priorities of the satisfied rules' use. Then all satisfied rules whose use are in P apply to the transaction.
For example, suppose the threshold is three, and a transaction satisfies the conditions of five rules. Suppose also that these rules' use have priorities one, two, two, three, and four. Then the top three priorities are one, two, and three, so all but the last rule apply to the transaction.
The recordDeviations configuration variable enables you to record deviations. You must set this configuration variable to YES at transaction type level to track the deviations.
Item classes have two uses. First, they let you build header-level rules that are sensitive to item-level business variables such as a line item’s cost or the total amount billed to a given cost center. Second, they let you build subordinate-item-level rules that generate separate approver lists for each subordinate item in a transaction.
Item Classes
An item class aggregates a type of subordinate items that a transaction can have. An item class only has one property, its name, which can be up to 100 bytes long.
Items
There can be many items of a given item class, in a single transaction. For example, a transaction can have many line items. Each item must have a unique item ID, such as a line-item or cost-center ID and it must be at most 100 bytes long.
AME Objects Associated with Item Classes
An attribute is always associated with a single item class, and has a separate value for each item in the item class. An approver-generating rule is always associated with a single item class. It contributes to the approver lists for the items in the item class.
You use an item class in a transaction type by specifying values for its properties. The header item class is special because all transaction types have a predefined item class use for the header. You cannot delete this use. Each transaction has exactly one header item, and it always has the transaction ID as its item ID. The item class use for all other item classes are optional.
The item class use have the following properties:
Order Number
An item class use has an order number, which is always an integer with a value of 1 to 'n'. The item class order numbers in the related item class use sort the set of all item classes used by a given transaction type. The order numbers start at one and ascend to at most the number of item classes the transaction type uses. The order numbers are not necessarily unique, so the highest order number may be lower than the number of item class use in the transaction type.
AME uses the item classes' order numbers at run time to sort items' approver lists by item class, for a given transaction. See Parallel Approval Process for details.
Parallelization Mode
An item class use has a parallelization mode that has one of two possible values: serial and parallel. The mode governs how AME sorts items' approver lists by item ID. See Parallel Approval Process for details.
Sublist Mode
An item class use's sublist mode determines how AME sorts the sublists in each item's approver list. There are four possible values:
Serial
Parallel
Pre-approvers first, then authority and post approvers
Pre-approvers and authority approvers first, then post-approvers
See Parallel Approval Process for more details.
Item-ID Query
An item class use tells AME how to generate a transaction's item-ID list for the items in a given item class, within a given transaction. The use accomplishes this by defining an item-ID query. The query may reference AME's :transactionId bind variable, and must return the item IDs in ascending order.
Note: If the item-ID query does not return the IDs in ascending order, then any dynamic attribute use for the attributes associated with the item class will not work properly.
Oracle strongly recommends that SQL queries used to retrieve information must use only base tables and not secure views. The SQL query must also not include any context-sensitive logic.
The most common reason AME raises an exception (which typically results in the related application’s stopping a transaction’s workflow) is that AME cannot ascend a hierarchy, either because a slot in the hierarchy is vacant, or because an approver’s level in the hierarchy is indeterminate. For example, in the case of the HRMS supervisory hierarchy, an approver may have a null supervisor or a null job level. In this case, the missing data must be entered into the appropriate application before restarting the offending transaction’s workflow.
When AME cannot determine a transaction’s next required approver (in response to a request from an application, or when you use the Test Workbench tab), it:
Raises an exception in the routine that has trouble generating the approver list, and re-raises the exception up its call stack until an AME API routine catches the exception. Note that AME does not generally raise the exception to the routine that called its API.
Logs each exception to its internal exception log (where possible), and to Workflow (when the AME API was called from a workflow in another application).
If AME was responding to a request from another application it identifies the next required approver the person or user account identified by the appropriate value of the adminApprover configuration variable, and sets the approval status of this approver to ame_util.exceptionStatus. (This is the only circumstance where AME uses this approval-status value).
The requesting application may or may not notice that AME has identified an administrative approver as the next required approver, or that AME has set the approver’s status to indicate that an exception has occurred. If it does, it typically will respond by stopping the transaction’s workflow and notifying a Workflow system administrator. In this case, the person or user identified by the adminApprover configuration variable will not at this time receive a notification regarding this transaction (unless that person happens to be the Workflow system administrator as well). The application may elect instead merely to send a notification to the administrative approver identified by AME, indicating that an exception has occurred for the transaction.
If the requesting application does not notice that the next required approver is an administrative approver, it will treat the administrative approver as it would any other approver: by sending the approver a notification requesting their approval of the transaction. The approver would then have to discern that AME had encountered an exception while attempting to calculate the transaction’s approver list.
Oracle recommends that you configure the adminApprover configuration variable to identify the same individual as the Workflow and AME administrator for a given transaction type. This will have the effect of making sure the same individual is always notified when that transaction type’s workflow errors, regardless of whether the error arises within AME.
Use the Create New Transaction Type page.
Click Create Transaction Type on the Administrator Dashboard to open the Create New Transaction Type page.
Select the application for which you want to create the transaction type.
Enter the transaction type key and name. Typically, these properties must identify the nature of the transaction.
Click Next to add item classes to the transaction type.
AME adds header item class as the default item class for a transaction type. If you want to add another item class, select from the Add List and click Go. Enter the item class use details and click Apply to add the item class to the transaction type.
See Item Classes and Using Item Classes for further information.
Click Next to add mandatory attributes for the transaction type.
Select the attribute values and click Next to review the transaction type details.
Click Finish to add the transaction type to Oracle Approvals Management.
As an administrator, you can update the transaction type properties, edit the transaction type's item-class use to set the values of parallelization parameters, add new item classes, modify mandatory attributes' values. It is also possible, but uncommon, to edit the use's item-ID query.
To update a transaction type
Use the Update Transaction Type page.
On the Administrator Dashboard, click Update for the transaction type you want to update.
Modify the transaction type details in the Update Transaction Type page.
Click Finish to submit your changes.
You can delete transaction types that are not predefined.
To delete a transaction type
Use the Administrator Dashboard.
Click Delete for the transaction type you want to delete.
Confirm the deletion when prompted.
AME defines a number of configuration variables. In all cases, the configuration variables have default values that are created when AME is installed. In some cases, each transaction type can override the default value with its own value as well. Configuration-variable names and values are case-sensitive.
To set the configuration variables’ default values
Use the Configuration Variables page.
Click Configuration Variables in the Quick Links on the Administrator Dashboard or Business Dashboard to open the Configuration Variables page.
Change the required default values.
Click apply to set the configuration variables default values.
You use the same page to set a transaction type’s configuration-variable values that you use to set the variables’ default values, with two exceptions. First, you cannot change the values of the allowAllApproverTypes, allowAllItemClassRules, or allowFyiNotifications configuration variables for predefined transaction types, if you have set the values as Yes.
To edit a transaction type’s configuration-variable values
Use the Configuration Variables page.
Click Configuration Variables in the Quick Links on the Administrator Dashboard or Business Dashboard to open the Configuration Variables page.
Query the transaction type.
Modify the variables' value(s). See Configuration Variables.
If you want to use any of the default configuration variables value in your transaction type, then leave the specific transaction type variable field blank.
Click Apply.
You can update the following configuration variables at the transaction-type level:
adminApprover
allowAllApproverTypes
allowAllItemClassRules
allowFyiNotifications
currencyConversionWindow
forwardingBehaviors
productionFunctionality
purgeFrequency
repeatedApprovers
rulePriorityModes
A transaction’s exception log contains only those exceptions raised by AME when it processes the transaction. It can be useful to view the log to determine exactly why the transaction’s approval process has been interrupted.
To view the exception log
Use the Transaction Exception page.
Click Exception Log in the Quick Links on the Administrator Dashboard to open the Transaction Exception Log page.
Query the transaction type to view the exception details for all the transactions in the specific transaction type. Otherwise, query the specific transaction by entering the transaction ID to view exception details of the specific transaction.
The exception log appears, sorting the exceptions in descending log-ID order (that is, most recent exceptions first).
Click Purge to clear the exception log and confirm the operation when prompted.
You can view and print the approval setup details for you transaction type by running the Setup Report.
To run the setup report
Click Setup Report in the Quick Links on the Administrator Dashboard to open the Setup Report page.
Query the transaction type for which you want to run the Setup report and click Go.
Click Printable Page to enable you to print the report.
Click Print in the File menu to print the report.
However a Workflow system administrator or AME administrative approver becomes aware that AME is having trouble processing a transaction, they should respond to the problem as follows:
Check AME’s exception log for the transaction. See Viewing Specific Transaction's Exception Log.
Check Workflow’s context log for any other relevant details.
Correct the problem, which is usually data, that caused AME difficulty.
Restart the transaction’s workflow.
Clear the transaction’s exception log in AME. See Viewing Specific Transaction's Exception Log.