Handling SCSM Portal User Input

Many of you may have noticed that unless you have a minimal amount of data to pick from the Service Manager portal, you will need to pick a strategy to properly store and retrieve it.

The first think I think of NOT doing is extending classes. Don’t get me wrong, I know it sometimes will be necessary, but I would leave it for what is REALLY necessary, otherwise, the maintenance can be overwhelming.

With that in mind, you have basically two main options:

1. Customize your Service Request class or Runbook activity class, to add (more) fields data fields and create a property map for each service request. Or

2. Handle the user input form the “userinput” field and create the mechanisms to retrieve the data when needed. You may still need to jiggle a bit with RB Activities or custom activities to store the data temporarily.

Let’s take a look at each of the approaches.

1. In the first approach, you will likely need to extend the Runbook Activity class or the Service Request class (or even create a new class) to store the data that comes from the portal. Unfortunately, there is no way to request portal information and make it available in the request without storing it in a field of a work item.

So, when you’re creating your offer, you have to map:

image_thumb

Notice that the properties on the RB Activity are named Text1, Text2, etc. Wouldn’t it be ideal if they were called Office, FirstName, etc? Well, it is not impossible, but you would need different custom classes of RB Activities to allow that. You don’t want all that customization to manage.

So the answer is to keep a map of the properties, for each Service Request, show to which text field each piece of information was mapped. That is a manual work, on a spreadsheet and needs to keep being updated whenever a change is made.

You’ll very likely need some customizations to extended the number of Text fields, which ate 10 by default (limited to 254 characters) and 5 extended ones, limited to 2K chars.

The pros of this approach is that you can access the properties directly, inside notifications (they are just normal fields of an extended class).

2. The second approach will likely also need a class extension, since the mapping can’t be avoided. However, it doesn’t really matter to which order you map the fields. In this case, we will use the prompts themselves to query for the information we want. The catch is that if you change a prompt, you will need to fix something on the Orchestrator side, otherwise, the information will return empty.

For that to work, a little script is necessary, which will query the user input for a prompt, or multiple prompts, returning the Questions and answers (or alternatively, just the answers, if you like).

The user input field, although it shows like this in the console:

image

It is actually an XML file:

image

So, you have access to the input all the time from orchestrator. Here’s how it plays: a Runbook called QueryUserInput accesses a set of prompts, separated by commands, in quotes:

image

This runbook will return the answers (only) and the answers with questions, in this format:

image

function queryxml
{
Param ($xmlsource, $myquestion)
$answer=””
$NL=”`r`n”
$txml=$xmlsource
$t0=$txml.UserInputs.UserInput | foreach {
$t=$_.Answer
$q=$_.Question
switch ($_.Type)
{
‘String’
{
if ($q -eq $myquestion)
{
if ($te -ne “”)
{
$answer=$t+$NL
}
}
}
}
‘System.SupportingItem.PortalControl.InstancePicker’
{
if ($q -eq $myquestion)
{
if ($t -ne “”)
{
if (($t).Values.Count -eq “1”)
{
$t=($t).Values.Value.DisplayName+”`r`n”
}
else
{
$t=($t).Values.Value | foreach { ” – “+$_.DisplayName } | out-string
$t=$_.Question+$NL+$t
}
}
$answer=$t
}
}
}
Return $answer
}
$xmlsource=@”
`d.T.~Ed/{D1409ED5-B0AC-4747-8FD7-B121784040AD}.UserInput`d.T.~Ed/
“@
$question=`d.T.~Ed/{AA58444F-1CF2-4571-949A-A3294730B85B}.{859D1794-2409-45FF-A44B-862E9AEF7490}`d.T.~Ed/
foreach ($q in $question) {$myanswer=queryxml $xmlsource $q;if ($myanswer -ne “”) {$answers+=”$myanswer”;$answerswithquestions+=”$q : $myanswer”}}

The last part should look something like that:

image

This will allow you to query one or multiple queries from anywhere in your runbooks, so you can fill up Description or notes fields, setup notifications or make decisions based on the user input.

The rest of the runbook goes like this:

image

imageimageimageimageimageimage

Hope it helps!

 

Cheers!