Business Modeler

Teamcenter
Engineering Process Management
Business Modeler Help
Publication Number
business_modeler C
Teamcenter
Engineering Process Management
Business Modeler Help
This product is intended for use only described in this document.

Siemens PLM Software cannot be responsible for the proper functioning
of undescribed features and parameters.
Publication Number
business_modeler C
Manual History
Teamcenter
Engineering
Version
Manual Publication
Revision Date
A 2005 (10.0) September 2005
B 2005 SR1 June 2006
C 2005 SR1 MP7 September 2008
2007 MP7
Teamcenter 8
This edition obsoletes all previous editions.
2 Business Modeler Help business_modeler C

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8
Teamcenter Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Submitting Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Proprietary and restricted rights notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Understanding the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Administering Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Importing and Exporting Business Rules . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Exporting Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Importing Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Comparing Rule Configurations Using Diff/Merge Tools . . . . . . . . . . . . . . . . . 2-4
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Understanding the Impact of Property Inheritance on Naming Rule Behavior . . 3-2
Defining Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Attaching Naming Rules to Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Deleting Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Defining Naming Rule Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Creating Baseline Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Prepackaged Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Creating Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Understanding the Impact of Inheritance on Deep Copy Rule Behavior . . . . . . 5-1
Managing Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Restrictions on the Use of Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Compound Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

What Is a Compound Property? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Managing Compound Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
ID Context Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Defining Rules for Alias Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
business_modeler C Business Modeler Help 3

Contents
Defining Rules for Alternate Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Generic Relationship Management (GRM) Rules . . . . . . . . . . . . . . . . . . 8-1

Evaluation Order for GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Understanding the Impact of Type Inheritance on GRM Rules . . . . . . . . . . . . 8-2
Defining GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Reviewing GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Type Display Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

How Type Display Rules Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Applying Type Display Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Generating Shown Types Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Complex Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Enabled Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Modifiable Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Required Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Visible Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Managing Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Converting Action Rules to Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Importing and Exporting Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Working With Internal Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
Figures
2-1. Rule Compare Dialog Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

3-1. IntegerNum Naming Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3-2. RealNum Naming Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
3-3. Example of Naming Rule Pattern Using System Variables . . . . . . . . . . 3-14
3-4. Naming Rule With Two Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
8-1. Cardinality Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
10-1. Modifiable Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
10-2. Modifiable Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
11-1. Extension Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Tables
1-1. Business Rule Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

2-1. Import/Export Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
3-1. Properties Subject to Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Contents
3-2. Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3-3. Valid Characters for Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
3-4. Form Name Based on System Variables . . . . . . . . . . . . . . . . . . . . . . . 3-15
4-1. Valid Configurations for autoAssignToProject . . . . . . . . . . . . . . . . . . . 4-4
4-2. Examples of Action and Propagation Rule Behavior . . . . . . . . . . . . . . . 4-5
5-1. Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
10-1. Property Types and Value Types for the Enabled Rule . . . . . . . . . . . . . 10-2
10-2. Property Types and Value Types for the Initial Value Rule . . . . . . . . . . 10-4
10-3. Property Types and Value Types for the Modifiable Rule . . . . . . . . . . . . 10-6
10-4. Property Types and Value Types for the Required Rule . . . . . . . . . . . . . 10-7
10-5. Property Types and Value Types for the Visible Rule . . . . . . . . . . . . . . 10-8
11-1. Methods to Business Modeler Framework Mapping . . . . . . . . . . . . . . . 11-2
11-2. Business Modeler User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
11-3. Valid Configurations for autoAssignToProject . . . . . . . . . . . . . . . . . . 11-16
11-4. Examples of Extension and Propagation Rule Behavior . . . . . . . . . . . 11-17
11-5. Valid Configurations for checkLatestReleased . . . . . . . . . . . . . . . . . . 11-18
11-6. Valid Configurations for copyVariantExpr . . . . . . . . . . . . . . . . . . . . . 11-18
11-7. Valid Configurations for createCAEObjects . . . . . . . . . . . . . . . . . . . . 11-18
11-8. Valid Configurations for createObjects . . . . . . . . . . . . . . . . . . . . . . . 11-19
11-9. Valid Configurations for setIdentifierProperties . . . . . . . . . . . . . . . . . 11-19

Preface
This manual describes the creation and management of business rules that allow
you to customize the behavior of the Teamcenter engineering process management
data model.
This document supplements the Teamcenter Help Library. If you find

information inconsistent with that found in that Teamcenter Help Library,
contact the Global Technical Access Center (GTAC) for clarification.
Audience
The readers of this guide should be experienced administrators with advanced
knowledge of the Teamcenter data model, Teamcenter system behavior, and the
business practices of their enterprise.
Organization
This manual contains the following chapters:
Chapter 1 Getting Started describes the Business Modeler interface

and the types of business rules that you can apply to the
Teamcenter data model.
Chapter 2 Importing and Exporting Business Rules describes how to
import and export business rules in PLM XML format.
Chapter 3 Naming Rules describes how to administer rules that
allow you to implement custom naming conventions for the
objects used to represent your data.
Chapter 4 Action Rules describes how to administer rules that define
actions (precondition, preaction, and postaction) that are
performed in conjunction with a specific operation.
Chapter 5 Deep Copy Rules describes how to administer rules used to
determine which related objects are copied forward when
you save a new object based on an existing object or create a
new revision of an existing object.
Chapter 6 Compound Property Rules describes how to administer
rules used to define compound properties. Compound
properties are properties that can be displayed for one
object even though they are defined for and reside within
the object model of a different object.

Preface
Chapter 7 ID Context Rules describes how to administer the rules

that determine system behavior when creating alternate
and alias identifiers.
Chapter 8 Generic Relationship Management (GRM) Rules describes
the rules used to apply constraints on objects based on the
relationship between primary and secondary objects.
Chapter 9 Type Display Rules describes the rules used to control the
display of object types in the Teamcenter interface. These
rules can be applied to an entire site, a specific group, or a
specific role within a group.
Chapter 10 Property Rules describes the different types of property
rules: complex, enabled, modifiable, required, and visible,
used to control access to and the behavior of object
properties.
Chapter 11 Extension Rules describes how to administer extension
rules that allow you to use custom-defined functions and
predefined methods to extend Teamcenter behavior.
Appendix A Glossary defines Teamcenter terms.
Conventions
This manual uses the conventions described in the following sections.
Revision Marks
Technical changes are marked by a bar adjacent to the changed text.
Note, Caution, and Warning Icons

The following icons represent note, caution, and warning messages:
A note icon identifies general instructions or comments that need to be
emphasized.
A caution icon identifies practices that can either produce results contrary to
what you expect or result in damage to software or data.
A warning icon identifies practices that could result in permanent loss of

data or software.

Preface
Names and Values

This manual represents system names, file names, and values in fonts that help you
interpret the name or value. For example:
The file name is pom_schema_server-name_sid.
The conventions are:
Bold Bold font represents unvarying text or numbers within a name or

value. Capitalization is as it appears.
In the preceding example, pom_schema_ identifies an unvarying
portion of the name.
Italic Italic font represents text or numbers that vary. The characters in
italic text describe the entry. Letters are shown in lowercase, but
the varying text may include uppercase letters.
In the preceding example, server-name and sid represent varying
portions of the name.
text-text A hyphen separates two words that describe a single entry.
In the preceding example, server-name is a single value.
For example, the name of the pom_schema_server-name_sid file may be:

pom_schema_Blue5_f731

Preface
Command Line Entries, File Contents, and Code

This manual represents command line input and output, the contents of system files,
and computer code in fonts that help you understand how to enter text or to interpret
displayed text. For example, the following line represents a command entry:
create_change_types —u=user-name –p=password –g=group —f=file-name
Monospace Monospace font represents text or numbers you enter on a

command line, the computer’s response, the contents of system
files, and computer code.
Capitalization and spacing are shown exactly as you must enter
the characters or as the computer displays the characters.
In the preceding example, create_change_types identifies an
unvarying portion of the command.
Italic Italic font represents text or numbers that vary. The words in
italic text describe the entry.
The words are shown in lowercase letters, but the varying text
may include uppercase letters. When entering text, use the case
required by the system.
In the preceding example, user-name, password, group, and
file-name identify varying portions of the command.
text-text A hyphen separates two words that describe a single entry.
In the preceding example, user-name is a single entry in the
command.
The following example is a correct entry for the preceding create_change_types

command:
create_change_types -u=infodba -p=KLH3b -g=dba —f=change_types.dat

Preface
Syntax Definitions
This manual 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 ...]
Bold Bold text represents words and symbols you must enter exactly
as shown.
In the preceding example, you enter 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.
Following are examples of correct syntax for the harvester_jt.pl: command:

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

Preface
Teamcenter Documentation
Teamcenter documentation is provided as online help and as printable manuals:
• You can access online help by choosing Help from the menu bar of a Teamcenter
rich client application or by clicking one of the links under the Help icon in the
Teamcenter thin client user interface.
• You can access the printable manuals from the Teamcenter Documentation
CD-ROM. To view the PDF-formatted manuals, use Adobe Acrobat Reader,
downloadable free-of-charge from Adobe Systems Incorporated at the following
URL:
http://www.adobe.com
Acrobat Reader allows you to view these manuals online and print selected
pages, sections, or the entire manual. Siemens PLM Software grants permission
for Teamcenter users to print, duplicate, and distribute this documentation.
Submitting Comments
Portions of Teamcenter software are provided by third-party vendors. Special
agreements with these vendors require Siemens PLM Software to handle all problem
reports concerning the software they provide. Please submit all comments directly to
Siemens PLM Software.
Please feel free to give us your opinion of the usability of this manual, to suggest
specific improvements, and to report errors. Mail your comments to:
Siemens PLM Software Technical Communications
5939 Rice Creek Parkway
Shoreview, MN 55126
U.S.A.
To submit an incident report, you can use the Siemens PLM Software GTAC online
support tools at the following URL:
http://support.ugs.com
Proprietary and restricted rights notice

This software and related documentation are proprietary to Siemens Product
Lifecycle Management Software Inc.
© 2008 Siemens Product Lifecycle Management Software Inc. All Rights Reserved.
All trademarks belong to their respective holders.

Chapter
1 Getting Started
Understanding the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Administering Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
business_modeler C Business Modeler Help

Chapter
1 Getting Started
This chapter describes the components of the Business Modeler user interface and
also discusses how to perform certain administrative tasks, such as deleting rules
from the database.
Understanding the Interface

Table 1-1 describes the tabs displayed in the Business Modeler interface. Each tab
corresponds to a type of business rule.
Table 1-1. Business Rule Tabs

Tab Purpose
Naming Rules Defines naming conventions for the values of the string
properties associated with various object types. Naming rules
can be attached to the following properties:
• Item ID, item revision ID, and name for any item type
• Dataset name, ID, and revision number for any dataset type
• Name attribute for any form type
• Identifier, project, and work context

Action Rules Defines actions to be performed (precondition, preaction and
postaction) for various Teamcenter operations (Create, Save
As, Delete). Action rules are applied to items, item revisions,
and datasets.
Extension rules have replaced action rules;
therefore, the Business Modeler window does
not display the Action Rules tab by default.
Action rules can be displayed by setting the
BMF_SUPPRESS_ACTION_RULES_DISPLAY
preference. For more information, see the Configuration
Guide.
business_modeler C Business Modeler Help 1-1

Chapter 1 Getting Started
Table 1-1. Business Rule Tabs

Tab Purpose
Deep Copy Defines whether relational objects are copied as objects, copied
Rules as references, or not copied when users perform Save as and
Revise operations.
Deep copy rules are applied only to item revisions.
Compound Defines runtime properties on an object referenced by and
Property Rules related to a property on a source object. Compound property
rules can be applied to any item, item revision, dataset, or
form type.
Generic Defines a rule and affiliates the following constraints with it:
Relationship cardinality, changeability, attachability, and detachability.
Management
(GRM) Rules This module gives you the ability to define canned constraint
behavior for a given relation type without writing code.
Type Display Allows you to limit the types of objects that the entire site,
Rules specific groups, or specific roles in groups, can create. Display
types that have been suppressed cannot be created by the users
specified in the display rule. However, the suppressed object
types are still visible in the interface.
ID Context Rules Determines system behavior when creating alternate and alias
identifiers by combining valid combinations of identifier type,
ID context, and identifiable type. Cardinality rules for alternate
IDs are also created as part of the ID context rule.
Property Rules Allows you to change the following aspects of the behavior of
object properties:
• Modifiability
• Visibility
• Initial value
• Enabled
• Required
• Ability to define complex properties
Extension Rules Allows you to define method extensions and configure them in
to the Teamcenter application.
Refreshing the Rules Display

Occasionally, situations arise that require you to refresh your Business Modeler
window, for example, when a recently created object type is not displayed in the
type tree of the Properties tab. To refresh the display, choose the Refresh option
from the View menu.
1-2 Business Modeler Help business_modeler C

Getting Started
Administering Business Rules

Business rules are created using the tabbed panes in the Business Modeler interface.
Instructions for creating business rules are included in separate chapters later in
this manual. This section describes activities, such as deleting all rules or rules
associated with a specific module, that are not performed in the pane corresponding
to the individual rule type.
You can delete either all business rules in the database or only those corresponding
to a specific rule module using the import_export_business_rules command line
utility. For more information, see the Utilities Reference manual.

Chapter
2 Importing and Exporting

Business Rules
Exporting Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Importing Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Comparing Rule Configurations Using Diff/Merge Tools . . . . . . . . . . . . . . . . . 2-4

XML Diff/Merge Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
XML Diff/Merge Tools With Graphical User Interfaces . . . . . . . . . . . . 2-4
SiberMeld - SiberLogic Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
XML Diff and Merge Tool - IBM Alphaworks . . . . . . . . . . . . . . . . 2-5
XML Diff/Merge Tools With Command Line Interfaces . . . . . . . . . . . . 2-6
DeltaXML Markup - Monsell EDM Ltd . . . . . . . . . . . . . . . . . . . . 2-6
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Chapter
2 Importing and Exporting

Business Rules
This chapter describes the methods available to import and export business rule
configurations for use at multiple sites.
Business rules configurations can be defined at one site and distributed to other
sites. First, configure the business rules, and then export the configuration to an
XML file. This file can then be imported using the Business Modeler import feature
or using the import_export_business_rules command line utility at the receiving
site. For more information, see the Utilities Reference manual.
To avoid overwriting the business rules configuration at the receiving site, export
the current configuration to a separate XML file. This file can then be compared
and/or merged with the new XML file using XML diff/merge tools or the Business
Modeler import comparison feature. The merged XML file can then be imported into
Business Modeler to apply the new rule configuration.
Exporting Business Rules

The Business Modeler export feature allows you to export specific types of rules, for
example naming rules, or to export your entire business rule configuration. When
you access the Export dialog window, the system suggests types of rules to export
based on the tab from which you began the export operation.
To export business rules:
1. Click any rule tab in the Business Modeler window.

The system displays the pane corresponding to the rule module you selected.
2. Click the Export button in the lower-right corner of the pane.

The system displays the Export dialog window with the business rules
corresponding to the active pane selected for export.
3. To export business rules other than those corresponding to the active pane,
check the appropriate box. To export the entire rule configuration, check the All
Business Rules box.

Chapter 2 Importing and Exporting Business Rules
4. Locate the file into which you want to export the business rules. To export the
rules into a new file, enter a name in the File name field. Be sure to append
the .xml extension to the file name.
5. Select the operating system directory into which the XML file is saved.
6. Click the Export button.

The system exports business rules XML file in to the selected operating system
directory.
Importing Business Rules

Business Modeler allows you to import business rules from an XML file and compare
them to your existing rule configuration before importing them in to the database.
To import business rules:
1. Click any rule tab in the Business Modeler window.

The system displays the pane corresponding to the rule module you selected.
2. Click the Import button in the lower-right corner of the pane.

The system displays the Import Rule dialog window.
3. Choose the XML file from which you want to import rules.
Importing business rules overwrites the existing business rule
configuration. Siemens PLM Software strongly recommends exporting
the current configuration and merging it with the XML file that is to be
imported prior to performing the import operation.
4. To compare the existing business rule file against the file being imported, choose
the Compare and Import option. To import without comparing the files, choose
the Import Only option.
5. Click the Import button.

If you choose the Import Only option, the file is imported and the dialog window
closes.
If you choose the Compare and Import option, the system displays the Business
Rule Import Comparison dialog window (figure 2-1).

Importing and Exporting Business Rules
Figure 2-1. Rule Compare Dialog Window
6. To compare the files, choose one of the following comparison options:

• Display as Old/New
Displays your original rule file in the left pane and the file being imported
in the right pane.
• Display as Delta
Displays the delta between the files in a single tree.
• Display Original Only

Displays your original rule file.
• Display New Only

Displays only the new file being imported.
• Merge Add/Chg Comparison

Displays only the added and changed elements.
• Merge Changes Comparison

Displays only the changed elements.
7. Click OK.
The file is imported in to the database.
During import of XML files, a backup of existing rules is created in
$IMAN_TMP_DIR directory. The backup file is created on the machine where
the corporate server is running.

Comparing Rule Configurations Using Diff/Merge Tools

