Introduction to Teamcenter Customization

Introduction to Teamcenter CustomizationTeamcenter provides variety of mechanism for customization of teamcenter based on business requirement. The customization is based on base framework of API provide by teamcenter. In this blog I will discuss all customization options and its architecture. Customization Architecture Teamcenter customization architecture can be broadly distinguished based on Teamcenter technical architecture. It can be categorized in to three layers.  Server or Enterprise Layer  Web Layer  Client Layer Client Layer is basically portal or thin client customization which usually deals with UI and data handling of the result of server request. SOA client is SOA API for calling SOA services. You can see in detail of Teamcenter SOA service in my SOA blogs. Web Layer is nothing Teamcenter based J2EE deployment layer which basically communicate between Server and client. Server customization is core of all customization as most of the Business logic is written in this layer. It mainly deals with all business transaction as it interacts with data base through Persistence Object Layer (POM) API. FMS is resource layer which support actual file transfer between client and server through FMS framework. For more detail in FMS you can visit my blog on Teamcenter FMS. Server customization is done through C based API provided by Teamcenter. This API is also called Integration Toolkit (ITK). Apart from above discussed customization there is SOA customization and BMIDE extension which are basically either server and client\web customization or both. Below diagram depict Customization Architecture diagram for Teamcenter. As shown in diagram, all BMIDE extension is in server side. This is because most of BMIDE extension overrides or changes object behavior based on business requirement. This can be only accomplished in server layer; hence all extension is implemented by using core ITK API provide in server layer. Below diagram shows the Customization Architect of Teamcenter. Based on above Customization Architect, Teamcenter customization can be categorized in to following area. 1. Server Customization 2. Portal Customization 3. Web or Thin client customization 4. SOA based customization 5. BMIDE extension customization Server Customization: Server side customization is a most frequently used customization, as all business logic are written in this layer. Basically all requests pass through through server layer for all teamcenter transaction. Hence it is core of teamcenter customization. As discuss in Customization Architecture, Teamcenter provide C based API called Integration Toolkit (ITK) for server side customization. This toolkit provides hundred of API for processing various business process based on Teamcenter functionality. The ITK is categorized by various modules and functionality of Teamcenter. Also various extension mechanisms are provided by ITK toolkit to plug in custom code based on various Teamcenter events and object status. The detail discussion of ITK customization is out of scope of this blog and I will cover it another blog. Portal Customization: Teamcenter Client is layer is written on Java JFC and eclipse SWT. The core client API are written in Java JFC framework and slowly it will ported to eclipse SWT framework. Presently Teamceter support both JFC and SWT customization, but it is recommended to do customization in SWT looking at Teamcenter future vision. The Portal Customization can be done extending OOTB Plug-in or developing your own plug-in. Apart from JFC/SWT UI api, the Teamcenter client API also provides object interface component which is an encapsulation of Teamceter Data model through Client object model. This Object Interface component also form interface layer between client and server. Web or Thin Client Customization: This customization is for Teamcenter Web client. Teamcenter provides standard web interface for viewing and editing Teamcenter object in web browser. Web client is builds on asynchronous JavaScript and XML (AJAX) to allow dynamic loading of data in the browser. The HTML pages are renders by java script on XML data. Most of the thin client customization is carried through JavaScript which allow the rendering as well managing request\response from web server. Both client-toserver requests and server-to-client responses in Teamcenter thin client are standard HTTP responses. SOA Customization: It is also called Teamcenter services. It is a standard SOA based services provided by Teamcenter for integrating with third party as well custom client. Also Teamcenter provides framework to create your own custom SOA services. I covered Teamcenter SOA services in detail in my SOA blogs. BMIDE Extension Customization: This is mainly a server customization using Teamcenter BMIDE. BMIDE provide various extension customization mechanisms for implementing desired behavior in Teamcenter. Some of example of BMIDE extension is pre-action or post-action operation for Business object, Runtime property etc. This extensions are implemented in BMIDE environment by writing C\C++ server code mainly using ITK API. BMIDE framework create stub code and other require classes for extension implementation. Developer only required implementing base logic of the extension. I will try to cover extension implementation in one of my future blog. Apart from the above customization; Teamcenter Dispatcher module can also be customized for required translation behavior. Most of time Dispatcher client required to be implemented for extracting and loading translated file from Teamcenter. The Dispatcher Client Framework is based on Teamcenter SOA service and most OOTB SOA API is used apart from Dispatcher API which encapsulates most of complex Teamcenter SOA API calls. I already covered Dispatcher Customization in my blog on Teamcenter Dispatcher. See Also : Teamcenter FMS Overview Teamcenter SOA : Introduction Teamcenter Dispatcher Framework Posted by Manoj Blog at 11:43 AM No comments: Email ThisBlogThis!Share to TwitterShare to Facebook Sunday, August 4, 2013 Teamcenter Query Builder Query Builder is one of frequent used module in Teamcenter for creating object based search query. Query Builder is power full tool for quickly configuring Teamcenter for object based search query based on attribute criteria. It is also used in report builder for creating report based on query output. I covered it in detail in my Report Builder blog. In this blog I will explain in detail about local query builder configuration and basic concept to create or modify query. Basic of Query Builder: Teamcenter Query is based on Teamcenter persistence data model which I cover in Teamcenter Data Model. Following are the basic characteristic of query in Teamcenter. 1. Query is created against any of the Teamcenter persistence class. 2. Query Criteria can be defined either on attribute of target object or for the related object which are related to search class through either GRM relation or reference. 3. Criteria can be made invisible to end user by making use entry field empty. 4. Predefined keyword variable can be used against some of the attributes. These variable values are executed at runtime. For example keyword variable $USERID will resolve to session userid when query will be executed. 5. Teamcenter also support keyword query which allow to search dataset files content, that contain a specific keyword or combinations of keywords. 6. Query can also be customized through Teamcenter use exit. 7. Query results always shows list of object of class which is defined as search class in query builder. Steps for creating Query: Below description shows list of task required to be done for defining new query in Teamcenter through Query Builder. 1. Define Query : Before creating query, you have to first define what exactly required to be search and in what context. Context means some condition or criteria which user can either provide while executing search or defined as basic criteria for search itself. For example, if you want create a query for find specific Data type only, then you defined Object Type is query builder and make the field invisible. 2. Map to Data Model : After defining search requirement , you map it to persistence data model of Teamcenter. This become your search class in Query Builder. Basically the output will be shown for instance of this class only. It is assumed the admin user who will be building the query will be aware of basic data model of Teamcenter. I covered it in the my Teamcenter Data Model blog. Once you select the Search Class, automatically its attributes and GRM relation are shown in Attribute Display area. The attributes can be filter to show only class specific attributes or all inherited attributes from all parent classes. 3. Define Search Context : Then defined search criteria or context in which search required to happen. For example if you want to get Item Revision which has attachment of specific data set only. In this case you have to traverse from search class i.e Item Revision to Dataset through predefined GRM relation shown in attribute display area or through reference by from imanrelation object to Dataset (Primary object to Secondary Object). 4. Use Search Criteria Field : At last you defined the the criteria which you want to expose to user for executing the search. This defined list of attributes shown to The attribute can be of search class or related class. . You can navigate required class from Class Selection dialog which shows Teamcenter hierarchy data model. As defined above section this will be base class for query.User whose value can be set by user before query execution. The search result will be list of instance of this 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 results will be shows all revision of the item. There is no way to filter Search Results based on specific filter rules. Following are field of Search Criteria section Boolean Rule : This connect multiple search clauses in search criteria through And\OR condition. It refers to query locale file for actual display name of attributes search dialog. Limitation of Query Builder: Although Query Builder is very powerful tool of Teamcenter for configuring object based query. it can’t be achieved through configured Query Builder search. Query builder support almost all sql operator clauses. Query can be only be configured for persistence data object. For example for date attribute you can defined greater then or less then Operator to execute query for before or after date clauses. 4. The below image shows all support operation condition in Teamcenter. For example if I want to get latest Revision of Item. That means query against two independent object which are not related through some relation or reference can’t be created. This section help to select attribute used for search Criteria Search Criteria: This defined criteria for context search as well user search criteria field. For example in SQL you can build where clause based . Query rules can’t be build for joint query or set of and /OR clauses as can be defined in SQL statement. but it also has some limitation due to Teamcenter data model design. 3. 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. UserEntry Name : Shows the display name shown in query. Query can be only build for object in the context of related object defined in Data Model. 1.Attribute Selection: This provide list of attributes of search class. AND condition required related clauses should be satisfied where as OR condition means any of them. Option provide to see only display attributes for a given class or all attributes its inherited from all parent class hierarchy. It basically define rules of attributes are evaluated against the value provided for execution. 2. 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. Teamcenter provided both configurable like naming rule. Teamcenter is no difference with it. This layer represents actual entity to Business and its process. Business Rules are the top level layer of Data Model. See Also : Teamcenter Data Model Teamcenter Report Framework Teamcenter Data Model    Data Model is core of any Packaging software. Query results only shows list of instance of search class only. Developer should know detail aspect of POM layer for customization and extension of system. 5. Teamcenter Data model can be categorized in to three distinguish layer. It is not always one to one mapping. but closest to DB Tables for most of classes. They are POM or Schema Layer Business and Relation Object Layer Business Rules POM or Persistence Object Model is lowest layer. conditions etc or custom like extension for defining business rules. Business and Relation Object Layer resides above POM layer. Business Object and Relation defines overall Data Model from Business process perspective. Mainly Business Analyst or Solution Architect interacts at this layer. You can't see related object along with search object in query results dialogs. it is important to have a good understanding of its Data Model. . In this blog. This layer basically constitutes Business Object behavior based on the rules configured in BMIDE. To have a good technical command in any package.on set of and / or clause through grouping the clauses throuch under different bracket () . Business rules along with Business Object encapsulate overall PLM business process. which basically represent mapping for underlying Data Base of Teamcenter. 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. The base object in Teamcenter is called POM_object. Same is valid for Folder. Out of which one important class is POM_application_object class. POM level object are represented as tables in Teamcenter data base.Below diagram shows the basic building block of Teamcenter Data Model. This is important class from perspective of it actually representing all Business object of Teamcenter. It is base parent object for all object defined in Teamcenter. . it means there is base level object through which all the object in the stystem are derived. Dataset or ItemRevision. POM Schema of Teamcenter Data Model: Teamcenter Data Model Schema is hirierachy based. Workspace object which represent as parents of all objects which user can see in the teamcenter is derived from POM_application_object class. For example Item class is derived from workspace object. All Business classes in Teamcenter either directly or indirectly (through hierarchy) is derived from workspace object. Under POM_object classes there many immediate child classes which are mainly used as storage classes like form storage class. Below diagram shows the class hierarchy for basic workspace object. All derived class of Teamcenter Data Model is represented as corresponded table in data base. Reference by : The Business Object underline schema classed direct has reference to other object through attributes. it will create a new table in Data base with columns having custom attribute defined in BMIDE. Business Object can be seen as actual representation of real life entity which are encapsulated as Business object. Once deploy from BMIDE. user_exit etc). Rule can be either configurable (Ex: Naming Rules) or customization (extension. Business Object: The building block of Teamcenter is Business Object. Business Objects have property which can be persistence (attributes from underlining classes) or Dynamic (evaluated run time). Teamcenter UA provides hundred of OOTB business objects. In Teamcenter Relation can be categorized in to two groups. Hence child attributes are combination of parent attributes plus child attributes. GRM Relation: Teamcenter Relation is second building block. Relation defined the inter dependent of various Business Object with each others. It resides above POM Objects or DB Classes. Business Objects are related to each other through relations. For example POM_application object has reference to owning group or user. It can be compare to pointer reference to other classes in object orient concept. Business Objects behavior can be controlled through rules which are defined in BMIDE. .1) 2) 3) a) Most of time you create custom type by extending data model of Item or form type. The underlining objects are still persistence schema classes. Following are major characteristic of Business Object. All inherited classes automatically inherit parent attributes. 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. Also different relation type object can be created to defined different Business rules. They just provide data in term of data extraction and transformation mainly done through style sheet. The custom code required to be written. Property: Properties define business objects. . a) Persistence Property: Attributes which are stored in database. Till now Report in PLM are static and so called dumb data. And with the advancement and more emphasis on Analytic and Reporting on Enterprise data. Apart from persistence property. it is going to play key role in future. Teamcenter Report Framework Report is one of the key modules in any PLM system. which executes when the property value is fetch from server. For example you can define DeepCopy Rules or GRM Rules. Teamcenter also provide tool for creating both static as well intelligent report. d) Relation: This is property which defines relation between target object and source. Advantage of using GRM relation rather than direct relation is that of having more flexibility in term of defining business rules. 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. c) Runtime Property: These are property define dynamically through custom code. Example of this can Form property shown at Item or Item Revision. 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. there are other properties which are either derived from other relation object or created run time by writing custom codes. The functionality for complex and Analytic Report is also available in Teamcenter through third party tool. In this blog we will discuss on static report which can be created in Teamcenter through in Build report module. This are defined in underline schema classes. All attributes which are present in underline POM Class for given Business Object are automatically become property of Business Object. That’s all from Teamcenter Basic Data Model Perspective. Hope this provide good starting point for people who want to understand Teamcenter Data Model. Teamcenter property can be classified in following four categories. . 3) Custom Report: Teamcenter provide custom Hook for creating Custom report which usually can’t be created through Query or XSL. Reports in Teamcenter are based on Query and PLMXML Framework. Reports Builder always create Static Report Report Builder.Reports in Teamcenter: Teamcenter provide to Report Builder Module to create report based on PLM data from Teamcenter. Report Builder Modules Component: Report Builder five major components which basically define the extraction and transformation rule for Reports. 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. 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. I already cover PLMXML in my earlier blog . PLMXML output can be controlled in same way as of creating Transfer mode for exporting/importing object from Teamcenter. A custom exe can be written which can create a report when executed by user in Teamcenter session. Reports are basically categorized in three types in Report Builder. But the limitation is that this report will be always static report and no intelligence can be provided (Filter criteria. Report Style Sheet: This defined the Layout of the report. Most of the time customization of Report will be limited to XSL creation based on Report Layout requirement. Due to above limitation Teamcenter also provide tightly integrated Teamcenter Reporting and Analytic for advance report from different data source as well for Analytics.Query: This is search query created in Query Builder module of Teamcenter. See my PLMXML blog to know more about Property Set. Property Set: This defines addition attributes required to extract apart from default property for given Object Type by PLMXML Engine. Query defined which object required to be extracted under different search criteria. . Closure Rule: This component comes from PLMXML module. You can know more about style sheet in W3C site or Wikipedia. Also there is no way to fetch data from different source and normalize with Teamcenter for Reporting. Custom Component: This is used when you want to create custom reports through some customize code. Most of the generic report can be created from Report Builder without required for any customization. This style sheet is XSL files which can convert the XML output from Teamcenter in to different compatible format with proper layout. See my PLMXML blog to know more about Closure Rule. FMS is responsible for all transaction related to files from Teamcenter server and client. 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). Report Format: This define XML format for report extracted from Teamcenter. I covered Query in detail in my Query Builder Blog. If-Else Analysis etc). We required providing path of custom executable and parameter if any required for custom executable. It defines the extraction rule for the object extracted from Query. Teamcenter two format traditional PLMXML and TcXML based on new schema available in Teamcenter Unified. The Closure rule defines what other related objects required to be extracted along with target object coming from Query. The search criteria either can be exposed to end user or it can be hidden. Teamcenter FMS Overview File Management System (FMS) is one of the Teamcenter component for managing files or vault in Teamcenter. In this blog I will discuss the basic architecture of FMS and its interaction with Teamcenter Application. The two components of FMS are FMS server cache (FSC) and FMS client Cache. FMS has two components: FSC and FCC. Hence we required to have multiple FSC running in different server to server different geography or set of user or volume server. Basically there are three types of Files FMS Master FSC FCC . The below diagram shows FMS architecture. Architecture of FMS: As discussed in FMS Overview. Teamcenter Application Tier and Client Tier interact with FMS framework through HTTP or HTTPS protocol. 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. 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.FMS Overview: FMS is independent tool which run as service in server (as FSC) and client machine (as FCC). 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. For basic installation you usually have one FSC and multiple FCC based on number of user using the Teamcenter Client. 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. Each of portal clients will have one FCC running on client machine.    FMS Configuration Configuration of FMS is managed through xml files. Every file in a Teamcenter vault has a single file GUID associated with every replicated copy of the file. In this way FCC check for modification. 3. It has two main elements fccdefault : This override FCC configuration from FSC. Apart from FSC information it may information of Volumes related to FSC. FSC sent the file to FCC which in turn route it to client request. Also it has parameter related to FSC cache for files as well cache location. . FMS request is routed to FCC installed in client site for File retrieval. The priority defines FSC request sequence if the FCC is configured with multiple FSC for given sites id. performance requirement as well overall FSC architecture. 8. Whenever there is any request of file in teamcenter by user. You can have multiple FSC defined as a backup for failover. FSC: Defined detail of installed FSC in server. FCC check if the file cached in FCC and not modified. FMS master configuration file is master configuration file resides in master FSC server. User try to retrieve file from dataset. to determine when to pull a file from its local cache. FMS Master information help FSC to route the file request in case it doesn’t resides in it volume or cache. Any change in File results in having a new GUID for the file. Otherwise it will forward it to corresponding FSC. 5. 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. file size. FMS create a FMS ticket corresponding to file retrieval from vault. application server forward the request to FMS for retrieving file from Vault. If file doesn’t resides in FCC or changes. parentfsc : This define FSC which FCC refer to for downloading FMS configuration. The other FSC site information its retrieve from FMS Master config file. The parameter vale basically decided based on load.1. 4. Modification check of file is done through concept of GUID which is associated with every file in Teamcenter. FMS master configuration file which define various FSC sites in cluster or FSC Group. 6. Communication Flow between FMS and Teamcenter : Below is the process for communication between Teamcenter and FMS. FCC configuration installed in each client. FSC configuration basically contain two main elements FMSMaster : Defines FMS master location from where FMS Master Configuration file can be read by FSC. This has various configuration parameter related to client cache and request. 2. In has different parameter which defines files transfer characteristic as well error and log information. 7. FMS ticket is sent to client end which then request to FMS with FMS Ticket. then FCC sent request to FSC associated with the site id. FSC check if files is cached in its own server and belong to its own volume. GUID is a business neutral identifier for file contents. Teamcenter Dispatcher Framework. Dispatcher Client component basically manage extract and loading of data. Module does actual translation.The below diagram depict the overall flow of FMS request. Presently I am working Translation Service of Teamcenter. 1) Scheduler 2) Module 3) Dispatcher Client There is one more component called Dispatcher Admin which is basically used for Admin activity and it is optional component. Each component can be run in different server. c) Load translated result to teamcenter. For example Doc to PDF. . Translation service is nothing but to translate one file format to other. Hope this will help to understand FMS working and configuration. As name suggests scheduler manage the whole framework by interacting between Module and Dispatcher client. a) Extract Data from Teamcenter. b) Execute Translation. Though to share my learning experience with you people. Translation service comes as a Dispatcher Service under teamcenter installation. Each of the above three component run independently and can be run as service or in console. The broader task any translation are as follows. The below diagram depict the Translation Frame work. Hence the Dispatcher Service of teamcenter has three main components. I cover all aspect of FMS overview. it processes the request and put all extracted files required to be translated in to directory called staging directory. Module translate the file and put the output in staging directory. Teamcenter required to be configuring through ETS preferences for new translation services and object type on which this service is valid. As discussed in last blog there are three components for Translator. Scheduler in turn informs Module to start processing the task.Dispatcher Client is the front end of Dispatcher Framework which basically interacts with Teamcenter through SOA for translation request. Once completed schedule ping the Dispacher client which load translated file back to Teamcenter. it inform scheduler for translation processing. Once Dispatcher client completes the extract. Module and DispatcherClient required configuring to communicate to Scheduler. Once the request is received to Dispatcher Client. Component communicate through RMI Scheduler : This component act as Moderator between Module and DispatcherClient. In staging directory a unique subfolder is created for each request by Dispatcher client based on Task ID generated during user request in Teamcenter. In this blog I will discuss in detail on each of module and how to configure COTS translation service. Staging directory is required to be configured during Dispatcher Service Installation. 1) Scheduler 2) Module 3) Dispatcher Client Each module run as independent service and in different server. . Once installed the scheduler directory structure created as shown below. Siemens PLM provide lot of out of box translation service which required to be make active. In next blog I will provide more detail about each component and there configuration. Configuring Translator In my last blog I discuss Dispatcher Framework of Teamcenter. Most of time there is no change required to be done in Scheduler once installed.bat present in bin subfolder. If you want to make this . Every translation service in Module starts with name of service as element in translator. Lib store all Jar file correspond to scheduler.properties file stored in config subdirectory which defined port and other properties for Scheduler.The transscheduler.xml look like as follow The XML show subsection of configuring one of Translation service in Module. . Module invokes specific Translation based on Task information and Translator service available to it. Based on this information Scheduler in turn dispatch specific Translation task to the Module. The scheduler can be run by runscheduler.xml. Contain of translator. As in above example Translation service JtToCatiaV5 is configured under provider SIEMENS with service name jttocatiaV5. The conf folder has translator. Once installed the Module directory structure created as shown below. Means Module will not publish this service. Module: Module is the component which does actual translation. Modules publish this service to Scheduler. The above configuration show presently the service is not active.xml which contains all Translation service details for Module. It interacts with Scheduler to get the Translation Task. tcserver port number etc. For activating COTS translation usually we don’t required to change in DispatcherClient component. But this service are by default are not activated. Its main job is to fetch data files Teamcenter and upload translated file to Teamcenter.jt and output is of type . The Options element define what argument required to be pass. Also some of the Translator service required core service to be installed.CatProduct. In above example two arguments with –i and –o with their value will pass by Module will to jttocatiav5. The config contain all file related to Translator configuration for DispatcherClient. The Module can be run by runmodule.service active then required to change the isactive value to true. DispatcherClient: This is the component which interfaces with Teamcenter.bat. In this example the input file will of .properties contain information required to connect to Teamcenter like host. d:/Siemens /DISPAT~1/Module/Translators/jttocatia/v5 location/ jttocatiav5. Lib folder contains jar files for Dispatcher Client. Once installed the DispatcherClient directory structure created as shown below.bat present in bin subfolder. For example previewservice translation can only work if visualization and vis translator is installed.bat will be invoked located at d:/Siemens /DISPAT~1/Module/Translators/jttocatia/v5 location. Following steps required to be . The Module will convert the above config while calling actual jttocatia translator as follows. The TransExecutable element define the location of Translator root directory and name of exe or bat required to call for translation.config contains information related to Translator server like rmi port of Scheduler. Where as Service. All customize Jar file for new translator service required to be copy in this folder. In above example jttocatiav5. DispatcherClient.CATPart or . Apart from this Module has transmodule. Activating COTS Translation Service: Siemens provided many Cots service with installation. Detail regarding Translator customization will be discuss in my next blog. The FileExtensions define the input and output extension expected for this Translator. staging directory etc.properties file which detail has related scheduler rmi port and staging root directory configured. Translator Teamcenter user.bat -i {Input file dir} –o {outputfiledir} The inputfile dir and outputfile dir will get at run time through DispatcherClient component through Scheduler Component. Lib store all Jar file correspond to scheduler. Where as in Dispatcher client you required to right a code for extracting or loading or both and for Module required to define calling exe or bat fill which really do translation. Dispatcher Customization:Dispatcher provide java based out of box implementation for extract from TaskPrep for extracting specific data from teamcenter. 3) Verify following preference are present in Teamcenter to enable it in Teamcenter. Customizing Translation Services In my last two blog I have given detail about Teamcenter Translation Framework and its Configuration. 3) Upload the file back to teamcenter by creating dataset and upload the file.. : Provide list of Business Object type on which this translator can be invoked as primary object.DATASETTYPES. Customization Steps:Let take a example of one of Translation Use 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. So for COTS configuration required translation service name for preference ETS.TRANSLATORS. Attach dataset with given relation to Itemrevision. Then the preference required to be set is ETS.PROVIDERS : Provide list of Translator provider. ETS. the three main components are Dispatcher Client.bat file. 2) Change the core bat file for that translator present in root service directort and provide all required variable value like tc_root. Step 1 and 3 will be part of Dispatcher Client whereas step 2 will be part of Module implementation. SIEMENS is a default value.SIEMENS.TRANSLATORS. So in case of configuring COTS translation.xml inside Module/conf folder. c. 1) Extracting file to be translated from Teamcenter.JTTOCATIAV5 with multi-value and value as JtSimplification and other dataset type which support JT files. This provide list of Translation available by provider. Steps required be performed are as follows.done to make any COTS translator active 1) Modify Translator. . In this blog I will provide about customization and creating new translator service. a. b. 2) Translating file to required language either using custom language translator or third party translator like Google Translator.ug_root etc. In all most all cases Dispatcher and Module required to customize. ETS. For any customization this component required to be customized. ETS. For example for jttocatiav5 is required to be added here.xml as discussed in my earlier configuration blog. There are other preference which are optional.xml image above. Make service active by changing isactive attribute to true.. Also required to configured translator. For example in case of jttocatiav5 it should be invoked for JT dataset type only.. For example in jttocatiaV5 translator required to provide UGS_LICENSE_SERVER in catiav5tojt. As discussed in Translator Framework. Module and Scheduler. Now the requirement is to make this relation type and dataset type to be configurable. will required to change any thing. tc_data. See Translator.SIEMENS. prepareTask() is function required to be implemented. Usually both the class required to implemented for new translation service. In our example if we required to convert text document from one language to other then the task prep with first extract Document from target Dataset and put the file in staging location. The abstract class has some member variable which encapsulates all detail of translation request as well staging directory location.teamcenter. . Implementation: Dispatcher Framework provides two main interfaces for customization the translator. Also sample implementation can found in sample folder under Dispatcher Client root directory. Implementation to prepare task to submit to Translation serverice. 1) Taskprep class for extracting the file from Teamcenter. m_PrimaryObjs = request. This auto behavior can be controlled without writing piece of code by configuring Translator.ets. It is defined as abstract for Taskprep class and required to be implemented by all extending classes.xml for the specific translation service. Once the module complete the translation the Database Operation class will be invoked and the translated file will be uploaded to Teamcenter with specified dataset type and attach to target object with relation.the dispatcher invoke DatabaseOperation implementation for the given service for upload of data to team center. Extraction Implementation : Taskprep implementation is done by extending com. Taskprep is the first called when a translation request is created and Dispatcher then find the specific task prep implementation for correspondent translation service request.TaskPrep which is an abstract implementation of extraction. Once the Translation is done by Module . The function which is called execution is prepareTask(). The entire class document related to Dispatcher Client can be found under docs folder inside Dispatcher Client root directory. Some of key member are request: The request object for the current extract session stagingLoc : The staging location in which all the files will be place.getProperty("primaryObjects"). Pseudo implementation: Usually in implementation we access the target object called primary object and its associate object called secondary object through current request object. 2) DatabaseOperation class for loading the translated files to Teamcenter.extract.getModelObjectArrayValue(). Following are pseudo code for same.Also it provides OOTB Data Loader for loading of output file automatically. which is referred by Module for translation. The translation request detail is created as xml file which resides in staging director under unique task id. Once we get the primary object then the Name reference file required to be extracted from dataset and put in staging location. For example in Language translator usecase we would required to have option where user can provide from which language to which language a translation is required.For example in Language Translator we would required to change the character set to specific value based on translated Language selected by user.ModelObject are SOA base wrapper class for all Teamcenter objects .getFileToStaging(zIFile.getProperty("secondaryObjects"). This is done through SOA call to teamcenter.get_ref_list(). This can be retrieve and further process in Taskprep.put(argumentKey. argumentValue). For example in case of language translation we decided to that text file can be target object (Primary object) and the Item Revision to which is associated will be then secondary object. translationArgsMap.length. Also Taskprep can create its own argument based on process which can be used by module or database loader for further processing. primaryobject are object in teamcenter which selected for Translation and secondary object are those object which are associated with target through relation. This is done by having Translator Argument while creating translation request by user.m_InputFile = TranslationRequest. The sample will look like this .Also required to create a Translation request detail. ModelObject contexts[] = dataset. j < contexts. for(int j = 0. Sample code snippet Dataset dataset = (Dataset) m_PrimaryObjs[i].m_SecondaryObjs = request. The snippets for accessing the argument are as follows.This Map contains an Argument as key and its value as value.getModelObjectArrayValue(). Map translationArgsMap = TranslationRequest. } zIFile = (ImanFile)contexts[j]. stagingLoc). j++) { if(!(contexts[j] instanceof ImanFile)) { continue.getTranslationArgs(request). ImanFile zIFile = null. The map can be access through Option transOption = transOpts. Load() function required to be implemented for a translation service.equals("SomeoptionName")) strOutputType = transOption. Uploading of all result file is done through SOA call to Teamcenter. User and Taskprep option can be access through TranslationTask which is a member of DatabaseOperation.DatabaseOperation abstract class.getValue() . If requirement can’t be fulfilled through helper class then SOA can directly be called for .getOption(i). TranslatorOptions provide encapsulation of all option with Key and Value pair.getMapperResults(zDbMapInfo. if(transOption. The DatabaseOperation class has Translationdata transData attribute which encapsulate all translated request data.getTranslationDBMapInfo(). item and item rev. This is used by module for translating.getName(). The pseudo code for same will TranslatorOptions transOpts = transTask. From translation data we can get all information we populate during extraction (taskprep).ets. Also it has detail of corresponding dataset. ScResultFileType is expected file type for translation. Dispatcher Framework provides various helper class which encapsulate the SOA call to Teamcenter. For example from Transdata you can get result file list from translation. This help for loader to load all file in teamcenter.getTranslatorOptions(). List zResultFileList = TranslationTaskUtil. Where TranslationTaskUtil is utility class provide various generic facility.load.teamcenter. scResultFileType). For example above the option provide from and to language. This can be populated but not always required as in above example we also population uid of primary and secondary object which can be used for loading the translated file to with specific relation to an object. The pseudo code for same will TranslationDBMapInfo zDbMapInfo = transData. Loader Implementation: Database loader is implemented by extending com.Basically this xml contain user argument which required for Translation. The pseudo code for same will be zat dtsethelper.DatabaseOperation class name Service provider is the name of service provided.TSUGNXService. for example OOT translation service it is Siemens.TaskPrep class name Translator. Module Customization: Module customization usually has following steps.the same.Load= packagename.LanguageTransTaskPrep class name Translator.Prepare=packagename.property under DispatcherClient\config folder required to be update with the property file name import TSBasicService. . This is sample property file. 1) Create Translation programs or indentify third party application which is used for translation. Translation Servicename is the name of Translation service which configure in Module config and in Teamcenter preference ETS.TSProjectTransServic e. Jar File Packaging and Dispatcher configuration: We required to create a Jar file for the custom dispatcher code. One of function is which create new dataset for all result file list and attach it to primary or secondary target with a given relation.TRANSLATORS.Load= packagename.”serviceprovide”.”translation servicename”.createInsertDataset((ItemRevision)secondaryObj. 0ne of helper class is DatasetHelper class which provides all functions related to dataset. “resultdir”. (Dataset)primaryObj. ExampleTranslation examplelanguagetranslation.PROVIDERS. “releationtype”.LanguageTransDatabaseOperation class name Once the JAR package is created it required to put is DispatcherClient\lib folder. “namereferencetype”. 2) Usually we create a wrapper of bat file to run the Program. Also in JAR file should have a property file which defines implemented Taskpreperation and Database loader class initiated through reflection mechanism in dispatcher framework. Translator.Prepare=packagename. This is not required but .TSProEService. “filelist”. It is configure as preference called ETS. ExampleTranslation. ourpropertyfilename This will load all classed when DispatcherClient is started. In case of Language translation usecase service provider name can exampletranslation and service name can be examplelanguagetranslation.”translation servicename”. flag to insert to source dataset or itemrevision).examplelanguagetranslation. The content for property for this will be Translator. Also service.”serviceprovide”.TSCatiaService. “datasettype” . Probably we also required to create bat file for setting a JAVA_Home and other env variable.xml is as follow Where ModuleRoot is a key word belong to module base directory. Let take our example usecase of Language Translator. service name and various options supported by translation service. Hope it might be helpful for people who want to quick start on translation service. This will provide the flexibility to reuse the handler for other translation service. The above config when read by module framework will convert to call $ModuleRoot/Translators/examplelanguagetranslation/examplelanguagetranslation. This is from my side on Teamcenter Translation framework. Handler can implemented in such a way that it can take a argument of Translation Provider. Teamcenter SOA : Introduction Service Oriented Architecture (SOA) framework is offered by many enterprise product vendor due to its advantage of interoperability as well reusability. There are some Java API which invoke remote google translator. bat –input=”absolute file location” –outputdir=”outputdir” “from_lang value” “to_lang value” Also a workflow action handlercan be created to integrate a Language Translation with Change Management and other business process. ITK api required to be used is DISPATCHER_create_request. language from which it will be translate and to language which required to translated.most of the time we required to set some environment like Teamcenter root or Tc data. This bat will also take this four parameter required for our program. Teamcenter also offer SOA framework for customization as well for integration with other . Also due to service based framework based on buisness use case maje SOA API are easy to use as it hide all complexity to Application Developer. Any comments are welcome. We will required to create a Java wrapper on top of this API to create our Teamcenter Translator. Our sample config required to be added inTranslator. outputfile with location. Our Program will take input file . We are going to use third party translator for example Google Translator for it.xml under Module\conf regarding the service. 3) Add the service detail in Translator. 2) Creating your own SOA which can consume by others. SOA server architecture resides above Business Object layer (AOM layer). Teamcenter UA SOA : Teamcenter provide SOA framework as well set of out of box SOA service for direct consumption. Corba and auto generated stub in the server as well Data Model to support client application. Development can be done in any of above language either using OOTB SOA service for Application Development or developing your own SOA for other developer usage. It provides all the list of Service available for given Teamcenter environment. .Application. We will discuss in detail about Data Type and Operation in future blogs. Teamcenter SOA can be basically used in two ways. Also you can get all detail of Data Type and Operation corresponding to SOA services in the BMIDE as shown in below image. The list of SOA service can be seen in BMIDE under extension -> Code Generation->Services. 1) Using OOTB SOA service as SOA client. In series of Blog's I will provide detail concept of Teamcenter SOA framework and creating your own SOA based on Tc SOA Framework. Teamcenter SOA Framework: Teamcenter SOA service Framework provide set of connection protocol like HTTP. C++ and Java. Teamcenter SOA support following language presently C#. SOA server code can call ITK API to perform business logic as shown in below diagram. The libraries are present inside soa_client for respective supported programming language Java. . Apart from core Framework API teamcenter also provide set of SOA service for all modules like Workflow. 2) Using published SOA service. The API libraries are present in soa_client. Query. This ZIP required to be extracted preferably in TC_ROOT folder for linking Application code which usage SOA service. Error Logging. Exception handling etc. establish connection through SOA and use OOTB SOA services. For implementing SOA client required following steps. Teamcenter SOA : Using OOTB SOA Services In last blog I have given introduction to Teamcenter SOA service. In this blog I will provide detail of using OOTB SOA services provided by Teamcenter.> Services. 1) Implementing Login Credential and session Class encapsulation connection. Change Management. Object Model Change framework etc. Structure Manager etc.zip file on the Teamcenter software distribution image.We will see in my next blog how to use SOA API .zip also contain some sample SAO code in all supported language. The detail of all API and SOA service can be found in BMIDE in Extension view under Code Generation . soa_client. C++ and C#. Teamcenter provide set of core SOA Framework class for login . Process of using SOA Client: Teamcenter provide SOA framework for creating SOA session and using publish SOA services. 3) Optionally using other Framework services like Object Model Changes.Teamcenter SOA is set of API or programming interface used for application developer. For using SOA service first thing is to connect to Teamcenter Server with two tier (iiop connection) or four tier (web URL).C++ or Java.connection class and only required credential management through implementing the CredentialManager interface. . Teamcenter SOA framework encapsulates most of connection implementation through com. I provided the detail of setup step for sample code in this blog.soa. Or workflow service instance can be obtain through WorkflowService wfser = WorkflowService.client.teamcenter. The SOA client can implement either in . Each of this service has its own static service class which provide handle to those specific services. Detail of all services and its operation detail can be seen in BMIDE as shown in below images.getService(connectionObj).I suggest going through the sample program provided in SAO_client. public class AppCredentialManager implements CredentialManager Calling SAO services: Teamcenter provide set of OOTB SOA service for different modules like work flow etc. Similarly there are other several services for different functionality. connectionObj is the connection instance which we created above. First step is to get the connection instance for SOA which is done by creating connection instance url is connection string for two tier or four tier server connection. For example Query service handle can be get by SavedQueryService queryService = SavedQueryService.getService( connectionObj).zip. credentialManagerInstance is a instance of class which implemented CredentialManager interface.NET. Quick Example of using SOA service: Let look small code snippet of using OTTB SOA service in Java. The detail of all operations functionality and its argument Data Type is describe in BMIDE.The above image show the SavedQuery and available operation for it. . Once we get instance on query service we can invoke all available SOA operation on it. These below code release the object using operation from TcWorkflow SOA service. Temcenter SOA : Sample SOA Code Setup In this blog I will provide detail step for setting up sample SOA code provided in install image file under SOA zip file. . Then we prepare input argument by creating release options object. 3) Call the specific Operation for achieving the required results. In above example we get first WorkFlow service instance. 2) Prepare input argument Data for requesting for specific services. Hence in SOA implementation we have to first create instance of object and then encapsulate them in Array. 1) Get Instance of required SOA service by providing connection object. I hope the above blog will help you to understand basic aspect of using OOTB SOA services. Note the most of Argument for SOA API takes as array value and return are also in array.The above code release given object by calling Teamcenter SOA service. This are basic step for doing any SOA service call. Below steps is for Java SOA sample code. release input object and populating them with appropriate value. The reason for this is that Teamcenter SOA is design is such a way that it takes bulk request (in an array) in single operation for avoiding multiple calls to server from client. Add the variable 'TEAMCENTER_SERVICES_HOME'.1. then browse to .zip from install image to TC_ROOT directory. It will create soa_client folder under TC_ROOT. Open the Preferences dialog of eclipes (Window --> Preferences . Execute the client application Open the Debug/Run dialog ( Run --> Debug .../soa_client/java/sample. Add ClassPath variable for the root location of the soa_client folder. Compile the project If the IDE is not configured to Build Automatically. FMS_HOME need to be added just like TEAMCENTER_SERVICES_HOME 5. .6 and launch 3.While importing FileManagement sample. 2.. Import the project Open the Import dialog ( File --> Import.. select Finish Note:. Install Eclipse 3.. ).) Select the HelloTeamcenter Java Application The launch is configured to connect to the server on http://localhost:7001/tc to change this URI on the Args tab. Select the ClassPath Variable tab ( Java --> Build Path --> ClassPath Variables).. force a build of the project 6. set it to the root path of the 'soa_client' folder 4. ) Select Existing Project into Workspace (General --> Existing Projects into Workspace ) Click Next. Unzip soa_client... Refer my OOTB SOA Service Blog for basic understanding of sample code. Go through the files to understand how the services are being called and can be used in the custom solution. ensure its pointing out to the right URI and this can be checked through Run->Debug Configurations-> Arguments If it the connection is through iiop.Only Java and C++ bindings work in 2-tier mode. In this blog we will discuss about basic for creating your own SOA. .If the connection is http. Teamcenter SOA : Create You Own SOA In my last two blog I discussed about basic fundamental of SOA and how to use OOTB SOA in client side. Usually new SOA service is required to be created when you don’t find OOTB SOA satisfying your requirement or what to have the service behavior in different way. it should be set as follows -Dhost=iiop:localhost:1572/TcServer1 Note:. 7. Following are the guideline for creating your own SOA. For example for Java you can select loose or strong binding. 3) Analyze what service you want to implement. Creating SOA services: As you understand the basic building block of creating SOA. Meanings of this Data Types are same as in a programming language like C or Java. Loose vs. Map or Enumeration. In SOA you can define data type either of Structure. Loose binding mean Key/Value pair mapping as string map of data and its value. we are ready for creating your own SOA service in the BMIDE. Operations: Operation defines set of function which will available to client for created a request for services to be performed. Structure defines set of basic data types encapsulated in structure.1) Check whether you can achieve the required result at client side by using OOTB SOA. This will help in defining input data type. Data Type: Data Type defined encapsulation of Data while creating a request for SOA service as well getting output from SOA service. 2) Analyze the desire state of transaction between Client and SOA server layer. Before You Start: Before start you should understand some aspect of SOA service in teamcenter. This will also help in deciding whether you required having loose or strong binding. Whereas strong binding means the client data model is populated with typed objects that correspond one-to-one with their server-side object type. . The SOA service can be either defined through single operation if it is a simple service or set of Operation if it is a complex use case. 5) Analyze what output will be provided for requested service and how the output will be used. 2) Create new SOA service library or use existing if you already have one. Similarly Map is data container. The detail of steps of creating SOA service is given in this blog. Hence decision required to be taken based on use case. For example if SOA service is for creating some static reports then loose Binding can be good option and for integration strong binding is good option. Following are the steps of creating SOA service 1) Define preference binding. 4) Analyze what input to perform the service. Strong Binding: The binding define how the data map between SOA server and Client. Whether it will be single request base or multiple requests which satisfy the use case. For example you have to look whether transaction should be committed in one request or multiple request provide by OOTB SOA is acceptable. Jar file created for the client (if it is Java Binding) and dll for server. The Operation will have input data type and return data types. Server side implementation is always in C++ and ITK API can be used for implementation. The stubs for all Operation is already created by BMIDE and only required to implement the business logic for the Operation. The detail steps is given in Steps for creating SOA. 10) Deploy the server dll in TC_ROOT\bin directory. 5) Defined all the Operations with define data type. 7) Implement the server side code for all defined operation in BMIDE. Only addition will be to add the client SOA jar file in the Class path for using Java client and client dll if using c++ binding. 8) No implementation is required at client side.3) Create new service under SOA service library. 9) Build the BMIDE project. . The process is same as defined for OOTB service in the Blog. 4) Define all the data type which will be used for SOA Operation. 11) Implement custom SOA service in client side. 6) Generate code in BMIDE by selecting Generate Code -> Service Artifacts. This will create stub code for both server and client side (see step blog for detail). Data Type can be either defined data type or OOTB data types. I thanks my friend Bhaskar for introducing me to Teamcenter SOA Framework. The SOA service provides all the query present in Teamcenter Query Builder. Teamcenter SOA : Detail Steps for SOA Creation This blog provides detail steps of creating your own SOA. Create a new service library in BMIDE Extensions tab by selecting Project->Code Generation->Services . it return list of Query Objects encapsulated in custom Data Structure. Hope this blogs will help good foundation for all people who want to learn Teamcenter SOA services and serve as quick start on for using and creating own services. The Operation doesn't take any input argument. The SOA has one Operation which gat all query object in Teamcenter. Detail Steps : 1.These close my series on Teamcenter SOA. 2. Define the DataTypes and Operations as per the requirement. Ex: Operation is to get all the saved queries. Open the new service (Ex: ServiceTest) 2. Select the newly created service library (Ex: D4SoaTest) and create new service 2. Define Data Types as below Define data type TestQueryObject . Click on Add button in the Data Types tab b.a. Select Structure and click Next c. Select DataType elements by clicking Add button query->Teamcenter::ImanQuery [holds the query tag] queryname->std::string [holds the name of the query] querydescription->std::string [holds the description of the query] . Enter name as TestObjectQuery and description for it d. Select Structure and click Next c. Select DataType elements by clicking Add button queries->Vector of TestQueryObject services->Teamcenter::Soa::Server::ServiceData . name and description a. Click on Add button in the Data Types tab b. Enter name as TestGetSavedQueriesResponse and description for it d.Define data type TestGetSavedQueriesResponse – Used for as return data type in operation which returns vector of query objects holding query tag. Enter Service Operation Description: SOA Operation for getting Query List a. Click on Browse button of New Service Operation dialog a. Select D4::Soa::Test::_2012_02::TestService::TestGetSavedQueriesRe sponse as the return data type a.5. Create Operation using the above defined data type. Click Add on to create new operation. . Enter Service Operation Name: testGetSavedQueries a. Select Operations tab of the service (Ex Test Service). Enter Return Description: List of Query Object in Teamcenter a. a. Click on Finish 5. Once the Operation is created. 6.a. Save the datamodel. 6. in Operation Tab when Service is opened. . Select GenerateCode>Service Artifacts 9.This contains the auto generated files for the client (no changes required to these files) Project->output->server->LibraryName . Check the Console view to know if the code generation is successful or errors in other case. Select the library created (D4SoaTest). (no changes required to these files) . Source and header files corresponding to each service are created.6.This contains the auto generated files for the server(no changes required to these files) Project->output->types->LibraryName .This contains the auto generated files for the data types that are created. 9. They are placed in the following path in Navigator view: Project->src->server->LibraryName Ex: AccentureTest->src->server->D4SoaTest (This folder contains the files which need to be implemented by the developer) Project->output->client->LibraryName . Inferences: a. Operations in the service by name TestService: ii. Services in the library D4SoaTest: TestService c. Name of the service library: D4SoaTest b. i. testGetSavedQueries . 11. Operation ‘testGetSavedQueries’ is high . Shown below is the file generated in the step #8. Open the source file and enter the required code. Project\output\server\lib (libraries which would be copied to Teamcenter Server TC_ROOT\bin) a. Project\output\client\jars (Project\output\types \lib if its c++ bindings) – jars files to added to java client classpath a. 12. Dlls are generated in a.lightened for a quick notice. Build the project. Project\output\types\jars (Project\output\types\lib if its c+ +bindings) contains the types definition – jars files to added to java client classpath Note:- . dll under types\lib and server\lib are same. libD4soatypes. Deploy the data model. . Ensure the dependant libraries are added to the library definition. 13. This will deploy the library.a. service and operation definitions in the template to the database as well as it copies the built server libraries to TC_ROOT\bin. c. Check console to see a successful build message b. Ex Project\output\server\lib to TC_ROOT\bin You can now call your SOA at client site in a same way as you called sample SOA. Ex: query module is used in the D4SoaTest library and hence added to the D4SoaTest library definition.