Introduction to Teamcenter Customization

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

Customization Architecture

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

•  Server or Enterprise Layer
• Web Layer
• Client Layer

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

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

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

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

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

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

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

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

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

See Also :

Teamcenter FMS Overview

Teamcenter SOA : Introduction

Teamcenter Dispatcher Framework

Teamcenter Query Builder

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

Basic of Query Builder:

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

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

Steps for creating Query:

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

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

Query Builder Dialog Section

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

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

 

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

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

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

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

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

Limitation of Query Builder:

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

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

See Also :

Teamcenter Data Model

Teamcenter Report Framework

 

 

 

Teamcenter FMS Overview

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

FMS Overview:

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

Architecture of FMS:

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

FMS Configuration

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

·         FMS Master

·         FSC

·         FCC

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

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

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

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

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

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

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

Communication Flow between FMS and Teamcenter :

Below is the process for communication between Teamcenter and FMS.

1.       User try to retrieve file from dataset.

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

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

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

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

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

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

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

The below diagram depict the overall flow of  FMS request.

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

Teamcenter POM Query

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

Introduction 

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

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

So there are three main constituent of any sql query.

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

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

Following are basic characteristic of POM Query.

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

Steps for building POM Query

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

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

Create Query
Unique identification for query

POM_enquiry_create (“get_itemid”)

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

Select attributes

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

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

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

Build Expression

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

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

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

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

Int  : POM_enquiry_set_int_value

Double : POM_enquiry_set_double_value

Char : POM_enquiry_set_string_value

String : POM_enquiry_set_string_value

Logical POM_enquiry_set_logical_value

Date : POM_enquiry_set_date_value

Tag : POM_enquiry_set_tag_value

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

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

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

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

Expression Binding

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

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

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

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

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

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

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

POM_enquiry_set_where_expr(“get_itemid”, "ExprId3")

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

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

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

Where row, col and report are output. 

rows : number of results.

cols : Number of column for each result

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

The above binding can be better understand by below diagram.

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

if(rows > 0 )

      {

            int reportrow = 0 ;

            tag_t *objs = Null Tag

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

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

            {

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

                 

            }

           

      }

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

Delete Query

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

POM_enquiry_delete ( “get_itemid” )

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

Teamcenter Data Model

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

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

·         POM or Schema Layer

·         Business and Relation Object Layer

·         Business Rules

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

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

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

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

 

POM Schema of Teamcenter Data Model:

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

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

 

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

Business Object:

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

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

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

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

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

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

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

Property:

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

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

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

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

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

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

Teamcenter SOA : Detail Steps for SOA Creation

This blog provides detail steps of creating your own SOA. The SOA service provides all the query  present in Teamcenter Query Builder. The SOA has one Operation which gat all query object in Teamcenter. The Operation doesn't take any input argument, it return list of Query Objects encapsulated in custom Data Structure.

Detail Steps :

1. Create a new service library in BMIDE Extensions tab by selecting Project->Code Generation->Services

2. Select the newly created service library (Ex: D4SoaTest) and create new service
3. Open the new service (Ex: ServiceTest)
4. Define the DataTypes and Operations as per the requirement. Ex: Operation is to get all the saved queries. Define Data Types as below

Define data type TestQueryObject

1. Click on Add button in the Data Types tab
2. Select Structure and click Next
3. Enter name as TestObjectQuery and description for it
4. 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]

Define data type TestGetSavedQueriesResponse – Used for as return data type in operation which returns vector of query objects holding query tag, name and description

1. Click on Add button in the Data Types tab
2. Select Structure and click Next
3. Enter name as TestGetSavedQueriesResponse and description for it
4. Select DataType elements by clicking Add button

queries->Vector of TestQueryObject

services->Teamcenter::Soa::Server::ServiceData

5. Create Operation using the above defined data type. Select Operations tab of the service (Ex Test Service). Click Add on to create new operation.
1. Click on Browse button of New Service Operation dialog
2. Select D4::Soa::Test::_2012_02::TestService::TestGetSavedQueriesResponse as the return data type
3. Enter Service Operation Name: testGetSavedQueries
4. Enter Service Operation Description: SOA Operation for getting Query List
5. Enter Return Description: List of Query Object in Teamcenter
6. Click on Finish

5. 1. 

6. Once the Operation is created, in Operation Tab when Service is opened.
7. Save the datamodel.
8. Select the library created (D4SoaTest). Select  GenerateCode->Service Artifacts

9. Check the Console view to know if the code generation is successful or errors in other case.
10. Source and header files corresponding to each service are created. 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  - This contains the auto generated files for the client (no changes required to these files)

Project->output->server->LibraryName  - 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. (no changes required to these files)

Inferences:

1. Name of the service library:    D4SoaTest
2. Services in the library D4SoaTest:

1. TestService

3. Operations in the service by name TestService:

2. testGetSavedQueries

11. Open the source file and enter the required code. Shown below is the file generated in the step #8. Operation ‘testGetSavedQueries’ is high lightened for a quick notice.

12. Build the project. Dlls are generated in
1. Project\output\client\jars  (Project\output\types \lib if its c++ bindings) – jars files to added to java client classpath
2. Project\output\server\lib (libraries which would be copied to Teamcenter Server TC_ROOT\bin)
3. 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:-

1. Check console to see a successful build message
2. libD4soatypes.dll under types\lib and server\lib are same.
3. Ensure the dependant libraries are added to the library definition. Ex: query module is used in the D4SoaTest library and hence added to the D4SoaTest library definition.

13. Deploy the data model.  This will deploy the library, service and operation definitions in the template to the database as well as it copies the built server libraries to TC_ROOT\bin. 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. 

See Also :

Teamcenter SOA : Introduction
Teamcenter SOA : Using OOTB SOA Services

Temcenter SOA : Sample SOA Code Setup
Teamcenter SOA : Create You Own SOA