Још

Wednesday, November 28, 2012

Teamcenter SOA : Introduction

Service Oriented Architecture (SOA) framework is offered by many enterprise product vendor due to its advantage of interoperability as well
reusability. Also due to service based framework based on buisness use case maje SOA API are easy to use as it hide all complexity to Applica on
Developer. Teamcenter also offer SOA framework for customiza on as well for integra on with other Applica on. In series of Blog's I will provide detail
concept of Teamcenter SOA framework and crea ng your own SOA based on Tc SOA Framework.

Teamcenter UA SOA :

Teamcenter provide SOA framework as well set of out of box SOA service for direct consump on. Teamcenter SOA can be basically used in two ways.

1) Using OOTB SOA service as SOA client.

2) Crea ng your own SOA which can consume by others.

Teamcenter SOA support following language presently C#, C++ and Java. Development can be done in any of above language either using OOTB SOA
service for Applica on Development or developing your own SOA for other developer usage. The list of SOA service can be seen in BMIDE under
extension -> Code Genera on->Services. It provides all the list of Service available for given Teamcenter environment. Also you can get all detail of Data
Type and Opera on corresponding to SOA services in the BMIDE as shown in below image. We will discuss in detail about Data Type and Opera on in
future blogs.

Teamcenter SOA Framework:

Teamcenter SOA service Framework provide set of connec on protocol like HTTP, Corba and auto generated stub in the server as well Data Model to
support client applica on. SOA server architecture resides above Business Object layer (AOM layer). SOA server code can call ITK API to perform
business logic as shown in below diagram.

1 од 9
Teamcenter SOA is set of API or programming interface used for applica on developer. The API libraries are present in soa_client.zip file on the
Teamcenter software distribution image. The libraries are present inside soa_client for respective supported programming language Java, C++ and C#.
This ZIP required to be extracted preferably in TC_ROOT folder for linking Application code which usage SOA service. soa_client.zip also contain
some sample SAO code in all supported language.We will see in my next blog how to use SOA API , establish connection through SOA and use OOTB
SOA services.

See Also :
Teamcenter SOA : Using OOTB SOA Services
Temcenter SOA : Sample SOA Code Setup

Teamcenter SOA : Create your Own SOA

Teamcenter SOA : Detail Step for Creating SOA

Posted by Manoj Tiwari at 4:28 AM 8 comments:

Sunday, October 28, 2012

Teamcenter Report Framework

Report is one of the key modules in any PLM system. And with the advancement and more emphasis on Analy c and Repor ng on Enterprise data, it is
going to play key role in future. Till now Report in PLM are sta c and so called dumb data. They just provide data in term of data extrac on and
transforma on mainly done through style sheet. Now with the advancement of technology and powerful system report is become more complicated
and expected to provide answer rather than just dumping the data in nice format. Teamcenter also provide tool for crea ng both sta c as well
intelligent report. In this blog we will discuss on sta c report which can be created in Teamcenter through in Build report module. The func onality for
complex and Analy c Report is also available in Teamcenter through third party tool.

Reports in Teamcenter: Teamcenter provide to Report Builder Module to create report based on PLM data from Teamcenter. Reports in Teamcenter are
based on Query and PLMXML Framework. The basic concept is to get the objects from Teamcenter through query which is basically converted by
Teamcenter server in to PLMXML output on top of which xsl style sheet can be applied for layout and Report UI. PLMXML output can be controlled in
same way as of crea ng Transfer mode for expor ng/impor ng object from Teamcenter. I already cover PLMXML in my earlier blog . Reports Builder
always create Sta c Report Report Builder. Reports are basically categorized in three types in Report Builder.

1) Summary Report: These are basically general overall report where report is not in context of specific object. Ex: Change Object Status Reports
2) Item Report: These reports are generated in context of specific object which generally selected by user to create a report. Ex: Signoff Report
for CR where CR required to be selected.
3) Custom Report: Teamcenter provide custom Hook for crea ng Custom report which usually can’t be created through Query or XSL. A custom
exe can be wri en which can create a report when executed by user in Teamcenter session.

Report Builder Modules Component:

Report Builder five major components which basically define the extrac on and transforma on rule for Reports.

2 од 9
Query: This is search query created in Query Builder module of Teamcenter. Query defined which object required to be extracted under different
search criteria. Search Criteria can be either based on some property of Target object or based related object (Ex Item Revision as Target and Dataset as
related object). The search criteria either can be exposed to end user or it can be hidden. I covered Query in detail in my Query Builder Blog.

Closure Rule: This component comes from PLMXML module. It defines the extrac on rule for the object extracted from Query. The Closure rule defines
what other related objects required to be extracted along with target object coming from Query. See my PLMXML blog to know more about Closure
Rule.

Property Set: This defines addi on a ributes required to extract apart from default property for given Object Type by PLMXML Engine. See my
PLMXML blog to know more about Property Set.

Report Format: This define XML format for report extracted from Teamcenter. Teamcenter two format tradi onal PLMXML and TcXML based on new
schema available in Teamcenter Unified.

Report Style Sheet: This defined the Layout of the report. This style sheet is XSL files which can convert the XML output from Teamcenter in to different
compa ble format with proper layout. You can know more about style sheet in W3C site or Wikipedia. Most of the me customiza on of Report will be
limited to XSL crea on based on Report Layout requirement.

Custom Component: This is used when you want to create custom reports through some customize code. We required providing path of custom
executable and parameter if any required for custom executable.

Most of the generic report can be created from Report Builder without required for any customiza on. But the limita on is that this report will be
always sta c report and no intelligence can be provided (Filter criteria, If-Else Analysis etc). Also there is no way to fetch data from different source and
normalize with Teamcenter for Repor ng.

Due to above limita on Teamcenter also provide ghtly integrated Teamcenter Repor ng and Analy c for advance report from different
data source as well for Analy cs.

See Also :
Basic of PLMXML Export/Import
Teamcenter Query Builder

Posted by Manoj Tiwari at 9:48 AM 3 comments:

Saturday, September 15, 2012

PLM Migration : Part 2

This is con nua on of my previous blog on PLM Migra on Part 1. In this blog I am going to discuss about other PLM migra on considera on . On my
previous blog we discuss about

· What to Migrate
· How to Migrate
· Before you start

In this blog we will discuss in brief about remaining factors

· Design Approach

3 од 9
 · CAD Migra on
· CAD vs Meta Data Migra on

Design Approach:
Design of Migra on required having be er architect and valida on mechanism. Also log and Report crea on mechanism should be in place. Most of
complex migra on is done through ETL process mainly through staging data base where transforma on, normaliza on and cleaning is done. Following
point should be considered while doing Design through ETL process.

1) Clean interface data load and Staging Table design should be defined. It is recommended to have separate table for input data and for
transforma on. This will help in be er traceability and data valida on.
2) All excep on related should be log in Error table and appropriate report should generated for further ac on on those excep ons. This will
help in saving lot of me at upload stage since most of issue can be caught in transforma on stage.
3) Sequence of interdependent upload should be well defined and documented. Since in PLM is a complex web of interlink data the hierarchy of
data dependency as well sequence data load is important to defined.
4) If there is mul system migra on then proper valida on procedure should be wri en for integrity of data and its accuracy from different
system

Typically following High Level flow involved in ETL migra on.

1) Extrac on from legacy system.

a. Meta Data Extrac on
b. Non CAD Files
c. CAD extrac on
2) Load Meta data to staging
3) Input data Valida on
4) Transforma on
5) Post Transfer Valida on
6) Staging Extrac on for upload
7) Data Upload.
a. CAD Upload
b. Metadata and Volume files Upload

It is important to do Design for sync of Metadata, File and CAD files upload. All three are interdependent on each other. For example CAD load will may
required property like type, part number etc from staging for CAD upload.

CAD Migra on:

CAD Migra on is one of the difficult aspects of PLM migra on. Usually CAD migra on is usually done through third party tool which has CAD
integra on capability with the given system. For example Siemens PLM provide UG NX tool like ug_export/ug_import and ug_clone for export/import
CAD part from Teamcenter. These tools provide lot of configura on op on for doing custom export/import to the PLM system. These types of tools are
usually used for migra ng CAD part by providing proper configura on file.

