≡ Menu
Get the Newsletter!

What are Classes and Business Objects? Attributes and Properties?

Root of the Business Object tree

The other day a great question was asked on the Teamcenter Engineering group on LinkedIn. A “Teamcenter Enterprise student trying to learn Unified,” asked a question about Business objects and all that:

[quote style=”boxed”]I’m having difficulty wrapping my head around this concept of Class, Business Objects, Attribute, and Property. In Enterprise, like Java…[/quote]

A-ha! There’s his first problem. He’s a Java programmer. No, no, not like that. I bear no malice for Java programmers. Some of my best friends are Java programmers, you know.

No, the problem is that for those of us who are familiar with Object Oriented languages and the vocabulary that goes along with them is that we’re actually at a disadvantage when it comes to understanding Teamcenter’s terminology.
Teamcenter uses a lot of the same words in ways that seem similar to how we’re used to seeing them, but there’s just enough difference to make all the difference in the world.

So let’s see if we can’t unwrap some of the confusion. There are the two main types of objects in Teamcenter, Classes and Business Objects. Classes have attributes, while business objects have properties, which come in four varieties: persistent, compound, runtime, relation. Let’s examine each:


Root classes in TC class hiearchy
Class may also be known as a Storage Class; you’ll see both terms used in the documentation. Myself, I prefer to always use Storage Class because it helps me differentiate it from the Object Oriented Class concept and because the word Storage helps me to remember what it is.
A Storage Class represents a table in the underlying database. It is the persistent, static, representation for a set of objects and if you were to examine the underlying database tables you’d see that each Class in Teamcenter has its own table in the database. Furthermore, each object of a particular class is a row in that table.
Attributes are the database columns for a Class. Since they are stored in the database, they are persistent.


Root of the Business Object treeBusiness Objects are the things you actually create and work with in Teamcenter; they represent the business data. Besides simply letting you define what values can be stored, Business Objects also let you define the behavior you want objects to have, such as display names, naming rules, LOVs, display rules, Pre-conditions, Pre- and Post-actions, etc. Most of the work you do in the BMIDE setting up the data model deals with Business Objects.


Business Objects come in two varieties: Persistent Object Model (POM) Objects, which encapsulate a storage class, and dynamic Runtime Business Objects, which do not. “Persistent” data is data that is written out to a storage device and can be retrieved at some later time; a word document on your hard disk is persistent. In Teamcenter, a persistent object is one that is stored in a database table, specifically the one for the relevant storage class. You can define your own persistent business objects with the BMIDE.

Runtime objects do not encapsulate a storage class so they cannot be stored on disk and are not persistent. They have to be calculated “on the fly”. Generally they are derived by examining other data in the system. For example, a BOM Line is derived by applying the currently selected revision rule to a BOM View Revision. You cannot define your own, custom, runtime business objects with the BMIDE; only custom persistent business objects may be defined. Defining a new runtime business object would require you to write program code to define its behavior.


Primary and secondary business objects encapsulating their storage classes Most Persistent Business Objects, such as Item, Folder, or Tool, have their own, dedicated, storage class which has the same name as the Business Object itself. These are called Primary Business Objects. Because they each have their own storage class, primary business objects can have persistent properties that are unique to themselves and their child business objects.

Secondary Business Objects, most notably the various Datasets types such as Text, UGMASTER, and PDF, use the same storage class as their parent business object. All secondary business objects which share the same storage class share the same set of persistent properties.


There are four types of property: Persistent, Runtime, Compound, and RelationIn Teamcenter, properties are the values attached to business objects – as opposed to attributes, which are attached to classes. There are four types of properties: persistent, compound, runtime and relation.


Persistent properties are the properties that come directly from the underlying storage class. Whatever attributes the storage class has become persistent properties of the business object.


Compound properties are properties defined on one object whose values are obtained by traversing relationships in the data model to find an attribute on some other property. For example, The ItemRevision Storage Class has an attribute, items_tag, which points to the parent item of the revision. The Item then has an attribute called owning_user. If you wanted to, you could create a Compound Property on ItemRevision called items_owning_user that returned the value found by evaluating ItemRevision.items_tag.owning_user.


Runtime Properties are properties that are calculated at runtime. Basically, there’s some ITK code somewhere that is invoked every time you ask for the value of that property. For example, if you had an Automobile business object with persistent properties fuel_capacity, which measured how many gallon of fuel the tank held, and milage, which told you how many miles you could expect to travel per gallon, then you could define a runtime property, range, to tell you how far the automobile could travel on a tank of gas by evaluating the calculation fuel_capacity x milage = range.


