Getting Started with Customization - Help!help.aviacons.ru/.../pdf/getting_started_with_customization.pdf · PLM00003I Getting Started with Customization 2-1. Chapter2 Basic customization

Teamcenter 10.1

Getting Started with Customization

Publication NumberPLM00003 I

Proprietary and restricted rights notice

This software and related documentation are proprietary to Siemens ProductLifecycle Management Software Inc.

© 2013 Siemens Product Lifecycle Management Software Inc. All Rights Reserved.

Siemens and the Siemens logo are registered trademarks of Siemens AG. Teamcenteris a trademark or registered trademark of Siemens Product Lifecycle ManagementSoftware Inc. or its subsidiaries in the United States and in other countries. Allother trademarks, registered trademarks, or service marks belong to their respectiveholders.

2 Getting Started with Customization PLM00003 I

Contents

Proprietary and restricted rights notice . . . . . . . . . . . . . . . . . . . . . . . . . 2

Overview of customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

What you can customize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Siemens PLM Software customization support . . . . . . . . . . . . . . . . . . . . . . . 1-1Syntax conventions used in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Basic customization concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Four-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Rich client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Thin client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Application interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Customization applications and toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Teamcenter object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

Common customization tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Change page layout with style sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Change menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Customize a business object icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Develop a form for the rich client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Customize Teamcenter behavior with a user exit . . . . . . . . . . . . . . . . . . . . . . 3-2Create codeful customizations with the Business Modeler IDE . . . . . . . . . . . . 3-3

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1

Figures

Four-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Request overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5AJAX model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Class object diagram legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11Item/item revision model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Dataset model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Form model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20System administration model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22Class hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25

PLM00003 I Getting Started with Customization 3

Chapter

1 Overview of customization

What you can customize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Siemens PLM Software customization support . . . . . . . . . . . . . . . . . . . . . . . 1-1

Syntax conventions used in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

PLM00003 I Getting Started with Customization

Chapter

1 Overview of customization

What you can customizeUse this manual as a general guide to customizing Teamcenter from Siemens PLMSoftware. It provides you with an overview of the various tools and methods you canuse to change Teamcenter to meet your needs.

Note This manual is for those who want to customize Teamcenter. Typically,programmers, system administrators, and development managers use thismanual as a starting point for their customizations.

You can customize just about anything in Teamcenter, including:

• User interface appearance

You can customize the appearance of both the rich client and thin client.

For more information, see the Client Customization Programmer’s Guide.

• Teamcenter behavior

You can change Teamcenter behavior by integrating external applications usingthe Integration Toolkit (ITK) or Teamcenter Services.

For more information about ITK, see the Server Customization Programmer’sGuide and the Integration Toolkit Function Reference. For more informationabout Teamcenter Services, see the Services Guide and the Services Reference.

Note The Integration Toolkit Function Reference and the Services Referenceare not available in PDF format. They are available only in theTeamcenter 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 canhave as great an impact on the appearance and behavior of Teamcenter ascustomization methods can.)

For more information, see the Business Modeler IDE Guide.

Siemens PLM Software customization supportSiemens PLM Software is committed to maintaining compatibility betweenTeamcenter product releases. If you customize functions and methods usingpublished APIs and documented extension points, be assured that the nextsuccessive release will honor these interfaces. On occasion, it may become necessary

PLM00003 I Getting Started with Customization 1-1

Chapter 1 Overview of customization

to make behaviors more usable or to provide better integrity. Our policy is to notifycustomers at the time of the release prior to the one that contains a publishedinterface behavior change.

As Teamcenter evolves and advances, leveraging newly available technologies,Teamcenter will make the ability to extend and tailor Teamcenter as flexible andsimple as possible. The direction is to fully leverage the developing Eclipse paradigmto consolidate the thin client and rich client frameworks. A single client frameworkallows extending both the thin client and rich client with a single extension. Notethat this consolidation will change the current extension model for the thin clientin the future.

Siemens PLM Software does not support code extensions that use unpublished andundocumented APIs or extension points. All APIs and other extension points areunpublished unless documented in the official set of technical manuals and help filesissued 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 originalsource code; the inspection of header files; and the examination of configurationfiles, database tables, or other artifacts of implementation. Siemens PLM Softwaredoes not support code extensions made using source code created from such reverseengineering.

If you have a comment or would like to request additional extensibility, contactthe Siemens PLM Software customer support representatives at GTAC for furtherassistance.

Syntax conventions used in this guideThis guide uses a set of conventions to define the syntax of Teamcenter commands,functions, and properties. Following is a sample syntax format:

harvester_jt.pl [bookmark-file-name bookmark-file-name ...][directory-name directory-name ...]

The conventions are:

Bold Bold text represents words and symbols you must type exactly asshown.

In the preceding example, you type harvester_jt.pl exactly asshown.

Italic Italic text represents values that you supply.

In the preceding example, you supply values for bookmark-file-nameand 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.

1-2 Getting Started with Customization PLM00003 I

Overview of customization

Following are examples of correct syntax for the harvester_jt.pl: command:

harvester_jt.plharvester_jt.pl assembly123.bkmharvester_jt.pl assembly123.bkm assembly124.bkm assembly125.bkmharvester_jt.pl AssemblyBookmarks


Chapter

2 Basic customization concepts

Four-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Rich client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Thin client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Application interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Customization applications and toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Teamcenter object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Legend for object diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Item and item revision model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Sample item and item revision model . . . . . . . . . . . . . . . . . . . . . . . . 2-11Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Item revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13Modifying an item/item revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16Item business object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Dataset model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Form model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19System administration model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Product structure object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Application encapsulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22Class hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23Mapping business objects and classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Object-oriented data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26

What is an object? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27Object-oriented language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27

Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28What is the registry? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28User properties files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29Supported types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29Registry keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30


Chapter

2 Basic customization concepts

Four-tier architectureTeamcenter is constructed in tiers. The lowest tiers are closest to the databaseand file volumes and the highest tiers are closest to the user. These layers run ontop of, and add functionality to, existing host facilities instead of replacing hostfacilities. For example, Teamcenter interfaces to the host electronic mail facilities,but also provides a higher level of messaging to overcome certain limitations ofthe 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.


• Web tier

The Web tier is a Java application that runs in a Java 2 EnterpriseEdition (J2EE) application server, such as WebLogic, and is responsible forcommunication between the client tier and enterprise tier.

• Enterprise tier

The enterprise tier comprises a configurable pool of Teamcenter C++ serverprocesses and a server manager. The enterprise tier retrieves data from andstores data in the database. A server manager manages a pool of Teamcenterserver processes. This is the tier where you use ITK programming to customizeTeamcenter on the server side.

• Resource tier

The resource tier comprises a database server, database, volumes, and fileservers with a file management system.

o Teamcenter File Management System (FMS) downloads and uploads filedata for the rich client, Teamcenter lifecycle visualization, and the thin clientconfigured with Teamcenter lifecycle visualization. It provides a file storage,caching, distribution, and access system. Multi-Site Collaboration also usesFMS 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

There are three ways to read, edit, or create data in Teamcenter:


Chapter 2 Basic customization concepts

o Interactively

o Import/export

o Programmatically

Interactive access is accomplished through the forms and menus or throughthe interactive dialogues of applications integrated within Teamcenter.Import/export involves taking the data out of Teamcenter, accessing the data byany means at your disposal and later, putting data back into the Teamcentersystem. ITK also provides programmatic access.

You accomplish file access through the FMS ITK interface. You can use the filemanagement functions in this module to interface into the operating systemI/O utilities.

The information in the database is stored in tables in a relational databaseand is accessed using SQL. Only the POM should ever read from, or write datadirectly to, Teamcenter tables. Other application programs can create and accesstheir own tables directly.

The Persistent Object Manager (POM) is the tool that we provide for internalprogrammers, third parties, and customers to define their own data businessobjects, create and access their own data, and access simple Teamcenter data.To define data business objects, you normally use the Business Modeler IDE,rather than directly editing schemas or writing code (for more information aboutthis application, see the Business Modeler IDE Guide). It also presents anobject-oriented view of data, rather than the tabular view that SQL presents.Finally, it implements the locking, checking of access rights, and referentialintegrity checks for the system.

At the highest semantic level, there are application level procedures for accessingdata. These procedures can potentially operate on many objects at once, and canperform tasks other than just simple data reads and writes.

For example, an ITK procedure to add an attribute to a Classification object canactually cause a new object to be created in the database. References must beadded from this new object to the Classification object and vice versa. SeveralPOM calls must be made to build a valid set of data. Those POM calls make evenmore use of SQL to finally speak to the relational database in its terms of tables,rows, and values. In general, the POM should not be used to access object datafor which there are higher level ITK procedures.


Basic customization concepts

Four-tier architecture

Rich client architecturePOM is the core module in Teamcenter. The POM interfaces the applicationsmodules to the system modules. The primary system module in Teamcenter isusually either the Oracle RDBMS or SQL Server using ODBC.

For more information about supported databases and versions, see the followingWeb site:

http://support.industrysoftware.automation.siemens.com/



certification/teamcenter.shtml

The POM allows applications to interface to the system module at a higher levelof data abstraction than RDBMS relational tables. For example, an applicationmay request the POM to create a folder in Teamcenter. The POM interprets thiscommand 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. Thislayer 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 andperform work on Teamcenter data. These consist of Teamcenter modules,such as My Teamcenter, Structure Manager, EPM, Find, and Teamcentersystem administration. The applications, application objects, object interfaceadapter, and POM layer form the Teamcenter server.

o Core modules layer

The layer below the applications consists of core modules. These modulesperform medium-level functions required by the application module.

Thin client architectureThe thin client uses the Web tier in the four-tier architecture. This architecture isshared between the rich client and thin client.

• Request overview

The most important architectural feature of the thin client is that allclient-to-server requests use standard HTTP and all server-to-client responsesare standard HTTP responses. This standard technology allows great flexibilityin both client-side generation and handling of requests and server-sideprocessing of requests.

The following figure illustrates the communication between the Web browserand Teamcenter.



Request overview

• Browser client model

Browser clients use the tcserver TcScript API to communicate with the server.

o AJAX model

The thin client interface uses Asynchronous JavaScript and XML (AJAX) toallow dynamic loading of data in the browser. For example, this technology isused to expand additional levels in an existing tree without refreshing therest of the tree.

The following figure illustrates the AJAX model.



AJAX model

o Architecture

The differences between serving complete HTML pages or XML fragmentsare transparent to the server. It does not matter to the server whether it isserving them to an old page-based browser client, or a dynamic JavaScriptclient, or any other kind of client. This is part of the flexibility enabled bythe use of standard Web technology.

• Server processing model

There are two main features of the Teamcenter Web server:

o Statelessness

The tcserver process is logically stateless—successive requests are entirelyself-contained and do not rely on the state of the server from previousrequests. All persistent states are saved back to the database and thestateful process objects are unloaded at the end of each transaction. Thishas several benefits:

Scalability



The pool manager can cull the least-used processes incurring only theoverhead of a future logon. There is no need to maintain a persistentsession since no state is held in the server.

Resilience

Experience shows that the Teamcenter core is not failure-proof, but whenit does crash, the pool manager can start another session transparentlyto the user once the user reloads to resend the request.

Error handling

On error, rollback works correctly as there is no potentially corruptiblestate.

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 architecturestack, TcScript interpreter, and client interaction pattern. With the XMLAPI, the Teamcenter Web server is a general lightweight Teamcenter serverproviding a simple XML interface. The API is directed at the Web, so itmay be inappropriate for other specific tasks, but you can easily extend theAPI by implementing new page templates to execute any ITK-accessibleTeamcenter function. Customization is simple because of the separation ofthe custom user interface from the standard data delivery by the XML API.

Application interfacesThere are two application interfaces you can use to integrate external applicationswith Teamcenter:

• Teamcenter Services

Teamcenter Services allow different applications to communicate with oneanother using services. Teamcenter Services use service-oriented architecture(SOA), which is appropriate for integrating separate applications with a looselinkage and network-friendly APIs that do not need to be modified with everyTeamcenter version. This is the preferred method of integrating third-partyand client applications. Future releases will extend this interface and providetools so you can easily extend it.

For more information about Teamcenter Services, see the Services Guide andthe Services Reference.

Note The Services Reference is available only in the Teamcenter HTML HelpCollection. It is not available in the PDF collection.

• Integration Toolkit (ITK)

Use the ITK interface when programming within the Teamcenter server (forexample, extension points, workflow handlers, or low-level batch programs) andwhen constructing new interfaces for Teamcenter Services. It is a low-levelinterface that normally requires many more calls than the higher level interface(Teamcenter Services) to execute a given action, but it is powerful when youneed to access the system in this way. For integrating external applications,



