A discovery data item was rejected because the item is already bound to another Membership relationship

A discovery data item was rejected because the item is already bound to another Membership relationship

  • Comments 1
  • Likes

I’ve heard people asking about why they get this error occasionally lately.  I’ll try to explain it here and tell you how to work around it.

 

This is the error message:

A discovery data item was rejected because the item is already bound to another Membership relationship.

 

You can get this message in the console or it can also be the underlying error when submitting a request via the portal.  It is normally thrown when you are trying to create a new object, in particular a type projection object for those of you that know what that means.

First a little background….

In the System Center data model there are four different relationship types:

  • Reference - a simple peer-peer relationship
  • Containment – something contains something else.  Example: Group contains Windows computer.  The Windows computer can exist without the Group.  Even if the Group is deleted the Windows computer does not need to be deleted.
  • Hosting – a specific type of containment relationship where the hosted object can’t exist without the container.  Example:  Windows computer hosts SQL Server instance.  The SQL Server can’t exist without the hosting Windows computer.   If the Windows computer is deleted the SQL Server instance should be deleted too.  The contained object can be contained by another object though.  For example the SQL Server instance can be contained by a Group.
  • Membership - a specific type of containment relationship where the contained object can’t exist without the container (like hosting) but it can’t be contained by another object by that relationship type.  Example: a given Activity Work Item can only be contained by one other parent work item – i.e. Change Request, Incident, etc.

There are a few different membership relationship types out of the box:

    System.Hosting
    System.MobileDeviceHasOperatingSystem
    System.ConfigItemHasFileAttachment
    System.UserHasPreference
    System.CalendarHasHoliday
    System.CalendarHasWorkDay
    System.WorkItem.TroubleTicketHasActionLog
    System.WorkItem.TroubleTicketHasAnalystComment
    System.WorkItem.TroubleTicketHasAuditComment
    System.WorkItem.TroubleTicketHasNotificationLog
    System.WorkItem.TroubleTicketHasUserComment

    System.WorkItemHasActionLog
    System.WorkItemHasBillableTime
    System.WorkItemHasCommentLog
    System.WorkItemHasFileAttachment
    System.SLA.ConfigurationHasTarget
    System.SLA.ConfigurationHasWarningThreshold
    System.WorkItemHasSLAInstanceInformation
    System.ReviewActivityHasReviewer
    System.WorkItemContainsActivity
    Microsoft.SystemCenter.ConfigurationManager.PackageContainsProgram
    Microsoft.SystemCenter.ServiceDesigner.ServiceHasGroups
    System.Knowledge.DocumentHasAverageRating
    System.DeviceHasPowerActivity
    System.DeviceHasPowerCapability
    System.Notification.ChannelHasConfigurationSource
    System.InboundEmail.ConfigurationHasRule

Now, let’s understand the problem.

Let’s say you have created an incident template.  Let’s say in that incident template you created an action log entry.  That action log entry has a GUID for an ID that must be unique amongst all of the action log entries in the system.  That action log entry is related to the parent incident by the System.WorkItem.TroubleTicketHasAnalystComment relationship type which is a membership relationship type.

When you create the first incident based on that template the action log entry will be created and that GUID will be used.   The action log entry will be related to the incident by the System.WorkItem.TroubleTicketHasAnalystComment relationship type.  If you submit another incident using that template the console will attempt to submit a action log entry with the same GUID.  The Data Access Service will recognize that an action log entry with that GUID already exists and thus can’t create it again.  Instead it tries to add that existing action log entry to the new incident.  Since the relationship type – System.WorkItem.TroubleTicketHasAnalystComment – is a membership type it will fail because a given child object can only be a member of one container object via that relationship type.  And that is why you get the error message:  

A discovery data item was rejected because the item is already bound to another Membership relationship.

Just to decode that a bit for you – we use the phrase “discovery data items” to describe any object that is being inserted or updated in the database.

So – the lesson here is to not use action log entries, billable hours, file attachments, etc. in work item templates because you will only be able to create exactly one work item with that template and the rest of the attempts will fail. 

If you have a template like this you have some choices how to fix it.  If it is a billable hours entry, file attachment, etc you can just open the template in the form and remove those objects and save the template.  If you have a template with action log entries in it that is a little more difficult to remove because the form doesn't allow you to remove action log entries.  You can either remove them via PowerShell with SMLets if you are experienced with that or you can delete the template and recreate it (without the action log entries this time) or you can export out the MP and delete the rows of XML in the <Template> section for that template.

Hope that helps!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks for this helpful post Travis.

    We've experienced exact this issue. So I guess there is no other way to add fileattachments automatically except using PowerShell / Orchestrator and monitor when a new WI is created and then let the workflow attach the files?

    Cheers, Alex