Bill of Material Lifecycle

In last blog, I discuss on BOM concept. There I mention various Bill of Material aspects in various stage of product and their dependency. It is interesting to discuss on BOM lifecycle and its evolution from conceptual stage to full fledge manufactured product to maintenance. In this blog I will explain through life cycle of BOM across the product life cycle done as in house development. The BOM lifecycle can varies based on overall process of company for example some company might only manufacture as order hence they As Build design BOM and they directly CREATE Manufacturing BOM from it.

Concept BOM

As the product is visualize based on input from various source like client, sales, technology advancement etc, the Bill of Material creation started.  The concept BOM can be created either from scratch or derived from existing BOM. This BOM can be generated from CAD if the product is more engineering rich product or non CAD if it more features bases products where CAD might be subset of overall product. This BOM are used for proof of concept and goes through various iteration for design feasibility, cost consideration, compliances etc. Once concept phase is completed and decided on basic design and feature of Products, it moves product design.

Design BOM

Design BOM usually driven from concept phase. Design BOM can be derived from concept BOM or can be created completely new based on maturity of concept BOM. BOM are either created Top Down or bottom up. Top down BOM as name suggested design by defined from top like modules or assembly level and defined detail part in advance stage of product development, where as bottom up come to picture where design is done from parts or component level. Usually functional driven product development is done top down where systems or subsystems are defined first and then boiled down to detail design of Bill of Material. Complex product is usually designed through Top down design like Space Craft, heavy automatic machine etc. Teamcenter has Modular BOM functionality to support Top down BOM. Design BOM is usually CAD driven with physical and geometric aspect is modeled in CAD software and related data manages in PLM which is usually integrated with CAD package. Design BOM evaluate from basic CAD design to sophisticated CAE for Analysis BOM. Typically CAE BOM is derived for detail design BOM and is cross link through BOM management software. Once Design BOM is release for multiple iterative process and analysis, it handed over to manufacturing department for manufacturing the product from Design BOM. Manufacturing again realign the BOM from manufacturing aspect and create MBOM.

 

Manufacturing BOM:

Manufacturing engineer create MBOM (Manufacturing BOM) from Design BOM. The basic difference between Design BOM and MBOM is that design engineer look the Product in development from perspective of end product with detail of parts and components where manufacturing engineer look it from perspective of manufacturability of the product. Hence manufacturing view of BOM component and there sequence might be different from that of designer. For example designer might look two components for the given assembly as direct child of assembly, where as manufacturing might look same two components as parent child of each other from assembly sequence perspective. Similarly same component in the design BOM might be shown as two parts in manufacturing BOM. For example T plate might be single part for the designer but for manufacture engineer it two parts with welding operation. Apart from component reorientation manufacture engineer also add information in MBOM related to tools, fixture etc to encapsulate complete information for manufacturing the product. MBOM can be either created in PLM system or ERP like SAP PP. MBOM is usually required CAD assistance for aligning the design part and adding resource like tools and fixtures. Also most of manufacturing are done through NC (Numeric Control) machine, hence NC programming is also create from the given geometry information of part in MBOM. This NC programming is feed in to machine through series of operation information also called routing or Bill of Process. Routing or BOP (Bill of Process) is a detail operation sequence to produce or assemble a given Part or Product. The BOP is created in context of Manufacturing BOM and BOM component can be related to one or more operation in BOP. Rout

ing or BOP is usually done in ERP like SAP, but now PLM vendor also provide very good functionality for Routing which tightly integrate by MBOM and CAD\CAM and NC. Teamcenter provide Part Planer which provide tight integration with MBOM, BOP and NX CAM. This type integration provides better leveraging of information in one place. The below diagram depicit the complete lifecycle of BOM and relation between MBOM and Bill of Process.

 

Service BOM:

