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:
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 Custom 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:
Standard CI: DB layout example
Simple CI: DB layout example
Configuration Item Dialog
The Configuration Item settings are available in the Administration application → Schema → Configuration Items page:
Select the existing Configuration Item record and click Edit 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:
| 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:
|
Display Name |
CI name displayed in the user interface.
|
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:
|
Data Definitions |
Add necessary Data Definitions that should be included in the edited Configuration Item and choose cardinality for each DD:
Cardinality types:
|
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):
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.
|
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: |
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:
|
Color |
Optionally, specify the border color of the label shown in the Recents menu for the items of the current CI:
|
"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:
|
|---|---|
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:
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:
|
|---|---|
Attributes |
a list of suitable for the object state attributes from a specified on the previous step Data Definition:
|
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:
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:
|
|---|---|
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:
|
|---|---|
History expression |
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). |
The archiving of records is a basic feature of the Digital Workspace platform. It provides mechanisms to relocate records that are no longer needed to other areas of the database, thus relieving transactional tables.
However, business applications must explicitly implement this archiving function so that it is meaningfully integrated into the use cases. On the one hand, this concerns the consideration of logical relationships of the data and, on the other hand, user access to the archived data via navigation, search, and, if necessary, dashboards and reports.
In the current functional scope of Matrix42 Enterprise Service Management, archiving for incidents is implemented in the Service Desk application. Archiving of other configuration items is neither offered nor supported in the delivered applications.
Archiving moves objects out of the Production database schema to Archiving schema, which literally equals removing the object from the Production database and causes all other objects, which refer to archived objects but still stay in the Production database, lose the relation both in the database and in User Interface (but the relation between these objects can be handled only from the Archived Object side). To avoid such confusion, it is recommended to exclude from archiving those objects which are still referenced by other objects in the Production database.
Create Configuration Item
A new Configuration Item can be created from Administration application → Schema → Configuration Items by Add New Configuration Item action. The action starts a wizard that allows in a single flow creating a new Configuration Item with required Data Definitions structures, configure Role Security (CRUD Security), and build a basic User Interface for a new Configuration Item.
The wizard allows defining only the most popular attributes of the Configuration Item. The rest attributes are auto-generated (e.g. Display Expression) or stay unset. Use the full-fledged Configuration Item Edit Dialog for adjusting the created CI.
General page
Internal Name,
|
Find more details on Configuration Item Edit Dialog |
|---|---|
Protection Level |
Defines the customization type of CI. The users with standard certificates are allowed to create only "Custom" CI, which means the CI can be modified by any Customer, i.e. user with access to this area of the application. Other protection levels are available and intended for internal usage and in-house development of the Matrix42 platform. |
Simple Configuration Item |
Defines the database structure of the new Configuration Item. For more details see Configuration Item Types. Checkbox options:
|
User Roles with Full Access |
the list of the User Roles which be granted full access to the objects of the creating Configuration Item. The role "Administrators" retrieves Full Access by default. |
User Roles with Read Access |
the list of the User Roles which be granted the Read-only access to the objects of the creating Configuration Item. |
If the CI requires a special Role Permissions configuration that is not present on the wizard, it can be easily achieved after the CI creation with the "Set Permissions" action.
Data Definitions page
Main Data Definition |
Defines the base Data Definition for the Simple Configuration Item. Find more details on Simple Configuration Item. The control is available only on the General page when the "Simple Configuration Item" checkbox is set. |
|---|---|
Include "single-mandatory" Data Definitions to CI |
Allows specifying the list of the Data Definitions which will be added to the new Configuration Item with cardinality Mandatory (single). If CI requires Data Definitions with other cardinality (e.g. Optional - Multi), they can be added afterward in the CI Edit Dialog. |
Create Data Definition |
Allows to define a new Data Definition which will be created together with the Configuration Item, and added to CI as Mandatory (Single). |
Support Dimension Security |
This option is available for the Standard CI (see General page → set Simple Configuration Item checkbox option to disabled). Checkbox options:
|
Result Page
When the Configuration Item has been successfully created the wizard displays the Result page with the links to a just created CI details page and to the wizard "New Management Area" which allows automatically generate all required user interfaces for the CI:
