Objects in Teamcenter

There are the two main types of objects in Teamcenter.

1. Classes

2. Business Objects.

Classes have attributes, while business objects have properties.

CLASSES AND ATTRIBUTES

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.

BUSINESS OBJECTS

Business 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.

PERSISTENT AND RUNTIME 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

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.

PROPERTY

In 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.

Properties are of  four types: 

                    1. Persistent
                    2. Compound
                    3. Runtime
                    4. Relation 

1.PERSISTENT PROPERTIES

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.

2.COMPOUND PROPERTIES

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.

3.RUNTIME PROPERTIES

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.

4.RELATION PROPERTIES

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.