Hierarchies

Hierarchies represent the relationships between BMC Helix Capacity Optimization entities. Use hierarchies to perform actions such as: grouping entities for assigning access rights to users, deriving metrics from related entities, creating reports for related entities.

Relationships can be made between any two entities in BMC Helix Capacity Optimization, subject to these rules:

• A domain can be a parent of a system, or of a business driver, or of another domain.
• A system can be a parent of another system.
• A business driver can be a parent of another business driver.

For more information, see Entity relationships.

This topic contains the following sections:

Navigating the console workspace tree

The console workspace tree shows all of the visible parent-child relationships that are currently valid, by representing these relationships in hierarchies nested together under a single root domain named All Domains.

Workspace tree example

The console workspace tree displays only those relationships that are useful for organizing the workspace. These relationships are marked as visible. The Hierarchy tab of an entity shows all relationships that the entity plays a role in, whether visible or invisible.

If an entity is a child of two different entities, then the child is shown twice in the tree, once under each of its parents. Hierarchies can be nested recursively at any level, and therefore the same entity might appear multiple times in the tree at different levels.

You can modify the console workspace tree under All Domains by moving or importing entities from one parent domain into another. Moving an entity breaks its relationship to its parent and creates a new relationship to the new parent entity. Importing an entity into a domain adds a new parent-child relationship, while keeping the existing one intact.

To understand how to move or import an entity from one domain to another, see Adding system and business driver entities to a domain

Viewing systems and business drivers

The bottom portion of the console workspace tree is occupied by a folder named All systems and business drivers. This folder does not contain hierarchies, but instead contains systems and business drivers that do not fit into the hierarchies under All Domains:

• Newly discovered entities are those that have been created by connectors, but have not been placed inside any domain as child entities.
• Unassigned entities are those that once had been in the hierarchies under "All Domains", but whose connectors no longer place them inside any domain as child entities; nor are they imported into another domain as child entities.
• Dismissed entities are those that have been explicitly deleted. This folder is analogous to a "trash bin" or "recycle bin". Once the Dismissed entities folder is emptied, these entities and all of their data will be forgotten by BMC Helix Capacity Optimization.
• Unreachable entities are those whose connectors are no longer active.

To learn about the life cycle of entities, see Life cycle and status of entities.

Deriving measurements from hierarchies

Besides letting you organize and group entities, a hierarchy can also automatically produce calculated KPIs. For example, a hierarchy can calculate the average of a certain KPI over all children and associate this result to the parent. This is useful to obtain aggregated measurements over a set of measured objects.

The following figure is an example of a hierarchy that organizes the systems in a domain by hardware type; for each hardware type, the average CPU utilization of child systems is calculated.

Hierarchy example

Modifying the hierarchy

There are two ways to modify the hierarchy by creating or breaking parent-child relationships:

• Automatic: BMC Helix Capacity Optimization automatically creates relationships based on a hierarchy rule that is applied either regularly or every time new data is added by a connector.

• Manual: The user manually creates or breaks a relationship between two entities, for example, by adding or removing an entity from a domain.

An example of the automatic method is a hierarchy rule that places virtual machines under their virtual host. After the activation of this rule, a newly created virtual machine is automatically inserted into the hierarchy when new data is imported. Another example is a hierarchy rule added on behalf of a connector, which always inserts a host into a particular domain that stands for an owner, every time it runs and finds the host in its data source. If the connector finds the host no longer belongs to that owner, or that the host has been removed from its data source, then its hierarchy rule breaks the relationship, and the host disappears from its parent domain.

An example of the manual method is when a user moves a system from one domain to another domain. By default, BMC Helix Capacity Optimization will break the parent-child relationship with the first domain, and create a new parent-child relationship with the second. To understand how to move an entity from one domain to another, see Adding system and business driver entities to a domain.

If an entity is manually added as a child to a domain, then a relationship is automatically created, and the entity appears in the console workspace tree at the indicated location.
Any entity may have multiple parents, and such an entity will appear underneath each of these parents along with its own children and their children.

If an entity being automatically added to domain A by a connector is also imported into a second domain B, it takes part in two separate relationships, and the workspace tree will continue to show the entity under both domains.