While importing rules using the Business Modeler import feature, it is important
to avoid overwriting the current business rules configuration. To avoid overwriting
the current rule configuration, export the configuration to an XML file, which can
then be compared or merged with the new XML file using an XML diff/merge tool.
The compared/merged XML file can then be imported in to Teamcenter to apply the
new rule configuration. You can also use the Business Modeler import comparison
feature. For more information, see Importing Business Rules, earlier in this chapter.
XML Diff/Merge Tools

The following sections describe the diff/merge tools in descending order of how well
each tool meets the following criteria:
• Availability of GUI access to the tool
• Facility to perform comparison on the document object model (DOM) trees rather
than on the XML file
• Provision for validating the XML files being compared
• Ease of installation and use
• Fewest additional software requirements
• Platform support
The details about each tool include the advantages and disadvantages and other
relevant details, such as software prerequisites, platform support, and links to the
vendor sites.
XML Diff/Merge Tools With Graphical User Interfaces

The tools in this section employ a graphical user interface.
SiberMeld - SiberLogic Inc.

SiberMeld is a tool that understands the hierarchies of structured elements.
Advantages:
• Document object model (DOM) trees are constructed and compared to find the
differences.
• Coordinate expansion of hierarchies in all panes makes it easy to navigate the

hierarchies and focus on the differences between the files.
• Flexible granularity selection.
• Does not require ID attribute for structure discovery.
• Validates XML file structure.

Disadvantages:
• Tool stops responding if the validation of the XML files fails.
• Works only with Java™ Runtime Environment (JRE)1.3.1
Access:
GUI
Software requirements:
JRE 1.3.1
Platform support:
Any platform that supports Java Runtime Environment
Web site:
http://www.siberlogic.com/products_new/sibermeld/
XML Diff and Merge Tool - IBM Alphaworks
XML Diff and Merge Tool is a Java program that can be used for reconciling changes
made by users to an XML document.
Advantages:
• Constructs and compares document object model (DOM) trees to find the
differences between the files.
• Easy to use.
• Validates XML file structure.

Disadvantages:
Tool stops responding if an invalid XML file is encountered.
Access:
Command line, programming, GUI.
Software requirements:
Java SDK 1.2.x or SDK 1.3, XML parser for Java 1.1.4 or above.
Platform support:
AIX, Windows NT, Linux, Windows 2000, Windows XP, and all Java 2 platforms.
Web site:
http://www.alphaworks.ibm.com/tech/xmldiffmerge/

XML Diff/Merge Tools With Command Line Interfaces
DeltaXML Markup - Monsell EDM Ltd
DeltaXML compares any two similar XML files and generates an XML delta file
describing the differences between the two input files.
Advantages:
• Delta file uses a format that clearly represents the differences found in the two
XML files being compared.
• Delta file can also be applied in a way that all deletes are interpreted as adds
and vice versa. This is useful as an undo operation.
• Ignores insignificant differences in white space.
• Ignores comments and processing instructions.
• Understands that XML attributes can be in any order.
Disadvantages:
• Does not validate XML file structure.
• Possibility of errors while automatically merging the differences from one file
in to another.
Access:
Command line.
Requirements:
JRE 1.2.x or later.
Platform support:
Any platform that supports Java Runtime Environment.
Web site:
http://www.deltaxml.com/deltaxml_markup.html

Error Handling
While exporting or importing rules using Business Modeler, you may encounter
errors caused by the BusinessRulesXMLHelper class or the methods of the rules
module classes that support the import and export of rules. Any error that occurs
during the import process causes a reversion to the previous configuration (that is, to
the configuration that existed prior to deleting all the rules).
Table 2-1 describes import/export error messages and actions for resolving them.
Table 2-1. Import/Export Error Messages

Error Message Resolution
Could not get the class name of The particular rule instance could be corrupted.
an instance For more information, see the specific rule
module.
Failed to delete instances The particular rule instance could be corrupted.
For more information, see the specific rule
module.
Failed to create rule instances The particular rule instance could not be created.
The data in the XML file may not be valid for
the particular rules. For more information, see
the specific rule module.
Null value obtained for instance The particular rule instance could be corrupted.
For more information, see the specific rule
module.
There are no rule instances in Currently there are no rules configured in the
the database database to be exported. You must create rules
before you can export them.
The current user does not have Only a user with administrator privileges can
SA Privilege use the XML import/export feature. Ensure that
you have administrator privileges.
The XML platform utilities The XML platform utilities cannot be initialized
could not be initialized if the local code page transcoder is not loaded.
Ensure that the LANG environment variable
is set to C or any other valid encoding codeset
and that the LC_ALL environment variable is
set to NULL.
The XML file could not be Verify that the XML file exists and that you have
validated read access to the file.
The XML file could not be Verify that the
generated. $IMAN_DATA\BusinessRules.dtd file is
not corrupted and that you have read access
to the DTD file.
The XML file could not be Use a well-formed, valid XML file when
parsed/validated importing data. Ensure that the exported rules
file has not been modified.

Table 2-1. Import/Export Error Messages

Error Message Resolution
The XML file contains null The XML file contains invalid characters.
value. Import aborted.

Chapter
3 Naming Rules
Understanding the Impact of Property Inheritance on Naming Rule Behavior . . 3-2

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Defining Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Attaching Naming Rules to Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Deleting Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Defining Naming Rule Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

Using Literal Variables in Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Using Nested Rules in Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Using System Variables in Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Creating Naming Rules With Two Patterns . . . . . . . . . . . . . . . . . . . . . . . 3-15
Using Counters With Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Creating Baseline Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

Chapter
3 Naming Rules
This chapter describes how to use Business Modeler to define naming rules and
patterns and associate them with object properties.
Naming rules allow you to specify valid patterns for applying custom naming
conventions to items, item revisions, identifiers, datasets, forms, projects, and work
contexts. In addition, naming rules can be used to define patterns for automatically
generating IDs (by clicking the Assign button) when creating objects. Naming
rules are attached to object properties. A single rule can be attached to multiple
properties. While a property can have only one attached rule, a single rule can
include multiple patterns.
At present, these rules can be applied only to string properties.
Naming rules can also be created and managed using the apply_naming_rule
utility. For more information, see the Utilities Reference manual.
Table 3-1 describes the item, dataset, form, identifier, project, and work context
properties to which naming rules can be attached and the actions to which naming
rules apply.
Dataset naming patterns used in conjunction with the Save As option are
implemented using the DATASET_saveas_pattern preference. For more
information, see the Configuration Guide.
Table 3-1. Properties Subject to Naming Rules

Object Property Name Create Modify
Item Item ID X X
Item revision ID X X
Name X X
Baseline suffix X
Identifier ID X X
Baseline suffix

Chapter 3 Naming Rules
Table 3-1. Properties Subject to Naming Rules

Object Property Name Create Modify
Dataset Dataset ID X X
Name X
Revision number X
Form Name X X
Project Project ID X X
Project name X X
Work context Work context name X X
Understanding the Impact of Property Inheritance on Naming Rule

Behavior
Properties that are added to an object type are automatically inherited by all
subtypes of the parent type. Conversely, properties removed from a parent type
are automatically removed from all subtypes. Because naming rules define valid
patterns for the values of properties associated with various object types, they too
are subject to the principles of inheritance.
Naming rules are evaluated as follows:
If a naming rule exists for the type, it is applied. Otherwise, the hierarchy is
ascended until a rule is located or the top-level parent is reached.
Example
This example assumes that for the Item class a type, Document, exists. In addition,
a subtype of the Document type, MyDoc, exists. Naming rules are applied to the
properties of these object classes/types/subtypes, as show in table 3-2.
Table 3-2. Naming Rules

Class/Type/Subtype Property Naming Rule Applied
Item item_id RuleA
name RuleB
item_revision_id None
Document item_revision_id RuleC
MyDoc name RuleD

Naming Rules
With these rules established, rules are applied accordingly when a user performs the
following actions:
• Creates a new item of type Item.
The item ID and name for the new Item are derived using naming rules RuleA
and RuleB (table 3-2), which are attached directly to the top-level Item type.
• Creates a new item of type Document.

The item ID and name are derived using naming rules RuleA and RuleB, which
are inherited from the Item type. The item revision ID is derived using naming
rule RuleC, which is attached directly to the Document type.
• Creates a new item of type MyDoc.

The item ID is derived using naming rule RuleA, which is inherited from the
Item type. The item revision ID is derived using naming rule RuleC, which is
inherited from the Document item type, and the name is derived using RuleD,
which is attached directly to the MyDoc subtype.
Applying Naming Rules to Identifiers and Identifier Revisions

The Identifier class uses pairs of identifier-name and identifier-nameRev types.
Alternate identifiers of the identifier-name type are item-level masters. Alternate
identifiers of the identifier-nameRev type are revision-level supplements to the
item-level master.
Naming rules on the ID property of a master identifier type are automatically
inherited by the ID property of the supplemental revision-level identifier type.
Therefore, unless a separate naming rule is defined for the revision-level identifier,
the ID properties of both the master and the revision-level type use the same naming
rule, which results in the sequence counter for the identifier revision-level IDs being
increased each time a revision is created, as shown in the following example:
CAAA00011-CORP1048 (Item)
CAAA00011 (Item Master)
ALT-AAA00009@Evaluat-Nozzle EVA (Identifier)
ALT-AAA00017@Evaluat-jojojo (Identifier)
CAAA00011/A-CORP1048 (Item Revision)
CAAA00011/A (Item Revision Master)
ALT-AAA00009/ALT-AAA00010@Evaluat-Nozzle EVA IdentifierRev
ALT-AAA00017/ALT-AAA00018@Evaluat-jojojo IdentifierRev
To prevent this behavior, you must define a separate revision naming rule on the ID
property of supplemental revision-level identifier types, as follows:
1. Define a naming rule, for example, MyRule1, that generates the counter and
attach it to the ID property of the identifier.
2. Define another naming rule, for example, MyRule2, that is identical to

MyRule1 and attach it to the ID property of the identifier revision.
The alternate ID is generated and the counter is incremented as follows:
000/000@Master-1
001/000@Master-1
002/000@Master-1
003/000@Master-1

Defining Naming Rules

The process of defining naming rules includes creating the rule, defining valid
patterns for the rule, and optionally, enabling counters that allow automatic
generation of object ID and/or revision when creating items, item revisions, and
identifiers. Once created, the rule can be assigned to the property of an object type.
To create and add patterns to a naming rule:
1. Click the Naming Rules tab.

The system displays the naming rules window.
2. Click the Edit Naming Rules tab.

The system displays the pane used to create and modify naming rules.
3. Enter a name for the rule in the Rule Name field.
4. Click the Create button to the right of the Rule Name field.
The system creates the rule in the database.
5. Add a pattern to the naming rule by performing the following steps:
a. Click the Add button to the right of the pattern display area.
The system displays the Add Rule Pattern dialog window.
b. Specify the pattern by manually entering text in the blank pattern field or
by selecting a List of Values (LOV) or rule as the basis for the pattern.
For more information about patterns, see Defining Naming Rule

Patterns, later in this chapter.
c. Click OK.
The system displays the pattern in the display area and closes the Add Rule
Pattern dialog window.
d. Add additional patterns, as desired, by repeating steps a through c.
6. Optionally, check the Generate Counters box.

The Generate Counters option enables the Assign button that allows users to
automatically assign object ID and revision ID values when creating items, item
revisions, and identifiers in Teamcenter.
The system activates the Initial Value and Maximum Value fields.
7. Optionally, enter the values at which the counter would begin and end in the
Initial Value and Maximum Value fields.
8. Click Save to associate the patterns and counter values with the rule.

Naming Rules
To remove a pattern from a naming rule:


3. Choose the rule from the Rule Name list.

The system displays the patterns associated with the selected rule in the pattern
display area.
4. Select the pattern from the list of patterns.
5. Click the Remove button to the right of the pattern display area.
The system removes the pattern from the list.
6. Click Save to save the modified pattern list.
To modify a pattern in a naming rule:



The system displays the patterns associated with the selected list in the pattern
display area.
4. Select the pattern from the list of patterns.
5. Click the Modify button to the right of the pattern display area.
The system displays the Add Rule Pattern dialog window.
6. Modify the pattern values, as required.
For more information about patterns, see Defining Naming Rule Patterns,
later in this chapter.
7. Click OK.
The system closes the Add Rule Pattern dialog window.
8. Click Save to save the modifications to the database.

To delete a naming rule:

The system displays the naming rules tabs.


The system displays the patterns associated with the selected list in the pattern
display area.
Before deleting the rule, ensure that it is not attached to any object
properties.
4. Click the Delete button to the right of the Rule Name list.
The system displays a confirmation dialog window.
5. Click Yes to delete the rule or No to cancel the deletion.

Naming Rules
Attaching Naming Rules to Properties

Once a naming rule is defined, it can be attached to one or more object properties.
You can attach only one rule to each property; however, each naming rule can be
comprised of multiple patterns. Multiple patterns allow object properties to have
several different naming patterns and also provide a mechanism for recursive
patterns.
In addition, subtype objects inherit the naming rules that are assigned to the
properties of their parent type objects. When attaching naming rules, you can retain
the inherited rules or remove them from a specific subtype. For more information,
see Understanding the Impact of Property Inheritance on Naming Rule Behavior,
earlier in this chapter.
For a list of the properties to which naming rules can be attached, see table 3-1,
To attach a naming rule to an object property:

2. Click the Attach Naming Rules tab.

The system displays the objects to which naming rules can be associated in the
left pane of the window. In the right pane, the system displays the list of rule
names and case sensitivity options.
3. Select the object type or subtype to which you want to attach the naming rule by
expanding the Naming Rules tree and clicking the object node.
The system displays the selected object type and the properties that are subject
to naming rules in the lower-left pane of the window.
4. Select the property from the tree in the lower-left pane.
5. Choose one of the following type case options:

• Mix
Specifies that values entered by the user for the selected property are
retained in the form in which they are entered.
• Upper
converted to uppercase.
• Lower
converted to lowercase.
6. Choose a naming rule from the Rule Name list.

The system displays the naming rule, including associated patterns and counters.
7. Verify that this is the rule that you want to attach to the property, and click
the Attach button.

To detach a naming rule from an object property:

2. Click the Attach Naming Rules tab.

The system displays the objects to which naming rules can be associated in the
left pane of the window. In the right pane, the system displays the list of rule
names and case sensitivity options.
3. Select the object type or subtype from which you want to detach the naming rule
by navigating the Naming Rules tree and clicking the object node.
The system displays the selected object type and the properties that are subject
to naming rules in the lower-left pane of the window.
4. Select the property from the tree in the lower-left pane.

The system displays the naming rule attached to the property in the right pane
of the window.
The naming rule displayed for a subtype object may be inherited from a
parent type rather than being assigned directly to the subtype. Detaching
a rule from a parent type also detaches the rule from the subtypes by
which it is inherited.
5. Choose the blank value in the Rule Name list.

The system removes the rule pattern from the display area and activates the
Attach button.
6. Click the Attach button.

The system detaches the rule from the object property. In addition, the rule is
also detached from the properties of any subtypes of the selected object type. If
the selected type is a subtype and the rule was attached to an inherited property,
the rule is removed only from that subtype but is not from the parent type.
Deleting Naming Rules

The naming rule to be deleted should not be attached to any object properties.
1. Select the rule name to be deleted in the combo box.
2. Click the Delete button.
For information on deleting all naming rules, see To delete a naming rule:, earlier in
this chapter.

Naming Rules
Defining Naming Rule Patterns