Once Part or Product is manufactured, it required to be service and maintained throughout Product life cycle. For consumer items like Mobile, TV etc it means managing serviceable parts and for complex product for example heavy machinery it means not only managing serviceable parts inventory, but also managing periodic maintenance and overhaul of the system. Hence OEM (Original Equipment Manufacturer) also publish Service Bill of Material along with Product specification, so that proper planning for spare part inventory, maintenance and overhaul can be done by Product owner. Service BOM usually will be derived from Design BOM as it’s more closely related to part information and detail then the manufacturing. But it also will derive from MBOM from maintenance and overhaul perspective. For example assembly sequence.  Service BOM also contains more specific information relevant to serviceability perspective like information of oil on bearing etc.

That’s all on BOM Lifecycle. Hope this might help you to understand overall Bill of Material concept and its use in various stage of Product.

See Also :
Bill of Maaterial Concept

Bill of Material Concept

BOM management is most important functionality of PLM system. BOM is most critical component in a product based industry and managing it is still most challenging aspect in PLM system. The complexity increases as BOM lifecycle doesn’t reside just in one system or domain but in multiple Enterprise systems. Also Bill of Material for a given Product or Part means different to different section of people in the company based on their perspective and functionality for the given BOM. In this blog, I will discuss BOM basic, variation and challenge for managing it in any enterprise.

Concept of Bill of Material: BOM is defined as “A comprehensive list of raw materials, components and assemblies required to build or manufacture a product”. Hence it is a detail recipe of product which help to define, build and maintain a product. Since product goes through various lifecycle and interacts with various discipline or domain from Design to Manufacturing to Service to Finance, Bill of material also goes through similar lifecycle and various discipline or domain. Hence for a given product there resides many BOM based on the lifecycle and discipline which required using it. For example Design Engineer mainly deals with Functional aspect of product where as Manufacture Engineer deals with manufacturability aspect of product. Hence the way the Design Engineer look same BOM is different from manufacture engineer. Same is true for Service Engineer, Procurement etc. Each one has his own way of looking of BOM. There is numerous ways for defining the BOM for same product. In technical terms, BOM can mainly classified as follow

a)      Design BOM (EBOM): This deal with functional aspect of product. This is mainly first steps of BOM creation for a product. The design BOM usually originates from CAD model or Functional architecture breakdown. Manufacturing BOM usually derived from Design BOM.\

b)      Manufacturing BOM (MBOM): This BOM deals with manufacturing aspect of Product. Hence it can have detail related to manufacture information along with part detail of product. For example Tools or Fixture can be part of Manufacturing BOM (or it can be reference in the Part). Also some single design part can be consider combination of component ( Ex : Welding two plates ).

c)      Material BOM: This BOM mainly managed in ERP system for inventory and process planning. They deal with actual physical aspect of parts. Design or Manufacturing BOM can have component which might not be real or perishables item. For example MBOM can have component for intermediate manufacturing operation which doesn’t exist as storage or tangible part.

 

d)      Service BOM: This BOM deals with Serviceability of Product. This BOM has only that information which defines the service aspect of Product. Hence it deals only with list of part which is serviceable. Therefore this BOM doesn’t have detail for subassembly which constitute as a single part from service perspective.

Apart from above BOM type there are some other BOM type like Order BOM, Procurement BOM etc which are derivatives of above BOMs with some variation. Also BOM can also be distinguishing based on configurability of BOM.

Configurable BOM: From single BOM, based on certain rules or condition you can derive various resultants BOM. For example for a given model of a car, you can multiple versions. The Configurable BOM is used to dynamically create "end-items" that a company sells. The rule as basically variant and condition are option for those variant. For example based on engine type, power train can be selected in a given BOM. Configurable BOM provide a means to company to manage single BOM for multiple products variant. This saves considerable time and cost to company. All major PLM tools provide configurable BOM management modules.

Master BOM: Looking at so many BOMs variant for a given product, it is always a night mare for the company to manage all BOM and synchronize all when there is any change in either upstream (Design) or downstream (Service). To overcome this challenge, the concept of Master BOM has come.  Master Bill of Material can be defined as single source of BOM having all aspect of information for various configuration and discipline. Hence Master BOM by definition is single source of truth for all BOM. Industry is still struggling to find the exact solution in term of defining and managing Master BOM. Also it become more complex due to the facts that different BOM types are managed in different systems. PLM vendors including Siemens PLM has come various solution and tools, but still required to show the success and maturity of managing Master BOM as a single source of truth across various BOM lifecycle and discipline.

