Inhaltsverzeichnis

Objects generally do not exist separately in i-doit but are in relation to each other. The servers are contained in racks, admins maintain servers, an operating system with software is running on a server ... In this article we will elaborate on the basic concepts of object relations.

Relation Types

Objects can be in various types of relations. To provide clarification each relation receives a type. Many pre-defined types of relations are already supplied by i-doit in the default installation. A listing of all these types can be found at Administration → CMDB Settings → Relation types.

 

 Relation titleDescription from the point of view of the master objectDescription from the point of view of the slave object
Administration serviceis administration instance for
is managed by
Assigned cardshas card
is card of
Backupsavessaved by
Chassisincludesis inserted to
Cluster memberships
is member of
has member
Cluster service assignmentis host for on
runs on
Connectorsis connected to
is connected with
Contact assignment (administrates)
administratesis administered by
Contact assignment (uses)usesis used by
Contract assignment
is contract of
has contract assignment
DBMSadministratesis configured in
Database access
is used by
has database access
Database gateway
has database gateway to
is database gateway
Database instance
is host for
runs on
Database links
has database link to
is database link of
Dependencyhas dependency to
depends on
FC port
supplies network
network is supplied by
Fileshas file assignment to
is file for
Group memberships
is member of
has member
Headquarter (Organization)
is headquarter of
is branch of
Host address
supplies network
network is supplied by
Interfacehas dependency to
depends on
Layer 2 Transport
transports Layer 2 Net
is transported by
Locationis location of
is located at
Logical devices (Client)
is connected to
is connected with
Logical locationis logical unit ofis assigned to
Network connections
is connected to
is connected with
Operating system
has operating system
is installed on
Organization (Organization)has member
belongs to
Organization (Persons)
has member
belongs to
Person group memberships
has member
is member of
Portssupplies network
network is supplied by
Power consumer
supplies power to
obtains power from
Remote Management Controller
is remotely managed by
is management controller of
Replication partner
is Replication partner of
has Replication partner
SOA-Componentis SOA component of
has SOA component
SOA-Stackshas SOA Stack
is SOA Stack of
Service assignment
is host for
runs on
Service component
is Service component of
has Service component
Share Accessshare is used by
has share access to
Software assignment
is running
runs on
Stackingis stack for
is stacked with
VRRPhas VRRP member
is VRRP member of
Virtual host
is administration instance for
is managed by
Virtual machine
is host for
runs on

Below the list of relation types a new type can be created using the Add new value button. If you wish to use this relation in a custom category, you have to define it as "Implicit".

Already documented object relations are listed in Extras → CMDB → Relations according to their respective type. When you click on All in the navigation tree to the left, all object relations are loaded regardless of their type. With large IT documentations it may take a while to load the list.

 

Relation Objects

When creating a relation between two objects, a third object of the type Relations is created in the background. The object title of this object consists of the object title of the master object, followed by the description and the object title of the slave object.

Example:

Master objectDescription of the relationSlave object
PDU-HQ-Intern-01-Asupplies power
ESX1

The relation object is required to save characteristics of the relation as attributes. This includes:

  • Relation type: see above
  • Weighting: see below
  • Service (optional): The object relation can be directly assigned to a service.

As it is already obvious, an object relation consists of a master and a slave object. This is a weighted relation. The slave object is dependent on the master object.

 

The direction of the relation (which object is the master and which one is the slave) has consequences for the CMDB explorer. Object relations are displayed recursively either upwards or downwards in the tree view. Master objects are below the slave objects in the standard profile.

License requirements for objects

Relation objects do not require a license.

Relations Category

Relations to other objects are gathered in the Relations category per object. This category is assigned to each object type in a fixed way and can be opened via the arrows icon.

 

Implicit versus Explicit Relations

Relations do not only have different types (see above) but they are also being created implicitly or explicitly. Implicit relations originate from categories. If the Location category is edited, for example, and an object which is higher in the hierarchy is selected in the Location attribute, then the implicit relation of the type Location will be created automatically in the background. This implicit relation is also shown in the Relations category at Extras → CMDB → Relations → Locations.

If you want to build a relation between two objects independent of the categories and their attributes, an explicit relation will be created. This explicit relation is created in the Relations category. The object where you are during that moment is pre-selected as Object 1. The object with which Object 1 is to be put into a relation has to be selected under Object 2. You also have to choose the direction between the two objects.  Dependency is selected as the default relation type, as it is already set as explicit at Administration → CMDB Settings → Relation types. But you can also easily define a new explicit relation and use it immediately. This can be carried out via the slips-icon, similar to the procedure with Dialog+ fields.

 

When creating a new explicit relation type, the type and the descriptions can be defined from the corresponding object views.

Implicit or explicit?

So what is better: Should you use implicit or explicit relations? The answer is: implicit relations. Categories and attributes are central elements for structuring the IT documentation. Users document in categories and that is also where users look for information. Therefore it is better to document unspecific relations of the type Dependency explicitly in a category in which implicit and explicit relations are varied. Both possibilities can be evaluated, but only the implicit relations are transparent.

Weighting

Each relation receives a weighting, as already mentioned above. The weighting is specified as attribute in the relation object. Values between 1 and 10 are possible as weighting. They express how dependent the slave object is on the master object. 1 means very important, while 10 means unimportant. 5 is the golden mean, it stands for important and represents the default value.

Example: A power supply receives its power from an UPS, so the weighting could be 1 (very important) as the power supply could not function without a usable UPS. However, if a node fails within the web cluster, other nodes take on its job. This means that the dependency to higher-level services is not as strong and could lie somewhere between 5 (important) and 10 (unimportant).

The Analysis module uses this weighting in combination with services and Network Monitoring to evaluate which services are affected by malfunctions.

Parallel Relations

Besides the direction-based relations with master and slave objects there exist also parallel relations in i-doit. The parallel relations also set two objects in relation to each other, however, without expressing a dependency on each other.

Example: When a web cluster with multiple nodes is documented in i-doit, the nodes act independently of each other. Only the functioning of the cluster depends on all nodes. The Cluster members category (or the mirrored category Cluster memberships) creates parallel object relations between the cluster members in the background.

A listing of all parallel relations can be found at Extras → CMDB → Relations → Parallel relations. They cannot be created by the user but are created implicitly and automatically in the background.

 

Object Relation in a Custom Category

Object relations can be documented in custom categories. You need to distinguish between two field types:

  • Object-Browser: No relation object is created. The relation to be documented here between two objects is not listed in the Relations category and the CMDB explorer does not process these relations.
  • Object-Relation: Here only an implicit relation type can be given as Addition. Explicit relations are not shown.

 

Object browser or object relation?

As for implicit and explicit relations the same question arises: Which field type is better? Here the answer is clear as well: The Object-Relation has additional uses and should therefore be preferred to the Object-Browser.