Relate CI to Multiple Activities in a Service Request

Scenario: You have a Request Offering on the portal in which the user will select a CI. The CI is attached to the Service Request as a Related Item.

You also need that CI to be available to some of the activities. The scenario is close to mapping prompt outputs from a Request Offering to fields in multiple Work Items. Maybe the user entered and ID number of sorts which is relevant information for more than one activity in a Service Request.

First create a Service Request Template and add a few activities similarly to what has been done below

Add a Manual Activity at the end of the flow with the title "Dummy".

We need 4 runbooks. one that monitors new Service Requests, one that will get all the Manual Activities in that Service Request, one that creates a relation in each Manual Activity to the CI. And the last runbook ties them all together.

The monitoring runbook is just as one would expect.

Relate CI to Multiple Activities in a Service Request

In this example I get all related "Windows Computers" and feed them to "Relate CI to MA".

"Relate CI to MA" - This runbook will be called as many times as there are Manual Activities in the Service Request.

The magic happens in this runbook:

Get Manual Activity IDs in SR

Get Related MAs

Get 'Dummy' MA

Delete MA Relation - Removes the Dummy Activity from the Service Request

The Script looks like this:

Set-ExecutionPolicy Unrestricted -Scope Process -Force

Import-Module -Name 'SMLets'

$S = "MA{ID from "Get SR"}".Replace("SR","");
$E = "{ID from "Get 'Dummy' MA"}";

$MAIDs = Get-SCSMObject -Class (Get-SCSMClass -Name "System.WorkItem.Activity.ManualActivity$") -Filter "DisplayName -gt `"$S`" -and DisplayName -lt `"$E`"" | Select -ExpandProperty Id;

This is what we needed the 'dummy' for. Altenately one could cycle through all the Manual Activites and pick the one with the highest ID. The Run .NET Script activity must publish the $MAIDs variable.

Return Data

And finally we relate the CI to the MA - Under properties for this runbook in the "Concurrency" tab, enter a number greater than 1 for "Maximum number of simultaneous jobs". As many as you expect there will be of Manual Activities in a Service Request without overloading your runbook server. 5-10 is a good number (depending on your hardware setup).

Testing: Start the monitoring runbook and create an instance of the template from the beginning of this tutorial and add a "Windows Computer" in the "Related Items" tab of the Service Request - or whatever class of CI your runbook supports.

Extending: As you may only want to relate CIs in specific Service Requests, or different types of CIs for each Service Request you will have to add some logic to the "Relate CI to Multiple Activities in a Service Request"-runbook.

Alternatives: Instead of using a monitor you could add a runbook-activity as the first activity in the Service Request.

Copy Notes between Manual Activities

Inspired by Anders Bengtssons blogpost I have come up with a different approach, similar to what I showed in Service Request with Optional Activites.

Again I exploit the setup where Manual Activities are extended with a number of properties. First create a Service Request template and add two activities. In the Extension tab for the first one enter __copy_note_on_completion__ in UserInput5 (or whatever you called yours).

Now create a runbook that monitors Manual Activities matching this configuration.

The monitor triggers on Manual Activities that are updated to status Completed, and where UserInput5 equals __copy_note_on_completion__. The runbook looks in its whole as below

The runbook invoked by the monitor being triggered looks like this

The first two activities are just as their title indicates.

Get Next MA

The filter value is: MA[Sum(Right({ID from "Get MA"},sum(len({ID from "Get MA"}),-2)),1)]

In short it adds 1 to the Manual Activity ID - for further details consult the Runbook Designer help on the topic Data Manipulation.

You can configure this anyway you like. Point being that we copy the "Notes" property from one activity to the next.

Now we just need to start the monitor, create a Service Request using the template described in the beginning of this tutorial. Complete the first activity and enter something meaningful like "Red herring tastes like salty beef". After a short wait the Orchestrator magic will provide you with an updated description in the following activity

 

