Updating Assets that are Under Lifecycle Management
If you need to update an asset that has reached the production phase of its lifecycle, you have a couple of choices. If you need to make a minor change, for example, you need to correct an attribute setting, add a classifier to the asset or modify the asset's description, an authorized user can simply make the change directly to the production version of the asset. If you are working in a multi-stage environment, you will need to manually apply the updates to the asset in each of the participating registries.
If the changes are substantive, in particular, if they involve changes to the structure of a schema or the definition of an interface, then you should create a new version of the asset. When you create a new version of an asset, the new version enters the initial lifecycle state, just as though it were a completely new asset. The new version of the asset will pass through the entire lifecycle just like any other new asset of its type.
If you are working in a multi-stage environment, you must create the new version on the registry that hosts the first stage of the lifecycle (that is, on the creation CentraSite). When the new version reaches the end state on that stage, you would promote the new version of the asset to the next stage just as you did with the previous version of the asset.
Creating a Different Lifecycle Path for a New Version of an Asset
For certain asset types, you might want to define separate lifecycle paths for new instances of an asset and new versions of an asset. For example, in a lifecycle for an XML schema like the one shown below, you might want new versions of existing schemas to bypass the Proposed state and go directly to the Design state.
Alternate Lifecycle Path for a New Version of an Asset
Creating an alternate path in a lifecycle requires the use of policies that conditionally change the state of an asset depending on the way in which the asset is classified. In the example shown above, this is achieved by doing the following:
Defining an initial state (the New state) through which all schemas (new or versioned) pass.
Creating policies that execute immediately after a schema enters the New state. These policies switch the schema to the Proposed state or the Design state depending whether the schema is classified as New or Existing.
To implement a lifecycle like the one above, you must add to the XML Schema asset type a Classification attribute that can be used to classify a schema as either New or Existing. (You would need to create a custom taxonomy to support this attribute.)
You must also create two policies that execute after a schema enters the New state: one policy that executes when a New schema enters the New state (this policy will switch the schema to the Proposed state), and one policy that executes when an Existing schema enters the New state (this policy switches the schema to the Design state).
Note: The example above describes how you can use policies to conditionally route an asset between two alternate paths when an asset enters the initial state of its lifecycle. However, you can use this same technique to establish alternate paths at any point in the asset's lifecycle. Its use is not limited to the initial state.
