Automation–Orchestrating Service Manager–Action Log

Hello Readers/Viewers!

In this post, I am presenting you with a simple “tip/trick” for Orchestrating Service Manager - More specifically, Action Log entries.

Let’s get to it!

What is the use case?

Create new Action Log entries for Service Manger Work Items from Orchestrator.

Why?

Well, once these actions are in Orchestrator, they can be initiated from virtually any other application and/or process. It offers another data entry option for Service Manager Work Items.

NOTE: The following guidance is specifically for adding new Action Log entries to existing Service Requests.

Okay, you have sold me, how do you do it?

It all comes down to a simple Runbook that looks like this:

Activities:

1. Get Object (from the Service Manager Integration Pack)
2. Generate GUID (customized Run .Net Script activity)
3. Create Related 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, Create SR Action Log, 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:

Then you will need to generate and “ID”.

This is a GUID value that is required for the “Create Related Object” Activity. As noted above, I used the “Run .Net Script” Activity:

PowerShell from Activity:

The data generated by this PowerShell is then passed as Published Data.

And leveraged by the third Activity, the “Create Related Object”. The following is its example configuration:

NOTE: What may not be obvious is that the “Target Class” needs to be “Trouble Ticket Action Log”. This class is the “secret ingredient” for this operation.

From there, you fill out the information in the required (and optional) fields.

Here is a breakdown (and a bit of a zoom in) for this example:

NOTE: “Entered by” would most likely come from an external source via Published Data or Variable. I used a hard coded value for the sake of this example. “Action type” is a multi-select field, fed directly from Service Manager. Here are the available out of the box options:

NOTE: “Entered date” can be manually entered (not recommended) or come from an external source via Published Data (shown) or a Variable. “ID” is the GUID that is generated in the second Activity and will need to come from that Activity as Published Data (shown).

NOTE: “Title” and “Description” are Optional Fields. I believe they are critical for the example and any solution where this example is leveraged, as they show the end user (from Console or Portal) the reason for the Action Log update. I chose to hardcode values, but strongly recommend this data come from an external source via Published Data or Variable.

Finally, the this simple example Runbook is complete.

The results from its execution can be seen here (from the SM Portal):

NOTE: You may have to adjust the timestamp (leveraging the “Format Date/Time” Activity so that it makes sense with the rest of what you are seeing in the portal (time zones or time zone storage may be a bit off based on DB storage times/GMT/etc.).

What else?

The content/learning here could be extrapolated for similar tasks (updating Action Log entries, interaction with Action Log entries for different Work Item types, etc.).

Oh, and I hope to turn this “Orchestrating Service Manager” into a bit of a “series” for the Automation and IT Service Management Tracks. I have a couple other “tips and tricks” that I would like to show, so stay tuned!

I hope this was helpful!

enJOY!