Naming rule patterns can be composed of literal strings of characters, lists of
patterns using Lists of Values (LOVs) as literal variables, and pattern variables
composed of existing naming rules. Naming rules are considered pattern variables.
For more information about using pattern variables, see Using Nested Rules in
Patterns, later in this chapter.
Lists of values are literal variables and must be enclosed in double quotation
marks (").
Each pattern can consist of combinations of the characters shown in table 3-3.
Table 3-3. Valid Characters for Patterns

Character Pattern Match
& Alphanumeric value.
X Uppercase alphanumeric value.
x Lowercase alphanumeric value.
N Numeric value.
n Numeric value.
@ Alphabetic value.
A Uppercase alphabetic value.
a Lowercase alphabetic value.
“string” String delimiters.

? Any single character value.
\ Escape the next character to have a literal
meaning.
This character is only required when using
delimiters inside of other delimiters, for example,
“A\”Special\”Name”, which matches [A
“Special” Name].
If you do not use the back slash (\) it is
not possible to include delimiters as part
of a name. The same is true of braces ({ })
and brackets ([ ]). For example, the pattern
{RULE:Test\$Now\{a\}${ROLE}}, applied to a user
whose current role is Designer, would look for the
following definition: Test$Now{a}Designer.


${system-variable} Substitutes the value of a Teamcenter system
variable.
System variables are normally used in
double quotation marks. However, it is
possible that a preference value can be a
pattern rather than a literal.
The following values are valid for system variable:

GROUP User’s current group.
ROLE User’s current role.
USERID User’s ID.
USERNAME User’s name
SITENAME Site name
All:pref Specifies a preference variable.
GROUP:pref Specifies a group preference
variable.
ROLE:pref Specifies a role preference
variable.
SITE:pref Specifies a site preference
variable.
USER:pref Specifies a user preference.
{variable-type:variable-name} Literal variable delimiters {Type:Name}
Values in the list are treated as quoted strings.
The following values are valid for variable type:
LOV Lists of Values
RULE NAME_Rules
[variable-type:pattern-name] Pattern variable delimiters [Type:Name]
Values in the list are treated as patterns. The
following values are valid for variable type:
LOV Lists of Values
RULE NAME_Rules

Naming Rules

Regular expressions The regular expression delimiter allows names
to be validated, not generated, using standard
regular expressions. This delimiter cannot be
used in a pattern that automatically generates
counters. The regular expression delimiter is %,
which indicates that the rest of the pattern is a
regular expression.
For example, the pattern for an item ID with two
uppercase alphabetic characters followed by one
digit would be AAn. However, if the digit was
not allowed to be zero, a the following regular
expression could be used: AA%^[1-9]$.

Using Literal Variables in Patterns

To illustrate the use of literal variables, assume that the naming convention for
a particular type of dataset requires a 3-character suffix, either ENG or MFG,
followed by a 4-digit number ranging from 0000 to 9999.
To establish this pattern, a List of Values (LOV) named Context is created
containing the values ENG and MFG. (For more information about creating Lists of
Values, see List of Values Help.) A naming rule is then created and the Naming Rule
Pattern Editor is used to create the pattern using the LOV and numeric characters.
The pattern would appear as follows:
{LOV:Context}nnnn
The naming rule is then attached to the name property of the dataset type.
Literal variables cannot be used in patterns used to autogenerate counters.
Using Nested Rules in Patterns

Naming rules are considered pattern variables when they are nested within
other naming rules. Pattern variables cannot be used in rules that auto
generate counters.
The naming rules in this example, IntegerNum and RealNum, work together to
define a number field with a required decimal point.
The pattern goes beyond 9 to 10, because the IntegerNum rule (figure 3-1) contains
two patterns, one of which refers to the IntegerNum rule itself, allowing 1 or more
digits.
Figure 3-1. IntegerNum Naming Rule

Naming Rules
Figure 3-2. RealNum Naming Rule

The RealNum rule (figure 3-2) refers to the IntegerNum rule twice, with a decimal
point enclosed in double quotation marks (".") between the references.
The IntegerNum rule has two patterns:
n
n[RULE:IntegerNum]
When these patterns are evaluated against the id string 23.456, it nests through
the patterns as follows:
Nest Match
Level Matching Pattern Prefix ID String
1 [RULE:IntegerNum]"."[RULE:IntegerNum] Yes 23.456
2 n"."[RULE:IntegerNum] No 23.456
2 n[RULE:IntegerNum]"."[RULE:IntegerNum] Yes 23.456
3 n"."[RULE:IntegerNum] Yes 3.456
4 n No 456
4 n[RULE:IntegerNum] Yes 456
5 n No 56
5 n[RULE:IntegerNum] Yes 56
6 n Yes 6

Using System Variables in Patterns

This example illustrates how system variables are used in patterns in the naming
rule for the form type CMSForm.
System variables are typically used in strings or in rule names, and are delimited
with dollar signs ($) and braces ({}) characters, as shown in figure 3-3.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE BusinessRules PUBLIC "teamcenterdata" "BusinessRules.dtd">

<BusinessRules>
<NameRuleGroup>
<NameRule object_desc="NR:TestCMSForm">
<rule_name><![CDATA[TestCMSForm]]></rule_name>
<pattern><![CDATA["${ROLE}"]]></pattern>
<pattern><![CDATA["${GROUP}"]]></pattern>
<pattern><![CDATA["${USERID}"]]></pattern>
<pattern><![CDATA["${USERNAME}"]]></pattern>
<pattern><![CDATA["${SITENAME}"]]></pattern>
<pattern><![CDATA["${ALL:XXX}1"]]></pattern>
<pattern><![CDATA[An{RULE:TestRole${ROLE}Pat}]]></pattern>
</NameRule>
<NameRule object_desc="NR:TestRoledbaPat">
<rule_name><![CDATA[TestRoledbaPat]]></rule_name>
<pattern><![CDATA[A]]></pattern>
<pattern><![CDATA[B]]></pattern>
</NameRule>
<NameRule object_desc="NR:TestRoletestPat">
<rule_name><![CDATA[TestRoletestPat]]></rule_name>
<pattern><![CDATA[C]]></pattern>
<pattern><![CDATA[D]]></pattern>
</NameRule>
</NameRuleGroup>
<NameFieldGroup>
<NameField case="Mixed" object_desc="NF:CMSForm.object_name">
<type_name><![CDATA[CMSForm]]></type_name>
<property_name><![CDATA[object_name]]></property_name>
<rule_name><![CDATA[TestCMSForm]]></rule_name>
</NameField>
</NameFieldGroup>
</BusinessRules>
Figure 3-3. Example of Naming Rule Pattern Using System Variables

Naming Rules
If the user’s current session has these values, the form name can be as shown
in table 3-4.
Table 3-4. Form Name Based on System Variables

Variable and
value used Form Name From patterns
Role=Test Test "${ROLE}"
Group=test test "${GROUP}"
Userid=infodba infodba "${USERID}"
Username=System System Admin "${USERNAME}"
Admin
Sitename=MySite MySite "${SITENAME}"
Preference variable A1 "{ALL:XXX}1"
XXX=A
A1C An{RULE:TestRole${ROLE}Pat}
The preceding example shows how the pattern can vary based on the user’s role. If
the user’s current role is dba, the pattern changes from:
An{RULE:TestRole${ROLE}Pat}
to the following, which refers to the patterns from the rule named TestRoledbaPat:
An{RULE:TestRoledbaPat}
The example in table 3-4 uses a fictitious site preference called XXX. Any preference
or environment variable can be used.
Creating Naming Rules With Two Patterns

This example illustrates a naming rule that must match one of the following
patterns to be considered valid:
"CORP-"nnn"-P-"AA
NONCORP"nnnn”
In figure 3-4, the first pattern, "CORP-"nnn"-P-"AA, is the only one used to generate
counters. The second pattern allows a user to enter an alternate ID.
Figure 3-4. Naming Rule With Two Patterns

Using Counters With Naming Rules

Only one pattern in a naming rule, the first pattern, is used with counters. Other
patterns in the rule are used for validation but not for automatically generating
the ID.
Any number of counters can be used in a pattern, for example nnn"."a. With
counters activated for this pattern, the Assign button would allocate IDs as follows:
000.a
000.b
000.c
.
.
.
000.z
The right-side counter range completes first and then moves to the next range from
the right, as follows:
001.a
002.a
003.a

Naming Rules
Creating Baseline Naming Rules

In this example, a naming rule is created for items of type Item, as follows:
Item Rule
A Released Rev
A.001 PDI
A.002 PDI
A.003 PDI
B Released Rev
B.001 PDI
B.002 PDI
C Working Rev
To establish this rule, perform the following steps:

1. Using Type, create an item type called ItemPDR.
For more information about creating item types, see Type Help.
2. Create a naming rule called Baseline rev rule (any name can be used) with
the following pattern:
"."NNN
3. Attach the Baseline rev rule to the baseline suffix property on the ItemPDR
item type.

Chapter
4 Action Rules
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Prepackaged Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Creating Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Checking for Latest Released . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Copying Variant Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Understanding the Implications of the autoAssignToProject Method on Project
Propagation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Creating Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Chapter
4 Action Rules
This chapter describes how to administer rules that define actions (precondition,
preaction, and postaction) that are performed in conjunction with a specific operation.
Overview
Action rule functionality is no longer displayed in the rich client interface
by default, but can be enabled via user preference. Action rules are being
replaced by extension rule functionality. For more information about
converting action rules to extension rules, see chapter 11, Extension Rules.
Action rules define actions to be performed in different phases (precondition,

preaction, and postaction) for different operations (such as create, save as, and
delete). These rules are applied to items, item revisions, and datasets.
Teamcenter allows you to apply predefined methods on objects in order to extend the
Teamcenter data model. These predefined methods are part of the baseTeamcenter
product. Business Modeler helps you configure canned methods for items and item
revisions.
Prepackaged methods allow you to change the behavior of item, item revision, and
dataset types without writing custom code. Once the types are configured with
prepackaged methods, the configuration information is stored and can be easily
distributed to other sites.
Before using this module, you must first configure the prepackaged methods.
For more information, see the Integration Toolkit Programmer’s Guide. Once
method configuration is complete, the canned methods can be executed from
any user interface.
Prepackaged methods can be implemented without impact to functionality provided

by existing written methods.

Chapter 4 Action Rules
Prepackaged Methods
The following prepackaged methods are available when configuring action rules in
Business Modeler:
• createObjects
• checkLatestReleased
• copyVariantExpr
• autoAssignToProject
Creating Objects
createObjects is a canned method that creates objects while creating a new
item or item revision. This method is a postaction for ITEM_create_msg and
ITEM_create_rev_msg messages.
This method is ignored if the current logged-in user’s group is system
administrator and the IMAN_BYPASS_CANNED_METHODS environment
is set to either ALL or to the name of this canned method (as stored in
database, such as createObjects).
For Item/ItemRevision types where this method is configured on creation, the

objects mentioned during configuration are created and attached to the parent
item/item revision with relations mentioned at configuration time. The configuration
of the method is done from Business Modeler.
This canned method is also made available for the dataset on create message.
The name of the new objects created is the one based on the USER_EXIT for name
creation (such as for objects where this available), or the parent object name.
For example, if a dataset needs to be created along with an item, the USER
EXIT to create a new dataset name is used. But if the object to be created
does not have a USER EXIT to create the name, the name of the object is
the same as the parent object name.
The information required during configuration is the object type to create and the
relation with which it should be attached to the parent object (that is, the item or
item revision for which this canned method is configured).
At configuration, the dataset, form, and folder types are displayed based on Saved
Query_METHOD_CM_objectTypes, and the relation types is displayed based on
Saved Query_METHOD_CM_relationTypes.

Action Rules
Checking for Latest Released

checkLatestReleased is a canned method that checks whether the latest revision
of an item is released, before creating a new revision. This method is a precondition
for the ITEM_create_rev_msg message for the ItemRevision type against which
it is configured.
administrator, and the IMAN_BYPASS_CANNED_METHODS environment
database, that is, checkLatestReleased).
If the logged in user’s group is set to something other than
checkLatestReleased, this method checks for the existence of not more than
a predefined (through configuration) number of revisions without a release
status.
The creation of a new item revision is stopped and an error message is
displayed if the number of revisions without status is equal to, or more than
the predefined number.
Copying Variant Expressions

copyVariantExpr is a canned method that copies forward variant information,
such as option, option defaults, and rule checks from the source item revision to
the target item revision. It does not copy forward the variant information, such
as variant conditions at the occurrence level. This method is a postaction for the
ITEM_copy_rev_msg message.
administrator, and the IMAN_BYPASS_CANNED_METHODS environment
database such as copyVariantExpression),
On execution, this method sets the new revision’s variant to the one corresponding to
the source revision. This method does not modify the expression block, and it only
sets the new revision’s variant based on the source revisions variant.
autoAssignToProject automatically assigns the selected workspace object to the
user’s current project, as defined by the work context or user settings.
If a current project is not specified for the user, this method is ignored
and the object is not automatically assigned. In addition, when the
autoAssignToProject method is implemented, the Project Name field on the
New Item dialog window in My Navigator is grayed out.

Table 4-1 describes the types, operations, and actions for which the
autoAssignToProject method is valid.
Table 4-1. Valid Configurations for autoAssignToProject

Type Operation Action
Item and all subtypes Create Post-Action
of item
Item revision and Revise Post-Action
all subtypes of item
revision Save As To Existing
Item
Create BaseLine
Revision
Deep Copy
Create Revision
Dataset and all Save Post-Action
subtypes of dataset
Form and all subtypes Save Post-Action
of form

Action Rules
Understanding the Implications of the autoAssignToProject Method

on Project Propagation Rules
Configuring the autoAssignToProject method for an object type has implications
on the project propagation rules. Project propagation rules determine which
secondary objects are assigned to a project when a primary object type is assigned.
(For more information, see My Navigator Help.) When there is a conflict between a
propagation rule and the execution of the autoAssignToProject method, the method
takes precedence.
Consider the following points when implementing the autoAssignToProject method:
• The autoAssignToProject method applies only to newly created objects; whereas,
propagation of related objects to projects occurs whenever a relation between two
objects is created, modified, or deleted.
• The autoAssignToProject method explicitly assigns objects to projects; therefore,

the objects can only be removed from the project by explicitly selecting the object
and using the Project→Remove option in one of the Teamcenter applications.
• Propagation rules implicitly assign secondary objects to projects. Therefore,

when the primary object is explicitly removed from the project, the secondary
object is also removed from the project.
The scenarios described in table 4-2 illustrate the relationship between action rules
and propagation rules when assigning objects to projects.
Table 4-2. Examples of Action and Propagation Rule Behavior

Scenario Project Assignment Behavior
The autoAssignToProject method Both objects are automatically assigned to
is configured for types P (primary the current project, regardless of whether
object) and types S (secondary the IMAN_requirement relation is
object). A user creates an object specified in the propagation rule list.
of type P and an object of type S
related by the IMAN_requirement
relation.
The autoAssignToProject method The object of type P is automatically
is configured for types P (primary assigned to the current project based on
object), but not for types S (secondary the autoAssignToProject method. If the
object). A user creates an object IMAN_requirement relation is specified
of type P and an object of type S in the propagation rule list, the type S
related by the IMAN_requirement object is also assigned to the project. If
relation. the IMAN_requirement relation is not
specified in the propagation rule list, the
secondary object is not assigned to the
project.

Table 4-2. Examples of Action and Propagation Rule Behavior

The autoAssignToProject Both the primary and secondary object are
method is configured for types automatically assigned to the project based
P (primary object) and types S on the configuration of the method rule,
(secondary object). In addition, the resulting in an explicit assignment rather
IMAN_requirement relation is than the implicit assignment that occurs
defined as a propagation rule. The when an object is assigned to a project based
user creates an object of type P and on propagation rules.
an object of type S. After creating
the objects, the user attaches the
secondary object to the primary
object using the IMAN_requirement
relationship.
Creating Action Rules

To create an action rule, perform the following steps:
1. Click the Action Rules tab.
The system displays the Action Rules pane.
2. Expand the Action Rules tree and expand the object type for the action rule.
The system displays the actions available for the selected type.
3. Expand the node corresponding to the action for which you want to establish
the rule.
The system displays the operational phases associated with the action:
Pre-Condition, Pre-Action and Post-Action.
4. Expand the phase node.

The system displays the methods available for the combination of phase, action,
and object type.
5. Check the box corresponding to the method, for example, autoAssignToProject.

The system displays a description of the method in the right pane of the Action
Rules window. The Do you want to apply this canned method option is selected
by default.
6. Click Apply to apply the action rule.

Chapter
5 Deep Copy Rules
Understanding the Impact of Inheritance on Deep Copy Rule Behavior . . . . . . 5-1
Managing Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Creating, Modifying, and Deleting Deep Copy Rules . . . . . . . . . . . . . . . . . 5-3
Deep Copy Rules for Secondary Datasets . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Example: Copy as Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Restrictions on the Use of Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

Chapter
5 Deep Copy Rules
This chapter describes the administration of deep copy rules. Deep copy rules
determine which related objects are copied forward when you save a new object
based on an existing object or create a new revision of an existing object.
Deep copy rules provide a method to specify the combination of objects types and
the relationships between primary and secondary objects that define which objects
are copied from one revision to the next. Deep copy rules take the following form in
the site preference file:
Relation-Type:Object-Type:true/false
The relation type is the type of relationship by which an object, such as a dataset,
form, or folder, is related to an item revision. The true and false values indicate
whether or not the rule can be overridden by a user. true indicates that the user
cannot override the behavior imposed by the deep copy rule. false indicates that a
user can override the behavior of the rule.
Deep copy rules are used in conjunction with the creation of item and item
revisions using the Save As and Revise menu options. For more information,
see My Navigator Help.
Understanding the Impact of Inheritance on Deep Copy Rule Behavior

Deep copy rules defined for a parent object type are automatically inherited by all
subtypes of the parent type. Conversely, deep copy rules removed from a parent type
are automatically removed from all subtypes.
Deep copy rules are evaluated as follows:
If a deep copy rule exists for the type, it is applied. Otherwise, the hierarchy is
ascended until a rule is located or the top-level parent is reached.

Chapter 5 Deep Copy Rules
Example
This example assumes the existence of a hierarchy in which the MyDRevision
type is a subtype of the MyDocRevision type, which in turn is a subtype of the
DocumentRevision type which is a child type of the ItemRevision class.
Deep copy rules are applied to the Revise action of the object classes/types/subtypes,
as show in table 5-1.
Table 5-1. Deep Copy Rules