If an entity is no longer attached as a child to any other entity in the console workspace tree, it is moved into the special Unassigned folder. If subsequently the entity becomes attached to a domain in the console workspace tree, then the entity is moved back from the Unassigned folder into the tree at the appropriate location. See Life cycle and status of entities to understand these transitions.

Viewing a hierarchy

If an entity has parents or children in the hierarchical structure, its main page shows the additional Hierarchy tab.In this tab you will find a table that lists all parents and all children (if any) for each hierarchy in which the entity is involved. In this case, the navigation tree will also show the hierarchy name as an expandable node. The available relationship types are listed in Entity types.

Each parent or child name can be clicked to navigate to the corresponding entity.

Creating a hierarchy

Manual hierarchies can be created as explained in Adding system and business driver entities to a domain.

How do ETL modules update a hierarchy

When an ETL modules runs, if it needs to create or maintain relationships between domains in the workspace tree and the entities that it is creating, an "Object relationships" hierarchy rule is created and activated on its behalf. Every time the connector runs, the hierarchy rule is scheduled to run after it in order to update the relationships that the connector asserted.

The assertions that a connector makes affect the hierarchy only indirectly.

The first time the connector asserts an entity and its relationship as a child of a domain or system in the tree, the hierarchy rule attaches the entity into the tree as asserted. For subsequent runs, the hierarchy rule compares the assertions made by the connector on the previous run with the assertions made on the last run. The hierarchy rule uses this comparison to modify the console workspace tree. This logic, called delta processing, makes the effect of automatic relationship assertions indirect.

• For every relationship asserted both on the previous and the last run, the hierarchy rule makes no change to the hierarchy in the console workspace tree.

• For every relationship asserted on the previous run but not asserted on the last run (presumably because the connector failed to find the entity or the relationship in its data source), the hierarchy rule breaks the relationship in the tree. If a relationship is broken and the child entity is no longer connected to any other entity in the console workspace tree, then the hierarchy rule disconnects the child entity from the tree and places it in the Unassigned folder.

• If a subsequent run of the connector rediscovers and re-asserts the entity and its relationship, then the hierarchy rule reinstates the relationship, and the entity reappears in the tree as a child of the domain. If the entity had previously been added to the Unassigned folder, it now disappears out of that folder.

To understand how relationships are represented in the database, see Entity relationships.

To understand how connectors can be written to update relationships to conform to an external entity catalog such as a configuration management database (CMDB), see Writing an extractor for CMDB.

If an ETL has completed running, it has only loaded its data into the stage area. If the ETL has also asserted relationships for the hierarchy, then this hierarchy is not built until the hierarchy rule actually runs.

An ETL task may or may not load the OBJREL dataset. If it does, then it has a hierarchy rule that will later run and create the hierarchy changes according to the OBJREL assertions.

How to check whether an ETL's hierarchy rule has run

Interfering with automatically updated relationships

If an entity E is moved from domain A, where it is being placed by a connector as a child, to a different domain B, then its relationship with domain A is broken. This break interferes with an automatic update of the same A-E relationship.

The automatic updates made by the connector will not revive this particular relationship. Because the connector will continue to assert the same relationship on every run, delta processing will not detect any change, and this relationship will remain broken.

If some unrelated cause in the connector's data source causes the entity to not be updated by a run of the connector, then delta processing detects that the relationship with domain A is broken, but because the tree already shows this relationship as broken, the hierarchy rule makes no changes. On the next run of the connector that re-asserts the relationship, its hierarchy rule will find a second delta, this time to recreate the relationship with A. From that point on, the entity will continue to appear as a child of both A and B.

You can clean up the effect of this kind of interference with automatically updated relationships, by using the Restore relations action on the Object relationships hierarchy rule corresponding to the connector task, as shown below. You can access the Hierarchy rules by navigating to Administration > Data Warehouse > Hierarchy rules.

Hierarchy rules example

You can click Restore relations to perform the following actions:

• Break all parent-child relationships ever created by this rule.
• Create all relationships asserted by the last run of the connector, without any delta processing.

As a result, the hierarchy is restored to the way the connector last asserted its relationships.