Processing Trees and Recursive Hierarchies in the Multidimensional Warehouse

This chapter provides an overview of tree and recursive hierarchy processing and tree and recursive hierarchy process results, and discusses how to run the Tree and Recursive Hierarchy process.

Understanding Tree and Recursive Hierarchy Processing

This section discusses:

• Trees and recursive hierarchies.

• OWE tree flattener versus MDW tree denormalizer.

• Hierarchies that are supported by the tree and recursive hierarchy process.

• Denormalized tree result balancing.

• Skip levels.

• Tree and recursive hierarchy source tables.

• Multilanguage Support for Relationship and Hierarchy Tables.

Trees and Recursive Hierarchies

PeopleSoft transaction applications store hierarchical structures in the form of trees and recursive hierarchies. In PeopleSoft applications, a recursive hierarchy is a data hierarchy in which all levels of data are from the same data table, and the parent-child relationships between levels are defined in the same source table. That is, recursive hierarchies are generic two-column tables, with the columns representing parent and child.

However, in the Multidimensional Warehouse (MDW), PeopleSoft hierarchical structures, such as trees, recursive hierarchies, and Address Book-based hierarchies (for Enterprise One) must be in denormalized form. This enables efficient data query, as well as integration with third-party business intelligence tools. PeopleSoft’s tree and recursive hierarchy processing provides the functionality to denormalize trees and recursive hierarchies for multidimensional reporting.

The Tree and Recursive Hierarchy process populates existing relationship and hierarchy tables, which are the source for business intelligence reporting. Unlike the original hierarchy structure—such as tree or recursive hierarchy—that the utility processes, the relationship table contains parent-child relationships within the structure not only to the direct children, but also to the indirect children of a node in the hierarchy. The denormalized structure enables you to use one simple join to access all lower-level entities within a hierarchy that are related directly or indirectly to a particular entity. For this reason, a relationship table is frequently used to facilitate further processing of a fact table, such as aggregation, or to integrate with a third-party reporting tool.

The extract, transform, and load (ETL) process that you use to create input tables for business intelligence reporting combines with the ETL Tree and Recursive Hierarchy process, enabling you to flatten and denormalize your data in a single process. You run the Tree and Recursive Hierarchy process at the same time you that run the ETL process to populate the MDW.

Note. The Tree and Recursive Hierarchy process cannot process some invalid trees. Specifically, it cannot process a tree that refers to a node that does not exist in the node table, as specified in the tree structure definition, and a tree that refers to a leaf that does not exist in the detail table, as specified in the tree structure definition.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager

OWE Tree Flattener Versus MDW Tree Denormalizer

This section details the differences between the MDW Tree and Recursive Hierarchy ETL utility and the OWE Tree Flattener utility. Understanding the differences in how these two utilities are used can help you understand why two separate tree processing utilities are necessary in EPM.

The PeopleSoft Tree and Recursive Hierarchy process has two parts: tree flattener and tree denormalizer. First, the process flattens a tree or recursive hierarchy into a relationship table. Next, the process denormalizes the data further into a hierarchy table. Although the processes are sequential, not all tree or recursive hierarchy tables must be denormalized into a hierarchy table. Thus, this step is optional. For example, you may not need to denormalize a hierarchy if you are not using it for business intelligence reporting, but only to facilitate fact data processing, as in aggregating data.

PeopleSoft trees, recursive hierarchies, and Address Book-based recursive hierarchies relate each node in a hierarchy only to its direct parent or child. Data stored in this way makes it difficult to access non-subsequent child notes (the “grandchildren,” or further removed generations) of a hierarchy. The relationship table, which is the result of the flattening part of the Tree and Recursive Hierarchy process, makes all generations related to a specific node easily accessible by associating each node in a hierarchy to any of its descendents, direct or indirect.

The output of the denormalization part of the Tree and Recursive Hierarchy process is a hierarchy table. A hierarchy table format associates the lowest level nodes to all of its parents, direct or indirect, in a row of data. That is, the data in a hierarchy table is denormalized such that a node relationship for a particular path within a tree or recursive hierarchy is represented in one row.

The Tree denormalizer process converts trees into a multicolumn data format so that they can be used by your selected business intelligence reporting tool. The output of the tree flattener portion of the process is the input to the tree denormalizer portion of the process. When you process a dimension, you must run the tree flattener and the tree denormalizer in sequential order. When you process a fact, if the fact uses a tree as its source, usually only the tree flattener is required.

