Executable Design/Change-Time Actions on Your Asset Catalog
This section describes various executable actions on assets.
Lifecycle State Changes
CentraSite provides the ability to define and track the lifecycle of an asset by using a state model. CentraSite allows the use of active policies to govern specific transitions in the lifecycle management process of an asset.
The lifecycle management (LCM) system for an asset helps to:
Assess change impact and manageability across all service consumers
Ensure service quality through an integrated lifecycle approval process
Enable a single viewpoint for service stages and their artifacts
Typically, assets such as Web services pass through different states (designing, implementation, testing) before they can be used in a production environment. As the number of objects in a registry grows, it is necessary to introduce stages (Development, Test, Production) to provide adequate operational environments for all parties involved in the lifecycle. Furthermore, an organization may want to add conditions and rules for passing an object through the lifecycle. Therefore the registry should allow administrators to define roles and permissions and connect these to lifecycle steps.
Rules for changing Lifecycle state
For any given lifecycle model, a list of names of users and groups who are allowed to move assets to new states is maintained within the definition of the lifecycle model. For each user or group, the permission to move assets to new states can be restricted to a subset of the available states in the model. When the lifecycle model is assigned to an asset and a state has users or groups defined for it, only a user who is one of the defined users or groups can make the transition of the asset into that state. If no users or groups are defined for a particular state, any user who has Modify permission on the asset can change the lifecycle state for that asset.
Several rules determine who can change the lifecycle state of an asset. These rules are summarized in the following diagram.
For example: If you are the owner of a lifecycle model, you can assign any lifecycle state of this lifecycle to an asset whose asset type has this lifecycle model assigned, as long as you have the Modify Assets permission for the asset.
Any user who has the Create Assets permission can create an asset whose asset type has a lifecycle model assigned. When the asset is created, CentraSite automatically sets the lifecycle state of this asset to the initial state. However, to change the state from the initial state to another lifecycle state, the user requires the appropriate permissions as described above.
Note: | Manage Assets permission does NOT include the rights to change lifecycle states. |
Ownership Changes
In CentraSite, there are two concepts of ownership. An asset belongs to a particular user (known as the asset's owner) and it also belongs to a particular organization. The owner of an asset has special access rights to the asset and serves as the asset's main point of contact. The asset's organization determines whose rules of governance apply to the asset.
After an asset is created, it is sometimes necessary to change its ownership. For example:
You may want to transfer an asset
to another user if the original owner leaves the company, transfers to another position, or is otherwise unable to continue serving as the owner of an asset.
You might need to transfer ownership of an asset
to another organization when the asset reaches a point in its lifecycle where it is managed by a different group of users. When a service moves into production, for example, you may want to transfer it to your operations organization.
User Ownership
The user who adds an asset to the catalog automatically becomes the asset's owner. User ownership is specified by the asset's Owner attribute, which appears on the asset's details page.
The owner of an asset automatically receives Full permission on the asset. The owner also participates in various processes and policies that affect the asset. For example, the owner of an asset is responsible for reviewing and approving all consumer-registration requests that users submit against the asset.
When you change ownership of an asset, you transfer all the permissions and responsibilities associated with ownership of the asset to another user.
Note: | Certain predefined assets that are installed with CentraSite are owned by an internal user known as the default user. You cannot transfer assets to or from this user. |
Organizational Ownership
The organizational ownership for an asset is specified by the asset's Organization attribute. The organization to which an asset belongs determines which policies apply to the asset, which lifecycle model it follows, and which group of users have implicit permission to view the asset. In other words, it determines whose rules of governance apply to the asset.
An asset's Organization attribute is specified when a user adds the asset to the catalog. Users can add assets to any organization for which they have Create Assets permission. (Most users only have permission to create assets in their own organization, so most assets in the registry belong to the same organization as their owner.)
The organization to which an asset belongs is shown in the Organization attribute on the asset's details page.
Note: | In some parts of the user interface and the CentraSite API for JAXR documentation, the organization to which an asset belongs is referred to as the submitting organization. This is simply another way of referring to the organization that is specified in the asset's Organization attribute. |
Effect of Ownership Changes on Registry Objects
When you change the ownership of an asset, CentraSite modifies the asset's Owner and Organization attributes in the way you specify. Additionally, CentraSite:
Records the ownership change in the audit log.
Triggers pre- and post-update policies that exist for the asset.
Sends a notification to the inbox of the asset's previous owner and the new owner. This behavior can be suppressed by modifying a parameter of the Default Move Handler action that is activated by the Default Move Handler.
Updates the asset's instance level permissions (if the asset is transferred to a different user).
Updates the asset's lifecycle state (if the asset is transferred to an organization that has its own lifecycle model for the asset's type).
Before transferring an asset to another user and/or organization, review this information so you understand how the asset will be affected.
Effect of an Ownership Change on Permission Assignments
When you transfer ownership to another user, the Full permission that CentraSite implicitly grants to the owner of an asset is transferred to the new owner and taken away from the previous owner (the previous owner retains existing explicit permissions on the asset). CentraSite makes no changes to the instance-level or role-based permissions currently associated with the asset. This means that:
All instance-based permissions that are assigned to the asset will remain in effect after the transfer. For example, if group ABC currently has Modify permission on an asset, group ABC will continue to have Modify permission on the asset after the ownership change.
All role-based permissions remain as is. If a user currently has access to the asset through an organization-level role-based permission, the user loses access to the asset if it is transferred to another organization.
CentraSite Control makes no attempt to preserve a user's access to the asset by adjusting the user's role-based permissions. If you change the organizational ownership of an asset, you should review the role-based permission settings in the receiving organization afterwards to ensure that the asset is available to all the users who need it.
Policies that are Triggered During an Ownership Change
CentraSite treats an ownership change as an update to the asset. Thus, changing the ownership of an asset triggers the execution of any pre-update and post-update policies that apply to the asset. If a pre-update policy fails, the ownership of the asset is not changed.
Note: | When you transfer an asset to a different organization, CentraSite applies the policies of the receiving organization to the asset. |
Effect of an Ownership Change on Objects Associated with the Asset
If you transfer a composite asset to another user or organization, CentraSite automatically changes the ownership of all the asset's nonshared components.
Other than changing the nonshared components for a composite type, CentraSite does not change the ownership of any objects, assets, or repository artifacts that are associated with the asset. For example, if an Application asset has a Uses relationship with a Service asset, changing the ownership of one asset in this relationship does not change the ownership of the other.
After you transfer an asset to a new owner, review the asset and ensure that the new owner has permission to access the objects with which it is associated. Adjust the permission settings on those assets as necessary to ensure the new owner has access to them.
Effect of an Ownership Change on Other Versions of the Asset
Changing the ownership of an asset that is versioned does not affect any previous or later versions of the asset. When you transfer the ownership of a particular version of an asset, CentraSite transfers just that version. Other versions of the asset are not affected.
Effect of an Ownership Change on the Asset's Lifecycle State
If you transfer an asset to a different user, but you do not change its organization, the asset's lifecycle state is not changed. However, if you transfer an asset to another organization, the asset's state can change depending on the lifecycle model (LCM) that is in effect for the asset's type in the receiving organization.
The following table describes how the asset's lifecycle state is affected during a transfer to another organization:
If the originating organization uses... | And the receiving organization uses... | Then... |
No LCM for the type | No LCM for the type | The asset's lifecycle state does not change (that is, it remains unset). |
No LCM for the type | An organization-specific LCM for the type | The asset's lifecycle state switches to the initial state of the receiving organization's LCM. |
The system-wide LCM for the type | The system-wide LCM for the type | The asset's lifecycle state does not change. |
An organization-specific LCM for the type | No LCM for the type | The lifecycle state is removed from the asset. |
An organization-specific LCM for the type | An organization-specific LCM for the type | The asset's lifecycle state switches to the initial state of the receiving organization's LCM. |
Download Documents
CentraSite Control offers two methods of retrieving the source files of CentraSite assets, namely exporting and downloading. The source file is the file that was imported into CentraSite in order to create the registry entry for the asset. For example, the source file for a web service asset is the service's WSDL file. The source file for an XML schema asset is its schema file. The difference between exporting and downloading is as follows:
The
export feature creates a zip file containing one or more assets from the repository, as well as all associated registry objects.
The
download feature creates a zip file containing just the source file of a single asset from the repository, without any of the associated registry objects. If the source file refers to other source files in the repository (for example, a WSDL file can reference XML schema files), the referenced files will also be included in the zip file. If the asset refers to files in the Supporting Document Library, these can optionally be included in the zip file.
If an asset was not created by an importer, but was instead created from scratch without using a source file, the download feature can still be activated. In this case, however, the downloaded zip file does not contain an asset source file but instead only contains files from the Supporting Document Library that are attached to the asset.
Structure of the Zip File
The zip file is organized as a directory that holds all the downloaded files. Subfolders are only created if any of the names of the downloaded files are not unique; in this case, the files are stored in consecutively numbered subfolders (for example: 1/SchemaA.xsd, 2/SchemaA.xsd, and so on.).
If a downloaded file refers to one or more other downloaded files, for example if a WSDL file refers to a schema, the reference within the file is adjusted so that it points relatively to the file in the zip file. This is also true if the referenced file is located within a numbered subfolder.
Example: The WSDL file Service.wsdl refers to SchemaA.xsd, to another SchemaA.xsd with a different namespace and to SchemaB.xsd. The resulting zip file has the following structure:
Service.wsdl
1/SchemaA.xsd
2/SchemaA.xsd
SchemaB.xsd
Impact Analysis
CentraSite offers the possibility of viewing associations between the registry objects and hence identifying the impact when updating or deleting an asset in the catalog. This is called Impact Analysis.
The impact analysis feature enables you to easily navigate and visualize the associations between the catalog assets and registry objects. This feature helps you to:
Understand asset-to-objects associations by displaying the associations that exist between the catalog assets and other registry objects.
Check that existing associations between the assets and objects are not violated when you make changes in the registry. Also, check the external links from registry objects to supporting documents.
Determine the impact that updating or deleting an asset would have on its related objects.
You can visualize the currently defined associations for an asset with other registry objects, either in a graphical or a tabular form. The graphical representation is enabled through a Flash-based web browser.
Note that apart from the assets, you can also view the impact analysis for other CentraSite objects like organizations, users, groups, and roles through their shortcut menu.
Graphical Visualization
By default, the impact analysis is shown in a graphical form. You can switch to the tabular view using the link Switch to Tabular View. When you are using the tabular view, you can switch to the graphical view using the link Switch to Graphical View.
The graphical view shows a visual representation of the selected asset, the objects referred to by the asset, the objects that refer to the asset, and the asset's associations.
Here is an example of the impact analysis diagram for the asset CalculatorService, which is an asset of type Service:
The asset for which the impact analysis is being displayed is shown in a box with orange colored text (in the example, CalculatorService). The objects that are associated with the central asset are displayed initially in boxes with dark blue text on a lighter background (for example, the node Default Organization).
Associations between assets are represented by orange-colored arrows. Each association has a name and a direction (indicated by the arrowhead). For example, the diagram shows the association with the name Service that connects the Default Organization node to the CalculatorService node. This indicates that an association of type Service connects the two nodes. The arrowhead points to the CalculatorService node, indicating that Default Organization contains a service CalculatorService.
The display of the associations can be expanded or collapsed as required. If an association is shown with an orange plus sign, you can click on the plus sign to expand the association; this reveals the node or nodes at the other end of the association, and the plus sign changes to a minus sign. To collapse the association, that is, to hide the other end of the association, click on the minus sign, and the display reverts to its original state.
When you expand an association, the association's background color changes to blue. If you collapse a previously expanded association, its color remains blue; this way you can identify the associations that you have already visited. Associations that have not yet been expanded are displayed with a neutral background (that is, the same background color as the drawing canvas).
The text in the box for any collapsed association shows the following items of information:
The type of the association.
The number of currently invisible target nodes that are attached to the visible source node.
The object type of the invisible target node(s).
So, for example, the association labeled deployed on (1) Application Server in the diagram indicates an association of type deployed on between the visible source node Default Organization and a currently invisible node of type Application Server.
If you click on an object (as opposed to an association), a window appears with a short summary of the object's definition.
You can move the whole diagram within the web browser display by moving the cursor to an empty part of the diagram and dragging the diagram in the required direction.
You can rearrange the position of any node in the diagram by clicking on the node and dragging it to a new location on the canvas.
The display also contains a bird's eye view of the impact analysis diagram, for example:
The shaded central part is the part that is shown in detail in the full display. You can drag the shaded central part to any location in the bird's eye view, and the focus of the full display moves accordingly. You can minimize the bird's eye view by choosing the - icon. The minimized view shows just a menu bar with a + icon. To restore the view, click the + icon.
Predefined Configurations for Impact Analysis
You can use a filter to restrict the type of objects and associations displayed, and to specify the maximum depth of nesting for the displayed associations.
CentraSite provides the following built-in filter configurations that you can use to visualize the impact analysis for the various objects:
Asset Dependencies: This shows associations that are of particular relevance for assets.
Schema Usage: This shows associations that are of particular relevance for schema objects.
Organization Details: This shows associations that are of particular relevance for organization objects.
Service Details: This shows associations that are of particular relevance for service assets.
webMethods Assets: This shows associations between services and
webMethods Suite types like CAF and web applications.
By default, CentraSite displays the Asset Dependencies filter configuration. You can select a configuration that you require to visualize the asset's impact from the Configuration tab.
If required, you can choose the filter configuration that you want to customize, and change the filter settings accordingly. If you change any of the filter configurations and click the Refresh Canvas icon in the appropriate configuration menu, the display is updated as per your new settings. Any such changes you make apply also in subsequent login sessions. If you want to return to the original settings, delete the filter configuration; this deletes the current settings and restores the configuration to its original state.
Asset Versions
You can use the versioning feature in CentraSite to add an updated version of an asset to the catalog. For example, if you make significant changes to a Service asset (such as adding operations to the service or modifying the data types that it uses), you can use the versioning feature to add the new version of the service to the catalog.
When you version an asset, you become the owner of the new version of the asset. Ownership is not carried forward from the previous version. The new version of the asset belongs to the same organization as its previous version.
Versioning can be active or inactive for any given asset type. If you are using CentraSite in conjunction with other components of the webMethods Suite, the versioning capability for the asset types defined by these components is by default not activated. Unless the documentation for the webMethods Product Suite components states otherwise, do not activate the versioning for these asset types.
When you create a new version of an asset, CentraSite internally treats the new asset version as a new registry object and assigns a new internal object ID to it. The new version is related to the old version by a Supersedes association from the new version to the old version. In cases where the detail page of an asset has a Summary profile, the association is displayed under the Summary profile.
The metrics and event information that was collected for the old version of the asset remains unchanged in the CentraSite Registry Repository The old version's metrics and event information will not be copied to the new version. CentraSite begins collecting metrics and event information for the new version of the asset.
CentraSite maintains two sets of version numbers for an asset. One set is maintained for CentraSite's own internal use. CentraSite automatically assigns this version number when you create a new version of an asset. You cannot modify it. The version numbers assigned by CentraSite have the format <MajorVersion>.<Revision> and are always sequentially numbered starting from 1.0 (for example, 1.0, 2.0, 3.0). If the revision feature is enabled, the revision number is incremented automatically each time you modify the current version of the asset.
Each version of an asset also has a separate user-defined version identifier. This is the public version number that CentraSite Control shows to users when it displays the catalog. The user-defined version identifier does not need to be numeric. For example, you might use a value such as V2.a (beta) to identify a version.
Note: | Depending on the type of asset you version, some of the attributes are cloned from the original asset and others are not. For example, when you version a Service asset, the settings on the Classifications profile are cloned, however, the attribute settings on many of the other profiles, including the Permissions profile, are not. After you version an asset, you should always examine the attribute settings for the new version and set them appropriately. |
Asset Revisions
Within each version of an asset you can have several revisions. When revision processing is enabled, CentraSite stores a new revision of the current asset version each time you update the asset. In CentraSite Control you can view the stored asset properties for each stored revision.
For example, if you have an asset whose current version is 2.1, you may want to modify the contents of the Description attribute of the asset in the asset's detail page, but without creating a new version. In this case, when you save the new description of the asset, the version number is updated automatically by CentraSite to 2.2.
When revision processing is enabled, the revision number of an asset is initially 1 and is automatically incremented each time you save changes to the asset. When revision processing is disabled, all revisions of an asset except the most recent are discarded and the revision number is automatically reset to 0.
When you create a new revision of an asset, CentraSite internally treats the new asset revision as the same registry object and does not assign a new internal object ID to it.
Currently, when you switch the revision feature on or off, you can only do this for all assets in all organizations; there is no possibility of limiting the effects of revision processing to a subset of the assets or organizations.
By default, that is, immediately after the installation of CentraSite, revision processing is switched off.
Deleting an object also deletes all of its revisions. The constraints for deleting objects however apply only to the current revision. This means that all incoming associations that exist on the current state of the object have to be released before deletion.
If an object with existing revisions is exported, then only the currently selected revision is exported and the revision history is not exported.
Searching (including Advanced Search) always defaults to the current revision of an object. It is possible to express a revision label in an advanced search. If an advanced search expects revisions to be found, it is not possible to define additional search criteria.
Visualization of Revisions
When revision processing is switched on, you can view the revisions of any given asset by choosing the Versions tab in the asset's detail view. If an asset has several revisions, these will be shown. If an asset has not been modified since it was created, the asset's version will be shown with a single revision with the number .1
The following example shows an asset with two versions. Version 2 of the asset has two revisions, namely 2.1 and 2.2. Version 1 is unchanged since it was created and has therefore a revision 1.1:
If you want to view the asset properties stored for any particular revision, choose the link for the required revision. Note that you cannot change the properties of a revision of an asset version if there is a newer revision of the same asset version.
Instance and Profile Permissions
Permissions determine the operations users can perform and the set of objects users can access. You define the user-specific or group-specific permissions of an asset through the Permissions profile.
Instance-Level Permissions
Instance-level permissions grant users or groups access to a specific asset in the catalog.
CentraSite allows you to set permissions on an entire asset. This feature enables you to specify the actions they enable a user or group to perform asset in CentraSite Control. For any given asset, you can define View, Modify, Full permissions for different users and groups.
The instance-level permissions that can be set on a given asset for any user or group are:
Permission | Description |
View | Enables the specified user or group to the profile when they view the asset. |
Modify | Enables the specified user or group to modify the attribute settings in the profile when they view the asset. |
Full | Enables the specified user or group to delete the asset. |
Profile Permissions
CentraSite allows you to set permissions on individual profiles within an asset. This feature enables you to specify which of the available profiles can be viewed or edited by users when they display an asset in CentraSite Control. For any given asset, you can define different profile permissions for different users. For example, if an asset includes a profile called Source Control that displays links to your source control systems, you may want to restrict the visibility of that profile to authorized developers.
The profile permissions that can be set on a given asset for any user or group are:
Permission | Description |
View | Enables the specified user or group to the profile when they view the asset. |
Modify | Enables the specified user or group to modify the attribute settings in the profile when they view the asset. |
The individual profiles do not include the Full permission because users cannot delete a profile from an individual asset.
Important: | The profile permissions can be used to prevent users from viewing and accessing a particular set of attributes through CentraSite's graphical user interfaces. However, they do not restrict access to the attributes themselves at the asset level. |
Propagation of Permissions
An asset can have one or more dependent objects. For example, a Service asset can refer to a WSDL which in turn can refer to one or more XML Schema assets. You can optionally choose whether the permissions assigned to an asset instance should be automatically propagated to the asset instance's dependent objects.
In the context of CentraSite Control, propagation of permissions means that the new permissions completely replace the old permissions; the new permissions are not merged with the old permissions. As an alternative, you can use a change-time policy containing the action Set Instance and Profile Permissions. With this action, you can choose whether the new permissions will be merged with the old permissions or will replace the old permissions.
Propagation of Instance Level Permissions
By default, the access level permissions that are assigned on an asset are implicitly propagated to these dependent objects. This behavior is activated when you select the Propagate permissions to dependent objects check box in the asset's Permissions tab. For example, assigning Modify permission on a Service asset propagates the Modify permission to the asset's WSDL, schemas, and so on.
If you do not have permission to assign instance-level permissions to a dependent object, the dependent object will not be modified and a warning message is issued.
You can propagate permissions only for the following asset types:
(Web) Service
REST Service
OData Service
XML Schema
BPEL
Propagation of Profile Permissions
In addition to propagating permissions that control the access to an asset instance, it is also possible to propagate permissions that control the access to the asset instance's profiles. This means that the profile permissions that you define for an asset instance can be propagated to the asset's dependent objects. However, this is only possible if the dependent object is of the same asset type as the first object; this restriction arises because different asset types can have different sets of profiles.
This behavior is activated when you select the Propagate profile permissions check box in the asset's Permissions tab. This check box is only available for the following asset types:
(Web) Service
REST Service
OData Service
XML Schema