Class/Type/Subtype Copy Option Deep Copy Rule Applied
DocumentRevision Copy As Object RuleA
Copy As Reference None
Don’t Copy RuleB
MyDocRevision Copy As Object None
Copy As Reference RuleC
Don’t Copy None
MyDRevision Copy As Object None
Copy As Reference None
Don’t Copy RuleD
With these rules established, a user performs the following actions and the rules
are applied accordingly:
• Revises a document item of type DocumentRevision.
The related objects are copied forward as specified in the definition of
RuleA, but the related objects as specified in the definition of RuleB are not
copied, as RuleB uses the Don’t Copy option. Both rules are defined for the
DocumentRevision parent type.
There are no inherited rules in this example.
• Revises a document item of type MyDocRevision.

The related objects are copied forward as specified in the definition of RuleA and
RuleC, but the related objects as specified in the definition of RuleB are not
copied. RuleA and RuleB are inherited from the DocumentRevision parent
type. RuleC is defined against the MyDocRevision subtype.
• Revises a document item of type MyDRevision.

The related objects are copied forward as specified in the definitions of RuleA
and RuleC, but the related objects as specified in the definition of RuleD are
not copied. RuleA and RuleC are inherited from the DocumentRevision and
MyDocRevision types, respectively. Although a Don’t Copy rule is defined for
the DocumentRevision parent type, it is not applied to this example, because a
Don’t Copy rule is defined explicitly for the MyDRevision subtype.

Deep Copy Rules
Managing Deep Copy Rules

This section describes the basic steps to create, modify, and delete deep copy rules
and also provides examples of rules applying specific deep copy behaviors.
Creating, Modifying, and Deleting Deep Copy Rules

To create a deep copy rule:
1. Click the Deep Copy Rules tab.
The system displays the Deep Copy Rules tree.
2. Choose the item revision type or subtype to which you want to apply a deep
copy rule.
The system displays the selected item revision type and associated operations
for which deep copy rules can be defined in the lower-left pane of the Deep Copy
Rules pane.
3. Choose the operation for which the deep copy rule will be applied, either SaveAs
or Revise.
The system displays the rule definition options in the right pane.
4. Optionally, check the Required checkbox. When this option is chosen, the
behavior implemented by the deep copy rule cannot be overridden by users.
You can override the required status for individual rules by clearing the
check box next to the rule.
5. Choose a relation type from the Relation Types list.
6. Choose an object type from the Object Types list.

The relation type and object type define which objects are copied forward
when an item revision is saved as a new item revision or revised to a new
revision level. Only those object types attached to the item revision by the
specified relation type are copied forward.
7. Define the behavior of the object when copied forward by clicking the Add button
to the right of one of the following copy option fields:
Copy Option Description

Copy As Object Creates a new object of the same type and
relation as the source item revision. Objects
created by this method are totally independent
of the source object. Therefore, modifications
to the new object are not reflected in the
source object.
When defining attached data as part of the
Save As or Revise process in My Navigator,
the names of objects copied as new objects are
displayed in bold text in the Destination tree.

Copy Option Description

Copy As Reference Copies forward the related object but
maintains a reference to the source object.
Therefore, modifications performed on the
copied object are propagated to the source
object.
the names of objects copied as reference are
displayed in italicized text in the Destination
tree.
Don’t Copy Specifies that objects of the selected type and
relation are not copied forward to the new
object during the Save As or Revise operation.
the names of objects that are not copied are
stricken in the Destination tree.
To delete a defined rule:

2. Choose the item revision type from the tree.

Rules pane.
3. Choose the operation from which the deep copy rule will be deleted, either
SaveAs or Revise.
4. Choose a rule in either the Copy As Object, Copy As Reference, or Don’t Copy
field.
5. Click the Remove button to the right of the field.

The system removes the rule.
6. Click Apply.
The system deletes the rule from the database.
To modify a deep copy rule:

2. Choose the item revision type associated with the deep copy rule that you want
to modify.

Deep Copy Rules
Rules pane.
3. Choose the operation for which the deep copy rule will be modified, either
SaveAs or Revise.
4. Choose the rule to be modified in either the Copy As Object, Copy As Reference,
or Don’t Copy field.
5. Optionally, choose a new relation and/or object type from the Relation Types
or Object Types lists.
6. Optionally, check the Required box to define the rule as one that cannot be
overridden by users.
7. Click the Modify button to the right of the selected rule.

The system displays the modifications to the rule.
8. Click Apply.
The system saves the modified rule in the database.

Deep Copy Rules for Secondary Datasets

In addition to establishing rules to copy forward primary datasets that are associated
with a specific item revision type, you can also choose to copy forward secondary
datasets (those datasets that are attached to a primary dataset through a relation
type) to newly created item revisions.
Deep copy rules for primary datasets are created using the process described
in Creating, Modifying, and Deleting Deep Copy Rules, earlier in this chapter.
Deep copy rules for secondary datasets are established by defining values for the
TC_dataset_deep_copy_rules site preference. (For information about setting
preferences, see My Navigator Help.) You can use this preference to copy forward
any or all secondary datasets.
Secondary datasets can only be copied one level deep in the dataset hierarchy.
The default settings for the TC_dataset_deep_copy_rules preference enable

copying of the following secondary dataset types:
• DirectModel datasets connected to the UGMASTER dataset type by the
Rendering relation.
• DirectModel datasets connected to the UGPART dataset type by the

Rendering relation.
• DirectModel datasets connected to the UGALTREP dataset type by the

Rendering relation.
• NXDerived datasets connected to the DirectModel dataset type by the

TC_Derived relation.
You can enable deep copy for other types of secondary datasets by specifying the
primary dataset type, secondary dataset type, and relation type as values for the
TC_dataset_deep_copy_rules preference, in the following format:
primary-dataset-type:relation-type:secondary-dataset-type
For more information about the TC_dataset_deep_copy_rules preference, see

the Configuration Guide.

Deep Copy Rules
Example: Copy as Objects

This example assumes that an item revision of type Document has a UGMASTER
dataset attached to it by a Specification relation. Perform the following steps
to establish a deep copy rule that copies forward all UGMASTER datasets as
independent objects when the Save As operation is performed on the Document
item revision:
2. Choose the Document item revision type from the tree.

The system displays the selected Document item revision type and associated
operations for which deep copy rules can be defined in the lower-left pane of the
Deep Copy Rules pane.
3. Choose the Save As node.

4. Choose Specification from the Relation Types list.
5. Chose UGMASTER from the Object Type list.

To set the Copy As Objects rule, click the Add button adjacent to the Copy As
Object window. Note the buttons of the other copy options are also activated,
allowing you to specify other options.
6. Optionally, check the Required option. This option allows you to determine
whether the deep copy rule behavior can be overridden by users.
7. Click the Add button to the right of the Copy As Object field.
The system displays the rule in the Copy As Object field.
8. Click Apply.
The rule is saved in the database.

Restrictions on the Use of Deep Copy Rules

The following general restrictions apply to the use of deep copy rules:
• You must have dba privileges to manage deep copy rules.
• Objects attached to the item revision by the IMAN_reference relation can only
be subject to Copy As Reference or Don’t Copy rules. Reference attachments
cannot be copied forward as new objects.
• Once a rule has been defined for an object type, it cannot be duplicated using
other copy options. For example, if a rule has been defined to copy forward
UGMASTER datasets attached to a specific source item revision type by the
IMAN_specification when the Save As operation is performed on the item
revision, you cannot define a rule on the same object type/operation combination
to use a different copy option.

Chapter
6 Compound Property Rules
What Is a Compound Property? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Managing Compound Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Chapter
6 Compound Property Rules
This chapter describes compound property rules and how they are administered
using Business Modeler.
Each Teamcenter object type has a set of predefined properties and associated
properties. Depending on the business and process requirements of your company,
properties may need to be defined for the object types. Runtime properties
functionality allows you to add new properties to types; however, adding and
registering new properties using this method requires writing custom code.
Compound property rules allow you to add new properties to object types without
writing custom code and without using runtime properties.
Although compound property rules provide an alternative to runtime
properties for adding new properties to types, they are not a replacement for
the runtime properties functionality.
What Is a Compound Property?

A compound property is a property that can be displayed for one object (the display
object) although it is defined and resides on a different object (the source object).
The display object and source object are related by one or more Teamcenter relations
and reference properties. The relationship between the display object and source
object can be either a reference relation, a GRM relation, or a combination of the
two. Compound properties behave as a property of the display object type.
Characteristics of Compound Properties

A compound property on an object displays the following characteristics:
• Default SET and ASK methods.
• The property inherits access rules from the source object.
• The protection (read/write permissions) of a compound property on the display

object is the same as that of the source object. You can modify the protection of
the compound property from the display object.
• If the source property is modifiable, the compound property is also modifiable.

However, if a ReadOnly flag is set on the compound property rule, the compound
property is a non-modifiable property even if the source property is modifiable.

Chapter 6 Compound Property Rules
• The compound property appears disabled on the display object if the property
on the source object is not modifiable.
• If the property on the source object is not readable, an error message is displayed.
• The name of a compound property and the UI display name can be different from
the property name and property UI display name on the source object.
• The value type of a compound property is the same as that of its source property.
For example, if the value type of the source property is PROP_string, the value
type of the compound property is also PROP_string.
• If the source property is a variable length array (VLA) the compound property is
also a VLA.
• If a list of values (LOV) is attached to the source property, the same LOV is
attached to the compound property.
• If the user does not have write privileges to the object on which the compound
property exists, the compound property is not modifiable.
• If the user does not have write privileges to the object on which the source
property exists, the user cannot modify the value of the compound property.
• To obtain the values of the compound property, the system traverses the object
hierarchy specified in the compound property rule. If the system fails to reach
the source property while traversing the object hierarchy, the value of the
compound property cannot be retrieved and an error message is displayed. The
value is displayed as a blank field in the rich client.
Managing Compound Property Rules

The Compound Property Rules module of Business Modeler allows you to add,
modify, or delete compound property rules, which enables you to add new properties
to Teamcenter types without writing custom code.
The Add button is available only when you choose to add a compound property
rule to a subtype. The Modify and Delete buttons are available only when you
select an existing compound property rule.
To create a compound property rule:

1. Click the Compound Property Rules tab.
The system displays the Compound Property Rules tree containing the object
types for which compound property rules can be defined.
2. Choose the subtype for which you want to create the compound property rule.
The system displays the attribute tree in the right pane.
3. Navigate through the attribute tree and select the property that you want to
display as a compound property on the display object.

Compound Property Rules
The property that you choose in this step is the source property.
4. Enter a name for the rule in the Compound Property Name field.
5. Optionally, select the Read Only option to designate the property as a property
that cannot be modified.
The Read Only option is only available if the selected source property is
modifiable.
6. Click the Add button at the upper-left of the attribute tree.

The system saves the compound property rule and displays it beneath the
subtype in the lower-left pane beneath the Compound Property Rules tree.
To modify a compound property rule:

2. Navigate the tree and choose the compound property rule that you want to
modify.
The system displays the subtype and property rule in the lower-left pane of the
window and the attribute tree in the right pane.
3. Optionally, perform any of the following modifications:

• Modify the name of the compound property in the Compound Property
Name field.
• Select a different source property for the compound property from the
attribute tree.
• Select or clear the Read Only option.
4. Click the Modify button at the upper-left of the attribute tree.

The system saves the modified rule.

Chapter 6 Compound Property Rules
To delete a compound property rule:

2. Navigate the tree and choose the compound property rule that you want to delete.
The system displays the attribute tree in the right pane.
3. Click the Delete button.

The system displays a confirmation dialog window.
4. Click Yes to delete the property.

The compound property rule is deleted and the change is reflected in the rule
tree.

Chapter
7 ID Context Rules
Defining Rules for Alias Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Defining Rules for Alternate Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Chapter
7 ID Context Rules
ID context rules determine behavior when creating alternate and alias identifiers by
combining valid combinations of identifier type, ID context, and identifiable type.
Cardinality rules for alternate IDs are also created as part of the ID context rule.
Defining Rules for Alias Creation

To define rules for alias creation, perform the following steps:
1. Click the IDContext Rules tab in Business Modeler.
2. Select the identifier context and identifier type from the dropdown lists. The
alias definition is specified using the IMAN_aliasid relation between an item
or item revision and an identifier. If you want to apply additional constraints,
you can do so using Business Modeler GRM rules.
3. Enter a description of the rule in the Description field.
4. Leave the Identifiable Type field blank.
5. Leave the Rule field blank. GRM rules for IMAN_aliasid relations control
the relation and cardinality. For more information, see chapter 8, Generic
Relationship Management (GRM) Rules.
6. Click the Create button.
Example
To illustrate a rule for alias creation, consider that you have two defined identifier
types, ID1 and ID2; two defined contexts, C1 and C2; and four identifiable objects,
Item1, Item2, ItemRevision1, and ItemRevision2.
You can define two ID context rules that associate identifier type ID1 with context
C1 and identifier type ID2 with context C2. With these rules defined, you cannot
create an alias using identifier type ID2 with context C1 or an alias using identifier
type ID1 with context C2.
If you do not apply GRM rules, both types of alias identifiers, ID1 and ID2, can have
an alias relation to all four identifiable objects: Item1, Item2, ItemRevision1, and
ItemRevision2. If, for example, you want to restrict alias relationships between
Item1 and ID1, you can use GRM rules to define the appropriate constraint. For
more information, see chapter 8, Generic Relationship Management (GRM) Rules.

Chapter 7 ID Context Rules
Defining Rules for Alternate Creation

To define rules for alternate ID creation, perform the following steps:
1. Click the IDContext Rules tab in Business Modeler.
2. Select the identifier context and identifier type from the dropdown lists.
3. Enter a description of the rule in the Description field.
4. Select the identifiable type (workspace object type) from the dropdown list.
5. Specify the appropriate rule in the Rule field.
6. Click the Create button.
Example
To illustrate a rule for alternate creation, consider that you have two item types,
PartDesign and PartMfg; four identifier types, Identifier, IdentifierRev,
MfgIdentifier, and MfgIdentifierRev; and four contexts, Production Part,
Temporary Part, Prototype Process, and Production Process. To ensure that
the Design and Manufacturing groups each have their own valid combinations, you
could define rules using the following combinations:
• Production Part/Identifier/PartDesign
• Production Part/IdentifierRev/PartDesign Revision
• Temporary Part/Identifier/PartDesign
• Temporary Part/IdentifierRev/PartDesign Revision
• Prototype Process/Identifier/PartMfg
• Prototype Process/IdentifierRev/PartMfg Revision
• Production Process/MfgIdentifier/PartMfg
• Production Process/MfgIdentifierRev/PartMfg Revision
When defining rules for alternates, you must have a rule for the item type
and a rule for the corresponding item revision type. You will not be able
to create alternate IDs unless both rules are defined. The identifier type
for an item revision must be the name of the identifier type associated
with the item appended with Rev.
All of the combinations listed above are valid; however, they do not define cardinality
or how many of each identifier can exist for a given instance of an item. Without a
cardinality rule, a PartDesign item and item revision can have as many alternate
IDs in the Production Part or Temporary Part contexts as desired.

ID Context Rules
To allow items to have more than one part number in the Temporary Part or
Production Part contexts, but to limit item revisions to one alternate in those same
contexts, you can define the following cardinality rule:
1. Production Part/Identifier/PartDesign/NULL
2. Production Part/IdentifierRev/PartDesign Revision/OneProdPart
3. Temporary Part/Identifier/PartDesign/NULL
4. Temporary Part/IdentifierRev/PartDesign Revision/OneTempPart

The values OneProdPart and OneTempPart are user-defined keys.
You can use any string, such as the values A and B, to achieve the same
results. Once the key value is not null, you can have only one combination
of IDContext/Identifier Type/Identifiable Type that exists for a given
instance of an identifiable.
These rule combinations allow a PartDesign item to have many part numbers in
production and temporary context, but restricts PartDesign Revision to only one
part number in production and/or temporary context.
The following combinations allow an item revision to have an alternate ID in either
Production Part or Temporary Part context but not in both contexts:
1. Production Part/Identifier/PartDesign/NULL
2. Production Part/IdentifierRev/PartDesign Revision/OneEngPart
3. Temporary Part/Identifier/PartDesign/NULL
4. Temporary Part/IdentifierRev/PartDesign Revision/OneEngPart

The value OneEngPart is a user-defined key. You can use any string,
such as the values A, to achieve the same results. Once the key value is
not null, you can have only one combination of IDContext/Identifier
Type/Identifiable Type with the same key value that exists for a given
instance of an identifiable.

Chapter
8 Generic Relationship
Management (GRM) Rules
Evaluation Order for GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Understanding the Impact of Type Inheritance on GRM Rules . . . . . . . . . . . . 8-2
Defining GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Reviewing GRM Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

Finding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

Chapter
8 Generic Relationship
Management (GRM) Rules
This chapter describes the rules used to apply constraints on objects based on the
relationship between primary and secondary objects.
Generic Relationship Management (GRM) rules are implemented using two panes in
Business Modeler: Create GRM Rules and Review GRM.
• The Create GRM Rules pane is used to create and modify the rules for
Teamcenter relations by selecting a primary type, a relation type, and multiple
secondary types.
• The Review GRM Rules pane allows you to delete or review the rules defined in
the database and find effective rules or redundant rules by selecting a primary
type, relation type, and secondary type.
The Create GRM Rules pane allows you to create and modify multiple rules at one
time, using the same constraints for multiple triplets (primary object type, secondary
object type, relation object type). This is achieved by selecting multiple secondary
object types.
Creating a rule for a particular primary or secondary type affects all subtypes
of the selected primary and secondary.
Evaluation Order for GRM Rules

