IT components come and go. You plan, purchase and operate them and take them out of service eventually. Bingo: This article is about the lifecycle management. It plays an important role in the IT documentation, since it can be used to track the state that a component has or should have. Furthermore, it should be possible to archive or delete the IT documentation itself.
Lifecycle of IT Components
The lifecycle of an IT component is documented in the CMDB status. The following CMD states are available with a fresh i-doit installation:
delivered from repair
CMDB status can be displayed as a column in the object lists in order to see the target condition of a documented object as fast as possible.
By representing the lifecycle it is possible to use i-doit for planning. Whether there is an upcoming big update or a relocation - the IT documentation is always present and offers valid statements.
Set CMDB Status Per Object
To represent the complete lifecycle of an object, the CMDB status attribute in the
General category is used per object. If a new object is created, it receives
in operation as its
CMDB status, if not explicitly set to a different state.
Manage CMDB Status
The adding, changing or deleting of a
CMDB status is carried out via
Administration → CMDB settings → CMDB status. For each
CMDB status the following information is needed:
- Unique name/ language constant (for translation)
- Unique constant (helpful for using the API, for example)
- Color (is used in object lists, the
Generalcategory, in the
CMDB-Explorerand many other cases)
Lifecycle of the IT Documentation
Apart from the objects that are to be documented, the documentation itself can also be subject to a lifecycle. A documentation artifact can be archived once it is not needed anymore. An artifact can also be marked as deleted, so that a person who is responsible for the IT documentation can irrevocably remove this artifact via the
It may be worthwhile for bigger environments to establish the required processes for the archiving and deleting of documentation artifacts. At what point shall parts of the documentation be archived? Who may clean up the IT documentation? These kind of questions need to be addressed by the team. The permission system of i-doit provides the required settings to assign the rights to archive or to purge parts of the documentation to specific users.
Almost all documentation artifacts (objects, category entries, values in
Dialog+-fields etc.) receive a state:
Normal: When working normally (create, edit), each artifact receives this state and can be used anywhere.
Archived: The artifact is hidden in the IT documentation. Further use, e.g. linking, is not possible anymore.
Deleted: The artifact is supposed to be purged but still exists completely with all relations in the IT documentation. Apart from this, the state is similar to
The cycle provides that every documentation artifact receives the
Normal status. Later on, the states will be
Archived and then
Deleted. A restoration to the respective previous state is possible at any time.
in addition to these three states there are also special cases concerning objects:
Unfinished: This state is assigned to a new object that has been created but not saved. This happens, for example, when a new object is created but the
Savebutton is not pressed. These objects can only be found via a report and can then be used. You should remove the unfinished objects on a regular basis via
Administration → Systemtools → Cache / Database → Remove unfinished objects. As an alternative, the unfinished objects can be removed automatically. More details can be found further below.
Template: An object can be used as a template for other objects.
Change template: An object can be used as a change template for mass changing.
If you want to delete a documentation artifact irrevocably, mark it as as
Deleted first and then use the
Purge function. This, however, is not a state because all data (including the previous state and any logbook entries) will be deleted during the
Purge process. This means that the object and its existence can't be traced anymore; thus you should use the function with particular caution.
Archive Objects, Mark them as Deleted or Purge them
The state of an object is visible in the
General category. If you wish to archive an object, mark it as deleted or purge it, you can do so via the object lists. For this purpose, the checkboxes of the corresponding objects are marked and one of the buttons
Purge needs to be pressed.
It is only possible to change to the next possible state. If an object is in the
Normal state, it will only be possible to change it to the
Archived state. You can only delete an object by using the filtered list of archived objects in the right-hand corner. Using
Recycle changes the object to its previous state.
There is no further query when purging an object except if relations to other objects exist.
Archive Category Entries, Mark them as Deleted or Purge them
A similar functionality as with the objects exists for some list categories ("Multi-value"). With this function you can archive category entries, mark them as deleted or purge them.
Simplified Deleting (
In order to purge a documentation artifact it first has to be archived and marked as deleted. To shorten this cycle, it is possible to activate the
Quickpurge button. This is done via
Administration → System settings → System parameters → Activate Quickpurge button. By this means you can purge an object or category entry regardless of its state.
Listing of all Objects that are Archived or Marked as Deleted
In order to receive a list with all objects which are archived or marked as deleted, you can use a report which can be configured via the Query Builder.
Remove Objects or Category Entries that are Unfinished/ Archived/ Marked as Deleted Collectively (
In almost all cases, unfinished objects are unwanted since they are not visible and thus can not be edited. However, also archived objects or objects marked as deleted are often undesired. The same applies to category entries. Therefore it is a good idea to purge these unwanted documentation artifacts. To this end you can use two methods: manual or automatic delection.
You can delete the artifacts via the web GUI. The respective function is located at
Administration → Systemtools → Cache / Database →
Categories. After using one of the provided buttons, a notification showing the amount of objects/ category entries which you are about to delete, will be displayed. After the deleting process it also shows statistics of the amount of objects/ category entries that have been deleted.
The controller also offers a possibility to delete undesired objects irrevocably. The corresponding handler is called
-t parameter determines the group of objects that are to be deleted based on their states:
-t 1: delete unfinished objects
-t 3: delete archived objects
-t 4: delete objects that are marked as deleted
Example for the deletion of unfinished objects:
The automation consists of executing the controller on a regular basis via cron job. An example with other important cron jobs can be found in the article regarding the controller.
Change of States in the Logbook
Changes of states are recorded completely in the logbook. Only when an object/ category entry is purged, the associated logbook entries will be permanently deleted.