Siemens PLM Software recommends that you use Teamcenter Services. If youneed functionality not exposed using Teamcenter Services, write new, high-levelservice methods using ITK and expose them as Teamcenter Services interfacesusing the Teamcenter Services toolkit.

For more information about ITK, see the Server Customization Programmer’sGuide and the Integration Toolkit Function Reference.

Note The Integration Toolkit Function Reference is not available in PDFformat. It is available only in the Teamcenter HTML Help Collection.

Customization applications and toolkitsYou can customize Teamcenter with several different applications and toolkits.What part of Teamcenter you choose to customize determines what application ortoolkit you should use.

• Integration Toolkit (ITK)

The Integration Toolkit (ITK) is a set of server-side software tools you can use tointegrate third-party or user-developed applications with Teamcenter. The ITKis a set of C and C++ functions used directly by Teamcenter and NX.

The Integration Toolkit is a set of callable subroutines that act as a programmaticinterface to Teamcenter. It is the means by which both internal and externalapplications interface with the Teamcenter core (including RDBMS) and theTeamcenter front end (including the window management subsystem). Internalapplications are those supplied such as NX. External applications are those thatyou decide to integrate into Teamcenter.

Teamcenter consists of various modules. The ITK interfaces the integrator’sapplication to these modules. The end goal of the ITK is to fully integrate anapplication into Teamcenter.

For more information about ITK customization, see the Server CustomizationProgrammer’s Guide and the Integration Toolkit Function Reference.

• C++ programming

You can write C++ code to perform server-side customizations using the BusinessModeler IDE.

For more information, see the Business Modeler IDE Guide and the ServerCustomization Programmer’s Guide.

• Teamcenter Services

Teamcenter Services use a service-oriented architecture (SOA) as one means toprovide customers with the ability to quickly and easily develop task-specificclients, utilities, and system integrations using the power of the Teamcenterserver. The Teamcenter Services operations are accessed through coarse-grainedinterfaces that minimize the amount of network traffic needed to accomplish anyspecific task. As such, Teamcenter is ideal for applications that were previouslyimpractical because of slow network speeds or limited network bandwidth.Teamcenter Services ship with libraries and interfaces to build applicationsin Java, C++, and .Net, giving you the flexibility to choose the technologythat best fits with your particular environment and standards. Teamcenter



Services also ship with WS-I compliant WSDL files for all operations, giving youfurther flexibility and the confidence that comes with supporting open industrystandards.

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 datain the Dispatcher Server (Dispatcher Server), storage of the Dispatcher Servertranslation results in Teamcenter, and management of the translation request.

For more information about Dispatcher, see Getting Started with Dispatcher(Translation Management).

• Thin client programming

The Teamcenter thin client is a Web-based client that uses XML, JavaScript,and HTML to render data from the server. Teamcenter provides generalcustomization techniques and tools to customize the thin client.

For more information about thin client customization, see the ClientCustomization Programmer’s Guide.

• Rich client programming

The Teamcenter rich client is based on a client-server architecture. The richclient is a user interface (UI) layer and is built and customized using the Javalanguage and the Eclipse integrated development environment. Teamcenterprovides general customization techniques and tools to customize the rich client.

For more information about rich client customization, see the ClientCustomization Programmer’s Guide.

Teamcenter rich client uses Java as the front end. Java is used because it isplatform independent and eliminates the need to build libraries on multipleplatforms. Java has the following features:

Architecture neutralObject orientedPortableDistributedInterpretedMultithreadedRobustDynamicSecure

In Java, a program is both compiled and interpreted. The compilertranslates a program into an intermediate language called Java bytecodes(platform-independent codes), and the interpreter parses and runs each Javabytecode instruction on the computer. Compilation happens only once, butinterpretation occurs each time the program is executed.

The Java platform has two components:

o Java Virtual Machine (Java VM)



o Java Application Programming Interface (Java API)

The Java API is a large collection of ready-made software components thatprovide many useful capabilities, such as graphical user interface (GUI) widgets.

The Java API is grouped into libraries of related classes and interfaces; theselibraries are known as packages. You can access the Java APIs from thefollowing Web site:

http://java.sun.com/reference/api/index.html

A detailed explanation of the Java programming language is available on thefollowing Web site:

http://java.sun.com/

Note CLASSPATH is an environment variable used for the ordered lookupof Java class files, icons, and property files. In previous versions ofTeamcenter, you could use the CLASSPATH environment variable tooverride icons, property files, and class files. However, Teamcenter nowuses Eclipse as its integrated development environment (IDE) and doesnot support the CLASSPATH variable. You must use Eclipse extensionsand extension points instead.


Teamcenter object model

Legend for object diagrams

The Teamcenter object model contains the classes used to manage data. The modelis described using a set of two basic relationship diagrams. One set of relationshipsshow the class hierarchy (taxonomy) and the other shows the associations that existbetween interacting objects in the system.

Following is the legend for the class object diagrams.



Class object diagram legend

Item and item revision model

Sample item and item revision model

The following figure shows an illustration of an item/item revision model.



Item/item revision model

Item

In Teamcenter, items are the fundamental objects used to manage information.Items provide an identification for physical or conceptual entities about which anorganization maintains information and audit/change control. Typical uses of itemsare parts, documents, and equipment. In an engineering/product developmentenvironment, parts are identified as items. An item has the following basicinformation:

• 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 treatedseparately. For example, an item can be used to manage parts and documents. Ifyou implement two item types, you can enforce rules based on the type of itemsthat are being manipulated.

Note The system, as delivered, provides a generic business object called Itemalong with several child business objects which all act as different itemtypes. If you need additional kinds of items, the system administratorcan 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 revisionis retained for historical purposes.

Note Each customer site defines its own procedures to determine how and when anew item revision should be created.

An item revision has the following basic information:

• ID

A unique identifier for an item.

• 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 someway relate to an item. For the data to be understood, it has to be associated in ameaningful way to the item or item revision. Teamcenter associates data to itemsand item revisions using relations.

Relations describe how the data is associated to an item and item revision. A datasetcontaining the CAD model, which defines an item revision, is a specification of theitem revision. Similarly, a standards document describing the fit, form, and functionof 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 itemrepresents various aspects of that item. A dataset containing stress test informationcould be added by the engineer, while a form containing size and weight informationcould be added by the specification engineer.