That’s all from my side on Bill of material. PLM vendors provide various powerful BOM tools for Managing, Collaboration and Visualization. I will discuss some of those in my coming blogs.

See Also :
Bill of Material Lifecycle

Introduction to Teamcenter Customization

Teamcenter provides variety of mechanism for customization of teamcenter based on business requirement. The customization is based on base framework of API provide by teamcenter. In this blog I will discuss all customization options and its architecture.

Customization Architecture

Teamcenter customization architecture can be broadly distinguished based on Teamcenter technical architecture. It can be categorized in to three layers.

•  Server or Enterprise Layer
• Web Layer
• Client Layer

Client Layer is basically portal or thin client customization which usually deals with UI and data handling of the result of server request.  SOA client is SOA API for calling SOA services. You can see in detail of Teamcenter SOA service in my SOA blogs. Web Layer is nothing Teamcenter based J2EE deployment layer which basically communicate between Server and client.  Server customization is core of all customization as most of the Business logic is written in this layer. It mainly deals with all business transaction as it interacts with data base through Persistence Object Layer (POM) API.  FMS is resource layer which support actual file transfer between client and server through FMS framework. For more detail in FMS you can visit my blog on Teamcenter FMS. Server customization is done through C based API provided by Teamcenter. This API is also called Integration Toolkit (ITK). Apart from above discussed customization there is SOA customization and BMIDE extension which are basically either server and client\web customization or both.  Below diagram depict Customization Architecture diagram for Teamcenter. As shown in diagram, all BMIDE extension is in server side. This is because most of BMIDE extension overrides or changes object behavior based on business requirement. This can be only accomplished in server layer; hence all extension is implemented by using core ITK API provide in server layer. Below diagram shows the Customization Architect of Teamcenter.

Based on above Customization Architect, Teamcenter customization can be categorized in to following area.

1. Server Customization
2.  Portal Customization
3. Web or Thin client customization
4. SOA based customization
5. BMIDE extension customization

Server Customization: Server side customization is a most frequently used customization, as all business logic are written in this layer. Basically all requests pass through through server layer for all teamcenter transaction. Hence it is core of teamcenter customization. As discuss in Customization Architecture, Teamcenter provide C based API called Integration Toolkit (ITK) for server side customization. This toolkit provides hundred of API for processing various business process based on Teamcenter functionality. The ITK is categorized by various modules and functionality of Teamcenter. Also various extension mechanisms are provided by ITK toolkit to plug in custom code based on various Teamcenter events and object status. The detail discussion of ITK customization is out of scope of this blog and I will cover it another blog.

Portal Customization: Teamcenter Client is layer is written on Java JFC and eclipse SWT. The core client API are written in Java JFC framework and slowly it will ported to eclipse SWT framework. Presently Teamceter support both JFC and SWT customization, but it is recommended to do customization in SWT looking at Teamcenter future vision. The Portal Customization can be done extending OOTB Plug-in or developing your own plug-in. Apart from JFC/SWT UI api, the Teamcenter client API also provides object interface component which is an encapsulation of Teamceter Data model through Client object model. This Object Interface component also form interface layer between client and server.

Web or Thin Client Customization: This customization is for Teamcenter Web client. Teamcenter provides standard web interface for viewing and editing Teamcenter object in web browser. Web client is builds on asynchronous JavaScript and XML (AJAX) to allow dynamic loading of data in the browser. The HTML pages are renders by java script on XML data. Most of the thin client customization is carried through JavaScript which allow the rendering as well managing request\response from web server. Both client-to-server requests and server-to-client responses in Teamcenter thin client are standard HTTP responses.

SOA Customization: It is also called Teamcenter services. It is a standard SOA based services provided by Teamcenter for integrating with third party as well custom client. Also Teamcenter provides framework to create your own custom SOA services. I covered Teamcenter SOA services in detail in my SOA blogs.

BMIDE Extension Customization: This is mainly a server customization using Teamcenter BMIDE. BMIDE provide various extension customization mechanisms for implementing desired behavior in Teamcenter. Some of example of BMIDE extension is pre-action or post-action operation for Business object, Runtime property etc. This extensions are implemented in BMIDE environment by writing C\C++ server code mainly using ITK API. BMIDE framework create stub code and other require classes for extension implementation. Developer only required implementing base logic of the extension.  I will try to cover extension implementation in one of my future blog.

Apart from the above customization; Teamcenter Dispatcher module can also be customized for required translation behavior. Most of time Dispatcher client required to be implemented for extracting and loading translated file from Teamcenter. The Dispatcher Client Framework is based on Teamcenter SOA service and most OOTB SOA API is used apart from Dispatcher API which encapsulates most of complex Teamcenter SOA API calls. I already covered Dispatcher Customization in my blog on Teamcenter Dispatcher.

See Also :

Teamcenter FMS Overview

Teamcenter SOA : Introduction

Teamcenter Dispatcher Framework

Teamcenter Query Builder

Query Builder is one of frequent used module in Teamcenter for creating object based search query. Query Builder is power full tool for quickly configuring Teamcenter for object based search query based on attribute criteria. It is also used in report builder for creating report based on query output. I covered it in detail in my Report Builder blog. In this blog I will explain in detail about local query builder configuration and basic concept to create or modify query.

Basic of Query Builder:

Teamcenter Query is based on Teamcenter persistence data model which I cover in Teamcenter Data Model. Following are the basic characteristic of query in Teamcenter.

1. Query is created against any of the Teamcenter persistence class.
2. Query Criteria can be defined either on attribute of target object or for the related object which are related to search class through either GRM relation or reference.
3. Criteria can be made invisible to end user by making  use entry field empty.
4. Predefined keyword variable can be used against some of the attributes. These variable values are executed at runtime. For example keyword variable $USERID will resolve to session userid when query will be executed.
5.  Teamcenter also support keyword query which allow to search dataset files content, that contain a specific keyword or combinations of keywords.
6. Query can also be customized through Teamcenter use exit.
7. Query results always shows list of object of class which is defined as search class in query builder.

Steps for creating Query:

Below description shows list of task required to be done for defining new query in Teamcenter through Query Builder.

1. Define Query : Before creating query, you have to first define what exactly required to be search and in what context. Context means some condition or criteria which user can either provide while executing search or defined as basic criteria for search itself. For example, if you want create a query for find specific Data type only, then you defined Object Type is query builder and make the field invisible.
2. Map to Data Model : After defining search requirement , you map it to persistence data model of Teamcenter. This become your search class in Query Builder. Basically the output will be shown for instance of this class only. It is assumed the admin user who will be building the query will be aware of basic data model of Teamcenter. I covered it in the my Teamcenter  Data Model blog. Once you select the Search Class, automatically its attributes and GRM relation are shown in Attribute Display area. The attributes can be filter to show only class specific attributes or all inherited attributes from all parent classes.
3. Define Search Context : Then defined search criteria or context in which search required to happen. For example if you want to get Item Revision which has attachment of specific data set only. In this case you have to  traverse from search class i.e Item Revision  to Dataset through predefined GRM relation shown in attribute display area or through reference by from imanrelation object to  Dataset (Primary object to Secondary Object).
4. Use Search Criteria Field : At last you defined the the criteria which you want to expose to user for executing the search. This defined list of attributes shown to User whose value can be set by user before query execution. The attribute can be of search class or related class.

Query Builder Dialog Section

Query Builder Modules has three important sections as shown in below image

Search Class: This is target class against which search will be executed. The search result will be list of instance of this class. As defined above section this will be base class for query. You can navigate required class from Class Selection dialog which shows Teamcenter hierarchy data model.

 

Attribute Selection: This provide list of attributes of search class. Option provide to see only display attributes for a given class or all attributes its inherited from all parent class hierarchy. This section help to select attribute used for search Criteria

Search Criteria: This defined criteria for context search as well user search criteria field. Following are field of Search Criteria section