You can control the Tree and Recursive Hierarchy process by specifying the hierarchy output table name for each tree or recursive hierarchy. If you do not specify a hierarchy output table name (Hierarchy Record Name), the denormalization process does not run, and the tree or recursive hierarchy is not denormalized.

Note. PeopleSoft analytical applications use a different ETL process for flattening hierarchical data. Do not confuse that process with the ETL process for business intelligence reporting described here.

Hierarchies Supported by the Tree and Recursive Hierarchy Process

This section reviews the hierarchies supported by the tree and recursive hierarchy process.

Source Database Tree

Source database trees are trees that exist in the source databases that supply data to the EPM warehouses. The source database tree is different from EPM tree, such that tree processing for a source database tree must consistently use the tree definition and underlying data from the source database that has been mirrored in the EPM OWS layer.

The following table provides a list of source tables in the OWS that contain source database tree definitions:

In addition to the source database tree definition tables that are listed in this list, the underlying data tables for trees are also used as the source for the source database tree processing. You must retrieve the name of the underlying data tables from the tree structure definition table; you will be asked to associate the data table for nodes and leaves when you create your trees. These data tables must already exist in the EPM OWS.

Sometimes the OWS data table name is not the same as the original data table name in the source database. You must refer to metadata console tables PS_MDC_JOB_SRC_REC and PS_MDC_JOB_TGT_REC to associate the OWS table name to its original name as it is found in the source database.

Source Database Recursive Hierarchy

The source table for a relationship or hierarchy table that is based on a recursive hierarchy of the source database data is the OWS table that is the mirror of the source database recursive hierarchy table. One example of the source database recursive hierarchy is the OWS Campaign table: PS_RA_CAMPAIGN.

Address Book Based Recursive Hierarchy

The Address Book-based recursive hierarchy is a specific case of a source database recursive hierarchy. It originates in the EnterpriseOne transaction database, and it is based on a recursive hierarchy that is stored in the F0150 table. The data in this table is copied into an OWS table called S_F0150. In order to decipher the Address Book-based recursive hierarchy, you need the OWS Address Book master table S_F0101 and the underlying data table. Some examples of the data tables for an Address Book-based recursive hierarchy are S_F03012 for Customer, S_F0401 for Supplier, and S_ F90CA040 for YouCentric Employee.

EPM Tree

EPM trees are typical PeopleSoft trees. They are created within the EPM database and are viewable through the PeopleSoft Tree Manager. The following table provides a list of EPM tables that contain tree definitions :

In addition to the EPM tree definition tables, the underlying data tables for the trees are also used as the source for the EPM tree processing. The name of the underlying data tables can be found in the tree structure definition table.

EPM Recursive Hierarchy

The difference between the EPM recursive hierarchy and the source database recursive hierarchy is that EPM recursive hierarchy stores its recursive hierarchy data in EPM OWE tables, rather than the copy of the source database recursive hierarchy table in the OWS.

Denormalized Tree Result Balancing

A tree is balanced if all of its branches, or paths, are the same length. For example, if one path of a balanced tree is three levels deep, then all of the paths in the tree must be three levels deep. An unbalanced tree has paths of varying length.

Some business intelligence tools, especially ROLAP tools, require that the denormalized dimension tables in the MDW be balanced to use data effectively. If you use a denormalized table for certain third-party business intelligence reporting, you must balance the hierarchy such that no columns contain blanks in the denormalized table. Because not all business intelligence tools require denormalized data to be balanced, the balancing process is optional. Because balancing occurs during denormalization, it has no impact on the tree flattening process.

If you choose to perform balancing, you can select up-balancing or down-balancing. Up-balancing is replicating detail data to a higher level. Down-balancing is propagating the lowest level nodes in a tree down to the node level next to the detail.

As a result of balancing an unbalanced tree, the description field for the newly created nodes contains a specific notation. This notation is <dd>~, where <dd> is the two-digit level number, for example 03 for level three, and ~, which is the special character that you select for the Hierarchy Balancing Infix field on the Hierarchy Group Definition page.

Note. The balanced node IDs remain the same as their original values.

The balancing process requires up to two parameters on the Hierarchy Group Definition:

• The flag to indicate that up-balancing, down-balancing, or no balancing process is to be performed.

• The special character to indicate that a node is introduced as a result of the balancing process.

  If no balancing is required, you do not populate this field.

Balancing Example

To provide an example of the balancing process, consider a simple tree with two levels: a parent node named auto and a child node named car. If the selected special character is ~, then these are the balancing results.

Balancing up:

Balancing down:

No balancing:

Skip Levels

Trees with strictly enforced levels require that each path of the tree has the same depth. You can skip a level if a portion of the hierarchy does not have nodes at that level. For example, one path in a tree may have levels A, B, C, and D, and another path may have levels A, C, and D (skipping level B).

Similar to tree balancing, skip level handling produces synthetic, or artificial, node entries to fill the gap in a denormalized table. For some business intelligence tools, especially ROLAP tools, you must close the gap produced by a skipped level to use the denormalized table effectively.

Because not all business intelligence tools require a skipped level to be closed, skipped level handling is optional. You use the same flag that indicates up-balancing or down-balancing for tree balancing to indicate processing of skip levels. The special mark for nodes that result from skip level processing is applied to the description field. The special mark is <dds>, where <dd> is the two-digit level number and <s> is the special character that you enter in the Skip Level Infix field on the Hierarchy Group Definition page.

Note. The special mark templates that you use for skip level balancing and for regular balancing can be the same or different than the other. For example, you can use <ddb> to refer to the result of balancing and <dds> to refer to the result of resolving a skip level, where dd refers to the level number, such as 03, b refers to the balancing infix character, such as ~, and s refers to the skip level infix character, such as #.

Skipping Levels Example

To provide an example of the skip-level process, consider the following summer tree:

Skip level summer tree

The following table represents the tree flattener result:

If the selected special character for balancing is ~, and the selected special character for skip-level handling is #, and the option is down balancing, then the skip level result the following result occurs:

Note. Due to space limitation, this example is rotated 90 degrees, with the table columns appearing in the rows.

Tree and Recursive Hierarchy Source Tables

The Tree and Recursive Hierarchy process can use as its source:

• A tree or recursive hierarchy originating in the source database and mirrored in the OWS.

• A tree or recursive hierarchy originating from the EPM database OWE.

• An Address Book-based hierarchy originating from an F0150 table (the Address Organization Structure Master), if the source is EnterpriseOne.

Note. The Tree and Recursive Hierarchy process cannot process trees that contain a combination of dynamic details and range details. This combination may yield incorrect reporting results when it is used with business intelligence tools.

Enterprise Tree and Recursive Hierarchy Source Tables

Enterprise recursive hierarchy tables are typically data tables; therefore, bringing them into the EPM OWS is similar to the process of bringing any source data table into the OWS using the source to OWS ETL jobs. Before you run the tree denormalizer part of the Tree and Recursive Hierarchy process, if you are using the source database's trees or recursive hierarchies, you must either first bring your source database tree and recursive hierarchy definition and structure tables into EPM OWS, or you must ensure that your EPM trees and recursive hierarchies exist in the EPM database.

This table lists the PeopleSoft Enterprise tree source tables that you bring into the OWS before running the Tree and Recursive Hierarchy process:

Enterprise One Recursive Hierarchy Source Tables

There is no tree structure for Enterprise One source tables. However, there are two types of recursive hierarchy tables:

• Recursive hierarchy information stored within a data table, such as F1640, the Activity Master table.

  Bringing these tables into the EPM OWS is similar to the process of bringing any source data table into the OWS.

• Recursive hierarchy information as separate from the underlying data table, such as F0150, the Address Organization Structure Master.

  Bringing tables into the EPM OWS is part of the MDW Tree and Recursive Hierarchy ETL process.

Multilanguage Support for Relationship and Hierarchy Tables

If your EPM database supports multiple languages, then you may need to apply multi-language capability in your relationship and hierarchy tables. You must have the language tables and also the corresponding outrigger tables. Language table names have an L prefix. Therefore, the name of your relationship language record is always prefixed with LR_, while the name of your hierarchy language record is always prefixed with LH_. The naming standard for outrigger tables is O prefix; therefore, OR_ is the prefix for your relationship outrigger record, and OH_ is the prefix for your hierarchy outrigger table.

The multi-language support for relationship and hierarchy tables are not built-in within the predelivered EPM warehouses. You must extend the warehouse by creating maps that populate the language and outrigger tables. You must also modify your reports to use the relationship and hierarchy tables, as well as their language and outrigger tables.

See Setting Up Multilanguage Processing and Running the Language Swap Utility (Optional).

Understanding Tree and Recursive Hierarchy Process Results

This section discusses tree flattener and tree denormalizer output tables and tree flattener and tree denormalizer results.

