SCSM Automated Service Request SMLets Creation ISSUES and Work Arounds

EDIT :

This post is from WAY back in March 2013, since then some new soultions that are much more elegant than this old solution have since be posted, I’d recommend you check these out first!

http://blog.coretech.dk/mme/set-scsmtemplatewithactivities-powershell-script/

http://blog.scsmsolutions.com/2013/12/check-list-creating-new-work-item-based-on-template-using-scsm-sdk/

As of late February 2014, this is officially on the Service Manager bug list so we should hopefully see a official fix here soon!

Original:

I recently made a post about creating Service Manager 2012 Service Requests using the Powershell SMLets and then also using the SMlets to apply a Service Request template. This method works great! However, if you plan on creating a highly automated  Service Request process, you will run into some problems.
When you create a Service Request and then apply a template you will have some issues. The following behavior is typical:

ISSUE 1 – Missing Activity Type Prefix
You will notice that  our Service Request activities have only a number ID value.  The activities do not have proper prefixes :

  • RA (for runbook activities)
  • MA (for Manual Activities)
  • RB (for RunBooks Activities)

This isn’t a huge issue and will likely not make a huge impact in most typical usages of Service Requests. However, my project needed to use Email notifications to inform various groups / users when manual activities or review activities were created / assigned to them. I found that using subscriptions with the Exchange Connector DO NOT properly if the activities do not have the proper prefix.

When you manually create a Service Request in the console and specify a template, you will not have this issue. This only seems to occur when you use the SMlets to Create a Service Request and then Apply a Template.

For this problem I have found 2 work arounds, both are NOT ideal but they will work.

Work Arounds for Missing Activity Type Prefix

1: Export and Edit the Management Pack XML file containing your Service Request Template and specify the ID for your activities.

You can export your Management Pack that contains the Service Request Template and edit the XML to force your activities to always have the proper Prefix.

Manual Acticity

<Property Path=”$Context/Property[Type=’CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity’]/Id$”>MA{0}></Property>

Review Activity

<Property Path=”$Context/Property[Type=’CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity.ReviewActivity’]/Id$”>RA{0}</Property>

 

In the below screenshot I have a manual Activity with the Title: “Do Something”, I added the appropriate line from above to the section in the Management Pack XML that defines our specific Activity in our Service Request Template:

Click Image to  to Open


You’ll have to add this line to each activity you want to have the Prefix. By specifying MA{0}, our manual activity will be created with the prefix “MA” followed by the typical auto-incremented number.

Once you have made the changes you can save and re-import your edited Management Pack XML.

After you have made this change, your SMLet created Service Request activities will all have the activity prefixes you specified.

 

2: Disregard the use of a template and built your service requests with Orchestrator.

Anders Bengtsson has a nice post that should help you out with this method : http://contoso.se/blog/?p=3179&utm_source=buffer&buffer_share=6bc9d

I’d recommend this only if you are creating a service request with a very small number of activities.

 

ISSUE 2
It’s not pictured here but you will likely see that the first activity by default will stay in status “Pending.” Anders Asp helped me on this one in my TechNet forum post: http://social.technet.microsoft.com/Forums/en-US/systemcenterservicemanager/thread/988a2d4e-6d54-4607-9082-509c6b5cc4d0

The fix for this was to simply use a RunBook step to set the status of the FIRST activity to “Active” (In Progress) 

In my project, the first Service Request activity was a RunBook activity. Without the above in my RunBook the first activity was stuck on Pending and refused to move. After running the above RunBook activities, my RunBook activity ran without issue.

 

These two issues were causing me issues but using the above work arounds I was able to continue on my project which utilizes a very complex Service Request Creation Process that utilizes DOZENS of Orchestrator Runbooks. I’m going to continue to research the core of the issues above as I dive deeper and deeper into the insides of Service Manager.

2 Responses to SCSM Automated Service Request SMLets Creation ISSUES and Work Arounds

  1.  

    the XML for the Manual Activity above has a typo here is the XML without the typo.

    MA{0}

  2.  

    Hi.

    I’m having the same issues. Did you ever find the core issue?

    Regards
    Knut

leave your comment


six − 5 =