Getting Started With Customization PDF
Getting Started With Customization PDF
Publication Number
PLM00003 I
Proprietary and restricted rights notice
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
Figures
1 Overview of customization
1 Overview of customization
• Teamcenter behavior
You can change Teamcenter behavior by integrating external applications using
the Integration Toolkit (ITK) or Teamcenter Services.
For more information about ITK, see the Server Customization Programmer’s
Guide and the Integration Toolkit Function Reference. For more information
about Teamcenter Services, see the Services Guide and the Services Reference.
Note The Integration Toolkit Function Reference and the Services Reference
are not available in PDF format. They are available only in the
Teamcenter HTML Help Collection.
• Data model
You can create data model that defines the objects and rules used in Teamcenter.
(Although this is more in the realm of configuration than customization, it can
have as great an impact on the appearance and behavior of Teamcenter as
customization methods can.)
For more information, see the Business Modeler IDE Guide.
to make behaviors more usable or to provide better integrity. Our policy is to notify
customers at the time of the release prior to the one that contains a published
interface behavior change.
As Teamcenter evolves and advances, leveraging newly available technologies,
Teamcenter will make the ability to extend and tailor Teamcenter as flexible and
simple as possible. The direction is to fully leverage the developing Eclipse paradigm
to consolidate the thin client and rich client frameworks. A single client framework
allows extending both the thin client and rich client with a single extension. Note
that this consolidation will change the current extension model for the thin client
in the future.
Siemens PLM Software does not support code extensions that use unpublished and
undocumented APIs or extension points. All APIs and other extension points are
unpublished unless documented in the official set of technical manuals and help files
issued by Siemens PLM Software Technical Communications.
The Teamcenter license agreements prohibit reverse engineering, including:
decompiling Teamcenter object code or bytecode to derive any form of the original
source code; the inspection of header files; and the examination of configuration
files, database tables, or other artifacts of implementation. Siemens PLM Software
does not support code extensions made using source code created from such reverse
engineering.
If you have a comment or would like to request additional extensibility, contact
the Siemens PLM Software customer support representatives at GTAC for further
assistance.
Bold Bold text represents words and symbols you must type exactly as
shown.
In the preceding example, you type harvester_jt.pl exactly as
shown.
Italic Italic text represents values that you supply.
In the preceding example, you supply values for bookmark-file-name
and directory-name.
text-text A hyphen separates two words that describe a single value.
In the preceding example, bookmark-file-name is a single value.
[] Brackets represent optional elements.
... An ellipsis indicates that you can repeat the preceding element.
Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
What is the registry? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
User properties files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Supported types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Registry keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Four-tier architecture
Teamcenter is constructed in tiers. The lowest tiers are closest to the database
and file volumes and the highest tiers are closest to the user. These layers run on
top of, and add functionality to, existing host facilities instead of replacing host
facilities. For example, Teamcenter interfaces to the host electronic mail facilities,
but also provides a higher level of messaging to overcome certain limitations of
the host facilities.
The Teamcenter architecture consists of the following tiers:
• Client tier
The client tier comprises the Teamcenter clients: the thin client and rich client.
For more information, see the Client Customization Programmer’s Guide.
• Web tier
The Web tier is a Java application that runs in a Java 2 Enterprise
Edition (J2EE) application server, such as WebLogic, and is responsible for
communication between the client tier and enterprise tier.
• Enterprise tier
The enterprise tier comprises a configurable pool of Teamcenter C++ server
processes and a server manager. The enterprise tier retrieves data from and
stores data in the database. A server manager manages a pool of Teamcenter
server processes. This is the tier where you use ITK programming to customize
Teamcenter on the server side.
• Resource tier
The resource tier comprises a database server, database, volumes, and file
servers with a file management system.
o Teamcenter File Management System (FMS) downloads and uploads file
data for the rich client, Teamcenter lifecycle visualization, and the thin client
configured with Teamcenter lifecycle visualization. It provides a file storage,
caching, distribution, and access system. Multi-Site Collaboration also uses
FMS servers to transfer data.
o For more information about supported databases, see the following Web site:
http://support.industrysoftware.automation.siemens.com/
certification/teamcenter.shtml
o Interactively
o Import/export
o Programmatically
Four-tier architecture
certification/teamcenter.shtml
The POM allows applications to interface to the system module at a higher level
of data abstraction than RDBMS relational tables. For example, an application
may request the POM to create a folder in Teamcenter. The POM interprets this
command and generates the necessary SQL statement to create the relational data.
• Client layer
The client layer consists of software tools used to interact with the user. This
layer is written in Java, making use of the JFC and SWT classes. The UIF layer,
along with the object interface components, form the Teamcenter client.
• Server layer
The server consists of the following layers:
o Application layer
The application layer consists of modules that allow the client to view and
perform work on Teamcenter data. These consist of Teamcenter modules,
such as My Teamcenter, Structure Manager, EPM, Find, and Teamcenter
system administration. The applications, application objects, object interface
adapter, and POM layer form the Teamcenter server.
Request overview
o AJAX model
The thin client interface uses Asynchronous JavaScript and XML (AJAX) to
allow dynamic loading of data in the browser. For example, this technology is
used to expand additional levels in an existing tree without refreshing the
rest of the tree.
The following figure illustrates the AJAX model.
AJAX model
o Architecture
The differences between serving complete HTML pages or XML fragments
are transparent to the server. It does not matter to the server whether it is
serving them to an old page-based browser client, or a dynamic JavaScript
client, or any other kind of client. This is part of the flexibility enabled by
the use of standard Web technology.
o Statelessness
The tcserver process is logically stateless—successive requests are entirely
self-contained and do not rely on the state of the server from previous
requests. All persistent states are saved back to the database and the
stateful process objects are unloaded at the end of each transaction. This
has several benefits:
Scalability
The pool manager can cull the least-used processes incurring only the
overhead of a future logon. There is no need to maintain a persistent
session since no state is held in the server.
Resilience
Experience shows that the Teamcenter core is not failure-proof, but when
it does crash, the pool manager can start another session transparently
to the user once the user reloads to resend the request.
Error handling
On error, rollback works correctly as there is no potentially corruptible
state.
o Flexibility
The tcserver process is designed to be as simple and flexible as possible.
The rich client and thin client share the same HTTP-based architecture
stack, TcScript interpreter, and client interaction pattern. With the XML
API, the Teamcenter Web server is a general lightweight Teamcenter server
providing a simple XML interface. The API is directed at the Web, so it
may be inappropriate for other specific tasks, but you can easily extend the
API by implementing new page templates to execute any ITK-accessible
Teamcenter function. Customization is simple because of the separation of
the custom user interface from the standard data delivery by the XML API.
Application interfaces
There are two application interfaces you can use to integrate external applications
with Teamcenter:
• Teamcenter Services
Teamcenter Services allow different applications to communicate with one
another using services. Teamcenter Services use service-oriented architecture
(SOA), which is appropriate for integrating separate applications with a loose
linkage and network-friendly APIs that do not need to be modified with every
Teamcenter version. This is the preferred method of integrating third-party
and client applications. Future releases will extend this interface and provide
tools so you can easily extend it.
For more information about Teamcenter Services, see the Services Guide and
the Services Reference.
Note The Services Reference is available only in the Teamcenter HTML Help
Collection. It is not available in the PDF collection.
Siemens PLM Software recommends that you use Teamcenter Services. If you
need functionality not exposed using Teamcenter Services, write new, high-level
service methods using ITK and expose them as Teamcenter Services interfaces
using the Teamcenter Services toolkit.
For more information about ITK, see the Server Customization Programmer’s
Guide and the Integration Toolkit Function Reference.
Note The Integration Toolkit Function Reference is not available in PDF
format. It is available only in the Teamcenter HTML Help Collection.
• C++ programming
You can write C++ code to perform server-side customizations using the Business
Modeler IDE.
For more information, see the Business Modeler IDE Guide and the Server
Customization Programmer’s Guide.
• Teamcenter Services
Teamcenter Services use a service-oriented architecture (SOA) as one means to
provide customers with the ability to quickly and easily develop task-specific
clients, utilities, and system integrations using the power of the Teamcenter
server. The Teamcenter Services operations are accessed through coarse-grained
interfaces that minimize the amount of network traffic needed to accomplish any
specific task. As such, Teamcenter is ideal for applications that were previously
impractical because of slow network speeds or limited network bandwidth.
Teamcenter Services ship with libraries and interfaces to build applications
in Java, C++, and .Net, giving you the flexibility to choose the technology
that best fits with your particular environment and standards. Teamcenter
Services also ship with WS-I compliant WSDL files for all operations, giving you
further flexibility and the confidence that comes with supporting open industry
standards.
For more information about Teamcenter Services, see the Services Guide.
• Dispatcher
Use Dispatcher for data translation including the triggering of translations,
extraction of data from Teamcenter for translator input, translation of the data
in the Dispatcher Server (Dispatcher Server), storage of the Dispatcher Server
translation results in Teamcenter, and management of the translation request.
For more information about Dispatcher, see Getting Started with Dispatcher
(Translation Management).
http://java.sun.com/
Note CLASSPATH is an environment variable used for the ordered lookup
of Java class files, icons, and property files. In previous versions of
Teamcenter, you could use the CLASSPATH environment variable to
override icons, property files, and class files. However, Teamcenter now
uses Eclipse as its integrated development environment (IDE) and does
not support the CLASSPATH variable. You must use Eclipse extensions
and extension points instead.
For more information, see the Client Customization Programmer’s Guide.
Item
In Teamcenter, items are the fundamental objects used to manage information.
Items provide an identification for physical or conceptual entities about which an
organization maintains information and audit/change control. Typical uses of items
are parts, documents, and equipment. In an engineering/product development
environment, parts are identified as items. An item has the following basic
information:
• ID
A unique identifier for an item.
• Name
A user-defined name to describe the item.
• Item type
A classification of items that allow different kinds of items to be treated
separately. For example, an item can be used to manage parts and documents. If
you implement two item types, you can enforce rules based on the type of items
that are being manipulated.
Note The system, as delivered, provides a generic business object called Item
along with several child business objects which all act as different item
types. If you need additional kinds of items, the system administrator
can create children of the Item business object at your site.
• Description
A text field of up to 240 characters used to describe the item.
Item revision
Item revisions are used to reflect modifications to an item. The original item revision
is retained for historical purposes.
Note Each customer site defines its own procedures to determine how and when a
new item revision should be created.
• Revision
A unique identifier for an item revision.
• Name
A user-defined name to describe the item revision.
Relations
Organizations produce several documents that describe, are used by, or in some
way relate to an item. For the data to be understood, it has to be associated in a
meaningful way to the item or item revision. Teamcenter associates data to items
and item revisions using relations.
Relations describe how the data is associated to an item and item revision. A dataset
containing the CAD model, which defines an item revision, is a specification of the
item revision. Similarly, a standards document describing the fit, form, and function
of a particular drawing is a requirement for the item.
An item or item revision can be related to several other objects, including datasets,
forms, folders, and other items and item revisions. Each object associated to the item
represents various aspects of that item. A dataset containing stress test information
could be added by the engineer, while a form containing size and weight information
could be added by the specification engineer.
Teamcenter provides a basic set of relations. The relations between the object and
the item and item revision determines the rules enforced.
Note Additional relations and their associated rules are defined by your system
administrator.
• IMAN_master_form
The master form relation associates a form to an item or item revision. This
form is a collection of attributes that describe the item or item revision. Rules
for this relation are as follows:
o An item or item revision must have write access to add or remove a master
form relation to a form.
o Only a form can have a master form relation to an item or item revision.
o An item can have only one master form. An item revision can have only
one master form.
o A form can have a master form relation to only one item or item revision.
• IMAN_requirement
The requirement relation associates data to an item or item revision, such as
standards, which must be adhered to in a drawing, or technical requirements for
a part. Rules for this relation are as follows:
• IMAN_manifestation
The manifestation relation associates other related data to an item or item
revision. This data may, however, be necessary for information, such as analysis
of the competing ideas from which a part was originally conceived. The
manifestation relation also associates data to the item revision that contains
data derived from the specification data (such as tool paths). Rules for this
relation are as follows:
o An item or item revision does not need to have write access to add or remove
a manifestation relation to an object. A manifestation relation can be added
or removed from a released item or item revision.
• IMAN_specification
The specification relation associates data which defines the item revision.
Examples are CAD models for parts or word processor files for documents. Rules
for this relation are as follows:
• IMAN_reference
The reference relation associates any data to an item or item revision. Rules
for this relation are as follows:
o An item or item revision does not need to have write access to add or remove
a reference relation to an object. A reference relation can be added or
removed from a released item or item revision.
• IMAN_revision
The revision relation associates item revisions to the appropriate item. Rules
for this relation are as follows:
o An item must have write access to add or remove an item revision from
the item.
• BOMView
The BOMView relation associates a product structure to an item. Rules for this
relation are as follows:
• BOMView Revision
The BOMView Revision relation associates a product structure revision to an
item revision. Rules for this relation are as follows:
Another method is to modify the contents of an object that is currently related to the
item and item revision.
Business objects are used to specialize the behavior of Teamcenter objects. Datasets
implement the most extensive use of business objects. The Dataset business object
is used to categorize datasets.
Examples of dataset business objects are a document, an NX part, and a spreadsheet.
When a document Dataset business object is opened, the word processor application
associated to this Dataset business object is opened. When an NX part Dataset
business object is opened, the NX application associated to this Dataset business
object is opened. For each Dataset business object, the available operations (for
example print and open) are defined, as well as the specific behavior of each
operation.
Item business objects extend the ability to specialize the behavior of items. You
may need to distinguish between a part used in production and equipment used to
produce that part. Both may need to be an item, yet the information and business
rules surrounding these items are different.
Dataset model
A dataset contains a series of dataset objects, which reference the ImanFile objects
that hold the data, and a RevisionAnchor object, which holds the list of dataset
versions and the dataset ID, if one exists. A dataset may also reference Form
objects. The following figure from the UML (Unified Modeling Language) editor in
the Business Modeler IDE shows the RevisionAnchor object that creates a new
logical dataset.
Dataset model
Dataset IDs are optional, but they must be unique. The unique ID enforcement in
datasets is performed at the application level. Each time the New®Dataset menu
command is used to create a dataset, the Save As and Import commands are used,
or the dataset is edited using the Properties command, the validation function is
called to ensure the dataset ID (id) and revision (rev) combination is unique within
that specified dataset business object.
Also, for each dataset business object, if the dataset ID is created using the Assign
button, a separate counter generates the next unique ID that is available for a
standalone dataset. This counter ensures id and rev are unique within the same
dataset business object.
When you create a dataset, two revisions are created: revision 0 and revision 1.
Revision 0 always points to the latest revision, so it initially points to revision 1. If
you create revision 2, then revision 0 points to that, and so on. In your programming,
if you want to point to the latest revision, point to revision 0.
ITK functions use this convention with revisions as follows:
• AE_ask_dataset
Given any dataset, returns revision 0.
• AE_ask_dataset_first_rev
Given any dataset, returns the oldest revision.
• AE_ask_dataset_latest_rev
Given any dataset, returns the most recent revision (not the revision 0 copy).
• AE_ask_dataset_next_rev
Given any dataset, returns the next revision in the sequence.
• AE_ask_dataset_prev_rev
Given any dataset, returns the previous revision in the sequence.
• AOM_save (dataset)
Creates a new, later version of the dataset and saves a copy to revision 0.
• AOM_delete
For the given dataset, deletes all revisions and the associated revision anchor.
All revisions of a dataset have the same owning user and group and the same
protection; updating any of those on any one revisions updates all other revisions.
For more information about these functions, see the Integration Toolkit Function
Reference.
Note The Integration Toolkit Function Reference is not available in PDF format. It
is available only in the Teamcenter HTML Help Collection.
Form model
Forms provide the ability to store customer defined attributes. Teamcenter provides
standard forms. Most of the forms used at a customer site, however, are modified to
capture the information unique to its business.
Forms are stored as POM objects. Attributes in the forms can be set and retrieved
using Form ITK functions and the POM query ITK functions. When a form is
stored, the database schema must be updated to recognize the new POM object.
The following figure shows a diagram of the form model using the UML (Unified
Modeling Language) editor in the Business Modeler IDE.
Form model
access rights in Teamcenter. The following figure shows a diagram of the access
control model.
If you start from scratch, you can develop an integrated application that does not
require a shell.
The Dataset class is the workspace object that an end user sees in their workspace.
The shell or integrated application associates one or more other pieces of data to the
dataset. More often than not, this means associating files for existing applications.
Some applications require several files in order to run. When this is the case, a
named reference can be created for each file. The name of the reference is often the
extension of the file but does not have to be. A CAD system may have a file in which
it stores geometric data with a .gmd extension, finite element modeling data in a file
with a .fem extension, and drawing data in a file with a .drw extension.
For such a CAD system, you could find references named geometry, fem, and
drawing, or gmd/fem/drw as the shell chooses. If you use the extensions, users do
not have to change the reference names during import, since by default the import
assumes the reference names correspond to the file extensions.
The model shows that the named reference can refer to an ImanFile object or other
descendant class of the POM object. This means a shell can be implemented that
does not use the ImanFile object to store file data, but instead uses its own file
object to store such information. However, you should do this rarely since there is a
loss of integrity that is provided by the ImanFile object. However, the flexibility it
provides may be necessary in some cases.
The RevisionAnchor object is provided to support versioning of datasets. Whenever
a dataset is created, a RevisionAnchor object is also created. This object maintains
a list of working revisions of the dataset. However, it is up to the shell/integrated
tool to use this facility. To use it, you must make revision copies and then make
changes to these copies.
Class hierarchy
The information in this section describes the hierarchy of classes (taxonomy).
Understanding this hierarchy, or returning to it, helps with understanding the rest
of the Teamcenter model description, which shows relationships and gives a more
detailed description of individual classes.
Class objects have a meaningful hierarchy that relates to the Teamcenter layered
software architecture previously discussed. It is presented in an indented outline
form.
The following legend defines the mnemonic descriptions shown in parentheses in
the figure.
Mnemonic Class
AE Application Encapsulation
AOM Application Object Module
BOM Bill Of Materials
CR Cascade Release
EPM Enterprise Process Modeling
FL Folder Manager
FORM Forms
Mnemonic Class
IMF ImanFile
ITEM Item
MAIL Teamcenter Mail
POM Persistent Object Manager
PS Product Structure
SA System Administration
UOM Unit of Measure
VM Teamcenter Volumes
WSOM Workspace Object
The following figure shows the more common classes in the hierarchy. For more
information about other classes, see the Business Modeler IDE Guide.
Class hierarchy
Object-oriented data
What is an object?
An object is a data structure. It is basically the same as an entity or an instance of a
class. A class defines a type of object, its attributes, and methods that operate on it.
For example, folder is a class in Teamcenter. It is defined to have a name, a
description, and a list of entries. These are the attributes of the folder class. When
a folder is instantiated, an actual folder object is created. It has attributes as
described here. There are also methods or functions defined for the folder class, such
as Insert and Remove.
Attributes in Teamcenter can be integer, float, boolean, string, date, tag, or arrays
of any of these types. A tag is a unique identifier of a reference (typed, untyped, or
external) or a relation (typed or untyped).
The attributes in Teamcenter can have some of following characteristics:
• Unique
There can be no duplicate values of the attribute in all of the instances of the
class.
• Protected
The attribute can only be modified by the application that created the object.
• NULL allowed
If this characteristic is not true, then the object cannot be saved until the
attribute is set.
• Upper bound
The highest value that the attribute can have.
• Lower bound
The lowest value that the attribute can have.
• Default value
The attribute may have an initial value.
Inheritance
A subclass inherits both attributes and methods from superclasses.
Multiple inheritance means that a class has two superclasses. That is, it inherits
the attributes and methods from two different classes. There are no instances of
multiple inheritance in Teamcenter.
A superclass may be a generalization of many similar classes. For example, the
WorkspaceObject superclass is a generalization for all of the classes whose
instances may be seen in the workspace (for example, in a folder). All of the
attributes and methods that are common to the Dataset, Folder, and other classes
are defined once in the WorkspaceObject superclass, rather than being defined
many times. Usually, generalizations are abstract or noninstantiable. This means
that the class exists for conceptual or convenience reasons, but you cannot actually
create an instance of one.
A subclass may be a specialization of another class. For example, the Envelope
subclass is a specialization of the Folder class. In this case, a new class is being
defined that is like another one except for some additional attributes and/or some
specialized behavior such as a specialized method.
Object-oriented language
An object-oriented language is a programming language that has built in key
words or constructs that either force or facilitate object oriented programming.
For example, C++ is one, because it supports classes, objects, inheritance, and
polymorphism. The C language is not.
However, you can do object-oriented programming with a nonobject-oriented
language; it is just harder. You can certainly have an object model with inheritance
of attributes and methods without using an object oriented language. This is what is
presented through ITK.
Internally, much of Teamcenter is written in C++. This provides an easy way of
handling polymorphism. You can take advantage of this in the ITK as well. If you
want to execute a method on an object, you do not need to call a function specific
to that action-class pair. You may call any function with that action up the tree of
superclasses for the selected object. For example, if you want to ask the name of an
envelope, you do not need to call the EMAIL_ask_envelope_name function (in fact,
that function does not exist). You can call the WSOM_ask_name function two levels
up in the hierarchy instead. That function realizes that it was actually passed an
envelope and invokes the envelope’s method to get the name.
• Inheritance
The ability to inherit class definitions and make modifications that specialize
the class, thus creating a new class.
• Polymorphism
Giving an action one name that is shared up and down an object hierarchy,
with each object in the hierarchy implementing the action in a way appropriate
to itself.
Registry
What is the registry?
The registry plays a vital role in the Teamcenter rich client. The registry uses
the properties files to define classes, icons, internationalized text, inheritance,
search order, and appearance. Our registry is fundamentally a subclass of
the ResourceBundle object found in Java and uses the properties files to
store replaceable information that can be tailored based on need. Many basic
customization tasks can be accomplished using the registry.
Note This registry is not the Windows registry.
The key contained within the registry is contained within the product code, but
the value can be modified. Every key/value pair that appears within the registry
falls into one of the following categories: appearance, structural, instantiation, or
localization.
• Appearance
Keys that define colors, fonts, and sizes.
• Structural
Keys that are defined (usually at the top) and are called import statements.
Importing allows the nesting of property files for searching. This allows you to
define a key in one place within the rich client that can be reused without being
duplicated. For instance, the OK button text must be localized in the rich client
user interface based on the current locale. Therefore, the text for OK is placed
within the aif_locale.properties file.
• Instantiation
Keys used to construct Java objects. Teamcenter rich client makes use of
reflection and dynamic instantiation within the Java language to construct
objects by their string name rather than hard-coding them within the source
code.
For example, each command that appears in the menu bars and toolbars is
dynamically constructed and run. You can subclass a command and replace it
with your own by replacing an entry within a properties file to tell the rich client
to use your command rather than the base command.
• Localization
Keys allow localization of text and messages to be flexibly obtained based on the
current locale of the OS where rich client is running. Teamcenter rich client is
delivered with locales that support English, German, French, Spanish, Italian,
Czech, Russian, Korean, Japanese, and Chinese. Each of these separate property
files is based on the convention that JavaSoft has established. Localization keys
are those for which the ResourceBundle class was first designed.
In any given package (directory) that uses registries, there are three property
files: base, locale, and user. These properties files contain structural,
instantiation, and appearance keys.
o Base properties file
Contains nonlocale-specific information and is the only property required
in a package.
Supported types
Primitive types are supported in the registry as well. The following types are
supported: color, font, integer, float, double, char, boolean, string, string array, and
images. Some of the types use special formats, as follows:
• Color
• Font
font-name, font-style, font-size
“Times Roman, Font.ITALIC, 12”
• String array
one,two,three
Registry keys
If a key must contain a blank or space, the space follows the backslash (\) character.
If the name of the type contains a space, such as that found in the Adobe Acrobat
type, the entry would be:
Adobe\ Acrobat=images/acrobat.gif
Java treats a space like an equal sign (=). Therefore, if the entry is:
Adobe Acrobat=images/acrobat.gif
Change menus
You can remove or add menus in Teamcenter:
• Remove menus
Removing menus is known as command suppression. Use the Command
Suppression application to remove menus from the user interface. You can also
use business object display rules to hide objects from menus.
For more information, see the Application Administration Guide, the Client
Customization Programmer’s Guide, and the Business Modeler IDE Guide.
• Add menus
You can add menus to the user interface using different methods. For example,
you can use Eclipse to add a menu to the rich client or edit XML files to add a
menu to the thin client.
For more information, see the Client Customization Programmer’s Guide.
4. Use the Fnd0Icon business object constant to specify the primary icon to
represent the business object.
• Thin client
Change the icons in the staging_location\webapp_root\typeicons directory.
For more instructions, see the Client Customization Programmer’s Guide.
• Use JavaBeans
Do this by launching Eclipse and creating a new JPanel component. Then add
Property bean components to the new JPanel.
6. Compile the user_part_no.c file and link it to the user exits library (the
libuser_exits.lib file) in the TC_ROOT\lib directory.
For more details about compiling and linking files, see the Server Customization
Programmer’s Guide.
• Extensions customization
Allows you to write a custom function or method for Teamcenter in C or C++ and
attach the rules to predefined hook points in Teamcenter.
A Glossary
A Glossary
architecture
Set of decisions, patterns, and principles for a product suite. The architecture
provides a framework for application development within that product suite and is
independent of specific functions.
class
Set of objects that share the same list of attributes but distinguishable by the value
the attributes acquire for specific objects. For example, the Automobile class can be
defined by the brand, color, and price, but each car associated to the Automobile
class has a different brand, color, and price combination.
class hierarchy
Structure defining subclasses that inherit the attributes of their superclasses, also
called their parents or ancestors.
client
Role played by a software component of a system when it requests particular services
be performed on its behalf by another entity, a server. See also server.
client tier
Teamcenter architectural tier that comprises the Teamcenter clients, Teamcenter
integrations with third-party applications, and the third-party applications
associated with the integrations.
closure rule
Definition or rule that allows the Teamcenter traversal algorithm to identify the
additional objects required for a specific principal object.
dataset
Teamcenter workspace object used to manage data files created by other software
applications. Each dataset can manage multiple operating system files, and each
dataset references a dataset tool object and a dataset business object.
extension
Method or listener implemented for an extension point.
extension point
Event or capability in the system, such as a precondition, preaction, or postaction,
that allow you to implement custom behavior.
extension rule
Business rule that adds predefined behavior to a business object’s operation and fires
as a precondition, preaction, or postaction.
form
Teamcenter workspace object used to display product information (properties) in a
predefined template. Forms are often used to create an electronic facsimile of a
hardcopy form in Teamcenter. See also master form.
four-tier architecture
Teamcenter architecture that includes four tiers: resource tier, client tier, Web tier,
and enterprise tier. Contrast with two-tier architecture.
GRM rule
See Generic Relationship Management rule.
LOV
See List of Values (LOV).
master form
Teamcenter workspace object used to display product information (properties) in
a predefined template. Master forms are used to display product information in
a standardized format.
PLM XML
Siemens PLM Software format for facilitating product life cycle interoperability
using XML. PLM XML is open and based on standard W3C XML schemas.
Representing a variety of product data both explicitly and via references, PLM
XML provides a lightweight, extensible, and flexible mechanism for transporting
high-content product data over the Internet.
POM
See persistent object manager (POM).
properties file
File containing the attributes (keys and values) that specify how an application is to
behave in the Teamcenter rich client.
registry file
Properties (.properties) file that contains the user-defined configuration settings
(keys and values) that are relative to how the application displays and performs
in the Teamcenter rich client. Each application registered in the rich client has a
.properties file known as a registry file.
rich client
Java-based user interface to Teamcenter installed on user workstations. The rich
client accesses Teamcenter databases using a remote or local server. Compare to
thin client.
server
System software component that performs a specifically defined set of software
services on behalf of one or more clients. In a typical Teamcenter installation,
servers are centralized on dedicated hosts that support a large number of clients.
Clients are distributed on hosts connected to the servers via various networking
techniques. See also client.
thin client
Teamcenter user interface that provides a streamlined browser-based view of product
information stored in a Teamcenter database. The thin client is configured in the
Web tier, which creates and serves its Web pages to the client. Compare to rich client.
two-tier architecture
Teamcenter architecture that includes a resource tier and a client tier. The resource
tier comprises the database server and database. The client tier comprises the
Teamcenter rich client, third-party applications that integrate with the rich client,
and a local server. This architecture supports only the Teamcenter rich client.
Contrast with four-tier architecture.
A H
Access control object model . . . . . . . . . 2-21 Hierarchy of classes . . . . . . . . . . . . . . 2-23
API, see HTTP requests . . . . . . . . . . . . . . . . . . . 2-4
Appearance keys . . . . . . . . . . . . . . . . . 2-28
Application encapsulation object I
model . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Application Programming Interface . . . . 2-9 Icons . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Architecture . . . . . . . . . . . . . . . . . . . . . 2-1 Inheritance . . . . . . . . . . . . . . . . . . . . . 2-27
Audience . . . . . . . . . . . . . . . . . . . . . . . 1-1 Instantiation keys . . . . . . . . . . . . . . . . 2-28
Integration Toolkit . . . . . . . . . 2-7–2-8, 3-2
B Item
Business object . . . . . . . . . . . . . . . . 2-17
Base properties files . . . . . . . . . . . . . . 2-29 Model . . . . . . . . . . . . . . . . . . . . . . . 2-11
BOM view . . . . . . . . . . . . . . . . . . . . . 2-16 Modifying . . . . . . . . . . . . . . . . . . . . 2-16
Objects . . . . . . . . . . . . . . . . . . . . . . 2-12
C Revisions . . . . . . . . . . . . . . . . . . . . 2-13
ITK, see Integration Toolkit
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
C++ code . . . . . . . . . . . . . . . . . . . . . . . 3-3 J
Class hierarchy . . . . . . . . . . . . . . . . . . 2-23
CLASSPATH environment variable . . . 2-10 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Color format . . . . . . . . . . . . . . . . . . . . 2-29 API . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
common_user.properties file . . . . . . . . . . 3-1 Components . . . . . . . . . . . . . . . . . . . 2-9
Compatibility . . . . . . . . . . . . . . . . . . . . 1-1 Foundation classes . . . . . . . . . . . . . . 2-10
Conventions, syntax definitions . . . . . . . 1-2 Overview . . . . . . . . . . . . . . . . . . . . . . 2-9
Programming language . . . . . . . . . . 2-10
D
L
Dataset object model . . . . . . . . . . . . . . 2-17
Dispatcher . . . . . . . . . . . . . . . . . . . . . . 2-9 License agreement . . . . . . . . . . . . . . . . 1-1
Locale properties files . . . . . . . . . . . . . 2-29
E Localization keys . . . . . . . . . . . . . . . . 2-29
Encapsulation . . . . . . . . . . . . . . . . . . . 2-27 M
F Manifestation . . . . . . . . . . . . . . . . . . . 2-14
Master form . . . . . . . . . . . . . . . . . . . . 2-14
Files Menus . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
common_user.properties . . . . . . . . . . . 3-1 Modifying an item/item revision . . . . . . 2-16
Properties . . . . . . . . . . . . . . . . . . . . 2-29
Font format . . . . . . . . . . . . . . . . . . . . 2-30 O
Form object model . . . . . . . . . . . . . . . . 2-19
Forms . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Object model . . . . . . . . . . . . . . . . . . . . 2-10
Four-tier architecture . . . . . . . . . . . . . . 2-1 Access control . . . . . . . . . . . . . . . . . 2-21