Managing Trigger Points
The Manage Trigger Point page provides a comprehensive view of policies that are associated with a specific trigger point. This page displays policies and policy groups in a hierarchy, with the trigger point as the root and policy groups (if any) as parents of policies.
In addition, this page enables you to assign execution options at the trigger point level and at the policy group level, facilitating policy arbitration and better policy management.
|
Page Name |
Definition Name |
Usage |
|---|---|---|
|
EOCF_MANAGE_TP |
Manage trigger points. |
Use the Manage Trigger Point page (EOCF_MANAGE_TP) to manage trigger points.
Navigation:
This example illustrates the fields and controls on the Manage Trigger Point page. You can find definitions for the fields and controls later on this page.
The trigger point hierarchy on the left-hand side of the page displays all the policies and policy groups associated with the selected trigger point. The trigger point appears as the highest-level item in the hierarchy while policy actions appear as the lowest level items.
Field or Control |
Description |
|---|---|
Filter |
This field applies only to policies displayed in the hierarchy and the Existing Policies/ Policy Groups grid. It displays active policies, in-design policies, or all policies depending on the selection. |
SetID |
Toggle the value in this field to view policies for this setID. |
You can remove a policy or policy group from a trigger point by selecting the policy or policy group to be deleted, and then clicking the Delete icon. Removing a policy or policy group from the trigger point disassociates it from the trigger point, but does not delete it from the database.
A policy group is not reusable—once the policy group is disassociated from a trigger point, it can not be referenced.
Any changes made to a trigger point by adding or removing policies or policy groups or by modifying execution options take effect at runtime and only for new user sessions. Therefore, you must sign-out and sign-in again to see any changes made.
Note: A policy that is associated with a single trigger point (either directly or within policy groups) cannot be removed from the trigger point. To disable such a policy, you must edit it and set the status to In Design.
To set priorities to policies, you may need to reorder policies or policy groups within a trigger point or a parent policy group. Reorder policies and policy groups by using the Reorder icon.
Click Add Policy to create a new policy and associate it with the trigger point. The Build a Policy page appears.
Click Add Policy Group to create a new policy group and to associate it with this trigger point.
A policy group may be used to set policy priority within a group, to deactivate policies, to nest child policy groups, and to assign preconditions.
Reuse a policy in multiple trigger points and policy groups if the contexts are compatible.
Click the Reuse Policy link in the Existing Policies/Policy Groups section of the Manage Trigger Points page to reuse an existing policy.
Select one of the policies listed in the grid by selecting the appropriate option. Click OK. The selected policy is associated with the trigger point or policy group.
This example illustrates the fields and controls on the Reuse Policies page. You can find definitions for the fields and controls later on this page.
Note: If a policy is reused within a single trigger point through direct association with the trigger point, or by association with a policy group within the trigger point, you cannot remove this policy from either the trigger point or the policy group within the trigger point. If you want to remove such a policy, you must deactivate the policy by setting its status to In Design.
Preconditions are combinations of one or more conditions. They are optional and only policy groups can have preconditions.
At runtime, the policies within a policy group are not evaluated unless the precondition evaluates to true.
For example, you could have a precondition defined for a self-service policy group, such as “Is this user on the internet?” Consequently, all policies within that policy group would not be executed unless the precondition of being on the internet evaluates to true.
Click Add Precondition to access the Add Precondition page.
This example illustrates the fields and controls on the Add Precondition page. You can find definitions for the fields and controls later on this page.
Select terms and operators; specify values on the right-hand side.
The following execution options can be specified for a trigger point or a policy group:
Field or Control |
Description |
|---|---|
Execute All |
This is the default, if specified for a trigger point. This option enables execution of all policies within a trigger point or policy group. During runtime, when executing policies within a policy group, the system adheres to the execution option specified for the policy group. |
Execute Limited Number |
Enables execution of a maximum (of the number specified) policies that evaluate to true. |
Use Parent Execution Options |
(Policy groups only). This is the default for policy groups. At runtime, this uses the execution options of either the trigger point or the parent policy group. |
This section describes the execution options and various scenarios of how they can be used.
Execute All
The Execute All option tests all policies in a trigger point; that is, all policies in the trigger point can cause actions to occur if their conditions prove true.
For example, if a trigger point has three policies and the execution option is set to Execute All, all three policies are evaluated.
Execute Limited Number
The Execute Limited Number option evaluates all policies in the trigger point until one of the policies' conditions evaluates to true. Therefore, suppose that you set Execute Limited Number to 1 for a trigger point that has three policies, where Policy 1 evaluates to false and Policy 2 evaluates to true; Policy 3 will not be considered and Policy 2 is executed.
Various Scenarios of Execution Options
Policy groups may have their own execution options that could affect the option setting. For example, consider the following diagram:
Diagram showing scenario 1 execution options
In Scenario 1, if Policy 1 proves false, then all policies in Policy Group 1 are evaluated because its execution option overrides the trigger point's execution option. Therefore, even though the trigger point is set to execute one policy, if Policy 2, 3, and 4 evaluate to true, those three policies' actions will execute.
Consider Scenario 2:
Diagram showing scenario 2 execution options
In this scenario, assume that all policy conditions are true; actions from Policy 1, 2, 3, 4, 5, and 8 will execute.
Consider Scenario 3:
Diagram showing scenario 3 execution options
In this scenario, the trigger point's execution option is the default (as is Policy Group 1). Assuming that all policy conditions are true, this trigger point executes exactly as in Scenario 2; that is, actions from Policy 1, 2, 3, 4, 5, and 8 will execute.
Consider Scenario 4:
Diagram showing scenario 4 execution options
In this scenario, assume that all policy conditions are true. The execution option for Policy Group 2 overrides that for Policy Group 1; therefore, all of the policy actions for Policy Group 2 execute. However, Policy 5 is not considered, nor is Policy 6 because three policy actions have already executed (Policy 2, 3, and 4).
Guidelines for Setting Execution Options
Unless you have a specific reason to set options, Oracle recommends using the default execution options. If only a few conditions could be true for a trigger point, and these conditions are logically exclusive (only one could be true at a time), set the number of policies considered to one (Execute Limited Number =1) to improve performance.
If, for whatever reason, only a few policy options should be considered, and no policy groups exist, setting a limitation for the trigger point is a good practice.
If you have a trigger point containing unrelated policies and a category of possible conditions that may be true, for which only one set of consequent actions should be taken, the best practice is to separate the unrelated policies into a separate policy group with a limitation on the number of policies allowed to fire.