Boolean Rule : This connect multiple search clauses in search criteria through And\OR condition. AND condition required related clauses should be satisfied where as OR condition means any of them.

UserEntry Name : Shows the display name shown in query. It refers to query locale file for actual display name of attributes search dialog. Make it empty if you want to hide some of clauses.

Logical Operator: This is most important field of Search field which defined actual query condition required to be executed. It basically define rules of attributes are evaluated against the value provided for execution. For example for date attribute you can defined greater then or less then Operator to execute query for before or after date clauses. Query builder support almost all sql operator clauses. The below image shows all support operation condition in Teamcenter. 

Limitation of Query Builder:

Although Query Builder is very powerful tool of Teamcenter for configuring object based query, but it also has some limitation due to Teamcenter data model design.

1. Query can be only be configured for persistence data object.
2. Query can be only build for object in the context of related object defined in Data Model.  That means query against two independent object which are not related through some relation or reference can’t be created.
3. There is no way to filter Search Results based on specific filter rules. For example if I want to get latest Revision of Item, it can’t be achieved through configured Query Builder search. The results will be shows all revision of the item. The reason is all Item Revision of Item are related to Item only which is of reference relation and there is no way defined search criteria which filter old revision.
4. Query rules can’t be build for joint query or set of and /OR clauses as can be defined in SQL statement. For example in SQL you can build where clause based on set of and / or clause through grouping the clauses throuch under different  bracket () . 
5.  Query results only shows list of instance of search class only. You can't see related object along with search object in query results dialogs.

See Also :

Teamcenter Data Model

Teamcenter Report Framework

 

 

 

Teamcenter FMS Overview

File Management System (FMS) is one of the Teamcenter component for managing files or vault in Teamcenter. FMS is responsible for all transaction related to files from Teamcenter server and client. In this blog I will discuss the basic architecture of FMS and its interaction with Teamcenter Application.

FMS Overview:

FMS is independent tool which run as service in server (as FSC) and client machine (as FCC). Teamcenter Application Tier and Client Tier interact with FMS framework through HTTP or HTTPS protocol. The two components of FMS are FMS server cache (FSC) and FMS client Cache. As name suggest FSC is service running in server side which basically cache file in server and serves multiple user request where as FMS client cache work in client machine where it serve request for single user and also interact with FSC for getting latest or new files from server.

Architecture of FMS:

As discussed in FMS Overview, FMS has two components: FSC and FCC. For basic installation you usually have one FSC and multiple FCC based on number of user using the Teamcenter Client. Each of portal clients will have one FCC running on client machine. But in production Environment where user can be in multiple geographical location or number of user are so high that single FSC can’t service so many users. Also if volumes are mounted in different server then also we required FSC on each volume server as FSC is must for each of the volume server. Hence we required to have multiple FSC running in different server to server different geography or set of user or volume server. This multiple FSC server are distributed in such a way that they can be near to each of geographical location.  Due to multiple FSC server architect we then required to define one FSC server as master for managing request and routing to different FSC server. The below diagram shows FMS architecture.

FMS Configuration

Configuration of FMS is managed through xml files. Basically there are three types of Files

·         FMS Master

·         FSC

·         FCC

FMS master configuration file is master configuration file resides in master FSC server. FMS master configuration file which define various FSC sites in cluster or FSC Group. Apart from FSC information it may information of Volumes related to FSC. It will also have default configuration information for FSC and FCC which can be override by respective configuration

FSC configuration file is installed in each of the FSC server. FSC configuration basically contain two main elements

FMSMaster : Defines FMS master location from where FMS Master Configuration file can be read by FSC. FMS Master information help FSC to route the file request in case it doesn’t resides in it volume or cache.

FSC: Defined detail of installed FSC in server. In has different parameter which defines files transfer characteristic as well error and log information. Also it has parameter related to FSC cache for files as well cache location. The parameter vale basically decided based on load, file size, performance requirement as well overall FSC architecture.

FCC configuration installed in each client. It has two main elements

fccdefault : This override FCC configuration from FSC. This has various configuration parameter related to client cache and request.

