Introduction to Design and 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.
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 |
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 | 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 Business UI 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 Business UI 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.
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).
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 Business UI, 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.