Skip to content

SLA in SCSM 2012. Part 1. Object model.

SLA in SCSM 2012. Part 1. Object model. published on 6 Comments on SLA in SCSM 2012. Part 1. Object model.

SLA management system in SCSM 2012 is one of the most powerful feature in contrast with SCSM 2010 where we can use only 24/7 SLA. But in this cycle of articles I don’t want to show you to setup SLA management in click-click-next guide. My goal is to show you how SLA management settings are stored, handled and worked. I hope what this will allow you to use all feature of the SLA management system in SCSM 2012.

In this first article I will show which object are used by SLA management system and how they stored in SCSM. Before read this series of article you already must know what is SLA management and how to setup it in SCSM 2012. So this series is addressed to more advanced administrators and developers. And part 1 is just a reference of the object model for SLA management. To understand most of information in this article you must already know something about classes, relationships and other terms from authoring process.

Note: to avoid misunderstanding I will use terms from SCSM console.

SLA objects

First of all, let’s remember which objects are used by SLA management system in SCSM 2012. To turn on SLA management we must create and setup next objects:

  • Calendar
  • Metric
  • Queue
  • Service Level Objectives

To create Service Level Objective we must select target class (you can use all classes inherited from WorkItem but in most cases it will be incident and Service Request), queue, calendar, metric and set target time and warning threshold.

Calendar

Calendar used to set the scheduler for time calculation. You can use as many calendars as you want. For storing calendars data  SCSM use the System.Calendar class with properties in tabled below: :

Id Internal id of the each calendar object . Key property. Generated when saving object from console.
Timezone Time zone for current calendar. Stored with special string format.
DisplayName Display name of the calendar as you see in console
Description Same field from console

As you can see there is no data about workdays and holidays. To store this data SCSM use the System.Calendar.WorkDay class for workdays and System.Calendar.Holiday class for holidays. List of properties for System.Calendar.WorkDay  class:

Id Internal id of the each workday object . Key property. Generated when saving object from console.
DisplayName Same as Id but not key property.
IsEnabled If enabled, this object used as workday for time calculation. For all objects created from console the value always “true”
DayOfWeek Day of week. One of the Calendar.DayOfWeek enumaration value.
StartTime Start time for given workday in UTC
EndTime End time for given workday in UTC

List of properties for System.Calendar.Holiday class:

Id Internal id of the each workday object . Key property. Generated when saving object from console.
DisplayName Display name of the holiday in console.
StartTime Start date for holiday in UTC. Time part are ignored in console.
EndTime End date for holiday in UTC. Time part are ignored in console.
IsRecurring If true the holiday will be repeated each year. Can’t be set via console.

The next two relationship used to bind all this classes together :

Name Source Target
System.CalendarHasHoliday System.Calendar System.Calendar.Holiday
System.CalendarHasWorkDay System.Calendar System.Calendar.WorkDay

As example, if you’ve select standard work week (Monday to Friday, 10:00 to 18:00) and one holiday 01 January then SCSM will create in DB:

  1. One object of System.Calendar class
  2. Five objects of  System.Calendar.WorkDay class (one for each day of week)
  3. One object of System.Calendar.Holiday class
  4. Relationships between objects 1 and 2, 1 and 3.

Small summary:

  • Calendar’s objects are stored in database so you can move calendar setting between two different SCSM installations only with SDK: get object from source installation, save to some file, load in target installation from file).
  • Time zone parameter stored in specified format so if you want to create\update Calendar object with SDK you must set right format. In other case you can get the “Value cannot be null. Parameter name: timeZone” exception in console.

Small PowerShell snippet and output how to get all calendars with SMLets:
image

The ability to create and update calendar’s objects with SDK used by Anders in his awesome solution “Generate a CSV-file containing all holidays for your SLA calendar”.

Metric

Metric object used to store data about what date properties of the target class are used to calculate SLA target time. For storing metric’s data SCSM use the System.SLA.DateProperty.TimeMetric class (inherited from System.SLA.Metric) with next list of properties:

Id Internal id of the each metric object . Key property. Generated when saving object from console.
DisplayName Display name of the metric.
Description Description of the metric
TypeId Id of the target class (Guid)
StartDateProperty Id of the property used as start date(Guid)
EndDateProperty Id of the property used as end date(Guid)
PauseEventCriteria Criteria to pause target time calculation (cannot be set via console and not supported by Microsoft)
ResumeEventCriteria Criteria to resume target time calculation (cannot be set via console and not supported by Microsoft)

Small summary:

  • Same as calendar, metric are stored in database so you can move them between installation only with SDK.
  • Class Metric contain two hidden properties, but changing of this properties are totally unsupported by Microsoft. You can read more about it in Part 3.

Queue

Queues in SCSM is a kind of group. In fact, the queue is a group what can contains objects of the classes inherited from System.WorkItem class. So each time when you create the new queue the new singleton class (A singleton class is one for which there can only ever be a single instance,and this instance created in same time as singleton class. Moreover, the ID the class is the same as ID of the object created from this class) and discovery for what class will be created (what is the reason why you must select management pack to create new queue – all classes and discoveries are saved in management pack).

After you’ve created the queue in selected management pack will be created three definitions: (1) singleton class inherited from System.WorkItemGroup:

<ClassType ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" Accessibility="Public" Abstract="false" Base="WorkItem!System.WorkItemGroup" Hosted="false" Singleton="true" Extension="false" />