GRM rules are evaluated whenever a relation between a primary and secondary
object is created, modified, or deleted. The order in which GRM rules are evaluated
for a given primary type (PType), relation type (RType), and secondary type
(SType), is as follows:
1. Find a match for PType-RType-SType.
2. If not found, find a match for PType-GRM_match_All-SType.
3. If not found, repeat steps 2-1 and 2-2 for each super type of PType and SType.
4. If a GRM rule is found, apply the rule.

Chapter 8 Generic Relationship Management (GRM) Rules
Understanding the Impact of Type Inheritance on GRM Rules

GRM rules apply constraints on objects based on the relationship between primary
and secondary objects. The primary and secondary type trees in the GRM rule
interface allow you to configure relation rules between primary and secondary objects
at any level of the type hierarchy. For example, if the ItemRevision type is chosen
as the primary type and the DirectModel dataset type is chosen as the secondary
type, all subtypes of the ItemRevision and DirectModel types inherit the relation
rule. Therefore, all instances of the subtypes of the ItemRevision primary type that
are related to all instances of the subtypes of the DirectModel secondary type by the
relation type specified by the rule are subject to the constraints defined by the rule.
The Review GRM Rules pane displays the relation rules inherited by subtypes for
every rule associated with a parent type. Inherited rules are displayed as grayed out.
Relation rules defined for a specific subtype take precedence over relation rules
defined for a parent type.
Defining GRM Rules

To create a GRM rule, perform the following steps:
1. Click the GRM Rules tab.
The system displays the Create GRM Rules and Review GRM Rules tabs.
2. Click the Create GRM Rules tab.

The system displays the primary type selection tree, the relation type selection
list, the secondary type selection area, and the constraint definition area.
3. Select a primary object type or subtype from the Primary Type Selection tree.
You can also use the Find by name field beneath the tree to locate the
type. Enter search criteria and click the Find Type Nodes button to the
right of the text field.
The system highlights the first type found that matches the search criteria.
Click the Find Type Nodes button to move to the next found type node.
4. Choose a relation type from the Relation Type Selection list. This relation type
is used to associate the primary type (and any subtypes of the primary type) to
any selected secondary types (and subtypes of selected secondary types).
5. Choose one or more secondary types by performing the following steps:

a. Expand the Relation Rules tree in the Secondary Type Selection area and
select the secondary type (or subtype) node or nodes.
Upon selection of the secondary type, if any GRM rule constraints exist for
the combination of primary, secondary, and relation type, they are displayed
in the Constraints area.
Click Cancel at any time to reset the Constraints area with the
original constraints of the GRM rule for the currently selected
secondary type.

Generic Relationship Management (GRM) Rules
b. Move the selected type to the List of Selected Types by either double-clicking
or clicking the Add button . Click the Add All Types button to add all
types with the same constraint as the selected type.
6. Apply constraints to the GRM rule, as follows:
Constraint Description/Options
Cardinality Determines the number of allowed
occurrences of the primary object in relation
to the secondary object and of the secondary
object in relation to the primary object. In
the example shown in figure 8-1, an item
object can have 0 or N number of NX datasets.
However, NX datasets can be placed under
only one item.
The Unlimited option can be applied to the
cardinality of primary or secondary object
types. To specify a limited cardinality, enter
an integer in the text field.
Changeability Changeable
No constraints on adding, changing, or
deleting links relative to the constrained
object.
Add Only
No change or removal of links is allowed
relative to the constrained object.
Frozen
Indicates a relation that cannot be
manipulated once it is established. No
new relation can be established regardless
of the cardinality range, and established
relations cannot be removed.
Attachability Unrestricted
Indicates that there are no restrictions on
attaching the relation links between the
primary and secondary objects.
Write Access Required
Considers the Access Manager write
protection to determine whether attaching
the initial or additional relation links
between primary and secondary types is
allowed.

Chapter 8 Generic Relationship Management (GRM) Rules
Constraint Description/Options
Detachability Unrestricted
Indicates that there are no restrictions
on removing the relation links between
primary and secondary objects.
Write Access Required
Considers the Access Manager write
protection to determine whether removing
the relation links between primary and
secondary types is allowed.
In figure 8-1, 0..1 is the primary cardinality value and 0..N is the secondary
value.
Figure 8-1. Cardinality Example
Reviewing GRM Rules

Use the Review GRM Rules pane to view the standard Teamcenter relationships
as well as those that you have created.
Inherited GRM rules are grayed out in the rules table.
You can view GRM rules by selecting one of the following methods.
Finding Rules
The Find button on the Review GRM Rules panel is always enabled to allow you to
find GRM rules for any combinations (triplets) of a selected primary type, relation
type, and selected secondary type using any of the following methods below:
• Select a primary type in the tree in the Primary Type Selection area.
• Choose a relation type from the Relation Type Selection list.
• Select a secondary type from the tree in the Secondary Type Selection area.
• Choose the root node of the tree in the Primary Type Selection area to display
all GRM rules for all primary types.
• Choose the root node of the tree in the Secondary Type Selection area to display
all GRM rules for all secondary types.
• Choose the null value from the Relation Type Selection list to display GRM rules
for all relation types.

Generic Relationship Management (GRM) Rules
The Find Effective Rule button is enabled only when a primary type, a relation
type, and a secondary type are selected. This button returns one GRM rule that is
applied when associating a secondary type to a primary type by way of the selected
relation type. This search returns the GRM rule specifically defined for the triplet
(selected primary type, selected relation type, selected secondary type). If no GRM
rule is defined for the triplet, the system tries to find a rule that matches the triplet
(selected primary type, GRM_match_all, selected secondary type). If no GRM rule
is found, the system continues through the type hierarchy to find one GRM rule that
can be inherited from the parent types by the triplet. For example, suppose a GRM
rule is created for the following objects:
Type Object
Primary type WorkspaceObject
Secondary type Dataset
Relation type Reference
Returns the following objects:
Type Object
Primary type ItemRevision (a WorkspaceObject)
Secondary type Text (a dataset)
Relation type IMAN_reference
If there is a specific rule for the triplet ItemRevision, IMAN_reference, Text, this
rule is returned. Otherwise, if there is a specific rule for the triplet ItemRevision,
GRM_match_all, Text, this rule is returned. Finally, the rule for the triplet
WorkspaceObject, IMAN_reference, Dataset is returned.
Similar to the Find Effective Rule button, the Find Redundancy button is
enabled only when a primary type, a relation type, and a secondary type are
selected. This find function returns two GRM rules, one of which is considered
redundant. One of the rules is enough to achieve the required behavior. For
example, if a GRM rule exists on Primary:POM_object,Secondary:POM_object
Relation:GRM:match_all and another exists on
Primary:POM_object,Seondary:POM_object,Relation:IMAN_rendering,
if all other aspects of the rule, such as cardinality and attachability remain the
same, these rules become redundant.
The GRM Rule table displays all the GRM rules found using any find feature (Find ,
Find Effective Rule, or Find Redundancy). When you select a GRM rule in the table,
the Delete button is enabled to allow you to delete the selected rule.

Chapter
9 Type Display Rules
How Type Display Rules Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Group and Role Hierarchical Inheritance . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Type Hierarchical Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Applying Type Display Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Generating Shown Types Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Chapter
9 Type Display Rules
This chapter describes the administration of type display rules that allow you to
control the ability of users to create various types of Teamcenter objects.
Type display rules allow you to control the object types that are available for creation
in the Teamcenter rich client and thin client interfaces.
Type display rules do not prevent creation of objects from the ITK layer.
These rules restrict the display of object types in the creation dialog windows and
can be applied to an entire site, a particular group, or a specific role in a group, and
can be applied to the following base object types and their associated subtypes:
• Alias
• Dataset
• Folder
• Form
• Identifier
• Item
• MEActivity
• MEOP
• MEProcess
• MEWorkarea

Chapter 9 Type Display Rules
How Type Display Rules Work

By default, all object types are available for creation by all users. Type display rules
suppress the display of object types in the object creation dialog windows, thus
preventing the users in a specific group or users who fill a certain role within a group
from being able to create objects of those types.
Although users cannot create objects associated with restricted object types,
they can view them and perform other operations, such as copying, modifying,
or deleting the objects.
Group and Role Hierarchical Inheritance

Type display rules are subject to the principles of group hierarchy and inheritance.
Rules defined at the site level are inherited by all groups and roles within groups.
Rules defined for a group are inherited by all subgroups, but rules applied to a
subgroup do not affect the parent group(s) or other subgroups at the same level in
the hierarchy (sibling groups).
Rules applied to roles within groups apply to all users with that role, but do not
affect other roles in the same group.
Type Hierarchical Inheritance

In addition to being subject to the principles of group hierarchy and inheritance,
type display rules are also subject to type inheritance. For example, consider a type
hierarchy consisting of the Item class with a corresponding Document item type.
In addition, there is a subtype of Document called MyDocument.
If the Item class is selected as the base type for the display rule, all items types are
displayed in the Available Types list.
Subtypes are not displayed in the Available Types list when a class is
selected as the base type.
If the Document item type is selected as the base type for the display rule, all
subtypes of the item type, including the MyDocument subtype, are displayed in the
Available Types list. Display rules set at the item type level take precedence over
rules set at the class level. In addition, rules set at the subtype level take precedence
over rules set at the type and class levels.

Type Display Rules
Applying Type Display Rules

To apply a type display rule, perform the following steps:
1. Click the Type Display Rules tab in the Business Modeler window.
The system displays the Organization tree in the left pane and the type selection
features in the right pane of the window.
2. In the Organization tree, select the group or role to which the type display rule
applies.
To apply a site-level rule, select the root node (Organization) rather than a role
or group. To locate a group or role in the tree, type the name, or a portion of
the name along with a wildcard character, in the text box located beneath the
tree. Click the Groups button to search for a group. Click the Roles button to
search for a role.
3. In the right pane of the window, click the down arrow in the Select the Base
Type field.
The system displays the Type Selection tree in a separate dialog window.
The list of base types is defined by the
TYPE_DISPLAY_RULES_list_of_primary_types preference. For
more information, see the Configuration Guide.
4. Expand the tree and select the base type or subtype to which the display rule
applies.
If you select a subtype, the contents of the Available Types and Shown Types
lists are inherited from the parent type or types. You can override the display
rules inherited from parent types by modifying the Shown Types list relative
to a selected subtype.
5. Add or remove object types from the Shown Types list by selecting the type and
using the Add or Remove button to move the type from one list to the other.
You cannot suppress the display of all subtypes of a base type just by
selecting the supertype to be hidden. Some super types are protected by
system-level display rules that are configured during installation and are
not subject to type display rules.
6. When the Shown Types list reflects the types that you want the users in the
selected group or role to be able to create, click the Save button.
The type display rule is saved in the database and can be exported to other
Teamcenter sites.

Chapter 9 Type Display Rules
Generating Shown Types Reports

Reports of shown types can be generated for specific types or groups/roles. A
complete report of shown types for all groups/roles can also be generated.
To generate a shown type report, perform the following steps:
1. Click the Type Display Report Wizard button located in the lower-right corner
of the Type Display Rules pane. The system displays the Type Display Rules
Report Wizard dialog window.
2. Select one of the following report generation options:

• Report on Selected Accessors (Group/Role)
• Report on Selected Types
• Complete Report
3. Click the Next button. The system displays step 2 of the wizard.
4. Depending on the report option, choose one of the following options:

• For a selected accessor report, select the accessor (group or role) from the
Organization tree.
• For a selected types report, select a type, or types, from the list.
• For a complete report, click the Yes button to generate the report.
The system displays the report in the Print dialog window.
5. If you choose to generate an accessor or selected types report, click the Next
button.
The system displays step 3 of the wizard, which shows the list of accessors or
types that you have selected for inclusion in the report.
6. Click the Yes button to generate the report.

The system displays the report in the Print dialog window. For more information
about printing options, see My Navigator Help.

Chapter
10 Property Rules
Complex Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Enabled Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Applicable Property and Value Types for the Enabled Rule . . . . . . . . . . . . 10-2
Initial Value Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Modifiable Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Applicable Property and Value Types for the Modifiable Rule . . . . . . . . . . 10-6
Required Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Visible Property Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

Chapter
10 Property Rules
This chapter describes the administration of property rules that allow you to control
access to and the behavior of object properties.
You can control whether a property is modifiable, visible, enabled, or required. In

addition, you can set an initial value for a property and define complex properties
comprised of a combination of properties and constant strings that assign a value
to the property. Once configured, property rules apply to properties as displayed in
both the rich client and thin client interfaces.
The following rules can be applied to object properties:
• Modifiable
• Initial value
• Visible
• Enabled
• Required
• Complex property
Property rules defined on parent types are inherited by subtypes. For example, a
property rule defined on the Item type is inherited by the Document type and
all subtypes of the Document.
You can override property rules defined on parent types. For example, if a property
rule is configured on the object_desc property of the Item type to make it modifiable
only if null, a separate rule can also be configured on the object_desc property of
the Document subtype to set the initial value of the object_desc property. In this
case, the rule defined on the Document subtype takes precedence over the rule
applied to the parent Item type.
Access Manager (AM) rules take precedence over property rules. For example,
if you define a property rule stating that an object property is modifiable, but
the user has not been granted write access to the object, the property remains
read-only and the user cannot modify it.

Chapter 10 Property Rules
Complex Property Rules

Complex property rules allow you to specify a combination of properties and constant
strings to assign a value to a selected property. Complex properties are derived from
one or more properties depending on the pattern of the rule, for example:
$prop1+"string literal"+$prop2
The complex property rule applies only to the following object types: item, item
revision, alias, identifier, dataset, and form. In addition, source properties and the
destination property must belong to the same object.
If complex properties are derived from runtime properties, the properties are
only updated when the object is explicitly saved.
Complex property rules apply only to string properties and are stored as preferences.
For more information, see the Configuration Guide.
Example
Use the following pattern to define the description of an item as a combination of the
ItemId and ItemName properties combined with a string literal:
$item_id+"//"+$object_name
If a complex property rule and an initial value rule are defined for the same
object property, the complex property rule takes precedence over the initial
value rule.
Enabled Property Rule

The enabled rule allows you to specify whether a property is enabled in the interface.
Valid values for the enabled rule are true and false.
This rule cannot be set to true for read-only properties. In addition, if this
rule is set to false, users cannot modify the values through the rich client and
thin client interfaces; however, the property values can be modified using
the ITK interface.
Applicable Property and Value Types for the Enabled Rule

Table 10-1 shows the property types and value types for which the enabled rule
is applicable.
Table 10-1. Property Types and Value Types for the Enabled Rule
Property Not
Type Value Type Applicable Applicable
Compound Basic data types (int, char,
X
string)
Typed and untyped reference X
Typed and untyped relation X

Property Rules
Table 10-1. Property Types and Value Types for the Enabled Rule
Property Not
Type Value Type Applicable Applicable
Attribute Basic data types (int, char,
X
string)
Reference Basic data types (int, char,
X
string)
Relation Basic data types (int, char,
X
string)
Runtime Basic data types (int, char,
X
string)
Initial Value Property Rule

The initial value rule allows you to specify the initial value to be assigned to a
property when the corresponding object is created. The initial value rule applies
only to the following object types: item, item revision, alias, identifier, dataset, and
form. When entering initial values as variable length arrays (VLAs), the initial
values must be separated by commas.
The initial value applies only when the property for which it is defined is
empty or null.
Initial values are prepopulated in the Name and Description fields in the New Item,
Revise, New Form, New Dataset, and New Folder dialog windows.
If an initial value rule and a complex property rule are defined for the same
object property, the complex property rule takes precedence over the initial
value rule.
Applicable Property and Value Types for the Initial Value Rule
Table 10-2 shows the property types and value types for which the initial value
rule is applicable.

Table 10-2. Property Types and Value Types for the Initial Value Rule
Property
Type Value Type Applicable Not Applicable
Compound Basic data types (int, X
char, string)
Typed and untyped NULLTAG only,
reference if NULL values
are allowed for
this property.
Typed and untyped X
relation
Attribute Basic data types (int, X
char, string)
Typed and untyped X
reference
Typed and untyped X
relation
Reference Typed and untyped X
reference
Relation Typed and untyped X
relation
Runtime Basic data types (int, X
char, string)
Typed and untyped NULLTAG only,
reference if NULL values
are allowed for
this property
Typed and untyped X
relation

Property Rules
Modifiable Property Rule

The modifiable rule allows you to place restrictions on the modifiability of an object
property. The following restrictions can be applied:
• Read Only
Allows users to view the value of the property but does not allow them to modify
the value.
• Write
Allows users to modify the value of the property if they have write access to the
object to which the property belongs.
• Write Only if Null

Allows users to modify the property only if the existing value is null, or empty.
Examples
The following examples illustrate the use of the modifiable rule:
To restrict the description of an item from being changed once it is defined, apply
the rule shown in figure 10-1.
Figure 10-1. Modifiable Property Rule

