Introduction to Teamcenter Customization Teamcenter 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 Teamcenter customization architecture can be broadly distinguished based on Teamcenter Teamcenter technical architecture. It can be categorized in to three layers. Server or nterprise !ayer "eb !ayer #lient !ayer • • •
#lient !ayer is basically portal or thin client customization which usually deals with $I and data handling of the result of server request. S%A client is is S%A API for calling S%A services. &ou &ou can see in detail of Teamcenter S%A service in my S%A blogs. "eb "eb !ayer is nothing Teamcenter based '( deployment layer which basically communicate between Server and client. Server customization is core of all customization as most most of the )usiness logic is written in this layer. It mainly deals with all business transaction as it interacts with data base through Persistence %b*ect !ayer +P%,- API. ,S is resource layer which support actual file transfer between client and server through ,S framework. or more detail in ,S you can visit my blog on Te Teamcenter amcenter ,S ,S.. Server customization is done through # based API provided by b y Teamcenter. Teamcenter. This API is also called Integration Toolkit +IT/-. Apart Apart from above discussed customization there is S%A customization and ),I0 e1tension which are basically either server and client2web customization or both. )elow diagram depict #ustomization #ustomization Architecture Architecture diagram for Teamcenter. Teamcenter. As As shown in diagram3 all ),I0 e1tension is in server side. This is because most of ),I0 e1tension overrides or changes ob*ect behavior based on business requirement. This can be only accomplished in server layer4 hence all e1tension is implemented by using core IT/ API provide in server layer. )elow diagram shows the #ustomization Architect of o f Teamcenter. Teamcenter.
)ased on above abov e #ustomization Architect3 Teamcenter Teamcenter customization can be categorized in to following area. 5. Serv Server er #ust #ustom omiz izat atio ion n (. Portal #ustomization 6. "eb or or Thin Thin clien clientt custom customiza izatio tion n 7. S%A S%A bas based ed cust custom omiz izat atio ion n 8. ),I0 ),I0 e1tens e1tension ion custom customiza izatio tion n
Server Customization: Server side customization is a most frequently used customization3 as all business logic are written in this layer. )asically all requests pass through through server layer for all teamcenter transaction. 9ence it is core of teamcenter customization. As discuss in #ustomization Architecture3 Teamcenter provide # based API called Integration Toolkit +IT/- for server side customization. This toolkit provides hundred of API for processing various business process based on Teamcenter functionality. The IT/ is categorized by various modules and functionality of Teamcenter. Teamcenter. Also Also various e1tension mechanisms are provided by IT/ toolkit to plug in custom code based on various Teamcenter Teamcenter events and ob*ect status. The detail discussion of IT/ customization is out of scope of this blog and I will cover it another blog.
Teamcenter #lient is layer is written on 'ava '# and eclipse Portal Customization: Teamcenter S"T. The The core client API are written in 'ava '# framework and slowly it will ported po rted to eclipse S"T framework. Presently Teamceter support both '# and S"T customization3 but it is recommended to do customization in S"T looking at Teamcenter Teamcenter future vision. vision. The Portal #ustomization can be done e1tending %%T) Plug:in or developing your own plug:in. Apart from from '#;S"T $I api3 the Teamcenter Teamcenter client API also provides ob*ect interface component which is an encapsulation of Teamceter 0ata model through #lient ob*ect model. This %b*ect Interface component also form interface layer between client and server.
)ased on above abov e #ustomization Architect3 Teamcenter Teamcenter customization can be categorized in to following area. 5. Serv Server er #ust #ustom omiz izat atio ion n (. Portal #ustomization 6. "eb or or Thin Thin clien clientt custom customiza izatio tion n 7. S%A S%A bas based ed cust custom omiz izat atio ion n 8. ),I0 ),I0 e1tens e1tension ion custom customiza izatio tion n
Server Customization: Server side customization is a most frequently used customization3 as all business logic are written in this layer. )asically all requests pass through through server layer for all teamcenter transaction. 9ence it is core of teamcenter customization. As discuss in #ustomization Architecture3 Teamcenter provide # based API called Integration Toolkit +IT/- for server side customization. This toolkit provides hundred of API for processing various business process based on Teamcenter functionality. The IT/ is categorized by various modules and functionality of Teamcenter. Teamcenter. Also Also various e1tension mechanisms are provided by IT/ toolkit to plug in custom code based on various Teamcenter Teamcenter events and ob*ect status. The detail discussion of IT/ customization is out of scope of this blog and I will cover it another blog.
Teamcenter #lient is layer is written on 'ava '# and eclipse Portal Customization: Teamcenter S"T. The The core client API are written in 'ava '# framework and slowly it will ported po rted to eclipse S"T framework. Presently Teamceter support both '# and S"T customization3 but it is recommended to do customization in S"T looking at Teamcenter Teamcenter future vision. vision. The Portal #ustomization can be done e1tending %%T) Plug:in or developing your own plug:in. Apart from from '#;S"T $I api3 the Teamcenter Teamcenter client API also provides ob*ect interface component which is an encapsulation of Teamceter 0ata model through #lient ob*ect model. This %b*ect Interface component also form interface layer between client and server.
Teamcenter "eb client. Web or Thin Client Customization < This customization is for Teamcenter Teamcenter Teamcenter provides standard web interface for viewing and editing Teamcenter ob*ect in web browser. "eb "eb client is builds on asynchronous 'avaScript and =,! +A'A=- to allow dynamic loading of data in the browser. The 9T,! pages are renders by *ava script on =,! data. ,ost of the thin client customization is carried through 'avaScript which allow the rendering as well managing request2response from web server. )oth client:to: server requests and server:to:client responses in Teamcenter thin client are standard 9TTP responses. Teamcenter services. It is a standard S%A based SOA Customization < It is also called Teamcenter services provided by Teamcenter for integrating with third party as well custom client. Also Teamcenter Teamcenter provides framework to create your own custom S%A services. I covered Teamcenter Teamcenter S%A services in detail in my S%A blogs. blogs. BMIDE Etension Customization: This is mainly a server customization using Teamcenter Teamcenter ),I0. ),I0 provide various e1tension customization mechanisms for implementing desired behavior in Teamcenter. Teamcenter. Some of e1ample of ),I0 e1tension is pre:action or post:action operation for )usiness ob*ect3 >untime property etc. This This e1tensions are implemented in ),I0 environment by writing #2#?? server code mainly using IT/ API. ),I0 framework create stub code and other require classes for e1tension implementation. 0eveloper only required implementing base logic of the e1tension. I will try to cover e1tension implementation in one of my future blog.
Apart from the above customization4 Teamcenter 0ispatcher module can also be customized for required translation behavior. ,ost of time 0ispatcher client required to be implemented for e1tracting and loading translated file from Teamcenter Teamcenter.. The 0ispatcher #lient ramework is based on Teamcenter S%A service service and most %%T) S%A API is used apart a part from 0ispatcher API which encapsulates most of comple1 Teamcenter Teamcenter S%A API calls. I already covered 0ispatcher #ustomization in my blog on Teamcenter 0ispatcher. See Also < Teamcenter !MS Overvie" Teamcenter Te amcenter SOA : Introduction Teamcenter Dis#atcher !rame"or$ Posted by ,ano* )log at 55<76 A, @o A, @o comments< mail m ail Th This is)lo )logT gThi his sSha Share re to Twitter Twitt erShare Share to acebook
Sunda%& Au'ust (& )*+, )*+ , Teamcenter -uer% Builder Buery )uilder is one of frequent used module in Teamcenter Teamcenter for creating ob*ect based search query. Buery )uilder is power full tool for quickly configuring c onfiguring Teamcenter Teamcenter for
ob*ect 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 >eport )uilder blog. blog. In this blog I will e1plain in detail about local query builder configuration and basic concept to create or modify query.
Basic o. -uer% Builder: Teamcenter Teamcenter Buery is based on Teamcenter persistence data model which I cover in Teamcenter Te amcenter 0ata ,odel ,odel.. ollowing are the basic characteristic of query quer y in Teamcenter. Teamcenter. 5. Buery is is created created against against any of the the Team Teamcenter center persis persistence tence class. class. (. Buery #riter #riteria ia can be defined defined either either on attribute attribute of targe targett ob*ect or for for the related related ob*ect which are related to search class through either C>, relation or reference. 6. #riteria #riteria can can be made made invisibl invisiblee to end user by making making use entry entry field field empty empty.. 7. Predefined Predefined keyword keyword variable variable can be used used against against some of the attribut attributes. es. These These variable values are e1ecuted at runtime. or e1ample keyword variable D$S>I0 will resolve to session userid when query will be e1ecuted. 8. Teamcenter Teamcenter also support keyword query which allow to search dataset files content3 that contain a specific keyword or combinations of keywords. E. Buery can also also be custom customized ized through through Teamcent Teamcenter er use e1it. F. Buery result resultss always always shows list list of ob*ect ob*ect of class class which which is defined defined as search search class in query builder.
Ste#s .or creatin' -uer%: )elow description shows list of task required to be done for defining new query in Teamcenter Teamcenter through Buery )uilder. 5. De.ine -uer% < )efore creating query3 you have to first define what e1actly required to be search and in what conte1t. #onte1t means some condition or criteria which user can either provide while e1ecuting search or defined as basic criteria for search itself. or e1ample3 if you want create a query for find specific 0ata type only3 then you defined %b*ect Type Type is query builder and make the field invisible. (. Ma# to Data Model < After defining search requirement 3 you map it to persistence data model of Teamcenter Teamcenter.. This become your search class in Buery )uilder. )asically )asically the output will be shown for instance of this class only. It is assumed the admin user who will be building bu ilding the query will be aware of basic data model of Teamcenter. I covered it in the my Teamcenter 0ata ,odel blog blog.. %nce you select the Search #lass3 automatically its attributes and C>, relation are shown in Attribute 0isplay area. The attributes can be filter to show only class specific attributes or all inherited attributes from all parent classes. 6. De.ine Search Contet < Then defined search criteria or conte1t in which search required to happen. or e1ample if you want to get Item >evision which has attachment of specific data set only. only. In this case you have to traverse from search class i.e Item >evision >evision to 0ataset through predefined C>, relation shown in attribute display area or through reference by from imanrelation imanrelation ob*ect to 0ataset +Primary ob*ect to Secondary %b*ect-. 7. /se Search Criteria !ield : At last you defined the the criteria which you want to e1pose to user for e1ecuting the search. This defined list of attributes shown to
$ser whose value can be set by user before query e1ecution. The attribute can be of search class or related class.
-uer% Builder Dialo' Section Buery )uilder ,odules has three important sections as shown in below image
Search Class < This is target class against which search will be e1ecuted. The search result will be list of instance of this class. As defined above section this will be base class for query. &ou can navigate required class from #lass Selection dialog which shows Teamcenter hierarchy data model.
Attribute Selection: This provide list of attributes of search class. %ption 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 #riteria Search Criteria: This defined criteria for conte1t search as well user search criteria field. ollowing are field of Search #riteria section )oolean >ule < This connect multiple search clauses in search criteria through And2%> condition. A@0 condition required related clauses should be satisfied where as %> condition means any of them.
$serntry @ame < Shows the display name shown in query. It refers to query locale file for actual display name of attributes search dialog. ,ake it empty if you want to hide some of clauses. !ogical %perator< This is most important field of Search field which defined actual query condition required to be e1ecuted. It basically define rules of attributes are evaluated against the value provided for e1ecution. or e1ample for date attribute you can defined greater then or less then %perator to e1ecute query for before or after date clauses. Buery builder support almost all sql operator clauses. The below image shows all support operation condition in Teamcenter.
0imitation o. -uer% Builder: Although Buery )uilder is very powerful tool of Teamcenter for configuring ob*ect based query3 but it also has some limitation due to Teamcenter data model design. 5. Buery can be only be configured for persistence data ob*ect. (. Buery can be only build for ob*ect in the conte1t of related ob*ect defined in 0ata ,odel. That means query against two independent ob*ect which are not related through some relation or reference canGt be created. 6. There is no way to filter Search >esults based on specific filter rules. or e1ample if I want to get latest >evision of Item3 it canGt be achieved through configured Buery )uilder search. The results will be shows all revision of the item. The reason is all Item >evision of Item are related to Item on ly which is of reference relation and there is no way defined search criteria which filter old revision. 7. Buery rules canGt be build for *oint query or set of and ;%> clauses as can be defined in SB! statement. or e1ample in SB! you can build where clause based
on set of and ; or clause through grouping the clauses throuch under different bracket +- . 8. Buery results only shows list of instance of search class only. &ou canHt see related ob*ect along with search ob*ect in query results dialogs.
See Also : Teamcenter Data Model Teamcenter 1e#ort !rame"or$
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 dierence with it. In this blog, I will eplain 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 categori!ed in to three distinguish layer. They are P"M or #chema $ayer %usiness and &elation "b'ect $ayer %usiness &ules P"M or Persistence "b'ect Model is lowest layer, which basically represent mapping for underlying Data %ase of Teamcenter. It is not always one to one mapping, but closest to D% Tables for most of classes. Developer should know detail aspect of P"M layer for customi!ation and etension of system. %usiness and &elation "b'ect $ayer resides above P"M layer. This layer represents actual entity to %usiness and its process. Mainly %usiness (nalyst or #olution (rchitect interacts at this layer. %usiness "b'ect and &elation de)nes overall Data Model from %usiness process perspective. %usiness &ules are the top level layer of Data Model. This layer basically constitutes %usiness "b'ect behavior based on the rules con)gured in %MID*. %usiness rules along with %usiness "b'ect encapsulate overall P$M business process. Teamcenter provided both con)gurable like naming rule, conditions etc or custom like etension for de)ning business rules.
%elow diagram shows the basic building block of Teamcenter Data Model.
POM Schema of Teamcenter Data Model: Teamcenter Data Model #chema is hirierachy based, it means there is base level ob'ect through which all the ob'ect in the stystem are derived. The base ob'ect in Teamcenter is called P"M+ob'ect. It is base parent ob'ect for all ob'ect de)ned in Teamcenter. P"M level ob'ect are represented as tables in Teamcenter data base. (ll derived class of Teamcenter Data Model is represented as corresponded table in data base. nder P"M+ob'ect classes there many immediate child classes which are mainly used as storage classes like form storage class. "ut of which one important class is P"M+application+ob'ect class. This is important class from perspective of it actually representing all %usiness ob'ect of Teamcenter. -orkspace ob'ect which represent as parents of all ob'ects which user can see in the teamcenter is derived from P"M+application+ob'ect class. (ll %usiness classes in Teamcenter either directly or indirectly through hierarchy/ is derived from workspace ob'ect. 0or eample Item class is derived from workspace ob'ect. #ame is valid for 0older, Dataset or Item&evision. %elow diagram shows the class hierarchy for basic workspace ob'ect.
Most of time you create custom type by etending data model of Item or form type. "nce deploy from %MID*, it will create a new table in Data base with columns having custom attribute de)ned in %MID*. (ll inherited classes automatically inherit parent attributes. 1ence child attributes are combination of parent attributes plus child attributes. Business Object: The building block of Teamcenter is %usiness "b'ect. It resides above P"M "b'ects or D% 2lasses. %usiness "b'ect can be seen as actual representation of real life entity which are encapsulated as %usiness ob'ect. The underlining ob'ects are still persistence schema classes. Teamcenter ( provides hundred of ""T% business ob'ects. 0ollowing are ma'or characteristic of %usiness "b'ect. 3/ %usiness "b'ects are related to each other through relations. 4/ %usiness "b'ects have property which can be persistence attributes from underlining classes/ or Dynamic evaluated run time/. 5/ %usiness "b'ects behavior can be controlled through rules which are de)ned in %MID*. &ule can be either con)gurable *6 7aming &ules/ or customi!ation etension, user+eit etc/. GRM Relation6 Teamcenter &elation is second building block. &elation de)ned the inter dependent of various %usiness "b'ect with each others. In Teamcenter &elation can be categori!ed in to two groups. a/ &eference by 6 The %usiness "b'ect underline schema classed direct has reference to other ob'ect through attributes. It can be compare to pointer reference to other classes in ob'ect orient concept. 0or eample P"M+application ob'ect has reference to owning group or user.
b/ 8&M &elation 6 "ther way relation between is created by creating a relation ob'ect which encapsulate both %usiness ob'ect through concept of primary and secondary ob'ect. (dvantage of using 8&M relation rather than direct relation is that of having more 9eibility in term of de)ning business rules. 0or eample you can de)ne Deep2opy &ules or 8&M &ules. (lso dierent relation type ob'ect can be created to de)ned dierent %usiness rules. Property: Properties de)ne business ob'ects. (ll attributes which are present in underline P"M 2lass for given %usiness "b'ect are automatically become property of %usiness "b'ect. (part from persistence property, there are other properties which are either derived from other relation ob'ect or created run time by writing custom codes. Teamcenter property can be classi)ed in following four categories. a/ Persistence Property6 (ttributes which are stored in database. This are de)ned in underline schema classes. b/ 2ompound Property6 It a property which basically propagates property of other ob'ect which is related to target business ob'ect through either reference or relation. *ample of this can 0orm property shown at Item or Item &evision. c/ &untime Property6 These are property de)ne dynamically through custom code. The custom code re:uired to be written, which eecutes when the property value is fetch from server. d/ &elation6 This is property which de)nes relation between target ob'ect and source. That;s all from Teamcenter %asic Data Model Perspective. 1ope this provide good starting point for people who want to understand Teamcenter Data Model.
Teamcenter 1e#ort !rame"or$ &eport is one of the key modules in any P$M system. (nd with the advancement and more emphasis on (nalytic and &eporting on *nterprise data, it is going to play key role in future. Till now &eport in P$M are static and so called dumb data. They 'ust provide data in term of data etraction and transformation mainly done through style sheet. 7ow with the advancement of technology and powerful system report is become more complicated and epected to provide answer rather than 'ust dumping the data in nice format. Teamcenter also provide tool for creating both static as well intelligent report. In this blog we will discuss on static report which can be created in Teamcenter through in %uild report module. The functionality for comple and (nalytic &eport is also available in Teamcenter through third party tool.
Reports in Teamcenter: Teamcenter provide to &eport %uilder Module to create report based on P$M data from Teamcenter. &eports in Teamcenter are based on
importing ob'ect from Teamcenter. I already cover P$M=M$ in my earlier blog . &eports %uilder always create #tatic &eport &eport %uilder. &eports are basically categori!ed in three types in &eport %uilder. 3/ #ummary &eport6 These are basically general overall report where report is not in contet of speci)c ob'ect. *6 2hange "b'ect #tatus &eports 4/ Item &eport6 These reports are generated in contet of speci)c ob'ect which generally selected by user to create a report. *6 #igno &eport for 2& where 2& re:uired to be selected. 5/ 2ustom &eport6 Teamcenter provide custom 1ook for creating 2ustom report which usually can;t be created through
!uery6 This is search :uery created in
Teamcenter !MS Overvie" 0ile Management #ystem 0M#/ is one of the Teamcenter component for managing )les or vault in Teamcenter. 0M# is responsible for all transaction related to )les from Teamcenter server and client. In this blog I will discuss the basic architecture of 0M# and its interaction with Teamcenter (pplication.
"MS O#er#ie$: 0M# is independent tool which run as service in server as 0#2/ and client machine as 022/. Teamcenter (pplication Tier and 2lient Tier interact with 0M# framework through 1TTP or 1TTP# protocol. The two components of 0M# are 0M# server cache 0#2/ and 0M# client 2ache. (s name suggest 0#2 is service running in server side which basically cache )le in server and serves multiple user re:uest where as 0M# client cache work in client machine where it serve re:uest for single user and also interact with 0#2 for getting latest or new )les from server. Architecture of "MS: (s discussed in 0M# "verview, 0M# has two components6 0#2 and 022. 0or basic installation you usually have one 0#2 and multiple 022 based on number of user using the Teamcenter 2lient. *ach of portal clients will have one 022 running on client machine. %ut in production *nvironment where user can be in multiple geographical location or number of user are so high that single 0#2 can;t service so many users. (lso if volumes are mounted in dierent server then also we re:uired 0#2 on each volume server as 0#2 is must for each of the volume server. 1ence we re:uired to have multiple 0#2 running in dierent server to server dierent geography or set of user or volume server. This multiple 0#2 server are distributed in such a way that they can be near to each of geographical location. Due to multiple 0#2 server architect we then re:uired to de)ne one 0#2 server as master for managing re:uest and routing to dierent 0#2 server. The below diagram shows 0M# architecture.
• • •
"MS on%&uration 2on)guration of 0M# is managed through ml )les. %asically there are three types of 0iles 0M# Master 0#2 022
3. 4. 5. B. C.
. E. F.
"MS master con%&uration )le is master con)guration )le resides in master 0#2 server. 0M# master con)guration )le which de)ne various 0#2 sites in cluster or 0#2 8roup. (part from 0#2 information it may information of Aolumes related to 0#2. It will also have default con)guration information for 0#2 and 022 which can be override by respective con)guration "S con%&uration %le is installed in each of the 0#2 server. 0#2 con)guration basically contain two main elements "MSMaster : De)nes 0M# master location from where 0M# Master 2on)guration )le can be read by 0#2. 0M# Master information help 0#2 to route the )le re:uest in case it doesn;t resides in it volume or cache. "S: De)ned detail of installed 0#2 in server. In has dierent parameter which de)nes )les transfer characteristic as well error and log information. (lso it has parameter related to 0#2 cache for )les as well cache location. The parameter vale basically decided based on load, )le si!e, performance re:uirement as well overall 0#2 architecture. " con%&uration installed in each client. It has two main elements fccdefault 6 This override 022 con)guration from 0#2. This has various con)guration parameter related to client cache and re:uest. parentfsc 6 This de)ne 0#2 which 022 refer to for downloading 0M# con)guration. ?ou can have multiple 0#2 de)ned as a backup for failover. ommunication "lo$ bet$een "MS and Teamcenter : %elow is the process for communication between Teamcenter and 0M#. ser try to retrieve )le from dataset. -henever there is any re:uest of )le in teamcenter by user, application server forward the re:uest to 0M# for retrieving )le from Aault. 0M# create a 0M# ticket corresponding to )le retrieval from vault. 0M# ticket is sent to client end which then re:uest to 0M# with 0M# Ticket. 0M# re:uest is routed to 022 installed in client site for 0ile retrieval. 022 check if the )le cached in 022 and not modi)ed. Modi)cation check of )le is done through concept of 8ID which is associated with every )le in Teamcenter. 8ID is a business neutral identi)er for )le contents, to determine when to pull a )le from its local cache. *very )le in a Teamcenter vault has a single )le 8ID associated with every replicated copy of the )le. (ny change in 0ile results in having a new 8ID for the )le. In this way 022 check for modi)cation. If )le doesn;t resides in 022 or changes, then 022 sent re:uest to 0#2 associated with the site id. The priority de)nes 0#2 re:uest se:uence if the 022 is con)gured with multiple 0#2 for given sites id. 0#2 check if )les is cached in its own server and belong to its own volume. "therwise it will forward it to corresponding 0#2. The other 0#2 site information its retrieve from 0M# Master con)g )le. 0#2 sent the )le to 022 which in turn route it to client re:uest.
The below diagram depict the overall 9ow of 0M# re:uest.
I cover all aspect of ,S overview. 9ope this will help to understand ,S working and configuration.
Teamcenter Dis#atcher !rame"or$2 Presently I am working Translation Service of Teamcenter. Though to share my learning e1perience with you people. Translation service comes as a 0ispatcher Service under teamcenter installation. Translation service is nothing but to translate one file format to other. or e1ample 0oc to P0. The broader task any translation are as follows. a- 1tract 0ata from Teamcenter. b- 1ecute Translation. c- !oad translated result to teamcenter. 9ence the 0ispatcher Service of teamcenter has three main components. 5- Scheduler (- ,odule 6- 0ispatcher #lient There is one more component called 0ispatcher Admin which is basically used for Admin activity and it is optional component. ach of the above three component run independently and can be run as service or in console. ach component can be run in different server. As name suggests scheduler manage the whole framework by interacting between ,odule and 0ispatcher client. 0ispatcher #lient component basically manage e1tract and loading of data. ,odule does actual translation. The below diagram depict the Translation rame work.
0ispatcher #lient is the front end of 0ispatcher ramework which basically interacts with Teamcenter through S%A for translation request. Teamcenter required to be configuring through TS preferences for new translation services and ob*ect type on which this service is valid. %nce the request is received to 0ispatcher #lient3 it processes the request and put all e1tracted files required to be translated in to directory called staging directory. Staging directory is required to be configured during 0ispatcher Service Installation. In staging directory a unique subfolder is created for each request by 0ispatcher client based on Task I0 generated during user request in Teamcenter. %nce 0ispatcher client completes the e1tract3 it inform scheduler for translation processing. Scheduler in turn informs ,odule to start processing the task. ,odule translate the file and put the output in staging directory. %nce completed schedule ping the 0ispacher client which load translated file back to Teamcenter. Siemens P!, provide lot of out of bo1 translation service which required to be make active. In ne1t blog I will provide more detail about each component and there configuration.
Con.i'urin' Translator In my last blog I discuss 0ispatcher ramework of Teamcenter. In this blog I will discuss in detail on each of module and how to configure #%TS translation service. As discussed in last blog there are three components for Translator. 5- Scheduler (- ,odule 6- 0ispatcher #lient ach module run as independent service and in different server. #omponent communicate through >,I Scheduler : This component act as ,oderator between ,odule and 0ispatcher#lient. ,odule and 0ispatcher#lient required configuring to communicate to Scheduler. %nce installed the scheduler directory structure created as shown below.
The transscheduler.properties file stored in config subdirectory which defined port and other properties for Scheduler. The scheduler can be run by runscheduler.bat present in bin subfolder. !ib store all 'ar file correspond to scheduler. ,ost of time there is no change required to be done in Scheduler once installed. Module: ,odule is the component which does actual translation. It interacts with Scheduler to get the Translation Task. ,odule invokes specific Translation based on Task information and Translator service available to it. . %nce installed the ,odule directory structure created as shown below.
The conf folder has translator.1ml which contains all Translation service details for ,odule. ,odules publish this service to Scheduler. )ased on this information Scheduler in turn dispatch specific Translation task to the ,odule. #ontain of translator.1ml look like as follow
The =,! show subsection of configuring one of Translation service in ,odule. very translation service in ,odule starts with name of service as element in translator.1ml. As in above e1ample Translation service 3tToCatia45 is configured under provider SI,@S with service name *ttocatia8. The above configuration show presently the service is not active. ,eans ,odule will not publish this service. If you want to make this
service active then required to change the isactive value to true. The TransEecutable element define the location of Translator root directory and name of e1e or bat required to call for translation. In above e1ample *ttocatiav8.bat will be invoked located at d<;Siemens ;0ISPATJ5;,odule;Translators;*ttocatia;v8 location. The %ptions element define what argument required to be pass. In above e1ample two arguments with Ki and Ko with their value will pass by ,odule will to *ttocatiav8.bat. The ,odule will convert the above config while calling actual *ttocatia translator as follows. d<;Siemens ;0ISPATJ5;,odule;Translators;*ttocatia;v8 location; *ttocatiav8.bat :i LInput file dirM Ko LoutputfiledirM The inputfile dir and outputfile dir will get at run time through 0ispatcher#lient component through Scheduler #omponent. The !ileEtensions define the input and output e1tension e1pected for this Translator. In this e1ample the input file will of .*t and output is of type .#ATPart or .#atProduct. Apart from this ,odule has transmodule.properties file which detail has related scheduler rmi port and staging root directory configured. The ,odule can be run by runmodule.bat present in bin subfolder. !ib store all 'ar file correspond to scheduler. Dis#atcherClient: This is the component which interfaces with Teamcenter. Its main *ob is to fetch data files Teamcenter and upload translated file to Teamcenter. %nce installed the 0ispatcher#lient directory structure created as shown below.
!ib folder contains *ar files for 0ispatcher #lient. All customize 'ar file for new translator service required to be copy in this folder. 0etail regarding Translator customization will be discuss in my ne1t blog. The config contain all file related to Translator configuration for 0ispatcher#lient. 0ispatcher#lient.config contains information related to Translator server like rmi port of Scheduler3 staging directory etc. "here as Service.properties contain information required to connect to Teamcenter like host3 Translator Teamcenter user3 tcserver port number etc. or activating #%TS translation usually we donGt required to change in 0ispatcher#lient component.
Activatin' COTS Translation Service: Siemens provided many #ots service with installation. )ut this service are by default are not activated. Also some of the Translator service required core service to be installed. or e1ample previewservice translation can only work if visualization and vis translator is installed. ollowing steps required to be
done to make any #%TS translator active 5- ,odify Translator.1ml inside ,odule;conf folder. ,ake service active by changing isactive attribute to true. See Translator.1ml image above. (- #hange the core bat file for that translator present in root service directort and provide all required variable value like tcNroot3 tcNdata3ugNroot etc. or e1ample in *ttocatia8 translator required to provide $CSN!I#@SNS>> in catiav8to*t.bat file. 6- erify following preference are present in Teamcenter to enable it in Teamcenter. a. TS.P>%I0>S < Provide list of Translator provider. SI,@S is a default value. So in case of configuring #%TS translation3 will required to change any thing. b. TS.T>A@S!AT%>S.. This provide list of Translation available by provider. So for #%TS configuration required translation service name for preference TS.T>A@S!AT%>S.SI,@S. or e1ample for *ttocatiav8 is required to be added here. c. TS... < Provide list of )usiness %b*ect type on which this translator can be invoked as primary ob*ect. or e1ample in case of *ttocatiav8 it should be invoked for 'T dataset type only. Then the preference required to be set is TS.0ATASTT&PS.SI,@S.'TT%#ATIA8 with multi:value and value as 'tSimplification and other dataset type which support 'T files. There are other preference which are optional.
Customizin' Translation Services In my last two blog I have given detail about Teamcenter Translation ramework and its #onfiguration. In this blog I will provide about customization and creating new translator service. As discussed in Translator ramework3 the three main components are 0ispatcher #lient3 ,odule and Scheduler. or any customization this component required to be customized. In all most all cases 0ispatcher and ,odule required to customize. "here as in 0ispatcher client you required to right a code for e1tracting or loading or both and for ,odule required to define calling e1e or bat fill which really do translation. Also required to configured translator.1ml as discussed in my earlier configuration blog.
Customization Ste#s:!et take a e1ample of one of Translation $se case where we required to translate one dataset content from one language to other and upload the translated file to same attach revision with specific relation and dataset type. @ow the requirement is to make this relation type and dataset type to be configurable. Steps required be performed are as follows. 5- 1tracting file to be translated from Teamcenter. (- Translating file to required language either using custom language translator or third party translator like Coogle Translator. 6- $pload the file back to teamcenter by creating dataset and upload the file. Attach dataset with given relation to Itemrevision. Step 5 and 6 will be part of 0ispatcher #lient whereas step ( will be part of ,odule implementation.
Dis#atcher Customization:0ispatcher provide *ava based out of bo1 implementation for e1tract from TaskPrep for e1tracting specific data from teamcenter.
Also it provides %%T) 0ata !oader for loading of output file automatically. This auto behavior can be controlled without writing piece of code by configuring Translator.1ml for the specific translation service. The entire class document related to 0ispatcher #lient can be found under docs folder inside 0ispatcher #lient root directory. Also sample implementation can found in sample folder under 0ispatcher #lient root directory. Implementation< 0ispatcher ramework provides two main interfaces for customization the translator. 5- Taskprep class for e1tracting the file from Teamcenter. Implementation to prepare task to submit to Translation serverice. (- 0atabase%peration class for loading the translated files to Teamcenter. $sually both the class required to implemented for new translation service. Taskprep is the first called when a translation request is created and 0ispatcher then find the specific task prep implementation for correspondent translation service request. %nce the Translation is done by ,odule 3the dispatcher invoke 0atabase%peration implementation for the given service for upload of data to team center. In our e1ample if we required to convert te1t document from one language to other then the task prep with first e1tract 0ocument from target 0ataset and put the file in staging location. %nce the module complete the translation the 0atabase %peration class will be invoke d and the translated file will be uploaded to Teamcenter with specified dataset type and attach to target ob*ect with relation.
Etraction Im#lementation : Taskprep implementation is done by e1tending com.teamcenter.ets.e1tract.TaskPrep which is an abstract implementation of e1traction. The abstract class has some member variable which encapsulates all detail of translation request as well staging directory location. Some of key member are request< The request ob*ect for the current e1tract session sta'in'0oc : The staging location in which all the files will be place. The function which is called e1ecution is prepareTask+-. It is defined as abstract for Taskprep class and required to be implemented by all e1tending classes. #re#areTas$67 is function required to be implemented. Pseudo im#lementation: $sually in implementation we access the target ob*ect called primary ob*ect and its associate ob*ect called secondary ob*ect through current request ob*ect. ollowing are pseudo code for same. m_PrimaryObjs = request.getProperty("primaryObjects").getModelObjectArrayValue();
m_eco!daryObjs = request.getProperty("seco!daryObjects").getModelObjectArrayValue();,odel%b*ect are S%A base wrapper class for all Teamcenter ob*ects . primaryob*ect are ob*ect in teamcenter which selected for Translation and secondary ob*ect are those ob*ect which are associated with target through relation. or e1ample in c ase of language translation we decided to that te1t file can be target ob*ect +Primary ob*ect- and the Item >evision to which is associated will be then secondary ob*ect. %nce we get the primary ob*ect then the @ame reference file required to be e1tracted from dataset and put in staging location. This is done through S%A call to teamcenter. Sample code snippet ataset dataset = (ataset) m_PrimaryObjs#i$; ModelObject co!te%ts#$ = dataset.get_re&_list(); 'ma!ile 'ile = !ull; &or(i!t j = *; j + co!te%ts.le!gt,; j--) i&(/(co!te%ts#j$ i!sta!ceo& 'ma!ile)) co!ti!ue; 0 'ile = ('ma!ile)co!te%ts#j$;m_'!putile = 1ra!slatio!2equest.getile1otagi!g('ile3 stagi!g4oc);Also required to create a Translation request detail3 which is referred by ,odule for translation. or e1ample in !anguage translator usecase we would required to have option where user can provide from which language to which language a translation is required. This is done by having Translator Argument while creating translation request by user. This can be retrieve and further process in Taskprep. The snippets for accessing the argument are as follows. Map tra!slatio!ArgsMap = 1ra!slatio!2equest.get1ra!slatio!Args(request);This ,ap contains an Argument as key and its value as value. Also Taskprep can create its own argument based on process which can be used by module or database loader for further processing. tra!slatio!ArgsMap.put(argume!t5ey3 argume!tValue);or e1ample in !anguage Translator we would required to change the character set to specific value based on translated !anguage selected by user. The translation request detail is created as 1ml file which resides in staging director under unique task id. The sample will look like this
)asically this 1ml contain user argument which required for Translation. or e1ample above the option provide from and to language. This is used by module for translating. Also it has detail of corresponding dataset3 item and item rev. This can be populated but not always required as in above e1ample we also population uid of primary and secondary ob*ect which can be used for loading the translated file to with specific relation to an ob*ect. 0oader Im#lementation: 0atabase loader is implemented by e1tending com.teamcenter.ets.load.0atabase%peration abstract class. !oad+- function required to be implemented for a translation service. The 0atabase%peration class has Translationdata trans0ata attribute which encapsulate all translated request data. rom translation data we can get all information we populate during e1traction +taskprep-. or e1ample from Transdata you can get result file list from translation. This help for loader to load all file in teamcenter. The pseudo code for same will
Translation0),apInfo z0b,apInfo O trans0ata.getTranslation0),apInfo+-4 !ist z>esultile!ist O TranslationTask$til.get,apper>esults+z0b,apInfo3 sc>esultileType-4 "here TranslationTask$til is utility class provide various generic facility. Sc>esultileType is e1pected file type for translation. $ser and Taskprep option can be access through TranslationTask which is a member of 0atabase%peration. The pseudo code for same will Translator%ptions trans%pts O transTask.getTranslator%ptions+-4 Translator%ptions provide encapsulation of all option with /ey and alue pair. The map can be access through %ption trans%ption O trans%pts.get%ption+i-4 if+trans%ption.get@ame+-.equals+Someoption@ame-str%utputType O trans%ption.getalue+- 4 $ploading of all result file is done through S%A call to Teamcenter. 0ispatcher ramework provides various helper class which encapsulate the S%A call to Teamcenter. If requirement canGt be fulfilled through helper class then S%A can directly be called for
the same. Qne of helper class is 0ataset9elper class which provides all functions related to dataset. %ne of function is which create new dataset for all result file list and attach it to primary or secondary target with a given relation. The pseudo code for same will be zat dtsethelper.createInsert0ataset++Item>evision-secondary%b*3 +0ataset-primary%b*3 Rdatasettype 3 Rreleationtype3 Rnamereferencetype3 R resultdir3 Rfilelist3 flag to insert to source dataset or itemrevision-4 'ar ile Packaging and 0ispatcher configuration< "e required to create a 'ar file for the custom dispatcher code. Also in 'A> file should have a property file which defines implemented Taskpreperation and 0atabase loader class initiated through reflection mechanism in dispatcher framework. This is sample property file. Translator.serviceprovide.translation servicename.PrepareOpackagename.TaskPrep class name Translator. .serviceprovide.translation servicename.!oadO packagename.0atabase%peration class name Service provider is the name of service provided3 for e1ample %%T translation service it is Siemens. It is configure as preference called TS.P>%I0>S. Translation Servicename is the name of Translation service which configure in ,odule config and in Teamcenter preference TS.T>A@S!AT%>S. In case of !anguage translation usecase service provider name can e1ampletranslation and service name can be e1amplelanguagetranslation. The content for property for this will be Translator. 1ampleTranslation e1amplelanguagetranslation.PrepareO#ac$a'ename20an'ua'eTransTas$Pre# class name Translator. 1ampleTranslation.e1amplelanguagetranslation.!oadO #ac$a'ename20an'ua'eTransDatabaseO#eration class name %nce the 'A> package is created it required to put is 0ispatcher#lient2lib folder. Also service.property under 0ispatcher#lient2config folder required to be update with the property file name import TS)asicService3TS#atiaService3TSProService3TS$C@=Service3TSPro*ectTransServic e3 ourpropertyfilename This will load all classed when 0ispatcher#lient is started.
Module Customization: ,odule customization usually has following steps. 5- #reate Translation programs or indentify third party application which is used for translation. (- $sually we create a wrapper of bat file to run the Program. This is not required but
most of the time we required to set some environment like Teamcenter root or Tc data. 6- Add the service detail in Translator.1ml under ,odule2conf regarding the service. !et take our e1ample usecase of !anguage Translator. "e are going to use third party translator for e1ample Coogle Translator for it. There are some 'ava API which invoke remote google translator. "e will required to create a 'ava wrapper on top of this API to create our Teamcenter Translator. %ur Program will take input file 3 outputfile with location3 language from which it will be translate and to language which required to translated. Probably we also required to create bat file for setting a 'AAN9ome and other env variable. This bat will also take this four parameter required for our program. %ur sample config required to be added inTranslator.1ml is as follow
"here ,odule>oot is a key word belong to module base directory. The above config when read by module framework will convert to call 8Module1oot9Translators9eam#lelan'ua'etranslation9eam#lelan'ua'etranslation2 bat in#ut;lan' value< =to>lan' value< Also a workflow action handlercan be created to integrate a !anguage Translation with #hange ,anagement and other business process. IT/ api required to be used is DISPATC?E1>create>re@uest2 9andler can implemented in such a way that it can take a argument of Translation Provider3 service name and various options supported by translation service. This will provide the fle1ibility to reuse the handler for other translation service.
This is from my side on Teamcenter Translation framework. 9ope it might be helpful for people who want to quick start on translation service. Any comments are welcome.
Teamcenter SOA : Introduction #ervice "riented (rchitecture #"(/ framework is oered by many enterprise product vendor due to its advantage of interoperability as well reusability. (lso due to service based framework based on buisness use case ma'e #"( (PI are easy to use as it hide all compleity to (pplication Developer. Teamcenter also oer #"( framework for customi!ation as well for integration with other
(pplication. In series of %logGs I will provide detail concept of Teamcenter #"( framework and creating your own #"( based on Tc #"( 0ramework. Teamcenter 'A SOA : Teamcenter provide #"( framework as well set of out of bo #"( service for direct consumption. Teamcenter #"( can be basically used in two ways. 3/ sing ""T% #"( service as #"( client. 4/ 2reating your own #"( which can consume by others. Teamcenter #"( support following language presently 2H, 2 and Java. Development can be done in any of above language either using ""T% #"( service for (pplication Development or developing your own #"( for other developer usage. The list of #"( service can be seen in %MID* under etension @K 2ode 8eneration@K#ervices. It provides all the list of #ervice available for given Teamcenter environment. (lso you can get all detail of Data Type and "peration corresponding to #"( services in the %MID* as shown in below image. -e will discuss in detail about Data Type and "peration in future blogs.
Teamcenter SOA "rame$or(: Teamcenter #"( service 0ramework provide set of connection protocol like 1TTP, 2orba and auto generated stub in the server as well Data Model to support client application. #"( server architecture resides above %usiness "b'ect layer ("M layer/. #"( server code can call ITL (PI to perform business logic as shown in below diagram.
Teamcenter #"( is set of (PI or programming interface used for application developer. The (PI libraries are present in soa)client*+ip )le on the Teamcenter software distribution image. The libraries are present inside soa+client for respective supported programming language Java, 2 and 2H. This IP re:uired to be etracted preferably in T2+&""T folder for linking (pplication code which usage #"( service. soa+client.!ip also contain some sample #(" code in all supported language.-e will see in my net blog how to use #"( (PI , establish connection through #"( and use ""T% #"( services.
Teamcenter SOA : /sin' OOTB SOA Services In last blog I have given introduction to Teamcenter #"( service. In this blog I will provide detail of using ""T% #"( services provided by Teamcenter. Teamcenter provide set of core #"( 0ramework class for login , *rror $ogging, "b'ect Model 2hange framework etc. (part from core 0ramework (PI teamcenter also provide set of #"( service for all modules like -ork9ow, 2hange Management,
I suggest going through the sample program provided in #("+client.!ip. I provided the detail of setup step for sample code in this blog. 0or using #"( service )rst thing is to connect to Teamcenter #erver with two tier iiop connection/ or four tier web &$/. Teamcenter #"( framework encapsulates most of connection implementation through com.teamcenter.soa.client.connection class and only re:uired credential management through implementing the 2redentialManager interface. The #"( client can implement either in .7*T,2 or Java. 0irst step is to get the connection instance for #"( which is done by creating connection instance
url is connection string for two tier or four tier server connection. credentialManagerInstance is a instance of class which implemented 2redentialManager interface. public class AppredentialMana&er implements redentialMana&er allin& SAO ser#ices: Teamcenter provide set of ""T% #"( service for dierent modules like work 9ow etc. *ach of this service has its own static service class which provide handle to those speci)c services. 0or eample
-ork9ow#ervice wfser N -ork9ow#ervice.get#ervice connectionObj/O connection"b' is the connection instance which we created above. #imilarly there are other several services for dierent functionality. Detail of all services and its operation detail can be seen in %MID* as shown in below images.
The above image show the #aved
The above code release given ob'ect by calling Teamcenter #"( service. This are basic step for doing any #"( service call. 3/ 8et Instance of re:uired #"( service by providing connection ob'ect. 4/ Prepare input argument Data for re:uesting for speci)c services. 5/ 2all the speci)c "peration for achieving the re:uired results. In above eample we get )rst -ork0low service instance. Then we prepare input argument by creating release options ob'ect, release input ob'ect and populating them with appropriate value. 7ote the most of (rgument for #"( (PI takes as array value and return are also in array. The reason for this is that Teamcenter #"( is design is such a way that it takes bulk re:uest in an array/ in single operation for avoiding multiple calls to server from client. 1ence in #"( implementation we have to )rst create instance of ob'ect and then encapsulate them in (rray. I hope the above blog will help you to understand basic aspect of using ""T% #"( services.
Temcenter SOA : Sam#le SOA Code Setu# In this blog I will provide detail step for setting up sample #"( code provided in install image )le under #"( !ip )le. %elow steps is for Java #"( sample code.
3. n!ip soa+client.!ip from install image to T2+&""T directory. It will create soa+client folder under T2+&""T. 4. Install *clipse 5. and launch 5. (dd 2lassPath variable for the root location of the soa+client folder. "pen the Preferences dialog of eclipes -indow @@K Preferences ... /. #elect the 2lassPath Aariable tab Java @@K %uild Path @@K 2lassPath Aariables/. (dd the variable GT*(M2*7T*&+#*&AI2*#+1"M*G, set it to the root path of the Gsoa+clientG folder
B. Import the pro'ect "pen the Import dialog 0ile @@K Import... / #elect *isting Pro'ect into -orkspace 8eneral @@K *isting Pro'ects into -orkspace / 2lick 7et, then browse to ...>soa+client>'ava>sample, select 0inish 7ote6@ -hile importing 0ileManagement sample, 0M#+1"M* need to be added 'ust like T*(M2*7T*&+#*&AI2*#+1"M* C. 2ompile the pro'ect If the ID* is not con)gured to %uild (utomatically, force a build of the pro'ect . *ecute the client application "pen the Debug>&un dialog &un @@K Debug .../ #elect the 1elloTeamcenter Java (pplication The launch is con)gured to connect to the server on http6>>localhost6E3>tc to change this &I on the (rgs tab.
If the connection is http, ensure its pointing out to the right &I and this can be checked through &un@KDebug 2on)gurations@K (rguments If it the connection is through iiop, it should be set as follows @DhostNiiop6localhost63CE4>Tc#erver3
.ote:/ "nly Java and 2 bindings work in 4@tier mode. E. 8o through the )les to understand how the services are being called and can be used in the custom solution. &efer my ""T% #"( #ervice %log for basic understanding of sample code.
Teamcenter SOA : Create ou O"n SOA In my last two blog I discussed about basic fundamental of #"( and how to use ""T% #"( in client side. In this blog we will discuss about basic for creating your own #"(. sually new #"( service is re:uired to be created when you don;t )nd ""T% #"( satisfying your re:uirement or what to have the service behavior in dierent way. 0ollowing are the guideline for creating your own #"(.
3/ 2heck whether you can achieve the re:uired result at client side by using ""T% #"(. 4/ (naly!e the desire state of transaction between 2lient and #"( server layer. 0or eample you have to look whether transaction should be committed in one re:uest or multiple re:uest provide by ""T% #"( is acceptable. 5/ (naly!e what service you want to implement. -hether it will be single re:uest base or multiple re:uests which satisfy the use case. B/ (naly!e what input to perform the service. This will help in de)ning input data type. C/ (naly!e what output will be provided for re:uested service and how the output will be used. This will also help in deciding whether you re:uired having loose or strong binding.
Before 0ou Start: %efore start you should understand some aspect of #"( service in teamcenter. 1oose #s* Stron& Bindin&6 The binding de)ne how the data map between #"( server and 2lient. $oose binding mean Ley>Aalue pair mapping as string map of data and its value. -hereas strong binding means the client data model is populated with typed ob'ects that correspond one@to@one with their server@side ob'ect type. 1ence decision re:uired to be taken based on use case. 0or eample if #"( service is for creating some static reports then loose %inding can be good option and for integration strong binding is good option. Data Type: Data Type de)ned encapsulation of Data while creating a re:uest for #"( service as well getting output from #"( service. In #"( you can de)ne data type either of #tructure, Map or *numeration. Meanings of this Data Types are same as in a programming language like 2 or Java. #tructure de)nes set of basic data types encapsulated in structure. #imilarly Map is data container. Operations6 "peration de)nes set of function which will available to client for created a re:uest for services to be performed. The #"( service can be either de)ned through single operation if it is a simple service or set of "peration if it is a comple use case.
reatin& SOA ser#ices: (s you understand the basic building block of creating #"(, we are ready for creating your own #"( service in the %MID*. The detail of steps of creating #"( service is given in this blog. 0ollowing are the steps of creating #"( service 3/ De)ne preference binding. 0or eample for Java you can select loose or strong binding. 4/ 2reate new #"( service library or use eisting if you already have one.
5/ 2reate new service under #"( service library. B/ De)ne all the data type which will be used for #"( "peration. C/ De)ned all the "perations with de)ne data type. The "peration will have input data type and return data types. Data Type can be either de)ned data type or ""T% data types. / 8enerate code in %MID* by selecting 8enerate 2ode @K #ervice (rtifacts. This will create stub code for both server and client side see step blog for detail/. E/ Implement the server side code for all de)ned operation in %MID*. The stubs for all "peration is already created by %MID* and only re:uired to implement the business logic for the "peration. #erver side implementation is always in 2 and 2T3 AP2 can be used for implementation. F/ 7o implementation is re:uired at client side. Q/ %uild the %MID* pro'ect. Jar )le created for the client if it is Java %inding/ and dll for server. 3/ Deploy the server dll in T2+&""TRbin directory. 33/ Implement custom #"( service in client side. The process is same as de)ned for ""T% service in the %log. "nly addition will be to add the client #"( 'ar )le in the 2lass path for using Java client and client dll if using c binding.
The detail steps is given in Steps for creating S%A.
These close my series on Teamcenter S%A. I thanks my friend )haskar for introducing me to Teamcenter S%A ramework. 9ope this blogs will help good foundation for all people who want to learn Teamcenter S%A services and serve as quick start on for using and creating own services.
Teamcenter SOA : Detail Ste#s .or SOA Creation This blog provides detail steps of creating your own #"(. The #"( service provides all the :uery present in Teamcenter
Detail Steps : 1. 2reate a new service library in %MID* *tensions tab by selecting Project @K2ode 8eneration@K#ervices
#elect the newly created service library *6 DB#oaTest/ and create new service 2.
2.
"pen the new service *6 #erviceTest/
2.
De)ne the DataTypes and "perations as per the re:uirement. *6 "peration is to get all the saved :ueries. De)ne Data Types as below
De)ne data type Test
a.
2lick on (dd button in the Data Types tab b. #elect #tructure and click 7et c. *nter name as Test"b'ect
:uery@KTeamcenter66Iman
De)ne data type Test8et#aved
2lick on (dd button in the Data Types tab b. #elect #tructure and click 7et c. *nter name as Test8et#aved
:ueries@KAector of Test
C. 2reate "peration using the above de)ned data type. #elect "perations tab of the service * Test #ervice/. 2lick (dd on to create new operation. a. 2lick on %rowse button of 7ew #ervice "peration dialog a. #elect DB66#oa66Test66+434+466Test#ervice66Test8et#aved
8.
a.
"nce the "peration is created, in "peration Tab when #ervice is opened. 6.
6.
#ave the datamodel.
6.
#elect the library created DB#oaTest/. #elect 8enerate2ode@ K#ervice (rtifacts
Q. 2heck the 2onsole view to know if the code generation is successful or errors in other case. Q. #ource and header )les corresponding to each service are created. They are placed in the following path in 7avigator view6 Project->src->server->LibraryName *6 (ccentureTest@Ksrc@Kserver@KDB#oaTest This folder contains the )les which need to be implemented by the developer/ Project->output->client->LibraryName @ This contains the auto generated )les for the client no changes re:uired to these )les/ Project->output->server->LibraryName @ This contains the auto generated )les for the serverno changes re:uired to these )les/ Project->output->types->LibraryName @ This contains the auto generated )les for the data types that are created. no changes re:uired to these )les/
2nferences: a. b.
i.
7ame of the service library6 DB#oaTest #ervices in the library DB#oaTest6
Test#ervice
c.
ii.
"perations in the service by name TestService 6
test8et#aved
"pen the source )le and enter the re:uired code. #hown below is the )le generated in the step HF. "peration Vtest8et#aved
lightened for a :uick notice.
34. a.
%uild the pro'ect. Dlls are generated in Project RoutputRclientR'ars Project RoutputRtypes Rlib if its c bindings/ U 'ars )les to added to 'ava client classpath
7ote6@
a.
Project RoutputRserverRlib libraries which would be copied to Teamcenter #erver T2+&""TRbin/
a.
Project RoutputRtypesR'ars Project RoutputRtypesRlib if its c bindings/ contains the types de)nition U 'ars )les to added to 'ava client classpath
