Још

Saturday, August 17, 2013

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

1 од 14
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

Posted by Manoj Tiwari at 11:43 AM 30 comments:

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.

2 од 14
 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.

3 од 14
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

Posted by Manoj Tiwari at 5:45 AM 15 comments:

Saturday, June 29, 2013

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 transac on
related to files from Teamcenter server and client. In this blog I will discuss the basic architecture of FMS and its interac on with Teamcenter
Applica on.

FMS Overview:

FMS is independent tool which run as service in server (as FSC) and client machine (as FCC). Teamcenter Applica on 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 mul ple user request where as FMS client cache work in client machine
where it serve request for single user and also interact with FSC for ge ng latest or new files from server.

Architecture of FMS:

As discussed in FMS Overview, FMS has two components: FSC and FCC. For basic installa on you usually have one FSC and mul ple FCC based on
number of user using the Teamcenter Client. Each of portal clients will have one FCC running on client machine. But in produc on Environment where
user can be in mul ple geographical loca on 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 mul ple FSC
running in different server to server different geography or set of user or volume server. This mul ple FSC server are distributed in such a way that they
can be near to each of geographical loca on. Due to mul ple FSC server architect we then required to define one FSC server as master for managing
request and rou ng to different FSC server. The below diagram shows FMS architecture.

4 од 14
FMS Configura on

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

· FMS Master
· FSC
· FCC

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

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

FMSMaster : Defines FMS master loca on from where FMS Master Configura on file can be read by FSC. FMS Master informa on 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 characteris c as well error and log
informa on. Also it has parameter related to FSC cache for files as well cache loca on. The parameter vale basically decided based on load, file
size, performance requirement as well overall FSC architecture.

FCC configura on installed in each client. It has two main elements

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

paren sc : This define FSC which FCC refer to for downloading FMS configura on. You can have mul ple FSC defined as a backup for failover.

Communica on Flow between FMS and Teamcenter :

Below is the process for communica on between Teamcenter and FMS.

1. User try to retrieve file from dataset.

2. Whenever there is any request of file in teamcenter by user, applica on server forward the request to FMS for retrieving file from Vault.
3. FMS create a FMS cket corresponding to file retrieval from vault. FMS cket 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. Modifica on check of file is done through concept of GUID which is associated with
every file in Teamcenter. GUID is a business neutral iden fier 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 modifica on.
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 mul ple 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 informa on 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.

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

Posted by Unknown at 7:35 AM 23 comments:

Saturday, May 18, 2013

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

6 од 14
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.

7 од 14
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.

Posted by Manoj Tiwari at 9:03 AM 11 comments:

Sunday, April 14, 2013

Teamcenter Data Model

Data Model is core of any Packaging so ware. 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 be er understanding of Teamcenter system.

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

· POM or Schema Layer

· Business and Rela on 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 customiza on and extension of system.

Business and Rela on Object Layer resides above POM layer. This layer represents actual en ty to Business and its process. Mainly Business Analyst or
Solu on Architect interacts at this layer. Business Object and Rela on defines overall Data Model from Business process perspec ve.

Business Rules are the top level layer of Data Model. This layer basically cons tutes 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,
condi ons 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_applica on_object class. This is important class from perspec ve of it actually represen ng 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_applica on_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.

8 од 14
Most of me 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 a ribute defined in BMIDE. All inherited classes automa cally inherit parent a ributes. Hence child a ributes are
combina on of parent a ributes plus child a ributes.

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 representa on
of real life en ty which are encapsulated as Business object. The underlining objects are s ll persistence schema classes. Teamcenter UA provides
hundred of OOTB business objects. Following are major characteris c of Business Object.

1) Business Objects are related to each other through rela ons.

2) Business Objects have property which can be persistence (a ributes from underlining classes) or Dynamic (evaluated run me).
3) Business Objects behavior can be controlled through rules which are defined in BMIDE. Rule can be either configurable (Ex: Naming Rules) or
customiza on (extension, user_exit etc).

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