To prevent users from modifying an item ID, apply the rule shown in figure 10-2.
Figure 10-2. Modifiable Property Rule

Applicable Property and Value Types for the Modifiable Rule

Table 10-3 shows the property types and value types for which the modifiable rule
is applicable.
Table 10-3. Property Types and Value Types for the Modifiable Rule
Property
Compound Basic data types (int, X
char, string)
Typed and untyped X
reference
Typed and untyped X
relation
Attribute Basic data types (int, X
char, string)
Typed and untyped X
reference
Typed and untyped X
relation
Reference Typed and untyped X
reference
Relation Typed and untyped X
relation
Runtime Basic data types (int, X
char, string)
Typed and untyped X
reference
Typed and untyped X
relation

Property Rules
Required Property Rule

The required rule allows you to specify whether a value must be entered for a
specific object property. Valid values for the required rule are true and false. The
required rule applies only to the following object types: item, item revision, alias,
identifier, dataset, and form.
Applicable Property and Value Types for the Required Rule

Table 10-4 shows the property types and value types for which the required rule
is applicable.
Table 10-4. Property Types and Value Types for the Required Rule
Property Not
Type Property Type Applicable Applicable
Compound Basic data types (int, char, X
string)
Attribute Basic data types (int, char, X
string)
Reference Typed and untyped reference X
Relation Typed and untyped relation X
Runtime Basic data types (int, char, X
string)

Visible Property Rule

The visible rule allows you to specify whether a specific object property is visible in
the interface. For example, you can add runtime properties for internal purposes
and set the visible rule to false to hide them from users. Valid values for the visible
rule are true and false.
Visibility rules can only be applied to properties with a presentation name
set to a non-NULL or nonempty value. Properties for which the display name
is set to NULL are not displayed in the interface, and this behavior cannot
be overridden using property rules.
Applicable Property and Value Types for the Visible Rule

Table 10-5 shows the property types and value types for which the visible rule
is applicable.
Table 10-5. Property Types and Value Types for the Visible Rule
Property
Compound Basic data types (int, char, X
string)
Attribute Basic data types (int, char, X
string)
Reference Typed and untyped reference X
Relation Typed and untyped relation X
Runtime Basic data types (int, char, X
string)
Typed and untyped reference x

Chapter
11 Extension Rules
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Business Modeler User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Managing Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7

Extension Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Defining Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Assigning Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Converting Action Rules to Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Importing and Exporting Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Working With Internal Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15

Using the autoAssignToProject Extension . . . . . . . . . . . . . . . . . . . . . . . 11-16
Understanding the Implications of the autoAssignToProject Extension on Project
Propagation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
Using the checkLatestReleased Extension . . . . . . . . . . . . . . . . . . . . . . . 11-17
Using the copyVariantExpr Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Using the createCAEObjects Extension . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Using the createObjects Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Using the setIdentifierProperties Extension . . . . . . . . . . . . . . . . . . . . . 11-19

Chapter
11 Extension Rules
Extension rules allow you to use custom functions and predefined methods to extend
Teamcenter behavior. This chapter describes how to customize system behavior
using the Business Modeler framework and also describes how to convert existing
action rules to extension rules in the new framework.
Introduction
Prior to the introduction of the Business Modeler framework, system behavior
was extended using action rules (predefined methods applied to preconditions,
preactions, or postactions of selected operations) or by using the methods framework,
which requires creating custom code and registering it against a method on a type or
property.
Using the methods framework, actions in Teamcenter that can be extended are
represented by messages, for example, ITEM_create_msg and ITEM_delete_msg.
Methods are associated with these messages. Each method is internally represented
by the ImanMethod class, which keeps track of the base method of the message
and also tracks all registered precondition, preaction, and postaction functions.
When a message is invoked, the method is executed and the ImanMethod class
executes each registered function. This customization methodology is limited to
customization using the C API and does not offer visibility of the registered methods
and functions for reuse.
The Business Modeler framework also requires creating code, but it stores messages,
methods, and method registrations in the database as operations, extensions, and
extension points, which can be defined and configured using the Business Modeler
interface. This customization methodology supports the C and C++ APIs and uses
database storage that allows the reuse of extensions.
Customization implemented using the methods framework is interoperable
with customization implemented using the Business Modeler framework. In
this scenario, the registered methods are executed prior to executing business,
type, and property operations.

Chapter 11 Extension Rules
Table 11-1 maps the terms and concepts of the methods framework with those of the
Business Modeler framework.
Table 11-1. Methods to Business Modeler Framework Mapping

Methods Framework Business Modeler Framework
Message Business operation
Message on type Type operation
Message on property Property operation
Precondition Precondition extension point
Preaction Preaction extension point
Postaction Postaction extension point

Method implementation Extension rule
Extension Rules
Extension rules allow you to customize system behavior by applying extensions to
extension points that are related to business operations in Teamcenter. Business
operations are actions performed in the system, such as creating and saving an item,
fetching or setting a property value, or invoking a user exit. Extension points are
events in the system, such as a postaction on an operation or a user exit, that allow
you to implement custom behavior. Extensions contain information about functions
associated with Teamcenter types and properties.
Business operations can expose one or more extensions points, which in turn can
contain zero or more extensions. Extensions within an extension point display the
following characteristics:
• Extensions can be arranged to execute in a specific sequence.
• Each extension can have a set of arguments that is unique within the extension
point.
• Extensions can be activated and deactivated within an extension point.
• External extensions can be configured in the same manner as the core extensions
delivered with the Teamcenter product.
• An extension can be included more than once in a single extension point and can
also be included in multiple extension points.
• User exit operations can only be configured from the base extension point.

Extension Rules
Business Modeler User Exits

Table 11-2 lists the user exits that are available for creating extension rules in
Business Modeler. For more information about the user exists listed in the table, see
the Integration Toolkit Function Reference.
Table 11-2. Business Modeler User Exits

Extension Rule Operation Name User Exit Name Purpose
USER EndItem Search USER_appr_update_end_item_search_results Allows the PSE spatial search to
return higher-level assemblies,
rather than parts. This allows a
designer to identify assemblies in
a particular region and then select
components of interest. This exit
affects only spatial searches and not
other searches, for example, by item
attribute or classification. Typically,
this exit looks for the value of an
attribute on the item. A default
implementation is provided that
switches on the item master form
user_data_1 = ABOVE ERCT
attribute. For more information, see
Appearance Configuration Help.
USER Update Mapped Data USER_ps_update_appr_attr Creates the attribute mappings
for occurrence note changes that
are tracked and available for PSE
search.
USER Define BomCompare BMF_BOM_compare_modes This exit takes an occurrence note
Mode type and partitions it into a number
of appearance attributes that you
can then search for separately in
PSE. For more information, see
Appearance Configuration Help.
USER Ancestor Bomline USER_bomline_is_preferred_ancestor Allows you to customize the value of
the Preferred Ancestor property.
Typically, you return the item ID of
the higher-level assembly associated
with a given BOM line, according
to the value of an attribute on the
item. This property allows you to
identify the higher-level assembly to
which a BOM line belongs. This is
useful when viewing results in the
PSE Search dialog window, which
contains a flat list of components.
If you add the Preferred Ancestor
column to the properties table,
you can more easily identify the
relevant higher-level assembly.
This capability is also useful when
displaying unattached BOM lines
in PSE. A default implementation
is provided that switches on the
item master form user_data_1
= ABOVE ERCT attribute. For
more information, see Appearance
Configuration Help.
USER Copied DS Details USER_copied_datasets_details


USER Copied DS Name USER_copied_dataset_name
USER DS RevId USER_new_dataset_rev
USER DS Id USER_new_dataset_id
USER DS Name USER_new_dataset_name
USER Validate DS Name USER_validate_dataset_name
USER Def Never Used Rels USER_ecm_define_never_used_relations
USER Get Base Rev Rules USER_ecm_get_base_revision_rules
USER Get Prev BVR USER_ecm_get_prev_bvr
USER Get Process Name USER_ecm_get_process_name
USER Cust Check Func Names ERPCUSTOM_get_custom_check_funcs
USER Cust Derive Func Names ERPCUSTOM_get_custom_derive_funcs
USER Get Mesh File Name USER_get_batch_meshing_nr_name Takes a base file name, the mesh
size, and a file name extension, and
creates a file name string with the
mesh size encoded in the name with
the specified extension. The user
exit adds the mesh size to the end
of the file name, immediately before
the extension, and preceded by an
underscore. For example, with a
base name of 000001, mesh size of
10, and an extension of bdf, the
default user exit generates a default
encoding of 000001_10.bdf.
USER Get File Name USER_new_file_name
USER Folder Name USER_new_folder_name
USER Form Name USER_new_form_name

USER New AltIdfr Id USER_new_alt_id
USER Validate Alt Idfr USER_validate_alternate
USER Validate AltIdfr Id USER_validate_alt_id
USER Item Import USER_end_import_of_item
USER Local Import USER_end_local_import
USER Def Display Revs USER_ask_display_revisions
USER Item New Id USER_new_item_id
USER Check Above ERCT USER_appr_item_is_above_ERCT Allows you to set the level at which
the configuration rules switch
from unit effectivity configuration
to date released configuration
when creating appearances. For
more information, see Appearance
Configuration Help.
USER Before Item Create USER_create_item
USER After Item Create USER_item_created
USER Item New Alt RevId USER_new_revision_id_from_alt_rule
USER Item New RevId USER_new_revision_id

Extension Rules

USER Baseline Sync USER_synchronize_baseline
USER Pre Rev Create USER_create_revision
USER Baseline Dryrun USER_baseline_dryrun_validator
USER Validate ItemId RevId USER_validate_item_rev_id
USER Group Role Change USER_new_current_group
USER Filter Registrations USER_register_plmxml_filters
USER Register actions USER_register_plmxml_actions
USER Register Export Methods USER_register_plmxml_export_methods
USER Register Import Methods USER_register_plmxml_import_methods
USER Schema Mappings Regs USER_register_plmxml_schema_mappings
USER Check Pubrec Access USER_ods_check_pubrec_access Implements a granular security
scheme, such as protecting a
Publication Record from specific
users at a particular site. For
more information, see Multi-Site
Collaboration Help.
USER BomView Name USER_ps_default_bom_view_name Implements the default naming
scheme of BOM views. For more
information, see Product Structure
Editor Help.
USER Copy Eff Data For Copy CALS_copying_bvr
USER Copy Eff Data For Revise CALS_revising_bvr
USER BVR Name USER_ps_default_bvr_name Implements the default naming
scheme of BOM view revisions.
For more information, see Product
Structure Editor Help.
USER List BVR Diffs SMP_PS_list_bvr_diffs
USER Save Unsaved Eff Objs CALS_saving_bvr
USER Ask Seq Nos USER_ask_seq_numbers
USER New Seq No USER_ask_new_seqno Generates sequence numbers that
differ from the standard sequence
numbers generated in decades (10,
20, 30, and so on).
USER Add Eff Objs For Deletion CALS_deleting_occ
USER Custom Execute USER_execute_saved_query Returns objects for display.
USER Execute USER_query_execute Returns column-value triples for
display.
USER Free Rows USER_query_free_rows
USER Map Row USER_query_map_row
USER Search Client Prgm USER_get_keyword_search_client
USER Search Keyword USER_process_keyword_search_results
USER Register Report Cols USER_register_report_columns
USER End BOM Compare USER_bom_cmp_end_report
USER Start BOM Compare USER_bom_cmp_start_report
USER Emp Summary Employee_Sum_Report


USER Get Grp Access Levels Access_Levels_Report
USER Import Export Data Import_Export_Report
USER Include Row USER_report_include_row
USER Item Admin Data Get_Item_AdminData
USER Items By Grp Object_By_Group
USER Item Data By Proj By_Proj_Item_Summary_Report
USER Item Summary Item_Summary_Report
USER Item Data By Dataset ItemsByDataset
USER Items Not Released NonReleased_Item_Report
USER Items Released Released_Item_Report
USER Print MRP BVR Diffs SMP_PS_mrp_print_bvr_diffs
USER Obj Inquiry Data Object_Inquiry
USER Obj Search Object_Search
USER Print BVR diffs SMP_PS_print_bvr_diffs
USER Print Row print_a_row
USER Release Levels For Grp Users_and_Release_Levels_Report
USER Mass Storage Data Mass_Storage_Report
USER WSO Data print_report
USER Add Canned Methods USER_add_canned_methods
USER Archive File Name USER_default_archive_filename
USER Archive Tape Name USER_default_archive_tape_label
USER Build Subs Notf Msg USER_build_notify_message
USER Register AIWS Extns USER_register_aiws_extensions
USER Register EPM Handlers EPM_register_toolkit_handlers
USER Register Funcs USER_init_module
USER Register Properties USER_register_properties
USER Session User Exit Module USER_exit_module
USER Archive Export Dir USER_idsm_end_remote_import
USER Check Remote Site Txn USER_idsm_start_remote_export
USER Publish Object USER_ods_publish_object
USER Str Cmp With Sort USER_string_compare
USER Init Tool USER_gs_shell_init_module
USER Eval Cmp Result USER_evaluate_compound_result
USER invoke pdm server USER_invoke_pdm_server
USER invoke user code str USER_invoke_user_code_string
USER invoke user code taglist USER_invoke_user_code_taglist
USER invoke user create objs USER_invoke_user_create_objs

Extension Rules
Managing Extension Rules

Extension rules can be defined and configured to modify Teamcenter behavior. This
section describes different aspects of managing extension rules, such as extension
rule inheritance, defining external extensions, defining extensions in Business
Modeler, and configuring extensions within extension points.
Extension Rule Inheritance

The following basic guidelines apply to the inheritance behavior of extension rules:
• Extension rules on super types are propagated to (inherited by) subtypes.
• Inherited extension rules cannot be modified at the subtype level; modifications

must be made at the parent level.
• When a new extension is assigned to a subtype, the subtype inherits the

extensions of the super type.
Figure 11-1 illustrates the effect of type inheritance on extension rule behavior.
Figure 11-1. Extension Rule Inheritance

Defining Extensions
External extensions can be defined to customize Teamcenter behavior. Before
defining the extension in Business Modeler, you must first write the custom function
in C or C++ and store it in a either a common library or a specific library. You can
define a single library or multiple libraries to store the functions that you associate
with extensions. For more information, see the Integration Toolkit Programmer’s
Guide. In addition, you must determine the parameters that are passed to the
program when it is executed.
Specify the values for these parameters when you assign the extension. Values can
be user-defined or derived from a saved query or List of Values (LOV). When defining
the extension, you must also specify the type operations, property operations, and
extension points for which the extension is valid.
To define an extension:
1. In the Business Modeler application, click the Extension Rules tab.

The system displays two tabs: Define Extensions and Assign Extensions. The
Define Extensions pane is active.
2. Enter a name for the extension.

The extension name must be appropriate to the extension language
specified in the Type field, as follows:
C language The extension name must match the name of the
function.
C++ The extension name must conform to the following
format:
NameSpace::ClassName::MethodName
If there is no NameSpace, the name can be formatted

as follows:
ClassName::MethodName
3. Choose the appropriate language for the extension from the Type list.
4. Enter the name of the library that contains the implementation of the extension
in the Library/Jar field.
The list of valid libraries is controlled by the
BMF_CUSTOM_IMPLEMENTOR_PATH preference. For more
information, see the Configuration Guide.
5. Specify whether a single parameter, multiple parameters, or no parameters

(by selecting the blank option in the list) are associated with the extension by
choosing an option from the Parameter Set list.

Extension Rules
6. Define the parameters to be passed to the extension, as follows:

The parameters defined in this step are displayed in the Arguments panel
on the Assign Extensions tab and are used to specify values for the
arguments passed to the function associated with the extension.
a. Click the Add button to the right of the Parameter Definition List.
The system displays the parameter details dialog window.
b. Enter a name for the parameter in the Name field.
c. Choose the type of parameter from the Type list, either Integer, String, or
Double.
d. Choose one of the following Suggested List options: None, LOV or, Query.
None Specifies that you must enter the argument value manually
when assigning the extension.
LOV Specifies that values are derived from a List of Values.
Query Specifies that values are derived from the results of a query.
e. If you choose the LOV option in the previous step, enter the name of the
LOV in the LOV Name field.
If you choose the Query option in the previous step, enter the name of the
saved query.
To view the names and details of LOVs and saved queries, go to the
List of Values and Query Builder applications in the Administration
section of the Teamcenter application manager.
7. In the Availability area, define the extension points for which the extension is
valid, as follows:
a. Click the Add button to the right of the Availability list.
The system displays the Select Extension Point dialog window.
b. Choose an object type or user exit folder from the tree.

User exits are displayed as operations; however, you must first select
a folder in the tree corresponding to the pseudo class of the user exit.
c. Choose whether the extension applies to an object type or a property

associated with an object type by choosing either the Type or Property option.
Type extensions are subject to rules of hierarchical inheritance. For
more information, see Extension Rule Inheritance, earlier in this
chapter.
d. If you choose the Type option, select the operation and extension point for
which the extension is available.

e. If you choose the Property option, select a property from the Select Prop
list, an operation from the Operation list, and an extension point from the
Extension Point list.
8. Click Create.
The system displays the new extension in the Defined Extensions list.
To modify an extension:
2. Choose an extension from the Defined Extensions list.

