I’ve been asked recently for my thoughts about where custom data should be stored in Teamcenter. Should it be stored on a Master Form or in object properties? So, I thought I’d write something on the subject. I also would like to hear what other TC developers are using and what pros or cons they’ve encountered.

Background on Master Forms

If you want to store persistent data about an item in Teamcenter you need to extend the data model somehow. That means that somewhere in the database you either need to add a column to an existing table or create a new table to store the data.

In Teamcenter Engineering when you created a new Item Type there wasn’t a new table created for that type. All items were stored in the same database table and shared the same set of database columns to store their attributes. If you wanted to add an additional property to the table you’d be adding it as a field for every single item in the database. So if you added a Sheet Size property to your drawings, you’d also be adding to your Parts, CAE Items, Manufacturing Process Plans, etc.

Honestly, I’m not 100% certain you could add columns to the item table in TC Engineering. I think you could with the old Schema Editor application, but I never tried to do it, never heard anyone even suggest doing it, and have no particular interest in trying the experiment myself.

So the preferred method for adding your own custom data fields was to add them to a Master Form object which was created and attached automatically to each Item. Essentially you would create a table (storage class) for your custom attributes and then link it to the master form for your item. If you wanted multiple items to share the same set of common attributes you could link the same storage class to multiple form types.

Adding Properties in Teamcenter 8

In Teamcenter 8, AKA, Unified, you can still store your custom data on master forms. However, you can also extend the data model to add properties directly to items and item revisions — in fact, you can now add properties to any workspace object (i.e any data type that inherits from WorkspaceObject). You can do this because Teamcenter now allows you create a new table in the database for every new type you add. When you add an new attribute to a business object type you are adding a column to that specific type’s table. The attribute is only picked up by that business object type and its descendents.

Which one should you use?

You’ll have to decide for yourself, but here is my opinion.

For a brand new data model with no legacy Teamcenter Engineering data model to contend with, I prefer the new method of putting properties directly on the items.

Ease of use

Attributes you add directly to the model are on par with the attributes that Siemens adds themselves and are easier to access and manipulate than attributes on master forms. Data fields on forms seem like second class data to me. It’s a lot easier to access and manipulate properties on items and revisions than on a master form attached to the item or revision. To get to a value stored on an item’s master form you have to traverse a relationship from the item to the form, and then another one from the form to the file where the attributes are actually stored (no, they’re not actually added to the form itself. The form has a reference to where they’re stored). To get to a property stored directly on the item there are no intermediate relationships and object to traverse. This makes it easier for developers to develop queries write ITK code. It’s also easier for the user to view the properties in the Navigator — they’re all in one place on the object itself, not split between the object for off the shelf attributes and the form for custom attributes.

Legacy Data Model

On the other hand if you’re coming from TC Engineering and you’ve already got lots of data stored on forms and processes built up around them it’s probably a good idea to keep using forms unless and until you discover a definite need to get away from them. Whatever difficulties are imposed by forms are already baked into your daily business processes. The more you already rely on them, the more risk you take on trying to migrate off of them.

What is the future for forms?

The people from Siemens I’ve heard all maintain that forms are not going away and they will continue to be supported. I take them at their word on that. Anyone who’s worked with NX/Unigraphics through several versions knows that no tool is ever dropped from it— so you have 16 different ways of drawing a curve (dumb, parametric, sketcher, law curves, view dependent… I’m sure I’ve forgotten a few and missed some recent developments). So I don’t expect master forms to be removed anytime soon. But still, object properties looks to me like where most of the future development and direction will be, so given a choice that’s where I’d like to be too.

That’s just my opinion though. I’m interested in hearing yours.