SM12 has a great feature for Service Level Management. I will not go into any details because this was already described here or here. With SM12 you are very flexible to deal with different service levels, metrics and also time zones. In the background things happen different from SM10 as now an object of type “Service Level Instance Time Information” is created for every new SLO that applies to an Incident. This object is then referenced to the incident. One Incident can have multiple SLOs applied, for instance one because an Incident is a Priority 5 Incident, and another one because the affected User is a VIP User. The downside of this approach is that handling the “target end date” of incidents is a bit more complex because you always have to use the relationships and then find out what the effective target end time is. This blog post shows how this can be made a little bit easier.
I wanted to have a way to easily get the target end date of every incident out of the database as easy as possible. Therefore I created a runbook that gets the most restrictive SLO of an Incident and writes this to a text property of the incident. Then you can simply read this property and have the needed information without always having to deal with relationships. I solved this with a simple Orchestrator runbook that looks like this.
The first activity monitors if new objects of type “Service Level Instance Target Information” is created. If this is the case, the runbook gets triggered.
The scripts looks like this.
$SMDefaultComputer = “scsm01.itnetx.ch”
$SLAID = ID from “Monitor Object” (published data)
$incident = @()
$incidentobj = @()
import-module smlets –force
Get classes, relationships and enumerations
$class_SLATimeInfo = get-scsmclass -name System.SLA.Instance.TimeInformation$
$class_Inc = get-scsmclass -name system.workitem.incident$
$rel = get-scsmrelationshipclass -name System.WorkItemHasSLAInstanceInformation$
$status_SLAActiveID = (get-scsmenumeration -name SLAInstance.Status.Active$).id
Get SL instance time information objects
$SLATimeInfos = get-scsmobject -class $class_slatimeinfo -filter “id = $SLAID”
Get all Incidents related to the SL instance time object fro the last step
foreach($SLATimeInfo in $SLATimeinfos)
{
$incident = (get-scsmrelationshipobject –bytarget $SLATimeInfo).sourceobject
$incidentobj += $incident.adaptemo()
}
Delete duplicate Incident objects from the array
$incidentobj = $incidentobj | select –unique
Get all SL instance time information objects for incidents and select earliest target end date, then write back to text field “Target Resolution Time” (as this field is not used anymore with the new SLO SM12 feature)
foreach($inc in $incidentobj)
{
$SLATimes = $inc | get-scsmrelatedobject | where{$_.classname -eq $class_slatimeinfo} | foreach{$_.targetenddate}
$TargetTime = $SLATimes | sort | select -first 1
$inc | Set-SCSMObject -Property targetresolutiontime -value $targettime
}
Feel free to optimize this a little bit as this was from a quick and dirty approach 
Now check the runbook in and start it. After that create a new incident and make sure one or multiple SLOs target this incident. It takes some time until the SM workflow engine applies the SLOs (creates those objects).
Then after while the runbook should be triggered and the earliest target end date should appear in the target resolution time field.
With this field populated you are now more flexible to work with the target resolution time, e.g. to display that information in the regular incident views or when somehow extracting this information out of the database.
Have fun
Marcel
