In Orchestrator we often use a monitoring activity in the beginning of a runbook, for example monitor Service Manager for new incidents. In SMA we do this a bit different which I will explain in this blog post. Remember that you can connect Orchestrator and SMA together as shown in this blog post http://contoso.se/blog/?p=3857 , and get the best of both of them.
In general we need to write a runbook (Powershell workflow script) that runs every X minute and checks “a source” and then performs some “action”, as shown in figure 1. We could do this in one runbook but it might be a better idea to split it up, so we can re-use and share code in other scenarios.
Figure 1
In the following example, shown in figure 2, we monitor Service Manager for new incident that don’t have a support group configured, we do this every 10 minute and if we find a incident that don’t have support group set, we update it. The “SCSM_Search_IR” runbook pass the found incident ID and new support group to the “SCSM_Update_IR” runbook.
Figure 2
We build the “Monitor” runbook with input parameters for “Search” runbook and interval, so the same “Monitor” runbook can be used in multiple scenarios. The “Action” runbook have input parameters for the incident to update and support group to set, so we can reuse the runbook in other scenarios were we need to set support group for an incident. We can start the “Monitor” runbook multiple times, for example if we need to monitor Service Manager for incident with specific state every five minutes we can start a new instance of the “Monitor” runbook. If the action is to update the incident with new support group we can reuse the current “Action” runbook, just need to write a new “Search” runbook. This example is shown in figure 3.
Figure 3
Let’s look at runbook examples.
The “Monitor” runbook
This is the “Monitor” runbook that runs based on an interval and starts a “Search” runbook.
workflow blog_monitor {
param (
# Mandatory parameter of type INT, number of seconds between loops
[parameter(Mandatory=$true)]
[int]$Interval,
# Mandatory parameter of type String, name of search runbook
[parameter(Mandatory=$true)]
[string]$SearchRunbook
)
$WAP = Get-AutomationVariable -Name ‘SMA-WebServiceEndpoint’
while($true)
{
start-sleep -s $Interval
Start-SmaRunbook -Name $SearchRunbook -WebServiceEndpoint $WAP
}
}
The “Search” Runbook
This is the “Search” runbook. It search for incidents created since last run with blank support group setting. The runbook use a variable (blog_search_SCSM) to keep track of processed incidents. If it finds an incident it starts the “SCSM_SetTier” runbook and pass the incident ID and new support group (tier).
workflow blog_search_SCSM
{
$SCSMServer = Get-AutomationVariable -Name 'Service Manager server'
$fromdate = Get-AutomationVariable -Name 'blog_search_SCSM'
$wap = Get-AutomationVariable -Name 'SMA-WebServiceEndpoint'
inlinescript {
$class = Get-SCSMClass -computername $using:SCSMServer -Name System.Workitem.Incident$
$incidents = Get-SCSMObject –Class $class –filter "CreatedDate > $using:fromdate" -computername $using:SCSMServer | where{$_.tierqueue -eq $null}
ForEach ($incident in $incidents) {
Start-SmaRunbook -Name scsm_set_tier -Parameters @{"IRid"=$incident.ID; "Tier"="Tier 1"} -WebServiceEndpoint $using:wap
}
}
$fromdate = get-date -format G
Set-AutomationVariable -Name 'blog_search_SCSM' -Value $fromdate
}
The “Action” runbook
This is the runbook that sets support group for an incident
workflow scsm_set_tier
{
param (
# Mandatory parameter of type String, id of Incident
[parameter(Mandatory=$true)]
[string]$IRid,
# Mandatory parameter of type String, name of new support group
[parameter(Mandatory=$true)]
[string]$Tier
)
$SCSMServer = Get-AutomationVariable -Name 'Service Manager server'
inlinescript {
$class = Get-SCSMClass -computername $using:SCSMServer -Name System.Workitem.Incident$
$incident = Get-SCSMObject –Class $class –filter "ID -eq $using:IRid" -computername $using:SCSMServer
$incident | Set-SCSMObject -ComputerName $using:SCSMServer -Property tierqueue -Value "$using:Tier"
}
}
Test it
To start these runbooks start the “Monitor” runbook and fill in the parameters. After a while we can see the different runbooks are running or has ran
These examples are written in a very “raw” format, to show clean examples. It is a good idea to add for example error handling, logging and parameter validation. In some scenarios it can also be an idea to combine some of the runbooks. When you use a variable for “checkpoint” it is important to understand that only one instance of the runbook can be running. In this scenario it is not an issue as we will only have one runbook running looking for new incidents without support group.
Note that this is provided “AS-IS” with no warranties at all. This is not a production ready solution, just an idea and an example.
Recent Comments