NOTE: This assumes that ID's are ascending sequentially. If activity order is changed in the template (using the console) the ID is not changed to follow the new ordering. This is because the sequenceID is changed to reflect the new order, while the XML order is not (the activity IDs are definied by the listed order in XML). The MP will need to be exported, the XML changed to reflect the new ordering and re-imported.

Also sometimes the order in the XML is changed while sequenceID is not, meaning the ID ordering is messed up. Same fix (export, edit, import).

Service Request with Optional Activites

Imagine you have a Service Offering on the Self Service Portal where, depending on the users answers, an activity must be performed or not.
It could be that the users requests a new workstation, and they can choose to have it delivered to their office and setup, or they can pick it up themselves. In this case the first activity could be to prepare the workstation, and the second, depending on the users wish, to deliver the workstation to their office. Ie. if the user picks up the workstation themselves we want to skip the second activity.

If you have an extension to your Manual Activity as below we can monitor specific fields in Orchestrator and act accordingly. If you have nothing like this in your Service Manager configuration see the ressources section in the bottom.

Create a new runbook and add a Monitor Object from the SCSM2012 IP and configure it as below.

Link it to an Invoke Runbook activity. This runbook will do the real work, ie. set the status of the Manual Activity to "skipped" as follows:

Monitoring runbook

Configuration of the Invoke Runbook activity

The invoked runbook

Configured the Update Object activity as this

All in all fairly simple. Start the monitoring runbook and create a Service Request Template. Add a Manual Activity and go to the Extensions tab and enter __skip__ in the UserInput4 field.

Now create a Request Offering based on this template. A single user prompt should do the trick:

Map the answer to the activity.

Go to your Self Service Portal and submit a request on your newly published Request Offering. Or if you, like me, haven't set up a portal yet, create a SR using the console.

Wait abit and for the Orchestrator magic to happen. The history tab of the Manual Activity should look something like this. Also notice that the Service Request was completed automatically - there were no activites left to be done.

If you find that there are tons of workflows with optional activities, you may consider adding a field specifically for this purpose and monitor that instead.

Ressources:

• How to Extend a Class in the Authoring Tool

SCSM Customization - collection of blog-posts

I currently have a million tabs open with all kinds of goodie blog-posts. To make it easier for me (and hopefully also others).

• This is pretty much a must read: How to Add the Service Manager Authoring Tool’s Form Controls to Visual Studio
• C# code snippets for Service Manager #1 - code snippets by Rob Ford. Lots of code snippets - just read them all!
• C# code snippets for Service Manager #2 - more code snippets by Rob Ford. He shows code on: Custom console tasks, how to use IDataItem (interface SCSM objects), working with workflows, how to approve a RA, and lastly how to get a user from an SMTP address
• Service Manager 2012 – How to disable form controls for a Resolved or Closed Incident – Part 1 - exactly as the title tells us. A good starting tutorial for customizing SCSM using C# and Visual Studio. Part 2 is here.
• Making fields required. I suggest reading these posts: Make field required on IR and SR forms: SCSM 2012 (Technet), How to make existing fields required in the incident form, and How to: Create a Custom Validation Rule.
• Another must read for serious customization work Debugging Custom SCSM Form in Visual Studio
• Create custom UserControl for SCSM 2010 SP1 - another tutorial I can recommend. A bit more complex than previously mentioned ones.
• Tutorial by Travis Wright - easy to get started on Custom Console Tasks for Create, Edit, Delete
• We all need to do this at some point: How to add a button to edit ListView item on a custom SCSM form
• One for the toolbox: Sealing a Management Pack using fastseal.exe
• Helps you populate your Single Instance Picker og List Picker: Service Manager Custom Forms–Single Instance Pickers and List Pickers
• Easy to do in the Authoring Tool, almost as easy in VS: How to Bind the Service Manager Authoring Tool’s Form Controls in Visual Studio
• Some code to setup a ListView Binding to a related class in a SortableListView (Technet)
• Article on input validation Enforcing Complex Business Data Rules with WPF
• Article on Data Binding - provides a basic understanding on a very important topic
• When you have the time, look these through: http://scsmnz.net/tag/scsm/

