Add SR Comment with Powershell
Steffen_Dobritz
Member IT Monkey ✭
When I'm trying to add a comment to a SR via New-SCRelationshipInstance I got an error message that "A discovery data item was rejected because the item is already bound to another Membership relationship". The meaning of this error msg is discussed here. And there are some tutorials they uses smlets library to solve this issue. But I want to know how to add a comment without smlets. Which piece of the puzzle I missed?
import-module "C:\Program Files\Microsoft System Center\Service Manager\PowerShell\System.Center.Service.Manager.psd1"
$relComment = Get-SCSMRelationship -name "System.WorkItemHasCommentLog"
$analystCommentClass = Get-SCSMClass -Name "System.WorkItem.TroubleTicket.AnalystCommentLog"
$NewGUID = ([guid]::NewGuid()).ToString()
$Properties = @{Id = $NewGUID;
Comment = "Some Comment";
EnteredBy = "Some Name";
EnteredDate = (Get-Date).ToUniversalTime();
IsPrivate = $false;
}
New-SCSMClassInstance -Class $analystCommentClass -Property $Properties -ComputerName $server
$comment = Get-SCSMClassInstance -Class $analystCommentClass | ?{$_.Id -like $NewGUID}
New-SCRelationshipInstance -RelationshipClass $relComment -Source $SR -Target $comment
I checked if $comment is bounded to an other container there is no result:
$comment.GetRelatedObjectsWhereTarget($relComment.ID).EnterpriseManagementObject
Best Answer
-
Options
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
When it comes to SMLets, it's a lot of working with objects in memory and Type Projections. When it comes to the native cmdlets, it's almost the same thing. But New-SCRelationshipClassInstance needs some different parameters to make this happen. The difference being that instead of creating objects in memory and committing, with native cmdlets you're creating the object when you create the relationship.
#define classes $relComment = Get-SCSMRelationship -name "System.WorkItemHasCommentLog" $analystCommentClass = Get-SCSMClass -Name "System.WorkItem.TroubleTicket.AnalystCommentLog" $srClass = Get-SCSMClass -name "System.WorkItem.ServiceRequest" $sr = Get-SCSMClassInstance -class $srClass -Filter {Id -eq "SR83"} #build the Comment $NewGUID = ([guid]::NewGuid()).ToString() $commentProperties = @{Id = $NewGUID; Comment = "Some Comment"; EnteredBy = "Some Name"; EnteredDate = (Get-Date).ToUniversalTime(); IsPrivate = $false; } #create the Comment on the SR New-SCRelationshipInstance -Source $sr -RelationshipClass $relComment -TargetClass $analystCommentClass -TargetProperty $commentProperties1
Answers
When it comes to SMLets, it's a lot of working with objects in memory and Type Projections. When it comes to the native cmdlets, it's almost the same thing. But New-SCRelationshipClassInstance needs some different parameters to make this happen. The difference being that instead of creating objects in memory and committing, with native cmdlets you're creating the object when you create the relationship.
#define classes $relComment = Get-SCSMRelationship -name "System.WorkItemHasCommentLog" $analystCommentClass = Get-SCSMClass -Name "System.WorkItem.TroubleTicket.AnalystCommentLog" $srClass = Get-SCSMClass -name "System.WorkItem.ServiceRequest" $sr = Get-SCSMClassInstance -class $srClass -Filter {Id -eq "SR83"} #build the Comment $NewGUID = ([guid]::NewGuid()).ToString() $commentProperties = @{Id = $NewGUID; Comment = "Some Comment"; EnteredBy = "Some Name"; EnteredDate = (Get-Date).ToUniversalTime(); IsPrivate = $false; } #create the Comment on the SR New-SCRelationshipInstance -Source $sr -RelationshipClass $relComment -TargetClass $analystCommentClass -TargetProperty $commentPropertiesBut New-SCRelationshipClassInstance needs some different parameters to make this happen. The difference being that instead of creating objects in memory and committing, with native cmdlets you're creating the object when you create the relationship.
How did you figure out to create the relationship in that way? Because the following command does work for relationship "System.WorkItemRelatesToConfigItem" as well.
Great question!
Short answer: I've made a terrifically large amount of mistakes over the years 😁
Long answer: Most of the time you're relating Work Items to Config Items, or using automation to drive Work Items from a Config Item. As a result the relationship and process become habit pretty quick. But the thing that's easy to overlook in this process is that the objects exist before you relate them. Think about any picker in the console/portal - the objects exist before you relate them. It's also exactly what you're accomplishing with:
The SR already exists, the CI already exists and then you relate them. Even if you were automating CI creation to link to Work Items it is still valid because that CI can exist without a Work Item. Whereas:
And it's that must pattern that drives how to create the relationship. Either you can create them because the concepts can exist independently on their own:
Or you create the object and relationship in a single go, because the nature of the object/relationship requires them to both exist
And all of these musts are featured as Relationship Class names on the Microsoft Article you cite. Since the list is relatively short and even shorter for relationships you may use (i.e. create a Reviewer or Leave a Comment). These too become their own habit.
Hope that helps clear things up 😀