Teamcenter provides a basic set of relations. The relations between the object andthe item and item revision determines the rules enforced.

Note Additional relations and their associated rules are defined by your systemadministrator.

• IMAN_master_form

The master form relation associates a form to an item or item revision. Thisform is a collection of attributes that describe the item or item revision. Rulesfor this relation are as follows:

o An item or item revision must have write access to add or remove a masterform 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 onlyone 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 asstandards, which must be adhered to in a drawing, or technical requirements fora part. Rules for this relation are as follows:

o An item or item revision must have write access to add or remove arequirement relation to an object.

o A form can have a requirement relation to an item or item revision.

o Only version 0 (zero) of a dataset can have a requirement relation to anitem or item revision.

o A folder, envelope, BOM view, or BOM view revision cannot have arequirement relation to an item or item revision.

o An item cannot have a requirement relation to another item or item revision.

o An item revision can have a requirement relation to another item or itemrevision.

o An item revision cannot have a requirement relation to another item revisionif they are both revisions of the same item.

• IMAN_manifestation

The manifestation relation associates other related data to an item or itemrevision. This data may, however, be necessary for information, such as analysisof the competing ideas from which a part was originally conceived. Themanifestation relation also associates data to the item revision that containsdata derived from the specification data (such as tool paths). Rules for thisrelation are as follows:



o An item or item revision does not need to have write access to add or removea manifestation relation to an object. A manifestation relation can be addedor removed from a released item or item revision.

o A form can have a manifestation relation to an item or item revision.

o Only version 0 (zero) of a dataset can have a manifestation relation to anitem or item revision.

o A folder, envelope, BOM view, or BOM view revision cannot have amanifestation relation to an item or item revision.

o An item cannot have a manifestation relation to another item or itemrevision.

o An item revision can have a manifestation relation to another item or itemrevision.

o An item revision cannot have a manifestation relation to another itemrevision if they are both revisions of the same item.

• IMAN_specification

The specification relation associates data which defines the item revision.Examples are CAD models for parts or word processor files for documents. Rulesfor this relation are as follows:

o An item revision must have write access to add or remove a specificationrelation to an object.

o A form can have a specification relation to an item or item revision.

o Only version 0 (zero) of a dataset can have a specification relation to anitem or item revision.

o A folder, envelope, BOM view, or BOM view revision cannot have aspecification relation to an item or item revision.

o An item cannot have a specification relation to another item or item revision.

o An item revision can have a specification relation to another item or itemrevision.

o An item revision cannot have a specification relation to another item revisionif they are both revisions of the same item.

• IMAN_reference

The reference relation associates any data to an item or item revision. Rulesfor this relation are as follows:

o An item or item revision does not need to have write access to add or removea reference relation to an object. A reference relation can be added orremoved from a released item or item revision.

o Any object can have a reference relation to an item or item revision.



o Only version 0 (zero) of a dataset can have a reference relation to an itemor item revision.

o A reference object cannot reference itself.

• IMAN_revision

The revision relation associates item revisions to the appropriate item. Rulesfor this relation are as follows:

o An item must have write access to add or remove an item revision fromthe item.

o Only an item revision can have a revision relation to an item.

o The revision relation in an item is established by creating a new revision ofan item using the provided functionality. An item revision cannot be cut orpasted into an item.

• BOMView

The BOMView relation associates a product structure to an item. Rules for thisrelation are as follows:

o An item can have many BOMView relations.

o BOMView relations can represent different versions of a product structure.For example, one can be the design structure and another can be themanufacturing structure.

• BOMView Revision

The BOMView Revision relation associates a product structure revision to anitem revision. Rules for this relation are as follows:

o An item revision can have many BOMView Revision relations.

o BOMView Revision relations can represent different versions of a productstructure. For example, one can be the design structure and another can bethe manufacturing structure.

Modifying an item/item revision

Teamcenter is designed to organize the data created by other applications in a logicalmanner. When an item is first created, an item ID is reserved. It is only by addingdata to an item, however, that the item becomes meaningful.

Datasets are used to store information created by other applications. These datasetscan be associated to an item and item revision.

In Teamcenter, both item revision and dataset versions are intended to representmodifications to information. Item revisions represent the item at significantmilestones. Dataset versions represent day to day changes. An item has revisions;a dataset has versions.

There are two ways to modify an item and item revision. One method is to simplyadd or remove relations from the item and item revision by using cut and paste.



Another method is to modify the contents of an object that is currently related to theitem and item revision.

Item business object

Business objects are used to specialize the behavior of Teamcenter objects. Datasetsimplement the most extensive use of business objects. The Dataset business objectis 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 applicationassociated to this Dataset business object is opened. When an NX part Datasetbusiness object is opened, the NX application associated to this Dataset businessobject is opened. For each Dataset business object, the available operations (forexample print and open) are defined, as well as the specific behavior of eachoperation.

Item business objects extend the ability to specialize the behavior of items. Youmay need to distinguish between a part used in production and equipment used toproduce that part. Both may need to be an item, yet the information and businessrules surrounding these items are different.

Dataset model

A dataset contains a series of dataset objects, which reference the ImanFile objectsthat hold the data, and a RevisionAnchor object, which holds the list of datasetversions and the dataset ID, if one exists. A dataset may also reference Formobjects. The following figure from the UML (Unified Modeling Language) editor inthe Business Modeler IDE shows the RevisionAnchor object that creates a newlogical dataset.



Dataset model

Dataset IDs are optional, but they must be unique. The unique ID enforcement indatasets is performed at the application level. Each time the New®Dataset menucommand 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 iscalled to ensure the dataset ID (id) and revision (rev) combination is unique withinthat specified dataset business object.

Also, for each dataset business object, if the dataset ID is created using the Assignbutton, a separate counter generates the next unique ID that is available for astandalone dataset. This counter ensures id and rev are unique within the samedataset 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. Ifyou 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.

• AE_find_dataset ("name", &dataset)

Finds revision 0 of the dataset.

• AOM_refresh (dataset, true)

Loads the given dataset version for modification.

• 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 sameprotection; updating any of those on any one revisions updates all other revisions.

For more information about these functions, see the Integration Toolkit FunctionReference.

Note The Integration Toolkit Function Reference is not available in PDF format. Itis available only in the Teamcenter HTML Help Collection.

Form model