Tree Flattener and Tree Denormalizer Output Tables

Running the Tree and Recursive Hierarchy process creates:

• A relationship table created by the flattening portion of the Tree and Recursive Hierarchy process.

• A hierarchy table (if you run the denormalization portion of the process).

  In the hierarchy table:

  • The Tree and Recursive Hierarchy process denormalizes each node of a winter tree to the detail level.

  • The Tree and Recursive Hierarchy process denormalizes only the leaves in a summer tree to the detail level.

  • An unbalanced level, skip level, or both, has a special character infix, which you specified on the Hierarchy Group Definition page, for example ~ , concatenated with the tree node ID in the denormalizer output table TRDN.

Output Relationship Tables

The output table structures of the MDW flattened tree or recursive hierarchy relationship data are similar for all relationship tables, except for the keys, which indicate whether the trees are setID, business unit, or user-defined based.

Relationship tables capture the parent-child relationship between an entity and its direct or indirect children in a hierarchy. For this reason, relationship tables always have a parent column and a child column. In addition, because the EPM tree and recursive hierarchy process also handles source database trees and recursive hierarchy and all setID, business unit, and user-defined based trees, the key sets are adjusted according the tree or recursive hierarchy that is being flattened. Also, certain keys are not required because they may not be relevant, depending on the source type, tree, or recursive hierarchy. The flag, NODE_DET_FLAG, is used to indicate whether the entry is a node or a detail in the tree or recursive hierarchy. This field has translate values, where D indicates that the entry is a detail and N indicates that the entry is a node.

The MDW relationship table is also effective-dated. When the source is a tree, the effective date of the relationship data is the tree effective date. When the source is a recursive hierarchy, the effective date of the relationship data is the recursive hierarchy process date.

Relationship tables for recursive hierarchies also store the driver record description. The driver record is the recursive hierarchy table or the underlying data table, in the case of recursive hierarchies that are based on the F0150 table. The record description is obtained from the PeopleSoft record definition table (PSRECDEFN).

Because relationship tables have a description field, the hierarchy processing creates a related language table for the relationship table. This related language table has all of the keys of the base relationship table, plus one additional key, LANGUAGE_CD. (The non-key field that is in the related language table for the relationship table is the description field.)

Note. Relationship tables always have a prefix R_ to identify them.

The following table represents an output relationship table for setID based trees:

The following table represents an output relationship table for business unit based trees:

The following table represents an output relationship table for user-defined (no key) trees:

The following table represents an output relationship table for setID based recursive hierarchy trees:

The following represents an output relationship table for business unit based recursive hierarchy trees:

The following table represents an output relationship table for non business unit and non setID based recursive hierarchy trees:

Output Hierarchy Tables

For hierarchy tables, the keys match the keys of the trees or recursive hierarchy, either setID, business unit, or user-defined key based. Hierarchy tables capture all of the parent IDs and descriptions of a detailed entity in a hierarchy. For this reason, they always have an entity ID as a key. The prepackaged Tree and Recursive Hierarchy ETL utility supports data processing for a hierarchy that is up to 32 levels deep, including one level for details. Therefore, it has 32 ID and description columns. The ID column is named L<n>_ID, where n is the hierarchy level. The description column is named L<n>_DESC.

Hierarchy tables have a description field for each of the supported levels for denormalization. (PeopleSoft supports 32 levels for a table.) Except for the entity ID and description, which are the lowest level, the ID and description are named L<n>_ID and L<n>_DESCR, where n is between 1 and 31, which is one less than the number of supported levels.

The hierarchical data is also effective-dated. When the source is a tree, the effective date of the hierarchy data is the tree effective date. When the source is a recursive hierarchy, the effective date of the hierarchy data is the recursive hierarchy process date. Like the relationship tables, hierarchy tables for recursive hierarchy also have the record description as a key. The record is the recursive hierarchy driver record. The description is obtained from the PeopleSoft record definition table (PSRECDEFN).

Because a hierarchy table has a description field, the process creates the related language table for the hierarchy table. The related language table for the hierarchy table has all of the keys of the base hierarchy table, plus one additional key called LANGUAGE_CD. (The non-key fields that exist in the related language table of the hierarchy table are the description fields.)

Note. Hierarchy tables are always prefixed with H_ to identify them.

The following represents an output hierarchy table for setID based trees:

The following table represents an output hierarchy table for business unit based trees:

The following table represents an output hierarchy table for user defined (no key) trees:

