Sidebar

Using iTop

Creating your iTop

iTop Customization

"How to" examples
DataModel

User Interface

Automation & Ticket management

Portal Customization

Add a lifecycle on Physical Device

Prerequisite: You must be familiar with the Syntax used in Tutorials

learning:
How to add a lifecycle on a class
level:
Intermediate
domains:
XML, Lifecycle
min version:
2.3.0

Goal

This tutorial will explain how you can add a simple lifecycle on Physical Device. We will use the existing status values and just define a few transitions to navigate between those states.

What's required?

  • We must identify an enum attribute which will carry the lifecycle states. If it does not exist, it can be created
  • We will define the default state, which is automatically used at object creation
  • We will define the different states and stimuli
  • For each State, we will:
    • Define the previous State, which is used as a base for fields flags
    • Define the transitions available from that state
    • At the state level and/or by transition, redefine if fields are mandatory, read-only or hidden. If nothing is defined for a given field, we check

with the Designer

Prerequisite: You must be a Combodo's customer

Adding a lifecycle to a class

Limited to Designer Power User

It is now possible to add a lifecycle to a class which does not have one yet

Step 1: Select the class, check the Lifecycle tab and press Add State icon:

Step 2: Select the Enumeration field which will be used to store the lifecycle state.

Step 3: Once your press Initialize the existing values of the enumeration field will be created as States. If your enum had a default value, it will be used as the Initial state, otherwise, the first value will be used. In all case that can be changed easily.

Step 2.1: You have no enumeration field on your class, then create one first.

Lifecycle can only be defined on non-abstract classes
You can define a lifecycle on a child class using an enumeration field from a parent class, but be cautious if multiple children do the same, they share the same list of states and deleting one on a child will delete it on all children.

with an iTop Extension

Prerequisite: You must be familiar with creating an iTop extension.

Datamodel

There is a enum field on the class PhysicalDevice which can be used for the carrying the lifecycle, it's the status.
Let's suppose that we would like to manage 4 different status: implementation, production, obsolete, stock, which all exists already in the standard datamodel. If it was not the case we would have added the missing values.
In standard datamodel, CI are created in status production, here we want to change this to have implementation as the initial state.

itop-design / classes
    <class id="PhysicalDevice">
      <fields>
        <field id="status">
          <default_value _delta="redefine">implementation</default_value>
        </field>
      </fields>
    </class>

Lifecycle

To add a lifecycle, we add

  • the tag lifecycle
  • the attribute field carrying the states
  • the list of states which must match the possible values of the enum field set above

States

itop-design / classes
    <class id="PhysicalDevice" _delta="must_exist">
      <!-- We add the lifecycle tag -->
      <lifecycle _delta="define">
        <!-- We specify the code of the field carrying the lifecycle -->
        <attribute>status</attribute>
        <!-- We list of possible states, which must match enum values -->
        <states>
          <state id="implementation">
            <!-- Mandatory flags which can remain empty -->
            <flags/>
            <transitions/>
          </state>
          <state id="production">
            <flags/>
            <transitions/>
          </state>
          <state id="obsolete">
            <flags/>
            <transitions/>
          </state>
          <state id="stock">
            <flags/>
            <transitions/>
          </state>
        </states>
      </lifecycle>
    </class>

With the above XML, which is correct, we have defined a lifecycle with 4 states, but we are missing all the transitions, so there is no way to navigate from one state to another yet. So let's add:

  • The list of possible stimuli
  • For each state:
    • For each transition available from this state
      • define the stimulus which will trigger that transition
      • define the target state on which the transition ends

In our simple example, we want to be able to follow this graph, which cover all the possible transitions:
implementation + ev_move2prod > production + ev_stock > stock + ev_move2prod > production + ev_obsolete > obsolete

The result is here:

itop-design / classes
    <class id="PhysicalDevice" _delta="must_exist">
      <lifecycle _delta="define">
        <attribute>status</attribute>
        <!-- list of possible stimuli, triggering transition -->
        <stimuli>
          <stimulus id="ev_move2prod" xsi:type="StimulusUserAction"/>
          <stimulus id="ev_obsolete" xsi:type="StimulusUserAction"/>
          <stimulus id="ev_stock" xsi:type="StimulusUserAction"/>
        </stimuli>
        <states>
          <state id="implementation">
            <flags/>
            <!-- From each state, define possible transitions -->
            <transitions>
              <!-- Recommended: use stimulus code as transition id -->
              <transition id="ev_move2prod">
                <!-- Define the stimulus which will trigger that transition -->
                <stimulus>ev_move2prod</stimulus>
                <!-- define the target state, where the transition will end -->
                <target>production</target>
                <!-- below flags are mandatory but can be empty -->
                <flags/>
                <actions/>
              </transition>
            </transitions>
          </state>
          <state id="production">
            <flags/>
            <transitions>
              <transition id="ev_obsolete">
                <target>obsolete</target>
                <actions/>
              </transition>
              <transition id="ev_stock">
                <target>stock</target>
                <actions/>
              </transition>
            </transitions>
          </state>
          <state id="obsolete">
            <flags/>
            <transitions/>
          </state>
          <state id="stock">
            <flags/>
            <transitions>
              <!-- The below transition is identical to the one on state implementation -->
              <transition id="ev_move2prod">
                <stimulus>ev_move2prod</stimulus>
                <target>production</target>
                <flags/>
                <actions/>
              </transition>
            </transitions>
          </state>
        </states>
      </lifecycle>
    </class>
More details on adding state and transition: Counting time waiting for 3rd party

For all the other possibilities related to lifecycle, check the XML Data Model Reference

latest/customization/add-lifecycle.txt ยท Last modified: 2023/07/21 10:19 (external edit)
Back to top
Contact us