The system displays the details of the extension in the right pane of the window.
3. Optionally, modify the language type and/or library in which the program
associated with the extension is stored.
4. Optionally, add, modify, or remove a parameter from the Parameter List.

To modify a parameter, select the parameter from the list and click the Modify
Parameter Definition button. The system displays the Parameter Details dialog
window. Modify the parameters as described in Defining Extensions, earlier in
this chapter.
To remove a parameter, select the parameter from the list and click the Remove
Parameter Definition button.
5. Optionally, add, modify, or remove an entry from the Availability list.

To modify an availability entry, select the entry from the list and click the Modify
Extension Point button. The system displays the Select Extension Point dialog
window. Modify the availability as described in Defining Extensions, earlier in
this chapter.
To remove an availability entry, select the entry from the list and click the
Remove Extension Point button.
6. Click Modify to save the modifications to the extension rule.
To delete an extension:
2. Choose an extension from the Defined Extensions list.

The system displays the details of the extension in the right pane of the window.
3. Click Delete.
The system removes the extension from the database.

Extension Rules
Assigning Extensions
This section describes the process used to configure defined method extensions,
including:
• Displaying, adding, modifying, or removing extensions from an extension point.
• Specifying argument values for defined arguments of an extension in an

extension point.
• Ordering the extensions configured for a specific extension point.
• Activating an extension within an extension point.

Some extension points for primary types have configured internal extension
rules. Although these extensions are visible in the extension assignment
table, they must not be removed.
To add extensions to an extension point:

1. Click the Extension Rules tab, and then click the Assign Extensions tab.
The system displays the Extension Point Selection area and the Extension
Method table.
2. Select a type or user exit pseudo class folder from the ClassAndTypes tree in
the Extension Point Selection area.
3. Select an operation or user exit from the Operation list.
4. Select an extension point from the Extension Point list.

User exits can only be configured from the base extension point.
If extensions are available for the selected type, operation, and extension point,
the Add button to the right of the Extension Method table is active.
5. Click the Add button to the right of the Extension Method table and double-click
in the Extension Name cell.
The system displays the list of extensions that are defined for the selected
extension point.
6. Choose an extension from the list.

The system displays the arguments for the extension.
The I.type field displays the object type for which the extension is defined.
For example, Item is displayed in the I.type field if you select an extension
associated with the Item object type. This field cannot be modified.
7. Check the Active checkbox to activate or deactivate the extension within the
extension point.
By default, the extension is active when you add it to an extension point.

8. If the parameters of the extension were defined without a suggested list of

argument values, enter a value or values in the field. If the parameters are
defined to present suggested lists of values, choose the appropriate values from
the lists.
9. Click the Add button to the right of the Argument Panel.

The system displays the argument in the Extension Method table.
10. Optionally, modify the sequence in which the extensions are executed, as follows:
a. Choose the row corresponding to the extension in the Extension Method
table.
Extensions are executed in descending order, as displayed in the table.
b. Click the up-arrow or down-arrow buttons to change the position of the

extension within the extension point.
c. Click Apply to save the changes.
11. Click Apply to save the configuration.

Extension rules configured for a super type (parent) are propagated to all
subtypes of that parent. For more information, see Extension Rule Inheritance,
To modify extension assignments:

1. Click the Extension Rules tab, and then click the Assign Extensions tab.
Method table.
3. Choose Type or Property from the Select Type or Property area.
4. Choose the operation from the Operation list.
5. Choose the extension point from the Extension Point list.

The system displays the extensions assigned to the selected type, operation,
and extension point along with the associated arguments. In addition, if the
extension is inherited from a parent type, the owning (parent) type is displayed
in the table.
Inherited extensions cannot be modified at the subtype level. To modify
an inherited extension, you must modify the extension in the context of
the owning (parent) type.
6. Optionally, modify the sequence in which the extensions are executed, as follows:
table.

Extension Rules

7. Perform one of the following tasks to modify the extension assignment.

Arguments are unique to the extension within the context of the extension
point.
To modify an argument:
a. Select the argument in the Argument Panel and click the Modify button.
b. Modify the argument values, as required.
c. Click Apply.
To add an argument:
a. If the parameters of the extension are defined without a suggested list of
argument values, enter values in the field. If the parameters were defined to
present suggested lists of values, choose the appropriate values from the lists.
b. Click the Add button to the right of the Argument Panel.
c. Click Apply.
To remove an argument:
a. Select the argument in the Argument Panel.
b. Click the Remove button.
c. Click Apply to save the argument.
To modify the sequence in which extensions are executed:

table.

To activate or deactivate an extension:

a. Click the box in the Active column in the Extension Method table.
b. Click Apply to save the changes.

To remove extensions from an extension point:
1. Click the Extension Rules tab, and click the Assign Extensions tab.
Method table.
3. Choose the operation or user exit from the Operation list.

The system displays the extension and associated arguments, if applicable.
4. With the extension highlighted, click the Remove button to the right of the
Extension Method table.
The system removes the extension from the extension point.

Extension Rules
Converting Action Rules to Extension Rules

Action rules allow you to implement precondition, preaction, and postaction functions
using canned methods delivered as part of the Teamcenter installation. The action
rules feature is being deprecated at Teamcenter 8 and replaced with extension rules.
To migrate action rules to extension rules, the migrate_action_rules_to_bmf
utility must be run once per site. For more information about this utility, see the
Utilities Reference manual.
This process works only for standard canned methods delivered with
Teamcenter. If custom methods are implemented at your site, you must first
create the extension manually in the Business Modeler and then run the
migrate_action_rules_to_bmf utility. If the utility is run without first
creating the extensions in the database, the action rules related to custom
canned methods remain in the database.
Importing and Exporting Extension Rules

Extension rule configurations can be shared between databases using the Business
Modeler import and export features. For more information, see chapter 2, Importing
and Exporting Business Rules.
Only external extension configurations can be exported or imported. The
internal extensions installed during the Teamcenter installation process
cannot be exported.
Working With Internal Extensions

There are two varieties of extensions: internal extensions and external extensions.
Internal extensions are predefined methods delivered as part of the Teamcenter
product. These extensions cannot be modified. External extensions are custom
extensions that you add to the database.
The following internal extensions are delivered as part of your Teamcenter
installation:
• autoAssignToProject
• checkLatestReleased
• copyVariantExpr
• createCAEObjects
• createObjects
• setIdentifierProperties

Using the autoAssignToProject Extension

The autoAssignToProject extension automatically assigns the selected workspace
object to the user’s current project, as defined by the work context or user settings.
If a current project is not specified for the user, this extension (method) is
ignored and the object is not automatically assigned. In addition, when the
autoAssignToProject extension is configured for an item or ECO, the project
name is preselected in the Assign to Projects page of the item or ECO create,
revise, and save as dialog windows.
Table 11-3 describes the types, operations, and extensions points for which the
autoAssignToProject extension is valid.
Table 11-3. Valid Configurations for autoAssignToProject

Type Operation Extension Point
Item and all subtypes of Create Post-Action
item
Item revision and all Revise Post-Action
subtypes of item revision
Save As To Existing Item
Create BaseLine Revision
Deep Copy
Create Revision
Dataset and all subtypes of Save Post-Action
dataset
Form and all subtypes of Save Post-Action
form
Understanding the Implications of the autoAssignToProject Extension

on Project Propagation Rules
Configuring the autoAssignToProject extension for an object type has implications
on the project propagation rules. Project propagation rules determine which
secondary objects are assigned to a project when a primary object type is assigned.
(For more information, see My Navigator Help.) When there is a conflict between
a propagation rule and the execution of the autoAssignToProject extension, the
extension takes precedence.
The following points must be considered when implementing the
autoAssignToProject extension:
• The autoAssignToProject extension applies only to newly created objects;
whereas, propagation of related objects to projects occurs whenever a relation
between two objects is created, modified, or deleted.
• The autoAssignToProject extension explicitly assigns objects to projects;

therefore, the objects can only be removed from the project by explicitly selecting

Extension Rules
the object and using the Project→Remove option in one of the Teamcenter
applications.
• Propagation rules implicitly assign secondary objects to projects. Therefore,

when the primary object is explicitly removed from the project, the secondary
object is also removed from the project.
The scenarios described in table 11-4 illustrate the relationship between extension
rules and propagation rules when assigning objects to projects.
Table 11-4. Examples of Extension and Propagation Rule Behavior

The autoAssignToProject extension Both objects are automatically assigned to
is configured for types P (primary the current project, regardless of whether
object) and types S (secondary the IMAN_requirement relation is
object). A user creates an object specified in the propagation rule list.
of type P and an object of type S
related by the IMAN_requirement
relation.
The autoAssignToProject extension The object of type P is automatically
is configured for types P (primary assigned to the current project based on
object), but not for types S (secondary the autoAssignToProject extension. If the
object). A user creates an object IMAN_requirement relation is specified
of type P and an object of type S in the propagation rule list, the type S
related by the IMAN_requirement object is also assigned to the project. If
relation. the IMAN_requirement relation is not
specified in the propagation rule list, the
secondary object is not assigned to the
project.
The autoAssignToProject extension Both the primary and secondary object are
is configured for types P (primary automatically assigned to the project based
object) and types S (secondary on the configuration of the extension rule,
object). In addition, the resulting in an explicit assignment rather
IMAN_requirement relation than the implicit assignment that occurs
is defined as a propagation rule. The when an object is assigned to a project based
user creates an object of type P and on propagation rules.
an object of type S. After creating
the objects, the user attaches the
secondary object to the primary
object using the IMAN_requirement
relationship.
Using the checkLatestReleased Extension

The checkLatestReleased extension verifies whether the latest revision of an item
is in released status prior to creating a new revision. This extension (predefined
method) can be configured within the Pre-Condition extension point of the Create
Revision, Revise, and Save As To Existing Item operations for any item revision
type.

checkLatestReleased extension is valid.
Table 11-5. Valid Configurations for checkLatestReleased

Item revision Create Revision Pre-Condition
and all
subtypes of Revise
item revision Save As To Existing
Item
Using the copyVariantExpr Extension

The copyVariantExpr extension copies forward variant information, such as option,
option defaults, and rule checks from the source item revision to the target item
revision. It does not copy forward the variant information, such as variant conditions
at the occurrence level. This extension (predefined method) can be configured within
the Post-Action extension point of the Save As operation for any item type.
On execution, this extension (method) sets the variant for the new revision to the
variant that corresponds to the source revision. This method does not modify the
expression block.
copyVariantExpr extension is valid.
Table 11-6. Valid Configurations for copyVariantExpr

Item all Save As Post-Action
subtypes of
item
Using the createCAEObjects Extension

The createCAEObjects extension creates a CAE object after creating an item
revision. This extension (predefined method) can be configured within the
Post-Action extension point of the Revise operation for any ItemRevision.
createCAEObjects extension is valid.
Table 11-7. Valid Configurations for createCAEObjects

Item revision Create Revision Post-Action
and all
subtypes of
item revision

Extension Rules
Using the createObjects Extension

The createObjects extension creates objects after creating a new item or item
revision. This extension (predefined method) can be configured within the
Post-Action extension point of the Create operation for any Item type or against the
Post-Action extension point of the Revise, Save As To Existing Item, and Create
Revision operation for any item revision type.
When you assign the createObjects extension to an item or item revision type, you
define the arguments that specify the type of dataset, form, or folder object that is
created and the relationship with which that object is attached to the item or item
revision.
createObjects extension is valid.
Table 11-8. Valid Configurations for createObjects

Item and all Create Post-Action
subtypes of
item
Item revision Save As Post-Action
and all
subtypes of Save As To Existing
item revision Item
Revise
Create Revision
Using the setIdentifierProperties Extension

The setIdentifierProperties extension sets the selected attribute values to null
when deep copying an alternate identifier using the Revise or Save As operations.
This results in the selected attribute values not being carried forward. This
extension (predefined method) can be configured within the Post-Action extension
point of the Revise or Save As operation for any Identifier type or subtype.
createObjects extension is valid.
Table 11-9. Valid Configurations for setIdentifierProperties

Identifier and Revise Post-Action
all subtypes of
identifier
Identifier and Save As Post-Action
all subtypes of
identifier

Appendix
A Glossary

Appendix
A Glossary
This appendix defines Teamcenter terms.
Action Rule
Business rule that defines the actions required in different time phases (precondition,
preaction, and postaction) for create, save as, and delete operations. Action rules are
applied to item, item revision, and dataset.
Business Operation
Action performed against an object, such as creating, saving, or setting a property
value.
Compound Property Rule

Business rule that defines runtime properties on an object that references and
relates to a property on a source object. Compound property rules relate to the
property associated with type components. Applied types are item, item revision,
dataset, and form.
Deep Copy Rule

Business 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 revise
operation. Deep copy rules can be applied to save-as and revise item revisions.
Extension
Method or listener implemented for an extension point.
Extension Point
Event or capability in the system, such as a precondition, pre-action, or post-action,
that allow you to implement custom behavior.
business_modeler C Business Modeler Help A-1

Appendix A Glossary
Extension Rule
Business rule that defines the customization applied to a particular business
operation through an extension point.
External Extension
Extension created by a user to implement customized behavior.
Generic Relationship Management Interface

Rules interface that enables system administrators to form a rule and affiliate
the following constraints with it: cardinality, changeability, attachability, and
detachability. This interface enables system administrators to define predefined
constraint behavior for a relation type, without writing code. The interface provides
functionality for both creating and reviewing rules.
GRM Interface
See Generic Relationship Management Interface.
GRM Rule
Business rule created using the generic relationship management interface. See also
Generic Relationship Management Interface.
ID Context Rule
Business rule that determines system behavior when creating alternate and alias
identifiers by combining valid combinations of identifier type, ID context, and
identifiable type. Cardinality rules for alternate IDs are also created as part of
the ID context rule.
Internal Extension
Extension delivered as part of the Teamcenter product, also known as a canned
method.
Naming Rule
Business rule that defines the naming conventions for the string property value in
different type objects. Naming rules can be attached to the following properties:
Item ID, item revision ID, and name in item types
Dataset name, ID, and revision number in dataset types
Name form types
Predefined Method
Method that performs a specific business rule validation or action against an object
such as an item, item revision, or dataset.
Property Rule
Business rule that allows an administrator to control access to and the behavior of
object properties.
A-2 Business Modeler Help business_modeler C

Glossary
Type Display Rule

Business rule that allows an administrator to control the object types that are
available for creation in Teamcenter.
business_modeler C Business Modeler Help A-3

Index
A Definition . . . . . . . . . . . . . . . . . . . . . 6-1
Compound property rules . . . . . . . . 1-2, 6-1
Action rules . . . . . . . . . . . . . . . . . . 1-1, 4-1 Creating . . . . . . . . . . . . . . . . . . . . . . 6-2
Converting to extension rules . . . . . 11-15 Deleting . . . . . . . . . . . . . . . . . . . . . . 6-4
Creating . . . . . . . . . . . . . . . . . . . . . . 4-6 Modifying . . . . . . . . . . . . . . . . . . . . . 6-3
Prepackaged methods . . . . . . . . . . . . . 4-2 Conventions
Activating extensions within extension Caution icons . . . . . . . . . . . . . . . . . . . . 8
points . . . . . . . . . . . . . . . . . . . . . . . 11-13 Code . . . . . . . . . . . . . . . . . . . . . . . . . 10
Adding extension arguments . . . . . . . 11-13 Command line entries . . . . . . . . . . . . 10
Adding extensions to extension File contents . . . . . . . . . . . . . . . . . . . 10
points . . . . . . . . . . . . . . . . . . . . . . . 11-11 Names . . . . . . . . . . . . . . . . . . . . . . . . 9
Adding patterns to naming rules . . . . . . 3-4 Note icons . . . . . . . . . . . . . . . . . . . . . . 8
Adobe Acrobat Reader . . . . . . . . . . . . . . 12 Revisions . . . . . . . . . . . . . . . . . . . . . . 8
Alternate identifier attribute values, setting to Syntax definitions . . . . . . . . . . . . . . . 11
null . . . . . . . . . . . . . . . . . . . . . . . . 11-19 Values . . . . . . . . . . . . . . . . . . . . . . . . . 9
Applying type display rules . . . . . . . . . . 9-3 Warning icons . . . . . . . . . . . . . . . . . . . 8
Assigning extensions . . . . . . . . . . . . . 11-11 Copying variant information to new
Assigning objects to projects . . . . . 4-3, 11-16 items . . . . . . . . . . . . . . . . . . . . . . . 11-18
Attachability . . . . . . . . . . . . . . . . . . . . 8-3 copyVariantExpr method . . . . . . . . . . . . 4-3
Attaching naming rules . . . . . . . . . . . . . 3-7 createObjects method . . . . . . . . . . . . . . 4-2
Autoassign objects to projects . . . . 4-5, 11-16 Creating . . . . . . . . . . . . . . . . . . . . . . . . 5-3
autoAssignToProject scenarios . . . 4-5, 11-17 Creating action rules . . . . . . . . . . . . . . . 4-6
Creating compound property rules . . . . . 6-2
B Creating deep copy rules . . . . . . . . . . . . 5-3
Creating naming rules . . . . . . . . . . . . . . 3-4
Backslashes in patterns . . . . . . . . . . . . . 3-9 Creating related objects . . . . . . . . . . . 11-19
Baseline naming rules . . . . . . . . . . . . . 3-17 Customizing system behavior . . . . . . . . 11-1
Business Modeler interface . . . . . . . . . . 1-1
Business operations . . . . . . . . . . . . . . 11-2
Business rules D
Deleting . . . . . . . . . . . . . . . . . . . . . . 1-3 Deep copy rule behavior . . . . . . . . . . . . . 5-3
Exporting . . . . . . . . . . . . . . . . . . . . . 2-1 Deep copy rules . . . . . . . . . . . . 1-2, 5-1, 5-3
Importing . . . . . . . . . . . . . . . . . . . . . 2-2 Copy as object . . . . . . . . . . . . . . . . . . 5-3
Copy as reference . . . . . . . . . . . . . . . . 5-4
C Creating for primary datasets . . . . . . . 5-3
Deleting . . . . . . . . . . . . . . . . . . . . . . 5-4
Canned methods . . . . . . . . . . . . . . . . . . 4-2 Don’t copy . . . . . . . . . . . . . . . . . . . . . 5-4
Cardinality . . . . . . . . . . . . . . . . . . . 8-3–8-4 Example . . . . . . . . . . . . . . . . . . . . . . 5-7
Changeability . . . . . . . . . . . . . . . . . . . . 8-3 Inheritance . . . . . . . . . . . . . . . . . . . . 5-1
checkLatestReleased method . . . . . . . . . 4-3 Modifying . . . . . . . . . . . . . . . . . . . . . 5-4
Code conventions . . . . . . . . . . . . . . . . . 10 Primary datasets . . . . . . . . . . . . . . . . 5-6
Command line entry conventions . . . . . . 10 Relation and object types . . . . . . . . . . 5-3
Complex property rules . . . . . . . . . . . . 10-2 Required . . . . . . . . . . . . . . . . . . . . . . 5-3
Compound properties Restrictions . . . . . . . . . . . . . . . . . . . . 5-8
Characteristics of . . . . . . . . . . . . . . . . 6-1 Secondary datasets . . . . . . . . . . . . . . 5-6
business_modeler C Business Modeler Help Index-1

