Automation–Orchestrating Service Manager–User Inputs
Just a quick “tip/trick” post today… and one that you may not know about, but will definitely need to have in your toolbox if the need ever arrives.
Update or Create User Input data for a Service Request from Orchestrator.
Appending to User Input may be required as part of a process to “flag” a record complete without touching any other field. It also may come in handy to replicate (via a Runbook) the User Input capabilities from the Service Manager Web Console / Service / Request Offering system.
This first example illustrates Appending to Existing User Input Data. I will put a small example at the end for Creating New User Input Data, as it is far less complex and leverages the same concepts.
Appending to Service Request User Input Data comes down to a couple Runbook activities, some XML manipulation and coordination of Published Data:
- Get Object (from the Service Manager Integration Pack)
- Update User Input XML (customized Run .Net Script activity)
- Update Object (from the Service Manager Integration Pack)
NOTE: The Service Manager activities are generically named for this example. I recommend naming them based on their actual function (i.e. Get SR, Update SR User Input, etc.)
You will need to have a way to actually “Get” the SR Object GUID.
If you have the ID, you can pass it into the Runbook and then reference it as a filter in the “Get Object” Activity. For the purposes of this example, I have hardcoded a value for SR ID:
NOTE: For this use case, alternate filters against such as fields as SR Status, Existing User Input data, or Created Date/Time may be a good choice.
Then you will need to modify the existing User Input XML.
The following is my recommendation for using the existing User Input XML, and updating it with new data (appending to it):
NOTE: This is the “tip/trick”. You may have not realized that this field actually requires valid, well formed XML data. While the Integration Pack activities allow you to enter any day, the Service Manager Console will not be too happy with anything short of well formed XML.
PowerShell from this activity:
$ExistingUserInputXML = '<UserInputs> < UserInput Question="Title for Service Request" Answer="Blog Post" Type="string" /> < UserInput Question="Customer Name" Answer="TED" Type="string" /> < /UserInputs>'
$NewUserInputLength = $ExistingUserInputXML.Length - "</UserInputs>".Length
$NewUserInputXML = $ExistingUserInputXML.Substring(0,$NewUserInputLength) + ' <UserInput Question="Deprovision Status" Answer="Timed Deprovision Started" Type="string" /> < /UserInputs>'
NOTE: The example PowerShell here includes example User Input XML. As seen in the screen shot from Orchestrator, you would want to actually leverage Published Data from the Service Manager Integration Pack Activities / Variables.
User Input is completely custom and user defined.
You should also note that the field names and data are completely user defined. In this example the Appending User Input data has a “Question” of “Deprovision Status” and “Answer” of “Timed Deprovision Started”. The most important part of the User Input is its actual formatting and XML data. It should be in the following format:
<UserInputs> < UserInput Question="Question 1" Answer="Answer 1" Type="string" /> < UserInput Question="Question 2" Answer="Answer 2" Type="string" /> <UserInput Question="Question …" Answer="Answer …" Type="string" /> < /UserInputs>
The Updated User Input Data generated by this PowerShell is then passed as Published Data.
And leveraged by the next activity, the “Update Object”. The following is its configuration:
Based on the example Runbook activities and data used…
As mentioned above, this same method (User Input field updates within the Update Object activity of the Service Manager Integration Pack) can also be used to Create New User Input data (and/or Update existing User Input field (not Appending to).
The following is a quick example of creating New User Input Data (you will see the similarities right away):
NOTE: This example leverages the Create Object activity customized for creation of a new Service Request. User Input is an "Optional Field” which can be selected during design time.
REMINDER: The most important part to this is the well formed XML entered into the User Input field. You can make it as dynamic as you want, just make sure it is well formed XML. Because it is that important, here is the same example XML format as above:
<UserInputs> <UserInput Question="Question 1" Answer="Answer 1" Type="string" /> <UserInput Question="Question 2" Answer="Answer 2" Type="string" /> <UserInput Question="Question …" Answer="Answer …" Type="string" /> < /UserInputs>
Once again I hope to continue this “Orchestrating Service Manager” into a bit of a “series” for the Automation and IT Service Management Tracks. I still have a couple other “tips and tricks” that I would like to show, so stay tuned!
I hope this was helpful!