Forms provide the ability to store customer defined attributes. Teamcenter providesstandard forms. Most of the forms used at a customer site, however, are modified tocapture the information unique to its business.

Forms are stored as POM objects. Attributes in the forms can be set and retrievedusing Form ITK functions and the POM query ITK functions. When a form isstored, 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 (UnifiedModeling Language) editor in the Business Modeler IDE.



Form model

System administration model

The POM_application_object class and all its subclasses have owners andprotection that can be altered by the system administrator. The following figureshows a diagram of the system administration model.



System administration model

Product structure object model

For detailed information on the product structure object model, see the ServerCustomization Programmer’s Guide.

Access control model

Access control list (ACL) entries consist of a reference to a group and/or a user andthe access rights grant to such a subject. A subject is an object that can be granted



access rights in Teamcenter. The following figure shows a diagram of the accesscontrol model.

Access control model

Application encapsulation model

The application encapsulation data model is designed to enable Teamcenter tomaintain relations between data and the applications that can present it to theend user.

The model provides a means of declaring an application to Teamcenter by creatinginstances of the Tool class. It also provides a means of determining which toolto use for the creation and manipulation of various pieces of data. This is doneby providing a DatasetType object class for you to use when specifying the toolsthat can create and manipulate data.

A tool can be a shell. A shell is an executable image written to execute otherlegacy images. The shell uses the ITK to extract data from Teamcenter and updateTeamcenter with data created by the execution of legacy systems. A shell canbe developed that manages all applications at a site; it can be started from thecommand line. This shell can present a form to the user to fill out before executingthe legacy system so the shell can make any records that the site may need.

A shell can also be developed to copy data from Teamcenter into a temporary orworking directory from which a legacy (non-integrated) application is run. Thisallows some support for applications that always require interactive input. If theshell moves required files into the working directory, and the application reads filesfrom the current directory if only file names are specified, it would be very difficult toput procedures in place that require the user to use only file names when using suchapplications. If this is done, a shell can prepare data for an application, record thestate of the directory and use that information to determine what happened after theapplication is terminated. In this type of example, the input/output parameters ofthe application declaration in Teamcenter can allow this shell to ignore some scratchfiles that may be left in the directory by the executing application.



If you start from scratch, you can develop an integrated application that does notrequire 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 thedataset. 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, anamed reference can be created for each file. The name of the reference is often theextension of the file but does not have to be. A CAD system may have a file in whichit stores geometric data with a .gmd extension, finite element modeling data in a filewith 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, anddrawing, or gmd/fem/drw as the shell chooses. If you use the extensions, users donot have to change the reference names during import, since by default the importassumes the reference names correspond to the file extensions.

The model shows that the named reference can refer to an ImanFile object or otherdescendant class of the POM object. This means a shell can be implemented thatdoes not use the ImanFile object to store file data, but instead uses its own fileobject to store such information. However, you should do this rarely since there is aloss of integrity that is provided by the ImanFile object. However, the flexibility itprovides may be necessary in some cases.

TheRevisionAnchor object is provided to support versioning of datasets. Whenevera dataset is created, a RevisionAnchor object is also created. This object maintainsa list of working revisions of the dataset. However, it is up to the shell/integratedtool to use this facility. To use it, you must make revision copies and then makechanges 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 restof the Teamcenter model description, which shows relationships and gives a moredetailed description of individual classes.

Class objects have a meaningful hierarchy that relates to the Teamcenter layeredsoftware architecture previously discussed. It is presented in an indented outlineform.

The following legend defines the mnemonic descriptions shown in parentheses inthe 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 ClassIMF 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 moreinformation about other classes, see the Business Modeler IDE Guide.



Class hierarchy



Mapping business objects and classesStarting in Teamcenter 8, secondary business objects are mapped to their ownsubclasses and attributes are stored directly in the subclass for the entire hierarchy.In previous versions, secondary business objects were mapped to the parent classesof their primary business objects and secondary business object attributes werestored on the master form. If you upgrade from a previous version of Teamcenter orTeamcenter engineering process management to Teamcenter 8 or a later version,the metamodel migration upgrade converts the secondary business objects to theirown subclasses.

Warning You may lose data if you use Multi-Site Collaboration with a system thathas both pre-Teamcenter 8 and Teamcenter 8 or later sites.

• If you transfer data from a Teamcenter 8 or later site to apre-Teamcenter 8 site, any attributes you added to the subclasses inTeamcenter 8 or later versions are dropped at the pre-Teamcenter 8site.

• Similarly, if you transfer data from a pre-Teamcenter 8 site to aTeamcenter 8 or later site, any attributes you added to the masterform for the secondary business objects in the pre-Teamcenter 8version are dropped at the Teamcenter 8 or later site.

To avoid data loss when transferring data from a Teamcenter 8 or latersite to a pre-Teamcenter 8 site, create new attributes on the master formin Teamcenter 8 or later versions.

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 aclass. 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, adescription, and a list of entries. These are the attributes of the folder class. Whena folder is instantiated, an actual folder object is created. It has attributes asdescribed here. There are also methods or functions defined for the folder class, suchas Insert and Remove.

Attributes in Teamcenter can be integer, float, boolean, string, date, tag, or arraysof any of these types. A tag is a unique identifier of a reference (typed, untyped, orexternal) 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 theclass.

• 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 theattribute 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 inheritsthe attributes and methods from two different classes. There are no instances ofmultiple inheritance in Teamcenter.

A superclass may be a generalization of many similar classes. For example, theWorkspaceObject superclass is a generalization for all of the classes whoseinstances may be seen in the workspace (for example, in a folder). All of theattributes and methods that are common to the Dataset, Folder, and other classesare defined once in the WorkspaceObject superclass, rather than being definedmany times. Usually, generalizations are abstract or noninstantiable. This meansthat the class exists for conceptual or convenience reasons, but you cannot actuallycreate an instance of one.

A subclass may be a specialization of another class. For example, the Envelopesubclass is a specialization of the Folder class. In this case, a new class is beingdefined that is like another one except for some additional attributes and/or somespecialized behavior such as a specialized method.

Object-oriented language

An object-oriented language is a programming language that has built in keywords or constructs that either force or facilitate object oriented programming.For example, C++ is one, because it supports classes, objects, inheritance, andpolymorphism. The C language is not.

However, you can do object-oriented programming with a nonobject-orientedlanguage; it is just harder. You can certainly have an object model with inheritanceof attributes and methods without using an object oriented language. This is what ispresented through ITK.