The most considera on for CAD migra on is to understand modeling philosophy of organiza on like master model concept and inter part rela on. For
in NX you can create CAD model which are dependent on other part through expression or geometry. The above understanding is very important to
define the process and sequence of CAD data. Following should be considered before deciding on CAD migra on.

1) Modeling concept used in Organiza on.

2) Interdependent part rela on in CAD model like expression, wave link, pa ern, template etc in NX.
3) Categoriza on of part in different bucket to decide on sequence of migra on like library part, assembly or sub assembly etc.

4 од 9
 4) Understand if non master file like CNC or dra ing file etc. Understand there dependency on other parts.

Based on above analysis defined the CAD migra on strategy.

CAD vs Meta Data Migra on:

It is also important to understand dependency between Meta data and CAD in PLM system. In most of PLM system CAD integra on with PLM system
also depends on objects rela on in the System. For example wave link in NX also create a Teamcenter rela on. Also CAD migra on will also required
migra ng CAD files based on new part number and types. This informa on is a part of metadata but required for correct migra on of CAD in new
system. Hence this informa on will available from staging DB.

This closes my discussion on Migra on. I try covering important aspect of migra on Analysis to Design phase. There are other important aspects of
Migra on like tes ng which itself is a topic on its own. I will try to cover it seperate blog.

See also :
PLM Migra on : Part 1

Posted by Manoj Tiwari at 6:59 AM 3 comments:

Sunday, September 9, 2012

PLM Migration : Part 1

One of the most challenging aspect in PLM field is data migra on. It not only required metadata migra on but also vault files system specially CAD
files and this create higher degree of complexi y. Not only it required to make sure that all object and rela on are migrated correctly but also sanity of
interpart rela on related to CAD should also maintain. In this blog I will discuss the factor required to be consider for PLM migra on. Since migra on it
big topic, hence I will split the contain in to two parts.

Migra on Considera on:

Following are the important steps for PLM Migra on

· What to Migrate
· How to Migrate
· Before you start
· Design Approach
· CAD Migra on
· CAD vs Meta Data Migra on.

What to Migrate:
For any migra on you have to know what required to be migrated. In PLM migra on there will three aspect of migra on

1) Meta Data Migra on

2) Document File Migra on
3) CAD Migra on

Meta Data Migra on is migra on of data stored in DB from one system to other. Where Document migra on of actual files which is maintain by one
system to other. CAD migra on e

From system migra on perspec ve it can be either of this

1) Single System migra on i.e from one system to other system migra on
2) Mul System migra on. It can either of
a. Mul ple to Single System Migra on.
b. Mul ple System to Mul ple System.

For complexi y perpec ve Mul ple System to Mul ple System will be most complex. But they are usually break down to various project to make them
Mul ple to Single System migra on.

To define what to migrate we have to do first have good understanding of old and new system. Also required to have understanding of Buisness
process. As in many cases moving to new system also involved change in Buisness process to leverage the advance func onality of new system. Hence
proper analysis required to be done for Old vs New process as well GAP analysis for finding any short coming in new system func onality.

Once the above analysis is done then it come what data required to be migrated. In all cases metadata mapping play prominent role as they represent
real mapping of Buisness process to Object. Following aspect of Metadata mapping has to understand properly.

1) What are Buisness object from present system are required to migrated to new system.
2) What are the property of Buisness object required to be Migrated.
3) What rela on between objects is there in old vs new system

Object Mapping is most important aspect of migra on. Success of any migra on will depend on effec vely and correctly the mapping is done. Mapping
with will be usually boil down one of this scenario.

5 од 9
 1) One to One Mapping : One object map to similar object in new system.
Ex Part to Part migra on
2) One to Many Mapping : One object map to many object in new system:
Ex SAP Rou ng can map to Item and Item Revision.
3) Many to One Mapping : Many object map to one object in new system.
Ex: Two Object with rela on object merge to single object in new system.
4) Property to Object Mapping : Any Property in old system will map to Business object in new system.
Ex : Work Area property of Rou ng Opera on in SAP map to Workcell Item in Teamcenter.

