Skip to main content
Matrix42 Self-Service Help Center

Configuration Item

Overview

A Configuration Item (CI) represents the entities in the system. It is a structural unit that combines heterogeneous data into an object, treated as a single entity. CIs identify the components of the system and consist of the  Data Definitions (DD) - independent building blocks that can be manually managed in the Administration application and have a physical representation in the database as tables.

CIs can be referred to as logical entities that describe the structure of the objects and put together different data structures for a specific purpose, for instance: an Incident, a Task, a Person, a user Account, a Service, a Computer, a Service Catalog, Currency, an Order Request, basically anything that is tangible or not and can be characterized by a number of attributes grouped within a single entity which is a Configuration Item.  

Each CI serves as a structural unit that allows accessing and modifying the data of the database since, by design, it cannot be accessed directly through the Data Definition. 

If you work with a dialog, you normally work with a CI. Also, Security and Imports are always based on CIs. The constituent parts of the Configuration Items - the Data Definitions - are used to compose the layout of the CI. You can define that the CI must necessarily contain data from a DD or you can make it optional. Also, the data of a DD can have multiple instances inside the CI.  

One of the biggest CIs in the system is the SPSComputerType, it references 33 different DDs. It contains single mandatory DDs for the basic values of a computer like the SPSComputerClassBase and a lot of optional multi DDs for inventory items and other settings used by components like License management.

If you delete an instance of a CI from the system, all rows associated with the instance from the different DD tables, included in the CI, are deleted as well.

You may also construct these kinds of CIs with the standard Schema, include the same DD in all CIs, but with a "Simple CI Base" DD you don't have the overhead of the type table.

Created Configuration Items are used in the User Interface Layouts and as filtering conditions of the Actions.

Configuration Item Types

There are two basic types of Configuration Items: Standard CI and Simple CI. The type of CI is defined once when the CI is created and cannot be changed later on.  

Both types of CIs must include one or more Data Definitions. The main difference consists in the purpose of the CI and whether or not its components (DDs) should be reused in the other CIs. The DDs also have several types and result in specific restrictions according to their types.

Standard CI 

Standard CI groups a set of heterogeneous data structures where, by design, each component can be reused as a part of other Configuration Item.

  • Database layout particularities: Standard CI automatically creates a hidden database table - the type table - with technical fields that cannot be managed via the user interface, but this table serves as the main reference table for the Data Definitions of a CI, although it was not specified explicitly.  This table has the same name as the CI and contains a column with the name ID of type unique identifier. This is the unique key that is used in every DD that is part of the CI as the common connecting value. This hidden table cannot be changed and cannot be used for custom attributes or relations. Also, this type table is a unique table used for only one CI. A detailed example of the Standard CI layout in the database you may find below.
  • Example: a Data Definition holding the Journal entries records. The same Journal DD can be reused in the Incident CI, Task CI, Problem CI, Knowledgebase Article CI, etc.

The example below shows a schematic layout of the Standard CI, where each block represents a database table:

CI_type.jpg

Simple CI

Simple CI usage is reasonable when the specified main Data Definition is not going to be reused as a part of another Configuration Item of either Standard or Simple CI type.

  • Database layout particularities: Simple CI is based on an explicitly declared and single already existing Data Definition that serves as the main reference table for the Configuration Item. Even though it cannot be reused as a part of another Configuration Item, the same Data Definition can be reused multiple times as the main reference table of different Simple CIs. Simple CI can be based only on a Data Definition of a Simple Configuration Item Base type. Simple CI does not generate any hidden reference tables and thus improves the performance when working with such CI object. A detailed example of the Simple CI layout in the database you may find below.
  • Example: a Data Definition holding the basic attributes of the Service Form records. A service form is a specific form or set of fields that should be filled by the portal user when placing an order with a particular service. For example, if configured, a specific service form should be filled when the customer orders a hardware product (e.g. asking for the delivery address of the ordered asset). Another service form may require other information, for example when ordering a software service you may be asked for the asset where this software should be installed. In both cases, the same Service Form DD will be used as the main reference table for the Hardware Service Form CI and the Software Service Form CI. The internal components of the CI are different, but the basic reference table is the same and the Main Data Definition always has the sole purpose and is not supposed to be reused as a part of other CI. 

