In the previous chapter we created a custom object type and some attributes for the News Article object. Let us now design a custom Lifecycle for the News Article object so that when an instance (or content object) is created from News Article object type, it can be moved across the various Lifecycle stages such as Staging (or Review), Approval, etc. before taking the content live. A Lifecycle object in Documentum is associated with some other related objects such as Alias Sets, Permission Sets (ACLs), etc. and it is advisable to quickly go through the introductory chapters to flip through the basics we discussed earlier.
Broadly speaking, while designing Lifecycles, you need to bear in mind three important components:
- Alias Set(s) for the Lifecycle
- Permission Sets (ACLs) for various stages in the Lifecycle flow
- Actual Lifecycle design such as stages, labels, any scripts for pre or post processing, etc.
We will cover each of these in this chapter, by taking very simple examples so that you get a certain level of understanding and comfort that can be further extended and enriched while designing real-time applications in software projects.
An Alias Set in the context of a Lifecycle is a group of Aliases that make a Lifecycle portable across numerous environments. An Alias is nothing but a placeholder or a symbolic name for some actual value in a given context called an Alias Name. An Alias Value is the actual value for the Alias Name. A pair of Alias Name and Value constitutes an Alias and a group of such Aliases constitutes an Alias Set.
Imagine that a content object for a News Article was created by a content author and reviewed by a content manager. In a given department, the content author could be Mr. X and the content manager could be Ms. Y. In another department, the content authors and managers could be different persons and not necessarily Mr. X and Ms. Y.
An Alias Set comes in handy in such circumstances, helping us design an application with symbolic names for content author/manager groups, the actual values for which are resolved by the system at run time as per the current context/environment.
You can specify multiple Alias Sets for a Lifecycle and have one of them designated as the default Alias Set; the others are treated as Additional Alias Sets. This is just the right time to discuss something called the scope of an Alias within Documentum. The scope of an Alias is the context in Documentum within which the system resolves the actual value for a given Alias name.
Documentum recognizes the following scopes:
- Lifecycle scope: An Alias Set for the Lifecycle. SysObjects in Documentum attached to the particular Lifecycle help the system resolve the values.
- Workflow scope: The Alias Set attached to the workflow process template is resolved at run time by finding the actual values of all performers in the workflow, whenever a workflow is started from the given workflow process definition.
- Session scope: The Alias Set for the life of a given Docbase session (session config object) helps the system resolve the actual value for an Alias.
- User scope: User scope is used to resolve Alias values from the Alias Set that was defined when the given users and groups were created within Documentum.
- System scope: This scope is used to resolve the values for Alias names for the Alias Set defined for the server config object for the given Docbase.
Whenever a content object is attached to a Lifecycle in Documentum, the system first evaluates all the Alias values based on the Alias Set attached to the Lifecycle object. This shows the importance of an Alias Set in the context of a Lifecycle. Hence, in this chapter, we will start by first studying how to create Alias Sets for a Lifecycle and then move on to build security in the various Lifecycle stages (using ACLs) and eventually create a full-fledged Lifecycle object.