I'm trying to use New-SCSMRelationshipObject to create a System.WorkItemRelatesToRequestOffering relationship object. When I remove the management pack that contains all of my request offerings incidents that had relationships with those objects lose them. I'd like to keep these relationships, so I'm writing a script that pulls all the data for all objects in our system, and then makes my management pack changes, and fixes any data loss that occurred; I have it working for everything except this relationship.

I found this example of someone creating a relationship for the createdby relationship:

https://social.technet.microsoft.com/forums/systemcenter/en-US/9c0e0ee5-f14c-4399-9012-c488f05afb75/how-to-use-scsmnewrelationshipobject-with-smlets

From that example I gleaned this:

$CreatedByRelClass = Get-SCSMRelationshipClass System.WorkItemCreatedByUser$
$CRClass = Get-SCSMClass -Name System.WorkItem.ChangeRequest
$ChangeReq = Get-SCSMObject $CRClass -Filter "Id -eq CR45"
$UserClass = Get-SCSMClass -Name System.Domain.User
$CreatedByUser = Get-SCSMObject $UserClass -Filter "UserName -eq stestuser"

New-SCSMRelationshipObject -RelationShip $CreatedByRelClass -Source $ChangeReq -Target $CreatedByUser -Bulk

Using this example, I tried this:

$RelationshipObjectClass = Get-SCSMRelationshipClass -name System.WorkItemRelatesToRequestOffering
$SRClass = Get-SCSMClass -Name System.WorkItem.ServiceRequest
$ServiceReq = Get-SCSMObject $SRClass -Filter "Id -eq SR39"
$RequestOff = Get-SCSMClass -Name System.RequestOffering
$RelatedRequestOff = Get-SCSMObject $RequestOff -Filter "DisplayName -eq 'Finance Service Request'"

New-SCSMRelationshipObject -RelationShip $RelationshipObjectClass -Source $ServiceReq -Target $RelatedRequestOff -Bulk

However, I'm getting an error:

New-SCSMRelationshipObject : Cannot process extension elements as EnterpriseManagementObject. User EnterpriseManagementObjectProjection for all
extension element CRUD operations.
At line:1 char:1
+ New-SCSMRelationshipObject -RelationShip $RelationshipObjectClass -Source $Servi ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Microsoft.Enter...ationshipObject:CreatableEnterp...ationshipObject) [New-SCSMRelationshipObject],
   InvalidOperationException
    + FullyQualifiedErrorId : Relationshipship Error,SMLets.NewSCSMRelationshipObject

This made me think that perhaps I should be using the projections, so I switched my "source" and "target" object to be the projections, and go this error instead:

New-SCSMRelationshipObject : Cannot bind parameter 'Source'. Cannot convert the

"@{__base=Microsoft.EnterpriseManagement.Common.EnterpriseManagementObjectProjection; Object=SR39 ..." (I abbreviated this, but it basically spits out the entire object.)

value of type "EnterpriseManagementObjectProjection#System.WorkItem.ServiceRequestProjection" to type "Microsoft.EnterpriseManagement.Common.EnterpriseManagementObject".
At line:1 char:75
+ New-SCSMRelationshipObject -Relationship $RelationshipObjectClass -Source $Sourc ...
+                                                                           ~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [New-SCSMRelationshipObject], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,SMLets.NewSCSMRelationshipObject

I double checked that the target and source class types are all correct, I noticed the relationship's source class type is "System.Workitem", but if you look at an actual relationship object, the source class type is "System.Workitem.ServiceRequest", however this is also the case with the example above too. I can't any examples of people creating this particular relationship, so if anyone has, I'd love to see your examples, I'm confused why I can't get it to work.

• Edited by _Keith_ Wednesday, January 21, 2015 8:43 PM

Hi Keith,

You may check below link regarding the message:Error Cannot process extension elements as EnterpriseManagementObject:

http://blog.scsmsolutions.com/2012/08/error-cannot-process-extension-elements-as-enterprisemanagementobject/

Regards,

Yan Li

Hi Yan,

Looking at this post, I don't think this is PowerShell? He's using a constructor named "EnterpriseManagementObjectProjection". So, are you saying that it's not possible to use "New-SCSMRelationshipObject" to create this particular type of relationship? I'm confused why it works for CreatedBy and not RelatedRequestOffering?

Maybe this blog post is helpful:

Creating Membership and Hosting Objects/Relationships Using New-SCSMObjectProjection in SMLets

Damn, close, almost thought that was it. I did a little investigation, looks like the source of his problem was that the relationship type he was trying to create was the base type "System.Membership", this little snippit leads be to believe the one I'm trying to create is "System.Reference". Take a look at the snippit and let me know if you agree. I think other than that, my code in the initial post is correct?

$ContainsActivityRelationshipClass = Get-SCSMRelationshipClass -name System.WorkItemContainsActivity
$RelatesToRequestOffRelationshipClass = Get-SCSMRelationshipClass -name System.WorkItemRelatesToRequestOffering
$CreatedByRelClass = Get-SCSMRelationshipClass System.WorkItemCreatedByUser$

$ContainsActivityRelationshipClass.GetBaseType() | fl *
PropertyCollection : {}
Base               : ManagementPackElementUniqueIdentifier=189f4500-7a70-db53-9566-feea4695da29
Source             : IsMemberOf
Target             : Member
XmlTag             : RelationshipType
Abstract           : True
Accessibility      : Public
ManagementGroup    : Hitachi-SolutionsDEV_SCSM
ManagementGroupId  : 0b99cd7a-80c4-2a04-38c9-55bff6b15f47
Identifier         : 1|System.Library/31bf3856ad364e35|1.0.0.0|System.Membership||
Name               : System.Membership
Id                 : c89ea3f4-bcc3-a4ab-89c0-c58c2cd88c84
DisplayName        : Membership
Description        : Membership
LanguageCode       : ENU
Comment            :
Status             : Unchanged
LastModified       : 2014-09-05 10:15:49 PM
TimeAdded          : 2014-09-05 10:13:18 PM
InstanceName       :



$RelatesToRequestOffRelationshipClass.GetBaseType() | fl *
PropertyCollection : {}
Base               :
Source             : RefersTo
Target             : IsReferredBy
XmlTag             : RelationshipType
Abstract           : True
Accessibility      : Public
ManagementGroup    : Hitachi-SolutionsDEV_SCSM
ManagementGroupId  : 0b99cd7a-80c4-2a04-38c9-55bff6b15f47
Identifier         : 1|System.Library/31bf3856ad364e35|1.0.0.0|System.Reference||
Name               : System.Reference
Id                 : 5996b276-2d7f-7ca5-68e7-09186d9462d5
DisplayName        : Reference
Description        : Defines the basic properties of directed relationships
LanguageCode       : ENU
Comment            :
Status             : Unchanged
LastModified       : 2014-09-05 10:15:49 PM
TimeAdded          : 2014-09-05 10:13:18 PM
InstanceName       :


$CreatedByRelClass.GetBaseType() | fl *
PropertyCollection : {}
Base               :
Source             : RefersTo
Target             : IsReferredBy
XmlTag             : RelationshipType
Abstract           : True
Accessibility      : Public
ManagementGroup    : Hitachi-SolutionsDEV_SCSM
ManagementGroupId  : 0b99cd7a-80c4-2a04-38c9-55bff6b15f47
Identifier         : 1|System.Library/31bf3856ad364e35|1.0.0.0|System.Reference||
Name               : System.Reference
Id                 : 5996b276-2d7f-7ca5-68e7-09186d9462d5
DisplayName        : Reference
Description        : Defines the basic properties of directed relationships
LanguageCode       : ENU
Comment            :
Status             : Unchanged
LastModified       : 2014-09-05 10:15:49 PM
TimeAdded          : 2014-09-05 10:13:18 PM
InstanceName       :

• Edited by _Keith_ Tuesday, February 03, 2015 9:51 PM

Not sure that explains much. (my understanding) Membership relationships are relationships that must be created when the object is created, for instance containsactivity doesn't make sense to add later (I guess you could but it would be missing/lacking until then). It must be created as part of creating the object.

References can be added on the fly.

Membership relationships gives some weird errors when trying to create them after the object is created. But that does not seem to be the problem you are experiencing.

Anders,

Sounds like we're in agreement. I've found a work-around, but would still love to solve this. I'm importing the relationships as components of the SR's projection using CSV, and the Import-SCSMInstance cmdlet.

Extension elements are treated differently than other class objects. It's a nuance of the SCSM framework/SDK. Anton's blogpost (that Yan posted earlier) explains that in order to avoid the CRUD errors you have to use projections when dealing with Extension Elements. Request Offerings are an extension element (they're defined directly in an MP). So, since you're dealing with a request offering in your script, you have to respect the rules of the SDK..use a projection.

As to why this nuance exists, I have no insight..only theories (aka guesses).

• Edited by Aaron Croasmun Wednesday, February 04, 2015 8:18 PM

Aaron,

In my initial post I noted the error received when I tried to use the projection instead, even when using the Projections instead of the Class objects it didn't work, I suppose in either case, I'm still at a loss as to how to do this. Or do I only need to use the projection for the SR?

I see what you're saying now.

New-SCSMRelationshipObject can only be used with objects, not projections (which is why you got your second error). But, because of the extension element nuance, New-SCSMRelationshipObject is the wrong tool. It cannot be used to create relationships between an extension element object, like your request offering, and another object (which is why you got the first error).

I believe the misunderstanding is that you thought you could use projections with the New-SCSMRelationshipObject, but that's not what the CRUD error meant. It meant that you have to create the relationship _within_ a projection, not create the relationship between projections.

In other words, query for your service request using a type projection that contains the WorkItemRelatesToRequestOffering relationship component. Then, with the resulting projection, you can use the "Add()" method (in the SDK) which will create a relationship between your service request and request offering. Then you commit the entire projection (again, using the SDK).

How you might do this with Powershell is beyond me (I don't use powershell that much). Andreas's post on how to use the New-SCSMObjectProjection will give you insight on using projections in powershell..you wouldn't necessarily use New-SCSMObjectProjection (since your service request already exists), you'd probably use Get-SCSMObjectProjection. Whatever object that cmdlet spits out you would then use to add your request offering object to the WorkItemRelatesToRequestOffering component.

• Edited by Aaron Croasmun Wednesday, February 04, 2015 8:44 PM

Thanks a ton Aaron, that makes a lot of sense. As I mentioned, I found a work around in Powershell that let me do this by "updating" the SRs using a CSV that defined those relationships as components; it works, not how I'd like, but it's better than nothing.

The only problem I can see, is that as much as the relationships are part of the projections, I've found they don't always contain them, at least how I'd expect when I pull those objects in. If I look at all the properties of a Service Request projection, RequestOffering is a property; so if I pull that object so I can set properties and maybe use Set-SCSMObjectProjection to change the projection, I wonder if I can somehow modify the projection and then commit it hmmm. If anyone has done something like this I'd be curious what it looked like. It looks like Set-SCSMObjectProjection has an option to supply an object with the -Projection switch, but I wasn't able to pipe an object in, it still asked for a Hash Table of properties when I tried that though.