Relation properties define the relationships between objects. You can add any relation type – i.e any child of the IMANRelation business object – as a relation property of a business object. Doing so establishes the targeted business object as a Primary business object for the relationship type. Adding relation properties to business objects replaces the old method in TC Engineering of using the_primary_reference preference to establish the primary object types for each relation type.


Classes have attributes, business objects have propertiesHopefully things are a bit clearer now. Just remember that a Class is a database table, attributes are columns of those tables, Business Objects are the objects that the software lets you work with, and properties are the values associated with each business object.

Comments on this entry are closed.

  • RobertF

    Thanks for the post! Very informative.

  • Pradeep Karanam

    Thanks a lot for clearing the confusion..!

    • Scott

      Thank you, but I just corrected a mistake:

      Business Objects

      Finally, Business Objects represent the full data model for objects you create in Teamcenter. BusinessObject is the root of a hierarchy of object types with two branches, POM_Object and and RuntimeBusinessObject. All Business Objects under the POM_object branch encapsulates a Storage Class and provides access to its underlying attributes. RuntimeBusinessObjects exist only during a particular session, essentially they’re calculated “on the fly” and are not persistent.

      Them emphasized text is new. A bit more explanation is here (link broken and removed)

  • https://twitter.com/Skinning_Door Prashant Shrivastava

    Thanks scott, liked your blog very much…
    its very much related to kinda work a plm developer do everyday..
    thanks for sharing!!

    • Anonymous

      Thank you for taking the time to comment. I appreciate it!

  • Anonymous

    For all of you who’ve already read this post, it’s now been completely re-written — and improved! Even if you’ve already read it and liked it it’s worth your time to take a another look (in my own humble — and completely unbiased — opinion)

  • Mehul

    Good and precise article.

  • karan

    Hi Scott….. first of all would like appreciate for your efforts, this topic is really basic but often confusing to ppl working on teamcenter.

    After reading your article i just had few queries in my mind…….

    as mentioned in your article “Business Objects also let you define the behavior you want objects to have, such as display names, naming rules, LOVs, display rules, Pre-conditions, Pre- and Post-actions, etc.” …. i know that all this information about the object and associated naming rules, LOV’s etc, reside in the database. Does the link between such objects (like which LOV is attached to what property of an object) also reside in database. If so, how is it represented, can i find a reference of the attached LOV, display rule etc, somewhere in the db table representing a specific Object in the database?

    • http://plmdojo.com Scott Pigman

      First, thank you. I am very pleased that readers have found this article helpful. I’ll let you in on a secret: writing it (and rewriting it) was helpful to *me* too.

      To your question: of course that information is in the database somewhere, but what use is it to you, frankly, other than satisfying an academic curiosity? Don’t expect that’ll be easy to pull out of the tables. If I want to learn what’s linked to what I’ll look in the BMIDE application and perhaps the xml files it maintains.

      Regardless, looking at the tables for TC Engineering (which are probably about the same as TCUA) I see that there’s several tables whose names start with PLOV_ATTACHED_. The answers you seek probably lay there, although you’ll have some work to do to stitch it all together.

      • Punjabikaran

        well.. you are right in saying that this information is not of much importance apart from clearing some general curiosity. Actually i wanted to get a proper understanding of why teamcenter has two different layers of data representation i.e class model and object model.

        • http://plmdojo.com Scott Pigman

          well, peeking under the hood to see how the engine runs is certainly valid in my book, so have at it!

          I’m not entirely sure what you’re referring to as the class model vs. the object model, but I presume you mean Storage Class vs. Business Object. To me it’s an issue of what’s persistent (classes) and what’s dynamic, i.e. can be calculated or looked up by the program, business objects.

  • Vasanth

    Hi Scott,
    Your are doing great job, I appreciate all your efforts.
    To my knowledge, this is the best ever blog on teamcenter.
    I wish you to continue it for many more years.

  • Rupeshraje81

    Thanks Scott for Explaining the idea in short and sweet.

  • http://www.facebook.com/people/Stephen-Samuel/1816312230 Stephen Samuel

    The only thing that feels better than making a really cool tutorial, design or article, is sharing it with others that will really benefit by it. Please visit the NXTutorials.com website for more cool tutorials. 

  • Kinshah

    Scott, surely appreciate the article – although, most of the things are common knowledge and understanding (mostly intangible in their head), it’s always good to have it in black & white – so one can come back to it every so often (if there’s ever any confusion). Besides, reading it brings the clarity of thoughts.

    Anyways, could you be kind enough to take this article a bit further and provide some examples of when (within BMIDE) one would work with Business Objects and other times when working with Storage Class is needed? Maybe, it’s already documented some place – if so, please point me to it.

    Again, appreciate the efforts!

    • http://plmdojo.com Scott Pigman

      Thank you very much, I’m certainly glad you like it. My own thinking crystallized quite a bit in writing (and rewriting) this post.
      Regarding working with storage classes, to be honest I haven’t found much, if any, use in working directly with the storage classes. Perhaps that’s a peculiarity of the work I’m trying to do and if I was working on a different sort of project I would work more directly with the classes. I’ll ponder this question though and see if I figure something out.

      • http://hooverm.pip.verisignlabs.com/ Teamcenter Heretic

         I use storage classes to stash data that is not necessarily something users want to see but maybe something I want to report on.
        An example might be to use a storage class to stash some workflow metric data that would be extracted later for 6Sigma analysis or the like.

        Another place I have used this is to store the named reference info from a dataset delete operation.

        This kind of info can easily be queried/used even though there is no necessary reason for display (although forms can easily be attached if need be).

        • http://plmdojo.com Scott Pigman

          That’s a pretty neat idea. And annoying, because it’s one of those that seems so blindingly obvious that I feel that I should have thought of it. Except I didn’t. Thanks for sharing; I’m going to remember that one.

  • http://www.facebook.com/jintawee.utenpitak Jintawee Utenpitak

    Thanks for the excellent post, Scott! I am very glad to see
    such great blog on Teamcenter experience sharing.

    It would be appreciate if you could share the best practice
    to manage the metadata in Teamcenter. As we know the current version of
    Teamcenter allows us to create custom persistent attributes directly to item
    business object as well as using the default master form. What is the
    appropriate method to manage and store all kinds of metadata (e.g. company
    name, customer id, material, etc.)? Classification application also has its own
    way to define the data attributes and store all metadata into the
    classification objects. I cannot see the clear picture on how to choose these
    tools correctly when applying the real world scenario.

    • http://plmdojo.com Scott Pigman

      Thank you! I’m glad you’re liked it.

      You ask a good question that I’d like to tackle in a regular post, but the short answer is that based on what I know about TC 8 so far I prefer putting properties on objects directly instead of on forms. Try writing a query to search for values on a form; it’s doable but it’s messy. Item properties seem much cleaner. On the other hand, if you’re coming from TcEng and you’re using master forms already there’s no reason why you have to change.

      company names, customer ID, etc. — if you’re talking about parts purchased from vendors, you should know that there’s a vendor management template that’s an optional install. It has it’s own ideas h0w to identify some of that information. It might be worth a look. I’m not very knowledgeable about that one, frankly.

      I’m also not very knowledgeable about classification but the I’ve seen it used is more for broad categories of parts that users may want to search by. Fasteners, capacitors, and adhesives might be top-level categories.

      • http://www.facebook.com/jintawee.utenpitak Jintawee Utenpitak

        Exactly, I am totally agree with you on that  for the new installation we should define the attributes deirectly to item or item rev. instead of the master form.

        Thanks a lot for for your suggestion about vendor management template, I will have a look into it.

      • http://hooverm.pip.verisignlabs.com/ Teamcenter Heretic


        I’ve dug a bit into the classification stuff at a data model level and I’m super surprised at what I found!
        The structure of the data in classification leads me to believe that the old Genius4000 stuff was simply shoehorned into UA.

        I’ll bet you a beer that this module will someday be completely rewritten in my lifetime 😉

  • Saroj Qui

    Too good, Thanks Scott

  • Pankaj Shrivastava

    Thanks for the very informative post. I was looking at the different types of properties and I came across a “Configured Runtime” property. For example, ItemRevision has four of those, in addition to the plain vanilla “Runtime” properties. Could you throw some light on this property type?

    • http://plmdojo.com Scott Pigman

      Hi Pankaj, sorry I took so long to get back to you but I have a good reason: I don’t know the answer to your question. So, I’ve asked the question on my homepage to see if anyone else knows the answer.

  • Pankaj Shrivastava

    Thanks for the very informative post. I was looking at the different types of properties and I came across a “Configured Runtime” property. For example, ItemRevision has four of those, in addition to the plain vanilla “Runtime” properties. Could you throw some light on this property type?


    Good one Scotttttttt…


    scott please give me your email_id

    • http://plmdojo.com/ Scott Pigman

      Use the “contact me” page

  • Pingback: How to Build a Compound Property to a Form in a Dataset | The PLM Dojo()

  • Pingback: Limited Inheritance | The PLM Dojo()

  • Pingback: Bugs in TC's Hierarchy of Types and Subtypes | The PLM Dojo()

  • Gopal

    Good one Scott…

  • Gopal

    Good one Scott…

  • Sukanya

    Wow! that was an eye opener. Keep posting Scott. Nothing can better than learning your way..

  • Sukanya

    Hi Scott,
    I have a doubt here. Do you have to say that the class concept here does not exactly match with OOP class concept? If someone has to work on BMIDE and create new Persistent business objects, does he/she not create an instance of a class?

  • michael

    Hi Scott,Really good and useful information.Thanks for information.

  • Shravan

    Hi All,
    I need to work on Runtime properties in TCUA9.1.
    In earlier versions of TcUA, the Runtime properties were registered using ITK code outside BMIDE. But in 9.1 we have to do all the things within BMIDE.
    Kindly tell me the procedure.

    Thanks in Advance!!!

  • anand

    Hi All,
    I appreciate your effort on supporting us on querries.
    Could you please clarify me on team centre basics,i m new to this.

  • Suresh Venkitapathy

    Great Post….Keep going…

  • Florencia

    Hi, I need to know if I can easily get the data from Teamcenter and if I can have the entities of the app. Thanks!!

    • Teamcenter Heretic

      The short answer is probably YES… but your question requires more detail.
      Also, you must define “easy”

      • Florencia

        Well… I will explain more detailed.

        What I need to know is the way I can access to data in Teamcenter. Is there any type of file that we can export from the app or any API where we can see how to contact to a web service that contain data from projects and different information?

        Finally we need to know the different entities that are part of the app architecture design of the app.

        All this information is part of an investigation about software life cycle apps, we need to know all this things.

        Thanks in advance.

        • Teamcenter Heretic

          Sounds like you should talk to a Siemens sales person. These questions don’t have simple answers.

  • Rajendra Pawar

    Hi Scott,
    Thanks a lot for sharing imp information on this post.
    I would like to how to know the time zone which are using by Teamcenter Server.
    Can you tell me the SOA APIs to get time zone from Teamcenter server ?

  • Pingback: How To Build a Compound Property to a Form Inside a Dataset – The PLM Dojo()

  • Hasan Mert TAYMAZ

    Hi Scott,
    Thanks a lot for information.

    I would like to how to know, Could it possible to update Run time Properties (bomline attributes) via SOA APIs ?

    I know this can be done via ITK but i want to do it via SOA APIs.

  • Epsha

    Hi Scott,
    CAn you please tell me how to update the relation name in Teamcenter 9.1, may be using BMIDE?

  • Luis Valencia

    Hello Scott,

    I’ve been turning my head around on how to get a property from a primary object to a secondary object of a relation. I’m kind of thinking that relations only work one way in Teamcenter?

    On the secondary object properties of the realtion, there is no mention of the primary, as if they weren’t related at all. This is a Custom relation created for testing purposes. Is tehre any way around this? Thanks.

    • Teamcenter Heretic

      There are clear methods in ITK to get from primary to secondary and vise-versa. The relation browser also is clear.
      There are some relations that are not truly relations in both directions though…

      “Representation for” and “Representation of” are just this. One is a true relation and the other is a run-time property.
      This means that using something like compound properties works on one direction only :(

      • Luis Valencia

        I actually found a workaround modifying the Data Model manually in the default.xml file. I just went to the compound property I created and assigned a GSRMS2P, reload the data model in BMIDE and then deployed the model through TEM.

        It worked very well, I think is not fully supported though, but the property seems to work well in both directions now.

        • Aravind

          Hello Luis,
          Can you please throw some light on what is GSRMS2P and how did you assign it in BMIDE. Have a similar situation wherein, have to traverse from secondary relation to primary relation.

  • Sujatha Medipelly


    i have a doubt, is it possible to do automation in teamcenter. I have to do testing… need to create more than 50 objects in different environments. Please help me.

    • Kamran

      Of course it is possible to do automation in Teamcenter. You can pretty much do anything through automation that you can do manually (and more).

  • Rajesh

    Hi Scott,
    Could you please help me on understanding how correct item revisions are identifies runtime in temacenter for a item? I checked in BMIDE there is Revision list property but it is runtime so values are not stored in database. I am not understanding what logic or how it traverse to get all revisions of any particular item from database.

  • Danish

    hi Scott

    it is very helpful to me to understand the the difference between Class [storage Class] ,business object.
    Thanks a Lot .

  • Sitaramireddy Lankireddy

    hi Scott
    I like your posts very much.
    I want to know that is it possible to access the business object classes of teamcenter and its attributes in java api(plug in development).please tell me the path to achieve this.

Optimization WordPress Plugins & Solutions by W3 EDGE