PowerShell for SCSM: Updating the Action Log
When running PowerShell scripts in SCSM it is useful to add comments\notes\actions to the Work Item so that others can see what happened. This blog post will use PowerShell to add comments to the Action log and outline some of the issues along the way. The scripts can also be used in SCSM workflows using the Xapity PowerShell Activity.
The Action Log is available on: • Incident • Service Request • Problem We have found that some customers use the Notes field on Change, Release and Activities when they want to implement similar functionality.
There are three main types of Action Log comments are: • Analyst Comments • End User Comments • Actions - usually system generated events
Problem will not display End User Comments - they can be created, but will not display in the Action Log on the default Problem form. The assumption is that users are not creating Problems directly, users will raise Incidents and this will be converted into a Problem by an Analyst. We did not add End User Comments to the Type Projection.
Classes and Relationships
For the main types of Action Log comments:
For Incidents and Problem
For Service Requests:
The default Type Projections used for Incident and Service Requests have naming (alias) variations between them. Also Problem does not have a default Type Projection that includes the Trouble Ticket relationship.
The out of the box type projections use the following:
Incident Type Projection (System.WorkItem.Incident.ProjectionType): • Alias="ActionLogs" • Alias="UserComments" • Alias="AnalystComments"
Service Request Type Projection (System.WorkItem.ServiceRequestProjection): • Alias="ActionLog" • Alias="EndUserCommentLog" • Alias="AnalystCommentLog"
Xapity Action Log Type Projection We created the Xapity Action Log type projection so that we can add comments to Problem and to overcome the Alias inconsistencies between the Incident and Service Request. This is included in the full script solution download at the bottom of this blog.
The Xapity Action Log type projection has used the same Alias's as the default Service Request type projection to overcome these inconsistencies.
The PowerShell functions below require the Xapity Action Log type projection to be installed when adding comments to Incident and Problem.
Query Type Projections in SQL Looking at the Type Projections directly can be useful to confirm that you have the correct Alias and information when using the default Type Projections. This can be done in a couple of ways:
• Export the work item sealed management pack e.g. Incident Library, choose No to exporting resources. Open the XML file and search for TypeProjections. • Run the following SQL Query on the Service Manager database to find the relevant Type Projection. Click on the link and few the xml code for each Type Projection. This example is targeting Problem Type Projections.
Select cast(tp.ComponentXML as xml), * from TypeProjection tp where tp.TypeProjectionName like '%Problem%'
Action Types Actions are based on the following list of Action Types. When adding an Action comment Action Type is a required input. In Function 3 below we have used a switch blok to make it easier to enter this data - it uses the switch value in the third column.
The script below can be adapted to use the Xapity PowerShell Activity for Service Requests. In which case the ID input can use the $ParentID variable available from the PowerShell Activity.
High Level Explanation of the Functions (available in full below)
The script is written as three separate functions, one for each of the main action log comment types that can be added.
Function 1: Add-AnalystComment
Step 1: Import SMLets Smlets can be downloaded from here: https://smlets.codeplex.com/
Step 2: Define the Function and the inputs required Create the function and define the inputs required. All inputs are mandatory
Step 3: Define Work Item related variables To add a comment to the action log we need to set the class and type projection based on the work item (IR, SR or PR). The script uses the ID prefix to determine the Work Item and then sets the Class and type projection to use. SR is using an out of the box default type projection and IR\PR use the custom Xapity Action Log type projection. These type projections use the same Alias's to make referencing a lot easier.
Step 4: Work Item Object This gets the Work Item object using the Class and ID
Step 5: Create the Action Log Entry To add an action to the Action Log we need to create a new object and define each of the properties on the new Action Log entry.
Create a GUID which will then be used as the ID. The GUID is also used as the DisplayName.
The Class will depend on the work item, so we use the variable from the If Else block above
The Seed is the SR\IR\PR we are adding the Action log comment to and comes from the IF Else block above
The AnalystCommentLog is an alias from the type projection. As both the SR default and the Custom Xapity Type Projections use the same Alias we can keep this the same regardless of the type projection used.
Define the Analyst Comment Log class = System.WorkItem.TroubleTicket.AnalystCommentLog. This can be confirmed in the Type Projection.
Entered by - is a free text field and comes from the function input.
Description - is a free text field and uses the input from the function. Use line breaks and returns to have multiple lines in the comment.
Entered date - is the current time in UTC.
Analyst comments can be marked as private = $True or $False (does not show in Problem Analyst comments, only SR and IR)
Note: There is no Title on an Analyst or End User comment, they are automatically marked as Analyst or End User. Title exists only on Actions.
Step 6: Use the Projection to Update the Action Log This uses the SCSMObjectProjection command to add the Analyst Comment. The type projection will be the default SR or custom Xapity type projection.
Step 7: Function and input variables Examples of using the function for each work item type - SR, IR and PR:
Function 2: Add-EndUserComment
To add an End User comment is essentially the same as the Analyst Comments, with a few minor changes.
Step 2: Define the Function and the inputs required End User Comments do not support the Private check and it was removed from the function inputs.
Step 3: Define work item related variables Problem does support viewing End User Comments in the action log and it was removed from the IF Else block. The function will fail if a Problem ID is entered.
Step 5: Create the Action Log Entry End User Comments do not support the Private option and so it was removed as an option in $Projection The block has been updated to use the EndUseCommentLog alias and changed the class to System.WorkItem.TroubleTicket.UserCommentLog rather than the Analyst Comment values.
Function 3: Add-ActionComment
The Action comment is essentially the same as Analyst and End User Comments, with some extra options. The most obvious is the switch block for Action Type.
Step 2: Define the Function and the inputs required Actions have a two different inputs: • Action Type - switch value from Action Types list above • Title - any free text
Step 3a: Define Action Type
This block uses the Action Type list values from the description above to define the Ordinal Name of each Action Type.
Step 4: Create the Action Log Entry The Action Log entry has two new options - it adds the ActionType and Title variables. The block has been updated to use the ActionLog alias and has changed the class to System.WorkItem.TroubleTicket.ActionLog
Download this script and Type Projection: UpdateActionLogSamples.zip
Thanks to Anders Asp and Thomas Strömberg's for their contributions and blog posts. Both provided PowerShell examples of adding to the Action log and there blogs are worth checking out.
Thomas Strömberg's blog: http://www.zgc.se/ and his post Service Manager PowerShell Examples and his reply on the forums Upload attachment to service request using PowerShell that had a perfect example of the adding an action when attaching a file to the work item.
And some more background material:
A nice blog from kuntalme that provides a good Overview of Relationship Types in the System Center Platform
And a Travis Wright article is always only 1 degree of separation away from all things Service Manager: Creating Membership and Hosting Objects/Relationships Using New-SCSMObjectProjection in SMLets
Xapity PowerShell Activity
The Xapity PowerShell Activity is a new Activity for SCSM that enables PowerShell scripts to be run in SCSM workflows. Automate more of your processes directly in SCSM. Scripts are stored and updated from a central script repository. The scripts execution output can be viewed and if a failure occurs, an Email Notification can be sent.
Xapity - Innovative Software for SCSM - Discover our Products