Internally, much of Teamcenter is written in C++. This provides an easy way ofhandling polymorphism. You can take advantage of this in the ITK as well. If youwant to execute a method on an object, you do not need to call a function specificto that action-class pair. You may call any function with that action up the tree ofsuperclasses for the selected object. For example, if you want to ask the name of anenvelope, 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 levelsup in the hierarchy instead. That function realizes that it was actually passed anenvelope and invokes the envelope’s method to get the name.



Some of the important concepts of object-oriented programming are:

• Encapsulation

Combining data types with valid operations to form a class. A class is ablueprint, or prototype, that defines the variables and the methods common toall objects of a certain type.

• Inheritance

The ability to inherit class definitions and make modifications that specializethe 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 appropriateto itself.

Registry

What is the registry?The registry plays a vital role in the Teamcenter rich client. The registry usesthe properties files to define classes, icons, internationalized text, inheritance,search order, and appearance. Our registry is fundamentally a subclass ofthe ResourceBundle object found in Java and uses the properties files tostore replaceable information that can be tailored based on need. Many basiccustomization 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, butthe value can be modified. Every key/value pair that appears within the registryfalls into one of the following categories: appearance, structural, instantiation, orlocalization.

• 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 todefine a key in one place within the rich client that can be reused without beingduplicated. For instance, the OK button text must be localized in the rich clientuser interface based on the current locale. Therefore, the text for OK is placedwithin the aif_locale.properties file.

• Instantiation

Keys used to construct Java objects. Teamcenter rich client makes use ofreflection and dynamic instantiation within the Java language to constructobjects by their string name rather than hard-coding them within the sourcecode.



For example, each command that appears in the menu bars and toolbars isdynamically constructed and run. You can subclass a command and replace itwith your own by replacing an entry within a properties file to tell the rich clientto use your command rather than the base command.

• Localization

Keys allow localization of text and messages to be flexibly obtained based on thecurrent locale of the OS where rich client is running. Teamcenter rich client isdelivered with locales that support English, German, French, Spanish, Italian,Czech, Russian, Korean, Japanese, and Chinese. Each of these separate propertyfiles is based on the convention that JavaSoft has established. Localization keysare those for which the ResourceBundle class was first designed.

In any given package (directory) that uses registries, there are three propertyfiles: 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 requiredin a package.

o Locale properties file

Contains only localization keys. The reason for having the localizationseparate from the base is that when keys are to be localized within the richclient, it is easy to separate the localization keys from the rest. In addition,if you are developing customization to be deployed in more than one locale,this provides a convenient separation between the two and allows for easierlocalization that could be outsourced to third parties for completion.

For more information about localization, see the Localization Guide.

User properties files

These files contains properties that can be modified by customers. When you makemodifications to the rich client, always make them in the user properties file. Thisprotects the base system from user mistakes. It also enables a backup approach inthe event that the change breaks the rich client, in which case you can reload orobtain a copy from the reference directory.

User property files are always consulted first for registry lookups. The rich clientis completely loaded on demand. Therefore, when it starts up, the applicationslisted on the left side may or may not exist. This is not known until the user clickson the application for the first time. In addition, commands are never loaded untilrequested by the user. This loading method provides a small memory footprint andenables the system to only use resources that the user has requested.

Supported types

Primitive types are supported in the registry as well. The following types aresupported: color, font, integer, float, double, char, boolean, string, string array, andimages. Some of the types use special formats, as follows:

• Color



red, green, blue

255,255,255

• 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 Acrobattype, 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

Java interprets the key as Adobe and the value as Acrobat=images/acrobat.gif.


Chapter

3 Common customization tasks

Change page layout with style sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Change menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Customize a business object icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Develop a form for the rich client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Customize Teamcenter behavior with a user exit . . . . . . . . . . . . . . . . . . . . . . 3-2

Create codeful customizations with the Business Modeler IDE . . . . . . . . . . . . 3-3


Chapter

3 Common customization tasks

Change page layout with style sheetsChange the page layout in both the rich client and thin client by editing XMLrendering style sheets. You can use style sheets to change the layout of pages such asforms, the Properties dialog box, the Summary view, and the creation wizard dialogboxes. Style sheets are XML documents stored in XMLRenderingStylesheetdatasets on the server.


Change menusYou can remove or add menus in Teamcenter:

• Remove menus

Removing menus is known as command suppression. Use the CommandSuppression application to remove menus from the user interface. You can alsouse business object display rules to hide objects from menus.

For more information, see the Application Administration Guide, the ClientCustomization 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 amenu to the thin client.


Customize a business object iconYou can customize the icon for a new or existing Teamcenter business object for therich client or thin client:

• Rich client

1. If necessary, create the business object.

2. Create the icon.

3. Add the icon to your Business Modeler IDE project.


Chapter 3 Common customization tasks

4. Use the Fnd0Icon business object constant to specify the primary icon torepresent the business object.

5. Install the icon to the server.

For more instructions, see the Business Modeler IDE Guide.

• Thin client

Change the icons in the staging_location\webapp_root\typeicons directory.

For more instructions, see the Client Customization Programmer’s Guide.

Develop a form for the rich clientThere are four ways you can develop a form for the rich client:

• Use XML style sheets

Do this by modifying an existing XML style sheet or creating a new one. Thestyle sheet is an XML document stored as a XMLRenderingStylesheetdataset. When a style sheet is registered for a specific object type or form, itdefines the display of the object or form properties. Registration informationis stored in the preferences.

The thin client also uses the XML style sheets, so modifying them may changethe form’s appearance in the both the rich client and thin client.

• Use JavaBeans

Do this by launching Eclipse and creating a new JPanel component. Then addProperty bean components to the new JPanel.

• Extend the abstract class

Do this by creating a form type, extending the schema, creating the form panel,and registering the panel with the rich client.

• Create an automatic form

Do this by creating a form type and extending the schema.

Note In the thin client, the form’s contents appear, but you cannot customizethe layout.

For more detailed, step-by-step instructions, see the Client CustomizationProgrammer’s Guide.

Customize Teamcenter behavior with a user exitUser exits are exit points from Teamcenter’s standard functionality to a C program.You can write your own or customize Teamcenter’s ITK user exits to alter its behavior.

For example, you can use the following steps to change the autoassigned itemrevision ID from A to 001:


Common customization tasks

