System policies are predefined, design-time policies that CentraSite uses to perform internal operations (e.g., identifying the components associated with a given object) and registry-wide governance functions (e.g., ensuring the validity of policies prior to activation). Policies that are classified as predefined policies are system-wide in scope and execute at priority levels that are reserved for predefined policies. System policies are applied to assets regardless of the asset type's Policies can be applied property.
By default, predefined policies are not displayed by CentraSite Control. To view predefined policies, you must enable the Show Predefined Policies option on the Design/Change-Time Policy page.
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.
The following sections describe predefined policies.
The collector and handler policies are used to delete, move and export composite objects in a consistent way. Composite objects are objects that are made up, in part, of other registry objects. A Service object, for example, includes Operation objects, Binding objects and Interface objects. When you delete, move, or export a Service object, you want CentraSite to delete, move, or export the Service object and its related components. The collector and handler policies provide a way to consistently identify the set of registry objects that make up a composite object and treat those objects as a unit when performing delete, move and export operations.
To understand collectors and handlers, you must understand the concepts of shared components, nonshared components and required objects. If you are not already familiar with these concepts, review the material in the section Working with Composite Objects in the document Object Type Management.
Handler policies and collector policies operate together to delete, move and export composite objects.
The collector policy produces a list of the components (shared and nonshared) and required objects that are associated with a given instance of a composite object.
The handler policy performs the delete, move, or export operation (depending on the type of handler that has been invoked) on the given object based on the list of components and required objects the handler receives from the collector.
For example, when you delete an instance of a Service object, the Service delete handler policy invokes the Service collector policy to identify the set of components and required objects associated with that particular instance of a Service (e.g., its operations, bindings, interfaces, XML schemas, supporting documents and so forth). The delete handler then deletes the Service object and all of the nonshared components that were identified by the Service collector.
The following diagram illustrates how the handler and collector policies interact during a move, delete, or export operation.
An asset type must specify the handler and collection policies that are to be used to delete, move and export instances of its type. This is accomplished by defining a "HasHandler" association between the Type object and its handler and collection policies.
All types must have a "HasHandler" association to the four types of policies listed below.
| Kind of Policy | Description |
|---|---|
| Collector policy | A policy that executes on the OnCollect event and generates a list of the nonshared components, shared components and required objects associated with a given instance of the type. |
| Delete Handler policy | A policy that executes on the PreDelete event and deletes the components for a given instance of the type. |
| Move Handler policy | A policy that executes on the OnMove event and moves the components for a given instance of the type to another user and/or organization. |
| Export Handler policy | A policy that executes on the OnExport event and exports the components and required objects for a given instance of the type. |
Important:
An asset type must have one (and only one) of each of the four
kinds of policies shown above.
The following sections describe the predefined collector and handler policies installed with CentraSite.
The following table lists the set of default collector and handler policies that CentraSite uses for deleting, moving and exporting registry objects. The default collector and handler policies are used by many of the predefined types installed with CentraSite.
CentraSite also assigns the default handler policies to custom types that you create. CentraSite does not assign the default collector policies to custom types; this means that the default handler policies will continue as if the collector returned no objects.
Because CentraSite uses these policies for many of the predefined types and also assigns the handler policies to new types by default, you must not edit, delete or deactivate them.
| Policy Name | For more information |
|---|---|
| Default Collector | See The Default Collector. |
| Default Delete Handler | See The Default Delete Handler. |
| Default Move Handler | See The Default Move Handler. |
| Default Export Handler | See The Default Export Handler. |
The following table lists the specialized collector and handler policies that CentraSite uses for deleting, moving and exporting instances of certain predefined asset types.
The component lists for the various object types mentioned in the table are described in the section Working with Composite Types in the document Object Type Management.
You must not edit, delete, or deactivate any of the following policies.
| Policy Name | Description |
|---|---|
| Collector Policy For BPEL Process | Performs the collection process for BPEL Process objects. For a list of the components that this collector returns, see the BPEL Process component list. |
| Collector Policy For Process | Performs the collection process for Process objects. For a list of the components that this collector returns, see the Process component list. |
| Collector Policy for REST Service | Performs the collection process for REST Service objects. For a list of the components that this collector returns, see the XML/REST Service component list. |
| Collector Policy for Schema | Performs the collection process for XML Schema objects. For a list of the components that this collector returns, see the XML Schema component list. |
| Collector Policy for Virtual REST Service | Performs the collection process for Virtual REST Service objects. For a list of the components that this collector returns, see the Virtual XML/REST Service component list. |
| Collector Policy for Virtual Service | Performs the collection process for Virtual Service objects. For a list of the components that this collector returns, see the Virtual Service component list. |
| Collector Policy for Virtual XML Service | Performs the collection process for Virtual XML Service objects. For a list of the components that this collector returns, see the Virtual XML/REST Service component list. |
| Collector Policy for Web Service | Performs the collection process for Service objects. For a list of the components that this collector returns, see the Service component list. |
| Collector Policy for WS-Policy | Performs the collection process for WS-Policy objects. For a list of the components that this collector returns, see the WS-Policy component list. |
| Collector Policy for XML Service | Performs the collection process for XML Service objects. For a list of the components that this collector returns, see the XML/REST Service component list. |
| Collector Policy for IS Service Interface | Performs the collection process for Integration Server (IS) Service Interface objects. For a list of the components that this collector returns, see the IS Service Interface component list. |
| Virtual Service Export Handler | Performs the export process for Virtual Service objects. |
The following table lists the set of collector and handler policies that CentraSite uses for deleting, moving and exporting instances of certain registry objects that are not assets. You must not edit, delete, or deactivate these policies.
| Policy Name | Description |
|---|---|
| Asset Type Export Handler | Performs the export process for asset type definitions. |
| Collector Policy For Lifecycle Model | Performs the collection process for lifecycle models. |
| Collector Policy For Policy | Performs the collection process for Policy objects. |
| Default User Move Handler | Performs the move operation on users. |
| Taxonomy and Category Export Handler | Performs the export process for taxonomies and their categories. |
The Default Collector policy identifies the components and required objects for a given object. It does this by looking for specific kinds of associations between the composite object and other objects in the registry.
To identify the components of a composite object, the collector finds objects that are related to the composite object by an aggregation relationship or a reverse-aggregation relationship.
An aggregation relationship is indicated by the presence of an aggregated Relationship attribute in the composite object. Like a regular Relationship attribute, an aggregated Relationship attribute associates an asset with other objects in the registry. However, an aggregated Relationship attribute additionally indicates that the associated objects are components of the object that contains the aggregated Relationship attribute.
A reverse-aggregation relationship is indicated by a reverse-aggregated Relationship attribute that is present in another registry object and points back to the object on which the collection is being performed. Like a regular Relationship attribute, a reverse-aggregated Relationship attribute also associates an asset with other objects in the registry. However, a reverse-aggregated Relationship attribute additionally indicates that the object that contains the reverse-aggregated attribute is a component of the object at the end of the relationship.
Conceptually, both the aggregated and reverse-aggregated forms of the Relationship attribute establish a parent-child relationship between the object being collected (the parent) and objects that are its components (its children). However, the aggregated form expresses the relationship from the perspective of the parent object (i.e., the aggregated Relationship attribute exists in the composite object and identifies the object's components), whereas, the reverse-aggregated form expresses the relationship from the perspective of a child object (i.e., the reverse-aggregated Relationship attribute exists in a component object and identifies the composite object to which it belongs). The components that make up a composite object can be identified using aggregated Relationship attributes, reverse-aggregated Relationship attributes or a combination of the two.
Aggregated Relationship attributes are specified during the type definition for a composite object. Reverse-aggregated Relationship attributes are specified during the type definition of a component object.
In the list of components that the Default Collector returns to a handler, a component is marked as shared or nonshared. To determine whether a component is shared or nonshared, the Default Collector checks whether the component is associated with any objects other than the one on which the collection is being performed.
If the component is only associated with the object on which the collection is being performed, the Default Collector marks it as a nonshared object.
If the component is associated with other objects in addition to the one on which the collection is being performed, the Default Collector marks it as a shared object.
In addition to components, the Default Collector also locates the required objects that are associated with a given object. It does this based on presence of required-object Relationship attributes in the composite object.
Like aggregated and reverse-aggregated Relationship attributes, a required-object Relationship attribute identifies objects that are to be collected. When a composite object contains a required-object Relationship attribute, the Default Collector collects the objects that the attribute references and marks them as "required objects" in the list that it returns to the handler.
In addition to those required objects that the Default Collector locates based on the required-object Relationship attributes that it finds in a composite object, the collector also returns the following items as required objects:
The Type object associated with the object on which the collection is being performed
The repository items (i.e., supporting documents and other attached files) associated with the object on which the collection is being performed
The Default Collector policy is used by many of the predefined asset types installed with CentraSite. Do not edit, delete or deactivate this policy.
Important:
The Default Collector is triggered by an OnCollect event. The
sole purpose of this event is to trigger the collector policy for a given
object type. Do not attempt to use the OnCollect event to create additional
policies that execute before or after the Default Collector or any other
collector policy. Doing this can cause handlers to fail. Only one policy should
execute when an OnCollect event occurs, and that policy should be the
collection policy for the object type on which the OnCollect event
occurs.
The Default Delete Handler policy deletes 1) the object on which the delete operation was requested and 2) all of that object's nonshared components (as identified by the list that the collector returns to the handler).
The Default Delete Handler policy is used by many of the predefined asset types installed with CentraSite. CentraSite also uses this handler to delete policies and lifecycle models. Do not edit, delete or deactivate this policy.
The Default Delete Handler is automatically assigned to new types that you add to CentraSite.
The Default Delete Handler is different than the other handler policies in that it executes on an event (the PreDelete event) that is also used to trigger user-defined policies. The Default Delete Handler has a priority of 1, which ensures that it executes before any user-defined policies that are also scoped for the PreDelete event.
The Default Move Handler policy moves 1) the object on which the move operation was requested and 2) all of that object's nonshared components (as identified by the list that the collector returns to the handler).
The Default Move Handler policy is used by many of the predefined asset types installed with CentraSite. Do not edit, delete or deactivate this policy.
The Default Move Handler is automatically assigned to new types that you add to CentraSite.
Important:
The Default Move Handler is triggered by an OnMove event. The
purpose of this event is to trigger the move handler policy for a given object
type. Do not attempt to use the OnMove event to create additional policies that
execute before or after the Default Move Handler (or any other move handler
policy). Doing this could cause the handler to fail. Only one policy should
execute when an OnMove event occurs, and that policy should be the move handler
policy for the object type on which the OnMove event occurs.
The Default Export Handler policy generates an export archive file that contains 1) the object on which the export operation was requested and 2) all of that object's nonshared components, shared components and required objects (as identified by the list that the collector returns to the handler).
The Default Export Handler policy is used by many of the predefined asset types installed with CentraSite. CentraSite also uses this handler to export policies. Do not delete, deactivate or modify this policy.
The Default Export Handler is automatically assigned to new types that you add to CentraSite.
Important:
The Default Export Handler is triggered by an OnExport event.
The purpose of this event is to trigger the export handler policy for a given
object type. Do not attempt to use the OnExport event to create additional
policies that execute before or after the Default Export Handler (or
before/after any other export handler policy). Doing this can cause the handler
policy to fail. Only one policy should execute when an OnExport event occurs,
and that policy should be the export handler policy for the object type on
which the OnExport event occurs.