Index
TC_dataset_deep_copy_rules F
preference . . . . . . . . . . . . . . . . . . 5-6
File contents conventions . . . . . . . . . . . . 10
Defining extensions . . . . . . . . . . . . . . . 11-8
Finding effective GRM rules . . . . . . . . . . 8-4
Instructions . . . . . . . . . . . . . . . . . . . 11-8
Finding redundant GRM rules . . . . . . . . 8-5
Prerequisites . . . . . . . . . . . . . . . . . . 11-8
Defining external extensions . . . . . . . . 11-8
Defining GRM rules . . . . . . . . . . . . . . . 8-2 G
Deleting business rules . . . . . . . . . . . . . 1-3 Generate counters option . . . . . . . . . . . . 3-4
Deleting compound property rules . . . . . 6-4 Generating object and revision
Deleting deep copy rules . . . . . . . . . . . . 5-4 identifiers . . . . . . . . . . . . . . . . . . . . . . 3-4
Deleting naming rules . . . . . . . . . . . 3-5, 3-8 Generic Relationship Management (GRM)
Deprecated functionality . . . . . . . . . . . . 4-1 rules . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Detachability . . . . . . . . . . . . . . . . . . . . 8-4 GRM rule constraints . . . . . . . . . . . . . . 8-3
Detaching naming rules . . . . . . . . . . . . . 3-8 Attachability . . . . . . . . . . . . . . . . . . . 8-3
Documentation . . . . . . . . . . . . . . . . . . . 12 Cardinality . . . . . . . . . . . . . . . . . 8-3–8-4
Online help . . . . . . . . . . . . . . . . . . . . 12 Changeability . . . . . . . . . . . . . . . . . . 8-3
Printable files . . . . . . . . . . . . . . . . . . 12 Detachability . . . . . . . . . . . . . . . . . . . 8-4
GRM rules . . . . . . . . . . . . . . . . . . . . . . 8-1
E Constraints . . . . . . . . . . . . . . . . . . . . 8-3
Defining . . . . . . . . . . . . . . . . . . . . . . 8-2
Evaluation of GRM rules . . . . . . . . . . . . 8-1 Evaluation order . . . . . . . . . . . . . . . . 8-1
Exporting business rules . . . . . . . . . . . . 2-1 Find effective rule . . . . . . . . . . . . . . . 8-4
Error messages . . . . . . . . . . . . . . . . . 2-7 Find redundant rule . . . . . . . . . . . . . . 8-5
import_export_business_rules Reviewing . . . . . . . . . . . . . . . . . . . . . 8-4
utility . . . . . . . . . . . . . . . . . . . . . . 2-1
Exporting extension rules . . . . . . . . . 11-15
I
Extending system behavior . . . . . . . . . 11-1
Extension names . . . . . . . . . . . . . . . . . 11-8 Icon conventions . . . . . . . . . . . . . . . . . . . 8
Extension parameters . . . . . . . . . . . . . 11-8 ID context rules . . . . . . . . . . . . . . . 1-2, 7-1
Extension points Alias creation . . . . . . . . . . . . . . . . . . 7-1
In general . . . . . . . . . . . . . . . . . . . . 11-2 Alternate creation . . . . . . . . . . . . . . . 7-1
Removing extensions . . . . . . . . . . . 11-13 Identifiers and identifier revisions . . . . . 3-3
Extension rules . . . . . . . . . . . . . . . 1-2, 11-2 Implications of using the autoAssignToProject
Availability . . . . . . . . . . . . . . . . . . . 11-9 extension . . . . . . . . . . . . . . . . . . . . 11-16
Importing and export . . . . . . . . . . . 11-15 Implications of using the autoAssignToProject
Inheritance . . . . . . . . . . . . . . . . . . . 11-7 method . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Parameters . . . . . . . . . . . . . . . 11-8–11-9 Importing business rules . . . . . . . . . . . . 2-2
Extensions . . . . . . . . . . . . . . . . . . . . . 11-2 Cautionary note . . . . . . . . . . . . . . . . . 2-2
Activating within an extension Error messages . . . . . . . . . . . . . . . . . 2-7
point . . . . . . . . . . . . . . . . . . . . 11-13 Options . . . . . . . . . . . . . . . . . . . . . . . 2-2
Adding arguments . . . . . . . . . . . . . 11-13 Importing extension rules . . . . . . . . . 11-15
Adding to an extension point . . . . . . 11-11 Inheritance, impact on deep copy rules . . 5-1
Assigning . . . . . . . . . . . . . . . . . . . 11-11 Initial value property rules . . . . . . . . . 10-3
characteristics of . . . . . . . . . . . . . . . 11-2 Internal extensions
Defining . . . . . . . . . . . . . . . . . . . . . 11-8 autoAssignToProject . . . . . . . . . . . . 11-16
Defining external . . . . . . . . . . . . . . . 11-8 checkLatestReleased . . . . . . . . . . . 11-17
External . . . . . . . . . . . . . . . . . . . . 11-15 copyVariantExpr . . . . . . . . . . . . . . 11-18
Modifying arguments . . . . . . . . . . . 11-13 createCAEObjects . . . . . . . . . . . . . 11-18
Modifying assignments . . . . . . . . . . 11-12 createObjects . . . . . . . . . . . . . . . . . 11-19
Naming conventions . . . . . . . . . . . . . 11-8 setIdentifierProperties . . . . . . . . . . 11-19
Removing arguments . . . . . . . . . . . 11-13 Internal methods,
Removing from extension points . . . 11-13 autoAssignToProject . . . . . . . . . . . . . . 4-3
Supported languages . . . . . . . . . . . . 11-8 Item revisions, verifying release
External extensions . . . . . . . . . . 11-8, 11-15 status . . . . . . . . . . . . . . . . . . . . . . . 11-17
Index-2 Business Modeler Help business_modeler C

Index
Items Type case options . . . . . . . . . . . . . . . . 3-7

Copying variant information . . . . . . 11-18 Using counters . . . . . . . . . . . . . . . . 3-15
Creating related objects . . . . . . . . . 11-19
O
L Online help . . . . . . . . . . . . . . . . . . . . . . 12
Literal variables in naming rule
patterns . . . . . . . . . . . . . . . . . . . . . . 3-12 P
Pattern variables . . . . . . . . . . . . . . . . 3-12
M Pattern variables in naming rule
Manual set . . . . . . . . . . . . . . . . . . . . . . 12 patterns . . . . . . . . . . . . . . . . . . . . . . 3-12
Methods Patterns using the back slash
autoAssignToProject . . . . . . . . . 4-3, 11-16 character . . . . . . . . . . . . . . . . . . . . . . 3-9
checkLatestReleased . . . . . . . . . . . 11-17 Predefined methods
copyVariantExpr . . . . . . . . . . . . . . 11-18 autoAssignToProject . . . . . . . . . 4-3, 11-16
createCAEObjects . . . . . . . . . . . . . 11-18 checkLatestReleased . . . . . . . . . . . 11-17
createObjects . . . . . . . . . . . . . . . . . 11-19 copyVariantExpr . . . . . . . . . . . . . . 11-18
setIdentifierProperties . . . . . . . . . . 11-19 createCAEObjects . . . . . . . . . . . . . 11-18
Modifiable property rules . . . . . . . . . . . 10-5 createObjects . . . . . . . . . . . . . . . . . 11-19
Modifying . . . . . . . . . . . . . . . . . . . . . . . 3-5 setIdentifierProperties . . . . . . . . . . 11-19
Modifying compound property rules . . . . 6-3 Prepackaged methods . . . . . . . . . . . . . . 4-2
Modifying deep copy rules . . . . . . . . . . . 5-4 checkLatestReleased . . . . . . . . . . . . . 4-3
Modifying extension arguments . . . . . 11-13 copyVariantExpr . . . . . . . . . . . . . . . . 4-3
Modifying extension assignments . . . . 11-12 createObjects . . . . . . . . . . . . . . . . . . . 4-2
Modifying naming rule patterns . . . . . . . 3-5 Projects, assigning objects upon
creation . . . . . . . . . . . . . . . . . . 4-3, 11-16
N Property inheritance
Impact on naming rules . . . . . . . . . . . 3-2
Name conventions . . . . . . . . . . . . . . . . . . 9 Impact on property rules . . . . . . . . . 10-1
Naming rule patterns . . . . . . . 3-4–3-5, 3-9 Property rules . . . . . . . . . . . . . . . . 1-2, 10-1
Literal variables . . . . . . . . . . . . . . . 3-10 Complex . . . . . . . . . . . . . . . . . . . . . 10-2
Pattern variables . . . . . . . . . . . . . . . 3-10 Enabled . . . . . . . . . . . . . . . . . . . . . 10-2
Regular expressions . . . . . . . . . . . . . 3-11 Inheritance . . . . . . . . . . . . . . . . . . . 10-1
Using literal variables . . . . . . . . . . . 3-12 Initial value . . . . . . . . . . . . . . . . . . 10-3
Using nested rules . . . . . . . . . . . . . . 3-12 Modifiable . . . . . . . . . . . . . . . . . . . . 10-5
Using system variables . . . . . . . . . . . 3-14 Required . . . . . . . . . . . . . . . . . . . . . 10-7
Valid characters . . . . . . . . . . . . . . . . . 3-9 Visible . . . . . . . . . . . . . . . . . . . . . . 10-8
Valid system variables . . . . . . . . . . . 3-10
Naming rules . . . . . . . . . . . . . 1-1, 3-1, 3-3
Adding patterns . . . . . . . . . . . . . . . . . 3-4 R
Attaching to object properties . . . . . . . 3-7 Refreshing the rules tree . . . . . . . . . . . . 1-2
Baseline . . . . . . . . . . . . . . . . . . . . . 3-17 Regular expressions . . . . . . . . . . . . . . 3-11
Creating . . . . . . . . . . . . . . . . . . . . . . 3-4 Removing . . . . . . . . . . . . . . . . . . . . . . . 3-4
Creating with two patterns . . . . . . . . 3-15 Removing extension arguments . . . . . 11-13
Deleting . . . . . . . . . . . . . . . . . . . 3-5, 3-8 Removing naming rule patterns . . . . . . . 3-4
Detaching from object properties . . . . . 3-8 Required property rules . . . . . . . . . . . . 10-7
Generating counters . . . . . . . . . . . . . . 3-4 Reviewing GRM rules . . . . . . . . . . . . . . 8-4
Generating object and revision Revision conventions . . . . . . . . . . . . . ... 8
identifiers . . . . . . . . . . . . . . . . . . . 3-4 Rules
Modifying patterns . . . . . . . . . . . . . . . 3-5 Action . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Pattern variables . . . . . . . . . . . . . . . 3-12 Compound property . . . . . . . . . . . . . . 1-2
Properties subject to . . . . . . . . . . . . . . 3-1 Deep copy . . . . . . . . . . . . . . . . . . . . . 1-2
Property inheritance . . . . . . . . . . . . . 3-2 Extension . . . . . . . . . . . . . . . . . . . . . 1-2
Removing patterns . . . . . . . . . . . . . . . 3-4 Extension inheritance . . . . . . . . . . . 11-7
business_modeler C Business Modeler Help Index-3

Index
Generic Relationship Management TC_dataset_deep_copy_rules

(GRM) . . . . . . . . . . . . . . . . . . . . . 1-2 preference . . . . . . . . . . . . . . . . . . . . . . 5-6
ID context . . . . . . . . . . . . . . . . . . . . . 1-2 Type display rules . . . . . . . . . . . . . . . . . 1-2
Naming . . . . . . . . . . . . . . . . . . . . . . . 1-1 Applying . . . . . . . . . . . . . . . . . . . . . . 9-3
Property . . . . . . . . . . . . . . . . . . . . . . 1-2 Base types . . . . . . . . . . . . . . . . . . . . . 9-3
Type display . . . . . . . . . . . . . . . . . . . 1-2 Object types . . . . . . . . . . . . . . . . . . . 9-1
Shown types report . . . . . . . . . . . . . . 9-4
S TYPE_DISPLAY_RULES_list_of_primary_
types preference . . . . . . . . . . . . . . . . . 9-3
Setting alternate identifier attribute
values . . . . . . . . . . . . . . . . . . . . . . . 11-19 U
Specifying valid patterns for object names and
User exit configuration . . . . . . . . . . . 11-11
identifiers . . . . . . . . . . . . . . . . . . . . . . 3-1
Syntax definition conventions . . . . . . . . . 11
System variables in naming rule V
patterns . . . . . . . . . . . . . . . . . . . . . . 3-14 Value conventions . . . . . . . . . . . . . . . . . . 9
Verifying release status prior to revision
T creation . . . . . . . . . . . . . . . . . . . . . 11-17
Visible property rules . . . . . . . . . . . . . 10-8
Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Index-4 Business Modeler Help business_modeler C

Business Modeler

Uploaded by

Copyright:

Available Formats

Business Modeler

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Modeler

Uploaded by

Copyright:

Available Formats

Teamcenter

Engineering Process Management

Business Modeler Help

Business Modeler Help

This product is intended for use only described in this document.

This edition obsoletes all previous editions.

2 Business Modeler Help business_modeler C

Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Importing and Exporting Business Rules . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Deep Copy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Compound Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

ID Context Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

business_modeler C Business Modeler Help 3

Defining Rules for Alternate Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Generic Relationship Management (GRM) Rules . . . . . . . . . . . . . . . . . . 8-1

Type Display Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Property Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Extension Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

2-1. Rule Compare Dialog Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

1-1. Business Rule Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

4 Business Modeler Help business_modeler C

3-2. Naming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

business_modeler C Business Modeler Help 5

This document supplements the Teamcenter Help Library. If you find

Chapter 1 Getting Started describes the Business Modeler interface

business_modeler C Business Modeler Help 7

Chapter 7 ID Context Rules describes how to administer the rules

Note, Caution, and Warning Icons

A warning icon identifies practices that could result in permanent loss of

8 Business Modeler Help business_modeler C

Names and Values

Bold Bold font represents unvarying text or numbers within a name or

For example, the name of the pom_schema_server-name_sid file may be:

business_modeler C Business Modeler Help 9

Command Line Entries, File Contents, and Code

The conventions are:

Monospace Monospace font represents text or numbers you enter on a

The following example is a correct entry for the preceding create_change_types

10 Business Modeler Help business_modeler C

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

business_modeler C Business Modeler Help 11

Proprietary and restricted rights notice

12 Business Modeler Help business_modeler C

Understanding the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Administering Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

business_modeler C Business Modeler Help

Understanding the Interface

Table 1-1. Business Rule Tabs

• Name attribute for any form type

• Identifier, project, and work context

business_modeler C Business Modeler Help 1-1

Table 1-1. Business Rule Tabs

Refreshing the Rules Display

1-2 Business Modeler Help business_modeler C

Administering Business Rules

business_modeler C Business Modeler Help 1-3

2 Importing and Exporting