1. Install sample files using Teamcenter Environment Manager (TEM). In theFeatures panel, under Server Enhancements, select Sample Files.

For more detailed instructions, see the Server Customization Programmer’sGuide.

2. Open the TC_ROOT\sample\examples\user_part_no.c file in a text editor.

3. Find the line:

#define FIRST_REV_ID "A"

4. Change the line to:

#define FIRST_REV_ID "001"

5. Save and close the file.

6. Compile the user_part_no.c file and link it to the user exits library (thelibuser_exits.lib file) in the TC_ROOT\lib directory.

7. Copy the libuser_exits library file to the TC_ROOT\bin directory.

For more details about compiling and linking files, see the Server CustomizationProgrammer’s Guide.

Create codeful customizations with the Business Modeler IDEIf you want to extend the functionality of Teamcenter by writing C++ code, you canuse the Business Modeler IDE to write the code using the following methods:

• Data model based customization

Allows addition of custom C++ operations to business objects and overriding ofexisting operations on business objects.

• Teamcenter Services customization

Allows custom service-oriented architecture (SOA) service operations to bewritten to interact with the Teamcenter rich client.

• Extensions customization

Allows you to write a custom function or method for Teamcenter in C or C++ andattach the rules to predefined hook points in Teamcenter.

For step-by-step instructions, see the Business Modeler IDE Guide.


Appendix

A Glossary


Appendix

A Glossary

A

architectureSet of decisions, patterns, and principles for a product suite. The architectureprovides a framework for application development within that product suite and isindependent of specific functions.

B

Business Modeler IDETeamcenter application that enables a customer to define data model objects such asbusiness objects, classes, attributes, lists of values, and rules.

C

classSet of objects that share the same list of attributes but distinguishable by the valuethe attributes acquire for specific objects. For example, the Automobile class can bedefined by the brand, color, and price, but each car associated to the Automobileclass has a different brand, color, and price combination.

class hierarchyStructure defining subclasses that inherit the attributes of their superclasses, alsocalled their parents or ancestors.

clientRole played by a software component of a system when it requests particular servicesbe performed on its behalf by another entity, a server. See also server.

client tierTeamcenter architectural tier that comprises the Teamcenter clients, Teamcenterintegrations with third-party applications, and the third-party applicationsassociated with the integrations.

closure ruleDefinition or rule that allows the Teamcenter traversal algorithm to identify theadditional objects required for a specific principal object.

compound property ruleBusiness rule that defines run-time properties on an object that references andrelates to a property on a source object. Compound property rules relate to theproperty associated with type components. Applied types are item, item revision,dataset, and form.

PLM00003 I Getting Started with Customization A-1

Appendix A Glossary

D

datasetTeamcenter workspace object used to manage data files created by other softwareapplications. Each dataset can manage multiple operating system files, and eachdataset references a dataset tool object and a dataset business object.

deep copy ruleBusiness rule that defines whether relational type objects can be copied as object,copied as reference, or not copied when the user performs a save-as or reviseoperation.

E

extensionMethod or listener implemented for an extension point.

extension pointEvent or capability in the system, such as a precondition, preaction, or postaction,that allow you to implement custom behavior.

extension ruleBusiness rule that adds predefined behavior to a business object’s operation and firesas a precondition, preaction, or postaction.

F

formTeamcenter workspace object used to display product information (properties) in apredefined template. Forms are often used to create an electronic facsimile of ahardcopy form in Teamcenter. See also master form.

four-tier architectureTeamcenter architecture that includes four tiers: resource tier, client tier, Web tier,and enterprise tier. Contrast with two-tier architecture.

G

Generic Relationship Management ruleRule that defines the relationship between two business objects. The rule has thefollowing constraints: cardinality, changeability, attachability, and detachability.

GRM ruleSee Generic Relationship Management rule.

L

List of Values (LOV)Pick list of values accessed by end users from a menu at the end of a data field.LOVs ensure consistent data entries in the rich client.

LOVSee List of Values (LOV).

A-2 Getting Started with Customization PLM00003 I

Glossary

M

master formTeamcenter workspace object used to display product information (properties) ina predefined template. Master forms are used to display product information ina standardized format.

P

persistent object manager (POM)Interface between Teamcenter objects and the Relational Database ManagementSystem (RDBMS). The persistent object manager provides definition of classesby inheritance from other classes and definition of attributes, manipulation ofin-memory objects and support for their saving and retrieval to and from theunderlying RDBMS, support for applications accessing the same data concurrently,protection against the deletion of data used by more than one application, andsupport for the access control lists attributed to objects.

PLM XMLSiemens PLM Software format for facilitating product life cycle interoperabilityusing XML. PLM XML is open and based on standard W3C XML schemas.Representing a variety of product data both explicitly and via references, PLMXML provides a lightweight, extensible, and flexible mechanism for transportinghigh-content product data over the Internet.

POMSee persistent object manager (POM).

properties fileFile containing the attributes (keys and values) that specify how an application is tobehave in the Teamcenter rich client.

R

registry fileProperties (.properties) file that contains the user-defined configuration settings(keys and values) that are relative to how the application displays and performsin the Teamcenter rich client. Each application registered in the rich client has a.properties file known as a registry file.

rich clientJava-based user interface to Teamcenter installed on user workstations. The richclient accesses Teamcenter databases using a remote or local server. Compare tothin client.

S

serverSystem software component that performs a specifically defined set of softwareservices 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 networkingtechniques. See also client.

PLM00003 I Getting Started with Customization A-3

Appendix A Glossary

T

thin clientTeamcenter user interface that provides a streamlined browser-based view of productinformation stored in a Teamcenter database. The thin client is configured in theWeb tier, which creates and serves its Web pages to the client. Compare to rich client.

two-tier architectureTeamcenter architecture that includes a resource tier and a client tier. The resourcetier comprises the database server and database. The client tier comprises theTeamcenter 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-4 Getting Started with Customization PLM00003 I

Index

AAccess control object model . . . . . . . . . 2-21API, seeAppearance keys . . . . . . . . . . . . . . . . . 2-28Application encapsulation objectmodel . . . . . . . . . . . . . . . . . . . . . . . . 2-22

Application Programming Interface . . . . 2-9Architecture . . . . . . . . . . . . . . . . . . . . . 2-1Audience . . . . . . . . . . . . . . . . . . . . . . . 1-1