Next step for migra on is related to approach to Migra on

How to Migrate:
Once the What context of Migra on is clear, then come How. The approach is defined by considering many factory. Factor can be categorize in
following points

1) Bulk vs Phase wise migra on

2) Custom Migra on vs Thrid Party Migra onTools.

Bulk vs Phase wise migra on : Bulk migra on involve full migra on in one go. Following are the characteric c of Bulk Migra on

ü Complete movement of all data to new system at once.

ü All users switch over at the same me.

ü All processes move to New System at once.

ü Source system should not be modified a er migra on (read only)

Phase wise Migra on : This involved migra ng phase wise in a specific dura on may be few months to few years. This required to have both old
and new system to be co-exis ng for whole migra on dura on. Also may required to have sync interface between old and new system during
migra on period. Following are the character c of Phase wise Migra on

Movement of specific data to new system based on certain criteria. Ex Group wise, project wise, workflow based etc.

Set of users switch over the me.

Co-existence of old and new system for some dura on (From months to a year or so).

Bulk Migra on Phase Migra on

Lower overall costs Overall Higher Cost as two system required to maintain

No synchroniza on required between mul ple legacy Synchroniza on required between old and new system
and new system
Change Management and Training challenge is high. Be er Change and Training Management due to Phase
wise migra on
High impact in case of Migra on failure. Roll back can be easily done as old system coexist with
new system
Suitable for Simple to Medium Complex Data. Also Suitable for Complex data mode and huge CAD
simple CAD with few BOM Line and depth assembly.

Custom Migra on vs Thrid Party Migra on: Second decision point is too made on Migra on tools. Basically Migra on tools can be either Custom
Tools required specifically for migra on or Vendor Tools. Most of Vendors provide offer Out of Self tools to migrate in their na ve system. For
example Siemens PLM offer GMS for migra on from Legacy system to Tc UA. Similarly other PLM Vendor provides similar tools. Analysis required
to be done whether those tools are suitable for migra on use case or not. It is observed that PLM vendor usually claim to cover all use cases but in
reality there GAP. This is truer if new PLM system has own migra on tool. This can lead to have more effort and cost then having custom
approach.

Custom Migra on approach is more suited if migra on is from mul ple system and data model is complex. Custom Migra on gives more flexibility
and control in migra on. But at the same me it requires more effort and upfront cost for development and regressive tes ng. Most of me
Custom Approach is done through ETL (Extract, Transform and Load) process where transforma on is done in staging database. Following are the
characteris c of both approach.

6 од 9
 Custom Migra on Approach Third Party Tool Migra on
Higher Upfront Cost Only License cost involved
Suitable for Mul System Complete Migra on Suitable for simple migra on supported tool
Regressive tes ng required Limited tes ng required as it cer fied by provider.
Flexibility in case change in Business cases Can be costly and me consuming if the Tool doesn’t
support those use cases

Custom Migra on approach also not really means developing everything from scratch. Most of me custom solu on also involved using out of box
u lity provide by PLM system. Usually wrapper is wri en on top of them to make seamless migra on. For example migra ng CAD data always involves
Vendor provided import/export tool which required to in sync with Meta data which can done through custom tools.

Before you start:

Before we start actual migra on design it most important to have following aspect should be closed.

1) Data mapping is completed.

2) Also all Gap analysis and accordingly approach should be finalize.
3) Expected Dura on of actual Migra on and delta approach.
4) Infrastructure requirement mainly Server Capacity, Space etc.

We already discuss about Data Mapping and Migra on Approach. It is also important to plan for expected dura on because that will also defined
strategy for delta considera on during migra on process. Delta means all changes done between actual migra on start and comple on in na ve
system. Since user can start working in new system only when the whole migra on is completed, it is import to bring transi on changes also in new
system. This is done through Delta Migra on planning. Delta migra on comes in to picture when the migra on is expected to take more few days and
changes can moved from old to new system manually.

Infrastructure requirement is also important factory as it required considerable planning. Typically infrastructure requirement is calculated based on
amount metadata as well volume required to be migrated.