Creating your own Integration Pack for Orchestrator

In [SCOrch] Installing Orchestrator Integration Toolkit I showed how to get around installing the necessary tools for creating your own Integration packs.
I will now show how to create an activity that will raise an error. [SCOrch] Error handling runbooks in SC Orchestrator - Part 1 showed that there is a need for doing exactly that as I will examplify in part 2 (comming soon).

First we start the Orchestrator Command-Line Activity Wizard. Click Next and enter a name for the .NET assembly the wizard will eventually create. The name is used as a namespace identifier for the assembly. The assembly file will by default be saved to the Documents Library.

Click Next, then Add. Name the Command Raise Error and the Mode Run Windows PowerShell. Optionally provide a description.

In the Arguments tab click Add and enter Message. Click OK.

Again under the Arguments tab click Insert and select $(Message). Edit the Command Line to Throw $(Message). Click OK.

We now have a command (activity) that will "fail" everytime. We can even provide a message that will be displayed in the Orchestrator log. Click next and let it brew. When done click Build Integration Pack. The Orchestrator Integration Pack Wizard will start and the assembly we just created is already added. Click Next and enter the details. Category name is what is displayed in Orchestrator, and Product name is displayed in the SC 2012 Orchestrator Deployment Manager, but other than that you can enter pretty much what you like.