The following table represents an output hierarchy table for setID based recursive hierarchy trees:

The following table represents an output hierarchy table for business unit based recursive hierarchy trees:

The following table represents an output hierarchy table for non business unit and non setID based recursive hierarchy trees:

Related Language Tables

You use flattened (relationship) tables and denormalized (hierarchy) tables for business intelligence reporting; therefore, the tables have description fields. Thus, both types of tables have related language tables for multi-language reporting. If your company does not require multi-language processing, you do not have to populate the related language tables on the Relationship Record Definition and Hierarchy Record Definition pages. However, you must still define the relationship record name on the Relationship Record Definition page, and if you are running the denormalization part of the process, you must also define the hierarchy record name on the Hierarchy Record Definition page.

The Tree and Recursive Hierarchy process populates related language tables only if you specify a relationship language and outrigger record on the Relationship Record Definition page or a hierarchy language and outrigger record on the Hierarchy Record Definition page.

See Setting Up Multilanguage Processing and Running the Language Swap Utility (Optional).

Tree Flattener and Denormalizer Results

The output of flattening and denormalizing trees depends on the type of tree: summer or winter, balanced or unbalanced, skip level, and so on.

Summer Tree

This graphic shows an example of a summer tree before processing and without any balancing:

Example of a summer tree before processing

Processing of this tree results in the following relationship table:

In a summer tree, the relationship table does not contain a tree node to itself or other node. Tree nodes only relate to the leaves. In addition, the child level numbers are always set to 0.

The following table shows the hierarchy table, without balancing:

Note. In the previous example, the columns for levels 3 through 31 are not populated because the balancing option is turned off. If the balancing option were turned on, levels 3 through 31 would also be populated.

If your relationship or hierarchy tables require multi-language support, then you must create the outrigger tables for the relationship and hierarchy tables.

Dynamic Summer Tree

This graphic shows an example of a dynamic summer tree (with relationships between departments and employees) before processing:

Dynamic summer tree

The following table represents the Department database table:

The following table represents the Employee table:

Processing of this tree results in the following relationship table:

The following table shows the hierarchy table, without balancing:

Winter Tree

This graphic shows an example of a winter tree before processing:

Example of a winter tree before processing

This table shows the winter tree relationship table after tree flattening:

In the relationship table, every node in a winter tree is associated with itself, as well as any nodes that are directly or indirectly under it.

This table shows the winter tree hierarchy after tree denormalizing:

Recursive Hierarchy

The following table provides an example of a recursive hierarchy table:

In a PeopleSoft recursive hierarchy, an Entity Parent ID = 0 implies that the entity is at the top of the hierarchy, if the entity is of numeric field. If the entity is a character field, then the highest-level entity will have Entity Parent ID = blank (that is, a space).

Because the lowest level entities in the hierarchy are of the same type as the parents, we can think of a recursive hierarchy like a winter tree. Therefore, the relationship and hierarchy table output from the Tree and Recursive Hierarchy ETL utility resembles the output format for a winter tree. That is, any node in the recursive hierarchy is associated with itself, as well as any nodes directly or indirectly under it.

The following table shows the hierarchy table without balancing:

Setting Up Parameters for Tree and Recursive Hierarchy Processing

Before you can run the actual Tree and Recursive Hierarchy ETL process, you must first define the parameters for process.

This section provides an overview of parameters for the Tree and Recursive Hierarchy process and discusses how to:

• Define the target and language tables for tree flattening.

• Define the target and language tables for tree denormalizing.

• Create the hierarchy group definition.

Defining Parameters for the Tree and Recursive Hierarchy Process

To run the Tree and Recursive Hierarchy process, use the Tree Hierarchy-Relational Table (TH_RELTBL_DEFN) component, Tree Hierarchy-Hierarchy Table (TH_HIERTBL_DEFN) component, and Tree Hierarchy-Hierarchy Group Definition (TH_HIERGRP_DEFN) component.

Because you must first flatten all hierarchies that are processed, you must define the relationship table that is the target for the flattening process. Because the denormalization process is optional, you must define the hierarchy table only if you intend to denormalize the flattened table.

The following diagram shows the Tree and Recursive Hierarchy ETL utility setup pages:

Tree and recursive hierarchy ETL utility setup pages

Pages Used to Run the Tree and Recursive Hierarchy Process

Defining the Target and Language Tables for Tree Flattening

Access the Relationship Record Definition page.