, (2) new relationship between class above and target class type (Incident in example below):

        <RelationshipType ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident" Accessibility="Public" Abstract="false" Base="WorkItem!System.WorkItemGroupContainsWorkItems">
          <Source ID="ContainedByGroup" MinCardinality="0" MaxCardinality="2147483647" Type="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" />
          <Target ID="GroupContains" MinCardinality="0" MaxCardinality="2147483647" Type="Incident!System.WorkItem.Incident" />
        </RelationshipType>

and (3) new discovery of the GroupPopulator type based on criteria what you’ve defined for given queue (note to Expression section):

<Discovery ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815.Discovery" Enabled="true" Target="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" ConfirmDelivery="false" Remotable="true" Priority="Normal">
  <Category>Discovery</Category>
  <DiscoveryTypes>
    <DiscoveryRelationship TypeID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident" />
  </DiscoveryTypes>
  <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
    <RuleId>$MPElement$</RuleId>
    <GroupInstanceId>$MPElement[Name="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815"]$</GroupInstanceId>
    <MembershipRules>
      <MembershipRule>
        <MonitoringClass>$MPElement[Name='Incident!System.WorkItem.Incident']$</MonitoringClass>
        <RelationshipClass>$MPElement[Name='WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident']$</RelationshipClass>
        <Expression>
          <SimpleExpression>
            <ValueExpression>
              <Property>$Context/Property[Type='Incident!System.WorkItem.Incident']/Classification$</Property>
            </ValueExpression>
            <Operator>Equal</Operator>
            <ValueExpression>
              <Value>{e36c84ea-1903-caf8-c2cf-c1e271a27ca7}</Value>
            </ValueExpression>
          </SimpleExpression>
        </Expression>
      </MembershipRule>
    </MembershipRules>
  </DataSource>
</Discovery>

Small summary:

  • Queues can be easy moved between SCSM’s installation because they are saved in management packs
  • With queues you can use more complex criteria than you can use with standard criteria builder.

Service Level Objectives

The service level objectives (SLO) bind together all objects described above. Unfortunately the each SLO is not a simple object database or in management pack but few different objects. The main class for SLO is the  System.SLA.Configuration class with next list of properties:

Id Internal id of the each SLO object . Key property. Generated when saving object from console.
DisplayName Display name of the SLO.
Description Description of the SLO.
TypeId Class ID of the target type

To store the target time and warning threshold time SCSM use the System.SLA.TimeTarget  class (inherited from System.SLA.Target class) with next list of properties:

Id Internal id of the each target interval. Key property. Generated when saving object from console.
DisplayName Same as Id.
TimeMeasure Interval value (integer)
TimeUnits Enumeration of the Calendar.TimeUnits type.

And next relationships between all this objects :

Name Source Target Description
System.SLA.ConfigurationHasTarget System.SLA.Configuration System.SLA.Target Target resolution time
System.SLA.ConfigurationHasWarningThreshold System.SLA.Configuration System.SLA.Target Warning threshold time
System.SLA.ConfigurationRefersToCalendar System.SLA.Configuration System.Calendar Calendar
System.SLA.ConfigurationRefersToMetric System.SLA.Configuration System.SLA.Metric Metric

But  it is not all. The part of the settings for SLO are stored in management pack. When you saving the SLO object in console the next definitions in selected management pack will be created (note: the internal name of the definitions generated automatically, the Display Names of the created definitions are listed below):

  1. Group. Display name generated by the mask:
    SLA Group: %SLO_NAME%,
    where %SLO_NAME% – display name of the created SLO as it listed in console.
  2. Class inherited from System.SLA.WorkflowTarget. Display name generated by the mask:
    SLA Workflow Target: %SLO_NAME%
  3. Discovery for group (1). Membership rule: all object of the SLO’s target class with TimeAdded more than time creation of the SLO object AND contained in selected queue. To clarification here is screenshot of the membership rule with comment (screenshot is clickable):
    image
  4. Two rules (or workflows in terms of the SCSM console), where source is a event of added and removed relationship (one rule for each event) between group 1 and his member. Display name generated by the mask:
    %SLO_NAME%-AddRelationship
    and
    %SLO_NAME%-DeleteRelationship.
  5. Two rules (or workflows in terms of the SCSM console), where source is event of changed the object of the SLO’s target type with filter for first rule:
    “%DatePropertyStart% was equal null and now not equal null”,
    and for second rule
    “%DatePropertyEnd% was equal null and now not equal null”,
    where “%DatePropertyStart% and %DatePropertyEnd% is start and end datetime property from select metric. Display name generated by the mask:
    %SLO_NAME%-StartEvent
    and
    %SLO_NAME%-EndEvent.
  6. Two rules (or workflows in terms of the SCSM console), where source is event of changed the object of the SLO’s target type without any filters and disabled by default (Enabled=”false”). Display name generated by the mask:
    %ИМЯ_SLO%-PauseEvent
    and
    %ИМЯ_SLO%-ResumeEvent.

The last six rules is the heard of the SLA management system in SCSM 2012. How they works I will describe in Part 2 of this series.

Summary

This article is just reference for administrators and developers but even this information can help to answer on few FAQs:

  1. Why SLO isn’t implemented on object what was created before SLO itself?
  2. How to move SLO’s settings from one installation to another? (answer on this question is very sad)

Share

%d bloggers like this: