Teamcenter PLM

Sunday, March 16, 2014

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.

Sunday, January 19, 2014

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.

Saturday, August 17, 2013

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.

Server Customization

Portal Customization

Web or Thin client customization

SOA based customization

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.

Sunday, August 4, 2013

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.

Query is created against any of the Teamcenter persistence
class.

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.

Criteria can be made invisible to end user by making
use entry field empty.

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.

Teamcenter also support keyword query which
allow to search dataset files content, that contain a specific keyword or
combinations of keywords.

Query can also be customized through Teamcenter use exit.

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.

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.

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

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 totraverse from search class i.e Item Revisionto Dataset through predefined GRM relation
shown in attribute display area or through reference by from imanrelation
object toDataset (Primary object to
Secondary Object).

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.

Query can be only be configured for persistence
data object.

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.

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.

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 ()
.

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.

Saturday, June 29, 2013

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.

Saturday, May 18, 2013

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

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.

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

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

Sunday, April 14, 2013

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.

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 pointfor people who want to understand Teamcenter Data Model.