:: Version 2.7.0 ::

Add a lifecycle on Physical Device

Prerequisite: You must be familiar with the Syntax used in Tutorials and have already created an extension.

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

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

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: Flag Tickets waiting for a 3rd party

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

2_7_0/customization/add-lifecycle.txt ยท Last modified: 2020/04/15 15:23 (external edit)
Back to top
Contact us