Click Next. If you like you can provide an icon for the Raise Error activity. Select it and click edit, then modify and select an icon of your liking. Click Next and then Next again. Enter a name for the Integration Pack (it doesn't add .oip itself, so help it out). Click Next and let it brew once again, then Finish. The file is saved to the Documents Library.

Next install the IP using the Deployment Manager (I might show how in a later installment - it's really easy!).

Links

• http://msdn.microsoft.com/en-us/library/hh855854.aspx - The documentation is actually fairly decent. There is a part explaining how to test the assembly before putting it in an IP and deploying that IP (saves some time!)

tags: Orchestrator, Integration Pack

Installing Orchestrator Integration Toolkit

Finding the right MS-products to get started on a project is not always as easy as it should be. If one wishes to make their own IPs (Integration Packs) they need the Orchestrator Integration Toolkit. This does however require the WiX Toolset, and most of you will hit a page providing version 3.7, while you actually need 3.5 (atleast I couldn't get it to work with 3.7). Downloads below:

• WiX Toolset 3.5
• Orchestrator Integration Toolkit (the third of three available downloads)

tags: Orchestrator, Integration Pack, Toolkit, WiX, System Center

Error handling runbooks in SC Orchestrator - Part 1

I have not been able to find a whole lot of easy accesible information (ie. blogposts) on how to do error handling for runbooks in SC Orchestrator. After having conversed with Jakob from Coretech (http://www.coretech.dk/) and attending one of their seminars I got alot wiser on an approach to this (which I found very sensible). I hope this post can help others get started on this necessary aspect of developing runbooks.

A simple approach can be found in the following, and a good place to get started. What we want to do is simply get the Service Request with a specific ID. If none is found we wish to log the event.

Get SR will return sucess even if no objects was found with the given GUID. The link criteria  logic is a double negative, for which I apologize. These are normally not easy to comprehend.

If no objects are found we log an event.

Let's try and run it. In my experience the Runbook Tester will not log events, and just clicking run will not work for some reason (if someone knows please tell me in the comments). Instead create yet another runbook as below.

An event in your log should appear after running this runbook, and look something like this:

That was easy! But what if the Get SR activity failed? And as you may have noticed, the runbook completed with success although we defined no Service Request found as a failure. In part 2 (posted soon) I will address these issues.

Attaching a file to a Work Item using Orchestrator

As I found Microsoft's documentation for Upload Attachment somewhat lacking, so I will share my experience. This tutorial will help you attach a file to a given Work Item such as a Service Request or an Incident.
The final product will look something like this:

Add a parameter to Initialize Data that will contain the given Work Items ID, in this case a Service Request.
Get SR (Get Object) is as expected. Select whatever Work Item class you wish to attach a file to.
Get File Status from the File Management integration pack is also very straightforward. Select the file one wish to attach. If this is a variable value, one could add the filename (possibly one a network shared drive) as a parameter to Initialize Data.
As opposed to Microsoft's step 3.9 in the linked documentation, I would much rather give the attachment a unique identifier, and for this purpose I shall use Powershell. Script is as follows:

For your copy-paste leisure: $guid = [guid]::NewGuid(), and in the Published Data tab do as follows:

which will make the newly created guid available on the databus (and used in the following activity).
Next we will use the Create Related Object activity which looks like:

And the rest of the fields:

At this point the given Work Item would have an attachment. The final step is to put content into the attachment using Upload Attachment:

Note that the Object Guid is Target Object Guid from the previous activity (easy detail to miss in the documentation).

Auto-resolve inactive incidents with a specific status

Anders Bengtsson has provided a solution for auto-closing incidents in Service Manager. The solution works well for closing a resolved incident, as one would normally not wish to inform the Affected User that the incident has been closed.

In our system when an analyst inquires the Affected User for additional information on an incident the status of the incident changes to "Pending user response" which is filtered out in most of our incident views (out of sight, out of mind). We also decided that these incidents should automatically resolve after 5 days if we did not get a response from the Affected User. The above mentioned solution could do this with a minor change to the code, but as most email-templates would use the ResolutionDescription to inform the user why the incident was resolved, these would now provide no information in that regard.

The following Powershell-script solves this. I am in no way a PS-expert, and I did borrow pieces of code in various places (my apologies for not giving credit where credit is due). I did borrow code from
here which helped me update multiple properties (Status & ResolutionDescription) in an incident.

Possible drawback: as the criteria is based on LastModified, analysts logging a comment (ex. Called Anne's office, but no answer) or other activity on the incident would prolong the period it could stay in "Pending user response". A way to get around this would be to extend the incident with a field like "PendingUserResponseSinceDate" just like Service Requests has a "CompletedDate", and test on this instead. As we are using the SendMail plugin (which extends the incident with Message and MessageType), I did not use this solution.

Note: Requires SCSM Powershell Cmdlets from http://smlets.codeplex.com/
formatted using http://codeformatter.blogspot.dk/

 Import-Module smlets  
   
 ######################################################################################################  
 # Author: Anders Spælling, [email protected]  
 # Closes all incidents with pending status and unchanged for more than 5 days  
 ######################################################################################################  
   
 # set a resolution description  
 $ResolutionDescription = "Closed automatically due to inactivity"  
 # inactive for more than 5 days  
 $InactiveFordays = 5  
 $Incidents = @()  
 $Class = get-SCSMClass -Name System.WorkItem.Incident$  
 # Get Id of status enumeration  
 $PendingStatusId = (Get-SCSMEnumeration -Name "IncidentStatusEnum.Active.Pending").Id  
 # type is an object criteria  
 $cType = "Microsoft.EnterpriseManagement.Common.EnterpriseManagementObjectCriteria"  
 # get resolved status enumeration  
 $StatusResolved = Get-SCSMEnumeration -Name IncidentStatusEnum.Resolved  
 # set these properties on the incident  
 $PropertyHash = @{"ResolutionDescription" = $ResolutionDescription; "Status" = $StatusResolved}  
 $Then = (Get-Date).AddDays(-$InactiveFordays)  
 # criteria to filter on  
 $cString = "Status = '$PendingStatusId' and LastModified < '$Then'"  
   
 # create the object criteria  
 $criteria = new-object $cType $cString, $Class  
   
 Get-SCSMObject -criteria $criteria | Set-SCSMObject -PropertyHashtable $PropertyHash