Edition of Impact Analysis rules
ITSM Designer - Combodo's customers only
The “Impact Analysis” of iTop is based on the definition of “neighbors” for each class of object of the CMDB. The computation of the impact analysis starts from a given object and propagates to its neighbors, then to the neighbors of its neighbors, and so on. The definition of the “neighbors” of a given class is managed via a specific tab inside the ITSM Designer: “Impact Analysis”. This tab displays and manages only the direct neighbors of a given class.
Using the ITSM Designer, one can:
-
Add new neighbors to a given class
-
Remove neighbors from a given class
-
Change the properties of a neighbor
The Impact Analysis tab is divided in two panes:
-
The left pane shows the existing neighbors of the selected class, and is used to select a given neighbor
-
The right pane shows the properties of the selected neighbor
Principles
The diagram shown in the center pane looks similar to the Impact Analysis view in iTop (but only the direct neighbors are displayed, for clarity). The view is fixed, the elements cannot be moved around. One can click on an item (icon or arrow) to select the corresponding neighbor.
There are two types of neighbors:
-
The neighbors inherited from the definition of a parent class,
-
The neighbors defined on the current class.
The neighbors inherited from a parent class are displayed with a lighter color in the center pane.
When selecting such an inherited neighbor, the properties appear as read-only in the left pane and a special message is displayed at the top of the properties, with a button to jump to the class where this neighbor is defined.
The neighbors defined in the current class appear with a white line in the center pane. They can be modified by selecting them and editing the properties in the left pane.
When the definition of a neighbor specifies some redundancy, the neighbor is represented - as in the impact analysis - with an intermediate circle node containing the threshold of the redundancy:
Once a neighbor is selected, it points to a class. At the bottom of the properties, a drill-down button is available to navigate to this class:
Toolbar
The following toolbar buttons are available to manage the neighbors:
| Icon | Label | Action |
|---|---|---|
 |
Add Neighbor | Click on this button to display the form for creating a new neighbor on the current class. |
 |
Remove Neighbor | Click on this button to remove the currently selected neighbor. A confirmation will be asked. |
Neighbor Properties
When creating or editing a neighbor the following properties can be specified:
| Property | Meaning | Remarks |
|---|---|---|
| Specified by | How the neighbor is specified: either based on a relation represented by an existing attribute in the class, or by an explicit OQL query. | Only Power users can define neighbors based on OQL queries. For other users, the only possible choice is 'attribute' |
| Attribute | The attribute defining the relation to follow in order to reach the next neighbor of the current class | The allowed values are attribute codes representing a relation between two objects |
| Direction | Whether this neighborhood relation can be followed in both directions or only from the current class to the next neighbor | A bi-directional relation is needed to handle redundancy |
| Redundancy | The type of redundancy configured for this
neighbor: - None: no redundancy - Always enabled: the redundancy is enabled for all neighbors of this type - Enabled on each instance: the redundancy can be enabled/disabled on each instance of the neighbor class in iTop. |
If the redundancy is not “None”, a special attribute will be created in the neighbor class, in order to store the properties of the redundancy |
| Default threshold | The default value of the redundancy threshold | |
| Threshold unit | The unit for the threshold: either a number of objects or a percentage of the total number of source objects | |
| Threshold type | The value of the threshold can be: - Fixed: the same value will apply for all neighbors - Defined on each instance: the threshold can be configured on each instance of the neighbor class in iTop. |
If the Threshold type is
fixed, the Default threshold value will be
applied to all the objects in iTop, and will not be editable by the
end-user. If the Threshold type is Defined on each
instance, the value supplied in Default threshold
acts as the default value, but can be modified by the
end-user. |
| Downstream query | The OQL query returning the next neighbors from the current class. | Only Power Users can edit this property. The OQL
query can contain :this->xxxx placeholders to refer
to the fields of the current object. |
| Upstream query | The reverse of the Downstream
query. |
Only Power Users can edit this property. An upstream query is mandatory for configuring the redundancy on this neighbor. If the upstream query is not the exact reverse of the downstream query, unpredictable results will occur when the redundancy is configured. |
Example of Downstream and Upstream queries
To define that the “Application Solution” object is a neighbor
of the FunctionalCI class, one can simply use the attribute
applicationsolution_list, to achieve the same result
using OQL queries, the following queries must be specified:
Downstream query
SELECT ApplicationSolution AS A JOIN lnkApplicationSolutionToFunctionalCI AS L ON L.applicationsolution_id = A.id WHERE L.functionalci_id = :this->id
Upstream query
SELECT FunctionalCI AS CI JOIN lnkApplicationSolutionToFunctionalCI AS L ON L.functionalci_id = CI.id WHERE L.applicationsolution_id = :this->id
ApplicationSolution and can use parameters (in the
form :this->xxx which reference the
FunctionalCI class, whereas the Upstream
query must return objects of the class
FunctionalCI and can use parameters refering to the
ApplicationSolution class.Labels
When the redundancy is configured on an object, the display of the redundancy settings makes use of 4 labels:
| Label | Usage | Remarks |
|---|---|---|
| Field Label | This is the label used for the whole redundancy settings | This value is displayed either as the label of the field (when the redundancy settings are displayed in the “Properties” tab) or as a fieldset around the settings (when the settings are displayed at the bottom of a “relation” tab) |
| Redundancy disabled | The label displayed when the redundancy is disabled. | |
| Threshold is a count | The label displayed when the redundancy is defined by a specific number of items. | The placeholder %1$s must be present
in this label. It will be replaced by the actual value (in display
mode) or by an area where to type the desired value (in edition
mode). |
| Threshold is a percentage | The label displayed when the redundancy is defined by a percentage. | The placeholder %1$s must be present
in this label. It will be replaced by the actual value (in display
mode) or by an area where to type the desired value (in edition
mode). To display a percent sign in this label, one must escape it
by doubling the % character (i.e.
%%) |
Redundancy Settings
When a redundancy is specified, a special type of attribute
(AttributeRedundancySettings) is automatically added
to the neighbor class.
If the neighbor is defined by an attribute which is displayed as a dedicated tab in iTop (like many to many relations), the redundancy settings will be automatically displayed at the bottom of the corresponding tab (below the list of related objects).
If it is not the case, the redundancy settings must be displayed in the “Details” of the neighbor class. The designer appends this attribute into the “Details” Presentation of each class, but it is up to you to arrange this attribute at the proper place inside the details. Use the “Presentation” tab to edit the “Details” of each class then drag and drop the field to place it at the appropriate location.
Example: on the Server class, the two power supplies can be configured as redundant:
