Saturday, August 17, 2013

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.

Server Customization

Portal Customization

Web or Thin client customization

SOA based customization

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.

Sunday, August 4, 2013

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.

Query is created against any of the Teamcenter persistence
class.

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.

Criteria can be made invisible to end user by making
use entry field empty.

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.

Teamcenter also support keyword query which
allow to search dataset files content, that contain a specific keyword or
combinations of keywords.

Query can also be customized through Teamcenter use exit.

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.

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.

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 TeamcenterData 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.

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 totraverse from search class i.e Item Revisionto Dataset through predefined GRM relation
shown in attribute display area or through reference by from imanrelation
object toDataset (Primary object to
Secondary Object).

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.

Query can be only be configured for persistence
data object.

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.

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.

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 ()
.

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.