The main differences of the Simple CIs from the Standard CIs are:

  • Type table function: in Simple CIs it is performed by the Main Data Definition table, which may have attributes and relations and such a type table can be used as a base for different CIs.
  • Purpose: it should be used for very simple CIs that contain only one table or CIs that are all based on the same set of attributes and relations.

The example below shows a schematic layout of the Simple CI, where each block represents a database table:CI_type_simple.jpg

Standard CI: DB layout example

CI_DB_layout_stadard.jpg

Simple CI: DB layout example

CI_DB_layout_simpleCI.jpg

Configuration Item Dialog 

The Configuration Item settings are available in the Administration application → Schema Configuration Items page:

CI_schema_admin_1.png

Select the existing Configuration Item record and click Edit action or use Add New Configuration Item action to open the Configuration Item dialog page.  

CI settings include two tabs, General and Advanced, and have the particularities as described below. 

Minimum required information allowing to create a CI:

General

Common settings for any Configuration Item include:

CI_general.png

Field Description

Internal Name

An internal name of the CI that cannot contain spaces or special characters. 

Non-changeable and unique, used as an identifier of the CI.

By default, all manually created CIs have an automatically suggested Prefix for Custom Schema Objects that can be modified in the Global Settings of the Administration application.

The prefix allows differentiating the provided by default CIs from the custom CIs without having to check the protection level of the CI:

CI_prefix_1.png

Display Name

CI name displayed in the user interface. 

CI_names.png

Description

Optionally, add a short description that may help differentiate the purpose or the use case of the created CI. This information is helpful when there are several identical CI Display Names. 

Configuration Item type

Configuration Item type can be defined only for the new CI and cannot be changed afterward.

Simple Configuration Item check-box has the following options:

  • enabled (default): the CI is created as a Simple CI and requires a Data Definition that will be used as a main reference table of the CI. Specify the Data Definition in the Main Type Class field. Optionally, add other Data Definitions, that should be included in the CI. The Data Definition from the Main Type Class field will be included in the CI by default and should not be added additionally.  
  • disabled: the CI is created as a Standard CI.

Data Definitions

Add necessary Data Definitions that should be included in the edited Configuration Item and choose cardinality for each DD:

CI_general_dd.png

Cardinality types:

  • Mandatory: Data Definition entity is required (e.g. basic data of an Incident Activity is required); 
  • Mandatory (Multi): at least one Data Definition entity is required;
  • Optional: there can be a single entity of the specified Data Definition and it is optional (e.g. a Service can optionally have not more than one schedule according to which the service should be activated);
  • Optional (Multi): there can be more than one entity of the specified Data Definition and they are optional (e.g. multiple Journal entries in the Incident).

Advanced Dialog Page

Most of the Advanced dialog page settings are related to Schema, and some of the data is related to business logic (e.g. the Support Multiple Currencies checkbox has nothing to do with the Schema and is not used by it but is nevertheless stored in the Schema):CI_advanced.png
Technical Details

Field Description
ID

A technical field for the auto-generated ID of the created Configuration Item.

This field is blank when you are creating a new CI and will be filled automatically when the CI settings are saved.    

Non-editable and unchangeable information once the CI is created.

ID is a unique identifier of the created CI and is used internally to trace the relations of the Data Definition records to the appropriate Configuration Item (see TypeID attribute in the Standard CI and Simple CI DB layout diagrams).

Protection level

This information is available in the CI's preview mode and indicates whether any changes can be made to the set of Data Definition components of the CI, i.e. whether they can be added and/or removed from the CI.

  • Custom: all manually created CIs by default have custom protection level. This protection level denotes that the CI's structure can be modified, extended or reduced at your own choice and necessity;
  • Customizable: the CI has basic components that cannot be removed from the CI structure. Such CIs structure can only be extended with manually added Data Definitions.  
  • System Internal: CI structure is a system component and its structure cannot be modified in any way.
Display expression

Specify an ASQL expression to retrieve data that will be displayed each time the Configuration Item instance is initiated. 

For example, Incident CI display expression settings result in the following data retrieval to the page elements that are not explicitly added to the page layout:

 CI_display_expression_1.png

Support Multiple Currencies

This property of the Configuration Item defines the default value of the Allow Change Currency option. This option is used in the Currency control of the Layout Designer.