This closes the first part of PLM migra on blog. In this we discuss about factor required to be consider for migra on. In the next blog we will discuss
about Design and CAD aspect of migra on.

See also :
PLM Migra on : Part 2

Posted by Manoj Tiwari at 7:22 AM No comments:

Thursday, August 30, 2012

Basic of PLMXML Export/Import

Basic of PLMXML Export/Import

PLMXML is a very powerful tools for impor ng/expor ng data and file from Teamcenter to external system and vice-verse. PLMXML is Siemens PLM
sponsors XML schema for expor ng/impor ng metadata as well files from Teamcenter to other system,

The advantage of PLMXML is its flexibility of defining rule for data extrac on and import make it one of the widely use tool for integra on and data
exchange. It is also widely used in teamcenter other module like report builder and integra on. For defining the rules, admin module is present where
new rules can be created or modified exis ng rules. This rules are called Transfermode. In this blog we will discuss in detail the transfermode and its
child rules.

Transfer Mode:
Transfermode encapsulate the rules which defines import/export data from teamcenter. It basically govern the Export/Import rules and meta data
which required to be extracted from Teamcenter. Transfer mode mainly consist of

· Closure Rule
· Filter Rule
· Property Set

7 од 9
Closure rule: It defines scope of data transfer. Basically it tells how to traverse from target object to its related object and whether to process or skip
the object. For example if you are expor ng Item Revision and also you required to export a ach dataset with specific rela on and type, you required
to defined this detail in Closure rule.

Closure rule compromises five fields, primary object selector, secondary object selector, rela on selector, ac on, and an op onal condi onal clause.

Primary object selector is the target object from which the traverse will be defined for its related object which is called secondary object selector. So as
in our example for Item Revision to Dataset, Item Revision will become Primary object and Dataset will become secondary object selector as rule will
be traverse from Item Revision to Dataset. Primary or Secondary object selector can be either of Buisness Type or Class. The third field rela on
selec on defines how the primary and secondary object are related. Object in teamcenter can be either related through rela on, a ribute ,property.
Other is re y which tell that secondary object refer the primary object. Also there is other two specific to BOM which is occurencetype and content.

Ac on field tell the system what required to done with secondary object. It take this words.
Skip : The secondary object should not be exported and no further traversing from object is required.

Process: Process the secondary object (extract object), but no further traversing.

Traverse: Don’t process the object (no data extrac on), but traverse further for other related object as defined in closure rule.

Alter_closure_rule: Change closure rule for secondary object

Only Skip ac on can’t be combined will other. Process+Traverse means process the secondary object and traverse further to process its related object.

The closure rule is sequen al, means the secondary object will become primary if you want to extract data which is related to secondary object. For
example if you want to extract the file of Dataset when Item Revision is exported then we required to define new rule in closure rule which define the
traverse rule from dataset to Imanfile.

Property Set: It defines what property can extracted from process object. Closure rule which object required to be process, whereas Property set
defined what data/property required to be extracted for those object. By default Teamcenter extracted some set of property for different type of
object. For example revision id for item revision. But user required to extract further informa on then those required to defined in Property Set and
add in transfer mode.
It cons tute this following field.
Class or Type : Defined class or type name.
Property or A ribute: Define the a ribute required to be exported.
Ac on: Define whether to process the property or skip.

So for example if we required to extract the descrip on property of Item Revision, it required to be defined as shown in below figure

Filter rules : Filter rules allow a finer level of control over the data that gets translated along with
the primary objects by specifying that a user-wri en func on is called to determine
the filter applied against a given object. Basically it is required for complex scenario where closure rule can be in sufficient to control PLM Data

8 од 9
Export/Import. Mainly for condi on like if, else if cases and required customiza on.

Ac on rule : Ac on rules are set of method which can be call for before, during, and a er the
Transla on. Teamcenter provide some of out of box ac on rule. But client specific cases usually required customiza on. In TcUA ac on rule are
depreciated and replace by BMIDE extension mechanism

Posted by Manoj Tiwari at 2:23 AM 26 comments:

Newer Posts Home Older Posts

Subscribe to: Posts (Atom)

Simple theme. Powered by Blogger.

9 од 9