Using PowerCenter Labels

Challenge

Using labels effectively in a data warehouse or data integration project to assist with administration and migration.

Description

A label is a versioning object that can be associated with any versioned object or group of versioned objects in a repository. Labels provide a way to tag a number of object versions with a name for later identification. Therefore, a label is a named object in the repository, whose purpose is to be a “pointer” or reference to a group of versioned objects. For example, a label called “Project X version X” can be applied to all object versions that are part of that project and release.

Labels can be used for many purposes:

• Track versioned objects during development
• Improve object query results.
• Create logical groups of objects for future deployment.
• Associate groups of objects for import and export.

Note that labels apply to individual object versions, and not objects as a whole. So if a mapping has ten versions checked in, and a label is applied to version 9, then only version 9 has that label. The other versions of that mapping do not automatically inherit that label. However, multiple labels can point to the same object for greater flexibility.

The “Use Repository Manager” privilege is required in order to create or edit labels, To create a label, choose Versioning-Labels from the Repository Manager.

When creating a new label, choose a name that is as descriptive as possible. For example, a suggested naming convention for labels is: Project_Version_Action. Include comments for further meaningful description.

Locking the label is also advisable. This  prevents anyone from accidentally associating additional objects with the label or removing object references for the label.

Labels, like other global objects such as Queries and Deployment Groups, can have user and group privileges attached to them. This allows an administrator to create a label that can only be used by specific individuals or groups. Only those people working on a specific project should be given read/write/execute permissions for labels that are assigned to that project.

Once a label is created, it should be applied to related objects. To apply the label to objects, invoke the “Apply Label” wizard from the Versioning >> Apply Label menu option from the menu bar in the Repository Manager (as shown in the following figure).

Applying Labels

Labels can be applied to any object and cascaded upwards and downwards to parent and/or child objects. For example, to group dependencies for a workflow, apply a label to all children objects. The Repository Server applies labels to sources, targets, mappings, and tasks associated with the workflow. Use the “Move label” property to point the label to the latest version of the object(s).

Note: Labels can be applied to any object version in the repository except checked-out versions. Execute permission is required for applying labels.

After the label has been applied to related objects, it can be used in queries and deployment groups (see the Best Practice on Deployment Groups). Labels can also be used to manage the size of the repository (i.e., to purge object versions).

Using Labels in Deployment

An object query can be created using the existing labels (as shown below). Labels can be associated only with a dynamic deployment group. Based on the object query, objects associated with that label can be used in the deployment.

Strategies for Labels

Repository Administrators and other individuals in charge of migrations should develop their own label strategies and naming conventions in the early stages of a data integration project. Be sure that developers are aware of the uses of these labels and when they should apply labels.

For each planned migration between repositories, choose three labels for the development and subsequent repositories:

• The first is to identify the objects that developers can mark as ready for migration.
• The second should apply to migrated objects, thus developing a migration audit trail.
• The third is to apply to objects as they are migrated into the receiving repository, completing the migration audit trail.

When preparing for the migration, use the first label to construct a query to build a dynamic deployment group. The second and third labels in the process are optionally applied by the migration wizard when copying folders between versioned repositories. Developers and administrators do not need to apply the second and third labels manually.

Additional labels can be created with developers to allow the progress of mappings to be tracked if desired. For example, when an object is successfully unit-tested by the developer, it can be marked as such. Developers can also label the object with a migration label at a later time if necessary. Using labels in this fashion along with the query feature allows complete or incomplete objects to be identified quickly and easily, thereby providing an object-based view of progress.