Currency control can be added to the Dialog layouts and is designed to work with Data Definition attributes of the currency data type. The default value of the Allow Change Currency option defines how the currency data will be displayed in the user interface according to the Support Multiple Currencies check-box settings:

  • enabled: all newly added to the Dialog layout attributes of the Currency type (e.g. Price) that were included in the CI allow selecting the currency in the corresponding UI controls:
    CI_multiple_currency_enabled.png
    The Dialog saved with such currency appearance setting results in the following user interface element (if multiple currencies were configured in the application):
    CI_multiple_currency.png
  • disabled (default): the Currency attributes/controls show the Default Currency specified in the Global Settings of the Master Data application.
    CI_multiple_currency_default_disabled_layout.png
    Users will not be able to change the currency from the UI in this case:
    CI_multiple_currency_disabled_ui1.png

The Support Multiple Currencies property defines the default value of the Allow Change Currency option. It can be changed and adjusted manually as necessary along with the currency Display Type when editing the Dialog layout. 

Color

Optionally, specify the border color of the label shown in the Recents menu for the items of the current CI:

CI_color.png

 

"Create item" action

Optionally, define the icon and the position for the create a configuration item object action. The Create action is a generic action that is used on the Dataset View layouts.   

Icon

Choose an icon:

CI_create_icon_ui_1.png

Position

Enter an integer value to specify the position of the Create Item action among other Create actions of the Dataset View. The Create action with the smallest value specified here goes first in the list; the action with the second smallest value specified takes the second position, etc. 

Object State

A Configuration Item can optionally have a state that can be applied to each object, for instance:

  • Incident status can be New, Assigned, In Progress or Closed;
  • Service can be Released, Operational Blocked, Retired, etc.;
  • Knowledgebase Article status includes Draft, In Review, FInal, Expired etc.

Defined Object State characteristics are used as filtering conditions of the Actions:

 CI_object_state_actions_1.png

The example above does not show Close action for the closed Service Requests and Incidents. In other words, the action settings from the example allow showing Close action for all Service Request and Incident object types except for the items that have Object Status Values Closed(204). 

Status Values are suggested from the configured Object State properties for the CI:

Data Definition

the drop-down list suggests all Data Definitions that:

  1. were added to the current CI in the General tab of the CI configuration;
  2. have a suitable attribute with a reference to the Data Definition of a Pickup type (lookup table).
Attributes

a list of suitable for the object state attributes from a specified on the previous step Data Definition:

CI_state.png

State Group

an additional field available only for the Main Data Definition (SPSCommonClassBase). Initially, all statuses for different CIs were added to a single Data Definition and differentiated by the State Group:  

CI_object_state_1.png

The example shows that the Incident has a certain subset of states that are possible for an Incident CI, but only one set of object states can be used as the CI status.

Do not use the Main Data Definition (SPSCommonClassBase) if you need to create a new set of statuses for a specific data class. Any new set of object statuses that should be added to a CI must be created in a stand-alone Data Definition of pickup type and added to the suitable for the item Data Definition attribute.  

Autonumbering

Use these controls to set up auto numbering for items of this type (CI):

Every time a specified Data Definition item is created, an auto-incremental number is generated according to the pattern, specified in these settings: 

Prefix

the prefix added to the auto-generated item numbering, for instance:

  • INC is used for incidents;
  • SRV for services;
  • etc.
Digits

a number of digits the auto-generated number should consist of. For example, 5 digits with the specified SRV prefix result in such auto-incremental item numbering:

SRV00001, SRV00002, SRV00003, etc.

Data Definition

the automatically generated numbers are saved into the specified database table: for services it's SPSArticleClassBase.

Attribute
the automatically generated numbers are saved into the specified field of the chosen Data Definition: for services. .it's ServiceID. 

 

 Archiving

Enabled

Check-box options:

  • enabled: the system checks the specified ASQL condition from the History Expression field and archives appropriate CI records according to the schedule (normally triggered over the weekend). 
  • disabled (default): records archiving is disabled. 
History expression

CI_archiving_example.png

 Currently, the default version of the Matrix42 platform uses the Archiving for Incidents only. The default condition provided out of the box can be changed by customers.  

Example: the incidents that satisfy the provided condition will be moved out of the production database tables and will be stored in a different area of the database, for example, archive database. It is a good idea to archive the incidents that are no longer interesting and thus move them out of the active set of incidents, mainly for performance reasons (e.g. to speed up the search).  

 

 

  • Was this article helpful?