a) Reference by : The Business Object underline schema classed direct has reference to other object through a ributes. It can be compare to
pointer reference to other classes in object orient concept. For example POM_applica on object has reference to owning group or user.
b) GRM Rela on : Other way rela on between is created by crea ng a rela on object which encapsulate both Business object through concept
of primary and secondary object. Advantage of using GRM rela on rather than direct rela on is that of having more flexibility in term of
defining business rules. For example you can define DeepCopy Rules or GRM Rules. Also different rela on type object can be created to
defined different Business rules.

Property:

Proper es define business objects. All a ributes which are present in underline POM Class for given Business Object are automa cally become
property of Business Object. Apart from persistence property, there are other proper es which are either derived from other rela on object or created
run me by wri ng custom codes. Teamcenter property can be classified in following four categories.

a) Persistence Property: A ributes 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 rela on. Example of this can Form property shown at Item or Item Revision.
c) Run me Property: These are property define dynamically through custom code. The custom code required to be wri en, which executes
when the property value is fetch from server.
d) Rela on: This is property which defines rela on between target object and source.

That’s all from Teamcenter Basic Data Model Perspec ve. Hope this provide good star ng point for people who want to understand Teamcenter
Data Model.

Posted by Manoj Tiwari at 4:36 AM 62 comments:

Saturday, February 9, 2013

Teamcenter SOA : Detail Steps for SOA Creation

9 од 14
This blog provides detail steps of crea ng your own SOA. The SOA service provides all the query present in Teamcenter Query
Builder. The SOA has one Opera on which gat all query object in Teamcenter. The Opera on 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 selec ng Project->Code Genera on->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 Opera ons as per the requirement. Ex: Opera on is to get all the saved queries. Define Data Types
as below
Define data type TestQueryObject

a. Click on Add bu on in the Data Types tab

b. Select Structure and click Next
c. Enter name as TestObjectQuery and descrip on for it
d. Select DataType elements by clicking Add bu on
query->Teamcenter::ImanQuery [holds the query tag]
queryname->std::string [holds the name of the query]
querydescrip on->std::string [holds the descrip on of the query]

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

a. Click on Add bu on in the Data Types tab

b. Select Structure and click Next

10 од 14
 c. Enter name as TestGetSavedQueriesResponse and descrip on for it
d. Select DataType elements by clicking Add bu on
queries->Vector of TestQueryObject
services->Teamcenter::Soa::Server::ServiceData

5. Create Opera on using the above defined data type. Select Opera ons tab of the service (Ex Test Service). Click Add on to
create new opera on.
a. Click on Browse bu on of New Service Opera on dialog
b. Select D4::Soa::Test::_2012_02::TestService::TestGetSavedQueriesResponse as the return data type
c. Enter Service Opera on Name: testGetSavedQueries
d. Enter Service Opera on Descrip on: SOA Opera on for ge ng Query List
e. Enter Return Descrip on: List of Query Object in Teamcenter
f. Click on Finish

5.

6. Once the Opera on is created, in Opera on Tab when Service is opened.

7. Save the datamodel.
8. Select the library created (D4SoaTest). Select GenerateCode->Service Ar facts

11 од 14
 9. Check the Console view to know if the code genera on 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:

a. Name of the service library: D4SoaTest

b. Services in the library D4SoaTest:

i. TestService

c. Opera ons in the service by name TestService:

ii. testGetSavedQueries

12 од 14
11. Open the source file and enter the required code. Shown below is the file generated in the step #8. Opera on
‘testGetSavedQueries’ is high lightened for a quick no ce.

12. Build the project. Dlls are generated in

a. Project\output\client\jars (Project\output\types \lib if its c++ bindings) – jars files to added to java client classpath
b. Project\output\server\lib (libraries which would be copied to Teamcenter Server TC_ROOT\bin)
c. Project\output\types\jars (Project\output\types\lib if its c++bindings) contains the types defini on – jars files to added
to java client classpath
Note:-

a. Check console to see a successful build message

b. libD4soatypes.dll under types\lib and server\lib are same.
c. Ensure the dependant libraries are added to the library defini on. Ex: query module is used in the D4SoaTest library and hence
added to the D4SoaTest library defini on.

13 од 14
 13. Deploy the data model. This will deploy the library, service and opera on defini ons 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

Posted by Manoj Tiwari at 10:29 AM 9 comments:

Newer Posts Home Older Posts

Subscribe to: Posts (Atom)

Simple theme. Powered by Blogger.

14 од 14