Propagation Rules

Administration > Service Health > Propagation Rules

Alternatively, click Propagation Rules.

Each propagation rule is defined per CI type and includes a condition and a task:

• Condition. The condition describes the CI type (CIT) of the child CI, the CIT of the parent CI, and the KPI assigned to the child CI. When these conditions are met, the task is applied.

• Task. The task describes which KPIs and business rules are propagated to the parent CI. The task may also include custom thresholds for the business rule used to set the status of the KPI.

Using propagation rules, you can specify that when a KPI is assigned to a CI, one of the following occurs:

• No KPI is propagated to the CI's parent CI.

• The same KPI is propagated to the parent CI, but with a business rule that is not the default group rule.

• One or more different KPIs are propagated to the CI's parent CI.

In the context of propagations, the relationship between a CI and its parent CI is defined by the CI Impact links.

The propagation mechanism is triggered when a link between two CIs is added or removed in the RTSM or when you assign a KPI to a CI or detach a KPI from a CI in Service Health administration. By default, KPIs are propagated as follows:

• Each KPI attached to any child CI of any parent CI is automatically propagated to the parent CI.

• The KPI is assigned the KPI default business rule and rule parameters, as defined in the KPI definition in the KPI repository.

• If they exist, the thresholds are defined in the business rule repository.

• The default propagation is not visible in the user interface, but you can modify the interface to your preferences.

• If a parent CI is already assigned a specific KPI and the propagation is defined as propagating the same KPI from the child CI, the KPI is not propagated from the child CI.

Note Propagation rules respond to changes within the KPI and rule repositories. For example, if you have defined a propagation rule using a particular KPI, and this KPI is removed from the repository, the propagation rule becomes invalid.

Propagation rules on higher-level CITs are inherited by their descendant CITs.

An inherited propagation rule cannot be deleted on a child CIT. If you delete a propagation rule on a parent CIT, it is deleted on its descendant CITs as well.

If there are two rules on a CIT, one inherited from a parent CIT and one assigned to the CIT itself, the rule assigned to the CIT itself will be applied.

You create a set of propagations for a topology, meaning that for each level of parent CI in the hierarchy, you must create a set of propagations. A lot of propagations are repetitive, so the correct procedure is as follows:

1. Create a set of general propagations of Type 1 for a specific parent CI.

2. Create a set of more specific propagations of Type 2 for a specific KPI and a specific parent CI.

3. Create a set of more specific propagations of Type 3 for a specific KPI, a specific child CI, and a specific parent CI.

4. Create a set of non-propagations of Type 4 for a specific KPI, a specific child CI, and a specific parent CI.

The propagations are then sorted and applied to each parent CI.

A propagation is defined per triplet (parent CI type, child CI type, and KPI attached to the child CI type). The matcher sorts the complete list of propagations according to the algorithm described below.

1. Parent sorting:

   • A comparison triplet parent CI that is equal to the propagation parent CI (the number of hierarchy levels is 0 in the model hierarchy) is better than a comparison triplet parent CI that is derived – with a larger number of hierarchy levels – from the propagation parent CI.

   • A comparison triplet parent CI that is derived, in the class model, from the propagation parent CI with a smaller number of hierarchy levels is better than a comparison triplet parent CI that is derived from the propagation parent CI, with a larger number of hierarchy levels.

2. Child sorting:

   The mechanism performs the same type of sorting as the parent CI sorting on the child CI.

3. KPI sorting:

   The sorting is performed on the KPI where the KPI corresponding to the triplet KPI is better than Any KPI.

For each KPI propagated from a child CI type to a parent CI type (comparison triplet), the matcher scans the list of sorted propagations to find the propagation that most closely matches the triplet. A propagation is considered a match when:

• The parent CI type and the child CI type in the propagation correspond exactly to the comparison triplet parent CI or child CI, OR the child CI class in the comparison triplet is derived (in the class model hierarchy) from the child CI type in the propagation and the same for the parent CI type.

  AND

• The propagation KPI has the same ID number as the comparison triplet KPI OR the propagation condition specifies Any KPI.

The first propagation in the sorted list is used.

The depropagation mechanism is activated in the following cases:

• When a CI is deleted from the impact model.

• When a link between two CIs is deleted from the impact model.

• When a KPI is deleted from a CI of the impact model.

  For details on the impact model, see RTSM Modeling.

There are two cases of deb-propagation:

• Case A: a KPI is deleted.

• Case B: a CI is deleted or the link between two CIs is deleted.

In case A, the deb-propagation mechanism performs the following steps:

1. Finds the matching propagation for the deleted KPI according to its triplet (child CI, parent CI, and KPI type).

   The selected propagation includes the set of KPIs that might have been previously propagated by the deleted KPI.

2. Retains from the potential KPIs only the KPIs that are currently attached to the parent CI.

3. Finds the propagations that match the KPIs attached to the child CI and its siblings.

4. Builds a set of the KPIs that might have been previously propagated by the matching propagations from step 3.