BBase properties files . . . . . . . . . . . . . . 2-29BOM view . . . . . . . . . . . . . . . . . . . . . 2-16

CC++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8C++ code . . . . . . . . . . . . . . . . . . . . . . . 3-3Class hierarchy . . . . . . . . . . . . . . . . . . 2-23CLASSPATH environment variable . . . 2-10Color format . . . . . . . . . . . . . . . . . . . . 2-29common_user.properties file . . . . . . . . . . 3-1Compatibility . . . . . . . . . . . . . . . . . . . . 1-1Conventions, syntax definitions . . . . . . . 1-2

DDataset object model . . . . . . . . . . . . . . 2-17Dispatcher . . . . . . . . . . . . . . . . . . . . . . 2-9

EEncapsulation . . . . . . . . . . . . . . . . . . . 2-27

FFiles

common_user.properties . . . . . . . . . . . 3-1Properties . . . . . . . . . . . . . . . . . . . . 2-29

Font format . . . . . . . . . . . . . . . . . . . . 2-30Form object model . . . . . . . . . . . . . . . . 2-19Forms . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Four-tier architecture . . . . . . . . . . . . . . 2-1

HHierarchy of classes . . . . . . . . . . . . . . 2-23HTTP requests . . . . . . . . . . . . . . . . . . . 2-4

IIcons . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Inheritance . . . . . . . . . . . . . . . . . . . . . 2-27Instantiation keys . . . . . . . . . . . . . . . . 2-28Integration Toolkit . . . . . . . . . 2-7–2-8, 3-2Item

Business object . . . . . . . . . . . . . . . . 2-17Model . . . . . . . . . . . . . . . . . . . . . . . 2-11Modifying . . . . . . . . . . . . . . . . . . . . 2-16Objects . . . . . . . . . . . . . . . . . . . . . . 2-12Revisions . . . . . . . . . . . . . . . . . . . . 2-13

ITK, see Integration Toolkit

JJava . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

API . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Components . . . . . . . . . . . . . . . . . . . 2-9Foundation classes . . . . . . . . . . . . . . 2-10Overview . . . . . . . . . . . . . . . . . . . . . . 2-9Programming language . . . . . . . . . . 2-10

LLicense agreement . . . . . . . . . . . . . . . . 1-1Locale properties files . . . . . . . . . . . . . 2-29Localization keys . . . . . . . . . . . . . . . . 2-29

MManifestation . . . . . . . . . . . . . . . . . . . 2-14Master form . . . . . . . . . . . . . . . . . . . . 2-14Menus . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Modifying an item/item revision . . . . . . 2-16

OObject model . . . . . . . . . . . . . . . . . . . . 2-10

Access control . . . . . . . . . . . . . . . . . 2-21

PLM00003 I Getting Started with Customization Index-1

Index

Application encapsulation . . . . . . . . . 2-22Dataset . . . . . . . . . . . . . . . . . . . . . . 2-17Form . . . . . . . . . . . . . . . . . . . . . . . . 2-19Item and item revision . . . . . . . . . . . 2-11Product structure . . . . . . . . . . . . . . . 2-21System administration . . . . . . . . . . . 2-20

Object-orientedData . . . . . . . . . . . . . . . . . . . . . . . . 2-26Language . . . . . . . . . . . . . . . . . . . . 2-27

OOP conceptsEncapsulation . . . . . . . . . . . . . . . . . 2-27Inheritance . . . . . . . . . . . . . . . . . . . 2-27Polymorphism . . . . . . . . . . . . . . . . . 2-27

Oracle RDBMS . . . . . . . . . . . . . . . . . . . 2-3

PPersistent Object Manager . . . . . . . . . . . 2-3Polymorphism . . . . . . . . . . . . . . . . . . . 2-27POM, see Persistent Object ManagerProduct structure object model . . . . . . . 2-21Properties files . . . . . . . . . . . . . . . . . . 2-28

Rreference relation . . . . . . . . . . . . . . . . 2-15Registry . . . . . . . . . . . . . . . . . . . . . . . 2-28Registry keys

Appearance . . . . . . . . . . . . . . . . . . . 2-28Instantiation . . . . . . . . . . . . . . . . . . 2-28Localization . . . . . . . . . . . . . . . . . . . 2-29Structural . . . . . . . . . . . . . . . . . . . . 2-28Syntax . . . . . . . . . . . . . . . . . . . . . . 2-30

Relations . . . . . . . . . . . . . . . . . . . . . . 2-13requirement relation . . . . . . . . . . . . . . 2-14ResourceBundle object . . . . . . . . . . . . . 2-28Reverse engineering . . . . . . . . . . . . . . . 1-1revision relation . . . . . . . . . . . . . . . . . 2-16Rich client

Architecture . . . . . . . . . . . . . . . . . . . 2-3

Form . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Programming . . . . . . . . . . . . . . . . . . 2-9

SServer layer

Application layer . . . . . . . . . . . . . . . . 2-4Core modules layer . . . . . . . . . . . . . . 2-4

Service-oriented architecture . . . . . . 2-7–2-8Services . . . . . . . . . . . . . . . . . . . . . 2-7–2-8SOA, see Service-oriented architecturespecification relation . . . . . . . . . . . . . . 2-15Statelessness . . . . . . . . . . . . . . . . . . . . 2-6String array format . . . . . . . . . . . . . . . 2-30Structural keys . . . . . . . . . . . . . . . . . . 2-28Subclasses . . . . . . . . . . . . . . . . . . . . . 2-27Superclasses . . . . . . . . . . . . . . . . . . . . 2-27Supported types . . . . . . . . . . . . . . . . . 2-29Syntax definition conventions . . . . . . . . . 1-2System administration object model . . . 2-20

TTeamcenter Services . . . . . . . . . . . . 2-7–2-8Thin client

Architecture . . . . . . . . . . . . . . . . . . . 2-4Programming . . . . . . . . . . . . . . . . . . 2-9Requests . . . . . . . . . . . . . . . . . . . . . . 2-4

Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

UUnpublished APIs and extensionpoints . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

UserExit . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Properties files . . . . . . . . . . . . . . . . . 2-29

User exits . . . . . . . . . . . . . . . . . . . . . . . 3-2

Index-2 Getting Started with Customization PLM00003 I

Documents

Getting Started with Customization - Help!help.aviacons.ru/.../pdf/getting_started_with_customization.pdf · PLM00003I Getting Started with Customization 2-1. Chapter2 Basic customization