CentraSite Documentation : Getting Started with CentraSite : Implementation Concepts : Defining Design/Change-Time Policies : Issues to Consider When Developing Design/Change-Time Policies
Issues to Consider When Developing Design/Change-Time Policies
The following are issues to keep in mind when creating design/change-time policies for your CentraSite registry:
*When an event occurs in the registry, CentraSite executes all policies whose scope encompasses the event. Use priorities to control the order in which CentraSite executes the policies. Consider assigning something other than the default priority of 11 to routine policies. Doing this will enable you to more easily interject higher priority policies for the events associated with those policies, should you ever need to do so.
*Many of the built-in actions provided with CentraSite (including the approval actions) are scoped for state-change events and can only be used with objects that are under lifecycle management. Before you create a policy, determine which policy actions you want to use and check the event types that they support. To create certain types of policies, you might need to first apply a lifecycle model to the objects that you intend to govern with those policies.
*Exercise caution when using OnTrigger policies! If the policy updates objects, be certain that the scope of the policy is set precisely and targets only the set of objects that you intend to change. Used inappropriately, this type of policy can change objects in ways that cannot easily be undone.
*By default, CentraSite is configured to record only policy failures in the policy log. You can optionally configure CentraSite to log both successful and failed policies in its log. However, if you do this, the log can grow quite rapidly. Consider logging successful policy executions only when it is necessary for tracing or troubleshooting purposes. Or, if you choose to enable this option as part of your normal operations, consider purging the log on a regular basis.
*When CentraSite executes a policy, the policy's actions are executed on behalf of the user who triggered the policy (in other words, the actions are executed under that user's account). If the user does not have the permissions necessary to complete an operation initiated by a policy action, the action (and thus, the policy) will fail. For example, if a user triggers a policy that sets permissions on an object, the policy will fail unless the user has Full permission on the object. (Only users with Full permission on an object are allowed to change the object's permission settings.)
Copyright © 2005-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback