≡ Menu

A Sneak Peak at Multifield Keys in Teamcenter 10

Share the knowledge

As I’ve mentioned before, Multi-key identifiers in Teamcenter was a feature that many of us have been waiting for. It was originally rumored to be coming in TC 9, but that didn’t happen. Fortunately, it did make it into Teamcenter 10. Some customers have begun testing it in the pre-production version 10.0. I haven’t had a chance to work with it myself yet, but I’ve been studying the 10.0 documentation to learn what I can about it. The documentation refers to the new feature as, multifield keys. Here is what I know.

What I know about them

The multi field key is defined by setting the new MultiFieldKey business object constant on a particular business object type. That key field definition is inherited by the children of that business object type.

[box type=”alert”]
Disclaimer
This is all based on my reading of the documentation. It’s entirely possible that once I get a chance to test it for myself I’ll discover that things don’t work quite the way they were advertised to work.
[/box]

Multifield Key Definition

Multifield key definitions consist of a domain, which is the business object on which the multi field key is defined, and one or more properties of the business object. So if you defined a multifield key on Parts, Documents, and Designs your keys would be

  • Part{item_id}
  • Document{item_id}
  • Design{item_id}

And the effect would be that you could (finally) use the same Item ID for a Part, Document, and a Design. Which I think is pretty cool. It solves a lot of problems that in the past led a lot of us add otherwise unnecessary prefixes or suffixes to our item IDs to differentiate the IDs for two different types of objects.

But it doesn’t stop there…

Inheritance of multifield keys in TC 10.0

Like any other kind of property, the MultiFieldKey business object constant is inherited by all children of business object on which it was defined. So if you defined a key on the Part business object, and Part had three children, CompanyPart, VendorPart, IndustryPart, all three children would inherit the same key, Part{item_id}, and so the item ID used have to be unique amongst all of the children of Part. If multifield keys had been defined as {item ID, item type}, with item type being the type the current object, then CompanyPart, VendorPart, and IndustryPart could have all used the same identifier.

Works on more than just Items?

One thing I noticed, nowhere in the documentation I read did it specify that the MultiFieldKey business object constant could only be used Items and their subtypes. It consistently refers to adding the property to BusinessObjects rather than Items. So I have to wonder if we cam use multifield key support on things besides items. For example, can we use them on datasets?

My multifield key

The key fields I’m thinking of incorporating into our system are ItemType{item_id, cage_code}.

Have you tried multifield keys yet?

If you’ve actually worked with multi field keys, please let us know in the comments below. Does it work like the documentation says it should? Did you run into any unexpected problems? Did you notice any impact to performance? What properties did you include in your multifield keys?

  • Teamcenter Heretic

    I would be interested to hear how Siemens intends to rationalize the multi-key field with their current Vendor Management solution.
    Currently the VM solution simply appends a dash and the vendor name to the Vendor parts.
    This is a reasonable response to the current limitations, but what is the plan/migration path to a solution where the multi-key field can be a combo of vendor name and item id?

    I sooooo wish the multi-key made it into V9 as I’m dying for it…
    Cant wait to get rid of _DWG , _CAD , _PL as suffixes for my item ids!

    • http://plmdojo.com/ Scott Pigman

      I’m ready to get rid of the magic suffixes too but I worry that users will mistakenly select the wrong item when building assemblies — for example, grabbing the Part item instead of the CAD Design item they’re supposed to be using in their CAD assemblies.

      • Teamcenter Heretic

        There are definitely landmines to be discovered, especially in the Nx world.

        I can envision being able to hide data using conditions and roles in TC but I’m not very confident that the CAD folks will support this as soon as we will need it.

        I am looking forward to hearing some more about the practical implication of the multi-key filed form the Siemens folks as those who have been to beta are bound by non-disclosure and cannot really discuss the details at this point.

        In the case ot Part/Design I only see the users doing this a few times and when they discover that parts don’t have any CAD in them the learning process will take over (well at least for SOME users).

        • http://plmdojo.com/ Scott Pigman

          But NX will kindly offer to create a dataset for them under the Part, won’t it? Perhaps GRM rules will need to be tweaked to disallow CAD data under parts.

  • 4GDguy

    MFK can be used on any Business Object not only Items. You can define MFK for any BO, with a combination of any of its properties, so that it remains unique in DB. e.g, if you have a BO with properties id, rev and name; if you include all of these three properties in MFK, you can create that BO, with atleast one of these properties unique.

  • Teamcenter Heretic

    Well, just finished up a new V10.1 install and tried MFK.

    Really nice inside of Teamcenter however, these are not fully supported in Nx 8.5 and the workaround of using TC_MFK_DEFAULT_DOMAIN may not work as you expect.

    I’ve been sofar unable to get Nx to work even if I set this field. It comes with a default of “Item” so I set it to my both my actual Item BO and the Abstract one above with no luck.

    I do get something that indicates that the system doesn’t like it. No matter if I select Design, My Abstract BO, or one of the two “real” BOs below it.
    See attached image.
    I have also included a shot of my basic data model…

    • Teamcenter Heretic

      Here is the simple datamodel:

    • Teamcenter Heretic

      Well, look for a Teamcenter Documentation update soon…

      The docs for the TC_MFK_DEFAULT_DOMAIN currently state:

      “A valid value is a business object type name (for example, Item). The operation
      searches among objects of the specified type.”

      but… what they really mean is that you need to specify the Business object that generated the Multi-Field key that you are referencing.

      So, if you have a MFK that looks like MyGenericBO{item_id} and you attach it to MyDesignBO (for CAD use), you need to use MyGenericBO as the value, not MyDesignBO.

      A small nuance but very important in the end.

    • http://plmdojo.com/ Scott Pigman

      Thanks for sharing your experiences.
      How about opening a dataset from within NX? If you search for an item ID which isn’t unique what does NX do?

      • Teamcenter Heretic

        The whole concept of the MFK “Domain” is just that. A domain.

        The ITK calls shed some light on this as you will see some of the new calls are specific to both MFK and finding items by multiple attributes. The older calls carry notation that they will search within the default domain.

        So, to directly answer your question, let’s say I have a part rev called FRED/1 and it is in the MFK domain “MyPart”. If the default domain is “Item” (which BTW I was waaaay too scared to change) then when Nx looks for something called FRED/1 if it doesn’t find it in the Item domain then it acts just like it does in earlier versions if the Item does not exist, even though there is one in the MyPart domain.

        So, in my case what I did was to let all my Design BOs inherit their MFK domain from the Design (the default OOTB domain is Item) and then made my other BOs like MyPart, MyComlPart, MyLegacyPart in a domain called MyPart{“item_id”}.

        This hopefully doesn’t break any of the CAD tools and lets me control Part/Design/Drawing using the domain instead of the Item I warts like _DWG,_DSN etc.

        So far, so good.

Optimization WordPress Plugins & Solutions by W3 EDGE