parentfsc : This define FSC which FCC refer to for downloading FMS configuration. You can have multiple FSC defined as a backup for failover.

Communication Flow between FMS and Teamcenter :

Below is the process for communication between Teamcenter and FMS.

1.       User try to retrieve file from dataset.

2.       Whenever there is any request of file in teamcenter by user, application server forward the request to FMS for retrieving file from Vault.

3.       FMS create a FMS ticket corresponding to file retrieval from vault. FMS ticket is sent to client end which then request to FMS with FMS Ticket.

4.       FMS request is routed to FCC installed in client site for File retrieval.

5.       FCC check if the file cached in FCC and not modified. Modification check of file is done through concept of GUID which is associated with every file in Teamcenter. GUID is a business neutral identifier for file contents, to determine when to pull a file from its local cache. Every file in a Teamcenter vault has a single file GUID associated with every replicated copy of the file. Any change in File results in having a new GUID for the file. In this way FCC check for modification.

6.       If file doesn’t resides in FCC or changes, then FCC sent request to FSC associated with the site id. The priority defines FSC request sequence if the FCC is configured with multiple FSC for given sites id.

7.       FSC check if files is cached in its own server and belong to its own volume. Otherwise it will forward it to corresponding FSC. The other FSC site information its retrieve from FMS Master config file.

8.       FSC sent the file to FCC which in turn route it to client request.

The below diagram depict the overall flow of  FMS request.

I cover all aspect of FMS overview. Hope this will help to understand FMS working and configuration.

Teamcenter POM Query

POM Query is one of important ITK  module in teamcenter from perspective on Data extraction and performance. Teamcenter POM query is API layer provided to query database through API rather then  direct query in database, as Teamcenter doesn't officially expose the underline database design. Developer often prefer to use POM Query rather then going for sets of ITK api to get the desired object from Teamcenter because of performance factor as well using one set of call for getting desired object. Once you understand POM Query mechanism it is very easy to implement complex query cases through it rather then going through lengthy set of ITK API calls . In this blog I will give basis of POM query. With this basic understanding you can build complex query through it. I am assuming the reader will have basic understanding of Teamcenter Data Model. If not please refer my previous blog on Teamcenter Data Model

Introduction 

POM query is noting but sql query which wrapped around ITK program for extraction of data from teamcenter database. I will explain  POM query through simple SQL example which we will convert to POM query. Let assume we want to extract some item based on specific item id and item type . If we want to do it through SQL query, the sql statement look like this

Select puid from item where itemid = “1234”  and object_type = “Item”;

So there are three main constituent of any sql query.

•   Select (attributes)
• From (table)
• Where (condition)
• And /OR

SQL statement  is a function, constituting above three aspect. If you want to covert the above statement in to POM query, all the above aspect formS the building block for POM query.

Following are basic characteristic of POM Query.

• POM Query has unique identification.
• POM query will have select attribute from  POM Classes
• POM Query has expression which specified where condition
• All expressions are binding through POM query API with logical clauses
• POM query required to be executed to get the results

Steps for building POM Query

1. Create the query by unique name
2. Add select attribute on POM query by defining attribute and corresponding POM class
3. Build the  query with all specified expression\condition against query identification.
4. Bind the expression through logical value .
5. Execute the query and get the results.
6. Delete Query

Let see how the sample sql statement can be converted to POM query

Create Query
Unique identification for query

POM_enquiry_create (“get_itemid”)

Teamcenter identify  query through unique string name in a given session. Hence it is good practice to clear the query after it is used.

Select attributes

const char * select_attr_list[] = {"puid"};

POM_enquiry_add_select_attrs(“get_itemid”, “Item”,1,” select_attr_list)

The above api set the select attribute agaist POM Class (It item in this case). You can have multiple attribute defined for select attributes in array and specified that in api. We defined 1 as we have only select attribute in our case.

Build Expression

const char * itemid[] = {"1234"};

POM_enquiry_set_attr_expr(“get_itemid”, "ExprId1", "Item", "item_id", POM_enquiry_equal, “valueId1”)

