Chapter 12. Lifecycles

In this chapter, we will explore the following concepts:

• Designing lifecycles

• Using lifecycles

Business Process and Content Management

Workflows enable content-centric business process automation on Documentum. Workflows carry one or more objects through various activities performed by different performers. Lifecycles add a powerful dimension to this mix by enabling documents to move through states according to business rules.

Thus, Documentum not only automates business processes but also automates movement of content through various phases of its life — enforcing and automating business rules through both mechanisms. Lifecycles can also be used independently but the combination of the two opens up the possibilities for satisfying complex requirements.

The simplified, but core, difference between workflows and lifecycles is that a workflow is what people do and a lifecycle is what happens to a document. Let's extend the hiring process example from Workflows (Chapter...

Business Process and Content Management

Workflows enable content-centric business process automation on Documentum. Workflows carry one or more objects through various activities performed by different performers. Lifecycles add a powerful dimension to this mix by enabling documents to move through states according to business rules.

Thus, Documentum not only automates business processes but also automates movement of content through various phases of its life — enforcing and automating business rules through both mechanisms. Lifecycles can also be used independently but the combination of the two opens up the possibilities for satisfying complex requirements.

The simplified, but core, difference between workflows and lifecycles is that a workflow is what people do and a lifecycle is what happens to a document. Let's extend the hiring process example from Workflows (Chapter 11). Recall that the key document moving through the interview process is a candidate resume. For designing a lifecycle...

Lifecycle Concepts

A lifecycle is a set of linearly connected states that define the stages in an object's life. A state can be a normal state or an exception state. Normal states are used for normal progress through the stages and exception states help to deal with less frequent situations.

A lifecycle is associated with a set of object types and only objects of these types can apply this lifecycle. An object can be associated with at most one lifecycle at a time and it is in exactly one of the states present in the lifecycle. The object can move back and forth between the lifecycle states following the specified conditions and triggering changes in the process.

A state can have entry criteria that must be satisfied for an object to enter that state. When an object is about to enter a state, entry actions specified for that state are executed. Once an object has entered a state, any specified post-entry (post-change) actions are executed. Actions can be predefined actions or custom...

Lifecycles and Customization

Just like workflows, lifecycles are also a key component of Documentum customization. Lifecycles are usually bundled with other customization components in DocApps (see the chapter on DocApps for details).

A document lifecycle can be developed in the following manner:

1. 1.Analyze: The information is gathered about the relevant document types (or object types, in general) and the stages a document will need to go through. Also consider the conditions for state changes and what actions may be associated with them.

2. 2.Model: The lifecycle is modeled in terms of states, entry criteria, entry actions, and post-entry actions.

3. 3.Define: The model is formalized as a lifecycle using DAB. The lifecycle is validated and installed into the desired repository.

4. 4. Use: Business users with appropriate access start applying the lifecycle to objects. The objects can progress through the states via workflows, manual actions, or scheduled actions.

5. 5. Modify: If the lifecycle...

Analysis

Analysis of business rules for defining document lifecycles involves gathering information regarding the important stages in the life of a document type and the details around the transitions between these stages. Some additional information may also be captured about how the documents need to be managed within Documentum, as they progress through these stages. For example, it may be desirable to move the document to a new location and restrict access after a certain point in the document's lifecycle.

In the hiring process example, analysis may require talking to the Human Resources managers and the interviewers to understand if they want to sort resumes in different folders as they move through the hiring process and are later archived.

Modeling and Definition

Modeling and definition of lifecycles share several aspects and are discussed together in this section to avoid repetition. Modeling maps the requirements for the lifecycles to Documentum terminology to facilitate definition. The model is defined in a Documentum repository as a lifecycle using the Lifecycle Editor in Documentum Application Builder (DAB).

A lifecycle is a set of linearly connected states that define the stages in an object's life. A lifecycle is usually designed using DAB and is stored in the repository as dm_policy object. During development, the lifecycle has draft status. It can be validated for any errors and its status changes to validated if there are no errors. It is also possible to provide custom Docbasic procedures or SBOs (Service-based Business Objects) for performing custom validation. SBOs were discussed in Architecture (Chapter 4).

A validated lifecycle can be installed into a repository to make it available to all users, whereby its...

Use

Once a lifecycle has been installed into the repository, it can be used with the objects of types supported by the lifecycle. A lifecycle can be applied to an object of one of the associated types and then the object progresses through the lifecycle states according to the configured rules.

When a lifecycle is applied to an object, the object enters the initial state. An object can only be associated with one lifecycle at a time. Since different versions of an object are two separate objects, they can be attached to different lifecycles.

Note

A default lifecycle can be specified for a custom type. When an object is created for this custom type, the default lifecycle can be applied to it without explicitly selecting the specific lifecycle. This capability removes the need for the end users to identify a specific lifecycle.

In order to apply a lifecycle to an object, the user must have relate permission on the lifecycle or be the object owner.

An object can change state manually or automatically...

Modification

It is possible to modify a lifecycle after it has been installed and applied to objects. If the lifecycle needs to be edited, it is uninstalled and objects using this lifecycle cannot change their states. Once the modifications are completed, the lifecycle should be checked in, validated, and installed again.

Note

It is recommended not to create multiple versions of one lifecycle. The lifecycle should be checked in as the same version.

Help—Some DQL Queries

While DAB and Webtop can be used to interact with objects and lifecycles, the following queries can be used to obtain specific information directly.

The following DQL query identifies the lifecycle ID, current state, and the resume state (meaningful only if the current state is an exception state) for a document. Note, however, that all of this information is system data (internal) and not user-friendly. This information neither names the policy nor the states; they are all numbers.

SELECT r_policy_id, r_current_state, r_resume_state
FROM dm_document
WHERE object_name like 'MyDocument%'

The user-friendly information can be obtained from the lifecycle separately or by joining with the above query. The following query lists information about the states in a lifecycle named Resume:

SELECT object_name, state_name, state_description, state_class
FROM dm_policy
WHERE object_name = 'Resume'

Note that the state properties queried above are repeating properties and list all the...

Documentum Product Notes

Lifecycles are designed using the lifecycle editor in Documentum Application Builder. Typically, lifecycles are bundled in DocApps along with workflows and other customizations. Lifecycles provide powerful automation capabilities that can be used independently of workflows.

Checkpoint

At this point you should be able to answer the following key questions:

1. 1. What is a lifecycle? What purpose does it serve? How is it different from a workflow?

2. 2. What are states, state transitions, entry criteria, entry actions, post-entry actions?

3. 3. How can one apply lifecycles and check object states?

Test Your Understanding

1. 1. A lifecycle cannot be used without a workflow (True/False).

2. 2. In order to use a lifecycle:

   a. It must be instantiated

   b. It must be installed

   c. It must be applied to an object

   d. None of the above

3. 3. The entry criteria are evaluated on every state change (True/False).

4. 4. If a valid lifecycle has a Java-based entry action, the following can be added to the lifecycle while still keeping it valid:

   a. Another Java-based entry action

   b. A Java-based post-entry action

   c. A Docbasic-based entry action

   d. A Docbasic-based post-entry action

5. 5. For applying a lifecycle, the user must know its name (True/False).

6. 6. It is not sufficient for entry criteria to pass for a state change to succeed (True/False).

7. 7. A lifecycle is stored as an object of type:

   a. dm_lifecycle

   b. dmi_lifecycle

   c. dm_policy

   d. dmi_policy

8. 8. The lifecycle state of an object is stored in:

   a. Properties of the object

   b. Properties of the lifecycle

   c. Properties of the lifecycle instance

   d. None of the above...