5. Removes the KPIs of step 4 from the set of KPIs of step 2.

6. The remaining KPIs are deleted from the parent CI.

7. The deb-propagation mechanism is then applied to the next level of the impact model topology for each one of the KPIs deleted in step 6.

In case B, the deb-propagation mechanism performs the following steps:

1. Finds all the matching propagations for all of the KPIs attached to all of the siblings of the deleted (or detached) CI.

2. Builds a set of KPIs attached to the parent CI that were not propagated by any of the propagations from step 1.

3. Deletes from the parent CI all of the KPIs from step 2.

4. Activates the deb-propagation mechanism described in case A starting with the parent CI and the set of KPIs deleted from it in step 3.

• If you propagate the same KPI A from different child CIs (CI1 and CI2) with a different propagation, the propagation that affects the parent CI (CI4) regarding KPI A can be either one of the propagations (from CI1 or CI2). Because of this uncertainty, it is recommended to avoid specifying different propagations that propagate the same KPI but with different rules, thresholds, or both.

  

• According to the previous limitation, if you propagate the same KPI A from different child CIs (CI1, CI2, or CI3), the propagation that affects the parent CI (CI4) regarding KPI A can be either one of the propagations. If you delete one of the CIs (CI2) or one of its KPIs, the configuration of KPI A (rule and thresholds) is updated and propagated from either CI1 or CI3. The update is not performed if the KPI was customized by the user.

  

To create a new or edit an existing propagation rule:

1. Go to:

   Administration > Service Health > Propagation Rules

   Propagation rules are defined according to the CIT. Select a CIT in the CI Types pane to view its defined assignments and propagations.

2. Perform one of the following actions in the Assignments for CI Type pane:

   • To create a new propagation rule on the CIT, click New. The Create Propagation Rule panel opens.

   • To clone an existing propagation rule, select a propagation rule and click  Duplicate. The new rule will be initially labeled Copy of <rule name> and you must rename it. The original propagation rule is still available, and the new propagation rule automatically opens for editing.

   • To edit an existing propagation rule on the CIT, select a propagation rule and click Edit. The Edit Propagation Rule panel opens. Note that changes to an inherited rule (marked with ) will affect all child CIs of the parent CI type.

3. Enter the following information:

   • In the General section, define general propagation rule information: the propagation rule name (display name) and its description (optional).

   • In the Condition section, define which characteristics a CI must have so that the KPI propagation rule is relevant for this CI. The condition includes the CIT of the CI, the impacted CIT, and the assigned KPI. When these conditions are met, the task is applied.

     The following conditions are available:

     Source CI type

     This is the CI type which you selected in the CI Types pane. You cannot modify this setting.

     Impacted CI type

     This drop-down list contains the impacted CI types. Select a CI type from the list.

     Alternatively, to browse the CI type tree, click ... to open the Impacted CI type pane. Select the CI type and click Select.

     Assigned KPI

     This drop-down list contains the KPIs that can be assigned to the child CI. Select a KPI to define the condition.

     If you select Any KPI, the condition is filled if the CI has any KPIs assigned. For example, if you do not want any KPI propagated to the parent CI, select this option and select the KPI Propagation option Do not propagate the KPI.

   • In the KPI Propagation section, you define which KPIs and business rules are propagated to the parent CI, when the condition is met.

     Do not propagate the KPI

     The KPI propagated from the child CI will not be propagated to the parent CI.

     Propagate the same KPI using a different rule

     The KPI is propagated by using a business rule that is not the default group rule defined for this KPI. You must specify the business rule to be used for the KPI on the parent CI.

     Propagate custom KPIs

     Different KPIs and rules can be propagated to the parent CI.

     The selected KPIs and business rules are listed in a table. To add a new KPI propagation, click Add propagation. To edit an existing propagation, click Edit.

     In the KPI Definition drop-down list, select the KPI definition. In the Business Rules drop-down list, select the business rule. Click Apply to apply the values or Discard to discard the changes.

   Propagation rules have no retroactive effects. If you make any changes to propagation rules, the changes only affect from that point on.

4. Click Create to create a new rule or Save to save a modified rule. The details of the created or updated propagation rule are displayed in the Propagation Rules pane.

If you have modified a predefined rule (for example if you changed the applicable KPI propagation rules), you might want to return the rule and its parameters to their defaults.

Note that this is only applicable for rules whose origin is Predefined (customized).

1. Within the central Business Rules pane, select a predefined (customized) rule, and click the Revert button.

2. The rule to be reverted is highlighted. Click Yes to revert the rule to default.

In the CI Type pane, click Filter to open the filter options. Enable one or more appropriate filter options by checking the following options:

• Show only CI types with assigned propagation rules to display only CI types with assigned propagation rules.

• View to display all propagation rules that are contained within a certain view.

• Show valid/invalid propagation rules to view the CIT tree with all the CIT nodes that have valid or invalid assignments.

  To resolve invalid assignments, open each assignment for editing. The panel that appears contains details on what needs to be fixed in the assignment definitions.