CentraSite 10.7 | CentraSite User’s Guide | Policy Management | Introduction to Design and Change-Time Policies
 
Introduction to Design and Change-Time Policies
 
Execution of Design/Change-Time Policy
Design/Change-Time Policies Usage
Issues to Consider When Creating Design/Change-Time Policies
Design and change-time polices provide governance controls that you can use to effectively administer and manage web services and other assets within your SOA environment. Design-time policies enable you to control the acceptance of assets into the registry and manage their deployment into the runtime environment. You can use Design/Change-Time policies to ensure that assets entering the SOA environment conform to organizational standards and conventions, meet the architectural requirements of your enterprise, and adhere to industry best practices. You can also use policies to execute standard procedures, such as, initiating review processes, issuing notifications, and granting instance-level permissions at key points in an asset's lifecycle.
Design/change-time policies specify a set of actions that are to be executed when a specified event occurs to an instance of a specified object type. You use design/change-time policies to customize the behavior of CentraSite when certain events occur on assets and other objects in the registry (for example, during creation, modification, and/or deletion events). You can use design/change-time policies to perform tasks such as obtaining approvals, executing automated tests, issuing notifications, and imposing organizational standards when assets or other objects are created, modified, or deleted.
For example, a policy could instruct CentraSite to perform any of the following tasks:
*Verify that a schema name conforms to specified conventions when a new schema is added to the catalog.
*Submit a Web service to a review panel for approval before the service enters the Design state.
*Send an email notification to the IT organization when a service is deployed.
*Change the permission settings on an asset when the asset switches to the Available state.
*Assign a user in a given role to a particular group when a new user is added to CentraSite.
*Alter an asset's lifecycle path depending on the way in which the asset is classified.
Note:
The use of design/change-time policies is not supported if you are using a CentraSite Community Edition license.
A design/change-time policy has two major elements:
*action list: specifies the tasks (policy actions) that are to be executed.
*scope: specifies when the action list is to be executed.
Design and Change-Time Policy Actions
A policy action is a programmed task written in Java (a scripting language). A policy action can perform any type of work you require for example, sending an email, validating an attribute setting, submitting an approval request, updating a database. It can have one or more input parameters. An action that sends an email message includes input parameters that specify the text of the message and to whom it is to be sent. A policy action returns a completion code that indicates whether it completed its task successfully.
The action list in a policy can contain one or more actions. CentraSite executes the actions in the order that they appear in the list. If an action does not complete successfully, CentraSite immediately exits the policy and skips any remaining actions in the list. Policy failures are recorded in CentraSite's policy log.
CentraSite is installed with a library of built-in policy actions that you can use to construct policies. You can also develop your own custom actions using Java
Design and Change-Time Policy Scope
The policy scope specifies the conditions under which CentraSite is to execute the policy. It consists of two main parameters: Event Type and Object Type.
*The Event Type parameter: specifies the events to which the policy applies. An event represents a specific point during a registry operation when policies can be executed. Such points include the PreCreate event (the point in time just before CentraSite saves a new instance of an object to the registry), the PostCreate event (the point immediately after CentraSite saves a new instance of an object to the registry) and the PreDelete event (the point in time immediately before CentraSite deletes an object). Other events include the points in time before and after an update operation and before and after a state change.
*The Object Type parameter: specifies the types of objects to which the policy applies. Policies can be applied to any type of asset and to several other types of registry objects.
Together, the event type and the object type determine when the policy executes. You can make the scope as narrow or as broad as you need. That is, you can target the policy for one particular type of event and object (for example, a PreDelete event on an XML Schema) or apply the policy to multiple events and objects (for example, a PreCreate, PreUpdate, PreDelete event on a Service, an XML Schema, a BPEL Process).
Refining a Policy's Scope with Additional Selection Criteria
You can optionally refine the scope of a policy to narrow the set of objects to which the policy applies. To do this, you include additional selection criteria based on an object's Name, Description, or Classification properties. For example, you might create a policy that applies only to Application Servers whose name includes the string myDomain.com or to Application Servers that are classified as Software AG Runtime.
The ability to execute policies based on object classification is an especially effective way to selectively apply policies to objects.
Scope of a Policy Action
A policy action also has a declared scope. The action's scope specifies the object and event types with which the action can be used. Some actions have very specific object-type and event-type requirements. For example, you can use the Validate Policy Deactivation action only during a PreStateChange on a policy object. Other actions support a broad range of object and event types.
A policy can contain only actions that support the full set of object types and event types specified by the policy's scope. For example, if you create a policy that executes on the PreCreate and PreUpdate events for XML Schemas, it can only contain actions whose scope includes the PreCreate and PreUpdate event types and the XML Schema object type.
When you create a policy, CentraSite's user interface only allows you to select actions that satisfy the specified scope of the policy. If you subsequently change the policy's scope, CentraSite does not allow you to save the updated policy unless all of its actions support the policy's new scope.
Objects on Which Design/Change-Time Policies Can Operate
Design/change-time policies operate on the objects that CentraSite manages. The types of objects to which you can apply design/change-time policies are:
*Organizations
*Users (Note that policies you apply to User objects are enforced when events occur to the User objects in the CentraSite registry, not when events occur in the external naming directory.)
*Taxonomies
*Policies
*Assets. (You can create policies that apply generally to all policy-enabled assets or to specific policy-enabled types.)
*Report Templates
*Lifecycle Models
Applying Policies to Assets
The type definition for an asset includes a property setting called Policies Can Be Applied. This property determines whether assets of the given type are policy-enabled (that is, whether design/change-time policies are to be executed against them). When this property is enabled, you can create policies that are specific to the assets of that type. Additionally, instances of that type are capable of triggering design/change-time policies that target "assets" in general.
By default, the Policies Can Be Applied property is enabled for an asset type. If you do not want instances of particular asset type to be affected by design/change-time policies, disable this property in the asset's type definition.
Applying Policies to Virtual Types
When an asset is an instance of a virtual type, the set of policies that CentraSite applies to the asset depends on the virtual type's Inherit Base Type Policies setting. If the type's Inherit Base Type Policies option is enabled, CentraSite applies the policies of the base type to the asset in addition to the policies of the virtual type. For example, the Inherit Base Type Policies option is, by default, enabled for virtual services. Therefore, when CentraSite enforces policies for a virtual service, it applies the set of policies that are defined for the Virtual Service object type and the set of policies that are defined for the Service object type (the base type for the Virtual Service type).
If you disable the Inherit Base Type Policies option for a virtual type, CentraSite applies to the asset only the policies that are defined for the virtual type. For example, if you disable the Inherit Base Type Policies option for the Virtual Service object type, CentraSite applies to virtual services, only the policies that are defined for the Virtual Service type. Policies that are defined for the Service type are not applied.
The following table summarizes how the set of policies that CentraSite enforces for a virtual type is affected by the state of the Inherit Base Type Policies option:
If the virtual type's "Inherit Base Type Policies" option is...
And the policy is defined for the...
The instances of the virtual type will have...
ENABLED
Base Type
Base Type Policies
ENABLED
Virtual Type
Virtual Type Policies
ENABLED
Base Type
—AND—
Virtual Type
Base Type Policies
—AND—
Virtual Type Policies
DISABLED
Base Type
None
DISABLED
Virtual Type
Virtual Type Policies
DISABLED
Base Type
—AND—
Virtual Type
Virtual Type Policies
For more information about virtual types and the Inherit Base Type Policies option and which predefined types in CentraSite are virtual types, see Inheriting Base Type Profiles, Lifecycle Models, and Policies.
Note:
The Inherit Base Type Policies option does not affect policies that are assigned to the generic Asset type (that is, policies that apply to all assets). Policies that are associated with the Asset type are applied to both base types and virtual types, irrespective of the Inherit Base Type Policies setting.
Pre-Operation and Post-Operation Event Types
Many of the event types to which you can apply policies represent pre-operation events or post-operation events.
*Pre-operation events occur immediately before a requested operation is performed on a registry object. They include PreCreate, PreUpdate, PreStateChange, and PreDelete event types. When you apply a policy to a pre-operation event, CentraSite executes the requested operation only if the pre-operation policy executes successfully. You generally apply policies at these points to prevent the requested operation from being executed unless an object satisfies the verification checks performed by the policy.
*Post-operation events occur immediately after a requested operation is performed on a registry object. They include PostCreate, PostUpdate, PostStateChange, and PostDelete event types. When you apply a policy to a post-operation event, CentraSite executes the policy only if the requested operation is performed successfully. Post-operation polices are often used to notify users (through email) that certain modifications have occurred in the registry to update specified attribute values and to assign permission settings on an object.
Events during Which Design/Change-Time Policies Can Be Enforced
You can apply design/change-time policies when the following events occur to an object in CentraSite:
Event
Occurs...
Pre-Create
Immediately before CentraSite commits a new object to the registry.
Post-Create
Immediately after CentraSite commits a new object to the registry.
Pre-Update
Immediately before CentraSite commits an update to an existing object in the registry.
Post-Update
Immediately after CentraSite commits an update to an existing object in the registry.
Pre-Delete
Immediately before CentraSite removes an object from the registry.
Post-Delete
Immediately after CentraSite removes an object from the registry.
Pre-State Change
Immediately before a specified lifecycle state change is made to an object.
Post-State Change
Immediately after a specified lifecycle state change is made to an object.
OnConsumerRegistration
CentraSite Control: When an asset owner accepts a pending registration request by clicking the Apply Registration Policies button in the Pending Registrations inbox.
CentraSite Business UI: When a consumer requests access for an asset by clicking the Consume button in the Asset Details page.
OnTrigger
When you use the Run Policy Now button in CentraSite Control to run a policy on demand. For more information about this type of event, see Running a Policy on Demand.
OnCollect
When a handler process calls the collector. This event is intended to be used only by predefined policies that perform a collection process. For more information about collectors, see Collector and Handler Policies.
OnExport
When the export handler is called during an export operation. This event is intended to be used only by predefined policies that perform an export operation. For more information about export handlers, see Collector and Handler Policies.
OnMove
When the move handler is called during a move operation (the movement of an asset to another user or organization. This event is intended to be used only by predefined policies that perform a move operation. For more information about move handlers, see Collector and Handler Policies.
Supported Object and Event Combinations
Not all object types support the full set of events. Some events occur only with certain types of objects. For example, a PreStateChange event occurs only on Assets, Policies and Lifecycle Models. If you create a policy for a PreStateChange event on a User object, that policy will never execute, because a PreStateChange event will never occur on a User object.
The following table identifies the events that each object type supports:
Organization
Taxonomy
User
Policy
Lifecycle Model
Assets
Report Template
Pre-Create
Post-Create
Pre-Update
Post-Update
Pre-Delete
Post-Delete
Pre-State Change
Post-State Change
OnConsumer
Registration
OnTrigger
OnCollect
OnExport
OnMove
Actions that Design/Change-Time Policies Can Execute
An action in a design/change-time policy instructs CentraSite to perform a specific task, such as submit a request for approval, send an email notification to a group of users, perform a specified test or validate certain properties of an object.
Built-In Actions
CentraSite includes many built-in actions that you can use to compose design/change-time policies. Built-in actions are provided in the following categories:
Category
Descriptions
WS-I Compliance
Actions that test the conformance of a Web service to the basic profiles specified by the Web Services Interoperability organization (WS-I).
Design Time
Actions that you can apply when an object is initially added to CentraSite. In general, the actions in this category are designed to be used during a Pre-Create event.
Change Time
Actions that you can apply when an object within CentraSite is modified or deleted. This category contains actions that you use to obtain approvals, classify objects and perform various types of validation checks.
Global Templates
Actions that perform general tasks such as sending email notifications or setting permissions. The actions in this category can be used with nearly all event types.
ARIS
An action that notifies ARIS when changes occur to the business processes and services that have been published by ARIS to CentraSite.
Custom Actions
If you need to execute a task that is not provided by a built-in action, you can create a custom action to perform the work. A custom action consists of a Java class that performs the required task (for example, running a test, adding a required attribute, or updating an external database).
To use a custom action, you must upload the Java class to the CentraSite repository and define an action template for it. An action template specifies the location of your custom code and identifies the parameters that it uses. After you create the action template, your custom action appears in the CentraSite Control user interface and it can be inserted into a policy just like a built-in action.
System-Wide and Organization-Specific Policies
A design or change-time policy is either system-wide or organization-specific. System-wide policies apply to all organizations within an instance of CentraSite. Organization-specific models apply only to a specified organization.
Whether a policy is system-wide or organization-specific affects the policy's scope. When a policy is organization-specific, its scope is limited to the set of objects that belong to a specified organization. For example, if you create a policy that executes on a PreDelete event for XML schemas and you make that policy specific to organization ABC, then that policy executes only when XML schemas in organization ABC are deleted. If you make it system-wide, it executes when an XML schema in any organization is deleted.
Policy Priority
You can give a policy a priority value between 11 and 9999 (inclusive). Priority 11 is the default. Values less than 11 and greater than 9999 are reserved for system use.
The Priority setting contains a non-negative integer that indicates the policy's priority. A priority value of 0 represents the highest possible priority. You can give a policy a priority value between 11 and 9999 (inclusive). Priority 11 is the default. Values less than 11 (0 through 10) and greater than 9999 are reserved for system use. These priorities can only be assigned to predefined policies. You cannot assign these priority values to the regular, user-defined policies that you create using CentraSite Control.
Note:
A policy's Priority property is used only when CentraSite is given multiple policies to enforce for the same event. If CentraSite has only one policy to enforce, the Priority property is ignored entirely.
When an event triggers multiple policies, CentraSite examines the priorities of the selected policies and executes the policies serially, in priority order, from the lowest value to the highest value (that is, it executes the policy with the lowest value first). Each policy in the series is executed to completion before the next one begins.
For example, if an event were to trigger the following policies, CentraSite would execute the policies in the following order: B, A, C (as determined by the priority assignments 11, 25, and 100 respectively).
Policy
Priority
A
25
B
11
C
100
If two or more policies have the same priority value, their order is indeterminate. CentraSite will execute these policies in serial fashion after all lower priority policies and before any higher priority policies. However, you cannot predict their order.
Example
If CentraSite were given the following policies to enforce for an event:
Policy
Priority
Policy A
11
Policy B
25
Policy C
11
Policy D
100
Policy E (system policy)
0
It would execute the policies in the following order:
Policy
Priority
Policy E (system policy)
0
Policy A then Policy C (or vice versa) The order of these two policies cannot be controlled or predicted because they have the same priority.
11
Policy B
25
Policy D
100
Note:
The preceding example is shown for illustrative purposes. It is not a good practice to have an event trigger policies that have the same priority as exhibited by policies A and C above.
Policy Enforcement Time
The policy-enforcement process begins when a CentraSite user submits a request that acts on one of the object types. Depending on the type of request the user submits, one of the events identified can occur.
When an event occurs, CentraSite queries its database and executes policies that satisfy the following criteria:
*The policy's Event Type and Object Type settings match the given event type and object type.
—AND—
*The policy's object-selection criteria are satisfied by the object on which the event occurred.
—AND—
*The policy is scoped for the same organization as the object —OR— the policy is system-wide, meaning that it applies to all organizations.
Note:
It does not matter what kind of client submits the request or how the request reaches CentraSite. Design/change-time policies are applied to all requests, regardless of whether they come from the CentraSite Control user interface, or a JAXR-based client. Be aware that the execution of a policy can itself trigger another policy. This can occur if an action in a policy performs an operation that is within the scope of another policy.
Multiple Policies Triggered by an Event
When multiple policies have the same scope, all of those policies are triggered when an in-scope event occurs. To determine the order in which to execute these policies, CentraSite examines each policy's Priority setting.
Unsuccessful Design and Change-Time Policy Actions
When an action in a design/change-time policy completes its execution, it returns a completion code and a completion message. This information is written to the policy log if CentraSite is configured to log successful policies.
If the completion code indicates success, CentraSite performs the next action in the policy (if one exists) or completes the requested work on the object (for example, it commits the given change to the database).
If the completion code indicates failure, CentraSite records the error in the policy log. Then it immediately exits the policy. If the policy contains additional actions, those actions are not executed. If the policy was triggered by one of the pre-commit events (for example, during a Pre-Create, Pre-Update or Pre-State Change event) the requested operation is not performed. If the initial request had triggered multiple policies, any policy that had not yet been executed will be bypassed.
Predefined Policies Used by CentraSite
CentraSite includes a set of predefined policies that execute internal operations on the registry. Many of these policies relate to operations such as deleting objects, exporting objects and moving objects. By default, predefined policies are not shown in the policy list, however, you can view them by enabling the Show Predefined Policies option.
System policies often execute on events such as OnCollect, OnMove, and OnExport. For example, the OnMove event triggers the Default Move Handler policy, which makes the changes necessary to move an asset from one organization and user to another. If your site has special requirements, it can override certain predefined policies. For example, if you have an asset type that is not suitably exported by CentraSite's Default Export Handler policy, you can develop your own export handler policy to export assets of that type. .
Important:
If you belong to a role that includes the Manage System-Wide Design/Change-Time Policies permission, you have the ability to edit, delete, and deactivate CentraSite's predefined policies. However, you should not do this. These policies perform critical functions within the registry and must not be edited, deleted, or deactivated except under the direction of a technical representative from Software AG.