POM_enquiry_set_string_value (“get_itemid”, "valueId1", 1, itemid, POM_enquiry_bind_value )

The above set condition expression of the query. This is equal to item_id= ‘1234’. The expression is identified  by unique string  identification  which in this case is ExprId1. The value required to be binding through unique identified because of different data type binding. The value identifier valueId1 is then binding by value through proper API call based on attribute type to which it is binding. In our case binding is with string attribute, hence we call set_string_value api. If you have any other data type for attribute  then you have to  call appropriate API. Following data type are supported for POM Query.

Int  : POM_enquiry_set_int_value

Double : POM_enquiry_set_double_value

Char : POM_enquiry_set_string_value

String : POM_enquiry_set_string_value

Logical POM_enquiry_set_logical_value

Date : POM_enquiry_set_date_value

Tag : POM_enquiry_set_tag_value

This expression is binded by query by providing query identification which ‘get_itemid’ in our case. Similar expression will be for other condition of object type

 const char * itemtype[] = {"Item"};

POM_enquiry_set_attr_expr(“get_itemid”, "ExprId2", "Item", "object_type", POM_enquiry_equal, “valueId2”)

POM_enquiry_set_string_value (“get_itemid”, "valueId2", 1, itemtype, POM_enquiry_bind_value )

Expression Binding

Now the two expression should be combined for where clauses. The logical binding between expression is done through api call

POM_enquiry_set_expr(“get_itemid”, "ExprId3", "ExprId1", POM_enquiry_and, "ExprId2")

The above api will bind ExprId1 and ExprId2 with and clause. This is equal to

itemid = “1234”  and object_type = “Item”;

To identify the binding a new expression id is created. This expression id can be used now to develop complex binding if there are more then two condition clauses.

Expression can be binded by and, or and not condition. This is similar to sql condition binding.

Once the expression binding is completed, then we required to put as where clause in expression. This is done by calling API

POM_enquiry_set_where_expr(“get_itemid”, "ExprId3")

This set the where clause against expression ExprId3 which in binding expression for ExpId1 and ExpId2.

Query Execution
The above steps completes POM query which is now equivalent to SQL query. Now query required to be executed. Which is done by calling API

POM_enquiry_execute(“get_itemid”, &rows,&cols,&results)

Where row, col and report are output. 

rows : number of results.

cols : Number of column for each result

results : result of query in two dimension array. This is array of void pointer

The above binding can be better understand by below diagram.

Once query is executed and results are stored in array, they required to extracted and type cast for specific type based on select attributes provided for POM Query. For example is above case we extracted puid which is nothing but object tag. So we required to convert our output to tag pointer. Below psedo code shows how to extract and store it in tag array.

if(rows > 0 )

      {

            int reportrow = 0 ;

            tag_t *objs = Null Tag

            (objs) = (tag_t *)MEM_alloc( (objs), ( rows) *sizeof(tag_t)));

            for ( int i= 0; i< rows; i++)

            {

                  (objs)[i] = (*(tag_t *)( results [i][0]));

                 

            }

           

      }

Once results are stored after type cast then this object can be used as a any tag object id in teamcenter.

Delete Query

After executing the query and storing the result in appropriate object type we required to delete the query. Remember the each query is unique and identified through its string name. If we don’t delete the query, then query will remain in given state in a session and again if it hit same code it will trough a error as query with the given name is already registered in a session.

POM_enquiry_delete ( “get_itemid” )

That’s all for introduction POM query. Once you understand basic of POM query, you can implement various complex query by joining two tables and having multiple expression hierarchy. Most of the SQL statement can be converted to POM query. I suggest for complex query better to first visualize in term of SQL statement and then design POM query.

Teamcenter Data Model

Data Model is core of any Packaging software. To have a good technical command in any package, it is important to have a good understanding of its Data Model. Teamcenter is no difference with it.  In this blog, I will explain basic data model of Teamcenter as well corresponding schema in Database. This will help people new to Teamcenter to have a better understanding of Teamcenter system.

Teamcenter Data model can be categorized in to three distinguish layer. They are

·         POM or Schema Layer

