locked
Using Powershell SMLets "Set-SCSMObjectProjection" method to Update Properties in Bulk RRS feed

  • Question

  • Hello,

    We are using SMLets via Powershell to make many additional "post creation" changes to work items after they have been created via the portal / console, and we need a way to bulk update properties on work items, instead of making changes one object at a time.

    Rather than using "Set-SCSMObject -PropertyHashtable...." on the parent request, and then having to run "Set-SCSMObject -PropertyHashtable...." on each separate child activities, I would like to update all properties in bulk using Set-SCSMObjectProjection.

    The main reason we want to do this is for performance reasons, as we are finding that some of the post processing we are doing is taking significant amounts of time to run after the job has been created.

    Here is some sample code, where I am attempting to update the description of the parent SR, + the description of an existing child activity (MA11481). Unfortunately this is failing to run, as it does not understand "Activity". Hopefully someone can help me figure out how to get this working.

    $tpSR = Get-SCSMTypeProjection -ComputerName "smdev02" -Name "System.WorkItem.ServiceRequestProjection"
    $tp = Get-SCSMObjectProjection -ComputerName "smdev02" -Projection $tpSR -Filter "ID -eq SR11475"
    
    #Create a hash table of the Service Request Arguments
    $Changes = @{
        Activity = @{__CLASS = "System.WorkItem.Activity.ManualActivity";
                          __OBJECT = @{
                              "Id"	         = "MA11481";
                              "Description"  = "Testing2"
                          }
                    }
    	Description = "Testing 12345"
    }
    
    $tp | Set-SCSMObjectProjection -ComputerName "agdsmdev02" -PropertyValues $Changes

    The error I get is..

    Set-SCSMObjectProjection : Activity

    At line:14 char:7

    + $tp | Set-SCSMObjectProjection -ComputerName "agdsmdev02" -PropertyVa ...

    +       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        + CategoryInfo          : NotSpecified: (SR11475 - Hardware Request:EnterpriseManagementObject) [Set-SCSMObjectProjection], ObjectNotFoundException

        + FullyQualifiedErrorId : property not found on object,SMLets.SetSCSMObjectProjectionCommand

    Any assistance would be appreciated.



    • Edited by axpae Tuesday, July 4, 2017 10:37 AM
    Tuesday, July 4, 2017 10:34 AM

Answers

  • Hi Adrian,

    Yes, that is what I am saying - it is not possible to update both the Parent and the child activity in the same event, they are two separate events.

    I am not sure which would be more efficient using type projections or get-scsmobject.

    Personally I would have thought that the changing a few properties would have been very fast and that it wouldn't matter which was used. But obviously there is an issue here somewhere.

    Have you looked at Matthew Dowst's blog post on SCSM PowerShell: Creating PowerShell Workflows  

    The other way to do this is to look at a PowerShell Activity (from Xapity, Itnetx or Cireson) as these run in the SR Activity workflow. Any timing issues are not a factor as the Powershell activity is part of the workflow itself, so it does not move to the next step\activity until it has completed and if this is a bit slow no one notices.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Marked as answer by axpae Wednesday, July 5, 2017 8:41 AM
    Wednesday, July 5, 2017 2:21 AM

All replies

  • Hi

    I don't think this is going to work the way you want it to. In the example you have a filter that gets the SR object, but it does not get the activity objects on the SR. The SR activity objects are independent objects that are related to the SR and would require another step to retrieve them. 

    So I don't think you will be able to update an MA and an SR in one hit. The current SCSMObjectProjection targets the SR to make the SR changes and would need another SCSMObjectProjection step to make the MA changes. I don't see how this could be done as one step. Having the MA ID in the hash table is not going to filter to that MA on the SR.

    The other way to approach this is to look at why the existing Powershell script is slow. Updating a few values should not be taking that long. I am not sure how you trigger the action, it might not be the script itself that is slow, but rather workflow timing.

    Hope this helps.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    Tuesday, July 4, 2017 9:46 PM
  • Hey Glen, Thanks for the quick reply. Ok, so in the example I gave, $tp does contain all of the information, both for the SR and all child activities, but I guess what your saying is, although we can retrieve the parent workitem and all related childobjects, there is no way to update the parent work item and all child objects at the same time.. So, is it more efficient using the type projection to update an objects properties, or am I better off using set-scsmobject to make changes to properties? Or is the difference negligible? We are using orchestrator monitors to kick off post-creation scripts, as we were finding SCSM workflows a bit hit and miss. Even when we run the scrips manually to test updating work items we can see there slow, hence why we are optimising code. You are right, this is not the only thing to look at re slow execution time. Currently we are not using TPs at all for reading work items and activities, and just generally the code can be written to run more efficiently.. I guess we are just looking at all our options before we start optimising :).. Cheers, Adrian
    Wednesday, July 5, 2017 12:22 AM
  • Hi Adrian,

    Yes, that is what I am saying - it is not possible to update both the Parent and the child activity in the same event, they are two separate events.

    I am not sure which would be more efficient using type projections or get-scsmobject.

    Personally I would have thought that the changing a few properties would have been very fast and that it wouldn't matter which was used. But obviously there is an issue here somewhere.

    Have you looked at Matthew Dowst's blog post on SCSM PowerShell: Creating PowerShell Workflows  

    The other way to do this is to look at a PowerShell Activity (from Xapity, Itnetx or Cireson) as these run in the SR Activity workflow. Any timing issues are not a factor as the Powershell activity is part of the workflow itself, so it does not move to the next step\activity until it has completed and if this is a bit slow no one notices.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Marked as answer by axpae Wednesday, July 5, 2017 8:41 AM
    Wednesday, July 5, 2017 2:21 AM
  • Thanks for the info.. Much appreciated. Regards, Adrian
    Wednesday, July 5, 2017 8:41 AM