Relationship record name	Displays the target record for the flattening portion of the Tree and Recursive Hierarchy process.
Relationship language record	Enter the language record for this relationship table. This value is required only if this table is used for multi-language processing.
Relationship outrigger record	Enter the outrigger record for this relationship table. This value is required only if this table is used for multi-language processing.

Defining the Target and Language Tables for Tree Denormalizing

Access the Hierarchy Record Definition page.

Hierarchy record name	Displays the target record for the denormalizing portion of the Tree and Recursive Hierarchy processing.
Hierarchy language record	Enter the language record for this hierarchy table. You must enter this value only if this table is used for multi-language processing.
Hierarchy outrigger record	Enter the outrigger record for this hierarchy table. You must enter this value only if this table is used for multi-language processing.

Creating the Hierarchy Group Definition

Access the Hierarchy Group Definition page.

The Hierarchy Group Definition page contains a list of trees, recursive hierarchies, or both, that are related to a particular business process. For example, when you perform a workforce composition analysis, you must analyze data along organization, jobcode, and compensation code hierarchies. In this case, you can define the organization tree, jobcode tree, and compensation tree in one hierarchy group on the Hierarchy Group Definition page. Then, to perform workforce composition analysis, you need only to run tree processing using that hierarchy group ID as the parameter. When you run the Tree and Recursive Hierarchy process for that hierarchy group ID, the trees and recursive hierarchies that are associated with that ID are processed into either relational or hierarchical tables.

Note. The Hierarchy Group Definition page shown above is an example of this page using certain field values. If your field values differ, the fields that are available may be different. The following table of terms includes a list of all possible fields and the situations under which they display on this page.

Note. You can process multiple hierarchy definitions in one process. Use the + and – boxes on this page to add or subtract hierarchy definitions.

Running the Tree and Recursive Hierarchy ETL Process

After setting up the hierarchy parameters using the appropriate PeopleSoft Internet Architecture pages, you are ready to run the Tree and Recursive Hierarchy ETL process.

This section discusses how to run the tree and recursive hierarchy ETL process, which consist of the following steps:

1. Running OWS hierarchy jobs.

2. Running hash file hierarchy jobs.

3. Running hierarchy utility jobs.

Running OWS Hierarchy Jobs

This step is required only when there are source database tree hierarchies or Enterprise One address book based recursive hierarchies.

Perform the following steps to run the OWS hierarchy jobs:

1. In DataStage Director, navigate to the OWS hierarchy jobs by expanding the nodes in the left navigation panel, using the following path: EPM[release number]_Utilities, Tree_Recursive_Hierarchy, EsourceTree, StagingTreeMetadata, [warehouse name], Sequence.

   For an Enterprise One address book recursive hierarchy, use the following path to navigate to the OWS hierarchy jobs: EPM[release number]_Utilities, Tree_Recursive_Hierarchy, E1_AdrrBookRH, Staging.

2. Select all jobs in the Job Status view and select Job, Run Now... from the menu.

   The Job Run Options box appears.

3. Update the job parameters if necessary and click Run.

   The job is scheduled to run with the current date and time, and the job’s status is updated to Running.

Running Hash File Hierarchy Jobs

Perform the following steps to run the hash file hierarchy jobs:

1. In DataStage Director, navigate to the hash file hierarchy jobs by expanding the nodes in the left navigation panel, using the following path: EPM90_Utilities, Tree_Recursive_Hierarchy, Load_Hash_Files.

2. Select all the jobs in the Job Status view and select Job, Run Now... from the menu.

   The Job Run Options box appears.

3. Update the job parameters if necessary and click Run.

   The job is scheduled to run with the current date and time, and the job’s status is updated to Running.

Running Hierarchy Utility Jobs

Perform the following steps to run the hierarchy utility jobs:

1. In DataStage Director, navigate to the J_Hierarchy_Startup_Process job by expanding the nodes in the left navigation panel, using the following path: EPM90_Utilities, Init_Process, Init_Process.

2. Select the job in the Job Status view and select Job, Run Now... from the menu.

   The Job Run Options box appears.

3. Update the Hierarchy Group ID and Hierarchy Sequence Number job parameters with the appropriate values.

   To process all the hierarchies under a single group, provide the appropriate numerical value for the group ID. The sequence number can be left blank.

   To process a single hierarchy, both the Hierarchy Group ID and Hierarchy Sequence Number should be given while running the job.

4. Click Run.

   The job is scheduled to run with the current date and time, and the job’s status is updated to Running.