You are browsing the documentation for iTop 2.7 which is not the current version.

Consider browsing to iTop 3.0 documentation

SLA by Service Subcategory

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

How to change the way SLA/SLT are computed
XML, Lifecycle
min version:

This tutorial will explain

  1. How deadlines for TTO (Time To Own) and TTR (Time To Resolve) are computed for a particular Ticket
  2. How you can change the logic

How does it work?

Before changing, let's understand how it works in the standard Datamodel.



1. Computing TTO & TTR

When a UserRequest or Incident is created or modified, iTop retrieve all associated stopwatches (Time-To-Own and Time-To-Resolve by default) and for each:

  1. Start or Stop the stopwatches,
  2. Compute Dealines associated to each stopwatch (if any)
  3. Update stopwatch sub-items values

1.2 Computing Deadlines

How to know when a particular goal TTO or TTR will be reached?

  1. TTO and TTR both rely on the same query to retrieve applicable SLTs, with a metric parameter (TTO or TTR) as an SLT is flagged TTO or TTR
  2. They can also rely on the CoverageWindow and Holidays with manage_sla

1.2.1 Retrieve applicable SLT

The SLT will tell iTop what is the delay to apply to the current UserRequest or Incident for TTO or TTR

The query to retrieve the SLTs is defined as a constant

    <constant id="RESPONSE_TICKET_SLT_QUERY" xsi:type="string" _delta="redefine"><![CDATA[
/* In standard model, SLTs can be reuse on different SLAs */
/* In standard model, SLA is defined on the relationship between a CustomerContract and a Service */
JOIN lnkCustomerContractToService AS l2 ON 
JOIN CustomerContract AS sc ON 
/* We get the SLT applicable for the :metric (TTO or TTR) */
WHERE slt.metric = :metric 
/* We get the SLT applicable for the service requested in the Ticket (:this) */
AND l2.service_id = :this->service_id 
/* We get the SLT applicable for the customer defined in the Ticket (:this) */
AND sc.org_id = :this->org_id 
/* We get the SLT applicable for the type of Ticket (UserRequest or Incident) */
AND slt.request_type = :request_type 
/* We get the SLT applicable for the Ticket priority */
AND slt.priority = :this->priority
For Incident class, :request_type is hardcoded to incident
ComputeSLT($oTicket, $sMetric = 'TTO')
   if ($sType == 'Incident')
       $sRequestType = 'incident';
       $sRequestType = $oTicket->Get('request_type');


This tutorial describe a particular customized datamodel in which “SLA are defined by ServiceSubcategory”, but the same logic would apply with a different datamodel.

The datamodel

In the standard datamodel

  • Different SLA can be applied on each Service delivered to a Customer: one SLA for Service A and another SLA for Service B.
  • Different customers can have different SLA applied for the same Service. On Service A: one SLA for Customer 1 and another SLA for Customer 2.
  • An SLA is made of SLTs
  • An SLT can be reuse by multiple SLAs.

Let's see what is required to replace the SLA standard logic by a new one where “SLA are defined by ServiceSubcategory, independently of the Customers”

1. Remove the SLA from lnkCustomerContractToService

For removing sla_id from lnkCustomerContractToService class, check this Tutorial: Remove a field from Ticket.

2. Add the SLA on ServiceSubcategory

For adding sla_id on ServiceSubcategory class, start with this:

itop-design / classes
    <class id="ServiceSubcategory" _delta="if_exists">
        <field id="sla_id" xsi:type="AttributeExternalKey" _delta="define">
          <!-- We don't want to delete the Service Subcategory automatically, if SLA is deleted -->
          <!-- Better not forcing SLA to be set, unless you have no Service Subcategory created -->

Then complete presentation and dictionnary with the help of this Tutorial: Add a field to the Server class

3. Force the Service Subcategory to be provided

If you want to be able to set deadlines at Ticket creation, then the Service Subcategory must be provided. It is not mandatory in the standard datamodel, so we need to change this and make it mandatory.
For this check this Tutorial: Force a field to be always mandatory

Applicable SLT

The constant id=“RESPONSE_TICKET_SLT_QUERY” must be overwritten:

  • in the ITSM Designer
  • or within an extension.

Here is the new value to set for the constant:

/* Unchanged: We get SLTs for SLA */
/* Specific: SLA is defined on ServiceSubcategory */
JOIN ServiceSubcategory AS ss ON 
/* Unchanged: We get the SLT applicable for the :metric (TTO or TTR) */
WHERE slt.metric = :metric 
/* Specific: We get the SLA on the service sub-category requested in the Ticket (:this) */
AND = :this->servicesubcategory_id 
/* Specific: We do not consider the customer */
/* Unchanged: We get the SLT applicable for the type of Ticket (UserRequest or Incident) */
AND slt.request_type = :request_type 
/* Unchanged: We get the SLT applicable for the Ticket priority */
AND slt.priority = :this->priority

Extension: SLA considering business hours

If you have installed this extension: SLA considering business hours and changed in the datamodel the place where the CoverageWindow is defined (ExternalKey in class lnkCustomerContractToService) then you will have to change accordingly the coverage_oql parameter in the Configuration File of your iTop instance.

See the configuration of the extension for details.

2_7_0/customization/sla-service-subcategory.txt · Last modified: 2020/04/15 15:23 (external edit)
Back to top
Contact us