·         Business and Relation Object Layer

·         Business Rules

POM or Persistence Object Model is lowest layer, which basically represent mapping for underlying Data Base of Teamcenter. It is not always one to one mapping, but closest to DB Tables for most of classes. Developer should know detail aspect of POM layer for customization and extension of system.

Business and Relation Object Layer resides above POM layer. This layer represents actual entity to Business and its process. Mainly Business Analyst or Solution Architect interacts at this layer.  Business Object and Relation defines overall Data Model from Business process perspective.

Business Rules are the top level layer of Data Model. This layer basically constitutes Business Object behavior based on the rules configured in BMIDE. Business rules along with Business Object encapsulate overall PLM business process. Teamcenter provided both configurable like naming rule, conditions etc or custom like extension for defining business rules.

Below diagram shows the basic building block of Teamcenter Data Model.

 

POM Schema of Teamcenter Data Model:

Teamcenter Data Model Schema is hirierachy based, it means there is base level object through which all the object in the stystem are derived. The base object in Teamcenter is called POM_object. It is base parent object for all object defined in Teamcenter. POM level object  are represented as tables in Teamcenter data base. All derived class of Teamcenter Data Model is represented as corresponded table in data base. Under POM_object classes there many immediate child classes which are mainly used as storage classes like form storage class. Out of which one important class is POM_application_object class. This is important class from perspective of it actually representing all Business object of Teamcenter.  Workspace object which represent as parents of all objects which user can see in the teamcenter is derived from POM_application_object class.

All Business classes in Teamcenter either directly or indirectly (through hierarchy) is derived from workspace object. For example Item class is derived from workspace object. Same is valid for Folder, Dataset or ItemRevision. Below diagram shows the class hierarchy for basic workspace object.

 

Most of time you create custom type by extending data model of Item or form type. Once deploy from BMIDE, it will create a new table in Data base with columns having custom attribute defined in BMIDE. All inherited classes automatically inherit parent attributes. Hence child attributes are combination of parent attributes plus child attributes.

Business Object:

The building block of Teamcenter is Business Object. It resides above POM Objects or DB Classes. Business Object can be seen as actual representation of real life entity which are encapsulated as Business object. The underlining objects are still persistence schema classes.  Teamcenter UA provides hundred of OOTB business objects. Following are major characteristic of Business Object.

1)      Business Objects are related to each other through relations.

2)      Business Objects have property which can be persistence (attributes from underlining classes) or Dynamic (evaluated run time).

3)      Business Objects behavior can be controlled through rules which are defined in BMIDE. Rule can be either configurable (Ex: Naming Rules) or customization (extension, user_exit etc).

GRM Relation: Teamcenter Relation is second building block. Relation defined the inter dependent of various Business Object with each others. In Teamcenter Relation can be categorized in to two groups.

a)      Reference by : The Business Object underline schema classed direct has reference to other object through attributes. It can be compare to pointer reference to other classes in object orient concept. For example POM_application object has reference to owning group or user.

b)      GRM Relation : Other way relation between is created by creating a relation object which encapsulate both Business object through concept of primary and secondary object. Advantage of using GRM relation rather than direct relation is that of having more flexibility in term of defining business rules. For example you can define DeepCopy Rules or GRM Rules. Also different relation type object can be created to defined different Business rules.

Property:

Properties define business objects. All attributes which are present in underline POM Class for given Business Object are automatically become property of Business Object. Apart from persistence property, there are other properties which are either derived from other relation object or created run time by writing custom codes. Teamcenter property can be classified in following four categories.

a)      Persistence Property: Attributes which are stored in database. This are defined in underline schema classes.

b)      Compound Property: It a property which basically propagates property of other object which is related to target business object through either reference or relation. Example of this can Form property shown at Item or Item Revision.

c)       Runtime Property: These are property define dynamically through custom code. The custom code required to be written, which executes when the property value is fetch from server.

d)      Relation: This is property which defines relation between target object and source.

That’s all from Teamcenter Basic Data Model Perspective. Hope this provide good starting point  for people who want to understand Teamcenter Data Model.