One of the real beauties of System Center is the sheer flexibility you are offered when working with each of the independent components. For example, in a recent deployment of Service Manager, I chose not to leverage the Exchange Connector component or any of the internal mail-sending workflows hosted in Service Manager. Instead, I chose to leverage System Center 2012 – Orchestrator to do all the heavy work. I focused on addressing some of the business requirements for my new solution; one of these simple requirements was to ensure that at all times I keep the action log updated as I automated any activities associated with the incident. I figured that this was going to be trivial (as I had already read a number of posts related to this task and even had some luck in my test environment), but my experience with the proof of concept turned out to be a bit of a headache.
Prepare to Update the Action Log
Feeling confident, I set about bringing this requirement to life by creating a new runbook in Orchestrator, which would accept in the ID of the incident that I wished to update. The runbook would then simply look up the Service Manager environment to locate my incident. Once I have the incident located, all that I need to do is create a new unique GUID for the entry I am going to append to the action log of the Incident. Then, using the Create Related Object activity in Orchestrator, we can attach the update to the incident.
Let’s take a closer look at the activities and reveal what the dilemma is.
The first activity in the runbook simply accepts in the friendly name of the incident, for example IR1234, which we then pass along the pipeline to the Get Object activity.
The activity as illustrated simply establishes a connection to the Service Manager instance that we are working with and defines in the class that we are going to be focused on Incidents. The filter simply selects the incident ID provided from the list of incidents in the Service Manager environment, returning it to the pipeline for us to work with.
The next activity in the flow simply uses PowerShell to create a new GUID. It uses a .NET function as follows, and returns it to the pipeline ready for use.
$GUID = [guid]::NewGuid()
Finally, we reach the Create Related Object activity, which again connects to the Service Manager instance. Additionally, the Target Class we will be updating is called Trouble Ticket Action Log. The Relationship Type for this new object will be Trouble Ticket Has Action Log. We also will be providing the GUID of the incident, which we retrieved based on the incident ID, ensuring we are correctly referencing the incident to be updated.
In all the examples I have read, the Source Class used when updating the incident log has always been the Incident class. However, every time I test with this configuration the flow executes without error, but nothing was appearing in the action log of the incident.
In the scenario I was working with, I had extended the base Incident class with some extra properties and gave this new class a new name. In almost all the runbooks I was using the base class name except when I needed to reference some of the extra properties exposed in my class extension. This worked perfectly well, but it turned out that this is not acceptable when we are working with the action log. To resolve the case of my missing actions, in the Source Class of the Create Related Objects class, I must provide the name of my Extended Class. After this the entries magically appear! For reference my environments are System Center Service Manger 2012 R2.
Hope this one saves you some confusion.