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