IntegrationToolkitProgrammerGuide V10

Teamcenter® 2005 SR1
engineering process management
Teamcenter Engineering
Integration Toolkit Programmer’s
Guide
Publication Number
ENG00043 A
Teamcenter® 2005 SR1
engineering process management
Teamcenter Engineering
Integration Toolkit Programmer’s
Guide
This product is intended for use only described in this document. UGS
cannot be responsible for the proper functioning of undescribed features
and parameters.
Publication Number
ENG00043 A
Manual History
Manual Teamcenter Engineering Publication

Revision Version Date
A 2005 SR1 June 2006
©2006 UGS Corp.

All Rights Reserved.
Produced in the United States of America.
2 Integration Toolkit Programmer’s Guide ENG00043 A

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Teamcenter Engineering Documentation . . . . . . . . . . . . . . . . . . . . . . . . . 14
Submitting Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Software Copyright and Trademark Notices . . . . . . . . . . . . . . . . . . . . . . 14
Introduction to Integration Toolkit Programming . . . . . . . . . . . . . . . . . 1-1
General Caveats and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part I: ITK Concepts
Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Client Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Web Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Enterprise Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Resource Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Application Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Teamcenter Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Object-Oriented Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Using ITK Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Variable Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Initializing Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Special Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Linking Standalone Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Running the Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Batch ITK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Supplier Custom Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
ENG00043 A Integration Toolkit Programmer’s Guide 3

Contents
Part II: ITK Modules
Core Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Core Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

File Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Changing the Revisioning Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Types, Properties, and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
List of Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Audit Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Product Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Bill of Materials (BOM) Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

BOM Compare Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Product Structure (PS) Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
Product Structure Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
Persistent Object Manager Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Persistent Object Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

POM Inheritance Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
POM Enquiry Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Enterprise Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

EPM Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Customizing a Procedure With EPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
EPM Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18
Cascade Release Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Data Sharing of Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Object Import and Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Multi-Site Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Customizing Forms and Properties Display . . . . . . . . . . . . . . . . . . . . . 12-1
Communication With the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

Form UI Display Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Displaying a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Teamcenter Engineering Form Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Developing Automatic Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Developing Forms by Extending the Abstract Class . . . . . . . . . . . . . . . . . 12-6
Developing Forms Using JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Developing Forms and Customizing the Properties Display Using XML Style
Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

Contents
Customizing Text and Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Mechatronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Mechatronics Fundamental Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Harness Model Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
Mechatronics API Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
API Use Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Embedded Software Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15
Traversal Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Basic Features . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
User Exits . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Minimum Requirements . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Installation . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Developing a Traversal Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3
Sample Implementation . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
Figures
2-1. Four-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

4-1. Class Object Diagram Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4-2. Item/Item Revision Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4-3. Dataset Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
4-4. Form Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
4-5. System Administration Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
4-6. Access Control Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
4-7. Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
5-1. Journal File Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
5-4. Gateway Response Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
5-5. Code Template to Fix Invalid Characters . . . . . . . . . . . . . . . . . . . . . . . 5-9
5-6. user_server_exits.c File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
5-7. Java Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
5-8. Batch Program Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
5-9. Register Custom Callbacks Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
5-10. User Exits Customization Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
5-11. Server Exits Customization Example . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
5-12. Registering a Custom Handler in a Custom Exit Example . . . . . . . . . . 5-33
5-13. Sample Registration of Property Methods . . . . . . . . . . . . . . . . . . . . . . 5-34
6-1. Teamcenter Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
6-2. Property Method Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
6-3. Canned Methods Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
6-4. Property File Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
6-5. Adding an Attribute to an Existing Class . . . . . . . . . . . . . . . . . . . . . . 6-53

Contents
6-6. Adding an Attribute to a New Subclass . . . . . . . . . . . . . . . . . . . . . . . . 6-54

6-7. Adding a Property From a Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
6-8. Adding a Runtime Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56
7-1. Partial Listing of the am_text.xml File . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7-2. bmf_extension_workflow_sample.h Include File . . . . . . . . . . . . . . . . . . 7-7
7-3. bmf_extension_workflow_sample.c Source File . . . . . . . . . . . . . . . . . . . 7-12
8-1. Sample BOM Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
8-2. Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
8-3. Single Level Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
8-4. Compare Report Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
8-5. Property Display Element Definition . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
8-6. Display Order Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
8-7. Traversing Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
8-8. BOM Compare Visitor 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
8-9. BOM Compare Visitor 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
8-10. BOMView Class Attributes and Methods . . . . . . . . . . . . . . . . . . . . . . . 8-34
8-11. BOMView Revision Class Attributes and Methods . . . . . . . . . . . . . . . . 8-36
8-12. Occurrence Class Attributes and Methods . . . . . . . . . . . . . . . . . . . . . . 8-38
8-13. View Type Class Attributes and Methods . . . . . . . . . . . . . . . . . . . . . . 8-39
8-14. Note Type Class Attributes and Methods . . . . . . . . . . . . . . . . . . . . . . 8-40
8-15. Product Structure Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
8-16. Item Revision Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
9-1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9-2. Initial Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
9-3. Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
9-4. folderlib.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
9-5. Schema Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
9-6. ITK Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
9-7. Basic Single Table Enquiry Example . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
9-8. Simple Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
9-9. Simple Join Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
9-10. Practical Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
9-11. SELECT POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
9-12. WHERE POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-44
9-13. ORDER BY POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
9-14. Subquery POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-48
9-15. class_alias POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-50
9-16. pseudo_class POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52
9-17. Set-Expression INTERSECTION POM Enquiry APIs . . . . . . . . . . . . . . 9-53
9-18. Set-Expression DIFFERENCE POM Enquiry APIs . . . . . . . . . . . . . . . 9-54
9-19. Set-Expression UNION POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . 9-56
9-20. SUBSTR POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
9-21. cpid POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-58
9-22. UPPER and LOWER POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . 9-59
9-23. COUNT POM Enquiry APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60
10-1. Task Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10-2. Task Model Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
10-3. EPM Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
10-4. Module Initialization Function Example . . . . . . . . . . . . . . . . . . . . . . 10-12
10-5. Validation Rule File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
10-6. Validation Rule APIs Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17
10-7. ITK Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18
10-8. Release Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

Contents
11-1. Export Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

11-2. Import Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
12-1. Form Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
12-2. Form UI Display Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
12-3. Form Displayed in a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
12-4. Form Displayed in the Rich Client Viewer . . . . . . . . . . . . . . . . . . . . . . 12-3
12-5. Form Type Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
12-6. Basic UI Form and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
12-7. UI Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
12-8. Style Sheet Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
12-9. XML Definition Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
12-10. Form Rendering Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
12-11. Form Rendering Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
12-12. XML File Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
12-13. OneColumn Display Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
12-14. TwoColumn Display Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
12-15. Headed Rendering Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
12-16. Titled Rendering Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
12-17. User Properties XML Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
12-18. User Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31
12-19. Item Properties XML Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32
12-20. User Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-33
12-21. PropertyNameLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-33
12-22. PropertyTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-34
12-23. TitledPropertyTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-34
12-24. PropertyTextArea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
12-25. TitledPropertyTextArea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
12-26. PropertyButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
12-27. TitledPropertyButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
12-28. TitledPropertyLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-37
12-29. PropertySlider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-37
12-30. TitledPropertySlider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-38
12-31. PropertyDateButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-38
12-32. TitledPropertyDateButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-39
12-33. PropertyCheckbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-39
12-34. TitledPropertyCheckbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-40
12-35. PropertyRadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-41
12-36. TitledPropertyRadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-41
12-37. PropertyToggleButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-42
12-38. TitledPropertyToggleButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-42
12-39. LOVPopupButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-43
12-40. TitledPropertyLOVButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-43
12-41. PropertyLOVPopupButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-44
12-42. TitledPropertyLOVCombobox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-44
12-43. PropertyCheckboxOptionLov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-45
12-44. TitledPropertyCheckboxOptionLov . . . . . . . . . . . . . . . . . . . . . . . . . . 12-45
12-45. PropertyRadioButtonOptionLov . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-45
12-46. TitledPropertyRadioButtonOptionLov . . . . . . . . . . . . . . . . . . . . . . . . 12-46
12-47. PropertyToggleButtonOptionLov . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-46
12-48. TitledPropertyToggleButtonOptionLov . . . . . . . . . . . . . . . . . . . . . . . 12-46
12-49. PropertyObjectLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47
12-50. TitledPropertyObjectLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47
12-51. PropertyLongText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-48

Contents
12-52. TitledPropertyLongText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-49

12-53. TitledPropertyLogicalPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-49
12-54. PropertyArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-51
12-55. TitledPropertyArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-51
12-56. PropertyImage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-52
14-1. Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
14-2. Climate Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
14-3. Defining Port Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
14-4. Functionality Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14-5. Creating Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
14-6. Embedded Software Manager Example . . . . . . . . . . . . . . . . . . . . . . . 14-19
Tables
8-1. Variant Expression Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10

9-1. POM Enquiry Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40
9-2. Supported Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-61
11-1. Process and Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
12-1. Modified Components in Read-Only Forms . . . . . . . . . . . . . . . . . . . . 12-12
12-2. XML Elements and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21
12-3. JavaBeans Based on Rendering Hint and Style . . . . . . . . . . . . . . . . . 12-27
12-4. Default Renderers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-29
14-1. Mechatronics Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
14-2. Embedded Software Manager Functions . . . . . . . . . . . . . . . . . . . . . . 14-15
14-3. Signal Manager Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17

Preface
This manual describes how to use the Integration Toolkit to customize Teamcenter®
Engineering. Teamcenter Engineering belongs to the UGS® portfolio of digital
product lifecycle management software and services.
This document supplements the Teamcenter Engineering Help Library.

If you find information inconsistent with that found in that Teamcenter
Engineering Help Library, contact the UGS Global Technical Access Center
(GTAC) for clarification.
Audience
The readers of this guide should be experienced Teamcenter Engineering system
administrators and programmers.
Organization
This manual contains the following chapters and appendixes:
Chapter 1 Introduction to Integration Toolkit Programming defines

the Integration Toolkit and describes the two parts of the
manual.
Chapter 2 Architecture Overview describes the software architecture
of Teamcenter.
Chapter 3 Application Interfaces briefly describes the application
interfaces you can use to integrate external applications
with Teamcenter Engineering.
Chapter 4 Teamcenter Object Model begins with a brief description of
objects in general, then progresses to a discussion of the
Teamcenter Object Model. It also provides information on
the various objects used in the Teamcenter system and how
they are related.
Chapter 5 Using ITK Functions describes the format of ITK functions
as well as details about writing, compiling, linking, and
running ITK programs.
Chapter 6 Core Functions describes the modules that contain
Teamcenter’s core functionality.
Chapter 7 System Administrator describes the modules that contain
system administration functionality.

Preface
Chapter 8 Product Structure Management describes the modules that

contain product structure management functionality.
Chapter 9 Persistent Object Manager Layer describes the Persistent
Object Manager (POM), POM inheritance, and the POM
enquiry module.
Chapter 10 Workflow describes the Enterprise Process Modeling (EPM)
module and the Cascade Release (CR) application.
Chapter 11 Data Sharing of Data Objects describes how to import and
export objects and Multi-Site Collaboration programming
techniques.
Chapter 12 Customizing Forms and Properties Display describes
the processes used to create forms in the Teamcenter
Engineering rich client.
Chapter 13 Customizing Text and Error Messages describes how to
customize text and error messages.
Chapter 14 Mechatronics provides background information required
to use ITK APIs to create and manipulate Mechatronics
objects.
Chapter 15 Traversal Engine describes the Traversal Engine module
that allows you to develop utilities that traverse Teamcenter
Engineering structures, such as Product Structure (PS),
without needing to write a specific program.
Appendix A Glossary defines Teamcenter Engineering terms.

Preface
Conventions
This manual uses the conventions described in the following sections.
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.
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 Engineering Documentation

Teamcenter Engineering 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
Engineering rich client application or by clicking one of the links under the Help
icon in the Teamcenter Engineering thin client user interface.
• You can access the printable manuals from the Teamcenter Engineering
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. UGS grants permission for Teamcenter
Engineering 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 UGS to handle all problem reports
concerning the software they provide. Please submit all comments directly to UGS.
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:
UGS Technical Communications
4233 Lexington Avenue N., Suite 3290
Arden Hills, MN 55126-6198
U.S.A.
To submit an incident report, you can use the UGS GTAC online support tools at
the following URL:
http://support.ugs.com
Software Copyright and Trademark Notices

© 2006 UGS Corp. All Rights Reserved. This software and related documentation
are proprietary to UGS Corp.
UGS and Teamcenter are registered trademarks or trademarks of UGS Corp. or its
subsidiaries in the United States and in other countries.
Java and all Java-based marks are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States and other countries.
All other trademarks or registered trademarks belong to their respective holders.

Chapter
1 Introduction to Integration
Toolkit Programming
General Caveats and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
ENG00043 A Integration Toolkit Programmer’s Guide

Chapter
1 Introduction to Integration
Toolkit Programming
This chapter defines the Integration Toolkit and describes the two parts of the
manual.
UGS is committed to maintaining compatibility between Teamcenter

product releases. If you customize functions and methods using published
APIs and documented extension points, be assured that the next successive
release will honor these interfaces. On occasion, it may become necessary to
make behaviors more usable or to provide better integrity. Our policy is to
notify customers at the time of the release prior to the one that contains a
published interface behavior change.
UGS does not support code extensions that use unpublished and
undocumented APIs or extension points. All APIs and other extension
points are unpublished unless documented in the official set of technical
manuals and help files issued by UGS Technical Communications.
The Teamcenter license agreements prohibit reverse engineering, including:
decompiling Teamcenter object code or bytecode to derive any form of the
original source code; the inspection of header files; and the examination of
configuration files, database tables, or other artifacts of implementation.
UGS does not support code extensions made using source code created from
such reverse engineering.
If you have a comment or would like to request additional extensibility,
contact the UGS customer support representatives at GTAC for further
assistance.
The Integration Toolkit (ITK) is a set of software tools that you can use to integrate
third-party or user-developed applications with Teamcenter. The ITK is a set of C
and C++ functions used directly by Teamcenter and NX.
The Integration Toolkit is a set of callable subroutines that act as a programmatic
interface to Teamcenter. It is the means by which both internal and external
applications interface with the Teamcenter core (including RDBMS) and the
Teamcenter front end (including the window management subsystem). Internal
applications are those supplied such as NX. External applications are those that
you decide to integrate into Teamcenter.
ENG00043 A Integration Toolkit Programmer’s Guide 1-1

Chapter 1 Introduction to Integration Toolkit Programming
Teamcenter consists of various modules. The ITK interfaces the integrator’s

application to these modules. The end goal of the ITK is to fully integrate an
application into Teamcenter.
The topics in this manual provide the background information necessary for you to
understand the Teamcenter philosophy, architecture, and object model.
Refer to the Teamcenter Engineering Release Bulletin for a list of supported
compilers.
This manual is divided into two parts:

1. ITK Concepts
This part gives an overview of the Teamcenter architecture and the application
interfaces you can use to interact with it.
2. ITK Modules
This part describes the Teamcenter modules where you can use ITK to customize
your Teamcenter application.
General Caveats and Restrictions

Teamcenter reserves command line switches beginning with –z for internal
use. Therefore, ITK programs should avoid the use of switches which begin
with –z.
The dataset_cleanup utility fails to print out trailing information about the log
file after it finishes processing anchors before it exits to the prompt. On Windows,
you do not know if it ended correctly or the location of the log file. Also, it does not
delete anchors with zero size.
This applies to all ITK programs, not those only involving datasets. The problem can
be resolved by setting the IMAN_KEEP_SYSTEM_LOG environment variable to 1.
This applies to Windows only.
1-2 Integration Toolkit Programmer’s Guide ENG00043 A

Part
I ITK Concepts
This part describes the basic concepts you should be familiar with to customize
Teamcenter with ITK.
Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Application Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Teamcenter Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Using ITK Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Chapter
2 Architecture Overview
Client Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Web Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Enterprise Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Resource Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Chapter
2 Architecture Overview
This chapter describes the software architecture of Teamcenter.
Teamcenter is constructed in tiers. The lowest tiers are closest to the database
and file volumes and the highest tiers are closest to the user. The Teamcenter
architecture consists of the following tiers:
• Client tier
• Web tier
• Enterprise tier
• Resource tier
Figure 2-1. Four-Tier Architecture

These layers run on top of, and add functionality to, existing host facilities instead of
replacing host facilities. For example, Teamcenter interfaces to the host electronic
mail facilities, but also provides a higher level of messaging to overcome certain
limitations of the host facilities.

Chapter 2 Architecture Overview
Client Tier
The client tier comprises the Teamcenter Engineering clients: the thin client and
rich client. For more information, see the Thin Client Help - DHTML and the Rich
Client Customization Programmer’s Guide.
Web Tier
The Web tier is a Java application that runs in a Java 2 Enterprise Edition (J2EE)
application server, such as BEAWebLogic, and is responsible for communication
between the client tier and enterprise tier. The Web tier application also includes
the Application Interface Web Service (AIWS) and Teamcenter Engineering Data
Integration Services Adapter.
Enterprise Tier
The enterprise tier comprises a configurable pool of Teamcenter Engineering C++
server processes and a server manager. The enterprise tier retrieves data from
and stores data in the database. A server manager manages a pool of Teamcenter
Engineering server processes. This is the tier where you use ITK programming to
customize Teamcenter Engineering on the server side.
Resource Tier
The resource tier comprises a database server, database, volumes, and file servers
with two file management systems.
• The Teamcenter File Management System (FMS) downloads and uploads file
data for the rich client, Teamcenter Visualization, and the thin client configured
with Teamcenter Visualization. It provides a file storage, caching, distribution,
and access system. Multi-Site Collaboration also uses FMS servers to transfer
data.
• Teamcenter File Services (TCFS) is a legacy file management system, previously

called IMANFS, that provides a variety of volume-related services and operates
in conjunction with the File Management System (FMS). The Teamcenter
Engineering Organization application uses TCFS to create volumes and perform
other administrative functions. TCFS also supports file access for NX 4.0.1 or
earlier and Teamcenter Visualization 5.0 or earlier when you use these products
with Teamcenter Engineering. (NX 4.0.2 and Teamcenter Visualization 6.0 and
later use File Management System.)
• For more information about supported databases, see the Teamcenter

Engineering Release Bulletin.

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

• interactively
• import/export
• programmatically
Interactive access is accomplished through the forms and menus or through the
interactive dialogues of applications integrated within Teamcenter. Import/export
involves taking the data out of Teamcenter, accessing the data by any means at
your disposal and later, putting data back into the Teamcenter system. ITK also
provides programmatic access.
You accomplish file access through the ImanFile interface of the ITK when this is
available through TCFS. For FMS-based file access, use the FMS ITK interface. You
can use the file management functions in this module to interface into the operating
system I/O utilities.
The information in the database is stored in tables in a relational database and is
accessed using SQL. Only the POM should ever read from, or write data directly
to, Teamcenter tables. Other application programs can create and access their own
tables directly.
The POM is the tool that we provide for internal programmers, third parties,
and customers to define their own data types, create and access their own data,
and access simple Teamcenter data. To define data types, you normally use
administrative applications in the rich client, such as Schema Editor, Type, or
Business Modeler, rather than directly editing schemas or writing code (for more
information about these applications, see Schema Editor Help, Type Help, and
Business Modeler Help). It also presents an object-oriented view of data, rather than
the tabular view that SQL presents. Finally, it implements the locking, checking of
access rights, and referential integrity checks for the system.
At the highest semantic level, there are application level procedures for accessing
data. These procedures can potentially operate on many objects at once, and can
perform tasks other than just simple data reads and writes.
For example, an ITK procedure to add an attribute to a Configuration Management
(CM) object can actually cause a new object to be created in the database. References
must be added from this new object to the CM object and vice versa. Several POM
calls must be made to build a valid set of data. Those POM calls make even more use
of SQL to finally speak to the relational database in its terms of tables, rows and
values. In general, the POM should not be used to access object data for which
there are higher level ITK procedures.

Chapter
3 Application Interfaces

Chapter
3 Application Interfaces
This chapter briefly describes the application interfaces you can use to integrate
external applications with Teamcenter Engineering.
There are five application interfaces you can use to integrate external applications
with Teamcenter Engineering:
• Service-Oriented Architecture (SOA)
SOA allows different applications to communicate with one another using
services. SOA is appropriate for integrating separate applications with a loose
linkage and network-friendly APIs that do not need to be modified with every
release of Teamcenter Engineering. This is the preferred method of integrating
third party and client applications. Future releases will extend this interface
and provide tools so you can easily extend it. For more information about SOA,
see the Web Services Guide.
• Integration Toolkit (ITK)

Use the ITK interface when programming within the Teamcenter server (for
example, extension points, workflow handlers, or low-level batch programs)
and when constructing new interfaces for SOA. It is a low level interface that
normally requires many more calls than the higher level interfaces (SOA,
Application Interface Web Service, Application Integration Environment) to
execute a given action, but it is powerful when you need to access the system
in this way. For integrating external applications, UGS recommends that you
use SOA. If you need functionality not exposed using SOA, then write new,
high-level service methods using ITK and expose them as SOA interfaces using
the SOA toolkit.
• Application Interface Web Service (AIWS)

AIWS allows Teamcenter Engineering and an external application to share data
that exists in the same context. To communicate with an external application,
you must create and install an AIWS proxy client in the external application.
You can use only AIWS for some kinds of integrations, but SOA will eventually
replace AIWS. You should use AIWS only if no other interface supplies the
functionality you need and you cannot extend SOA with ITK as described. For
more information about AIWS, see the Application Interface Web Service (AIWS)
Configuration and Customization Guide.

Chapter 3 Application Interfaces
• Application Integration Environment (AIE)

AIE provides the framework and common functions required to integrate
applications with Teamcenter. AIE is similar to AIWS and it is the only choice
when working with some CAD integrations. You should use AIE only if no other
interface supplies the functionality you need and you cannot extend SOA with
ITK as described above. For more information about AIE, see the Application
Integration Environment Help
• Generic Shell
Generic Shell is a mechanism that Teamcenter Engineering uses to encapsulate
an application. Generic Shell intercepts application save commands and saves
data files in Teamcenter Engineering volumes instead of directly in the operating
system file structure. Generic Shell is appropriate for some kinds of very simple
integrations, and you can avoid programming altogether if you use this interface
carefully.
The user_edshell.c file in the /sample/examples directory shows how to
integrate an application into Teamcenter using the Generic Shell, in this case an
ASCII text editor. You can use the Teamcenter ITK to develop a new application
that is fully integrated with Teamcenter or it can be used to develop a shell for
an existing application.

Chapter
4 Teamcenter Object Model
Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Product Structure Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Item and Item Revision Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Item Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Modifying an Item/Item Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Item Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Dataset Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Unique ID Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Form Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
System Administration Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Access Control Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Application Encapsulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Object-Oriented Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Object-Oriented Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

Chapter
4 Teamcenter Object Model
This chapter begins with a brief description of objects in general, then progresses to
a discussion of the Teamcenter Object Model. It also provides information on the
various objects used in the Teamcenter system and how they are related.
Object Model
The model is described using a set of two basic relationship diagrams. One set
of relationships show the class hierarchy (taxonomy) and the other shows the
associations that exist between interacting objects in the system.
This is the legend for the class object diagrams that follow.
Figure 4-1. Class Object Diagram Legend
Product Structure Object Model

For detailed information on the Product Structure object model, see Product
Structure (PS) Module.
Item and Item Revision Model

Figure 4-2 shows an illustration of an item/item revision model. The textual
definitions that follow correspond to the objects of that model type.

Chapter 4 Teamcenter Object Model
Figure 4-2. Item/Item Revision Model
Item
In Teamcenter, items are the fundamental objects used to manage information.
Items provide an identification for physical or conceptual entities about which an
organization maintains information and audit/change control. Typical uses of items
are parts, documents, and equipment. In an engineering/product development
environment, parts are identified as items. An item has the following basic
information:
• ID
A unique identifier for an item.
• Name
A user defined name to describe the item.
• Type
A classification of items that allow different types of items to be treated
separately. For example, an item may be used to manage parts and equipment.
By implementing two item types, rules can be enforced based on the type of
items that are being manipulated.
The system, as delivered, provides a generic type called item. If you
need additional types, the system administrator can create them at
your site.

Teamcenter Object Model
• Description
A text field of up to 240 characters used to describe the item.
Item Revision
Item revisions are used to reflect modifications to an item. The original item revision
is retained for historical purposes.
Each customer site defines its own procedures to determine how and when a
new item revision should be created.
An item revision has the following basic information:

• ID
A unique identifier for an item.
• Revision
A unique identifier for an item revision.
• Name
A user-defined name to describe the item revision.
Relations
Organizations produce several documents that describe, are used by, or in some
way relate to an item. For the data to be understood, it has to be associated in a
meaningful way to the item or item revision. Teamcenter associates data to items
and item revisions using relations.
Relations describe how the data is associated to an item and item revision. A dataset
containing the CAD model, which defines an item revision, is a specification of the
item revision. Similarly, a standards document describing the fit, form, and function
of a particular drawing is a requirement for the item.
An item or item revision can be related to several other objects, including datasets,
forms, folders, and other items and item revisions. Each object associated to the item
represents various aspects of that item. A dataset containing stress test information
could be added by the engineer, while a form containing size and weight information
could be added by the specification engineer.
Teamcenter provides a basic set of relations. The relations between the object and
the item and item revision determines the rules enforced.
Additional relations and their associated rules are defined by your system
administrator.
• Master_form
The master_form relation associates a form to an item or item revision. This
form is a collection of attributes that describe the item or item revision. Rules
for this relation are as follows:
– An item or item revision must have write access to add or remove a

master_form relation to a form.

– Only a form can have a master_form relation to an item or item revision.
– An item can have only one master form. An item revision can have only
one master form.
– A form can have a master_form relation to only one item or item revision.
• Requirement
The requirement relation associates data to an item or item revision, such as
standards, which must be adhered to in a drawing, or technical requirements for
a part. Rules for this relation are as follows:
– An item or item revision must have write access to add or remove a

requirement relation to an object.
– A form can have a requirement relation to an item or item revision.
– Only version 0 (zero) of a dataset can have a requirement relation to an

item or item revision.
– A folder, envelope, BOMView, or BOMView Revision cannot have a

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

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

revision.
– An item revision cannot have a requirement relation to another item

revision if they are both revisions of the same item.
• Manifestation
The manifestation relation associates other related data to an item or item
revision. This data may, however, be necessary for information, such as analysis
of the competing ideas from which a part was originally conceived. The
manifestation relation also associates data to the item revision that contains
data derived from the specification data (such as tool paths). Rules for this
relation are as follows:
– An item or item revision does NOT need to have write access to add or
remove a manifestation relation to an object. A manifestation relation
can be added or removed from a released item or item revision.
– A form can have a manifestation relation to an item or item revision.
– Only version 0 (zero) of a dataset can have a manifestation relation to an

– A folder, envelope, BOMView, or BOMView Revision cannot have a

manifestation relation to an item or item revision.
– An item cannot have a manifestation relation to another item or item

revision.

– An item revision can have a manifestation relation to another item or

item revision.
– An item revision cannot have a manifestation relation to another item

• Specification
The specification relation associates data which defines the item revision.
Examples are CAD models for parts or word processor files for documents. Rules
– An item revision must have write access to add or remove a specification

relation to an object.
– A form can have a specification relation to an item or item revision.
– Only version 0 (zero) of a dataset can have a specification relation to an

– A folder, envelope, BOMView or BOMView Revision cannot have a

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

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

revision.
– An item revision cannot have a specification relation to another item

• Reference
The reference relation associates any data to an item or item revision. Rules
– An item or item revision does not need to have write access to add or remove
a reference relation to an object. A reference relation can be added or
removed from a released item or item revision.
– Any object can have a reference relation to an item or item revision.
– Only version 0 (zero) of a dataset can have a reference relation to an item

or item revision.
– A reference object cannot reference itself.
• Revision
The revision relation associates item revisions to the appropriate item. Rules
– An item must have write access to add or remove an item revision from
the item.
– Only an item revision can have a revision relation to an item.

– The revision relation in an item is established by creating a new revision of

an item using the provided functionality. An item revision cannot be cut or
pasted into an item.
• BOMView
The BOMView relation associates the product structure to an item. Rules for
this relation are as follows:
– An item can only have one BOMView relation.
– A BOMView relation can represent the product structure of only one item.
• BOMView Revision
The BOMView Revision relation associates a product structure revision to an
item revision. Rules for this relation are as followed:
– An item revision can only have one BOMView Revision relation.
– A BOMView Revision relation can represent the product structure of only

one item revision.
Modifying an Item/Item Revision

Teamcenter is designed to organize the data created by other applications in a logical
manner. When an item is first created, an item ID is reserved. It is only by adding
data to an item, however, that the item becomes meaningful.
Datasets are used to store information created by other applications. These datasets
can be associated to an item and item revision.
In Teamcenter, both item revision and dataset versions are intended to represent
modifications to information. Item revisions represent the item at significant
milestones. Dataset versions represent day to day changes. An item has revisions;
a dataset has versions.
There are two ways to modify an item and item revision. One method is to simply
add or remove relations from the item and item revision by using cut and paste.
Another method is to modify the contents of an object that is currently related to the
item and item revision.
Item Type
Types are used to specialize the behavior of Teamcenter objects. Datasets implement
the most extensive use of type. The dataset type is used to categorize datasets.
Examples of dataset types are a document, an NX part, and a spreadsheet. When
a document dataset type is opened, the word processor application associated to
this dataset type is opened. When an NX part dataset type is opened, the NX
application associated to this dataset type is opened. For each dataset type, the
available operations (for example print and open) are defined, as well as the specific
behavior of each operation.
Item types extend the ability to specialize the behavior of items. You may need
to distinguish between a part used in production and equipment used to produce
that part. Both may need to be an item, yet the information and business rules
surrounding these items are different.

The system, as delivered, provides a generic item type called item. If you
need additional types, they can be created by the system administrator
at your site.
Dataset Model
Figure 4-3 shows the RevisionAnchor that creates a new logical dataset.
Figure 4-3. Dataset Model
Unique ID Enforcement
The unique ID enforcement is performed at the application level. Each time the
New→Dataset command is used to create a dataset, the Save As and Import
commands are used, or the dataset is edited using the Properties command,
the validation function is called to ensure the dataset ID (id) and revision (rev)
combination is unique within that specified dataset type.
Also, for each dataset type, if the dataset ID is created using the Assign button, a
separate counter generates the next unique id that is available for a standalone
dataset. This counter ensures the id and rev is unique within the same dataset type.
Form Model
Forms provide the ability to store customer defined attributes. Teamcenter provides
standard forms. Most of the forms used at a customer site, however, are modified to
capture the information unique to its business.
Forms can be stored as POM objects. Attributes in the forms can be set and retrieved
using Form ITK functions. Forms stored as POM objects can use the POM query
ITK functions in addition to the Form ITK functions. When a form is stored as a
POM object, the database schema must be updated to recognize the new POM object.
Figure 4-4 show a diagram of the form model.

Figure 4-4. Form Model
System Administration Model

The POM_application_object class and all its subclasses have owners and
protection which can be altered by the system administrator. Figure 4-5 shows a
diagram of the system administration model.
Figure 4-5. System Administration Model

Access Control Model

Access control list (ACL) entries consist of a reference to a group and/or a user and
the access rights grant to such a subject. A subject is an object that can be granted
access rights in Teamcenter. Figure 4-6 shows a diagram of the access control model.
Figure 4-6. Access Control Model
Application Encapsulation Model

The application encapsulation data model is designed to enable Teamcenter to
maintain relations between data and the applications that can present it to the
end user.
The model provides a means of declaring an application to Teamcenter by creating
instances of the Tool class. It also provides a means of determining which tool
to use for the creation and manipulation of various pieces of data. This is done
by providing a DatasetType object class for you to use when specifying the tools
that can create and manipulate data.
A tool can be a shell. A shell is an executable image written to execute other
legacy images. The shell uses the ITK to extract data from Teamcenter and update
Teamcenter with data created by the execution of legacy systems. A shell can be
developed that manages all applications at a site that can be invoked and supplied
input on the command line. This shell can present a form to the user to fill out before
executing the legacy system so the shell can make any records that site may need
for any other reasons.
A shell could also be developed to copy data from Teamcenter into a temporary or
working directory from which a legacy (non-integrated) application is run. This
allows some support for applications that always require interactive input. If the
shell moves required files into the working directory, and the application reads files
from the current directory if only file names are specified, it would be very difficult to
put procedures in place that require the user to use only file names when using such
applications. If this is done, a shell can prepare data for an application, record the
state of the directory and use that information to determine what happened after the
application is terminated. In this type of example, the input/output parameters of
the application declaration in Teamcenter can allow this shell to ignore some scratch
files that may be left in the directory by the executing application.
If you start from scratch, you can develop an integrated application that does not
need a shell.

The Dataset class is the workspace object that an end user sees in their workspace.
The shell or integrated application associates one or more other pieces of data to the
dataset. More often than not, this means associating files for existing applications.
Some applications require several files in order to run. When this is the case, a
named reference can be created for each file. The name of the reference is often the
extension of the file but does not have to be. A CAD system may have a file in which
it stores geometric data with a .gmd extension, finite element modeling data in a file
with a .fem extension, and drawing data in a file with a .drw extension.
For such a CAD system, you could find references named geometry, fem, and
drawing, or gmd/fem/drw as the shell chooses. If you use the extensions, users do
not have to change the reference names during import, since by default the import
assumes the reference names correspond to the file extensions.
The model shows that the named reference can refer to an ImanFile object or other
descendant class of the POM object. This means a shell can be implemented that
does not use the ImanFile object to store file data, but instead uses its own file
object to store such information. However, you should do this rarely since there is a
loss of integrity that is provided by the ImanFile object. However, the flexibility it
provides may be necessary in some cases.
The RevisionAnchor object is provided to support revisioning of datasets.
Whenever a dataset is created, a RevisionAnchor object is also created. This
object maintains a list of working revisions of the dataset. However, it is up to the
shell/integrated tool to use this facility. To use it, you must make revision copies
and then make changes to these copies.

Class Hierarchy
The information in this section describes the hierarchy of classes (taxonomy).
Understanding this hierarchy, or returning to it, helps with understanding the rest
of the Teamcenter model description, which shows relationships and gives a more
detailed description of individual classes.
Class objects have a meaningful hierarchy that relates to the Teamcenter layered
software architecture previously discussed. It is presented in an indented outline
form.
The following legend defines the mnemonic descriptions given in parenthesis in
figure 4-7.
AE Application Encapsulation
AOM Application Object Module
BOM Bill Of Materials
CR Cascade Release
EPM Enterprise Process Modeling
FL Folder Manager
FORM Forms
IMF Teamcenter Engineering File
ITEM Item
MAIL Teamcenter Engineering Mail
POM Persistent Object Manager
PS Product Structure
SA System Administration
UOM Unit of Measure
VM Teamcenter Engineering Volumes
WSOM Workspace Object

Figure 4-7 shows the more common classes in the hierarchy. For more information
about other classes, see the Schema Editor.
Figure 4-7. Class Hierarchy

Object-Oriented Data
An object is a data structure. It is basically the same as an entity or an instance of a
class. A class defines a type of object, its attributes, and methods that operate on it.
For example, folder is a class in Teamcenter. It is defined to have a name, a
description, and a list of entries. These are the attributes of the folder class. When
a folder is instantiated, an actual folder object is created. It has attributes as
described here. There are also methods or functions defined for the folder class, such
as Insert and Remove.
Attributes in Teamcenter can be integer, float, boolean, string, date, tag, or arrays of
any of the above types.
The attributes in Teamcenter can have some of following characteristics:
Unique There can be no duplicate values of the attribute in all of the

instances of the class.
The attribute can only be modified by the application that
Protected
created the object.
If this characteristic is not true, then the object cannot be saved
NULL Allowed
until the attribute is set.
Upper Bound The highest value that the attribute can have.
Lower Bound The lowest value that the attribute can have.
Inheritance
A subclass inherits both attributes and methods from superclasses.
Multiple inheritance means that a class has two superclasses. That is, it inherits
the attributes and methods from two different classes. There are no instances of
multiple inheritance in Teamcenter.
A superclass may be a generalization of many similar classes. For example, the
WorkspaceObject superclass is a generalization for all of the classes whose
instances may be seen in the workspace (for example, in a folder). All of the
attributes and methods that are common to the Dataset, Folder, and other classes
are defined once in the WorkspaceObject superclass, rather than being defined
many times. Usually, generalizations are abstract or non-instantiable. This means
that the class exists for conceptual or convenience reasons, but you cannot actually
create an instance of one.
A subclass may be a specialization of another class. For example, the Envelope
subclass is a specialization of the Folder class. In this case, a new class is being
defined that is just like another one except for some additional attributes and/or
some specialized behavior such as a specialized method.

Object-Oriented Language
An object-oriented language is a programming language that has built in key
words or constructs that either force or facilitate object oriented programming.
For example, C++ is one, because it supports classes, objects, inheritance, and
polymorphism. The C language is not.
However, you can do object oriented programming with a non-object oriented
language; it is just harder. You can certainly have an object model with inheritance
of attributes and methods without using an object oriented language. This is what
we present through ITK.
Internally, much of Teamcenter is written in C++. This provides an easy way of
handling polymorphism. You can take advantage of this in the ITK as well. If you
want to execute a method on an object, you do not need to call a function specific
to that action-class pair. You may call any function with that action up the tree of
superclasses for the selected object. For example, if you want to ask the name of an
envelope, you do not need to call the EMAIL_ask_envelope_name function (in fact,
that function does not exist). You can call the WSOM_ask_name function two levels
up in the hierarchy instead. That function realizes that it was actually passed an
envelope and invokes the envelope’s method to get the name.

Chapter
5 Using ITK Functions
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Variable Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Journal Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Teamcenter Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Fixing Invalid Unicode Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Initializing Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Special Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Linking Standalone Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13

Important Comment for linkitk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Linking User Exits in UNIX and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Linking User Exits in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Exporting New Symbols From libuser_exits.dll on Windows . . . . . . . . . . . 5-16
Compiling and Linking Server Exits in Windows . . . . . . . . . . . . . . . . . . . 5-17
Running the Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Batch ITK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21

Batch Program Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Compiling and Linking Batch Programs . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Supplier Custom Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Building the Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Registering Custom Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

Registering User Exits Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Registering Server Exits Customization . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
Executing Multiple Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Registering Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
CUSTOM_register_callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
CUSTOM_register_exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
CUSTOM_execute_callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
CUSTOM_execute_callbacks_from_library . . . . . . . . . . . . . . . . . . . . 5-32
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Registering Runtime Properties Using Custom Hooks . . . . . . . . . . . . . . . 5-34
Integration Toolkit Programmer’s Guide ENG00043 A

Chapter
5 Using ITK Functions
This chapter describes the format of ITK functions as well as details about writing,
compiling, linking, and running ITK programs.
Format
All ITK functions have a standard format that attempts to give the most information
possible in a small space. A template is shown below, followed by a more detailed
description. All prototypes are located in include files named classname.h for the
class of objects that the functions operate on. For more information about specific
functions, see the Integration Toolkit Function Reference
The design intent for the format of ITK functions is to provide the maximum amount
of information in a small space. The standard format is:
int module_verb_class_modifier ( const type variable-name[dimension]
/* [I/O/OF] */ );
int Nearly all ITK functions return an integer error code. This
code can be passed to the EMH_get_error_string function.
module This is the module designator. Related classes are
grouped together in modules. For example, the Dataset,
DatasetType, Tool, and RevisionAnchor classes are all
handled by the AE module. Other examples of modules are
PSM, POM, FL, and MAIL.
verb This is the first key word describing an action to be taken on
an object or set of objects. Common actions are create, add,
remove, copy, set, and ask.
class This is the class name or an abbreviation of the class name.
The exceptions are for modules that only deal with one class,
like Workspace or modules that deal with many classes,
like WSOM and POM.
modifier This is a word or several words that give more description of
how the action of the verb applies to the class. For example,
in the RLM_update_af_status function, status indicates
what is being updated in the af (authorization folder).
const Input pointer variables which are not meant to be modified
normally are declared with a const to ensure that they are
not accidentally modified.

Chapter 5 Using ITK Functions
type This is the data type of the argument (for example, int,
tag_t*, or char***).
variable-name This is a variable name that is descriptive enough
so a programmer does not need to look it up in the
documentation.
dimension This value is normally specified for arrays where the
calling program is responsible for allocating space. They
are normally specified with a constant definition of the
form module_description_c. These constants should be
used in dimensioning arrays or looping through the values
of an array to make your programs more maintainable.
However, you may see the values of these constants in the
include files. This is useful so you do not establish naming
conventions that leads to name strings longer than can be
passed to the functions.
I/O/OF These characters indicate whether the particular argument
is input, output or output-free. Output-free means that the
function allocates space for the returned data and this space
should be freed with the MEM_free function.

Using ITK Functions
Variable Naming Conventions

Variables in the interface are normally as descriptive as possible, consisting of key
words separated by under-bars (_).
• Typedefs end in _t.
• Constants end in _c.
• Enums end in _e.
Most typedefs and constants begin with the module designator just like the function
names to make it clear where they are meant to be used.
Class Hierarchy
Because Teamcenter is an object-oriented system, it is not necessary to have a
function for every action on every class. Usually, functions associated with a
particular class work with instances for any subclasses. For example, the FL_
functions for folders work with authorizations and envelopes. The AOM module
and the WSOM module consist of functions that correspond to the methods of the
POM_application_object and WorkspaceObject abstract classes respectively.
AOM functions work for all application objects and WSOM functions work for all
workspace objects.
When you create objects, an implicit lock is placed on the newly created
object. After you perform an AOM_save, it is important that you call
AOM_unlock.
The same mechanism described here also enables standard Teamcenter functions to
work on subclasses that you may define. For example, if you define a subclass of the
folder class, you can pass instances of it to FL functions.

Debugging
This section contains information on ITK debugging aids such as journal files and
log files.
Journal Files
Teamcenter optionally journals the calls to all of the ITK functions. This is in a
file called journal_file after the program is run. This file can be very useful in
finding out what your program has done and where it went wrong. There are 5
journaling flags in the system for the POM, PSM, RLM, SA, and CMMV modules
and ITK in general. For POM, use the POM_set_env_info function; otherwise,
use the xxx_set_journaling(int flag) function, where flag is equal to 0 (zero) for
off or not equal to 0 for on. You could have ITK and RLM journaling on if you are
working in that area and leave POM and PSM journaling off, ensuring that your
journal file does not get cluttered with uninteresting information. Figure 5-1 shows
how the POM logs input and output arguments. Input arguments are logged with
their values, output arguments are logged on the way in with their names and on
the way out with their values.
POM_start ( ’aali’, ’aali’, ’Information Manager’, user, topmost_class_id,

pom_version)
@* --> 6s
@* FM_init_module
@* --> 8s
@* EIM_PM_id_of_process ( 103, process_id)
@* process_id = 558 returns 0
@* returns 0 [in 2 secs]
@* AM_init_module
@* FM_init_module
@* returns 0
@* FM_allocate_file_id ( file)
@* returns 0, file = 000127cc08b2
@* --> 9s
@* AM_identify_version ( identity)
@* returns 0
@* returns 0
@* EIM_PM_id_of_process ( 105, process_id)
@* process_id = 559 returns 0
@* --> 10s
@* FM_read_file ( 00650002)
@* returns 0 @* --> 11s
@* FM_ask_path ( 00650002, 750, path)
@* returns 0, path = ’/home/demov2/user_data/d1/f000627cbd90f_pom_schema’
@* --> 12s
@* FM_unload_file ( 00650002)
@* returns 0
@* --> 14s
@* FM_allocate_file_id ( file)
@* returns 0, file = 000227cc08b2
@* user = 006500e0 <QAscMZ60AAAAyD>, topmost_class_id = 006500d0, pom_version = 100
returns 0 (in 16 secs)
Figure 5-1. Journal File Example 1

Using ITK Functions
Figure 5-2 shows another example of a journal file.
POM_name_of_class ( 00650021, class_name)

@* class_name = ’Signoff’ returns 0
POM_class_id_of_class ( ’Signoff’, class_id)

@* class_id = 00650021 returns 0
POM_describe_class ( 00650021, NULL, application_name, descriptor, n_attrs, attr_ids)

@* application_name = ’Information Manager’, descriptor = 0, n_attrs = 4,
@* attr_ids = { 00650022, 00650023, 00650024, 00650025 } returns 0
POM_describe_attrs ( 00650021, 4, /
{ 00650022, 00650023, 00650024, 00650025 }, names, types, max_string_lengths,

referenced_classes, lengths, descriptors, attr_failures)
@*
@* names = { ’comments’, ’decision’, ’group_member’, ’decision_date’ },
@* types = { 2008, 2005, 2009, 2002 },
@* max_string_lengths = { 240, 0, 0, 0 },
@* referenced_classes = { 00000000 <AAAAAAAAAAAAAA>, 00000000 <AAAAAAAAAAAAAA>,
00650054, 00000000 <AAAAAAAAAAAAAA> },
@* lengths = { 1, 1, 1, 1 },
@* descriptors = { 64, 0, 0, 64 },
@* attr_failures = { 0, 0, 0, 0 } returns 0
POM_free ( 0041ac28)
@* returns 0
POM_subclasses_of_class ( 00650021, n_ids, subclass_ids)

@* n_ids = 0, subclass_ids = {}
@* NULL array pointer, length 0
@* returns 0

The first few hundred lines of a journal file contain a lot of text like the example
above. This is the result of reading in the schema. If you define POM classes, you
can see this information in there also. This is helpful in determining if you have in
the database what you think you have in it. Also, when you see class IDs or attribute
IDs elsewhere in the journal file, you can refer to this section to see what they are.

Figure 5-3 is an example of an application function being journaled.
RLM_ask_approver_roles ( 006500e1)
@* POM_length_of_attr ( 006500e1, 00650009, length)
@* length = 1 returns 0
@* POM_length_of_attr ( 006500e1, 00650009, length)
@* length = 1 returns 0
@* POM_ask_attr_tags ( 006500e1, 00650009, 0, 1, values, is_it_null,
is_it_empty)
@* values = { 006500dc <AAlccPghAAAAyD> }, is_it_null = { FALSE },
@* POM_free ( 0041cf50)
@* returns 0
@* POM_free ( 0041d390)
@* returns 0
@* role_count = 1, approver_roles = { 006500dc <AAlccPghAAAAyD> } returns 0

The journal information for lower level routines are nested inside the higher level
routines.
System Logs
In general, the system log is less useful, but sometimes you may see a
POM_internal_error or something else that does not make sense to you. You can
look in the system log to understand what went wrong. For example, if your program
crashes you may not have an error message, but the end of the system log may show
what the program was trying to do just before crashing.
Logging
For more information on logging, see the Log Manager (LM) module reference
section in the Integration Toolkit Function Reference.

Using ITK Functions
Error Handling
Teamcenter Errors
Teamcenter stores errors on a central error stack. An error may be posted at a
low level and each layer of the code handles the error reported by the level below,
potentially adding a new error of its own to the top of the stack to add more
contextual information to the exception being reported. This stack of errors is
what you see displayed in the Teamcenter error window in the user interface. ITK
functions always return the top error from the stack if there is one. If the call is
successful, ITK_ok is returned.
The Error Message Handler (EMH) ITK functions enable you to access the full
error stack and decode individual Teamcenter error codes into the internationalized
texts that are defined in the UIL code and displayed in the error windows at the user
interface. EMH ITK functions are defined in the emh.h header file. They give
the ability to store errors, access errors on the stack, and decode error codes into
internationalized text. For additional information on EMH functions, see the EMH
section in the Integration Toolkit Function Reference manual.
It is good practice to acknowledge that you have received and handled an
error reported by an ITK call by clearing the error store with a call to the
EMH_clear_errors function. However, if you do not do this it normally
does not cause a problem, as all initial errors should start a new stack with
a call to the EMH_store_initial_error function.
Fixing Invalid Unicode Characters

If an object attribute has an invalid Unicode character in it, the workspace object
gives an invalid Unicode character error in the rich client’s DOS window for some
operations, such as expanding a folder. It also may make a large number of network
calls, which dramatically slows Teamcenter operations. To determine if this is the
case, follow these steps:
1. Enable the rich client CORBA call profiler by adding the following line to the
client_specific.properties file:
corbaCallProfiler=start
2. Log in to Teamcenter.
3. Clear the Teamcenter Network Communications Profiler.
4. Perform a workspace object operation, such as expanding a folder.
5. Update the CORBA call profiler. You can see the icct calls for the workspace
object operation.

If there are a larger number of network calls, check the rich client’s DOS window for
an invalid Unicode character error for this operation. The error looks like this:
DefaultValidationEventHandler: [FATAL_ERROR]: An invalid XML character
(Unicode: invalid-character) was found in the value of attribute
"attribute" and element is "element".
If it is an invalid character error, open the gateway response in the Teamcenter

Network Communication Profiler with a text editor. In figure 5-4, the 003104-Arch
Modeler Var Enh-Phase 2 item has an invalid character in its description
(Architecture Modeler Variability Enh Phase II):
<TcResponse>
<TcCorbaResponse>
<Arg name="propertyUIFValueSet">
<Array><Entry>
<Array>
<Entry>
<Struct>
<Arg name="_discriminator" val="1"/>
<Arg name="string_value" val="003104-Arch Modeler Var Enh-Phase
2"/>
</Struct>
</Entry>
<Entry>
<Struct>
<Arg name="string_value" val=""/>
</Struct>
</Entry>
<Entry>
<Struct>
<Arg name="string_value" val="Item"/>
</Struct>
</Entry>
<Entry>
<Struct>
<Arg name="string_value" val="Architecture Modeler Variability Enh
□ Phase II"/>
</Struc>
</Entry>
Figure 5-4. Gateway Response Example

Using ITK Functions
If you have an invalid Unicode character, you can use the code shown in figure 5-5 as
a template to create your own ITK utility to fix the problem:
#include <iman.h>
#include <emh.h>
#include <pom.h>
#include <WSO-object-header-file.h>
// for example, if the item description has an invalid
// Unicode character, you must use #include <item.h>
int ITK_user_main(int argc,char* argv[])

{
int ifail = ITK_ok;
char * message;
tag_t item_tag;
char item_desc[ITEM_desc_size_c+1];
ITK_initialize_text_services(0); //to get the correct error strings
ifail = ITK_auto_login();
// Attempts an automatic login first by assuming sufficient
// data is available on the command line
ITK_set_journalling(TRUE);
// it only controls additional journalling that
// takes place inside your custom ITK code.
if(ifail != ITK_ok)
{
EMH_ask_error_text(ifail, &message);
printf("Error : Could not get User info : %d , %s \n",ifail,message);
MEM_free(message);
return ifail;
}
// Use appropriate ITK API to find the WSO

// Example shown below
ifail = ITEM_find_item ( "003104", &item_tag );
// Use appropriate ITK API to fix the corrupted field

ifail = ITEM_set_description ( item_tag, "Architecture Modeler
Variability Enh Phase II");
// Use appropriate ITK API to save the WSO

ifail = ITEM_save_item( item_tag );
// Use appropriate ITK API to show the property that has

// been fixed for verification
ITEM_ask_description ( item_tag, item_desc );
printf ( "Desc = %s\n", item_desc );
AOM_save(item_tag);
AOM_refresh(item_tag, false);
/* do clean up before exit..*/
ITK_exit_module(TRUE);
return ifail;
}
Figure 5-5. Code Template to Fix Invalid Characters

Memory Management
Frequently, memory is allocated by an Teamcenter function and returned to the
caller in a pointer variable. This is indicated in the code by the /* <OF> */ following
the argument definition. This memory should be freed by passing the address to the
MEM_free function. For example, to use the function:
int AE_tool_extent (
int* tool_count, /* <O> */
tag_t** tool_tags /* <OF> */
);
You should include the following code:

{
tag_t* tool_tags;
int tool_count;
int error_code;
int i;
error_code = AE_tool_extent &tool_count, &tool_tags);

if( error_code == ITK_ok )
{
for (i = 0; i < tool_count; i++)
{...}
MEM_free (tool_tags);
}
else
report the error

...
Include Files
All ITK programs must include iman.h. It has the prototype for ITK_init_module
and the definition of many standard datatypes, constants and functions that almost
every ITK program requires, such astag_t, ITK_ok, and MEM_free.
All of the other ITK functions have their prototypes and useful constants and types
in a file called classname.h. In addition there are header files for many of the major
modules that contain constants and include all of the header files for the classes in
that module. Sometimes this header file is required, sometimes it is just convenient.
The Integration Toolkit Function Reference manual tells you which header files
are required.

Using ITK Functions
For example, you could write:

#include "sa.h"
Or you could write:

#include "am.h"
#include "sa_errors.h"
#include "person.h"
#include "role.h"
#include "group.h"
#include "groupmember.h"
#include "user.h"
#include "site.h"
There is also an error include file for every module called module_errors.h or
sometimes classname_errors.h. These all contain error offsets from a value
assigned in the EMH_const.h file. One exception is POM which has its errors in
the POM_errors.h file.
Teamcenter also comes with a set of include files that mimic standard C include files.
For example, instead of using:
#include stdarg.h
You could use:

#include "iman_stdarg.h"
These include files are used in Teamcenter to insulate it from the operating system.
Sometimes the files include the system files directly, but other times system
dependencies are handled in the iman_ include files, thus enabling the Teamcenter
source code and yours to remain system independent. The files provided are:
• iman_ctype.h
• iman_errno.h
• iman_limits.h
• iman_math.h
• iman_stat.h
• iman_stdarg.h
• iman_sddef.h
• iman_stdio.h
• iman_stdlib.h
• iman_string.h
• iman_time.h
• iman_types.h
• iman_unixio.h

Initializing Modules
You must call the module initialization functions, such as FL_init_module, before
using any of the functions in that module. If you do not, you get an error like
FL_module_not_initialized. The only reason that a module initialization should
ever fail is if the module requires a license and there is no license available.
You should also remember to exit modules. In some cases this could cause significant
memory to be freed. It may also free up a concurrent license for use by another user.
Special Data Types

All objects in the ITK are identified by tags of C type tag_t. A run-time unique
identifier isolates the client code using the object from its representation in memory,
making it safe from direct pointer access.
Tags may be compared by use of the C language == and != operators. An unset tag_t
variable is assigned the NULLTAG null value. If two tags have the same value, they
reference the same object. For example:
#include "iman.h"
#include "ae.h"
{
tag_t dataset_tag;
int error_code;
login, etc. ...
error_code = AE_find_dataset ("my special dataset", &dataset_tag)

if( error_code ==ITK_ok )
{ if (dataset_tag == NULLTAG)
{ /*
* Could not find my special dataset, so go create one.
*/
error_code = AE_create_dataset_with_id (....
}
}
else
report error ....

Using ITK Functions
Compiling
Compile your program using the ANSI option. The ITK functions can also be called
from C++. Sample compile scripts are available in the IMAN_ROOT/sample
directory. Assuming the script name is compile, it can be used by executing the
following command.
IMAN_ROOT/sample/compile filename.c
The actual compile statements are as follows:
• HP
cc filename.c -c -Aa filename.o -D_HPUX_SOURCE -DHPP -I$IMAN_INCLUDE
• SOLARIS
cc -KPIC -DSUN -DUNX -D_SOLARIS_SOURCE -DSYSV +w -Xc -O -I.
-I${IMAN_INCLUDE} -c filename.c -o filename.o
• Linux
gcc -c -fPIC -m64 -DPOSIX -I${IMAN_INCLUDE} filename.c -o filename.o
• Windows
If you are using Windows, you must supply the -DIPLIB=none argument to tell
the compile script that a standalone program object is being compiled:
$IMAN_ROOT/sample/compile -DIPLIB=none filename.c
Linking Standalone Programs

When you link your program, you must include the itk_main.o file on the command
line. This file contains the main object for your ITK program. To make this work, all
of your ITK programs must begin like this:
int ITK_user_main(int argc, char* argv[])
{ int result;
/*
* We should use ITK_auto_login here.
*/
if( (result = ITK_auto_login()) == ITK_ok)

{
do what you need to do ...
result = ITK_exit_module();
}
return result;
}
The order of Teamcenter libraries is important or your code may not link. Also add
any additional object files you have created to the link script to include them in the
main executable. A sample linkitk script file exists in the IMAN_ROOT/sample
directory.
If the script name is linkitk, you can execute the script with the following command.
$IMAN_ROOT/sample/linkitk -o executable-name filename.o

Important Comment for linkitk

Check that you are using the correct Oracle libraries for a given Teamcenter release
when linking client programs. The release notes give the required Oracle release.
The reason for this requirement is that the Teamcenter libraries include some object
files derived from Oracle’s Pro*C preprocessor. This generates C calls for Oracle’s
libraries. Given the embedded SQL Teamcenter uses is Oracle’s published interface
and not the C libraries, it is important that the correct Oracle libraries consistent
with the version of Pro*C used to generate Teamcenter libraries be present for ITK
application builders at customer sites.
The Teamcenter-supplied version of Oracle is the correct version for ITK user
programs. Therefore, the above information should be relevant only where ITK
customers are building images against an independently installed Oracle system.
Be careful of upgrading Oracle without upgrading Teamcenter.
Additionally, this information only effects those building the ITK client programs.
Once linked correctly, the Oracle (archive) libraries required are linked into the
program statically and therefore do not depend upon the version of Oracle libraries
available at the point of using ITK programs.
Linking User Exits in UNIX and Linux

To verify your UNIX or Linux environment and installation:
1. Set the Teamcenter environment.
2. Create a user_exits and code directories.
3. Extract the objects with the following commands:

$ cd user_exits
$ ar -x $IMAN_ROOT/lib/libuser_exits.a
4. Complete your customization. It is good practice to include a printf statement

with a coding version and compile date. The following is a minimal example:
$ cd ../code
a. Copy all of the files that you want to modify (user_gsshell.c in the following
example):
$ cp $IMAN_ROOT/sample/examples/user_gsshell.c .
b. Make the required changes.

For example, include your own printf statement in the
USER_gs_shell_init_module function in the user_gsshell.c
file:
printf("\nCustom library for %s, version %s, compiled on %s %s\n\n",
customer, version, _DATE_, _TIME_);
c. Create additional .c files as required, but see below for Windows

considerations when exporting new symbols from the library.

Using ITK Functions
5. Compile your library objects and move them into the library directory:
$ $IMAN_ROOT/sample/compile *.c
$ cp *.o ../user_exits
6. Move into the library directory and link the library:

$ cd ../user_exits
$ $IMAN_ROOT/sample/link_user_exits
7. You now have a new libuser_exits.s file. Set the IMAN_USER_LIB command
to get Teamcenter to use it:
$ export IMAN_USER_LIB=’pwd’
$ $IMAN_BIN/iman
You see your printf messages after the Teamcenter copyright messages.
If the libuser_exits.so (or libuser_exits.sl on Hewlett-Packard) file compiles

without undefined symbols, then the installation and environment are correct.
Linking User Exits in Windows

To verify your Windows environment and installation:
1. Set the Teamcenter environment.
2. Create a user_exits and code directories.
3. Extract the objects with the following commands:

$ cd user_exits
$ extract_objects %IMAN_ROOT%\lib\libuser_exits.ar.lib
4. Complete your customization. It is considered good practice to include a printf

statement with a coding version and compile date. The following is a minimal
example:
$ cd ../code
a. Copy all of the files that you want to modify (the user_gsshell.c file in the
following example):
$ cp $IMAN_ROOT/sample/examples/user_gsshell.c .
b. Make the required changes.

For example, include your own printf statement in the
USER_gs_shell_init_module function in the user_gsshell.c
file:
printf("\nCustom library for %s, version %s, compiled on %s %s\n\n",
customer, version, _DATE_, _TIME_);
c. Create additional .c files as required, but see below for considerations when
exporting new symbols from the library.

5. Compile your library objects and move them into the library directory.
%IMAN_ROOT%\sample\compile -DIPLIB=libuser_exits *.c
copy *.obj ..\user_exits
6. Move into the library directory and link the library. You do not need .def files.
cd ../user_exits
%IMAN_ROOT%\sample\link_user_exits
7. You now have new libuser_exits.dll and libuser_exits.lib files. Set the
IMAN_USER_LIB command to get Teamcenter to use it.
To run standalone programs against this libuser_exits.dll library, you
must link them against the corresponding libuser_exits.lib file.
for /f "delims==" %i in (’chdir’) do set IMAN_USER_LIB=%i

%IMAN_BIN%\iman
You see your printf messages after the Teamcenter copyright messages.
Exporting New Symbols From libuser_exits.dll on Windows

Windows requires all symbols exported from .dll files to be declared. This
mechanism is invisible to UNIX, which exports every extern as usual (so you do not
need two sets of source).
In each header file declaring new functions for export from the .dll file:
1. Enter #include <libuser_exits_exports.h> as the last #include of the header
file before all declarations.
2. Enter USER_EXITS_API after the word extern to mark each function

declaration for export. This is called decoration.
3. Enter #include <libuser_exits_undef.h> at the end of the header file after all
declarations (within any multiple include prevention preprocessing).
In each source file defining new functions for export from the .dll file, ensure that
the .c file includes its own corresponding .h file, so the definitions in the .c file know
about the decorated declarations in the .h file. If you do not do this, the compiler
complains about missing symbols beginning with __int__ when you try to link
standalone code against the libuser_exits.lib file.
Now you can compile and link as normal (in other words, compile with
–DIPLIB=libuser_exits).

Using ITK Functions
Compiling and Linking Server Exits in Windows

You can use the UserService mechanism to call your ITK functions from Java in
the rich client. First register your ITK functions in the user_server_exits.c file.
Then compile this file and your source code and link them into the libserver_exits
library to make the functions available to the rich client.
1. In the IMAN_ROOT\bin directory, back up your old libserver_exits.dll library
file.
2. Copy the user_server_exits.c and user_server_exits.h files from the

IMAN_ROOT/sample/userservice directory to your working folder.
3. Register your ITK functions in the user_server_exits.c file. For example, if you
wanted to register an ITK function called ACME_PasteRevToNewstuff in the
user_server_exits.c file, the file would look like figure 5-6:
#include <user_server_exits.h>
#include <acme_userservice.h>
extern DLLAPI int USERSERVICE_register_methods ()

{
int status = ITK_ok;
int iNumberOfArgs = 0;
int *piArgTypes = NULL;
/*
* This function registers the server side user defined functions for the
* CORBA server
*/
iNumberOfArgs = 2
piArgTypes = (int*) SM_alloc_persistent (iNumberOfArgs * sizeof (int));
piArgTypes[0] = USERARG_STRING_TYPE;
piArgTypes[1] = USERARG_STRING_TYPE;
USERSERVICE_register_method( "ACME_PasteRevToNewstuff",
ACME_PasteRevToNewstuff,
iNumberOfArgs,
piArgTypes,
USERARG_TAG_TYPE);
return (status);
}
Figure 5-6. user_server_exits.c File Example
4. Compile your code and the user_server_exits.c file using the compile.bat
script in the IMAN_ROOT\sample directory with the following command:
%IMAN_ROOT%\sample\compile -DIPLIB=libserver_exits
user_server_exits.c your-source-code.c

5. Link the server exits using the link_server_exits.bat script in the

IMAN_ROOT\sample directory with the following command:
%IMAN_ROOT%\sample\link_server_exits
6. Copy the new libserver_exits.dll library file to the IMAN_ROOT\bin directory.
You can then call your ITK functions from the rich client. For example, if you
wanted to call the ACME_PasteRevToNewstuff function from a JPanel within an
application, the code would look like figure 5-7:
package com.acme.newapp;
import java.lang.Object;
import java.awt.*;
import javax.swing.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import com.ugsolutions.aif.*;
import com.ugsolutions.aif.kernel.*;
import com.ugsolutions.iman.kernel.*;
import com.ugsolutions.util.*;
public class NewAppApplicationPanel extends JPanel

{
JTextPane JTextPane1 = new JTextPane();
private AbstractAIFUIApplication application = null;

private IMANSession session = null;
private IMANUserService service = null;
private IMANComponent component = null;
public class NewAppApplicationPanel( AbstractAIFUIApplication app )

{
super (new BorderLayout());
application = app;
session = (IMANSession)application.getSession();
try
{
service = (IMANUserService)session.getUserService();
}
catch( IMANException e )
{
}
JtextPane1.setCaretColor(Color.red);
JtextPane1.setText(“Welcome”);
JtextPane1.setForeground(Color.magenta);
this.add (JTextPane1, null);
add( “North”, app.getApplicationHeader());
Object objs[] = new Object[2];
Figure 5-7. Java Code Example (Continued)

Using ITK Functions
String itemID = new String( “000001”);

String revID = new String( “A”);
objs[0] = itemID;
objs[1] = revID;
try
{
component = (IMANComponent) service.call( “ACME_PasteRevToNewstuff”, objs);
}
catch( IMANException e )
{
MessageBox msgBox = new MessageBox( e );
msgBox.setModal( true );
msgBox.setVisible( true );
}
}
public NewAppApplicationPanel()
{
try
{
jbInit();
} catch( Exception e )
{
e.printStackTrace();
}
}
private void jbInit() throws Exception

{
}
Figure 5-7. Java Code Example

Running the Executable

To run or execute the program, you must have Teamcenter system privileges (in
other words, an account on Teamcenter). If your program is called without the
ITK_auto_login function, supply the arguments for user, password and group. If
the ITK_auto_login function is used, the necessary arguments can come from
the command line. The specific style for entry is dependent on your code. In this
class, the standard procedure is as follows:
filename -u=user -p=password -g=group
Be careful to execute this command in a directory where additional files can be

created since session and log files are created at run time.

Using ITK Functions
Batch ITK
You can create batch ITK programs that are executed on a command line. Batch
programs log into the Teamcenter database using information on command line,
perform some actions, and then exit.
Batch Program Template

Figure 5-8 shows a template for writing a batch program:
#include <iman.h>
#define WRONG_USAGE 100001
void dousage()
{
printf("\nUSAGE: template -u=user -p=password -g=\"\" \n");
return;
}
int ITK_user_main(int argc, char* argv[])

{
int status;
char* usr = ITK_ask_cli_argument("-u=");/* gets user */
char* upw = ITK_ask_cli_argument("-p=");/* gets the password */
char* ugp = ITK_ask_cli_argument("-g=");/* what the group is */
char* help = ITK_ask_cli_argument("-h=");/* help option */
char *s;
if ( (help) )
{
dousage();
return WRONG_USAGE ;
}
/* Example of must have... */

if (( !usr) || (!upw) || (!ugp))
{
dousage();
return WRONG_USAGE ;
ITK_initialize_text_services (0);
status = ITK_init_module( usr,upw,ugp);
if ( status != ITK_ok)
{
EMH_ask_error_text( status, &s);
printf("Error with ITK_init_module: %s \n",s);
SM_free(s);
return status;
}
else printf("Logon to ’template’ succesful as %s.\n", usr);
Figure 5-8. Batch Program Template (Continued)

JOURNAL_comment ("Preparing to list tool formats");

lprintf("Preparing to list tool formats");
/* Call your functions between here */
ITK_exit_module( TRUE);
return status;
Figure 5-8. Batch Program Template

Using ITK Functions
Compiling and Linking Batch Programs

Follow this sequence to generate executables for batch programs.
Make sure the following environmental variables are set correctly:
• MSDEV_HOME
The home directory of the MSDEV VC++ compiler
• IMAN_INCLUDE
The Teamcenter include files directory
• USER_INCLUDE
Includes any user-specific header files
1. Compile the batch program with the compile script:

compile -DIPLIB=none filename.c
The –DIPLIB argument specifies the target library; use none for batch
programs.
2. Link your program with the system library with the linkitk script:
linkitk -o executable filename.obj file3.obj file2.obj
3. Execute the batch program:

• If you use ITK_auto_login:
filename arguments
• If you use ITK_init_module:

filename -u=user -p=password -g=group arguments
The compile and linkitk scripts are Teamcenter-specific scripts and are available
in the IMAN_ROOT/sample directory.

Supplier Custom Hooks
Introduction
Custom hooks allow nonconflicting customizations to co-exist.
Environment
All the server-side customizations of the site, including user_exits and server_exits
are built in the form of a single library, called site-name.dll/so/sl.
For example, if the site name is tceng_cust1, the library is tceng_cust1.dll/so/sl.
The custom library site-name.dll/so/sl is linked with libuser_exits. Use the
link_custom_exits/link_customer_exits.bat file from the IMAN_ROOT/sample
directory. All custom standalone ITK utilities are linked with the site-name.dll/so/sl
file instead of libuser_exits as the customization is in the site-name.dll/so/sl
file. To see the customization, define the custom library name in the
IMAN_customization_libraries preference. Make sure the prefix and the library
prefix mentioned above are the same. Set the preference in the Options dialog
window, accessed from the Edit menu in My Navigator. For additional information
on setting preferences, see My Navigator Help.
Building the Library File

To build the library file, follow these steps:
1. Create a working directory (for example, tceng_cust1).
2. Copy all your user exits and server exits customization code to this directory.
3. Compile your object files inside this directory using the

IMAN_ROOT/sample/compile command with the –DIPLIB=NONE
option.
4. Build the dynamic linked/shared library with the link_custom_exits command.

For example:
link_custom_exits tceng_cust1
• Do not modify or rebuild the libuser_exits and libserver_exits

libraries with the custom code.
• Do not unarchive the libuser_exits.ar.lib file. These object files

are not required to be linked with the tceng_cust1 library.
5. If you are using Windows, copy the .dll and .PDB files to the directory that
contains the .dll files. For example,
copy tceng_cust1.dll %IMAN_ROOT%\\bin\\.
copy tceng_cust1.pdb %IMAN_ROOT%\\bin\\.
If you are using UNIX, copy the shared library to the IMAN_USER_LIB
directory or put the tceng_cust1 directory in the shared library path
(Hewlett-Packard: SHLIB_PATH, Solaris: LD_LIBRARY_PATH).

Using ITK Functions
Registering Custom Callbacks

Create a site-name_register_calls.c file in the site’s source code development area.
Figure 5-9 shows an example.
#include <custom.h>
#include <user_exits.h>
#include your-include-files
extern DLLAPI int tceng_cust1_register_callbacks()
{
USER_register_custom_exit (“site-name”, “Base User Exit Function”, (CUSTOM_EXIT_ftn_t)
your-custom-function-name);
}
Figure 5-9. Register Custom Callbacks Example

• site-name_register_callbacks
This is the entry point to the custom library. This function is executed after
loading the custom library. Ensure that the site-name name is the same as
the value stored in the IMAN_customization_libraries preference. For
example, if the custom library is tceng_cust1, this function should be called
tceng_cust1_register_callbacks.
• site-name argument to the USER_register_custom_exit

site-name is also the same as the value stored in the
IMAN_customization_libraries preference.
• Base user exit function

This string is the name of the base user exit against which the custom function
is registered. All the USER_ and USERSERVICE_ functions from the files
provided in the IMAN_ROOT/sample directory can be customized.
• your-custom-function-name
This is the function pointer registered against the above base user exit. The
definition of this function does not need to exist in this file, it could be in another
file.
• your-include-files
Add any custom include files needed during the compilation and linking of the
custom library.

Registering User Exits Customization

Custom hooks provide you the ability to:
• Execute only site customization
• Execute site customization along with other customizations
• Execute the default core functionality
The custom functions registered in the site-name_register_calls.c file should have

an integer pointer as the first argument. This integer pointer should return the
decision, indicating whether to execute only the current customization, execute all
customizations, or only the default core functionality. The following variables are
defined in the custom.h file in the IMAN_ROOT/include directory:
#define ALL_CUSTOMIZATIONS 2
#define ONLY_CURRENT _CUSTOMIZATION 1
#define NO_CUSTOMIZATIONS 0
Figure User Exits Customization Example shows an example with the following
conditions:
• The site name is tceng_cust1.
• The custom library is tceng_cust1.
• A custom function is registered against the USER_new_dataset_name.
tceng_cust1_register_calls.c:
#include <custom.h>
#include <tceng_cust1_dataset.h>
#include <tceng_cust1_register_callbacks.h>
{
USER_register_custom_exit (“tceng_cust1”, “USER_new_dataset_name”, (CUSTOM_EXIT_ftn_t)
TCENG_CUST1_new_dataset_name);
}
tceng_cust1_register_callbacks.h:
extern DLLAPI int tceng_cust1_new_dataset_name (int *decision, va_list args);
tceng_cust1_dataset.c:
#include <custom.h>
Figure 5-10. User Exits Customization Example (Continued)

Using ITK Functions
extern DLLAPI int TCENG_CUST1_new_dataset_name (int *decision, va_list args)

{
/*
Expand the va_list using va_arg
The va_list args contains all the variables from USER_new_dataset_name.
*/
tag_t owner = va_arg (args, tag_t);
tag_t dataset_type = va_arg (args, tag_t);
tag_t relation_type = va_arg (args, tag_t);
const char* basis_name = va_arg (args, const char *);
char** dataset_name = va_arg (args, char **);
logical* modifiable = va_arg (args, logical *);
/*
if tceng_cust1 wants all other customizations to be executed, then set
*decision = ALL_CUSTOMIZATIONS;
elseif tceng_cust1 wants only its customization to be executed then set
*decision = ONLY_CURRENT_CUSTOMIZATION;
else if tceng_cust1 wants only base functionality to be executed, then set
*decision = NO_CUSTOMIZATIONS;
*/
/* Write your custom code
*/
return ifail;
}
Figure 5-10. User Exits Customization Example

The va_list argument in the CUSTOM_EXIT_ftn_t function should
match the arguments of the base user exit or server exit function in the
USER_register_custom_exit function.

Registering Server Exits Customization

This feature allows a site to build all their customizations in a single library. This
includes all the code from libuser_exits as well as from libserver_exits. The
following example shows how to register the server_exits in the custom library.
You need to add another entry in the site-name_register_callbacks function in the
site-name_register_callbacks.c file for the USERSERVICE_register_methods
exit.
For example, if the tceng_cust1 site wants to have some customization
for the USERSERVICE_register_methods function, then in the
tceng_cust1_register_callbacks.c file add the customization in figure 5-11.
#include <custom.h>
#include <tceng_cust1_serverexits.h>
#include <your-include-files>
{
USER_register_custom_exit (“tceng_cust1”, “USER_new_dataset_name”, (CUSTOM_EXIT_ftn_t)
TCENG_CUST1_new_dataset_name);
USER_register_custom_exit (“tceng_cust1”, “USERSERVICE_register_methods”,
(CUSTOM_EXIT_ftn_t)
TCENG_CUST1_register_userservices);
}
tceng_cust1_userservices.h:
extern int TCENG_CUST1_register_userservices(int *decision, va_list args);
tceng_cust1_ userservices.c:
extern in TCENG_CUST1_register_userservices( int *decision, va_list args)
{
/*
Expand the va_list using va_arg
As there are no arguments for USERSERVICE_register_methods(), no need to get any
variables.
*/
/*
if tceng_cust1 wants all other customizations to be executed, then set
elseif tceng_cust1 wants only its customization to be executed then set
*decision = ONLY_CURRENT_CUSTOMIZATION;
else if tceng_cust1 wants only base functionality to be executed, then set
*decision = NO_CUSTOMIZATIONS;
*/
}
Figure 5-11. Server Exits Customization Example

The va_list argument in the CUSTOM_EXIT_ftn_t function should
match the arguments of the base user exit or server exit function in the
USER_register_custom_exit function.

Using ITK Functions
Executing Multiple Customizations

If your site wants to execute some other site’s customization other than your
customization, follow the steps given below.
1. Both the tceng_cust1 and tceng_cust2 sites should follow the sections above to
register their customization for USER_ and USERSERVICE_ exits.
2. Both sites should build their tceng_cust1.dll/sl/so tceng_cust2.dll/sl/so

custom libraries share them.
3. Neither site should rebuild the libuser_exits and libserver_exits.
4. Add the custom library names in the IMAN_customization_libraries

preference in the Options dialog window, accessed from the Edit menu in My
Navigator.
IMAN_customization_libraries=
tceng_cust1
tceng_cust2
5. The preference values should match the library names. For example,
the tceng_cust1 site should have the tceng_cust1.dll/sl/so file and the
tceng_cust2 site should have the tceng_cust2.dll/sl/so file.
6. The custom libraries of the tceng_cust1 and tceng_cust2 sites (which would
be tceng_cust1.dll/sl/so and tceng_cust2.dll/sl/so respectively) should be in
the library path:
• LD_LIBRARY_PATH for Solaris or Linux
• SHLIB_PATH for Hewlett-Packard
• LD_LIBRARYN32_PATH for Silicon Graphics
• PATH for Windows

Registering Customizations
There are four different functions you can use to register customizations, depending
on the situation.
CUSTOM_register_callbacks
This function registers customizations for all customization contexts registered in

the Options dialog window (accessed from the Edit menu in My Navigator).
int CUSTOM_register_callbacks ( void )
It goes through each custom library registered in the Options dialog window, loads
the custom library, and calls the entry point function pointer to register custom
exits. The entry point function contains the custom registrations for the required
USER_ and USERSERVICE_ exits.
CUSTOM_register_exit
This ITK should be called only in the USER_preint_module function in the

user_init.c file. It should not be called anywhere else. This function registers a
custom exit (a custom function pointer) for a given USER_ and USERSERVICE_
exit function.
int CUSTOM_register_exit ( const char* context, /* */
const char* base_ftn_name, /* */
CUSTOM_EXIT_ftn_t custom_ftn /* */
);
• context
The context in which this custom exit has to be registered. It is the name of the
customization library (for example, GM, Ford, Suzuki).
• base_ftn_name
Name of the USER_ or USERSERVICE_ exit for which the custom exit has to
be registered (for example, USER_new_dataset_name).
• custom_ftn
The name of the custom exit (a custom function pointer).

Using ITK Functions
CUSTOM_execute_callbacks
This function executes the custom callbacks registered for a particular USER_ or
USERSERVICE_ exit.
int CUSTOM_execute_callbacks ( int* decision, /* <O> */
const char* ftn_name, /* */
variables /* */
);
• decision
Executes one of the following options:
– ALL_CUSTOMIZATIONS
– ONLY_CURRENT_CUSTOMIZATION
– NO_CUSTOMIZATIONS
• ftn_name
Name of the USER_ or USERSERVICE_ exit.
• variables
The variables that need to be passed to the custom exit (a custom function
pointer).
For each custom library registered in the Options dialog window, accessed from the
Edit menu in My Navigator,
• Get the corresponding custom function pointer.
• Execute the custom function with the arguments passed.
This function is called in all the USER_ and USERSERVICE_ functions in

user_exits and server_exits. The va_list has to be expanded in the custom
function.

CUSTOM_execute_callbacks_from_library
This function executes custom callbacks registered in a particular library for a

particular USER_ or USERSERVICE_ exit by:
• Getting the corresponding custom function pointer.
• Executing the custom function with the arguments passed.
int CUSTOM_execute_callbacks_from_library ( int* decision, /* <O> */

const char* lib_name, /* */
const char* ftn_name, /* */
variables /* */
);
• decision
Executes one of the following options:
– ALL_CUSTOMIZATIONS
– ONLY_CURRENT_CUSTOMIZATION
– NO_CUSTOMIZATIONS
• lib_name
Name of the customization context.
• ftn_name
Name of the USER_ or USERSERVICE_ exit.
• variables
The variables that need to be passed to the custom exit (a custom function
pointer).
The va_list has to be explained in the custom function.

Using ITK Functions
Example
Figure 5-12 (using tceng_cust1 as the site) shows registering a custom handler
in a custom exit.
extern int tceng_cust1_action_handler(EPM_action_message_t msg) {

/* insert custom handler code here */
extern DLLAPI int tceng_cust1_register_custom_handlers(int *decision, va_list args) {

int rcode = ITK_ok;
rcode = EPM_register_action_handler("tceng-cust1-action-handler", "",

tceng_cust1_action_handler);
if (rcode == ITK_ok)
fprintf(stdout, "tceng-cust1-action-handler successfully registered!\n");
else
fprintf(stdout, "WARNING - tceng-cust1-action-handler NOT registered!\n");
return rcode;
}
extern DLLAPI int tceng_cust1_register_callbacks () {
CUSTOM_register_exit ( "tceng_cust1", "USER_gs_shell_init_module",

(CUSTOM_EXIT_ftn_t) tceng_cust1_register_custom_handlers);
return ( ITK_ok );
}
Figure 5-12. Registering a Custom Handler in a Custom Exit Example

Registering Runtime Properties Using Custom Hooks

There is a limitation on registering property methods on the same type. Among the
registered property methods on the same type, the top one in the preferences stored
in the database overrides the registration of the one that follows. Therefore only
one registration works.
To work around this, register multiple methods (one as base method and the rest as
post_action methods) on the same type by following these steps:
1. Register one property method as base method, and the rest as post_action
methods.
2. To register the property methods, follow this sample registration in figure 5-13.
USER_prop_init_entry_t icsTypesMethods[] =
{
{ (char *)"WorkspaceObject", icsInitWorkspaceObjectProperties, NULL
}
};
int npTypes = sizeof ( icsTypesMethods )/sizeof( USER_prop_init_entry_t );
for ( i = 0; i < npTypes; i++ )

{
// firstly, findout if a base method is already registered for
// IMANTYPE_init_user_props_msg
ifail = METHOD__find_method( icsTypesMethods[i].type_name,
IMANTYPE_init_user_props_msg, &initUserPropsMethod );
if( ifail == ITK_ok)
{
if ( initUserPropsMethod.id != 0 )
{
// already registered, the add the method as a post_action method
// add method as post action to the existing base method
ifail = METHOD_add_action( initUserPropsMethod,
METHOD_post_action_type,
icsTypesMethods[i].user_method,
icsTypesMethods[i].user_args );
}
else
{
// not yet registerd, add the method as a base method
// there is no method registerd
ifail = METHOD_register_method ( icsTypesMethods[i].type_name,
IMANTYPE_init_user_props_msg,
icsTypesMethods[i].user_method,
icsTypesMethods[i].user_args,
&methodld );
}
}
}
Figure 5-13. Sample Registration of Property Methods

Part
II ITK Modules
Your interface to Teamcenter objects is through a set of C functions. These C

functions are logically grouped into Teamcenter modules.
For example, Teamcenter has a Persistent Object Manager (POM) module. This
particular module maps Teamcenter object definitions and operations to equivalent
definitions and operations in the relational database.
Core Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Product Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Persistent Object Manager Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Data Sharing of Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Customizing Forms and Properties Display . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Customizing Text and Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Mechatronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Traversal Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Chapter
6 Core Functions
Core Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

POM_object Abstract Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
POM_system_class Abstract Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
POM_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
POM_user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
POM_member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
GroupMember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
POM_application_object Abstract Class . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
WorkspaceObject Abstract Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Item Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
DistributionList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Signoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
ImanVolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
ImanFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
DatasetType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
RevisionAnchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
ItemMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Unit of Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Product Structure Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
File Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Relocating Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Adding an Action Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Sample Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
smp_cr_mv_hl.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
smp_cr_mv_fl.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Compiling and Executing smp_cr_mv_hl.c and smp_cr_mv_fl.c . . . . . . 6-27
sample_cr_move_files_main.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Compiling and Executing sample_cr_move_files_main.c and
smp_cr_mv_fl.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Changing the Revisioning Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28

Types, Properties, and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Discussion of Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Primary Types and Subtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Types, Methods, and Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 6-30
Key Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Attribute-Based Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Reference-Based Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Relation-Based Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Runtime (Derived) Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Compound Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Customizing Properties Using Methods . . . . . . . . . . . . . . . . . . . . . . . 6-33
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Message Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Method Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Property Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Registering a Property init_module Function . . . . . . . . . . . . . . . . . . . 6-38
Registering Properties and Property Methods . . . . . . . . . . . . . . . . . . 6-39
Writing Property Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Canned Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Server-Side Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41
Client-Side Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Best Practices for Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
Common Teamcenter Object Model Customization Scenarios . . . . . . . . 6-50
Tools and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
Creating a New Type Versus Adding a Subclass . . . . . . . . . . . . . . . . . 6-51
Adding a New Relation Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52
Adding a Persistent Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53
Adding an Attribute to an Existing Class . . . . . . . . . . . . . . . . . . . 6-53
Adding an Attribute to a New Subclass . . . . . . . . . . . . . . . . . . . . 6-54
Adding a Property From a Relation . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
Adding a Property From a Relation Using Teamcenter Preference
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
Adding a Property From a Relation Using ITK . . . . . . . . . . . . . . . 6-56
Adding a Runtime (Derived) Property . . . . . . . . . . . . . . . . . . . . . . . . 6-56
Adding a Compound Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Customizing the Behavior of a Type . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Customize the Overall Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Customize the Property Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6-57
Customizing the Master Suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58
General Hints on Customizing Properties . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Memory Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Method Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
PROP_init_value_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
PROP_ask_value_type_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
PROP_set_value_type_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60

Value Caching . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
Display Names . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-61
Hiding Properties . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-61
Workspace Columns ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-62

Chapter
6 Core Functions
This chapter describes the modules that contain Teamcenter’s core functionality.
Core Classes
This section describes the object model in more detail. For most classes, the
description includes:
• The purpose of the class
• The attributes defined by that class
• The methods defined by that class
• Any special meaning that inherited attributes or methods may have

– This information is presented to provide you with a greater
understanding of the Teamcenter architecture. However, it is
important that you use only the published ITK functions to
customize your application. While the ITK functions continue to be
supported, the methods or attributes to support those functions
may change.
– Methods to set and ask the attribute values are generally assumed
and not explicitly stated.
– A more detailed description of classes, attributes, and methods are

in the Integration Toolkit Function Reference manual.

Chapter 6 Core Functions
POM_object Abstract Class

The POM_object abstract class is the superclass of all POM classes.
• Attributes
timestamp
This is a value set internally by POM every time an object is saved. The user
does not have access to it. It is used in the locking system and in rollback.
pid
This is the persistent class identifier. It is unique for each class. It can be
used in queries for limiting searches to an object of a certain class but not
subclass.
• Methods
create
Creates a new instance of the subclass. All subclasses must specialize this
method. A create method normally creates an instance of its class, initialize
its parent class, then initialize its own attributes. By convention, the create
and initialize methods take as arguments the values for the attributes for
which NULL values are not allowed. So normally it is possible to invoke the
create method followed immediately by a save method call.
delete
Deletes the object under the Teamcenter integrity rules. That is, you cannot
delete an object if it is being referenced or if it is loaded in another process.
save
Saves the object that has been manipulated in memory to the database.
lock/unlock
Obtains or releases a write lock in the database.
load/unload
Loads an object into memory from the database or removes an object from
memory. The unload method does not save. It would normally be used when
an algorithm or a user has no further need for the object and wants the
object to be free for modification or deletion by another process.
refresh
Reloads an object from the database. Obtains a write lock if requested.
extent
Returns the tags of all of the instances of a particular class.

Core Functions
POM_system_class Abstract Class

An abstract class to categorize all of the classes that are intrinsic to the POM
and understood by internal POM code. Their attributes and methods are actually
independent of the Teamcenter application.
• Methods
initialize
All classes provide an initialize method, even if they do not have a public
create method. This must exist so the create method of a potential subclass
can initialize the attributes of its parent.
copy
Makes a duplicate copy of an object. This method is normally specialized.
is_modified
Determines if an object has been modified since it was loaded.
is_saved
Determines if an object has been saved.
is_locked
Determines if there is a write lock on the object in the process.
where_referenced
Returns the tags of all POM objects that have a reference to this object.
POM_group
Categorizes or collects a set of users.
• Attributes
name
The name of the group which is unique among all groups.
privilege
A flag indicating whether this group has system administration privileges or
not.
• Methods
find
Returns the tag of the POM_group class or an instance of a subclass of the
POM_group class with a given name.

Group
Specializes the POM_group class to contain a description and a list of roles.
• Attributes
description
A text string to describe the group.
list_of_role
A list of roles that exist for this group.
POM_user
Represents a user of the POM.
• Attributes
user_id
The string used to uniquely identify a user to Teamcenter.
password
The user’s password for logging into the POM.
user_name
A common name used by people to identify a user.
status
A flag to indicate if the user has been deleted but still has references. This
flag can be set if the system administrator attempts to delete the user but
cannot completely do so because the user still owns some objects. The user
is still unable to login with the POM in this case.
def_acl
The default protection to be applied to all instances created by a user.
default_group
The group that the user is to be considered part of, unless another one is
specified. A user may belong to multiple groups.
• Methods
find
Finds a POM_user class instance or an instance of a subclass of the
POM_user class with the given user identification.

Core Functions
User
Specializes a POM_user class instance to understand the specifics of the Teamcenter
workspace and environment.
• Attributes
mailbox
A reference to the folder used as this user’s mailbox.
home_folder
A reference to the user’s home folder.
newstuff_folder
A reference to the user’s Newstuff folder.
person
A reference to the person that this user represents. More than one user may
reference the same person.
os_username
The character string that identifies the operating system user associated
with the user.
volume
A reference to the volume that Teamcenter uses by default as a location
for newly created or imported files.
• Methods
find_user_objects
Returns the tags of all of the objects owned by this user.
change_user_object_owner
Changes the owner of an object from one user to another user and group.
delete_user_objects
Deletes all of the objects owned by a given user.

POM_member
Associates a user with a group.
• Attributes
user
A reference to the user that is a member of the group.
group
A reference to the group that the user is a member of.
ga
A flag indicating whether the reference user is a group administrator for
this group or not.
• Methods
find
Finds a POM_member class instance or an instance of a subclass of
POM_member that associates a given user with a given group.
find
Finds all of the POM_member class instances in a given group.
find
Finds all of the POM_member class instances for a given user.
GroupMember
Enables users to play a role in a group, rather than just be a member of it.
• Attributes
role
A reference to the role object that the user is to play in this group.
• Methods
find
Finds all of the group members for a given role in a given group.

Core Functions
POM_application_object Abstract Class

The superclasses of all classes that are defined as part of a POM application (in this
case, Teamcenter). In general, these attributes would be expected by almost any
POM application, but are not understood directly by POM internal code.
• Attributes
archive_info
Information about the location of archived data. This is empty if the object
has not been archived.
owning_group
The group that owns this object. Specific access rights can be assigned to
this group which applies to all of its members.
acl_bits
Data indicating the type of access different users and groups have to the
object.
last_mod_user
A reference to the user who last saved the object.
owning_user
A reference to the user who owns the object.
creation_date
The date that the object was created.
archive_date
The date that the object was archived.
last_mod_date
The date that the object was last modified.
backup_date
The date that the object was last backed up.
• Methods
initialize
All classes provide an initialize method, even if they do not have a public
create method. The initialize method is necessary for the create method
of a potential subclass to initialize the attributes of its parent.
archive/restore
Moves the bulk of an object’s data to a disk file. The bulk part is then deleted
from the Teamcenter database but the object remains and contains data
about where the archive information is.
backup
Copies the bulk of an object’s data out of Teamcenter.

• Specializations
– All of the POM_object methods are specialized by the AOM functions to not
only manipulate the object as a POM function would, but also to create,
manipulate, or delete other internal data structures that are specific to the
Teamcenter application.
When possible, you should always call AOM functions rather than
the equivalent POM function.
WorkspaceObject Abstract Class

To generalize the attributes and methods for all classes whose instances appear
in the Teamcenter workspace.
• Attributes
object_name
The name of the workspace object. This is the name that appears in a folder
window.
object_desc
A textual description of the object.
object_type
The class name of the specific subclass that is instantiated or a specialized
type, such as "target folder."
revision_number
A number representing how many times a given object has been modified.
Most classes do not support revisioning; in that case, this equals 1.
release_status_tag
A reference to a status object that indicates where the object is in the release
process.
object_application
Stores name of application that created the workspace object.
release_status_list
A POM_tag list of release statuses.
revision_limit
A user-specified count of how many revisions to keep.
date_released
Last date when object was released.

Core Functions
• Methods
describe
Returns a structure of useful information, such as object name, ID string
(name;revision), date created, date modified, and so on.
object_application
Returns the name of the application that creates and manipulates the
instances of the class, usually just Teamcenter. Some classes may specialize
this method. For example, the Dataset class’ method returns the name of
the tool that last modified them as the application.
revision_limit
Returns the number of revisions of a particular instance should be kept.
Most classes do not support revisioning; in that case, this equals 1.
getInfo
Returns the following basic information about a workspace object: name,
description, type, application, revision number, revision limit, owning user
name, owning group name, date created, date modified, date archived, date
of last backup, and date released.
setInfo
Sets new values for some of the attributes that were returned with getInfo.
freeInfo
Frees up the memory used in a getInfo operation.
find
Finds a workspace object of any subclass with a given name.
search
Finds all of the workspace objects of any subclass that matches the input
values for name, class name, owner, group, and various dates.
latest
Returns the latest revision of a given object. Since most classes do not
support revisioning, this method normally returns the input object. If the
class does support revisioning, then the newest revision is returned.
• Specializations
copy
Creates a new object just like the old one, optionally with a new name.

Folder
Provides a generic container of other objects in the workspace.
• Attributes
contents
A list of references to other workspace objects.
sort_order
A value indicating what order the user wants to see the folder contents in.
sort_criteria
The attribute on which to sort a folder’s contents.
• Methods
insert
Includes another workspace object in the folder’s list of references.
remove
Removes a reference to a workspace object in a folder’s list of references.
move
Moves an entry of a folder from one location in the list to another.
• Specializations
getInfo
In addition to the workspace object values, folders also return sort order, sort
criteria, and the number of entries in the folder.
Envelope
Provides a generic container of workspace objects that contains a list of receivers.
• Attributes
listOfReceivers
A list of users, groups, or distribution lists to send the envelope to.
sent_date
The date that the envelope was mailed.
sender
A reference to the user who sent the envelope.
• Methods
send
Places a reference to the envelope in the mailbox folder of each receiver.
• Specializations
– The name and description for an envelope have the specialized meanings of
subject and comments.

Core Functions
Item
Provides an identification for physical or conceptual entities about which an
organization maintains information and audit/control change. Items are the
fundamental objects used to manage information. Typical uses of items are parts,
documents and equipment. In engineering and product development environments,
parts are identified as items.
• Attributes
item_id
A unique character string which by the item is identified.
configuration_object_tag
The tag that points to the configuration object.
bom_view_tag
The tag that points to the BOM View.
uom_tag
The tag that points to the unit of measure.
• Specializations
create
Creates the item and the first item revision. This method also creates an
item master form for the item and the item revision. These forms have a
Master_form relation to the item and item revision.
delete
Deletes an item, its item master, and any relations to other objects. It also
deletes all item revisions of the item.
Item Revision
Reflects modifications to an item. Once an item revision has been released, a new
item revision can be created. The original item revisions are retained for historical
purposes. Customer sites define their own procedures to determine how and when
a new item revision should be created.
• Attributes
item_revision_id
A unique character string by which the item revision is identified.
items_tag
The tag that references the parent item.
structure_revision
The number of times the structure has been revised
• Specializations
find
Returns the item revision with a given item_revision_id and parent
item_id attributes.

copy
Creates a copy of the original item revision inside the same item.
create
Creates an item revision and an item master form. The item master form
has a Master_form relation to the item revision.
delete
Deletes the item revision, its item master, and any relations to other objects.
Dataset
Encapsulates the actual structure of a package of application data and associates
that package with a list of tools.
• Attributes
dataset_type
The tag of the DatasetType object that this dataset is a type of.
tool_used
The tag of the tool that created the particular dataset revision.
format_used
The format of the dataset.
user_class
A string attribute that enables you to further classify your datasets.
rev_chain_anchor
The tag of the revision anchor that associates the dataset with its previous
and subsequent revisions.
named_references
A list of references to objects that contain the actual application data. This is
presented through the interface as sets of three values:
– An object reference.
– A reference name.
– A reference type.
These are actually stored as three separate lists, ref_list, ref_names and
ref_types, which are kept in sync by Teamcenter.

Core Functions
• Methods
revise
Similar to the copy method, except the copy is considered a new revision of
the original dataset.
delete_all_revisions
Deletes all revisions of a dataset.
purge
Removes all old, non-referenced revisions except the latest.
• Specializations
revision_limit
A dataset object actually sets and asks the revision limit by using the keep
limit of its revision anchor.
copy
In addition to copying the dataset, this method also copies the revision
anchor. The new dataset becomes revision 1.
latest
Asks the revision anchor for the latest revision.
getInfo
Adds the dataset type name, tool name, site classification, and format to the
list of values returned by the getInfo method.
delete
Deletes the dataset and revision anchor if there are no other revisions and
the objects pointed to by the named references, they are the AE_PART_OF
type, and not referenced by another object or loaded in another session.
refresh
Refreshes the dataset and the revision anchor.

Tool
Represents an external application in Teamcenter. The tool must also contain
information about how to run the application and what kinds of input formats,
output formats, and parameters the application understands.
• Attributes
symbol_name
The command used to run the application.
site_classification
A text string that enables the user to classify tools.
shell_or_translator
A flag that indicates whether a tool is a normal application, a shell used to
communicate with an application, or a translator used to convert data from
one format to another.
encapsulator
The tag of the tool (shell) used to communicate between Teamcenter and
this tool.
input_formats
A list of formats this tool can understand as input.
output_formats
A list of formats that this tool can output.
variables
A list of names of input parameters that this tool can accept.
default_values
The default values of the above variables.
vendor_name
The name of the vendor that supplied the actual application.
version
The version of the application.
install_date
The date that the application was installed.

Core Functions
Form
Provides the customer with a collection of name/value pairs with enough information
to display a form window that can show and allow modification of the values.
• Attributes
form_file
The name of a compiled UIL file that contains the attribute names and
the layout of the form that Teamcenter uses for presenting it in the user
interface for display and modification.
data_file
The tag of the POM object that actually contains the name/value pairs. This
could be an ImanFile object or a POM class defined by the customer.
• Methods
ask_value
Returns the value of a particular attribute.
set_value
Sets an attribute value.
• Specializations
getInfo
Returns the workspace object values and the name of the form definition file.
delete, refresh, unload, and save
These methods act on the POM object or ImanFile object associated with
the form, as well as the form itself.

DistributionList
Contains the list of users, groups, and distribution lists that a particular type of
mail should go to.
• Attributes
listOfMembers
List of users, groups, and distribution lists.
Status
Represents an engineering task and the authorization process for that task.
• Methods
find
Finds a status with a given name.
Signoff
Associates an approval or authorization status with a group member.
• Attributes
group_member
The group member who is to decide to authorize or not.
decision
The decision. It must be YES, NO, or NO_DECISION.
decision_date
The date on which the decision was made.
comments
A string to contain any additional comments about the signoff. This is not
the same as the task comment.
Role
Describes a role that a user can play in a group.
• Attributes
role_name
The unique name of the role.
description
A description of the role.
• Methods
find
Finds a role with a given name.

Core Functions
Person
Represents an actual human being in the Teamcenter system. The person
profile can be customized by changing the selectedpersonwindowintl.uih and
selectedpersonwindowlocal.uih in the IMAN_LANGUAGE directory.
The following is the description of the person object model and how its attributes
are being mapped from the user interactive interface:
User Interactive Interface Object Model Description

Person name User name: the full name used to identify a
person.
Street Address pa1
City pa2
State pa3
Zip Code pa4
Country Code pa5
Organization pa6
Employee Number pa7
Internal Mail Code pa8
Email Code pa9
Phone Number pa10
All of the attributes, form name, and pa1 through pa10 are optional
attributes that can store up to 32 characters.
• Attributes
first_name
First name of the person.
middle_name
Middle name of the person.
last_name
Last name of the person.
street_address
The person’s street address.
city
The city where the person lives.
state
The state where the person lives.
zipcode
The person’s zip or mail code.
organization
The name of the company’s organization that the person is in.

phone_number
The person’s phone number.
date_of_birth
The person’s birthday.
• Methods
find
Finds a person with the given first name, last name, middle name, and date
of birth.

Core Functions
ImanVolume
Represents a physical storage location for files in the operating system in the
Teamcenter database.
• Attributes
volume_name
The unique name of the volume.
unix_path_name
The path name of the volume in UNIX format.
wnt_path_name
The path name of the volume in Windows format.
node_name
The name of the machine that the volume (directory) is on.
users
The list of users and groups that have access to this volume.
protection_mode
Not currently used.
machine_type
The type of machine that the volume’s directory resides on.
• Methods
find_by_name
Finds the volume with the given name.
find_by_path
Finds the volume with the given pathname.
grant_access
Gives a user or group access to a volume.
revoke_access
Removes write access to a volume for a user.
check_access
Determines if a particular user has write access to a particular volume.

ImanFile
Represents an operating system file in the Teamcenter database.
• Attributes
file_name
The leaf name of the file in the Teamcenter volume.
original_file_name
The name the file is given if it is exported to the operating system by the
IMF_export_file function.
sd_path_name
The pathname to the operating system file. This is in a system-dependent
format.
translate
Indicates whether the file is stored in Teamcenter machine-translatable
format.
text_flag
Indicates whether the file is text or binary.
machine_type
Indicates what machine format the file is in.
volume_tag
The tag of the volume on which the operating system file resides.
status_flag
Indicates if the file is scheduled to be deleted.
time_last_modified
The time stamp on the file indicating when it was last changed by
Teamcenter.
released_version
Reserved for future use.

Core Functions
• Methods
open
Opens the operating system file associated with the ImanFile database
object.
close
Closes the operating system file associated with the ImanFile database
object.
read
Reads binary data or lines of text from a file.
write
Writes binary data or lines of text to a file.
import
Brings an existing operating system file under control of Teamcenter as an
ImanFile database object.
export
Copies an ImanFile database object into a specified operating system
directory, thus relinquishing Teamcenter control over the file.

DatasetType
Represents a named list of tools that can operate on a particular type of dataset.
• Attributes
datasettype_name
The unique name of the DatasetType instance.
description
A description of the type of data that this object represents.
parent_type
The tag of a DatasetType class that this instance is a kind of. Enables the
user to classify dataset types.
list_of_tools
The tags of all of the tools that can operate on datasets of this type.
action_list
The list of workspace actions (open, destroy, purge, and so on) for which
this type of dataset has specialized behavior. The default tool is run if the
particular action chosen is in this list. If not, the action has the default
Teamcenter behavior.
named_ref_list
The list of all of the possible named references that datasets of this type
may have.
• Methods
default_tool
Return the default tool for the dataset type. This is the first in the list.
find
Return the tag of the dataset type with a given name.

Core Functions
RevisionAnchor
Provides facilities for collecting an ordered set of related objects. Normally these
would be successive revisions of an object. It is used only for datasets.
• Attributes
revisions
A list of the revisions.
keep_limit
Indicates how many revisions to keep before attempting to delete the older
ones.
highest_rev
Indicates the highest revision ever achieved in the life of this revision anchor.
• Methods
latest
Returns the most recently created object in the set of revisions.
make_room
Removes a number of objects from the set of revisions.
purge
Removes all objects from the set of revisions, except the latest.

ItemMaster
Represents a form that has a Master_form relation with an item and item revision.
This class can be specialized at each site, and Teamcenter comes with some standard
attributes.
Form objects can store data in two different ways. In the system as delivered, item
master and item revision master data is stored in ImanFiles. The ItemMaster
class is provided if you prefer to store the data in POM. To store it in POM, you need
to modify the itemmaster.uil and itemversionmaster.uil files by changing the
POMClassName entries to ItemMaster.
• Attributes
project_id
The identification of the project under which the item was developed.
previous_item_id
The item that is being superseded by this one.
serial_number
A number assigned to the item by your organization.
item_comment
Comments made by the engineer.
user_data_1/2/3
Fields where the user can place data.

Core Functions
Unit of Measure
Represents the unit of measure for an item. Valid units of measure are defined for
an Teamcenter installation by the system administrator.
• Attributes
symbol
An 8-character symbol for the unit (for example, in for inches).
name
A full name for the unit.
• Methods
extent
Lists the units of measure valid for an installation.
create
ask/set name/symbol
ind by name/symbol
Product Structure Objects
Go to the Product Structure (PS) section Product Structure (PS) Module of this
manual.

File Relocation
When you create a dataset in Teamcenter, a file is created in the user’s volume
directory. Once it is released (in other words, signoff is performed), it remains in the
same volume along with other non-released objects. To list and backup all of the files
related to the released datasets for all of the users, all of the dataset files should be
copied to a separate directory.
Two programs have been developed to perform this task. One activates an action
handler to relocate the files on release of the job. The other relocates all of the
existing released jobs.
Relocating Datasets
To relocate a dataset after it is released, you need to register an EPM action handler.
To register an EPM action handler, use the EPM_register_action_handler
function. Input parameters should be action strings and function callbacks.
This function should be called in the user_gsshell.c file.
Adding an Action Handler

A handler is a small program used to accomplish a specific task. There are two
kinds of handlers:
• rule
• action
To add an action handler, perform the following steps:

1. Run Teamcenter Engineering and login as a system administrator.
2. Choose the Admin group and open Workflow Designer.
3. Choose File→New Root Template. The New Root Template dialog window
is displayed.
4. Give the new root template a name and select another root template to base
this template on. Click OK.
5. Click the button that displays the task handlers panel.
6. Choose the task action where you want the handler to execute, then choose
the handler.
7. Choose the arguments needed for your handler and their values.
8. Choose the plus button to add the handler to the task action. When you are
done, close the Handlers dialog window.
To incorporate the action handler into other release procedures, follow steps
3 through 8.

Core Functions
Sample Programs
The following sample programs relocate files associated with datasets being released.
It assumes that the FLRELDIR directory exists on the operating system. If any of
the target objects are datasets, all files referenced by it are copied to the operating
system directory specified by FLRELDIR.
It is assumed, for these examples, that the usr/tmp/release directory exists on the
system and that all users have write permission to that directory.
These functions relocate only the files associated with the dataset. If the
job is released for an item, folder, form and dataset, then this function only
relocates the files for the job released for the dataset.
smp_cr_mv_hl.c
The smp_cr_mv_hl.c file contains the USER_cr_init_module function. This

should be called in the USER_gs_shell_init_module function.
Once called, a new auto-relocate-file action handler is registered and the job
is released. If it contains a dataset, the dataset is relocated to the FLRELDIR
directory.
smp_cr_mv_fl.c
This file contains the relocate_released_dataset_file function. Its purpose is

to relocate files associated with the datasets being released. Using the tag of the
release job as input, it finds all target objects. If any of the target objects is a dataset,
all files referenced by it are copied to the operating system directory specified by
FLRELDIR. The directory is not created by this function.
Compiling and Executing smp_cr_mv_hl.c and smp_cr_mv_fl.c
To compile the above files, add the USER_cr_init_module function to the

USER_gs_shell_init_module function of the user_gsshell.c file (supplied by
Teamcenter). Compile the smp_cr_mv_hl.c, smp_cr_mv_fl.c and user_gsshell.c
files separately. Create a new libuser_exits.sl file using the above .o files.
To execute this file, add the auto-relocate-file action handler to all of the release
procedures. Once the job is released, it copies released datasets to the FLRELDIR
operating system directory .
sample_cr_move_files_main.c
The sample_cr_move_files_main.c file works as a stand alone ITK program. It
logs into Teamcenter and initializes the AE, PSM and SA modules. Next, it creates
the FLRELDIR operating system directory. It then searches for all released jobs
containing datasets and relocates these dataset files to the FLRELDIR directory.

Compiling and Executing sample_cr_move_files_main.c and smp_cr_mv_fl.c
Compile the sample_cr_move_files_main.c and smp_cr_mv_fl.c files

separately. Link the two files using the linkitk command and create the
sample_cr_move_files_main executable. You can execute this file from the
command line using:
sample_cr_move_files_main -u=user-id -p=password -g=group
The user-id variable is the Teamcenter user login name; password is the Teamcenter
user password; and group is the Teamcenter user group name.
Changing the Revisioning Scheme

If you want to change the default item revisioning scheme to something else (for
example, revisions A, B, C, etc. to revisions -a, -b, -c, and so on), you must modify the
sample code in the user_part_no.c file.

Core Functions
Types, Properties, and Methods

Starting with Teamcenter Engineering 2005, you should not customize
Teamcenter using registered methods on types and properties. Instead,
customize Teamcenter using extension points and extensions. For more
information, see Adding New Extensions.
Programmers can customize and extend the Teamcenter data model to more closely
agree with the enterprise data model. Three modules are used to accomplish this:
• Types
• Properties
• Methods
Discussion of Basic Concepts

In C++, classes define objects. Objects are represented by a set of data and methods.
Types are an abstract definition of a class. Types define the actions an object can
perform and what the expected results should be, without defining how the action
should be performed.
Primary Types and Subtypes
In Teamcenter, types are used to abstract the implementation of a Persistent Object

Model (POM) class and each POM class is mapped to a primary type. The primary
type name is the same as the POM class name. Additional types can also be mapped
to a POM class if the type behavior is consistent. These additional types must use
another name and are considered subtypes or specializations of the POM class and
primary type.
For example, with a POM class item, Teamcenter includes a item primary type that
directly corresponds to item class. You can create a second type and map it to the
item type as well. The data associated with both types is identical, but the they may
have slightly different behavior. For example, the item class, since it is an abstract
representation of a product, might allow any value for the item ID. However, the
second type might only allow a restricted subset of item IDs. Although both types are
stored in the Teamcenter database as items, the type behavior is slightly different.
• ImanType
ImanType is the implementation of any type stored in the Teamcenter database.
• FormType
FormType is a specialized ImanType used to define a type for the Teamcenter
Form class.
• DatasetType
DatasetType is a specialized ImanType used to define a type for the
Teamcenter dataset class.

Types, Methods, and Default Behavior

Types provide a place holder for the methods associated with a class. Teamcenter
class definitions define the static state of an object and the basic behavior of the
class. The actual implementation of the behavior (action) is performed at runtime
using methods. Additional actions can also be attached to a type at runtime using
the Methods ITK module.
Types, properties, and methods are used to implement extended classes and custom
types. For additional information about customizing Teamcenter using extended
classes and custom types, see Configuration Guide.
Key Definitions
The following terms and concepts is widely used to describe types, properties, and
methods:
• Class
A class is the definition of an object implemented in the Teamcenter data model.
• Attribute
An attribute is a persistent piece of information that characterizes all objects
in the same class.
• Type
A type is the specialization of an Teamcenter class based on properties and
behavior.
• Primary Type
A primary type is a default ImanType that directly corresponds to each POM
class (in other words, the primary type name is the same as the POM class
name). Teamcenter automatically creates the primary type when a new POM
class is instantiated.
• Subtype
Subtypes are all types except the primary type that belong to the same POM
class. Subtypes inherit all the properties and behavior of the primary type.
You cannot create a subtype of a subtype in the same POM class.
• Property
A property is a piece of information that characterizes all objects of the same
type.
• Message
A message is a command that is passed to an object to execute some operation
(for example, save, copy, and delete).
• Method
A method is the execution of a message that is particular to that object type.

Core Functions
Relationship Diagram
Figure 6-1 shows the Teamcenter object model. It demonstrates the relationships
among objects, classes, and types. The figure also shows the relationships between
properties and attributes.
Figure 6-1. Teamcenter Object Model
Types
A type is a specialization of an Teamcenter class based on properties and behavior.

Teamcenter uses types to represent real-world objects (for example, part, tool,
employee). You can the Type application to create, modify, and delete types.
Properties
Type data (for example, ID, Name, Description, and so on) is defined by a set of
properties. The messages used to control these properties can be customized and
extended using property methods.
Methods
Type behavior (for example, save, delete, create, and so on) is defined by a set of
messages that are passed to the type at runtime. These messages are implemented
using methods. Methods are C/C++ functions. Programmers can define new
methods for types or customize and extend existing methods by adding pre- and
postconditions to these existing methods.

Properties
Properties perform only a simple set of functions, namely asking and setting the
value of the attribute or relationship they represent. They can return a List of
Values (LOV) that is applicable for that property.
Properties are represented by two classes: ImanProperty and
PropertyDescriptor. The PropertyDescriptor class defines the property for the
type, while the ImanProperty class holds the value for a property instance.
In base Teamcenter, each type is specified by a set of properties that directly maps
to the attributes defined for a class. You can customize and extend these types by
adding new properties to new or existing types. These properties can represent
anything you wish to define for a type.
All properties belong to one of five classifications:
• Attribute-based
• Reference-based
• Relation-based
• Runtime
• Compound properties
Properties can also be customized using methods.
Attribute-Based Properties
Attribute-based properties ask or set a simple value (for example, integer, string, and
date). The value is stored in the database as an attribute and mapped to the property.
Reference-Based Properties
Reference-based properties ask or set a reference to another object. The reference is
stored in the database as a Reference attribute and mapped to the property.
Relation-Based Properties
Relation-based properties ask or set a reference to secondary objects of an
ImanRelation type. The reference is stored in the database as a Relation type and
is derived from that ImanRelation type.
Runtime (Derived) Properties

Runtime properties are properties that can be defined at runtime and attached to
types. Runtime properties do not map directly to persistent attributes, references or
relations. Instead, runtime properties derive data from one or more pieces of system
information (for example, date and time) that are not stored in the Teamcenter
database.
Runtime properties can also be used to display a property of one type as if it were a
property of another type.

Core Functions
Compound Properties
A compound property is a property that can be displayed from one type, as if it

were the property of that type, though it actually resides on another type. Though
runtime properties can be used to display such a property, they require custom
coding to do so. Compound properties allow you to create such properties, without
custom coding, through the Business Modeler application.
Customizing Properties Using Methods
Property methods can be used to customize the ask_value, set_value and

initialize_value property messages. Although default behavior of these messages
is defined in base Teamcenter, you can modify this behavior by adding pre- and
postconditions to these messages.
Methods
Methods are user-definable functions that are associated with types and properties.
ITK methods allow Teamcenter sites to customize and extend the behavior of
Teamcenter objects and to incorporate enterprise business rules.
Methods are most often used to create subtypes in order to customize parent type
behavior. For example, instances of Class Item directly correspond to Type Item.
Methods can be used to define a subtype of item for a Teamcenter site to customize
the behavior of items at that site.
Inheritance
Methods incorporate limited single-level inheritance. For example, if no method has

been registered for a subtype, the equivalent primary type method is displayed
instead. This allows the creation of subtypes that implement an extension of a
limited subset of the primary type behavior.
Actions
A method can be divided into four functions that are executed in the following
sequence:
1. Precondition
2. Preaction
3. Base action
4. Postaction

All methods must have a base action, the other actions are optional. Each registered
action function must return ITK_ok for processing to continue to the next action.
Otherwise an error is posted and an integer error code is returned.
Precondition is only intended to verify that no conditions exist that could prevent
the method from executing properly. Actual execution of the method should only
commence in the pre-action.
Careful planning of pre- and post-actions allows extension of base action behavior
without having to re-implement the base action.
Message Identification
Each message is uniquely identified by a text string. These strings are used to
register methods as type/message combinations. To maximize runtime performance
when executing methods, minimize repeated lookups of message IDs. Teamcenter
assigns runtime unique integers to each message (message ID) and passes them to
the METHOD_SETUP_MESSAGE macro. It caches the message IDs in a static int
where they are retrieved the next time the method is executed. This can be useful
when implementing custom message execution code.
Method Registration
Methods are registered during initialization of Teamcenter. Registrations apply for

the duration of that Teamcenter session. User-defined methods must be registered
by code in the USER_init_module user exit function. This code must be called
after base Teamcenter initialization (including primary type method registration) is
complete.
The following sample program listing shows the code required to:
• Register a method.
• Execute the save message for an object of MyType type.

Core Functions
• Implement a precondition handler.
• Implement a base action.
#include <iman_msg.h> /* Defines basic messages like save. */

#include <my_type.h> /* Prototypes for the actions I want to register. */
int USER_init_module()
{
int ifail;
METHOD_id_t my_method;
/* Create the method by registering the base action.

*/
if ((ifail = METHOD_register_method("MyType", IMAN_save_msg,
&MYTPE_save, NULL, &my_method)) != ITK_ok)
{
return ifail;
}
/* Now add the pre-condition to the method.

*/
if ((ifail = METHOD_add_pre_condition(my_method, MYTYPE_save_precheck,
NULL)) != ITK_ok)
{
return ifail;
}
/* The action functions registered here will now be executed instead of

** the default save code every time AOM_save is called for an object
** of type MyType.
*/
return ITK_ok;
}

The following sample program listing shows the registered actions implemented
in the my_type.c file.
#include <my_type.h>
int MYTYPE_save_precheck(METHOD_message_t *, va_list args)
{
/* IMAN_save_msg is defined to pass the tag of the object as its only
** vararg.
*/
tag_t object_tag = va_arg(args, tag_t);
.
.
.
if (... everything ok to save...)
{
return ITK_ok;
}
else
{
return failure code;
}
}
int MYTYPE_save(METHOD_message_t *, va_list args)
{
/* IMAN_save_msg is defined to pass the tag of the object as its only
** vararg.
*/
tag_t object_tag = va_arg(args, tag_t);
/*... code to implement save action... */
return ITK_ok; /*... or failure code */

}

Core Functions
Property Methods
Property methods are special methods that are attached to a property instead of a
type. Property method actions are identical to those described in the Actions section
above. However, there are slight differences in the way the following functionality is
implemented:
• Inheritance
Property methods inheritance is similar to Inheritance discussed earlier in this
topic, except that property methods can be inherited through multiple levels
of type hierarchy.
The primary type hierarchy directly corresponds to the class hierarchy. When a
new user-defined type is created, it becomes a new subtype of the primary type.
Consider the class and type hierarchy as shown in figure 6-2.
Figure 6-2. Property Method Inheritance

– Item is a default Teamcenter WorkspaceObject class with a corresponding
Item primary type.
– The user-defined NewItem subclass is created and also has a corresponding

NewItem primary type.
– The user-defined Part subtype is created for the NewItem primary type .
If a method is registered against any WorkspaceObject property, that same

method also applies to the same property of Part.
• Message ID
Property message ID is implemented as discussed earlier in this section, except
that property methods use a the METHOD_SETUP_PROP_MESSAGE macro
instead of METHOD_SETUP_MESSAGE.
• Registration
Property methods registration is subject to the same rule and limitations
discussed above. Because property methods are registered against a single
property, they have a separate registration call and function. Also, property
methods are not registered until the property is used for the first time.

Registering a Property init_module Function
When registering properties and property methods, a special init_module function

is required for each type. You determine the names of these init_module functions.
To name the property init_module function, declare the function prototype and
insert the type name and the function name into the user_types_methods array
definition inside the USER_register_properties function in the user_init.c file.
A sample user_init.c file is provided in the
IMAN_ROOT/sample/properties/smp_props.c directory in
UNIX or Linux or IMAN_ROOT\sample\properties\smp_props.c on Windows.
This sample contains some useful properties. After you modify the user_init.c file,
relink the shared library.
The following example registers properties and property methods on the MyType
customer type. It uses a function called MYTYPE_prop_init_module to accomplish
this. You insert the new function into the user_init.c file.
Property Method Registration in user_init.c:
#include <iman_msg.h> /* Defines basic messages */
int USER_register_properties()
{
int ifail = ITK_ok;
/*
* You can declare your function prototypes here or in another file
* #included by this one.
*/
extern int MYTYPE_prop_init_module();
/*
* This array is used to register methods which initialize properties
* on types. The message name is IMANTYPE_init_user_props_msg. No coding
* is necessary in this function. Just add an entry in this array to
* indicate the object type, the function which implements the property
* additions/modifications and the list of arguments.
*
* The array should be terminated with a NULL entry.
*/
USER_prop_init_entry_t user_types_methods[] =
{
{ "MyType" , MYTYPE_prop_init_module , NULL },
{ "" , 0 , NULL }
};
int n_types = size of(user_types_methods)/size of(USER_prop_init_entry_t);
/*
* Do not edit this call. This call is not to be used elsewhere.
*/
ifail = IMANTYPE_register_properties(user_types_methods, n_types);
return ITK_ok;
}

Core Functions
Registering Properties and Property Methods
To add or remove properties and/or customize the behavior of properties, insert

code into the property init module function for the associated type (in other words,
the type characterized by the property).
The sample program below shows how to add the MyNewProperty runtime
property to the MyType type. The program does three main things:
1. Gets the tag and name of the type to register the property against.
2. Adds the property to the type.
3. Registers a property method against the ask_value message of the property.
The program does not hard code the type name. This is very important
to support the inheritance of the property onto subtypes. Always use the
IMANTYPE_ask_name function to get the type name from the type tag.
Registered actions implemented in my_type.c:
#include <prop.h>
extern int MYTYPE_ask_newprop_value_function(METHOD_message_t *message,/

va_list args);
int MYTYPE_prop_init_module(METHOD_message_t *message, va_list args)

{
/* Extract type_tag */
int ifail = ITK_ok;
tag_t type_tag = va_arg(args, tag_t);
tag_t pd_tag = NULLTAG;

char type_name[IMANTYPE_name_size_c + 1];
METHOD_id_t method_id;
ifail = IMANTYPE_ask_name(type_tag, type_name);

if(ifail == ITK_ok)
{
/* Add a new run-time property called MyNewProperty */

ifail = IMANTYPE_add_runtime_property(type_tag,
"MyNewProperty",
PROP_string,
32,
&pd_tag);
}
/* Add an askValue method for our property */
if(ifail == ITK_ok)
{
ifail = METHOD_register_prop_method(type_name, "MyNewProperty",
PROP_ask_value_string_msg,
MYTYPE_ask_newprop_value_function,
0, &method_id);
}
/* More property method registrations */
return ifail;
}

The PROP_ask_value_string function is replaced by the

AOM_ask_value_string function after version 10.0.
Writing Property Methods
After registering a property method to ask or set the value of a property, you must
write the actual property method function.
The sample program below shows how to write a property method to ask the value of
a runtime property. In this sample, the value is retrieved from storage, associated
with the property, and returned as-is. However, the value could have been retrieved
by calling any ITK function or by manipulating the value retrieved by the ITK
function using a suitable algorithm.
int MYTYPE_ask_newprop_value_function(METHOD_message_t *message, va_list args)
{
/* Extract property tag
*/
tag_t prop_tag = va_arg(args, tag_t);
char **value = va_arg(args, char**);
char* tmp_value_string = NULL;

int ifail = ITK_ok;
/* Compute or Find actual tmp_value_string then copy it into value with

* persistent memory allocation. The field value is automatically set
*/
if ((ifail = PROP_get_value(prop_tag, &tmp_value_string)) == ITK_ok)
{
*value = SM_string_copy_persistent(tmp_value_string);
}
return ifail;
}
Canned Methods
Custom canned methods are included with the Teamcenter system and can be
configured using the Business Modeler application. Canned methods allow you, as
system administrator, to change the behavior of items, item revisions, and dataset
types without having to write custom code. The user interface for using canned
methods is within the Business Modeler application in the Action Rules tab. Once
the types are configured with canned methods, the configuration information is
stored and can then be easily distributed to your other sites, without having to redo
the configuration from Business Modeler.
You have to make changes to both the server side and client side.

Core Functions
Server-Side Changes
To add site canned methods in order for them to be configurable from the Business
Modeler application, use the METHOD_CM_add_method method on the server
side. Site canned methods need to be added at session startup using this method.
int METHOD_CM_add_method (type_name, msg_name, action_type, func_name,
user_data_template, is_mandatory_template, user_dataQuery_detail)
The arguments are described as follows:

type_name
Name of class or types for which the canned method can be configured.
msg_name
Operation name for which the canned method can be registered against.
action_type
When to register the method:
• 0 – during precondition
• 1 – during preaction
• 2 – during base action
• 3 – during postaction.
func_name
Name of the canned method that appears in the Business Rules Application –
Action Rules Tree Node.
This argument must be unique for a given canned method.
user_data_template
Options required during canned method configuration and also during
registration. This must be a single string with each parameter separated in the
string by a double colon (::).
You cannot add, remove, or reorder the options in the user_data_template
argument unless you remove the existing configuration and repeat the
configuration for the associated canned method for all the affected types. This is
because the order and number of values stored in database is tightly tied to the
order of the values in the user_data_template argument.
is_mandatory_template
Details regarding whether a user_data_template parameter is mandatory or
optional. Use 1 for mandatory and 0 for optional. This must be a single string,
with each parameter separated in the string by a double colon (::).

user_dataQuery_detail
This can be NULL only if the user_data_template argument is NULL, or else this
should have a one-to-one mapping for the parameters in the user_data_template
argument. The saved query name should be used for parameters that need
to have a list box of values displayed in the rich client. A blank space (in
other words, " ") can be used for parameters that do not need any list box
values for display in the rich client. Along with the saved query name,
the attribute whose value needs to be displayed should be mentioned as
param1QueryName~attribute-name, where a tilda (~) must be the delimiter
between the saved query name and attribute name. The attribute-name is the
attribute of the query results whose value needs to be displayed in the list box.
The calls to this method must be made in the USER_add_canned_methods user

exit. For more information about these methods, see the Integration Toolkit Function
Reference manual.
All of the code below should be defined in some site function, such
as SITE_register_canned_methods, which in turn is called in
USER_add_canned_methods.
For example, your site has three site canned methods such as 1, 2, and 3:
1. SiteCannedMethod_1
A precondition on a create message for all items that takes no options for the
method.
A preaction on a saveAs message for all item revisions that takes no options for
the method.
A postaction on a delete message for a document item type that takes input on
the following method options: option_1, option_2 and option_3. Option_1
is mandatory and has values corresponding to the attr_1 attribute from the
execution result of the Query_1 query. Option_2 is not mandatory and does
not have any query information for its values. Option_3 is mandatory and has
values corresponding to the attr_3 attribute from the execution result of the
Query_3 query.

Core Functions
You can set up site canned methods on the server side by following these steps:
1. Register the site canned methods:
#include <typecannedmethod.h>
#include <iman_arguments.h>
……….
int inx = 0;
int ifail = ITK_ok;
2. Create a mapping array for function name to function pointer mapping:

METHOD_CM_func_name_and_ptr_t siteFuncNamePtrMapping[ ] =
{“SiteCannedMethod_1”, (METHOD_function_t)siteCannedMethodFunc_1_ptr},
{“SiteCannedMethod_2”, (METHOD_function_t)siteCannedMethodFunc_2_ptr},
{“SiteCannedMethod_3”, (METHOD_function_t)siteCannedMethodFunc_3_ptr}
}
For an example of how to implement site canned methods, see Canned Methods
Example, later in this section.
3. Create an array of canned method details like the following:

METHOD_CM_Func_Detail_t siteCannedMethods[ ] =
{“Item”, ITEM_create_msg, METHOD_CM_Pre_Condition_type,

“SiteCannedMethod_1”, “”,“”, “”},
{“ItemRevision”, ITEM_copy_rev_msg, METHOD_CM_Pre_Action_type,

“SiteCannedMethod_2”,“”, “”, “”},
{“Document”, ITEM_delete_msg, METHOD_CM_Post_Action_type,

“SiteCannedMethod_3”, “option_1::option_2::option_3”,“1::0::1”,
“query_1~attr_1:: ::query_3~attr_3”}

Notice the blank space between query_1~attr_1::blank::query_3~attr_3:

int siteFuncNameMappingCount = sizeof(siteFuncNamePtrMapping)/
sizeof(METHOD_CM_func_name_and_ptr_t );
int siteCannedMethodCount = sizeof(siteCannedMethods)/

sizeof(METHOD_CM_Func_Detail_t);
// Add the mapping information for the session.
for( inx = 0; inx < siteFuncNameMappingCount; inx++)
ifail = METHOD_CM_register_function (siteFuncNamePtrMapping[inx]. func_name,
siteFuncNamePtrMapping[inx].func_ptr);
4. Add the canned methods information:

for( inx = 0; inx < siteCannedMethodCount; inx++)
ifail = METHOD_CM_add_method(
siteCannedMethods[inx].classOrObjectType,
siteCannedMethods[inx].msgName,
siteCannedMethods[inx].actionType,
siteCannedMethods[inx].funcName,
siteCannedMethods[inx].userDataTemplate,
siteCannedMethods[inx].isMandatoryTemplate,
siteCannedMethods[inx].userSavedQueryDetail );

Core Functions
Figure 6-3 shows a detailed example of how to construct your ITK program to add
canned methods.
#include <stdio.h>
#include <grmtype.h>
#include <iman.h>
#include <iman_arguments.h>
#include <iman_msg.h>
#include <item_msg.h>
#include <method.h>
#include <typecannedmethod.h>
#include <wso_msg.h>
#include <typecannedmethod_errors.h>
extern int verifyCannedMethodTagIsValid(tag_t cannedMethod)

{
logical
instance_exists = FALSE;
int
ec = ITK_ok;
ec = POM_instance_exists(cannedMethod, &instance_exists);
if (ec != ITK_ok) fprintf(stdout, "\tPOM_instance_exists failed with
%d\n", ec);
if (instance_exists == FALSE)
{
fprintf(stdout, "\tCanned Method Tag is Not Valid\n", ec);
ec = METHOD_CM_invalid_method_tag;
}
else ec = ITK_ok;
return ec;
}
extern int myCMwithLOV(METHOD_message_t *msg, va_list args)

{
int
ec = ITK_ok,
action_type = 0,
exec_seq = 0,
option_value_count = 0,
option_count = 0,
ii = 0,
jj = 0;
Figure 6-3. Canned Methods Example (Continued)

tag_t
*new_item = NULL,
*new_rev = NULL,
cannedMethod = NULLTAG;
char
method_name[METHOD_CM_MAX_METHOD_NAME_LEN + 1] = "",
type_name_from_method[WSO_name_size_c +1] = "",
msg_name[METHOD_CM_MAX_MSG_NAME_LEN + 1] = "",
***option_values = NULL,
*item_id = NULL,
*item_name = NULL,
*type_name_from_msg = NULL,
*rev_id = NULL;
fprintf(stdout, "myCMwithLOV...\n");
/********************************************************************
* This section demonstrates how to get information from the method
********************************************************************/
IMAN_init_argument_list(msg->user_args);
cannedMethod = IMAN_next_int_argument(msg->user_args);
ec = verifyCannedMethodTagIsValid(cannedMethod);
if (ec != ITK_ok) return ec;
ec = METHOD_CM_describe(cannedMethod, type_name_from_method, msg_name,

&action_type, method_name, &exec_seq, &option_value_count,
&option_count, &option_values);
if (ec != ITK_ok)
{
fprintf(stdout, "METHOD_CM_describe failed with %d\n", ec);
return ec;
}
fprintf(stdout, "\n Information from the method\n");
fprintf(stdout, "\t type_name_from_method = %s\n",
type_name_from_method);
fprintf(stdout, "\t msg_name = %s\n", msg_name);
if (action_type == METHOD_CM_Pre_Condition_type)
fprintf(stdout, "\t action_type = Pre-Condition\n");
if (action_type == METHOD_CM_Pre_Action_type)
fprintf(stdout, "\t action_type = Pre-Action\n");
if (action_type == METHOD_CM_Base_Action_type)
fprintf(stdout, "\t action_type = Base-Action Method\n");
if (action_type == METHOD_CM_Post_Action_type)
fprintf(stdout, "\t action_type = Post-Action Method\n");
fprintf(stdout, "\t Order of execution = %d\n", exec_seq);

fprintf(stdout, "\t Number of parameters = %d\n", option_value_count);
fprintf(stdout, "\t Number of options required for canned method = %d\n",
option_count);
fprintf(stdout, "\t Values passed:\n\t");
for (ii = 0; ii < option_value_count; ii++)
{
for (jj = 0; jj < option_count; jj++)
fprintf(stdout, "\t %s",option_values[ii][jj]);
fprintf(stdout, "\n\t");
}
for (ii = 0; ii < option_value_count; ii++)
{
MEM_free(option_values[ii]);
}
MEM_free(option_values);
Figure 6-3. Canned Methods Example (Continued)

Core Functions
/********************************************************************
* This section demonstrates how to get information from the message
********************************************************************/
item_id = va_arg(args, char *),
item_name = va_arg(args, char*),
type_name_from_msg = va_arg(args, char*),
rev_id = va_arg(args, char*);
new_item = va_arg(args, tag_t *),
new_rev = va_arg(args, tag_t *),
fprintf(stdout, "\n Information from the message\n");

fprintf(stdout, "\t item_id = %s\n", item_id);
fprintf(stdout, "\t item_name = %s\n",item_name);
fprintf(stdout, "\t type_name_from_msg = %s\n", type_name_from_msg);
fprintf(stdout, "\t rev_id = %s\n", rev_id);
fprintf(stdout, "\t new_item = %d - new_rev = %d\n",
*new_item, *new_rev);
/********************************************************************
* Add custom post action code here
********************************************************************/
return ec;
}
/****************************************************************************
* registerMyCMwithLOV
*
* This function registers a canned method that uses two List of Values
* The LOVs are based on two saved queries, myCMobjectTypes and
* myCMrelationTypes, both having the attribute type_name as search critrea.
*
* Add the following lines to com\ugsolutions\iman\businessrules\common\
* common_user.properties file:
* myCMwithLOV.DESC=Description for myCMwithLOV
* myCMwithLOV.objectType.LABEL=Select Object Type?
* myCMwithLOV.relationType.LABEL=Select Relation Type?
****************************************************************************/
extern int registerMyCannedMethodwithLOV( void )
{
int
ec = ITK_ok;
fprintf(stdout, "registerMyCannedMethodwithLOV...\n");
ec = METHOD_CM_register_function("myCMwithLOV",
(METHOD_function_t) myCMwithLOV);
if (ec == ITK_ok) fprintf(stdout,
"\tMETHOD_CM_register_function successful!\n");
else
{
fprintf(stdout, "\tMETHOD_CM_register_function failed with %d!\n", ec);
return ec;
}
ec = METHOD_CM_add_method("Item", ITEM_create_msg,
METHOD_CM_Post_Action_type,
"myCMwithLOV", "objectType::relationType", "Y::Y",
"myCMobjectTypes~type_name::myCMrelationTypes~type_name");
if (ec == ITK_ok) fprintf(stdout, "\tMETHOD_CM_add_method successful!\n");

else fprintf(stdout, "\tMETHOD_CM_add_method failed with %d!\n", ec);
return ec;
}
Figure 6-3. Canned Methods Example

Client-Side Modifications
To register the canned method on the rich client, you have to modify either the
common_user.properties file or the common_locale.properties file in the
com.ugsolutions.iman.businessrules.common directory. The entries are:
• func_name.DESC=description
This description of the canned method displays in the Business Modeler
application. The tooltip for the tree node in the Business Modeler application is
the same. This entry is required
• func_name.userData.LABEL=question
This is a question you can place in the Business Modeler application to prompt
the user to enter a value. This entry is required only if the canned method has
data in the user_data_template argument.
For example, for a canned method to create objects when an item or item revision
is created, the method needs to know which objects to create and what relation
to attach to them. For this method, the user_data_template argument would
be objectType::RelationType. Corresponding to the user_data_template
argument, there needs to be entry in the common_user.properties or
common_locale.properties file as shown below:
createObjects.objectType.LABEL=Object of which type needs to be created?
createObjects.RelationType.LABEL=What relation should the above object be
attached with to the Parent Object?
Figure 6-4 displays the various texts in the Business Modeler application.
Based on the func_name (as shown in this example, createObjects) the other
entries, such as createObjects.DESC, createObject.objectType.LABEL, and
createObjects.RelationType.LABEL are obtained from the properties file. The
information obtained from the server is:
• func_name (here createObjects)
• user_data_template (here objectType::RelationType)
• Mandatory details for each of the parameters. If a field is mandatory, the input
field is displayed with a red triangle in the top right corner.
• Saved query names for each of the parameters. If a field needs to have the values
from a saved query, they are obtained based on the user_dataQuery_detail
information.
Figure 6-4 shows the how the properties file entries and the
METHOD_CM_add_method method arguments appear in the
Business Modeler application.

Core Functions
Figure 6-4. Property File Entries
1 func_name = createObjects.
2 createObjects.DESC = This method will create specified objects
and attach them with specified relation to the Type for which this
canned method is configured.
3 createObjects.objectType.LABEL = Object Type To Create.
4 createObjects.RelationType.LABEL = Relation To Attach With.
5 user_data_template = objectType::RelationType.

Best Practices for Customization

The addition of the types, properties, and methods modules in Teamcenter introduces
a great deal of flexibility in the area of data model customization. You can now
create new types, modify the behavior of existing types, add their own properties,
and completely customize the ask, set, and initialize behavior of these properties
using methods.
Common Teamcenter Object Model Customization Scenarios

A combination of reference-based, relation-based, and runtime properties can
accommodate nearly all type customization requirements. For implementation
examples, refer to IMAN_ROOT/sample/properties/smp_props.c (UNIX
or Linux), IMAN_ROOT\sample\properties\smp_props.c (Windows) and
./smp_prop_customization.c.
The following sections discuss the following approaches and techniques used to
customize the Teamcenter object model:
• Tools and techniques
• Creating a new type versus adding a subclass
• Adding a persistent property to an existing type
• Adding runtime/derived properties to an existing type
• Adding a compound property to an existing type
• Adding a relation between two types
• Customizing the behavior (overall and property) of a type
Tools and Techniques

If you want to customize the Teamcenter object model, you must be familiar with the
following applications, utilities, and ITK programming techniques:
• Adding classes
You can add new POM classes with the Schema Browser (in other words, sb or
schema_browser utilities) or the install utility. For more information, see
the Utilities Reference manual.
• Adding types
You can add new types using the install_types utility or the IMANTYPE ITK
functions. For more information about the install_types utility, see the Utilities
Reference manual. For more information about the IMANTYPE ITK functions,
see the Integration Toolkit Function Reference manual.
• Adding properties
You can add new properties to a type by declaring the function prototype
and inserting the name of the type and the function name into the
user_types_methods array definition inside the USER_register_properties
function in the user_init.c file. For more information, see Registering a Property
init_module Function, earlier in this chapter.

Core Functions
Creating a New Type Versus Adding a Subclass
Teamcenter only allows one level of subtypes to be added to each POM class. In
other words, you cannot create a subtype of an existing subtype in the same POM
class. Therefore, if you need additional subtypes, they must be added to a new POM
class or subclass. There is no limitation to the number and levels of subclasses that
can be added to a POM class.
The best way to specialize an existing Teamcenter object is to add a new type
rather than creating a new subclass. This is because subtypes inherit all the
properties and behavior of the super-type (in other words, primary type).
Also, adding a new subclass by extending the POM schema is a permanent
change. A type can be removed at a later date when it is no longer needed.
When creating a type for the Item class, corresponding types must be created
for the ItemRevision, ItemMaster, and ItemRevisionMaster classes. The
IMAN_BIN/install_types utility automatically creates these parallel types when a
new type is added to any one of the four classes. However, if one of the four parallel
types is deleted, the other three are not automatically deleted.
Teamcenter does not allow subclasses of the Item or ItemRevision POM
classes. If you try to add a subclass to them, you may see unpredictable
behavior and lose data. Therefore, use types to specialize these classes.
When creating a subclass of the Folder class, use the Schema Browser to create the
new subclass. Because there is no user interface for creating instances of Folder
subclasses, you must write some user interface extensions to instantiate any new
Folder subclasses.
Although the Dataset POM class can be subclassed, it is not advisable. Instead, use
a dataset type to specialize this class. Additionally, it is possible to extend a dataset
type by adding a form as a named reference. For more information about creating
and managing dataset types and named references, see Type Help.
Although the Form POM class can be subclassed, it is not advisable. Instead, use
a form type to specialize this class. For additional information about creating and
managing form types, see Type Help.

Adding a New Relation Type

Teamcenter supplies a standard set of relation types including Specification,
Manifestation, and Requirement. You can define new relation types. For
example, to create a new Model relation:
1. Define a new relation type using one of the following:
• GRM_create_relation_type function
• install_types utility
For example:
$IMAN_BIN/install_types -f=add -c=ImanRelation/
-t=CUSTOM_model
2. Define two text strings for this new relation type. One string is singular and is
used to display the relation type name in the user interface (for example, in
the Workspace Relation column). The other string is plural and is used when
displaying pseudo-folders.
3. Define the relation type text strings by adding new entries to iman_text.uil
according to the following format:
gk_relation-name_att
gk_relation-name_pf
For example:
gk_CUSTOM_model_att : exported "Model";
gk_CUSTOM_model_pf : exported "Models";
4. Compile the iman_text.uil file and copy the resulting the iman_text.uid file to
IMAN_APP_UID_DIR or IMAN_USER_UID_DIR as appropriate.
5. Define a display name for the property that is mapped onto this relation by
adding the following to the user_property_names.uih file:
CUSTOM_model : exported "Model";
6. Compile the property_names.uil file and copy the resulting

property_names.uid file to IMAN_APP_UID_DIR or
IMAN_USER_UID_DIR as appropriate.
7. To make this new relation type accessible from the Item Display Options dialog
window, add a relation-name_relation_primary preference entry to the site
preference stored in the database, listing each type of item and item revision you
want to be able to show the relation under. For example:
CUSTOM_model_relation_primary=
Item
ItemRevision
Document
DocumentRevision
You can also attach relations to objects other than items and item
revisions, but steps 5 and 7 would not apply in such a case, as you
cannot display such relationships in the workspace.

Core Functions
Adding a Persistent Property
You can add a persistent property to an existing type by adding the corresponding
attribute to an existing class or to a new subclass. The following shows various ways
to add a new persistent property, property2, to the database.
Adding an Attribute to an Existing Class
Adding an attribute to an existing class is rarely used because it is not possible to

add attributes to instantiated classes. Additionally, the Schema Browser does not
allow attributes to be added to saved classes even if they have not been instantiated.
However, if you are creating a new class, and have not created an instance of that
class in the database, this technique can be valuable. Figure 6-5 shows an example
of adding an attribute to an existing class.
Figure 6-5. Adding an Attribute to an Existing Class

The Schema Browser limitation can be overcome by using the install utility with
the –add_attr argument.
Once the attribute is added to the class, a new property is automatically generated
for the primary type. This property is created with default behavior (in other words,
the property is read-only and is not displayed in the workspace).
To add the attribute2 attribute to the existing ExampleA class (as shown in figure
6-5), follow these steps:
1. Add attribute2 to the ExampleA class using the Schema Browser or install
utility.
Steps 2 and 3 are required only if you are customizing the default
property behavior.
2. Register a property init module function for the ExampleA type.
3. Insert code into the property init module function to customize the behavior of
property2.

Adding an Attribute to a New Subclass
Because of the limitations that exist for adding attributes to existing Teamcenter
classes, another technique for adding a persistent property to a type is to create a
new subclass with the desired attributes. These attributes can then be mapped to a
new type. Figure 6-6 shows an example of adding an attribute to a new subclass.
Figure 6-6. Adding an Attribute to a New Subclass

The new subclass and attribute can be added using the Schema Browser. A primary
type is automatically be created with the same name as the class if the install_types
utility is run without any parameters, and if the underlying class is a workspace
object. To create a type for a non-workspace object or to create a type with a different
name than the subclass, run the install_types utility with the –f=add argument.
To add the attribute2 attribute to the new SubExampleA subclass, follow these
steps:
1. Add the new SubExampleA subclass to the ExampleA class with the Schema
Browser or install utility.
2. Add the new SubExampleA primary type with the install_types utility or the
IMANTYPE ITK functions.
3. The SubExampleA type inherits all of the properties of the ExampleA primary
type and automatically has a property that corresponds (in other words, has the
same name as) to attribute2.
Steps 4 and 5 are only required if you are customizing the default
property behavior.
4. Register a property init module function for the SubExampleA type.
property2.

Core Functions
Adding a Property From a Relation
Adding a relation between two classes (in other words, between a primary class and
a secondary class) is a technique that allows all the attributes of both classes to be
displayed as properties associated with the primary class. There are two approaches
that can be used for adding a relation between two classes:
• Teamcenter preference settings
• ITK
The advantage of using Teamcenter preference settings is that the relation

can be part of a Workspace Find by Class query.
Figure 6-7 shows how property2 can be added to the ExampleA type from the
ExampleB class using the RelationAB relation.
Figure 6-7. Adding a Property From a Relation
Adding a Property From a Relation Using Teamcenter Preference Settings
A generic preference (relation_type_relation_primary) automatically creates a

relation property on specified types by manually modifying the preference stored in
the database. For more information about adding relations using the Teamcenter
preference setting, see the Configuration Guide.
To add a new property (property2) from a relation (RelationAB) using Teamcenter
preference settings, follow these steps:
1. Create a new GRM type using the GRM_create_relation_type function or the
install_types utility.
2. Create a new relation_type_relation_primary preference entry in the

appropriate preference file stored in the database.
Steps 3 and 4 are only required if you are customizing the default
property behavior.
property2.

Adding a Property From a Relation Using ITK

To add a new property (property2) from a relation (RelationAB) using ITK,
follow these steps:
1. Create a new GRM type using the GRM_create_relation_type function or the
install_types utility.
3. Insert code into the property init module function to add the property2
relation property.
Step 4 is only required if you are customizing the default property
behavior.
property2.
Adding a Runtime (Derived) Property

Adding a runtime property is similar to adding a persistent property except that
Teamcenter controls the behavior of the property at runtime before displaying it to
the user. Essentially, the displayed value of the property is derived each time the
property is displayed.
Runtime properties can use many kinds of information (for example, property values
from other types, attributes of other classes, and system date and time) to derive
the displayed value. Figure 6-8 shows a runtime property (property2) derived from
two pieces of information: attribute2 and system date.
Figure 6-8. Adding a Runtime Property

To derive property2 from attribute2 and the system date, follow these steps:
2. Insert code into the property init module function to add runtime property2.
3. Insert code into the property init module function to customize the
behavior of property2. This must include registering a method against the
PROP_ask_value_type_msg function. This function contains the code for
deriving the value of this runtime property.
When you add a runtime property, the locking, unlocking, refreshing
and saving of the referenced object must be performed by the new
code. This is especially important when writing a method for the
PROP_set_value_type_msg function. Your code must lock the object, set
the value, save, and unlock the object entirely within the method.

Core Functions
Adding a Compound Property
You can add a compound property by defining a compound property rule through the
Compound Property rule module of the Business Modeler application. For further
details about creating a compound property rule, see Business Modeler Help.
UGS recommends that you use the Compound Property rules functionality when
you want a property to be displayed from an object (display object) as if it were the
object’s own property, though it is actually defined and resides on another object (the
source object), where the display and the source objects are connected through one
or more reference/relation properties.
Customizing the Behavior of a Type
There are two basic approaches that can be used to customize behavior of a type:
• Customize overall behavior (for example, create, save, delete)
• Customize property behavior (for example, askValue, setValue)
Customize the Overall Behavior
The overall behavior of a type (for example, create, save, and delete) is defined by
a set of messages that are passed to the type at runtime. These messages are
implemented using methods. New methods can be defined for a type (base action)
or existing methods can be customized and extended by adding a precondition,
preaction, or postaction.
Customize the Property Behavior
It is also possible to change the ask, set, and initialize behavior of both existing and
newly created properties. This is accomplished with the following ITK messages:
• PROP_UIF_ask_value_msg
• PROP_UIF_set_value_msg
• PROP_init_value_msg
• PROP_ask_value_type_msg
• PROP_ask_value_types_msg
• PROP_ask_value_type_at_msg
• PROP_set_value_type_msg
• PROP_set_value_types_msg
• PROP_set_value_type_at_msg
• PROP_is_modifiable_msg

Where type is one the following data types:

• Date (date)
• Double-precision floating point decimal (double)
• Integer (int)
• Logical (logical)
• Unique identifier (tag)
For examples of how to implement customizations using these messages in

conjunction with the METHOD_register_prop_method method, see the
IMAN_ROOT/sample/smp_prop_customization.c file.
Customizing the Master Suffix
If you want to customize the master suffix (for example, change it from Master to
_Master), follow these steps:
1. Go to the IMAN_ROOT/lang/textserver/language directory and open the
iman_text.xml file in a text editor.
2. Search for <key id="gk_master_suffix">.
3. Change the key entry to your custom master suffix (for example, change it from
Master to _Master).
4. Save the file and close the text editor.
5. Log into the rich client as an administrator.
6. Open the Type application.
7. Expand the Form Type and click the Item Master type.
8. In New subtype name, enter the new Form type name that reflects the new
suffix. It must be in the form Itemnew-suffix (for example, Item_Master).
9. Click Create.
10. Click the ItemRevision Master type.
11. Repeat steps 8–9 for ItemRevision Master. It must be in the form
ItemRevisionnew-suffix (for example, ItemRevision_Master).
12. Log off the rich client.
When you restart the rich client, the new master suffix takes effect.

Core Functions
General Hints on Customizing Properties

The following sections provide general hints and guidelines about customizing
properties. The following topics are discussed:
• Memory allocation
• Method arguments
• Messages
• Value caching
• Display names
• Hiding properties
• Workspace columns
Memory Allocation
If string values are to be passed from one function to another, the memory allocated
to these string values must be persistent. Therefore, the following memory allocation
ITK calls must be made:
• MEM_alloc_persistent
• MEM_string_copy_persistent
These functions ensure retention of memory until the MEM_free function is called.
Method Arguments
Method arguments extracted using va_arg must be extracted in the sequence

indicated in the Integration Toolkit Function Reference manual. For example:
tag_t prop_tag = va_args(args, tag_t);
char **value = va_args(args, char**);

Messages
The following sections provide hints, guidelines, and cautions about specific message
functions.
PROP_init_value_msg
The PROP_init_value_msg function initializes a property with a specified value.

A method registered against this message does not exist for most objects.
Therefore the METHOD_find_method, METHOD_add_action, and
some other functions cannot be used unless another method is registered.
The METHOD_find_method function does not consider this an error and
does not return a failure code. It merely returns a null method_id.
PROP_ask_value_type_msg
The PROP_ask_value_type_msg function can be used to return the value of a

property.
This message is called by most ITK functions and internally by Teamcenter.
However, some ITK functions (for example, Form, FL, AE, and so on) may
be bypassing this code at this time.
Never call the PROP_ask_value_type function from inside a method

registered against the PROP_ask_value_type_msg function on the same
property. This forces Teamcenter into a recursive loop. Instead use the
PROP_get_value_type function to get the raw data value.
PROP_set_value_type_msg
The PROP_set_value_type_msg function is passed whenever the user chooses OK
or Apply in the Attributes dialog window or sets a value in the workspace, PSE, or
with ITK. The PROP_assign_value_type function can be used.
Never call the PROP_set_value_type function from inside a method
registered against the PROP_set_value_type_msg function on the same
property. This forces Teamcenter into a recursive loop. Instead use the
PROP_assign_value_type function to store the raw data value.
Value Caching
Value caching is a technique used with runtime properties to improve performance.

This is valuable when the value of a derived property is not likely to change during
the current Teamcenter session. To cache values, use the following technique:
1. The first time a runtime property is called using the PROP_ask_value_string
method, cache the string value with the PROP_assign_type method.
2. On subsequent PROP_ask_value_string method calls, use the cached value by

calling the PROP_get_type method.

Core Functions
Display Names
Each Teamcenter property can be displayed in the user interface using the actual
(in other words, programming) property name or another more descriptive display
name. In most cases, the display name is more useful. Either of the following
techniques can be used to define property display names:
• Call the PROPDESC_set_display_name function in the property initialization
module function registered for the type on which this property exits.
• Edit the display name in the

IMAN_ROOT/lang/textserver/language/user_property_names.xml file.
If the name is set using the first technique, it appears in the Attributes
dialog window and is returned by the PROPDESC_ask_display_name and
AOM_UIF_ask_name functions.
If the name is set using the second technique, it is also a possible candidate for a
workspace column.
Hiding Properties
There are two techniques for hiding a property from the end user:
• Comment out the display name of the property as follows:
In the IMAN_ROOT/lang/textserver/language/user_property_names.xml
file, add the following:
<key id="">system_prop_name</key>
• Use the following method:

1. Call the PROPDESC_set_display_name method in the property
initialization method registered for the type on which this property exists.
2. Remove the property by calling the IMANTYPE_remove_property method

in the property initialization method registered for the type on which this
property exists.
The first option is preferable if you only want to hide unneeded properties from
the end user.

You can make these properties visible by setting the

PROP_display_real_propnames preference to TRUE. This can
be done by using ITK or through XML.
• If you use ITK, set the property display name to a null_string ( "" ). For example:
PROPDESC_set_display_name( pd_tag, "" )
• If you use XML, open the

IMAN_ROOT/lang/textserver/language/user_property_names.xml file and
set the attribute display name to "". For example:
<key id="">system_prop_name</key>
Ensure that the property name does not already exist in the
system_property_names.xml file.
Workspace Columns
If newly added properties are to be displayed as workspace columns, the default

IMAN_DATA file from the database must be copied and modified. Consider the
following example of adding a new workspace column called MyNewProperty:
WSColumnsShownPref=
object_type
owning_user
MyNewProperty
WSShownColumnWidthsPref=
20
32
32

Chapter
7 System Administrator
List of Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Properties Based on Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Properties Based on Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Runtime Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Capabilities and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Custom Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Creating a Custom Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Audit Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Defining an Action Handler for Audit Manager . . . . . . . . . . . . . . . . . . . . 7-4
Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-5

Adding New User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-5
Adding New Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-7
Step 1: Develop the C Custom Extension Code . . . . . . . . . ..... . . . . 7-7
Step 2: Build the Library . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-14
Step 3: Implement the C Custom Extension . . . . . . . . . . . ..... . . . . 7-15
Step 4: Define the Extension Using the Business Modeler User
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-15
Step 5: Assign the Extension . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-17
Step 6: Execute the Extension . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-17
Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-18
Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-18
BMOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-18
ExtensionPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-18
ExtensionDescriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-19
TypeBMOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-19
PropertyBMOperation . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-19
BusinessRuleDescriptor . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . 7-19

Chapter
7 System Administrator
This chapter describes the modules that contain system administration functionality.
List of Values
Use the List of Values (LOV) functions to define lists of values and to associate
them with attributes and properties. Associations can be stored in the database
(persistent) or independently associated for each Teamcenter session (runtime).
There are three types of LOV:
1. Properties based on type
2. Properties based on instance
3. Runtime properties
LOV is defined as a class in Teamcenter. Programmers can create, modify, and delete
LOVs using either ITK or the List of Values application in Teamcenter. This allows
you to view LOVs by entering ? in any attribute field.
Properties Based on Type

An LOV can be persistently associated to any type property. For example, different
LOVs could be defined for two types of the same class (for example, mechanical parts
and electrical parts for the item class).
Properties Based on Instance

An LOV can be persistently associated to one or more instances of a type property.
For example, an alternate LOV could be defined based on a range of serial numbers
or dates.
Runtime Properties
LOVs based on runtime properties are created and associated during each
Teamcenter session and are not persistent (in other words, not stored in the
database). For example, an attribute could have separate LOVs defined for each
state of a runtime property (for example, is_late: YES or NO).

Chapter 7 System Administrator
Capabilities and Limitations

You can create LOVs to define and limit user-entered values according to the
following rules:
• Exhaustive List of Values
Users must select one of the items on LOV. Other values are not allowed.
• Range of Values
LOV defines a range (upper and lower limits) of acceptable values. Other values
are not allowed.
• Suggested Value
LOV provides user with suggested values. Other values are allowed.
LOVs can contain integers, floating-point decimals, strings, dates, and tags. You can
register the handlers used to create LOV contents.
Access Manager
Custom Privileges
To create a new custom privilege, you must perform the following tasks:
• Define the new privilege in the am_text.xml file.
• Add the new privilege to the database using the install utility.
There are two attributes of a custom privilege that you must manually define in
the am_text.xml file:
• Privilege name
• Privilege token
The privilege name is the unique identifier that Teamcenter uses to store privileges
in the database; the token is the single-letter mnemonic for that privilege (for
example, R is the token for the default read privilege).
Figure 7-1 is a partial listing of the am_text.xml file:
<key id="k_am_rule_object_acl">Has Object ACL</key>

<key id="k_am_rule_has_class">Has Class</key>
<key id="k_am_rule_owning_user">Owning User</key>
<key id="k_am_rule_owning_group">Owning Group</key>
<key id="k_am_rule_owning_group_has_security">Owning Group Has Security</key>
Figure 7-1. Partial Listing of the am_text.xml File

System Administrator
Creating a Custom Privilege

To create a custom privilege, follow these steps:
1. Manually add the entries below to the
IMAN_ROOT/lang/textserver/language/am_text.xml
file:
• A name entry as follows:
<key id="k_am_priv_NAME">NAME</key>
• A token entry as follows:

<key id="k_am_token_NAME">T</key>
NAME is the name and T is the single-letter token you define for
this new custom privilege.
2. Run the install utility with the -priv argument by entering the following:
install -priv NAME infodba password dba
password is the infodba password and NAME is the new name for this
custom privilege you defined in step 1.

Audit Manager
Defining an Action Handler for Audit Manager

To define an action handler for Audit Manager, follow these steps:
1. Create a file (for example, my_handler.c) in the \users_exits\code directory
with the following code:
#include <subscription.h>
int PEC_Log_Handler(void* message, int nArgs, char** args)
{
ImanSubscriptionActionMsg_t* msg =
(ImanSubscriptionActionMsg_t*)message;
// add handler code here
return 0;
}
2. Declare the function in the user_exits.h file:

extern USER_EXITS_API int PEC_Log_Handler(void* message, int nArgs,
char** args);
ImanSubscriptionActionMsg_t is defined in the subscription.h file.
3. Compile the file and build the libuser_exits.dll file.
4. Install the handler. For example:

%IMAN_BIN%\install_handlers -f=create -id=PEC_Log_Handler
-funcname=PEC_log_Handler -functype=1 -execmode=1 exectime=1800
5. Modify the audit definition objects. You can modify the

IMAN_DATA\auditdefinition.dat file to add the new handler to
the audit definition object you want to change. Then either run the
IMAN_BIN\define_auditdefs -f=auditdefinition.dat command or
interactively log in to the Audit Manager application in the rich client and
modify the audit definition objects to add the new handler.

Business Modeler
Adding New User Exits

The macros used by user exits are defined in the bmfmessagemapping.hxx file
in the /src/bmf/code directory. The steps to set up a user exit within the Business
Modeler Framework (BMF) are outlined below:
1. Add the message details (unique #define value) in the user_exit_msg.h file
located in the src/user_exits/code directory.
2. Add a user exit macro entry in the appropriate (type or property) BMF message
mapping block defined in the bmfuserexithelper.cxx file (found in the
src/bmf/code directory):
ADD_BMF_USER_EXIT_MSG(typeName, message, extensionName,
functionPointer)
ADD_BMF_USER_EXIT_PROP_MSG(typeName, message, propertyName,
extensionName, functionPointer)
• For type user exit messages that support the methods framework:
For example, if you introduce a new type user exit message, such as
ITEM_myexit_msg on item types, then update the following list in the
bmfuserexithelper.cxx file:
BEGIN_BMF_MSG_MAP(BMFUserExitHelper,"BMFUserExitHelper"):
ADD_BMF_USER_EXIT_MSG("ImanQuery", QRY_execute_msg,
"BMF_USER_query_execute", 0)
ADD_BMF_USER_EXIT_MSG("Appearance",
APPR_update_enditem_search_results_msg,
"BMF_USER_appr_update_end_item_search_results", 0)
ADD_BMF_USER_EXIT_MSG("Item", ITEM_create_msg,
"BMF_USER_create_item", 0)
ADD_BMF_USER_EXIT_MSG("Item", ITEM_create_post_msg,
"BMF_USER_item_created", 0)
ADD_BMF_USER_EXIT_MSG("Item", ITEM_myexit_msg,
"BMF_USER_myexit", 0)
END_BMF_MESSAGE_MAP()
The last parameter of the ADD_BMF_USER_EXIT_MSG macro is

always set to zero. It is a placeholder for the function pointer. The
function pointer symbol is dynamically loaded at runtime.

• For property user exit messages that support the methods framework:
For example, if you introduce a new property user exit message to get
a custom user description, such as ITEM_get_desc_msg on a property
“object_desc” on item types, then update the following list in the
bmfuserexithelper.cxx file:
BEGIN_BMF_PROP_MSG_MAP(BMFUserExitHelper,"BMFUserExitHelper"):
ADD_BMF_USER_EXIT_PROP_MSG("Item", ITEM_check_above_erct_msg,
"user_data1", "", 0)
ADD_BMF_USER_EXIT_PROP_MSG("Item", ITEM_ask_display_revisions_msg,
"configuration_object_tag", "", 0)
ADD_BMF_USER_EXIT_PROP_MSG("Item", ITEM_assign_new_id_msg, "item_id",
"", 0)
ADD_BMF_USER_EXIT_PROP_MSG("Item", ITEM_get_desc_msg,"object_desc",
"", 0)
END_BMF_PROP_MESSAGE_MAP()
The fourth parameter of the

ADD_BMF_USER_EXIT_PROP_MSG macro is
always set to "" since the BMF generates the extension name to use
for property extensions. The last parameter is always set to zero.
It is a placeholder for the function pointer. The function pointer
symbol is dynamically loaded at run time.
3. In the user exit itself, add the following macro before executing any
other statements. This macro is defined in the bmf.h file, located in the
src/itk/code directory. See examples in the user_part_no.c file, located in the
src/user_exits/code directory. The variable argument list is dependent on the
specific parameters that any user exit requires.
BMF_EXECUTE_USER_EXIT_EXTENSIONS(typeName, propName, message, args...);
• For the type user exit message example:

BMF_EXECUTE_USER_EXIT_EXTENSIONS("Item", "",
ITEM_myexit_msg, args...);
• For the property user exit message example:

BMF_EXECUTE_USER_EXIT_EXTENSIONS("Item", "object_desc",
ITEM_get_desc_msg, args...);
4. Add an autotest for this user exit in the /src/bmf/test directory.

Adding New Extensions

This section explains how you create and use a custom C extension in Teamcenter
Engineering. This involves the following steps:
1. Develop the C custom extension code.
2. Build the library using the C custom extension code.
3. Define the extension using the Business Modeler user interface.
4. Assign the extension to an extension point.
5. Execute the extension.
Step 1: Develop the C Custom Extension Code
This section describes what is involved in coding a custom extension for use within
the Business Modeler Framework (BMF). The example referenced here is used in the
implementation illustration in the following section. This custom extension initiates
a workflow process on an item revision (after it is created) when creating an item.
This is custom code developed using standard ITK development practices.
#ifndef BMF_SAMPLE_C_2
#define BMF_SAMPLE_C_2
#include "bmf_extension_utils.h"
#include <epm.h>
#include <bmf.h>
#include <libuserext_exports.h>
extern USER_EXT_DLL_API int

bmf_extension_workflow_sample(METHOD_message_t* msg,
va_list args);
#include <libuserext_undef.h>
#endif // BMF_SAMPLE_C_2
Figure 7-2. bmf_extension_workflow_sample.h Include File

• #include bmf.h
Contains the structure definition (BMF_extension_arguments_t) needed
for processing user parameter data. This is processed as an array of these
structures by the developer.
typedef struct BMF_extension_arguments_s
{
char paramName[BMF_EXTENSION_ARGNAME_size_c + 1];
union val_union
{
int int_value;
double double_value;
char str_value[BMF_EXTENSION_STRGVAL_size_c + 1];
}arg_val;
} BMF_extension_arguments_t;
paramName
Contains the value of the Name field entered by the administrator in the
Parameter Details dialog window when defining the extension through the
Business Modeler application (see the example in Step 3: Implement the C
Custom Extension). In the example, there are two: Release Process and
Company ID.
val_union
Contains the actual value defined for the specified paramName when the
administrator assigns the extension to an entry point in the Argument Panel
for extension on the Assign Extension tab (made up of only one of the three
value definitions at one time based on the type of value). In the example,
Release Process is a mandatory String, and Company ID is an optional
Integer. A mandatory value is always present. An optional value may or
may not be present.
Contains the ITK function definition (BMF_get_user_params defined in

the bmf.h file) needed for retrieving the user parameter data of the custom
extension. This ITK function returns a row count and an array of all the existing
user parameter name/value pairs (using the BMF_extension_arguments_t
structure described above) from the input METHOD_message_t structure.
This array of structures needs to be freed by the ITK developer using a call
to the MEM_free function.
• #include libuserext_exports.h
Contains definitions needed for processing.
• #include libuserext_undef.h
Contains the symbol definition processing required for the user extension API.

• Any additional #include lines that need to be defined for the custom extension
based on functionality. In the sample, the epm.h file is needed because of the
workflow processing functionality it is using.
• USER_EXT_DLL_API
extern USER_EXT_DLL_API custom-extension-function
Prototype for each function that is created as a custom extension. In the

example, there is only one:
extern USER_EXT_DLL_API
bmf_extension_workflow_sample(
METHOD_message_t* msg,
va_list args);
All functions used as custom extensions must be defined this way.

The user parameters for the custom extension are stored in the message
structure (msg parameter) and retrieved by the BMF_get_user_params
function.
va_list contains the arguments for the current operation.

#include "bmf_extension_workflow_sample.h"
int getArgByName(BMF_extension_arguments_t* p,
int arg_cnt,
const char* paramName)
{
int i;
for (i =0; i < arg_cnt; i++)
{
if (iman_strcmp(paramName, p[i].paramName) == 0)
{
return i;
}
}
return -1;
}
int bmf_extension_workflow_sample(METHOD_message_t* msg,

va_list args)
{
int ifail = ITK_ok;
tag_t item_tag = NULLTAG;
tag_t rev_tag = NULLTAG;
char * item_id;
char * item_name;
char * type_name;
char * rev_id;
tag_t * new_item;
tag_t * new_rev;
char relproc[BMF_EXTENSION_STRGVAL_size_c + 1];

int no_args;
char job_desc[WSO_desc_size_c + 1] = {’\0’};
char job_name[WSO_name_size_c + 1] = {’\0’};
tag_t job_tag = NULLTAG;
char* bm_operation_name = 0;
char* bm_type_name = 0;
char* bm_property_name = 0;
Input_Params_t* params = NULL;

BMF_extension_arguments_t* tmpparam = NULL;
int paramCount =0;
int companyid = 0;
int attachment_type;
tag_t template_tag = NULLTAG;
tag_t allocation_tag = NULLTAG;
char *allocation_obj = NULL;
BMF_extension_arguments_t *input_args = NULL;
int index;
int divisionid;
Figure 7-3. bmf_extension_workflow_sample.c Source File (Continued)

/********************/
/* Initialization */
/********************/
//Get the parameters from the ITEM_create_msg

item_id = va_arg( args, char *);
item_name = va_arg( args, char *);
type_name = va_arg( args, char *);
rev_id = va_arg( args, char *);
new_item = va_arg( args, tag_t *);
new_rev = va_arg( args, tag_t *);
item_tag = *new_item;
rev_tag = *new_rev;
// Extract the user arguments from the message

ifail = BMF_get_user_params(msg, &paramCount, &input_args);
if (ifail == ITK_ok && paramCount > 0)

{
index = getArgByName(input_args, paramCount, "Release Process");
if (index != -1)
{
iman_strcpy(relproc, input_args[index].arg_val.str_value);
}
index = getArgByName(input_args, paramCount, "Company ID");

if (index != -1)
{
companyid = input_args[index].arg_val.int_value;
}
MEM_free(input_args);
Figure 7-3. bmf_extension_workflow_sample.c Source File (Continued)

/**************/
/* ITK code */
/**************/
If (relproc != NULL)
{
if (rev_tag != NULLTAG)
{
sprintf( job_name, "%s/%s-%d Job",
item_id, rev_id, companyid );
sprintf( job_desc,
"Auto initiate job for item/rev (%s/%s-%d)",
item_id, rev_id, companyid );
//Get the template tag.

ifail = EPM_find_template(relproc , 0, &template_tag);
if (ifail != ITK_ok)
{
return ifail;
}
// Create the job, intiate it and

// attach it to the item revision.
attachment_type = EPM_target_attachment;
ifail = EPM_create_process(job_name, job_desc,
template_tag, 1,
&rev_tag, &attachment_type,
&job_tag) ;
{
return ifail;
}
}
}
else
{
//throw error
}
}
return ifail;
} /* end of function - bmf_extension_workflow_sample */
Figure 7-3. bmf_extension_workflow_sample.c Source File

• #include custom *.h file described above

In the example, it is as follows:
#include bmf_extension_workflow_sample.h
• Any source code functions that need to be written to support the custom
extension based functionality. In the sample, there are two functions:
int getArgByName(
BMF_extension_arguments_t* p,
int arg_cnt,
const char* paramName)
Given the user arguments returned by the call to the BMF_get_user_params

function, return the index in the user argument array based on the input
parameter name string.
Any optional parameters for which no value was specified is not present in the
data array, so this function returns a –1.
int bmf_extension_workflow_sample(
METHOD_message_t* msg,
va_list args);
Retrieve the message parameters for the current operation using va_arg.
In this example, the current operation is ITEM_create_msg. So there are
four character string (pointers) and two tag_t pointers to retrieve. This data
represents item ID, item name, type name, revision ID, new item, and new
revision, respectively.
Retrieve the custom extension parameters from the user parameters of the
message using the BMF_get_user_params function. In this example, the
custom extension is bmf_extension_workflow_sample. So there is one
mandatory character string value and one optional integer value to retrieve.
This data represents Release Process and Company ID, respectively.
• Process each of the individual extension parameters that have been retrieved
into the array of BMF_extension_arguments_t structures.
Call the getArgByName local function to retrieve the appropriate value for
each data element and assign it to the appropriate variable.
The source code needs to be able to handle optional parameters that were not
assigned on a particular extension point.
• Now all of the data from the message and from the custom extension should be
available to you. Write the rest of the ITK functionality to accomplish the goal.

Keep in mind the following:

• An extension should be expected to process one message.
• The message data and custom extension user data are independent of each
other so it does not matter which is processed first. However, they should be
processed together as a set.
• You are expected to know the data that exists for the message. This includes
data types and the retrieval order so this data can be processed properly using
va_arg.
• You are expected to know the user data that exists for the custom extension. This
includes data types and whether each data element is mandatory or optional
so that this data can be processed properly after the BMF_get_user_params
function is used to retrieve this data.
• Several extensions can be compiled into the same library.

– Copy all the implementation C files to the same directory.
– Use the compile scripts (discussed below) and specify multiple targets to
be compiled.
– Execute the link script once to produce the library containing these
extensions.
Step 2: Build the Library
Compile and link the C custom code into a library. The directory path to this
library file is important and is used in a site preference value (described in Step 3:
Implement the C Custom Extension). This example describes a Windows build but
the process is similar for UNIX or Linux.
1. Start the Teamcenter environment console.
2. Change the current folder to where your extension files are.
3. Compile the code using the following command:

%IMAN_ROOT%/sample/compile -debug -DIPLIB=none
bmf_extension_workflow_sample.c
The compiler status should be zero if successful.
4. Link the code using the following command:

%IMAN_ROOT%/sample/link_custom_exits libsampleExtension
If there are errors, they show up between the create and link lines.
The libsampleExtension.dll file is in the current folder.

Step 3: Implement the C Custom Extension
This example illustrates how to set up a custom extension. It involves defining the
extension to the system and assigning the extension points to use this extension.
The implementation of the workflow custom extension (the sample developed in
the previous steps) initiates a workflow process on an item revision when creating
an item.
1. Launch the rich client and log into the Business Modeler with a user who has
the dba role.
2. Choose Edit→Options.
3. Click Search and enter BMF in Search on keywords. Click the Search button.
4. Click BMF_CUSTOM_IMPLEMENTOR_PATH in the Preferences list.
5. Set it to the full directory path where the extension files are located and choose
Modify.
Multiple path definitions are allowed and you can define both Windows and
UNIX/Linux paths at the same time. The application only loads those that match
the current server platform. This preference needs to be set so that the application
knows where to look for custom extensions. Once set, close the rich client and
start it again to load the new site preference values. For more information, see
the Configuration Guide.
Step 4: Define the Extension Using the Business Modeler User Interface
1. In the Business Modeler, click the Extension Rules tab. The Define Extensions
subtab is displayed.
2. Enter the name of the extension rule. In this example,

bmf_extension_workflow_sample. This name must match the
function name defined in the header file.
3. In Language Type, select C.
4. In Library, enter libsampleExtension.
5. In Parameter Set, select Multiple since there are two input parameters
(Release Process and Company ID).

6. Add the parameter definition to this extension.

a. Click the Add button in the Parameter List panel. The Parameter Details
dialog window is displayed.
b. Create the Release Process parameter.

• In Name, enter Release Process.
• In Type, select String.
• Select Mandatory to make the parameter mandatory.
• Click Apply.
c. Create the Company ID parameter.

• In Name, enter Company ID.
• In Type, select Integer.
• Clear Mandatory to make the parameter optional.
• Click Apply.
d. Close the Parameter Details dialog.
7. Modify the availability of this extension.

a. Click the Add button in the Availability panel. The Select Extension Point
dialog window is displayed.
b. In Select Type or Property, ensure Type is selected.

• In the tree, select Item.
• In Operation, select Create.
• In Extension Point, select Post-Action.
• Click Apply.
c. Close the Select Extension Point dialog window.
8. On the Extension Rules tab, choose Create.
This extension is now available to Item Create only as a postaction.

Step 5: Assign the Extension
1. Click the Assign Extensions subtab.
2. In Select Type or Property, ensure Type is selected.

• In the tree, select Item.
• In Operation, select Create.
• In Extension Point, select Post-Action.
3. Click the Add button on the top right to add an empty row in the Extension
Name list.
4. Double-click the Extension Name field in the table row and select
bmf_extension_workflow_sample.
5. Check Active in the table row to activate this extension.

The two arguments that were defined for this extension appear in Argument
Panel for extension with any mandatory fields highlighted with a star.
6. For the Release Process parameter, enter TCM Release Process.

For the Company ID parameter, enter 56.
Click Add next to the Arguments box.
7. Click Apply to attach the rule to the specified extension point.
Step 6: Execute the Extension
1. In the rich client, launch My Navigator.
2. Create a new item.
You see a TCM workflow process attached to the item revision when the item is
created.

Classes
Extension
This class stores information about the method information that is executed in an
operation. The attributes in this class are:
name
The name of the extension. The format is namespace::class::function-name
library_name
The library or JAR file name without extension.
lang_type
An enumerated value defined in the bmf.h file.
argdefs
The arguments this extension accepts.
validity
An array of strings that stores the ExtensionPoint classes that would be able
to configure this extension
BMOperation
This class stores information about the operations that can be performed on types or
properties. The attributes in this class are:
operation_name
The name of the operation. It is the message name on type or property.
extensionpoints
The ordered list of ExtensionPoint classes associated with this operation.
ExtensionPoint
This class stores information about the hookup point for executing methods. Four
extension points are supported: precondition, preaction, base action (not exposed to
user interface) and postaction. The attributes in this class are:
name
The name of the extension point.
is_overrideable
This value is false for base action. For the other points, this is true.
single_extension_only
This is true for base action
extpnt_type
This is an enumerator with four values.
ext_descriptors
The ordered list of configured extensions with parameters.

ExtensionDescriptor
This class stores information about a specific extension that is assigned to an

extension point with a specific set of parameters to be passed to the extension
invocation. The attributes in this class are:
extn
A reference to an extension.
args
The parameters to be passed to the extension.
condition
The condition under which the specified extension is executed. If this is NULL,
then the extension is always executed.
priority
The value that specifies the extension that should be executed first. If all have
equal priority, they are executed in the order listed in the ExtensionPoint class.
TypeBMOperation
This class stores information about operations specific to types. The attributes in
this class are:
type_name
The name of the type on which the operation or messages are defined.
PropertyBMOperation
This class stores information about operations specific to properties. The attributes
in this class are:
type_name
The name of the type.
prop_name
The name of the property on which the operation is defined.
BusinessRuleDescriptor
This class stores information about versions of a business rule. It is used for tracking
versions of operation. The attributes in this class are:
version
A string value representing a version. This is only used internally.

Chapter
8 Product Structure Management
Bill of Materials (BOM) Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Producing a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Create a BOM Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Defining What to Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Finding Children for a BOM Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Finding an Attribute ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Occurrence Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Editing the BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Packing the BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Sort Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Sample BOM Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Occurrences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Options and Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Option Creation and Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
BOM Variant Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Variant Expression Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Variant Clause List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
BOM Compare Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14

Scope of Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Defining a Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Compare Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
BOM Compare Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
BOM Compare Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Advanced Definition Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Display Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Aggregate Element Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Element Ordering Modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Element Application Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Object Output Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Column Output Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
Nonproperty Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
Advanced Execution Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
Performing a Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
BOM Compare Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
BOM Line Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29
Report Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
BOM Compare Output Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
BOM Compare Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32

Product Structure (PS) Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
Product Structure Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
BOMView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
BOMView Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
Occurrences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Attaching Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Precise/Imprecise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Multiple View Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Multi-Level Product Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Alternates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Class Attributes and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
View Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
Note Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Loading of PS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Adding Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Product Structure Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41

Where Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Relationship to the BOM ITK Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43

Chapter
8 Product Structure Management
This chapter describes the modules that contain product structure management
functionality.
There are two modules associated with managing product structure:

• Bill of Materials (BOM) Module
The BOM module operates at the highest level; below the PSE user interface and
above the PS module. It is oriented toward the presentation of and interaction
with product structure and encompasses the application of configuration rules.
The BOM module is used for general operations, such as creating reports and
editing structure. It pulls together information from items, item revisions,
BOMView revisions and occurrences to present them as entries in a bill of
materials.
• Product Structure (PS) Module

The PS module handles product structure operations at a lower level. It is also
responsible for the creation and manipulation of the basic structure objects (in
other words, BOMViews and occurrences).
This module is most useful for large scale import of structure data into
Teamcenter or batch operation to update specific structure attributes where the
overhead of building up the full presentation of BOM-related information is
not required.
Bill of Materials (BOM) Module

The BOM module is intended to give a consistent interface to the separate elements
that make up a line in a bill of materials. The design assumes that you have a
BOM window (which may be a printed report or a screen window) showing a bill of
materials made up of BOM lines. Each BOM line shows attributes derived from
items, item revision, occurrences and so on; along with some attributes belonging to
the BOM line itself. None of the individual objects the line represents (for example,
is_packed) are shown.
The names of the attributes give a clue as to which object they are derived from; you
can ignore that and treat them all as BOM line attributes. Although some attributes
are standard and listed in the bom_attr.h file, others are defined at runtime (for
example, the note types on occurrences) and have to be found by inquiry.

Chapter 8 Product Structure Management
The BOM module is described in two parts. The first part is for those who want to
produce a report listing a bill of materials. Following this is more detail describing
other functions needed for editing the bill and using more complicated facilities.
Producing a Report
When producing a report, there are certain procedures that you must follow.
Create a BOM Window

The first thing you have to do is create a BOM window with a call to the
BOM_create_window function. The window may need some default settings. For
example, default lines are not packed and the configuration rule is the user’s default
one (if defined); otherwise it is the latest with any status.
To change the configuration rule, you have to ask for the configuration rule
and then use the CFM ITK routines to modify it.
Defining What to Display

Next, call the BOM_set_window_top_line function to say what the window
displays a bill of materials on. This routine takes an item, item revision and BOM
view as arguments, but most of them can be NULLTAGs.
If item revision is non-null, then that particular revision is used. If it is NULLTAG,
then a non-null item must be given and the configuration rule is used to determine
the revision.
If the BOM view is non-null, then it is used. Otherwise, the oldest one is used.
Until multiple views are used, there is never more than one BOM view
in an item.
Finding Children for a BOM Line

Given a BOM line, you can find its children using the BOM_line_ask_child_lines
function. To find attributes of a line, you have to call the
BOM_line_ask_attribute_xxx function, where xxx depends on whether
you are asking about a tag, string, integer, logical or double. Before you can call the
ask_attribute function, however, you need to find the attribute ID for the attribute
you want to ask about.
Finding an Attribute ID
If you know what attribute you want, you can use the BOM_line_look_up_attribute
function to translate its name to an ID. Otherwise, you have to use the
BOM_line_list_attributes function to find all available ones and then work out
which you want.
Attributes themselves have attributes of their own. They have a name, user name,
mode, read-only flag and an internal/external flag. The name is unique and is what
you use to look up an attribute. The user name is not necessarily unique and is
intended as a suitable name to describe the attribute. The mode is a value defined in
the bom_attr.h file and states if the attribute is a string, int, or some other kind.

Product Structure Management
The read-only flag is true if the attribute cannot be changed. For example, assume
that the name attribute is built up from the item ID, revision ID and so on. As such,
the name cannot be changed. To change the name attribute, you have to change
the item ID directly.
Because an attribute is not read-only does not mean you can set that
attribute on any particular line. If the line shows released data, the
set_attribute fails.
The internal/external flag is intended to say whether the attribute was defined
internally (and might be expected to be available the next time you run the program)
or externally (by virtue of reflecting an occurrence note type; so it may not exist in
some other run of the program).
If you are looking for data that is not available as an attribute (for example, a dataset
in the item revision of some BOM line), you can use the tag attributes (item revision
tag, in this case) to find the underlying object. Next, use ITK queries on the object
A simple program displaying all attributes should ignore tag attributes as
being meaningless to display.
Occurrence Sequencing
The single level structure of an item revision is made up of a collection of links from
a BOMView revision (the parent) to the items which are components of the assembly
(the children). These links are known as occurrences.
An occurrence represents the usage of an item or an item revision within the product
structure of a parent. You can distinguish between different kinds of occurrences
in the BOM by referring to occurrence sequencing. For detailed information about
the BOM and product structure (PS) functions, see the Integration Toolkit Function
Reference manual.
Editing the BOM

If you want to edit the bill of materials you can use the BOM_line_cut,
BOM_line_add and BOM_line_substitute functions. Be aware that the latter two
use the same NULLTAG argument options as the BOM_set_window_top_line
function.
The BOM_line_set_precise function implements the option precise user interface
command. You can use the BOM_line_set_attribute_xxx functions to change those
attributes that are not read-only.
If you have edited structure by direct PS ITK calls, you can re-synchronize the BOM
world by calling the BOM_update_pse function. When you have finished your
edits you must call the BOM_save_window function to save any changes made
in that bill of materials.
The BOM_save_window function calls underlying PS routines to save
whatever data the BOM module knows needs saving. It is possible to mix
BOM and PS calls within the same program, but you must ensure that you
call PS to save any change you make that the BOM does not know of.
The other functions do not affect the stored data; they only affect the display (in this
case, the results of the BOM_line_ask_child_lines function).

Packing the BOM

Packing is controlled at the window level by a default flag. If you call the
BOM_line_pack or BOM_line_unpack function on a given line, however, the
results of later calls to ask_child_ lines on its parent change. By default, lines are
packable if they have the same item revisions and the same sequence numbers. By
calling the BOM_set_pack_compare function, you can supply a different compare
function. This function applies session-wide; it is not window-specific.
The interactive PSE assumes that all packed lines show the same sequence
number. If the user changes the sequence number, it sets all of the lines to
that number. If you change this function, PSE might not work correctly.
Sort Functions
The BOM_line_ask_child_lines function lists the lines in some order determined
by a sort function. The default function sorts by sequence number and then by item
name. The BOM_set_window_sort_compare_fn function can be used to change
this function on a per window basis.
Sample BOM Program

Figure 8-1 shows how the BOM ITK can be used.
/* An example program to show a list of a bill of materials using the BOM module
@<DEL>*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unidefs.h>
#include <mem.h>
#include <iman.h>
#include <item.h>
#include <bom.h>
#include <cfm.h>
#include <ps_errors.h>
/* this sequence is very common */

#define CHECK_FAIL if (ifail != 0) { printf ("line %d (ifail %d)\n", __LINE__, ifail);
exit (0);}
static int name_attribute, seqno_attribute, parent_attribute, item_tag_attribute;
static void initialise (void);

static void initialise_attribute (char *name, int *attribute);
static void print_bom (tag_t line, int depth);
static void print_average (tag_t top_line);
static void find_revision_count (tag_t line, int *count, int *total);
static void double_sequence_nos (tag_t line);
static int my_compare_function (tag_t line_1, tag_t line_2, void *client_data);
/*-------------------------------------------------------------------------------*/
/* This program lists the bill under some given item (configuring it by latest+working).
It then doubles all the sequence numbers and re-lists it by descending sequence number
order. It then counts how many lines there are in the bill and the average number of
revisions of the items in that bill.
It never actually modifies the database.
Figure 8-1. Sample BOM Program (Continued)

Run this program by:

<program name> -u<user> -p<password>
*/
extern int ITK_user_main (int argc, char ** argv )

{
int ifail;
char *req_item;
tag_t window, window2, rule, item_tag, top_line;
initialise();
req_item = ITK_ask_cli_argument("-i=");
ifail = BOM_create_window (&window);
CHECK_FAIL;
ifail = CFM_find( "Latest Working", &rule );
CHECK_FAIL;
ifail = BOM_set_window_config_rule( window, rule );
CHECK_FAIL;
ifail = BOM_set_window_pack_all (window, true);
CHECK_FAIL;
ifail = ITEM_find_item (req_item, &item_tag);
CHECK_FAIL;
if (item_tag == null_tag)
{ printf ("ITEM_find_item returns success, but did not find %s\n", req_item);
exit (0);
}
ifail = BOM_set_window_top_line (window, item_tag, null_tag, null_tag, &top_line);
CHECK_FAIL;
print_bom (top_line, 0);
double_sequence_nos (top_line);
/* we will not use
ifail = BOM_save_window (window);
because that would modify the database
*/
/* now let’s list the results sorted the other way */
ifail = BOM_create_window (&window2);

CHECK_FAIL;
ifail = BOM_set_window_config_rule( window2, rule );
CHECK_FAIL;
ifail = BOM_set_window_pack_all (window, false);
/* the default, but let’s be explicit */
CHECK_FAIL;
ifail = BOM_set_window_sort_compare_fn (window2, (void *)my_compare_function, NULL);

CHECK_FAIL;
ifail = BOM_set_window_top_line (window2, item_tag, null_tag, null_tag, &top_line);

CHECK_FAIL;
printf ("================================================\n");
print_bom (top_line, 0);
print_average (top_line);
ITK_exit_module(true);
return 0;
}
/*-------------------------------------------------------------------------------*/

static void print_bom (tag_t line, int depth)

{
int ifail;
char *name, *sequence_no;
int i, n;
tag_t *children;
depth ++;
ifail = BOM_line_ask_attribute_string (line, name_attribute, &name);
CHECK_FAIL;
/* note that I know name is always defined, but sometimes sequence number is unset.
If that happens it returns NULL, not an error.
*/
ifail = BOM_line_ask_attribute_string (line, seqno_attribute, &sequence_no);
CHECK_FAIL;
printf ("%3d", depth);

for (i = 0; i < depth; i++)
printf (" ");
printf ("%-20s %s\n", name, sequence_no == NULL ? "<null>” : sequence_no);
ifail = BOM_line_ask_child_lines (line, &n, &children);

CHECK_FAIL;
for (i = 0; i < n; i++)
print_bom (children[i], depth);
MEM_free (children);
MEM_free (name);
MEM_free (sequence_no);
}
/*-------------------------------------------------------------------------------*/
static void double_sequence_nos (tag_t line)

{
/* just to demonstrate modifying the bill */
int ifail;
char *sequence_no;
int i, n;
tag_t *children;
ifail = BOM_line_ask_attribute_string (line, seqno_attribute, &sequence_no);

CHECK_FAIL;
/* Top bom lines have no sequence number, and others may also not */
if (sequence_no[0] != ’\0’)
{
char buffer[100];
sprintf (buffer, "%d", 2 * atoi (sequence_no));
ifail = BOM_line_set_attribute_string (line, seqno_attribute, buffer);
{
char *child_name;
ifail = BOM_line_ask_attribute_string (line, name_attribute, &child_name);
CHECK_FAIL;
printf ("==> No write access to %s\n", child_name);
MEM_free (child_name);
}
else
{
CHECK_FAIL;
}
MEM_free (sequence_no);
}


CHECK_FAIL;
for (i = 0; i < n; i++)
double_sequence_nos (children[i]);
}
/*-------------------------------------------------------------------------------*/
static void print_average (tag_t top_line)

{
int count = 0, total = 0;
find_revision_count (top_line, &count, &total);
if (count <= 0)
{
printf ("impossible error has happened!\n");
}
else
{
printf ("lines in bill : %d\naverage revisions of each item : %d\n", count, total
/ count);
}
}
/*-------------------------------------------------------------------------------*/
static void find_revision_count (tag_t line, int *count, int *total)

{
/* A function to demonstrate going from BOM tags to other IMAN classes */
/* In this case, we get the Item tag for the BOM line, and then use it for an */
/* ITEM call. For a complete list of standard attributes see bom_attr.h, or */
/* use a BOM_list_attributes call to find all current attributes (new note */
/* types define new attributes) */
int ifail;
tag_t item_tag, *revisions, *children;
int i, n, revision_count;
char* item_id;
ifail = BOM_line_ask_attribute_tag(line, item_tag_attribute, &item_tag );
CHECK_FAIL;
/* the simplest example call I can think of: */
/* count how many revisions of this Item there are */
ifail = ITEM_list_all_revs (item_tag, &revision_count, &revisions);
CHECK_FAIL;
MEM_free (revisions);
(*count)++;
(*total) += revision_count;

CHECK_FAIL;
for (i = 0; i < n; i++)
find_revision_count (children[i], count, total);
}
/*-------------------------------------------------------------------------------*/

static int my_compare_function (tag_t line_1, tag_t line_2, void *client_data)

{
/* returns strcmp style -1/0/+1 according to whether line_1 and line_2 sort <, = or > */
char *seq1, *seq2;
int ifail, result;
ifail = BOM_line_ask_attribute_string (line_1, seqno_attribute, &seq1);
CHECK_FAIL;
ifail = BOM_line_ask_attribute_string (line_2, seqno_attribute, &seq2);
CHECK_FAIL;
if (seq1 == NULL || seq2 == NULL)
result = 0;
else
result = strcmp (seq2, seq1); /* Doing a reverse sort */
/* note: the default sort function compares Item names if the sequence numbers sort
equal but we will not show that here
*/
MEM_free (seq1);
MEM_free (seq2);
return result;
}
/*-------------------------------------------------------------------------------*/
static void initialise (void)

{
int ifail;
/* <kc> exit if autologin() fail */

if ((ifail = ITK_auto_login()) != ITK_ok)
fprintf(stderr,"Login fail !!: Error code = %d \n\n",ifail);
CHECK_FAIL;
/* these tokens come from bom_attr.h */

initialise_attribute (bomAttr_lineName, &name_attribute);
initialise_attribute (bomAttr_occSeqNo, &seqno_attribute);
ifail = BOM_line_look_up_attribute (bomAttr_lineParentTag, &parent_attribute);
CHECK_FAIL;
ifail = BOM_line_look_up_attribute (bomAttr_lineItemTag, &item_tag_attribute);
CHECK_FAIL;
}
/*-------------------------------------------------------------------------------*/
static void initialise_attribute (char *name, int *attribute)

{
int ifail, mode;
ifail = BOM_line_look_up_attribute (name, attribute);

CHECK_FAIL;
ifail = BOM_line_ask_attribute_mode (*attribute, &mode);
CHECK_FAIL;
if (mode != BOM_attribute_mode_string)
{ printf ("Help, attribute %s has mode %d, I want a string\n", name, mode);
exit(0);
}
}
Figure 8-1. Sample BOM Program

Occurrences
An occurrence represents the usage of an item or an item revision within the product
structure of a parent. You can distinguish between different kinds of occurrences in
the BOM and product structure. Refer to Occurrence Sequencing for the BOM and
Product Structures in the Integration Toolkit Function Reference manual.
Options and Variations

The basic concepts behind options and variations are that options are used to
customize the BOM and variant expressions that reference these options at runtime.
• Expressions
Expressions are built as a parse-tree of variant expressions. A collection of these
expressions is held in a variant expression block. The same mechanism is used to
attach variant conditions to an occurrence and attach variant declarations to an
item revision. The restriction is that only appropriate types of expressions may
be attached to each parent. With an occurrence, the variant expression block
may only contain one expression and must be a LOAD-IF type of expression.
With an item revision, many types of expressions may be used to declare an
option, set a value or apply an error check.
• Range of Allowed Values

Each variant expression contains an operator, a left operand and a right operand.
Options are defined to belong to some item, but the range of allowed values is
stored in option revisions. In most cases the bottom of an expression tree is an
option, but the declare operator references an option revision to identify the
range of allowed values current assembly option.
• Restrictions
Options are only enumerated values. Expression trees only evaluate to logical
or integer values.
If you want to print a report showing variant conditions on a BOM or ignore BOM
lines that are not selected by the current option values, use ITK enquiries for BOM
line values rather than trying to evaluate variant expression trees. The ITK routines
documented here are very low-level routines that are intended to be used to create
variant conditions when building a BOM.
Variant operator values are defined in the bom_tokens.h file. The
BOM_variant_op_rhs_is_string value can be added to other operators to allow a
string to be used as the right operand. In most cases the right operand should be an
integer value that is stored as a text string containing decimal digits.

Operators
Table 8-1 lists each variant expression operator, the type of left and right operands
allowed in that expression, and a brief description.
The operator names in the following table are truncated for convenience.
The full name is the operator name in the following table prefixed
with BOM_variant_operator_. For example, declare in the table is
BOM_variant_operator_declare.
Table 8-1. Variant Expression Operators

Left Operand Right Operand
Operator Type Type Description
declare option revision NULLTAG If this option has not yet been
declared for this BOM, then
declare it as this revision.
assy_uses option NULLTAG Not used.
default option expression or Sets the option to the specified
string value unless the option has
already been set. The value
is an integer index into the
allowed range of enumerated
values.
assign option expression or Sets the option to the
string specified value unless it has
been previously set. Returns
an error if the option already
has a different value.
error_if expression string Used to implement error
checks. Reports the string as
an error if expression is true.
if do-expression condition– Evaluates do-expression if
expression condition-expression is true.
This is used to implement
derived values by making the
do-expression set a default
value.
is_equal expression expression Compares the two
expressions. Typically the
first expression is an option
and the second a string in
order to verify that the option
is set to the specified value.

Table 8-1. Variant Expression Operators

Left Operand Right Operand
Operator Type Type Description
not_equal expression expression Compares the two
expressions. Typically the
first expression is an option
and the second a string in
order to verify that the option
is not set to the specified
value.
and expression expression Evaluates the logical AND of
the two expressions.
or expression expression Evaluates the logical OR of
the two expressions.
load_if NULLTAG expression The top operator of the
expression in a variant
condition attached to an
occurrence.
comment NULLTAG string Not used.
rule_set option expression or Used by variant rule objects
string to store option-value pairs.
This should not be used in
any other context.
brackets NULLTAG expression Placeholder for marking
sub-expressions which
the user would like to be
bracketed. This operator has
no effect on the evaluation
of the overall expression, it
is only used when displaying
the expression in text form.

Runtime Options
Once the assembly has been built to include variations data, option values can be
used to determine what parts of the assembly to display at runtime. Options can
be listed and set from a specified window using the BOM_window_ask_options
and BOM_window_set_option_value functions, respectively. If the desired option
is known, but it is not known whether it has been previously referenced, use the
BOM_window_find_option function instead of the BOM_window_ask_options
function. Figure 8-2 shows an example of listing and setting option values:
#include <string.h>
#include <iman.h>
#include <bom.h>
void panic();
void error(const char* message);
void set_option(tag_t w, const char *option, const char *value)

{
/* Sets an option to the specified value in PSE window w. */
tag_t *options, *option_revs;
tag_t found_option, found_option_rev;
int *indexes;
int i, n;
if (BOM_window_ask_options(w, &n, &options, &option_revs) != ITK_ok) panic();
for (i = 0; i < n; i++)
{
char *name, *description;
tag_t owning_item;
logical found;
if (BOM_ask_option_data(options[i], &owning_item, &name, &description)!= ITK_ok)
panic();
found = (strcmp(name, option) == 0);
MEM_free(name);
MEM_free(description);
if (found) break;
}
if (i == n) error("option not used in this window");
found_option = options[i];
found_option_rev = option_revs[i];
MEM_free(options);
MEM_free(option_revs);
if (BOM_list_option_rev_values(found_option_rev, &n, &indexes) != ITK_ok) panic();
for (i = 0; i < n; i++)
{
char *opt_value;
logical found;
if (BOM_ask_option_rev_value(found_option_rev, indexes[i], &opt_value)!= ITK_ok)
panic();
found = (strcmp(opt_value, value) == 0);
MEM_free(opt_value);
if (found) break;
}
if (i == n) error("option not allowed to have that value");
/* now do the work */
if (BOM_window_set_option_value(w, found_option, indexes[i]) != ITK_ok) panic();
MEM_free(indexes);
}
Figure 8-2. Runtime Options

Option Creation and Declaration
When creating a new option with the BOM_create_optionfunction, it is necessary

to declare the option revision against an item revision. You can both create and
declare an option with a single call to the BOM_new_option function. To declare
an existing option against a different item revision, call the BOM_declare_option
function.
BOM Variant Rule
The BOM variant rule is a runtime object that represents the list of options and
their values in a BOM window. In general, you can ignore this object and use the
BOM_window_ variant functions to get and set option values.
However, this object is for creating multiple BOM variant rules against a BOM
window; although only one is actually applied to the BOM window at any one time.
This can be used to set multiple option values without reconfiguring the entire BOM
after each set operation, although option defaults and rule checks are still triggered.
Then, once all options have been set, the BOM variant rule can be applied to the
BOM window.
The BOM variant rule supports an ITK interface that is almost identical to the
BOM window variant functions for getting and setting options and their values.
A BOM window’s current BOM variant rule can be obtained by a call to the
BOM_window_ask_variant_rule function.
Variant Expression Manipulation

In an attempt to simplify Variant Expression interaction at the ITK level, some
high-level concepts have been introduced. A Variant Clause List can be used to
create and edit conditional variant expressions (for example, Engine = 1.6 AND
Gearbox = manual). These conditional expressions can then be used to create
IF type Variant Expressions (for derived defaults, rule checks, and occurrence
configuration) using the simple BOM_variant_expr_ ITK calls.
Variant Clause List
Variant clause lists are used to store conditional variant expressions in a more easily
understood (and edited) format. For example, the condition:
"Engine = 1.6 OR Engine = 1.8 AND Gearbox = manual"
would be represented in a clause list as:

"Engine = 1.6"
"OR Engine = 1.8"
"AND Gearbox = manual"

In other words, each clause is a simple condition and a join operator (AND or OR).
Clauses may be added (anywhere in the list), deleted, moved, or queried. Individual
clauses within the list are identified by their position. The first clause is at position
0, the second at position 1, and so on.
Brackets are supported by variant clause lists. To add brackets around a section of a
clause list, call the BOM_variant_clause_toggle_brackets function and pass it
the array of clause positions to be contained within the brackets. For example, to
place brackets around the Engine = 1.8 AND Gearbox = manual section of the
previous example, pass in an array containing the positions 1 and 2.
To add brackets around a clause list section that contains more than two
clauses, pass in the positions of the first and last clauses in the section. The
other positions are ignored. The array mechanism is used, in preference to
only supplying first and last position arguments, to simplify user interface
implementations by allowing you to simply pass in the list of currently
selected clauses, rather than expecting you to filter the selection list down
to just the first and last.
BOM Compare Functions

BOM Compare provides a powerful method of comparing different BOMs, BOM
revisions, and configurations of BOMs.
Scope of Compare
BOM Compare operates on the contents of two BOM windows. This means that it
picks up the configuration rules of the BOM windows from which the compared BOM
lines were taken. If you want to compare different configurations of the same BOM,
first set up two BOM windows with the required configurations.
By default, the BOM_compare function compares everything below the supplied
BOM lines right down to the bottom of the BOM. It automatically loads any required
structures.
If a you want to prevent a compare from loading the components of a
specific structure, set the stop flag of the structure’s BOM line, using the
BOM_line_set_stop function. The stop flag can be cleared using the
BOM_line_clear_stop function. In PSE-based compares, the stop flags are set on
all visible leaf nodes and collapsed structure nodes.

Defining a Compare
A BOM Compare is defined by two components:
• Compare descriptor
• BOM Compare mode
Compare Descriptor
The compare descriptor is a list of attributes (referred to as compare elements to

differentiate them from POM attributes) that are used as the basis of the compare.
Although most compare elements are simply be properties (and are handled
automatically by the compare engine), you can compare based on nonproperty
elements by defining methods. You can also use methods to customize the compare
behavior for awkward properties (for example, quantity, which is described later in
this section).
Compare elements can be generally divided into two distinct groups: primary
elements and aggregate elements (there’s a third group: display elements, which is
described later in this section). The key difference between these two groups is that
primary elements define different entities, while aggregate elements are combined
for multiple instances of the same entity. For example, the compare functionality
before version 8 (when expressed in version 8 terms) defined "item id" as a primary
element, and "quantity" as an aggregate element. This meant that BOM lines
that had the same item id were bundled together for the purposes of compare and
their quantities were added together. In other words, 1 BOMLine with qty 2 was
equivalent to 2 BOMLines with qty 1.
In figure 8-3 below, the compare descriptor uses the bl_occurrence (occurrence
thread tag) property, the bl_item property, the bl_quantity property, and the
Torque (an occurrence note) property.
BOM Compare Mode
The BOM Compare mode is a uniquely named object that combines a compare
descriptor and a BOM traversal order. The BOM traversal order defines which
BOM lines are fed into the compare engine, and in what order. The BOM Compare
supports three traversals: single level, multilevel, and lowest level. A single
descriptor can be shared between multiple compare modes.
Figure 8-3 shows a single level compare which is best suited for an occurrence-based
compare.

int define_compare_mode()
{
int ifail;
tag_t desc;
ifail = CMP_find_desc("example desc", &desc);
return ifail;
if (desc == NULLTAG)
{
ifail = define_compare_desc(&desc);
return ifail;
}
ifail = BOM_compare_define_mode(
"example mode",
BOM_compare_singlelevel, /* from bom_tokens.h */
desc, /* from above */
false, /* not shown UI - irrelevant*/
false, /* no autopack - only multi-level needs this */
true /* virtual unpack - copes with packed bomlines */
/* All occurrence-based compares need this */
);
{
/* If it was previously defined, return success */
if (ifail == BOM_duplicate_bom_compare_mode)
{
EMH_clear_errors();
return ITK_ok;
}
/* otherwise report failure */
return ifail;
}
return ITK_ok;
}
int define_compare_desc(tag_t *desc)

{
tag_t new_desc;
tag_t new_element;
tag_t bomline_type;
/* Insert error handling here */
CMP_create_desc("example desc", &new_desc);
IMANTYPE_find_type("BOMLine", NULL, &bomline_type);
/***** Primary Element : Occurrence Thread *****/
Figure 8-3. Single Level Compare (Continued)

CMP_create_prop_element(
new_desc,
CMP_primary_element,
CMP_cache_sync, /* Cache property values in native type */
NULL, /* Do not define element name - will default to prop name */
false, /* Show value of this property in output */
bomline_type, /* Type to which prop belongs */
"bl_occurrence", /* Name of property */
NULL, /* No display prop - use real prop instead */
&new_element);
/***** Aggregate Element : Item *****/
CMP_create_prop_element(new_desc,
CMP_aggregate_element,
CMP_cache_sync,
NULL,
false,
bomline_type,
"bl_item",
"bl_item_item_id",
&new_element);
/***** Aggregate Element : Quantity *****/
compareCacheSync,
"k_compare_qty",
false,
bomline_type,
"bl_quantity",
NULL,
&new_element);
/***** Aggregate Element : Torque Occ Note *****/
CMP_cache_sync,
NULL,
false,
bomline_type,
"Torque",
NULL,
&new_element);
*desc = new_desc;
return ITK_ok;
}
Figure 8-3. Single Level Compare

For simple examples, defining a compare mode is relatively easy. You create your
descriptor and create a number of property elements against it. Then define your
mode, combining the descriptor with a traversal mode.

There are a number of features that are described as follows:

• UI Suppression
In the call to the BOM_compare_define_mode function, the fourth argument
is the mode UI display flag. This controls whether the UI should present this
compare mode in the PSE BOM Compare dialog window. This is a legacy setting
and is now irrelevant because even if this was set to true, the UI still would not
show this mode in the dialog window. The UI dialog window is currently hard
coded to our standard pre-version 8 compare modes.
• Auto Pack
In the call to the BOM_compare_define_mode function, the fifth argument
defines whether multi-level compares should pack BOM lines as it goes along.
Auto pack is an attempt to allow the simplification of the presentation of the
results of multi-level compares where the primary compare elements match the
pack rule attributes. By default, the BOM line pack attributes are item ID and
sequence number. These are the primary attributes for the standard multi-level
compare as currently supported by the PSE compare dialog window.
If you set this argument, set it to false.
• Virtual Unpack
In the call to the BOM_compare_define_mode function, the sixth argument
defines whether BOM lines should be temporarily unpacked during the compare.
If you are using bl_occurrence as one of your compare elements, set this flag to
true because packed BOM lines represent multiple occurrences. To gain access
to the individual occurrences, the compare must unpack the BOM line, pull out
the required data, and then repack, which is transparent to the end user. Why
is not this always switched on? The main limitation of virtual pack lies in the
BOM line property compare output. Normally, BOM compare sets a BOM line
property called Changes to display the actual changes that have happened to
the BOM line (for example, Qty 2->3 or Rev A->B). If you are performing an
occurrence-based compare, you might have two occurrences behind a packed
BOM line. One occurrence might have a change (for example, Qty 2->3). The
other occurrence might not have any change. In this situation, what should
compare put in the Changes property of the BOMLine? Should it say Qty 2->3?
Should it be empty? In reality, it says PACKED CHANGES, and expects the
user to manually unpack the BOM line to see to individual changes.
For non-UI compares, UGS recommends that the BOM windows being compared
have packing switched off.

• Caching
In the calls to the CMP_create_prop_element function, the third argument
tells BOM Compare whether and how to cache property values. The
CMP_cache_sync setting means that the type of the cache should be
synchronized to the property value type. Setting this to CMP_cache_none
would disable caching of that property. The CMP_cache_auto setting is similar
to CMP_cache_sync, but allows BOM Compare to make the final decision on the
cache type. This is important if you plan to use certain properties as aggregate
elements. For example, multiple tag elements cannot be aggregated into a tag
cache. Instead, they need a tag array cache type. The CMP_cache_auto setting
makes that decision for you. You can also manually specify the type of the cache,
but it is up to you to make sure that it is suitable for storing the property.
• Element Naming
In the calls to the CMP_create_prop_element function, the fourth argument
allows a user to specify the (internationalized) name by which this element is
known. If this is set to NULL, then the property name is used. Element naming
is primarily used for non-property compare elements, but can still be useful for
property elements where the property name is considered to be too verbose
for display in compare output. For example, with the bl_quantity property
you might want compare to output the more compact Qty rather than property
display name Quantity.
• Element Display Suppression

In the calls to the CMP_create_prop_element function, the fifth argument
allows for the possibility that certain elements are useful for comparing, but not
good for displaying. For example, tag elements are great for comparing, but
because they are simply unsigned integers they have no meaning to end users.
This ties into display elements.
• Element Display Aliasing

In the calls to the CMP_create_prop_element function, the eighth argument
provides a simplified version of the display elements concept. It allows an
unfriendly property to be replaced in the output stage with a more readable one.
In the example above, we used the bl_item property. This property is the tag of
the item. When displaying item changes to the user, you do not want to show
them item tags. Instead you would want to show them the item ID. To do this, we
could define bl_item_item_id as a display alias property of the bl_item property
element. Note that while you could use bl_item_item_id as your compare
element, the use of bl_item is much more efficient for two reasons: it is an
integer compare rather than a string compare, and bl_item is a directly defined
BOM line property while bl_item_item_id is indirected through the item.

BOM Compare Execution

Figure 8-4 shows the code for a simple compare report:
tag_t compare;
int n_lines;
char **lines;
tag_t *cmp_items;
int i;
BOM_compare_create(&compare);
BOM_compare_execute(compare,
bomline1, bomline2,
"example mode",
BOM_compare_output_report);
BOM_compare_report(compare, &n_lines, &lines, &cmp_items);
for (i=0; i<n_lines; i++)
{
printf("%s\n", lines[i]);
/*
** BOMLines relating to this report line can be obtained via
** BOM_compare_list_bomlines(cmp_items[i], ...);
*/
}
AOM_delete(compare);
Figure 8-4. Compare Report Code

If you want the changes written to the BOM line Changes property,
just add the BOM_compare_output_bomline argument to
the BOM_compare_output_report argument in the call to the
BOM_compare_execute function.
Advanced Definition Concepts

The following are advanced definition concepts that you should understand.
Display Elements
In addition to primary and aggregate elements, BOM Compare can also support
display elements. These are elements that have no impact on the actual comparison.
Display elements are extra context data that is written as part of compare output.
This is just an advanced version of the element display aliasing concept described
earlier. Aliasing is limited in that it only works with property elements, and only
a single alias property can be defined. Display elements can be defined with
methods, allowing non-property data to be used. You can also define as many display
properties as you want.

The Element Display Aliasing section describes using bl_item_item_id as a display

alias for bl_item. If you want to display the item name as well as the item ID, define
a property display element for the bl_item_object_name property in the descriptor,
as shown in figure 8-5:
CMP_display_element,
CMP_cache_sync,
NULL,
false,
bomline_type,
"bl_item_object_name",
NULL,
&new_element);
Figure 8-5. Property Display Element Definition

Note that display elements are not aggregated. Teamcenter assumes that the
display element property value is constant across all BOM lines in a set. As such,
the display element value is simply pulled out of the first BOM line that the compare
engine finds.
Aggregate Element Uniqueness
With numeric elements, aggregation is easy: the numbers are just added together.
However, with string elements, aggregation is more difficult. The standard behavior
is simply to concatenate the strings into a comma separated list, in alphabetical
order. For example, A and B becomes A,B. If you aggregate A and A, it enforces
uniqueness (A + A = A).
Element Ordering Modifier
Generally, string elements are sorted by simple alphabetic order. For example,
aardvark comes before albatross. However, you might want to store numeric
data in string attributes (for example, sequence number). In this case, alphabetic
order is not correct. For example, 20 comes before 3. To correct this, use the
CMP_set_prop_element_order function to set the element sort order to the
CMP_order_by_length_and_value setting.

Element Application Flags

The generic compare engine has no understanding of application concepts (BOM
Compare is an application built on top of the generic compare engine). However,
sometimes it is necessary for the application to store modifiers on the compare
descriptor. This is done using the application flags. Application flags are set by the
CMP_set_element_application_flag function. There are three application flags:
• BOM_compare_display_aggregate
• BOM_compare_stop_if_diff
• BOM_compare_dont_report_adds
These are defined and documented in the bom_tokens.h file.
Object Output Order

If you have multiple primary elements, the order in which you define the elements
has an impact on the order in which objects are output in a report. Consider a
compare where you have two primary elements: Item Id and Sequence Number.
Note that these are the primary elements for two of the standard compare modes. If
you define the Item Id element before the Sequence Number element, then objects
are output sorted by Item Id and then by Sequence Number within that.
Consider three BOM lines with the following attributes:
• item=widgetY, seqno=10
• item=widgetX, seqno=20
If you define your elements in the order (Item Id, Seq No), compare outputs the
lines in the order 2, 3, 1. This order is clearly not ideal. You normally would really
like the output to be in the same order in which it appears in PSE (in other words,
1, 2, then 3). To do this, simply reverse the order of element definition to be (Seq
No, Item Id). However, this affects the column output order, described in the
next section.
The use of sequence numbers introduces another feature. Consider this pair of
BOM lines:
The order output should be 1 first and 2 second. Because sequence numbers are
strings and not integers, a string compare is performed and alphabetically 100 comes
before 20. To get around this, mark the sequence number element (and any others
that store numbers as strings) as special with the CMP_set_prop_element_order
function.
CMP_create_prop_element(new_desc, ..., &seqno_element);
CMP_set_prop_element_order(seqno_element, CMP_order_by_length_and_value);
This call tells the compare engine to sort by length, before sorting by value.

Column Output Order
By default, report output is generated with the columns in the same order as the
elements were defined in. In the previous section we defined the Sequence Number
element ahead of the Item Id element to force the object output order to match the
PSE display order. The side effect of this is that the report columns are output in the
(Seq No, Item Id) order. This does not match the standard PSE column display
order where you expect to have the item defined in the leftmost column, followed by
the sequence number. You can suppress the display of the sequence number element
and define a display element against the sequence number property. However, the
better alternative is to define a display order. To do so, create a tag array and
populate it with the element tags in the order that you want the columns to appear.
Then pass that array into the CMP_set_element_display_order function as
shown in figure 8-6.
tag_t seqno_element;
tag_t itemid_element;
tag_t elements[2];
CMP_create_prop_element(new_desc, ..., &seqno_element);
CMP_create_prop_element(new_desc, ..., &itemid_element);
elements[0] = itemid_element;
elements[1] = seqno_element;
CMP_set_element_display_order(new_desc, 2, elements);
Figure 8-6. Display Order Definition
Methods
When using property-based compare elements, the system provides default behavior
for comparing the property values. There are also some simple modifiers that can be
applied to handle certain special cases. If none of the modifiers do what you need,
you can write code that does exactly what you want and then register it against
the element.
There are six method types supported by the generic compare engine:
• Compare Object
This method must compare a given object against a given compare set and return
its opinion on whether that object belongs in that set. Note that this is just one
primary compare element’s opinion. Other primary elements may disagree. All
primary elements must say yes for the object to be allowed into the set.
• Compare Aggregate
This method must compare the left and right sides of the given compare set and
return its opinion on whether the two sides are equivalent. Other aggregate
elements may disagree.
• Cache
This method must update the element’s cache when the supplied object is added
to the given side of the compare set.

• UIF Name
This method returns the display name for this element.
• UIF Value
This method returns the display value for this element.
• Free Cache
One of the supported cache types is CMP_cache_pointer. This cache type
means that the user is taking responsibility for creating and managing the
cache. The generic compare engine simply maintains a void * pointer to the
cache. When using this cache type, you must supply a Cache method (to create
and update the cache), a UIF Value method (to return the display value for the
cache), and a Free Cache method. This Free Cache method is used to release
the memory allocated by the Cache method.
Nonproperty Elements
This is the logical conclusion of the use of compare methods. A non-property element
is an element that is entirely driven through methods. It has no standard behavior.
This requires more effort, but allows maximum flexibility. For example, you could
perform a compare using elements that live entirely outside Teamcenter. It could
pull in data from a different database or from the Internet, which may take a
significant amount of time. If you plan to do this, UGS highly recommends caching.
For an example of a non-property element, see the quantity elements in the
smp_user_bom_cmp.c file. While quantity is a BOM line property, Compare cannot
handle it directly because of the need to cope with special concepts like as required
and undefined (PSE’s default quantity, in other words, one unit).

Advanced Execution Concepts

One of the advantages of the generic compare engine is that it provides access to
the internal data structures of the engine. This allows you to provide new output
destinations and formats directly off the raw data without having to post-process one
of the existing outputs. To use this, you must understand the internal data structure.
The top level object is the BOM Compare itself. This is the object that most of the
BOM Compare ITK deals with. A BOM Compare is described as having a mode, an
output destination, and two root BOM lines (often referred to as two sides of the
compare, left and right).
In single and lowest-level compare traversals, the BOM Compare object has a single
BOM Compare engine object. In multi-level compare traversals, the BOM Compare
has a tree of nested BOM Compare engines.
A BOM Compare engine contains a list of compare sets. Each compare set contains
two lists of BOM lines (one list for each side of the compare). Every BOM line in
a compare set has the same values for their primary elements. Compare sets are
capable of caching compared values. Primary and display elements are stored in a
single cache (per element) on the compare set. Aggregate elements require a cache
for each side of the compare.
To traverse this data structure, use the BOM_compare_visit_engine function, as
shown in figure 8-7. This function traverses the internal data structure invoking
callbacks as it goes.
{
tag_t compare;
BOM_compare_create(&compare);
BOM_compare_execute(compare,
bomline1, bomline2,
"example mode",
0 /* No output - we’re going to do it ourselves */ );
BOM_compare_visit_engine(compare,
enter_engine,
leave_engine,
visit_set,
NULL /* User data pointer */ );
}
Figure 8-7. Traversing Example (Continued)

int enter_engine(tag_t bomcompareengine, tag_t compareset, int depth,

void *user_data)
{
tag_t root1, root2;
BOM_compare_ask_engine_root_bomlines(bomcompareengine, &root1, &root2);
printf("Entering compare engine %x, comparing BOMs %x and %x\n",
bomcompareengine, root1, root2);
/* You could use the CMP ITK to query the contents of the engine */
return ITK_ok;
}
int leave_engine(tag_t bomcompareengine, tag_t compareset, int depth,

void *user_data)
{
printf("Leaving compare engine %x\n", bomcompareengine);
/* You could use the CMP ITK to query the contents of the engine */
return ITK_ok;
}
int visit_set(tag_t compareset, int depth, void *user_data)

{
/* You can use the CMP ITK to query the contents of the set */
printf("Compare set %x\n", compareset);
/* List which compare elements changed in this set */
int n;
tag_t *elements;
tag_t *bomlines;
int i;
CMP_ask_diff_elements(compareset, &n, &elements);
printf("Changed elements: ");
for (i=0; i<n; i++)
{
int element_type,
int priority,
int cache_type,
char *uif_name,
logical suppress_value;
char *lvalue;
char *rvalue;
CMP_ask_element_info(elements[i],
&element_type, &priority, &cache_type,
&uif_name, &suppress_value);
CMP_ask_element_value(compareset, CMP_LHS, elements[i], &lvalue);
CMP_ask_element_value(compareset, CMP_LHS, elements[i], &rvalue);
print(" %s has changed from %s to %s\n", uif_name, lvalue, rvalue);
SM_free(uif_name);
SM_free(lvalue);
SM_free(rvalue);
}
SM_free(elements);
Figure 8-7. Traversing Example (Continued)

/* List the bomlines on LHS of this set */
CMP_ask_objects_in_set(compareset, CMP_LHS, &n, &bomlines);

printf(" Affected BOMLines on left hand side: ");
for (i=0; i<n; i++)
{
printf("%x ", bomlines[i]);
}
printf("\n");
SM_free(bomlines);
return ITK_ok;
}
Figure 8-7. Traversing Example
Performing a Compare
The BOM Compare function BOM_compare_execute supersedes the older
BOM_compare call. The BOM_compare_execute function takes the tags of the
two BOM lines to be compared, along with the compare mode, and the output type,
and may optionally be given a compare context.
A compare context (gained from the BOM_compare_create function) is a slot into
which the results of a BOM Compare are put. Each one can only hold the results of
one compare. The BOM_compare_execute function can be told to use the default
compare context by passing in a null tag.
The default compare context is the one used by the user interface when running
BOM Compare from PSE. If you use the default context while the user interface
might be using it, you clear any BOM Compare-related BOM line highlighting and
the ability to click on a report line and have the PSE select the correlate BOM lines.
Merely using the default context causes this, even if you do not ask for BOM line
highlighting or text reports.
The standard mode names (BOM_std_compare_*_name) are available
as manifest constants from the bom_tokens.h file; the output selectors
(BOM_compare_output_*) are also available from the bom_tokens.h file. These
identifiers are used thus:
BOM_compare_execute( bomcomparecontext,
bomline1,
bomline2,
BOM_std_compare_single_level_name,
BOM_compare_output_bomline | BOM_compare_output_report );
For your own modes, you should establish and use your own manifest constants. The
standard compare modes are described in Product Structure Editor Help, but you
can also declare new ones using the BOM_compare_define_mode function. To
define your own modes, you need to understand compare descriptors, which are part
of the generic compare engine.
The generic compare engine provides a way to compare two sets of objects, and
obtain the differences between the sets. Each set is divided into subsets containing
objects that match each other according to some user-defined criteria (primary keys).
If both sets each have a subset whose objects match by their primary keys, then the
objects within each subset are compared according to further user-defined criteria
(aggregate keys), and the results for this second compare between each correlate
pair of subsets are made available. A subset with no correlate subset is an addition
(or a deletion). The keys are specified with a compare descriptor.

For example, the functionality of BOM Compare has been re-implemented on top of
this generic engine. The two sets are the two sets of BOM lines for comparison; the
BOM lines are gathered into subsets according to item ID and optionally sequence
number, the primary keys, and where both sides of the compare has correlate
subsets, they are compared for quantity and revisions, the aggregate keys.
BOM Compare Output

There are four forms of compare output available. The three original modes
are: user exits, BOM line, and report output. One is based on callbacks: the
BOM_compare_visit_engine fucntion.
User Exits
BOM Compare can call a number of user exit functions for both ITK- and PSE
window-invoked compares. The user exits are:
• USER_bom_cmp_start_report
• USER_bom_cmp_enter_report
• USER_bom_cmp_item_report
• USER_bom_cmp_parent_report
• USER_bom_cmp_exit_report
• USER_bom_cmp_end_report
These user exit functions are always called by the PSE window-invoked compare.
User exit output is optional for the ITK compare.
A number of ITK functions are available to allow the user exit functions to query
the compare results:
• BOM_compare_list_bomlines
• BOM_compare_ask_differences
• BOM_compare_ask_qty
• BOM_compare_ask_rev
• BOM_compare_ask_seqno
This list of functions has been augmented by the generic compare functions that can
be applied to compare engines.

BOM Line Output
The following BOM line string property is set to contain the changes relating to
the particular BOM line:
bl_compare_change
The following two properties are additionally supported when the

BOM_compare_legacy_properties preference is true:
bl_quantity_change
bl_revision_change
If no differences are found for a particular BOM line, these properties are all blank.
If the BOM_compare_legacy_properties preference is false or unset:
• bl_compare_change
Contains the type of change for this line, either Added or one or more of the
Aggregate keys and key values for the BOM Compare Mode specified. For the
standard compare modes, the keys are Qty or Rev for quantity changes and
revision changes, respectively, so this property might look like, Qty:1→2 or
Rev:A→B. This is a comma-separated list if more than one change occurs (for
example, both quantity and revision changes might look like Qty:1→2,Rev:A→B).
If the BOM_compare_legacy_properties preference is true:

• bl_compare_change
Contains the type of change, Added, Qty, or Rev for additions, quantity changes
and revision changes, respectively. This is a comma-separated list if more than
one change occurs (for example, both quantity and revision changes might look
like, Qty,Rev).
• bl_quantity_change
Contains details of a quantity change (in other words, if Qty is a sub-string of
the bl_compare_change attribute). The change is stored as the two quantities
separated by an arrow (for example, 1→2).
• bl_revision_change
Contains details of the revision change (in other words, if Rev is a sub-string of
the bl_compare_change attribute). The change is stored as the two revisions
separated by an arrow (for example, A→B). If more than one revision of an item
exists in one of the BOMs then all the revisions are listed (for example, A,B→C).
These properties may be cleared by calling the BOM_compare_clear function.

If another compare is started (in a particular compare context) before the
previous one has been cleared, the old properties are automatically cleared.

Report Output
Report output can be retrieved with the BOM_compare_report function. Note that
you must request report output when you call the BOM_compare_report function,
otherwise no report is generated.
The BOM_compare_report function returns the report as an array of formatted
chararacter strings. The first string contains the column headers for the report. The
function also returns an array of compare items that match the report lines. These
compare items can be queried with the following functions:
• BOM_compare_list_bomlines
• BOM_compare_ask_differences
These functions have been augmented by the generic compare functions, as for
the user exits.
These functions are only available if the BOM_compare_legacy_report preference
is true:
• BOM_compare_ask_qty
• BOM_compare_ask_rev
Report lines that do not have matching compare items (for example, the column
header line) have their compare item listed as NULLTAG.

BOM Compare Output Suppression

BOM Compare output suppression allows the BOM Compare user exit functions
to switch off certain forms of compare output. For example, the default user exit
functions do not perform any useful actions. To prevent the PSE window-based
compare from calling unnecessary user exit functions, the very first user exit
function (USER_bom_cmp_start_report) suppresses all other user exit output,
using the following line of code:
BOM_compare_suppress (line1, BOM_compare_output_userexit);
This suppression lasts for the duration of the current compare. The primary
intended use for this facility is if you wish to replace the BOM Compare’s internal
report window with your own report. To achieve this, you must write the user exit
functions to generate the report and display it in a window.
Once the report generation code has been written, the problem is how to control
which report window is displayed and when. You must first suppress the user exits
when report output was not selected in the BOM Compare dialog window:
If:
( (output & BOM_compare_output_report) == 0)
{
BOM_compare_suppress (line1, BOM_compare_output_userexit );
return ITK_ok;
}
You should now suppress the internal report window:

BOM_compare_suppress ( line1, BOM_compare_output_report );
There are many other potential uses for output suppression. Some further examples
are given in the USER_bom_cmp_start_report user exit source code.

BOM Compare Visitor
After you run a compare (possibly without any output modes specified), you can ask
the system to walk the results tree, running user-supplied callbacks at each node.
This is very similar to the user exits system above, but because you pass in the three
callback functions instead of linking them into the user exits library, you can process
the results in various ways without needing to change the user exits library. The
callbacks have this correlation with the user exits:
• The visit_set function is identical to the USER_bom_cmp_item_report
function, except that it has the extra user_data parameter - a void * parameter
supplied by your call to the BOM_compare_visit_engine function, pointing to
a structure you want your callbacks to build or maintain.
• The enter_engine function is analogous to USER_bom_cmp_parent_report

function. Figure 8-8 makes that relationship explicit:
#include <iman.h>
#include <bom.h>
int enter_engine( tag_t compare_engine, tag_t compare_set, int depth, void * user_data)
{
int itk_ret;
tag_t bomline1;
tag_t bomline2;
if ( ( itk_ret = BOM_compare_ask_engine_root_bomlines( compare_engine, &bomline1,
&bomline2) ) != ITK_ok )
return itk_ret;
return USER_bom_cmp_parent_report( bomline1, depth );
}
Figure 8-8. BOM Compare Visitor 1

• The leave_engine routine is called when all descendants of the latest active
parent announced through the enter_engine function have been visited. All
ordering is depth-first recursive, so each parent node is only reported once
immediately before all of its descendants, and once immediately after all of its
descendants. Figure 8-9 counts the number of BOM lines (on the left or right
hand side) determined to be different by the compare:
/* Count BOM Lines in a compare, declares

extern int count_bomlines_in_compare ( tag_t compare_context, int cmp_side );
*/
#include <bom.h>
#include <cmp.h>
#include <iman.h>
/* Structure for passing nominated side and current count around */

typedef struct
{
int count;
int side;
} count_bomlines_t;
/* Callback to add the number of objects for each set to user_data-count. */

/* Note, it would be trivial to put a loop in here to examine/modify
the BOM Lines in bomlines[], instead of merely counting them */
static int count_bomlines_visit_set ( tag_t compareset, int depth, void * user_data )
{
count_bomlines_t *data = (count_bomlines_t*) user_data;
int count;
tag_t *bomlines;
{
/* Ask compareset for the bomlines on the nominated side. (I’m
only interested in how many there are, not what they are.) */
int itk_ret;
if ( ( itk_ret = CMP_ask_objects_in_set( compareset, data->side, &count,
&bomlines ) ) != ITK_ok )
return itk_ret;
}
data->count += count;
MEM_free( bomlines );
return ITK_ok;
}
/* Run over the BOM compare results passed in, and return the number of
BOM lines, or -1 on error. */
extern int count_bomlines_in_compare ( tag_t compare_context, int cmp_side )
{
count_bomlines_t results = { 0, cmp_side };
/* Use NULL for parent (engine) entry/exit callbacks, because
they’re not interesting here */
if ( BOM_compare_visit_engine( compare_context, NULL, NULL, count_bomlines_visit_set,
(void*) &results ) != ITK_ok )
{
return -1;
}
return results.count;
}
Figure 8-9. BOM Compare Visitor 2

Product Structure (PS) Module

The Product Structure (PS) ITK module manages the creation, manipulation and
storage of product structure data within Teamcenter.
Product structure in Teamcenter is represented by assembly items containing
links to component items which make up the assembly. The structure of items is
represented in BOMView objects. The links to component items are known as
occurrences.
The PS ITK module covers the creation of BOMViews and BOMView revisions for
items and item revisions, the creation and modification of occurrences to reference
the component parts of an assembly, and the attachment of structure-related
attributes to occurrences.
Product Structure Classes

The PS module works with the following classes of objects:
• BOMView
• BOMView revision
• Occurrence
• View type
• Note type
Each has associated attributes and methods specific to their class.
BOMView
When an item is an assembly of other items, its assembly structure is represented

by a BOMView. A BOMView is a workspace object. It is an object distinct from the
item in order to support multiple views functionality, when a separate BOMView is
required to represent each different view of an item’s structure.
The class attributes and methods for BOMView in the PS module are shown in
the figure 8-10:
Figure 8-10. BOMView Class Attributes and Methods

In the figure:
• Item is the item to which this BOMView belongs, inquired by the
PS_ask_item_of_bom_view function.
• BOMView revisions are all of the revisions of this BOMView. They can be listed
using the PS_list_bvrs_of_bom_view function.
• ViewType specifies the type of this BOMView with the tag of a View Type
object. Use the PS_ask/set_bom_view_type functions to inquire or modify
its value, respectively.
• BOMView also inherits name and description from the workspace object, which
can be inquired and changed using the appropriate WSOM functions.
A BOMView is created by the PS_create_bom_view function. The name of the
BOMView must be unique for all BOMViews of the parent item. Be aware that no
initial revision is created, this is done by a call to the PS_create_bvr function.
A new or modified BOMView is not saved to the database until you
make a call to the AOM_save function. The item it is placed in is also
modified and must also be saved with a separate call to AOM_save.
BOMView Revision
The structure of an assembly item may change between successive revisions of the
item. Therefore the actual structure information of an item revision is stored in a
BOMView revision referenced by that item revision. A revision of BOMView "A"
must specify the structure of a revision of the item that owns BOMView "A".
There is no one-to-one correspondence between item revisions and BOMView
revisions, because where two or more revisions of an item have the same structure
they may share references to the same BOMView revision. A new working item
revision based on a previous released revision retains a reference to the released
revision’s BOMView revision until such time as the structure of the working item
revision needs to be modified. An item revision may reference only one revision of
a BOMView at a time.
BOMView revisions are workspace objects. They are presented in the workspace
separately from item revisions for three reasons:
• To allow access controls to be placed on the structure of an item revision
independently of access controls on the rest of the item revision’s data. For
example, to protect the structure from further modification while detailed
changes are still being made to a drawing.
• To allow the structure of an item revision to be put through a release procedure

independently of the rest of the data for an item revision.
• To allow for multiple views functionality, when an item revision is able to

reference BOMView revisions of different BOMViews, each of which represents a
distinct view of the structure of the item.

By default a BOMView revision is shown in the workspace as a specification of

an item revision.
The class attributes and methods for BOMView revision in the PS module are as
shown in figure 8-11:
Figure 8-11. BOMView Revision Class Attributes and Methods

The occurrences of a BOMView Revision are listed by the
PS_list_occurrences_of_bvr function. A BOMView Revision’s occurrences
are either all precise, in which case they reference child item revisions or
they are all Imprecise, in which case they reference child items. This is
determined by the state of the PreciseOrImprecise flag. This flag may be
inquired with the PS_ask_is_bvr_precise function and changed with the
PS_set_bvr_precise/imprecise functions.
The BOMView of which it is a revision is obtained by calling the
PS_ask_bom_view_of_bvr function.
A new BOMView revision is created using the PS_create_bvr function, giving the
tag of the parent BOMView and the item revision in which it is to be placed.
The PS_revise_bvr function creates a new BOMView revision based on an existing
revision of the same BOMView. The PS_copy_bvr function creates a new BOMView
revision based on an existing revision of a different BOMView.
A new or modified BOMView revision is not saved to the database until you
make a call to the AOM_save function. This also applies when occurrences
of a BOMView revision are modified. Additionally, when a new BOMView
revision is created, the item revision it is placed in is also modified and must
also be saved with a separate call to the AOM_save function.
Occurrences
The single level structure of an item revision is made up of a collection of links from
a BOMView revision (the parent) to the items which are components of the assembly
(the children). These links are known as occurrences. An occurrence represents the
usage of an item or an item revision within the product structure of a parent. You
can distinguish between different kinds of occurrences in the product structure by
referring to Occurrence Types and Occurrence Sequencing in the Integration Toolkit
Function Reference manual.
Occurrence is not presented as a distinct class within Teamcenter, rather as
an attribute of BOMView revision. In the PS ITK module, occurrences are
always addressed through their parent BOMView revisions.
Creation, modification or deletion of an occurrence is treated as a modification of

its parent BOMView revision. This allows access control to be centralized on the
BOMView revision. You do not have the danger of two users making simultaneous
changes to different occurrences within the same BOMView revision.

Attaching Attribute Data
Attribute data can be attached to occurrences. This is data that is specific to a

particular usage of a component item within an assembly, for example usage notes
and sequence numbers. Data that is generic to all usages of an item should be
attributes of the item itself.
Precise/Imprecise
If the child (component part) of an occurrence is a specific item revision, the

occurrence is precise. If the occurrence is a generic reference to an item, it is
imprecise. If you have an imprecise occurrence, the item it references may be
resolved at runtime to an exact item revision by the application of a configuration
rule.
Multiple View Functionality
To support multiple views functionality, an occurrence also specifies a child

BOMView to allow a particular view of a sub-assembly item to be included in the
structure.
Multi-Level Product Structure
A multi-level product structure is built up by BOMView revisions having occurrences

referencing other items with BOMViews and so on.
Alternates
Rather than referencing a single component item, an occurrence can contain links
to several alternate items (alternates). Alternates are interchangeable with one
other in the assembly. However, one of these alternates is specified as the preferred
alternate. All alternates of a single occurrence share the same attributes, the
attributes specified for the preferred alternate.
Any modifications the occurrence alternates is a modification to the BOMView
revision. Permanent modifications require write access to the BOMView revision.
Temporary modifications may be made during a Teamcenter session but cannot be
saved to the database.
Class Attributes and Methods
The class attributes and methods for occurrence in the PS module are shown in
figure 8-12.

Figure 8-12. Occurrence Class Attributes and Methods

Occurrences are not presented as separate objects in the ITK interface. You must
always address an occurrence in the context of its parent BOMView revision using
the tag of the BOMView revision as well as the tag of the occurrence itself. When you
modify an occurrence of a BOMView revision, you modify that BOMView revision.
The change is not written to the database until you save the parent BOMView
revision using the AOM_save function.
Occurrences are created with the PS_create_occurrences function. The
ChildItem is set to the tag of a component item revision or item, depending on
whether the parent BOMView revision is precise or imprecise. The ChildView can
be set to the tag of a BOMView of the ChildItem or to NULLTAG.
You can inquire about the child of an occurrence with the PS_ask_occurrence_child
function or change it with the PS_set_occurrence_child function. When
PS_set_occurrence_child is called, only the child component of the occurrence is
changed. All of the occurrence attributes (sequence number, notes, and so on) are
retained. This is the functionality employed by the Substitute command in the
PSE user interface.
An occurrence may have brief textual notes attached to it. A note is a string of up to
160 characters. Each note has a type defining its purpose (for example, usage, color,
adjustment). An occurrence may have any number of notes, provided each is of a
different type. The type must be one of a set of Note Type objects defined by the
system administrator for a Teamcenter installation. You can access and edit Notes
using the PS_list_occurrence_notes, PS_ask/set_occurrence_note_text and
PS_delete_occurrence_note functions.
A sequence number is used to identify and sort individual occurrences within a
single level of structure. It is a 15 character alphanumeric string and is inquired or
changed using PS_ask/set_seq_no, respectively.
Occurrence has a quantity attribute containing the amount of the child items
specified by the occurrence (for example, 4 bolts or 1.5 liters of oil). Quantity is stored
as a real number and is accessed by the PS_ask/set_occurrence_qty functions.
A negative quantity means the quantity is undefined.
An occurrence quantity must be expressed in the unit of measure attached
to the child (component) item referenced by the occurrence. Where a
component item has no unit of measure, the quantity value is interpreted
as the number of component items referenced by the occurrence. An
occurrence which specifies more than one usage of a component item is
known as an aggregate occurrence. For morel information about defining
units of measure, see the Integration Toolkit Function Reference manual.
An occurrence also carries a set of flags for storing additional data. Only one flag
attribute is implemented, PS_qty_as_required. When set, it indicates the child item
is to be used as required. Flags are inquired using the PS_ask_occurrence_flag
function and changed using the PS_set/clear_occurrence_flag functions.

A 4x4 transformation matrix can be stored on an occurrence for passing positional

information to a CAD system and is accessed using the PS_ask_set_transform
function.
By default, the occurrences of a BOMView revision are listed in the
order in which they were created. This order can be altered using the
PS_move_occurrence_to/up/down functions.
A change of ordering is treated as a modification to the parent BOMView
revision. Call the AOM_save function to store the change in the database.
Additionally, this ordering functionality is not available through the PSE
user interface. Occurrences are sorted by sequence number unless a
different custom sort algorithm is supplied for a Teamcenter installation.
You can create an alternate with the PS_add_alternate function. It takes an

existing item and makes it an alternate to the existing child of an occurrence. If the
occurrence previously had no alternates, the existing child is used as the preferred
alternate.
You can delete a non-preferred alternate with the PS_delete_alternate function.
The preferred alternate cannot be deleted.
You can make a non-preferred alternate the preferred alternate using the
PS_prefer_alternate function. If the BOMView revision is write-protected or
frozen, the change to the preferred alternate succeeds, but the change cannot be
saved to the database. This case is flagged by the is_temporary return value.
You can find the occurrence alternates using the PS_has_alternates and
PS_list_alternates functions. The PS_has_alternates function returns true if the
occurrence has two or more alternates defined. The PS_list_alternates function
returns a list of the occurrence alternates.
View Type
Each BOMView in Teamcenter has a type attribute. A View type is an object
that defines an identifying string for a type of view (for example, design view or
manufacturing). The system administrator defines View types for a Teamcenter
installation.
Teamcenter provides a default View type. All BOMViews created via the
Teamcenter user interface are of this type. The name of this View type is defined by
the PS_default_view_type_name token in the ps_tokens.h header file .
The class attributes and methods for the View type in the PS module are shown
in figure 8-13:
Figure 8-13. View Type Class Attributes and Methods

A View type is a site-defined classification of BOMViews. You can get a list of all
View types defined for an Teamcenter installation from the PS_view_type_extent
function. You can search for a particular View type by name using the
PS_find_view_type function. You can find the name of a View type object from its
tag by calling the PS_ask_view_type_name function.

Only the system administrator can alter the list of available View types,
using the PS_create_view_type and PS_delete_view_type functions.
Note Type
You can attach text notes to occurrences. Each note has a type (for example, usage
or adjustment), which defines the purpose of the note. The possible types of notes
are determined by the set of Note type objects defined for a Teamcenter installation
by the system administrator.
The class attributes and methods for Note Type in the PS module are shown in
figure 8-14:
Figure 8-14. Note Type Class Attributes and Methods

Note type is a list of types of occurrence note, as defined for a Teamcenter installation
by the system administrator. Each Note type has a short name used as an identifier
(for example, at the head of an attribute column in PSE) and a description which can
be used for a longer explanation of the purpose of the Note type.
Call the PS_note_type_extent function to get a list of available Note types. To find
individual types by name, use the PS_find_note_type function.
Functions that modify the list of available Note types
(PS_create_note_type, PS_delete_note_type and
PS_set_note_type_name/description) can only be called by a
user with system administrator privileges.
Loading of PS Objects
When a call to a PS ITK function needs to access the attributes of an object, that
object (if not already loaded) is loaded automatically. When a call to a PS ITK
function modifies the attributes of an object, that object is locked for modification
automatically if it is not already locked.
Adding Attributes
You can add attributes to PS objects using the PS ITK. Each class within the PS
module can have a number of client data attributes defined for it. Each instance of
such a class may then have each of these client data attributes set to reference a
POM object. This POM object must be of the class specified in the definition of
the appropriate client data attribute.

Product Structure Model

When Teamcenter displays the product structure of an assembly, you see a tree of
item revisions. Figure 8-15 shows an example:
Figure 8-15. Product Structure Model

This simplistic model is complicated by two additional requirements:
1. Teamcenter does not store references to exact revisions of items. This means the
assembly would have to be modified every time you wanted to use a new revision
of a component. Instead Teamcenter stores a reference to an item and turns this
into an exact item revision at runtime by application of a configuration rule.
The PS module itself does not deal with the use of configuration rules (for
detailed information, see Bill of Materials (BOM) Module, earlier in this
chapter), but configuration impacts the PS module with the requirement to store
references to imprecise items as well as precise item revisions.
2. PS has been designed to facilitate multiple views functionality. This is done by

using the BOMView object, each of which represents one view of the structure
of the item.
In an imprecise case, a structure references an item as well as a BOMView of that

item. At runtime, a configuration rule is applied to find the appropriate revision
of the item. If this component item revision references a revision of the specified
BOMView, then this component is a subassembly whose structure is defined by the
BOMView revision found. Otherwise, this component is treated as a piece part (it is
not further divisible into a substructure).
Figure 8-16 shows this diagrammatically. In the precise case, the item revision is
referenced directly by the occurrence, therefore the configuration step is eliminated.

Figure 8-16. Item Revision Model
Where Used
The PS ITK supplies three functions to produce where used reports on item revisions.
Each reports parent item revisions having a BOMView revision with occurrences
referencing the given item revision up to a specified number of levels.
• PS_where_used_all
This function reports all usages regardless of precise/imprecise status and
configuration rules.
• PS_where_used_configured
This function applies a configuration rule (from the CFM module) to report
usage in context.
• PS_where_used_precise
This function looks at precise occurrences.

Relationship to the BOM ITK Module

The BOM ITK module sits at a level above the PS module and beneath the PSE user
interface. It is oriented toward the presentation of and interaction with product
structure and encompasses the application of configuration rules.
The BOM module pulls together information from items, item revisions, BOMView
revisions and occurrences to present them as entries in a bill of materials. The
majority of product structure work can be done using the BOM module with the
exception of creating new BOMViews. For this, PS must be called.
The PS ITK is most useful for lower level operations (such as the large scale import
of structure data into Teamcenter) or batch operations to update specific structure
attributes where the overhead of building up the full presentation of BOM-related
information is not required. Direct calls into the CFM ITK can provide configuration
information to support use of the PS in this way without needing to use the BOM
module.

Chapter
9 Persistent Object Manager Layer
Persistent Object Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Data Definition Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Class Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Class_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Initial Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Attribute Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Attribute_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Index Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Class, Attribute, and Index Descriptions . . . . . . . . . . . . . . . . . . . . . . 9-7
Identification of Class Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Data Manipulation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Create Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Copy Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Save Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Load Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Unload Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Refresh Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Delete Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Select Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Order Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Reference of Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Instances of Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Class of Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Inquiries to Find Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Attribute Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Modifying Attributes in the Database . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Setting Attributes of Loaded Instances . . . . . . . . . . . . . . . . . . . . . . . 9-13
Getting Attributes of Loaded Instances . . . . . . . . . . . . . . . . . . . . . . . 9-13
Tag, Class_id and Attr_id Manipulation . . . . . . . . . . . . . . . . . . . . . . 9-13
Variable Length Array Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
Check Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Initialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Set Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Set User Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17

User and Group Inquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Application Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Access Control List (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Starting and Stopping POM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Password Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Control of Logins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Environmental Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Direct SQL Access to the Internal Structure . . . . . . . . . . . . . . . . . . . 9-22
Other Functions Available for User Assistance . . . . . . . . . . . . . . . . . . 9-23
POM Inheritance Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24

Common Include File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Schema Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
ITK Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
POM Enquiry Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33

What Is the POM Enquiry Module? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
Differences Between Old and New Systems . . . . . . . . . . . . . . . . . . . . 9-33
How Do I Use It? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-34
Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-34
Basic Steps to Creating Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
Basic Single Table Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
Note on Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
How to Do a Simple Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
More Advanced Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Important Terms and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Query Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Building Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40
Practical Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
SELECT Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
FROM Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
WHERE Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-44
ORDER BY Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-45
GROUP BY Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-47
HAVING Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-47
Subqueries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-47
Use of class_alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-49
Use of pseudo_class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-51
Use of Set-Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53
INTERSECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53
DIFFERENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-54
UNION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-55
Special Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
POM_enquiry_substr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
POM_enquiry_cpid_of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57

POM_enquiry_upper and POM_enquiry_lower . . . . . . . . . . . . . . . 9-59
POM_enquiry_countdist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60
POM_enquiry_in and POM_enquiry_not_in . . . . . . . . . . . . . . . . . 9-60
Supported Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-61
Use of POM Load by Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-63

Chapter
9 Persistent Object Manager Layer
This chapter describes the Persistent Object Manager (POM), POM inheritance,
and the POM enquiry module.
Persistent Object Manager

The Persistent Object Manager (POM) forms part of the data management layer of
the ITK. POM provides the interface between Teamcenter objects and the relational
database management system (RDBMS). POM provides:
• Data Definition Services
Definition of classes by inheritance from existing classes and definition of
attributes.
• Data Manipulation Services

Manipulation of in-memory objects and support for their saving and retrieval
to and from the underlying RDBMS.
• Locking
Support for many different applications accessing the same data concurrently.
• Referential Integrity
Protection against the deletion of data used by more than one application.
• Access Controls
Support for the access control lists attributed to objects. The access controls
themselves are manipulated by functions provided by the Access Manager.
Concepts
The following sections describe class, attribute, instance, index, and tag.
Class
A class is a definition of a data structure containing one or more attributes. Classes
are organized in hierarchy, with superclasses and subclasses. A class inherits
attributes from its parent (superclass) and passes its attributes on to its children.
POM allows only single inheritance; that is, any class can have only one parent, one
grandparent, and so on.

Chapter 9 Persistent Object Manager Layer
In figure 9-1, classes B and C can inherit from (in other words, be direct subclasses
of) only one immediate superclass, class A. Classes B and C cannot also inherit
from class XX.
Figure 9-1. Classes

Each class has a unique name. For example, the Human class is a subclass of
Primate, which is itself a subclass of Mammal. Primate inherits attributes such
as hairiness and warmbloodedness from the definition of Mammal. In addition
to the inherited attributes, it adds its own, such as binocular vision. As Human
inherits from Primate, it therefore has all the attributes of a Primate. In addition,
it can have specific attributes, such as I.Q.
Attribute
Attributes are the individual data fields within classes. Each attribute has a unique
name within the class that identifies it. It also has a definition that defines the
type of data object and its permitted values. For example, a Human has attributes
of weight and eye color. Weight is a real number. Eye color may be one of a set
(for example, blue, grey, brown).
You can declare attributes to be class variables. This is an attribute which has
the same value for all instances of the class. When the attribute value is changed
by modifying any instances, the value changes for all instances of the same class
(or subclass).
Instance
Instances are the individual data items created from class definitions. Making an
instance from a class definition is instantiating that class. Each instance has the
attributes defined in the class, but has its own values for these attributes. For
example, an individual Human might have a weight value of 160 pounds and an
eye color value of brown.
Some classes are defined to be uninstantiable, meaning they cannot be instantiated.
An example of such a class would be Mammal.
Index
Indexes are created on one or more of the attributes that exist within a class
definition. Indexes can only be defined across attributes that belong to the same
class.
Indexes aid performance. For example, two attributes that the Human class has
are weight and eye color. To list all Humans who have an eye color of brown, you
would probably search the database for all instances of the Human class that
matches the applied criteria.

Persistent Object Manager Layer
Though this type of search is performed well by a RDBMS, it is slow. The alternative
is to have an index on the eye color attribute. Internally, the database maintains its
index of where to find objects with the required attributes. Therefore, the search for
Humans with brown eyes is much faster if an index is put on a value attribute.
To optimize performance when defining the indexes, you have to anticipate what
searches the application is likely to be required.
Indexes improves query performance when searching on that indexed
attribute, but at a small time penalty for save, update, and delete operations
which must update the instance and the index.
An index can be defined as unique. This ensures that the POM checks for an existing
value for an index when a class with attributes containing an index is instantiated.
The uniqueness is tested only upon a save to the database. While an instance
remains in a user’s session, duplicates may exist.
For example, the POM_user class has a name attribute which has a unique index
defined on it. This prevents two POM users with the same name from being
registered with the POM.
When the unique index spans more than one attribute, the uniqueness must be for
all the attributes combined. For example, the POM_user class with first_name
and second_name attributes, both covered with a unique index, allows (John Smith
and John Brown) and (John Smith and Bill Smith), but not (John Smith and John
Smith), to be registered with POM.
Tag
A tag is a short-lived reference to an instance. The tag persists for the length of a
session and can be exchanged between processes in a session.
To exchange a reference to an instance between processes of different sessions, the
tag must be converted to a persistent identifier called a handle by the sender, and
from handle to tag by the receiver. The receiver’s tag can be different in value to the
sender’s as they are in different sessions.
Data Definition Services

To enable applications to specify their data model, you have to prepare an object
definition file. This file can then be processed and stored by the POM. You prepare
the object definition file using functions as explained below.
Class Definition
The POM_define_class function defines a new class as a subclass of an existing
class. You can define new classes at your site by specifying the following for the
new class:
• A unique class name.
• A super class.
• Additional class properties (for example, instantiable).

• Optionally, an application name, when it is required for the newly created class
to have certain operations performed on it by that named application.
The application name is a security feature. Operations on the instances
of that class, or at least the attributes of that class, are restricted to
the named application. The application identifies itself around the
operation. By keeping its registration code secret, which was given
during initialization, other applications cannot gain access to the classes
in a specified instance.
The new class inherits all the attributes defined for its superclasses.
To remove a class from the class tree, use the POM_remove_class function (the
schema is saved by this call). Removing the class ensures that it can no longer be
used to create new instances or to define new subclasses.
To remove a class:
1. Remove all of its subclasses.
2. Unload all loaded instances of the class.
3. Delete all saved instances.
You can now remove the class by calling the POM_remove_class function. To
use this function, the caller must be an Teamcenter system administrator. The
new schema, without this class and its subclasses, is saved when the POM_stop
function is called.
The POM_save_class function saves a new class.
Class_id
On creation, a class is given an identifier, the class_id. This is the internal reference
that the POM uses whenever that class is used in a function.
Initial Classes
When the POM is installed, the initial class hierarchy contains six classes. The
topmost class in this hierarchy and superclass of all POM classes is POM_object.
There are two direct subclasses of POM_object: POM_application_object
and POM_system_object. POM_system_object in turn has three subclasses:
POM_user, POM_group, and POM_member. Applications should define their
own classes using POM_application_object as their superclass, inheriting useful
attributes such as access control lists. Figure 9-2 shows the initial classes and their
relationship.

Figure 9-2. Initial Classes

Initially, there are no instances of the POM_application_object class. The
POM_user and POM_group classes are automatically instantiated. The user’s
name and password and the group’s name are taken from the first call to the
POM_start_modify function. The user is also made a member of the SYS_ADMIN
group (created automatically). If a group name is not specified in the call to
POM_start_modify, then only the SYS_ADMIN group is created.
Attribute Definition
To define an attribute for a class, use the POM_define_attr function. The argument
of this function, descriptor, determines by description of the attribute whether:
• It must be uniquely valued.
• A null value is allowed.
• It has an upper bound.
• It has a lower bound.
• It has an initial value.
• It is a class variable.
• It can be frozen.
• It can be written to/by, even if the class is application protected (for more
information, see Application Protection, later in this chapter).
• It can be read, even if the class is application protected.
The following functions are used to set the value (or NULL value) for an attribute
that has been defined to have lower and (or) upper bounds:
• POM_set_attr_lower_type
• POM_set_attr_lower_null
• POM_set_attr_upper_type
• POM_set_attr_upper_null
The bounds are closed. Therefore, the values specified for the bounds are themselves
legitimate. For example, if the lower bound is 0 (zero), then 0, 1, 2, and so on are
permissible, but -1, -2, and so on are not.

To set the initial value (or NULL value) for an attribute that has been defined to
have an initial value use the relevant function use one of the following functions:
• POM_set_attr_initial_type
• POM_set_attr_initial_null
For array-valued attributes, all the elements in the array take the same
lower and upper bounds and the same initial value.
The POM_remove_attr function removes the definition of an attribute from a

class that has not yet been saved.
Attribute_id
On creation, an attribute is given an identifier, the attr_id. This is the internal
reference that the POM uses whenever that attribute is used in a function.
Index Definition
To ease the search facility, a set consisting of one or more attributes can be specified
to be indexed.
The POM_define_index function defines an index by:
• Taking an existing class and a number of attributes which are already associated
with that class.
• Adding that index definition to the class definition.

A particular class cannot have two indexes of the same name, but two
different classes can. Therefore to specify an index it is necessary to
specify both:
– The name of the index.
– The class.
To remove an index definition from the class definition, use the POM_remove_index
function.
Indexes have the following restrictions imposed on them by the mapping of the
RDBMS:
• They cannot index on Note attributes.
• They cannot index Array attributes.
• They cannot index Nulls allowed attributes.
• They cannot define an index that spans class boundaries (in other words, class
to subclass).
Additionally, though it is possible to have several indexes on subsets and supersets

of attributes in existing indexes, the ordering of these indexes cannot be created
twice. You cannot have two indexes on the same set of attributes, even if the name
or order are different.

Class, Attribute, and Index Descriptions

The following functions enable you to make enquiries on classes, attributes, and
indexes:
• POM_describe_class
• POM_ask_attr_lower_type
• POM_ask_attr_upper_type
• POM_ask_attr_initial_type
• POM_describe_index
• POM_indexes_of_class
• POM_indexes_of_attr
• POM_attr_id_of_attr
Identification of Class Structure

There are functions within the POM module that identify the following:
• The superclasses and subclasses for a specified class.
• Whether one class is anywhere in the class structure below a given class.
• The ID of a class which is specified by its name.
• The name of a class which is specified by its ID.
Data Manipulation Services

The data manipulation services allow you to execute various actions on instances.
Create Instance
The POM_create_instance function allows you to create an instance of a specified
class.
It is possible to start the POM module without setting a current group. Because
of this, it is also possible that an attempt can be made to create an instance for
which an owning group cannot be set. When this happens, the function fails with
no current group.
A function fails with an improperly defined class when the class is only partially
defined. For example, if you define an attribute to have a lower bound but have not
yet set the value for this lower bound.
When an instance is created, all attributes with an initial value defined are set to
that value. System-maintained attributes, such as creation date and owning user,
are set by the system. All other attributes are empty. These must be set to allowable
values before the instance can be saved.

Copy Instances
To create copies of a set of existing instances, which must be loaded in the current
session, use the POM_copy_instances function. The new instances are of the same
class as the source. The attributes are maintained as follows:
• Application-maintained attribute values are copied.
• System-maintained attribute values (for example, creation_date) are set

appropriately.
The copy is created as an instance of the class in which the original instance was
instantiated. This applies even if the original instance is loaded as an instance of
a superclass.
Save Instances
By using the POM_save_instances function, instances created, or changes that
were made to a set of instances, are saved to the database. An additional option of
this function is the ability to discard the in-memory representation.
The POM_save_required function checks whether a specified instance was
modified. The instance may be newly created or loaded for modification in the
caller’s local memory storage. The function determines modification by testing
whether the local memory representation of the instance was altered since the
instance was loaded.
After an object instance is saved, it remains locked. The application must unlock the
object by calling the POM_refresh_instances function.
Load Instances
Instances can be loaded as instances of their own class or any superclass.
The POM_load_instances function loads and creates copies of specified instances
that are all of the same class. To load instances that are of different classes, use the
POM_load_instances_any_class function. However, the class that they are loaded
as must be common to all loaded instances as in figure 9-3:
Figure 9-3. Class Hierarchy

When an instance is loaded as an instance of a superclass it may lack certain
attributes which it would normally have. This can cause certain operations on the
instance to fail, giving an error message of the attribute not being defined for the
specified class. When this occurs, the argument is referring to the class which was
given to the calling function and not the class to which the instance really belongs.

When the modify_lock argument for this function is set, the instances are locked
for modification, therefore no other session can lock them for further modification
at the same time. When they are not locked for modification but are either set to
read_lock or no_lock, this permits other sessions to lock them for modification or
read as required.
The POM_load_instances_by_enq function executes a specified enquiry and loads
the resulting set of instances from the database, creating in-memory copies of the
instances.
The POM_is_loaded function checks whether a specified instance is loaded in the
caller’s local memory. Newly created instances are counted as loaded, as they are
already present in the local memory having been created during that session.
To check whether the given instance is loaded in the caller’s local memory for
modification, use the POM_modifiable function.
Unload Instance
The POM_unload_instances function unloads specified instances from the
in-memory representation without saving any changes that were made to the
in-memory representation.
To save changes that were made to the in-memory representation, use the
POM_save_instances function.
Refresh Instances
The refresh operation is the equivalent to unloading and then reloading an instance
without having to complete the two separate operations. This operation causes the
attribute values to be refreshed to the corresponding values in the database.
Occasions when the refresh operation can be used are:
• When you need to update the instance that is currently being worked on to
reflect changes that might have occurred since the user’s copy was made.
• When you decide to scrap all changes that have been made to the instance.
The POM_refresh_instances function refreshes a specified set of instances when

instances are all of the same class. This function can also be used to change the class
as the instances are loaded (within the same tree).
To refresh a specified set of instances that are not all of the same class, use the
POM_refresh_instances_any_class function. The instances are refreshed in
their actual class.
These refresh functions allow the specified instance’s locks to be changed.
The POM_refresh_required function checks whether a specified instance, which
is loaded for read in the caller’s local memory, requires a refresh by testing if the
database representation of the instance has been altered.
Delete Instances
The POM_delete_instances function enables the deletion of a specified instance.
The POM_delete_instances_by_enq function enables the execution of a specified
enquiry followed by the deletion of the resulting instances from the database.

The instances to be deleted must not be referenced or loaded by this or any

other POM session. This is how the POM maintains referential integrity.
Newly created instances (in other words, those that have not yet been
saved) cannot be deleted. This is because deletion is a database operation
and these newly, unsaved instances do not yet exist there. Unloading these
instances effectively deletes them. If a class is application-protected, then
instances of that class can only be deleted by that application (for more
information, see Application Protection, later in this chapter).
Select Instance
If the application knows before loading an instance which attributes it intends
to manipulate, the application may choose to load the instance with only those
attributes. This is called selecting. The instance is loaded in the normal way, with
the normal rules for loading applied, except that attributes that are not selected are
not loaded. Any attempt to manipulate these unselected attributes are trapped
by the POM.
The advantage of selecting over loading is that selecting an instance takes less time
than loading the full instance. The functions used to select instances are:
• POM_select_instances
• POM_select_instances_by_enq
A selected instance can be turned into a fully loaded instance by refreshing it.
Order Instance
To order an array of loaded POM instances on the values of attributes that are
common to all the instances, use the POM_order_instances function.
For this operation to be successful, the following criteria must be applied:
• The instances must be loaded.
• Only one attribute may be specified for ordering.
• None of the attributes being ordered can be empty.
Reference of Instance
The POM_references_of_instance function enables you to find all instances and
classes in the database which contain references to a specified instance.
The level of the search through the database is determined by the n_levels
argument. The where_to_search argument determines which domain to search (in
other words, local memory, database or both).
The DS argument limits the search to the working session (things not yet committed
to the database). The DB argument limits the search to the database only. DS and
DB together extends the search to both domains.
When a class is found to be referencing an instance, there is a class variable which
contains that reference.

Instances of Class
The POM_instances_of_class function returns all the instances of a specified class.
Class of Instances
To find the class to which an instance belongs, use the POM_class_of_instance
function. This function returns the class in which the instance was instantiated.
Use the POM_loaded_class_of_instance function to find the class of an instance
as it has been loaded.
Inquiries to Find Instances

An inquiry to the POM, is a pattern that can be applied to saved instances of a
specified class (and its subclasses) to select a subset of those instances.
The inquiry takes the form of restrictions on attribute values and combinations of
the same, using the logical operators AND and OR. For example, if you have a
furniture class with a color attribute and a table subclass with a height attribute, it
is possible to create an inquiry to list all instances of the table class which has the
restriction that the color is red.
Once an inquiry is created, it can be combined with other inquiries (such
as height less than three feet). It can then either be executed (to return a
list of tags of those instances that match the inquiry) or it can be passed to
the POM_load_instances_by_enq, POM_select_instances_by_enq, and
POM_delete_instances_by_enq functions which then load, select, or delete, as
appropriate, those instances which satisfy the inquiry.
The following functions enable the user to create, but not to execute, an inquiry of a
specified attribute or array-valued attributes:
• POM_create_enquiry_on_type
• POM_create_enquiry_on_types
To execute a specified inquiry and return a list of tags of instances as specified by

the inquiry, use the POM_execute_enquiry function.
To combine two inquirie,s use the POM_combine_enquiries function.
The POM_order_enquiry function specifies the order in which to produce the
instances.
• Each attribute may be ordered in ascending or descending order. The instances
are ordered on the value of each attribute in turn, starting with the first
attribute in the array.
• This function can be used to override a previously specified order. Therefore, for
instances, the same enquiry_id can be used more than once to produce different
orderings of the same instances.
It is not possible to order on either variable length arrays (VLA) or arrays.
The POM_negate_enquiry function negates a specified enquiry and the

POM_delete_enquiries function deletes specified enquiries.

Attribute Manipulation
Attribute manipulation enables you to modify attributes in the database, set and get
attributes of loaded instances, manipulate tag and class IDs, manipulate variable
length arrays, and check references.
Modifying Attributes in the Database
The following group of functions enables you to change the attribute values of an
instance without first loading the instance:
• POM_modify_type
• POM_modify_types
• POM_modify_null
• POM_modify_nulls
• POM_modify_type_by_enq
• POM_modify_types_by_enq
• POM_modify_null_by_enq
• POM_modify_nulls_by_enq
You can change the following attribute values:

• A specified attribute to a given value or to NULL for specified instances all
in the same class.
• All or some of the specified array-valued attribute to the given array of values, or
to NULL, for specified instances in the same class.
• The specified attribute to the given value for all instances found by an enquiry.
• All or some of the specified array-valued attributes to the given array of values
for all instances found by an enquiry.
These functions modify data directly in the database and not on loaded instances.

Setting Attributes of Loaded Instances

The following functions enable the user to set the value of a specified attribute in
an instance:
• The POM_set_attr_type and POM_set_attr_null functions change the
specified attribute to the specified value or to NULL in the local memory only, for
instances when the specified instances are all in the same class.
• The POM_set_attr_types and POM_set_attr_nulls functions change all or

some of the specified array valued attribute to the specified array of values or to
NULL, in the local memory only, for instances all in the same class.
When changing the specified array-valued attribute to NULL, the attribute must
exist for all the instances, therefore there must be a class with that attribute and
instances must be in that class or in a subclass of it. This also applies to non-array
attributes.
Getting Attributes of Loaded Instances

You can use the following functions within the POM module to retrieve the value of a
specified attribute in an instance, for loaded instances only:
• POM_ask_attr_type
Returns the value of the attribute for a specified instance. The value returned
is the value of that instance in the local memory; this could differ from the
corresponding value in the database.
• POM_ask_attr_types
Returns n-values of values of the array-valued attribute for a specified instance
starting from the position start. The values returned are those of the value of
that instance in the local memory; these could differ from the corresponding
values in the database.
Tag, Class_id and Attr_id Manipulation

The POM provides the following functions for conversion and comparison operations:
• POM_tag_to_string
• POM_string_to_tag
• POM_class_id_to_string
• POM_string_to_class_id
• POM_attr_id_to_string
• POM_string_to_attr_id
• POM_compare_tags
• POM_compare_dates

Variable Length Array Manipulation
Variable length arrays (VLA) are attributes that can have a variable number of
elements of their declared type. The data type of the VLA and class type (for typed
references) or string length (for notes and strings) are declared when the attribute is
defined.
When an instance of a class with a VLA attribute is created, that VLA attribute
is initialized to a zero length.
The following functions are used to extend or remove elements from the VLA. All
these functions, with the exception of POM_reorder_attr because it can be applied
to any array, are specific to VLAs:
• POM_insert_attr_types
Inserts the specified values into a specified VLA attribute at a specified position.
The maximum value for the specified position is the length of the VLA.
• POM_clear_attr
Clears all values from the specified VLA, effectively setting its length to 0 (zero).
• POM_remove_from_attr
Removes a specified number of elements from the VLA.
• POM_append_attr_types
Adds the specified values to the end of the specified VLAs.
• POM_length_of_attr
Returns the length of a specified VLA (in other words, the number of values
in the VLA).
• POM_reorder_attr
Reorders elements within a VLA.
Check Reference
To perform reference checking to find the type of a specified attribute of an instance,
use the POM_check_reference function.
The POM_check_reference function permits checking for consistency between the
class definition and the instance information.

Users and Groups

The POM allows users who may be members of one or more groups. Users,
groups, and members are maintained internally by instances of the POM_user,
POM_group, and POM_member classes. A user is associated with a group by the
existence of a member instance that links the user to the group. These instances
must be saved to the database (with the POM_save_instances function) before
they become usable.
A specified member of a group has the privilege of being the group administrator.
This empowers that user to add or remove other members to or from that group. The
system administrator or any member of the system administrator group has this
privilege for any group.
Users and groups in the POM are objects in a protected application, the individual
instances can only be manipulated by the authorized application (see the
POM_register_application and POM_identify_application functions). System
administrators that have been called to perform the changes can create new users
and delete old users.
If you create a new member object for yourself, you cannot immediately set
your current group (using the POM_set_group function) to that specified.
You must save the member object first.
User, group and member objects are instances of application-protected classes,

though some of the attributes of these instances are declared to be public read so
that they can be asked about using the normal calls. The effect of making these
classes application protected is to restrict access to certain attributes (for example,
changing the password of a user is only possible by someone who knows the old
password) or an system administrator and to prevent every user of the system from
being able to generate new users or delete bona fide users.
Create
The following functions create instances of users, groups and members:
• POM_new_user
• POM_new_group
• POM_new_member
The group administrator of the group in which the member resides, as well as the
system administrator, can create members of a group.
Users must be associated with a group using the member functions before the user
and group become registered.

Initialize
The following functions initialize users, groups and members:

• POM_init_user
• POM_init_group
• POM_init_member
Only system administrators are allowed to use the these functions.

If a new instance of the POM_user class is created, using the POM_new_user
function, the attributes of the instance are automatically initialized. However, if an
system administrator creates a subclass of the POM_user class, the attributes (for
example, names, password, and so on) of any new instance of the subclass must be
initialized. Call the POM_init_user function to perform this initialization.
The same rules apply to creating groups and members.
Delete
The following functions delete users, groups and members:
• POM_delete_user
• POM_delete_group
• POM_delete_member
These functions are required because of the application protection. They take
tags of instances of groups, users or members as appropriate or any subclass of
the same. If the subclass is also application protected, then that application must
also be identified.
Only a system administrator can use these functions.
When a user logs into the POM, the appropriate user and group objects
are locked so that they cannot be deleted. This lock is updated whenever
the user changes the group.
After a member object is deleted, the user specified cannot log into the listed group.

Set Group
To set the group to the named group, use the POM_set_group function.
Alternatively, the POM_set_group_name function sets a specified name for a
specified group.
The POM_set_default_group function sets the default group for the current user.
The user object must be loaded for modification and then must be saved again
afterwards for this change to be permanent.
The POM_set_user_default_group function sets the tag of the specified user’s
default group. This is the group which the user is logged into if the POM_start
function is given an empty string for the group_name argument. Only a system
administrator or that individual user can use this function.
To enable a user that is logging into a group to have group system administrator
privileges, use the POM_set_group_privilege function with the privilege
value of 1. A privilege value of 0 (zero) ensures that a person logging into the
specified group only has the privileges associated with an ordinary user. The
POM_set_member_is_ga function sets the group administration attribute for the
specified group to the specified value, either 0 (zero) or 1.
A member is a loaded form of the database link that gives the user authority to log
into the chosen group (in other words, gives the user membership to the group).
The POM_set_member_user function sets the user (tag) attribute of the specified
member instance to the supplied user tag. The POM_set_member_group function
sets the group (tag) attribute of the specified member instance to the supplied
group tag.
Set User Status
The POM_set_user_status function sets the status of the user. Only the system
administrator can use this function. The status is not interpreted by the POM, it is
provided for the system administrator to classify users.
User and Group Inquiries
• The POM_ask_owner function returns the owning user_tag and group_tag

for an instance.
• POM_is_user_sa advises if the current user is logged into the POM under a
privileged group.
• POM_ask_default_group returns the tag of the current users default group.
• In contrast to the previous function, the POM_ask_user_default_group

function returns the currently set default group for a user. Only a system
administrator or the individual user can use this function. The user object must
be loaded before using these functions.

• The POM_ask_group function returns the name of the group, as handed to the
POM_set_group or POM_start functions, and the group_tag, as returned by
the POM_set_group function.
• The POM_get_user function returns the name of the logged in user, as handed
to the POM_start function, and the user_tag, as returned by the POM_start
function.
Security
Teamcenter provides security through application protection and access control lists.
Application Protection
Classes can be associated with a particular application, so that only that application
can perform the following operations on instances of these classes:
• Set
• Ask
• Delete
The following operations are not affected by application protection:

• Create
The instance is of no use unless the attribute is completed, and it is not possible
to do this without using set.
• Load
Ask is required to get at the information.
• Save
This fails if there are any empty attributes, and set is required to fill them in.
• Modify
Modify is the equivalent to load, set, save, and unload.
The application protection affects all attributes defined in the given class in all
instances of it or its subclasses. Attributes can be unprotected by declaring them as
public, read, or modify in the attribute definition descriptor.
The association between a class and an application is not inherited by subclasses of
the class. Those subclasses may have an association with some applications. This
could be the same one as the class itself.
The POM_identify_application function is used by an application to identify itself
to the POM so that the POM allows it to perform protected operations on classes
with which the application is associated. On completion of the protected operations,
the application becomes anonymous. POM does not allow further operations without
the application re-identifying itself.

For an application to be registered with POM and thereby obtain the application
ID and code that is required by the POM_identify_application function, use the
POM_register_application function.
The code number returned by the POM_register_application function is a random
number which, in turn, is used as a level of security checking.
Access Control List (ACL)

Access to instances is controlled by the POM. To support this, all instances of the
POM_application_object class or its subclasses contain an access control list
(ACL). The ACL is consulted by most of the functions documented in the Data
Manipulation Services section, earlier in this chapter.
Functions to manipulate access controls are provided by the Access Manager
application. Access can be granted and revoked to and from users and
groups individually. The main functions provided for these operations are
AM_apply_access and AM_revoke_access.
There are four types of access that can be applied:
• delete
The privilege to delete the instance.
• read
The privilege to read the instance.
• write
The privilege to modify the instance, which also implies read privilege.
• change
The privilege to change the access control in force.
When instances of the POM_application_object class or its subclasses are created,

the ACL is set to be a default ACL for that particular user. This ACL contains
entries for the owning user, owning group, system utilities and world access. The
access given to each entry is governed by the AM_set_user_initial_acl function.
Additionally, the current user and group are set to be the owning user and owning
group of the instance respectively. For more information about how ACLs are
evaluated, see Access Manager, later in this chapter.
System Utilities
System utilities are managed by POM functions that enable you to start and stop
the POM, manipulate passwords, rollback a process to a previous state, control
timeouts and logins, and trap POM errors.
Starting and Stopping POM

The POM_start function is the first call to the POM module and therefore it logs
the user into the POM. If you call any other function before this function, then that
function fails except for POM_explain_last_error which always works.

The only alternative to calling the POM_start function to start the POM module is
for the system administrator to log into the POM using the POM_start_modify
function. This function differs from POM_start in that it allows the system
administrator and only the system administrator, to modify the schema (in other
words, define classes and remove class definitions).
To log out of the POM, use the POM_stop function.
Password Manipulation
To set the password for the specified user, use the POM_set_password function.
Because of the severity of this operation, it can only work on one user at
a time.
The POM_check_password function checks the password for a user by comparing

the given password with the stored password.
For security, the stored password is encrypted and never decrypted or returned
through the interface. The encryption algorithm is not public.
When Teamcenter Security Services are installed and the
TC_SSO_SERVICE environment variable is set in the iman_profilevars
file, passwords are managed by an external identity service provider rather
than Teamcenter. In this case, the POM_set_password function returns
POM_op_not_supported (the ability to change a password in the rich
client and ITK is disabled).
Rollback
The rollback facility enables you to restore a process to a previous state. The state at
which a process is restored is dependent on the position of the specified markpoint.
Markpoints are used at your discretion and are placed using the
POM_place_markpoint function. When a markpoint is placed, an argument is
returned advising you of the identifying number of that markpoint.
To rollback to an earlier state in the process, use the POM_roll_to_markpoint
function specifying the markpoint to which you want to rollback. This function
restores the local memory and the database to the corresponding state that it was in
when the specified markpoint was set.
As an overhead saving, rollback can be turned off with the POM_set_env_info
function.
The rollback removes the caller’s changes to the database. Any changes to the
database by other users are unaffected. If other users have made changes which
prevent the caller’s changes being reversed (for example, deleted or changed values
in an instance in the database), then the rollback fails.
Timeouts
You can use the POM_set_timeout function to set a session wide timeout value
to determine the period during which a POM function repeatedly tries to lock an
instance for change (for example, when calling the POM_load_instances function).

After the timeout period, if the POM function that is to perform the change is
unsuccessful at getting the lock, it returns the appropriate failure argument as
described in the relevant function.
The POM_ask_timeout function advises the user what timeout period has been
set for the session in seconds.
Errors
In the event of a failure, the POM_explain_last_error function explains why the
last failing POM function failed. The information that is returned by this function
includes:
• The actual error code.
• The argument that caused the function to fail.
• The name of the function that failed.
• A description of what that particular error code means.
The POM_describe_error function returns a string describing the specified error

code.
The description returned by this function is the same as that returned by
POM_explain_last_error. For convenience the POM_describe_error function
can be called with any error code at any time.
Control of Logins
The control of logins, which allows or prevents other users from accessing POM, is
set by the POM_set_logins function. When the system administrator needs to
perform an operation that requires only one POM user, the system administrator
can use the POM_set_logins function to prevent any other user from logging into
the POM. In the unusual event of the process which disabled logins terminating
abnormally, the system administrator does have the authority to login using the
appropriate group and password as identification, thus overriding the effect of the
earlier POM_set_logins function call.
However, all POM users can use the POM_ask_logins function to determine
whether other users are currently allowed to access the POM.
Audit Trail
The audit trail is the logging of specific actions by POM, To do this, the POM calls
the general Teamcenter logging function with the POM_set_audit_action function.
The POM_ask_audit_action function returns what auditing is currently active.
Environmental Information
The POM_set_env_info function offer alternative methods of enabling and
disabling operations as explained in its description. This function sets the following
environmental information:
• Enable or disable rollback.

• Enable or disable attribute value checking in the local memory (for example, for
the duplication of unique attributes or for checking against upper/lower bounds).
• Enable or disable journalling (for example, for writing a function’s arguments to

the system log when debugging and bug reporting).
• Enable or disable argument checking.
• Login of a traceback to the log file when receiving an error.
• Writing of all of POM SQL to the log file.
The POM_ask_env_info function returns the environmental information that was

specified by the POM_set_env_info function.
Miscellaneous
This section highlight the POM functions that give you access to SQL statements
and provide user assistance.
SQL
The application data stored by the POM module is accessible using direct SQL
statements for read and write purposes. The POM_sql_view_of_class function
creates a database view of the selected attributes in the given class. The view is
given the name supplied and the columns are aliased with the column names that
are given in the argument for the column names.
The attributes can be from a specified class or any superclass, but they cannot
include any array types.
Direct SQL Access to the Internal Structure

These functions described in this section have been provided to allow the end user
access to the database tables used by the POM.
• The POM_dbname_of_att function takes a class identifier and an attribute
identifier and returns the textual names of the SQL database table and the
column within that table in which the relevant attribute is stored. This function
can be used to either directly access the values of a specified attribute for
specific instances or to produce a query over all values of the relevant attribute
in a given class.
• The POM_type_of_att function returns the array type of the attribute identified
by its class_id and attr_id. The returned types of arrays are:
– non-array (for example, an integer)
– small array
– large array
– variable length array
• The POM_tag_to_uid function returns a UID, which is an internally reference

to an instance.

Other Functions Available for User Assistance
Because some POM tables (in other words, those that hold the values for the class
variables) have the entries specified by a combination of the site identifier, internal
attribute, and class identifiers, you must use the following functions:
• POM_site_id
Returns the site ID of the local POM installation.
• POM_attr_to_apid
Converts the external class and attribute identifiers into the internal integer
attribute identifier.
• POM_class_to_cpid
Converts the external class identifier into the internal integer representation
for a class.
• POM_get_char_ordering
Returns the ordering on the character set in use. This is useful when creating an
enquiry which selects on a string-valued attribute.
• POM_describe_token
Returns a string describing the specified token (for example, for the POM_int
token, which is a defined value, the returned string might be integer).
• POM_free
Frees the space that the POM allocated internally when returning an array of
information.
Values that can be handed to this function are indicated by the letters <OF> after
the argument in the function syntax.

POM Inheritance Example

This section contains an example of how to define POM classes that inherit from
existing Teamcenter classes. These files exist in the sample directory included with
the Teamcenter release.
The basic outline for defining and using new classes is:
1. Define the attributes and methods that you want your new class to have.
2. Find the class in Teamcenter or among other classes that you have defined that
is most like the one you want.
3. Write the schema definition file for your class, inheriting from the class you
located in step 2 and defining any attributes unique to your class.
4. Write functions to:

• Provide access to your class.
• Specialize existing methods.
• Define methods unique to your class.
• Initialize an instance of your class so that other classes can inherit from
yours.
Our example is for a class to represent a library of standard parts for a company.
Basically, a library should be like a folder:
• It needs to have a library type, either corporate, site or private.
• It needs to be protected against change by normal folder cut and paste

operations, unless the application running is the library manager.
• It needs to have a date indicating when the library was released.

Common Include File

The first file, folderlib.h shown in figure 9-4, is an include file that contains
definitions and enums used in the schema definition and the data manipulation
code. Using a common include file for both helps ensure that you do not have bugs
because of typing errors.
/*HEAD FOLDERLIB HHH iMAN */

/*
* Define for the application name
*/
#define LIBFL_APP_NAME "Librarian"
/*
* Define for the class name
*/
#define LIBFL_CLASS_NAME "LibraryFolder"
/*
* Defines for the attribute names
*/
#define FLLIB_MEMBER_ATTRIB"member"
#define FLLIB_DATE_ATTRIB"last_update"
/*
* enums for the library member values
*/
typedef enum LIBFL_member_e {
LIBFL_corporate, /*indicates a corporate library folder*/
LIBFL_private, /*indicates a private library folder */
LIBFL_site/*indicates a site library folder */
} LIBFL_member_t;
Figure 9-4. folderlib.h
Schema Definition
The next file, shown in figure 9-5, defines the schema for the LibraryFolder class.
Notice that it does not use the ITK_auto_login or ITK_init_module functions
because it must log in with the POM_start_modify function to modify the schema.

/*HEAD FOLDERLIB_SCHEMA CCC iMAN */

/*CLASS iMAN */
/*
*
* revisions:
* rv date who pr reason for change
*01 22mar91 smccreated.
*/
#include "iman.h"
#include "folderlib.h"
/*
*
*/
int main(
int argc, /* number of command line arguments */
char* argv[]/* list of command line arguments */
)
/*
* Description:
*This program will install a specialized FolderLand object in the POM
* database. This new object will store library information.
* Since this program is strictly calling POM, it does not require
* the use of ITK_user_main.
*-+
*/
{
int retcode = 0;
tag_t user_tag;
tag_tpom_obj_class_id;
int version,app_id, app_code;
tag_tsuper_class_id;
tag_tlibrary_folder_class_id;
tag_tlib_member_attr_id,lib_date_attr_id;
retcode = POM_start_modify("INFODBA", "Information Manager", "sys_admin",

&user_tag, &pom_obj_class_id, &version);
if (retcode == POM_ok)
{
/*
* Register the name of the application that will manipulate this
* object. This is to prevent any other application from accessing
* the object. Once an application is register, use the app_id and
* app_code change the application protection mode. Save
* these values for future use.
*/
if ((retcode = POM_register_application(LIBFL_APP_NAME,
"some_password", &app_id,
&app_code)) == POM_ok)
{
POM_identify_application (app_id, app_code, true);
Figure 9-5. Schema Definition (Continued)

/*
* Since we are going to inherit from Folder Manager , we need to
* get Folder Manager’s class id. The class name for Folder Manager
* is "Folder".
*/
POM_class_id_of_class ("Folder", &super_class_id);
/*
* Now define the new class LibraryFolder.
*/
POM_define_class (super_class_id ,
LIBFL_CLASS_NAME, LIBFL_APP_NAME ,
0, &library_folder_class_id);
/*
* Define the attributes for LibraryFolder.
*/
POM_define_attr(library_folder_class_id, FLLIB_MEMBER_ATTRIB,
POM_int, 0, NULLTAG, 1, 0, &lib_member_attr_id);
POM_define_attr(library_folder_class_id, FLLIB_DATE_ATTRIB,
POM_date, 0, NULLTAG, 1, 0, &lib_date_attr_id);
/*
* Save the new class to the database
*/
if ((retcode = POM_save_class(library_folder_class_id)) != POM_ok)
{
printf("Unable to save the new class.\n\r");
}
/*
* Turn on application protection, so that no one else can
* can manipulate the data definition for LibraryFolder class.
*/
POM_identify_application (app_id, app_code, false);
}
/*
* Log out of POM
*/
POM_set_logins(true);
POM_stop (true);
}
else if (retcode == POM_already_running )
{
printf("Unable to login as INFODBA.\n");
printf("No one can be logged in when running this program.\n\r");
}
else
{
printf("Error logging into POM as INFOMDBA. Error Code = %d\n\r",
retcode);
}
return (retcode);
} /*main*/
Figure 9-5. Schema Definition

ITK Extension
The code shown in figure 9-6 extends the ITK to include functions which manipulate
instances of the LibraryFolder class. Be aware that there is a LIBFL_initialize
function, thus this class may also be further specialized.
/*HEAD FOLDERLIB CCC iMAN */

/*CLASS ITK */
/*
*+-
*
* Description:
*
* This file contains the C ITK functions for the LibraryFolder object.
* LibraryFolder is a subclass of Folder.
*
*-+
*/
#include "iman.h"
#include "folder.h"
#include "folderlib.h"
/*
* LibraryFolder Class Functions
*/
int LIBFL_create(
const char name[WSO_name_size_c + 1], /* */
const char desc[WSO_desc_size_c + 1], /* */
LIBFL_member_t member, /* */
tag_t* lib_tag /* <O> */
)
/*
* Description:
* This function creates a LibraryFolder object. It will not be
* saved to the database until an explicit call to AOM_save() is
* made. A name and Library member must be specified.
*
* Function Return:
* A zero will be returned on success. Otherwise, an integer error
* code will be returned.
*
*-+
*
*/
{
int retcode = 0;
tag_t folderlib_id_class;
/*
* Get the class id for Folder and create a new instance of a
* LibraryFolder class.
*/
Figure 9-6. ITK Extension (Continued)

if ((retcode = POM_class_id_class(LIBFL_CLASS_NAME,
&folder_id_class)) == POM_ok)
if ((retcode = POM_create_instances(1,folderlib_id_class,
lib_tag)) == POM_ok)
{
/*
* Using the returned tag, initialize the object attributes.
*/
retcode = LIBFL_initialize (*lib_tag, name, desc, member);

}
return(retcode);
} /*LIBFL_create*/
/*
*+-
*/
int LIBFL_initialize(
tag_t lib_tag, /* */
const char name[WSO_name_size_c + 1], /* */
const char desc[WSO_desc_size_c + 1], /* */
LIBFL_member_t member /* */
)
/*
* Description:
* This function initializes a LibraryFolder object. It is meant to
* be called after the creation of an instance of a subclass of
* LibraryFolder.
*
* Function Return:
*
*-+
*
*/
{
int retcode = 0;
tag_t attr_id;
{
/*
* Initialize the attribute’s value for this instance of LibraryFolder
*/
retcode = POM_set_attr_int(1,&lib_tag,attr_id,(int) member);
/*
* Using the returned tag, initialize the superclass object attributes.
* Since a LibraryFolder is a subclass of Folder, it inherits the
* attributes from the Folder class.
*/
retcode = FL_initialize(*lib_tag, name, desc);

}
return(retcode);
} /*LIBFL_initialize*/

/*
*
*+-
*/
int LIBFL_set_member(
LIBFL_member_t member /* */
)
/*
* Description:
* This function sets the library member attribute. The attribute
* can be set to the following values:
*
* LIBFL_corporate
* LIBFL_private
* LIBFL_site
*
* Function Return:
*
*-+
*/
{
int retcode;
tag_t attr_id;
/*
* Get the attribute id for "member" attribute.
*/
if ((retcode = POM_string_to_attr_id((char *) FLLIB_MEMBER_ATTRIB,
&attr_id) == POM_ok))
{
/*
* Set the attribute’s value for this instance of LibraryFolder
*/
retcode = POM_set_attr_int(1,&lib_tag,attr_id,(int) member);
}
return (retcode);
} /*LIBFL_set_member*/
/*
*
*+-
*/
int LIBFL_ask_member(
LIBFL_member_t *member /* <O> */
)
/*
* Description:
* This function gets the current value of member attribute. The attribute
* can be one of following values:
*
* LIBFL_corporate
* LIBFL_private
* LIBFL_site
*

* Function Return:
*
*-+
*/
{
int retcode;
tag_t attr_id;
logical is_it_null, is_it_empty;
/*
* Get the attribute id for "member" attribute.
*/
if ((retcode = POM_string_to_attr_id((char *) FLLIB_MEMBER_ATTRIB,
{
/*
* Get the attribute’s value for this instance of LibraryFolder
*/
retcode = POM_ask_attr_int(lib_tag,attr_id,(int *) member,
&is_it_null,&is_it_empty);
}
return (retcode);
} /*LIBFL_ask_member*/
/*
*
*+-
*/
int LIBFL_set_last_accessed_date(
date_t date /* */
)
/*
* Description:
* This function sets the last accessed date attribute.
*
* Function Return:
*
*-+
*/
{
int retcode;
tag_t attr_id;
/*
* Get the attribute id for "last_update" attribute.
*/
if ((retcode = POM_string_to_attr_id((char *) FLLIB_DATE_ATTRIB,
{
/*
* Set the attribute’s value for this instance of LibraryFolder
*/
retcode = POM_set_attr_date(1,&lib_tag,attr_id,date);
}

return (retcode);
} /*LIBFL_set_last_accessed_date*/
/*
*
*+-
*/
int LIBFL_ask_last_accessed_date(
date_t *date /* <O> */
)
/*
* Description:
* This function gets the last accessed date attribute.
*
* Function Return:
*
*-+
*/
{
int retcode;
tag_t attr_id;
logical is_it_null, is_it_empty;
/*
* Get the attribute id for "last_update" attribute.
*/
if ((retcode = POM_string_to_attr_id((char *) FLLIB_DATE_ATTRIB,
{
/*
* Get the attribute’s value for this instance of LibraryFolder
*/
retcode = POM_ask_attr_date(lib_tag,attr_id,date,
&is_it_null,&is_it_empty);
}
return (retcode);
} /*LIBFL_ask_last_accessed_date*/
Figure 9-6. ITK Extension

POM Enquiry Module
What Is the POM Enquiry Module?

With the POM enquiry system, you can ask the database directly for information
instead of navigating loaded objects. For example, you can request a list of all the
workspace objects where the object_name is test. Another example is a list of all
the instances of a class that have a reference to a particular tag. If you use normal
ITK objects to try to get this information, it takes a lot of time and memory. The
POM enquiry system gives you this information much more quickly and efficiently.
The enquiry system allows you to develop queries that conform to the SQL-92
standard with a few exceptions. These exceptions are:
• You cannot use SELECT * FROM. Only named attributes are allowed.
• You cannot use Cartesian products.
• You cannot use outer joins.
POM enquiries are not the same as saved queries. They are completely
different mechanisms.
Differences Between Old and New Systems
There are actually two different enquiry systems—a newer one and an older one. You
should use the newer one with the calls that begin withPOM_enquiry_ because:
• It produces better, more efficient SQL which runs faster.
• It supports more features present in SQL and allows you to do more complex
queries.
• You can ask for more than one attribute to be returned. The old system only
returned the tags of matching objects.
• You can call the POM_load_instances_possible_by_enquiry function using a

new enquiry and have all the matching instances loaded efficiently.
The definition of all the API calls for the new enquiry system are in the enq.h
header file and the Integration Toolkit Function Reference. If you have legacy code,
you can continue to use the old enquiry system. However, only the newer enquiry
system is described here.
To make the code in this section more readable, the return values of the API
calls are ignored in the examples. In ITK, you should always check return
values before proceeding to the next call.

How Do I Use It?

You do not have to be a SQL expert to use the enquiry system, but it helps if you
know a little, especially if you are trying to debug errors. This section describes the
basic ideas of the query system. Later, there is very detailed information which
describes more complex concepts.
Basic Concepts
There are a number of basic building blocks for an enquiry. These are described
below and then the examples explain what you actually do with these and what
API calls to use.
Each enquiry has a unique name used to identify it. You specify the name when you
create the enquiry and must specify this name for anything you do with this enquiry.
Once you create an enquiry, it exists in memory until you delete it. Therefore, you
can access it using the unique name even if the tag for it has gone out of scope. It
also means you must clean it up explicitly once you’ve finished with it. An enquiry is
made up of a number of smaller parts:
• SELECT Attributes
The values you want to get back from the enquiry.
• ORDER BY Clauses
If you want your results to come back in a particular order, you can use an
ORDER BY. Note that this adds a SELECT attribute for the thing you are
ordering by.
• Attribute Expressions
These allow you to control what data you want returned. These expressions
form the where part of the generated SQL statement. There are two main
types of attributes:
– Fixed attributes
These are the same every time you run the enquiry. They can be simple
values (for example, name = ‘Bill’) or used to create joins between tables
(described below).
– Bind variables
These allow different values to be passed to the database each time the
enquiry is run. These typically would be used either to find related objects
or for values that you do not know at compile time (for example, the value
of tags).
When you add attribute expressions, you normally give both the name of the
attribute and the class it is from.
• Where Clause
This combines a number of attribute expressions using different set expressions.
The most common one is AND.

These parts are the ones that you come across most often. There are a few more than
can be used; they are listed later in this document.
For example, compare the different building blocks with a very simple SQL
statement:
SELECT attr1 from table1 where attr3=’test’ ORDER BY attr1
• attr1 is a SELECT attribute
• where attr3=’test’ is a where clause and
• attr3 and ’test’ are attribute expressions
• ORDER BY attr1 is an ORDER BY clause
Basic Steps to Creating Queries
If you create a POM enquiry, you must follow a number of steps and answer a
number of questions:
1. Create your query. Each query must have a unique name; it should be something
that you can recognize later and describes what it does.
2. Add the data you want returned to your enquiry.
3. Add any attributes you need for where clauses, joins, or other items.
4. Create expressions with the attributes from the previous step to make a where
clause.
5. Optionally, add an ORDER BY clause.
6. Execute the enquiry and extract the results.
7. Clean up.
Below are a number of examples that illustrate these steps for different cases.

Basic Single Table Enquiry
This is a very simple case. This example finds all the workspace objects whose type
is equal to a string that is passed in. Figure 9-7 shows a single bind variable to
compare strings.
/* Create enquiry and give it a name */

POM_enquiry_create (“find_wso_by_type”);
/* Add select attributes. We want the uids of the workspace

objects so we can load them: */
char * select_attrs[1] = {“puid”};
POM_enquiry_add_select_attrs (“find_wso_by_type”,
“workspaceobject”, 1, &select_attrs);
/* Add any attribute expressions. We need two of them - one

for the value we are given and another for the attribute we are
testing against: */
POM_enquiry_set_string_value (“find_wso_by_type”, "type_value",
1,&name, POM_enquiry_bind_value );
POM_enquiry_set_attr_expr (“find_wso_by_type”, "expr1",
“workspaceobject”, "object_type",
POM_enquiry_equal, "type_value" );
/* Set the where condition so we only get back matching rows: */

POM_enquiry_set_where_expr (“find_wso_by_type”, "expr1");
/* Now execute the query: */

POM_enquiry_execute (“find_wso_by_type”, &n_rows, &n_cols,
&values);
Figure 9-7. Basic Single Table Enquiry Example

The program can then iterate through the results and copy the results. Once that is
done, the results array should be freed up using the SM_free function.
Note on Attributes
In general, attributes are referred to by two strings: the name of the class you are
interested in and the attribute name. These values are the same as the definitions in
the schema and do not have to reflect the underlying database table structure. For
example, if you want to get the object_desc attribute of an item then you would
refer to it using the Item class and object_desc attribute. It does not matter that
the object_desc attribute is really on the workspaceobject parent class or what
the name of the column the data is stored in. The one exception is the puid attribute.
This is, in effect, the tag of the object and its unique identifier. If you want to load an
object or follow a reference from one object to another, you must use this attribute.

Housekeeping
As mentioned above, once a POM enquiry has been created, it is available until it is
deleted with the POM_enquiry_delete function. Therefore, you can either:
• Create the enquiry every time you use it and then delete it immediately
afterwards, or
• Create it once and reuse it during the session.
Reusing an enquiry is more efficient. However, be careful in case your code is called
just before a POM_roll_to_markpoint function call or something else that undoes
any allocations in the POM. To protect yourself against this, use a static variable
and the POM_cache_for_session function. For example:
static tag_t my_tag = null_tag;
if (my_tag == null_tag)
{
/* Create enquiry objects, set up bind values, etc */
…
POM_cache_for_session( &my_tag );
my_tag = 1;
}
else
{
/* just set up bind values */
…
}
/* now execute the enquiry and use the results */
…
The POM_cache_for_session function adds to the variable passed to it the data

that is rolled back during an UNDO operation or the POM_roll_to_markpoint
function. If one of these occurs, then your variable is set back to its previous value
(in this case null_tag) and you know you have to create the enquiry again.
How to Do a Simple Join
A join is when you link one table or object to another. For this example, we use
entries in the Process Stage List array and use them to join to EPM tasks. Figure
9-8 shows how they relate to each other.
Figure 9-8. Simple Join

Each entry in the process_stage_list array points to an EPMTask using its puid
field. The example in figure 9-9 is more complicated. The information you want is the
object_name attribute on all the EPMTasks referenced by the workspace object:

/* Create enquiry and give it a name */

POM_enquiry_create (“find_referenced_task”);
/* Add select attributes. We want the object_name of the Task: */

char * select_attrs[1] = {“object_name”};
POM_enquiry_add_select_attrs (“find_referenced_task”,
“EPMTask”, 1, &select_attrs);
/* We’re starting from the workspace object, so we must add a

couple of attribute expressions for that:*/
/* This is going to be the tag we have for the WSO. */

POM_enquiry_set_tag_value (“find_referenced_task” , "wso_tag" , 1,
&object, POM_enquiry_bind_value )
POM_enquiry_set_attr_expr (“find_referenced_task” , "this_wso",\

"workspaceobject" , "puid" , POM_enquiry_equal , "wso_tag" )
/* And now join the workspace object to the EPMTasks via the
process_stage_list attribute on the workspace object */
POM_enquiry_set_join_expr (“find_referenced_task” , "task_join" ,
"workspaceobject" , "process_stage_list" ,
POM_enquiry_equal , "EPMTask" , "puid" )
/* All that’s left now is to execute the query: */

POM_enquiry_execute (“find_wso_by_type”, &n_rows,
&n_cols, &values);
Figure 9-9. Simple Join Example
More Advanced Use
Important Terms and Concepts

To fully understand and be able to create queries, you must understand the following
important terms and concepts:
Class Alias
This is the equivalent of a table alias in the SQL-92 standard. The class alias
is very useful if you want to define a query that has a self-join. The classic
example of this is employees and managers (Find the list of managers and their
employees).
Pseudo Class
The pseudo class represents a compound attribute of a given Teamcenter class.
The attribute must be either a:
• Large array (LA) or
• Variable length array (VLA)
This is useful if you want to query the LA or VLA based on a condition on one
of the array attribute.
Set Expression
This is the way of combining the result of two or more queries into one using
(UNION,...). The queries must be union-compatible (in other words, they must
have the same number of attributes selected and they must respectively be
of the same domain).

Expression
There are two types of expressions that can be built in an SQL statement. These
are:
• Logical expressions
Any expression that results to a logical value (true or false). For example, A
or B, ( A and B ) or C, A=B, A>=B, A IS NULL, A in [a,b,c].
• Function expressions
Any expression that uses a function to manipulate an attribute. For example,
SUBSTR ( A,1,14), UPPER, A+B,LOWER(A), MAX(A), MIN(A), A+B,A/B.
Escape Character
Teamcenter provides two special wildcard characters:
POM_wildcard_character_one and POM_wildcard_character_any. You
can set these values by calling the POM_set_env_info function. However, if the
string contains any of these wildcard characters as part of the data, you have no
way of telling Teamcenter how to treat these values. Ffor this reason, there is a
token for the escape character called POM_escape_character.
You can set this character in the same way as for the
POM_wildcard_character_any or POM_wildcard_character_one
characters, by calling thePOM_set_env_info function with its first argument
POM_escape_character token. If any of the wildcard characters is part of the
data, then you must escape it with the chosen escape character.
• If the escape character is found in the string and is not followed by
either the wildcard characters or itself, the POM removes it from
the string.
• The PUID, PSEQ and PVAL keywords are reserved Teamcenter

words.
PUID can be used as an attribute of any POM class. PSEQ and
PVAL can only be used as attributes of a pseudo-class.
Query Specification
The SQL-92 standard query specification consists of the following clauses:
• SELECT select-list
• FROM class-list
• [ WHERE search-condition ]
• [ ORDER BY attribute-list ]
• [ GROUP BY attribute-list ]
• [ HAVING search-condition ]
Clauses enclosed by brackets [ ] are optional.

Building Expressions
The POM enquiry system APIs contain a list of functions that can be used to build
expressions. They are shown in table 9-1.
Table 9-1. POM Enquiry Functions

Function Description
POM_enquiry_set_attr_expr This is the recommended way for creating
expressions on class.attr. It is used as follows:
Create a type value:
POM_enquiry_set_type_value (enqid, valid,
n_values, values, property); here property can
be either POM_enquiry_const_value or
POM_enquiry_bind_value.
Create the expression:
POM_enquiry_set_attr_expr (enqid,
exprid, class, attr, operator, valid)
valid cannot be NULL. If the right hand
side of the expression is NULL such as
for the unary operators UPPER and
LOWER, then you must create (char
*valid="").
POM_enquiry_set_type_expr This is a convenient function that avoids the
need to create a value. It is used as follows:
POM_enquiry_set_type_expr (enqid, exprid,
class, attr, operator, type, value)
type must be the type of the attribute in question.
type can be: int, double, char, string, logical,
tag_t, date_t. In the case of tag_t and date_t, the
function name is POM_enquiry_set_tag_expr
and POM_enquiry_set_date_expr. However,
this function cannot be used to create expressions
on class.attr where the class has no associated
database table (such POM_system_class). Use
the POM_enquiry_set_attr_expr function
instead.

Table 9-1. POM Enquiry Functions

Function Description
POM_enquiry_set_expr This function is used to combine two expressions
into one. For example, - expr1 OR expr2, expr1
AND expr2. - UPPER ( SUBSTR ( A, 1,14 )).
- expr1 theta-op expr2 where theta-op can be:
=,>,>=,<,<=.... ( a+b)*c.
If you have an expression like
the following: (class.attr1 +
class.attr2)/class.attr3 in the
select-clause, you need to add an
expression to the where-clause as
follows: ( (class.attr3 > 0) AND
(class.attr3 IS NOT NULL)).
Practical Example
For example, if you want to find the name and type of all objects created since March
8, 2005, the SQL statement is:
SELECT object_name, object_type FROM WorkspaceObject WHERE creation_date >=
08-Mar-2005 00:00
The POM enquiry APIs required to create this query are shown in figure 9-10:

void ***report;
int n_rows, n_cols, row, column;
const char *select_attr_list[] = { "object_name", "object_type"};
date_t aDate;
ITK_string_to_date("08-Mar-2005 00:00", &aDate);
/*create a query*/
POM_enquiry_create("aEnqId");
/*add the list to the select clause of the query*/

POM_enquiry_add_select_attrs("aEnqId", "WorkspaceObject", 2, select_attr_list);
/*create a date value object.*/

POM_enquiry_set_date_value("aEnqId", "aValId", 1, &aDate,
POM_enquiry_bind_value);
/* create an expression for pcreation_date = Date using the value "aValId" */

POM_enquiry_set_attr_expr("aEnqId", "aExpId", "WorkspaceObject",
"creation_date", POM_enquiry_greater_than_or_eq, "aValId");
/*set the where clause search condition.*/

POM_enquiry_set_where_expr( "aEnqId", "aExpId"));
/*execute the query*/

POM_enquiry_execute("aEnqId", &n_rows, &n_cols, &report);
for (row = 0; row < n_rows; row++)

{
for (column = 0; column < n_cols; column++)
printf("%s\t", report[row][column]);
printf("\n");
}
Figure 9-10. Practical Example

Data in the report variable can be read as report[i][j] where i is the row and j
is the column.
As can be seen from the above example, the FROM clause was not defined. It is
automatically derived from the other clauses of the query.
SELECT Clause
The SELECT list of an SQL statement consists of a list of attributes and expressions.
The operator of the expression must be a valid one supported by the RDBMS in use.
The following are supported: +, -, /, *, substr, upper, lower, contact, to_number,
to_date, cpid_of, uid_of, max, min, avg, count all, count distinct, and sum.
Refer to table 9-2 below for valid token names supported by the enquiry system.
For example, if you want to find all the objects created by the users Ahmed, Hewat
and James, the SQL statement would be:
SELECT pa.object_name,pr.user_name FROM pom_application_object pa, user ur,
person pr WHERE ur.person = pr.puid and pr.puid = pa.puid and
pr.user_name in (’Ahmed’,’Hewat’,’James’)
The POM enquiry APIs required to create this query are as follows:
As can be seen from the above SQL statement, the object_name and user_name
attributes do not belong to the same class. Therefore we need to call the
POM_enquiry_add_select_attrs function twice, as shown in figure 9-11.

/*create variables for POM_enquiry_execute*/

int rows,cols;
void *** report;
/* Create a query*/
POM_enquiry_create ("a_unique_query_id")
/*create two variables called select_attr_list1 and select_attr_list2 */

const char * select_attr_list1[] = { "object_name"};
const char * select_attr_list2[] = { "user_name" };
/*create a variable value_list */
const char * value_list[] = {"Ahmed","Hewat", "James"};
POM_enquiry_add_select_attrs ( "a_unique_query_id", "pom_application_object", 1,

select_attr_list1 );
POM_enquiry_add_select_attrs ( "a_unique_query_id", "person", 1, select_attr_list2
);
/*Create the join expr ur.rpersonu = pr.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_1","user","person",
POM_enquiry_equal,"person","puid"
);
/*Create the join expr pr.puid = pa.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_2","person","puid",
POM_enquiry_equal,"pom_application_object","puid"
);
/*Create a tag value.*/

POM_enquiry_set_string_value ( "a_unique_query_id", "aunique_value_id", 3, value_list,
POM_enquiry_bind_value );
/*Create the expression user_name in (’Ahmed’,’Hewat’,’James’).*/

POM_enquiry_create_attr_expr ( "a_unique_query_id","auniqueExprId_3", "person",
"user_name",
POM_enquiry_in, "aunique_value_id" );
/*Combine the expr_1 and expr_2 using AND.*/

POM_enquiry_set_expr ( "a_unique_query_id","auniqueExprId_4", "auniqueExprId_1",
POM_enquiry_and, "auniqueExprId_2" );

/*Set the where clause of the query*/

POM_enquiry_set_where_expr ( "a_unique_query_id","auniqueExprId_5" );
/*Execute the query.*/

POM_enquiry_execute ( "a_unique_query_id",&row,&cols,&report);
/*Delete the query*/

POM_enquiry_delete ( "a_unique_query_id" );
Figure 9-11. SELECT POM Enquiry APIs

Notice that the POM_enquiry_bind_value token specifies that the query can be
rerun with different values without the need to re-evaluate the query. Also by using
bind variables, you are telling the database server to cache the plan of the execution
of the SQL statement which saves time.
FROM Clause
The FROM clause of the query is automatically generated.

WHERE Clause
The WHERE clause of a query restricts the result to only those rows that verify
the condition supplied.
For example, if you want to find the name and type of all objects created between
date1 and date2, the SQL statement is:
SELECT object_name,object_type FROM pom_application_object WHERE creation_date
BETWEEN date1 and date2

int rows,cols;
void *** report;
/*create a query*/
POM_enquiry_create ("a unique query id")
/*create a variable called select-attr_list*/

const char * select_attr_list[] = { "object_name","object_type"};
/*add the list to the select clause of the query*/

POM_enquiry_add_select_attrs ("a unique query id" , "pom_application_object", 2 ,
select_attr_list );
/*create two date_t variables.*/

const date_t aDate1;
const date_t aDate2;
const date_t date_list[2];
/*initialize adate1. */
aDate1.day = day1; aDate1.month = month1; aDate1.year = year1; aDate1.hours = 0;
aDate1.minutes = 0;
aDate1.seconds = 0;
/*initialize adate2. */
aDate2.day = day2; aDate2.month = month2; aDate2.year = year2; aDate2.hours = 0;
aDate2.minutes = 0;
aDate2.seconds = 0;
date_list[0]=aDate1;
date_list[1]=aDate2;
/*create a date value object.*/

POM_enquiry_set_date_value ("a unique query id" , "auniquevalueId", 2 , date_list
, POM_enquiry_bind_value );
/*create an expression for pcreation_date between aDate1 and aDate2 using the value
"auniquevalueId"*/
POM_enquiry_set_attr_expr ("a unique query id","auniqueExprId","pom_application_object",
"creation_date",POM_enquiry_between,"auniquevalueId");
/*set the where clause search condition.*/

POM_enquiry_set_where_expr ( "a unique query id","auniqueExprId");
/*execute the query*/

POM_enquiry_execute ( "a unique query id",&row,&cols,&report);

Figure 9-12. WHERE POM Enquiry APIs

ORDER BY Clause
The ORDER BY list of an SQL statement consists of a list of attributes and

expressions. The operator of the expression must be a valid one supported by the
RDBMS in use.
Refer to table 9-2 below for valid token names supported by the enquiry system.
For example, if you want to find all the objects created by the users Ahmed, Hewat
and James ordered by the user_name attribute, the SQL statement is:
SELECT pa.pobject_name,pr.user_name FROM ppom_application_object pa, puser ur,
pperson pr WHERE ur.rpersonu = pr.puid and pr.puid = pa.puid and pr.puser_name
in (’Ahmed’,’Hewat’,’James’) ORDER BY user_name
As can be seen from the above SQL statement, the object_name and user_name
attributes do not belong to the same class, therefore you need to call the
POM_enquiry_add_select_attrs function twice. The POM enquiry APIs required
to create this query are shown in figure 9-13.

int rows,cols;
void *** report;
/* Create a query*/
/*create two variables called select_attr_list1 and select_attr_list2 */

const char * select_attr_list1[] = { "object_name"};
const char * select_attr_list2[] = { "user_name" };
/*create a variable value_list */
const char * value_list[] = {"Ahmed","Hewat", "James"};
POM_enquiry_add_select_attrs ( "a_unique_query_id", "pom_application_object", 1,

select_attr_list1 );
POM_enquiry_add_select_attrs ( "a_unique_query_id", "person", 1, select_attr_list2
);
/*Create the join expr ur.rpersonu = pr.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_1","user","person",
POM_enquiry_equal,"person","puid"
);
/*Create the join expr pr.puid = pa.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_2","person","puid",
POM_enquiry_equal,"pom_application_object","puid"
);
/*Create a tag value.*/

POM_enquiry_set_string_value ( "a_unique_query_id", "aunique_value_id", 3, value_list,
POM_enquiry_bind_value );
/*Create the expression user_name in (’Ahmed’,’Hewat’,’James’).*/

POM_enquiry_create_attr_expr ( "a_unique_query_id","auniqueExprId_3", "person",
"user_name",
POM_enquiry_in, "aunique_value_id" );

Figure 9-13. ORDER BY POM Enquiry APIs (Continued)



/*set the order by clause.*/

POM_enquiry_add_order_attr ( "a_unique_query_id","Person","user_name",
POM_enquiry_asc_order
);


Figure 9-13. ORDER BY POM Enquiry APIs

GROUP BY Clause
This the same as the ORDER BY clause except for the sorting
order. Just replace the POM_enquiry_add_order_attr
function with the POM_enquiry_add_group_attr function
and the POM_enquiry_add_order_expr function with the
POM_enquiry_add_group_expr function.
HAVING Clause
This is the same as the WHERE clause. Replace the

POM_enquiry_set_where_expr function with the
POM_enquiry_set_having_expr function.
Subqueries
For example, if you want to find the list of folders whose contents attribute contains
a UGMASTER type dataset, the SQL statement is:
SELECT f1.puid FROM folder f1 WHERE f1.contents in ( SELECT ds.puid FROM
dataset ds WHERE ds.object_type = ’UGMASTER’ );


int rows,cols;
void *** report;
/*create a variable select_attr_list */

const char * select_attr_list[] = {"puid"};
/* Create a query*/
As can be seen from the above pseudo-SQL statement contains a subquery.

Hence the need for creating one.
/*Create a subquery.*/
POM_enquiry_set_sub_enquiry ( "a_unique_query_id", "subquery_unique_id" );
/* select the puid from Folder class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "Folder", 1, select_attr_list
);
/* select the puid from Dataset class.*/

POM_enquiry_add_select_attrs ( "subquery_unique_id", "Dataset", 1, select_attr_list
);
/*Create the expr ds.type = ’UGMASTER’.*/

POM_enquiry_set_string_expr ("subquery_unique_id","auniqueExprId_1","Dataset",
"object_type",POM_enquiry_equal,"UGMASTER"
);
/*Set the subquery where clause.*/

POM_enquiry_set_where_expr ( "subquery_unique_id","auniqueExprId_1" );
/*Create the expr f1.contents in subquery.*/

POM_enquiry_set_attr_expr ("a_unique_query_id","auniqueExprId_2","Folder","contents",
POM_enquiry_in,"subquery_unique_id"
);
/*Set the outer query where clause.*/

/*Execute the outer query.*/


Figure 9-14. Subquery POM Enquiry APIs

The POM_enquiry_in function can be replaced by

the POM_enquiry_not_in, POM_enquiry_exists, or
POM_enquiry_not_exists function.
For IN, NOT IN, EXISTS and NOT EXISTS operators, see your RDBMS reference
manual.
Use of class_alias
For example, if you want to find the list of folders whose contents attribute contains
a folder of type ’override’ and its contents has an item revision X, the pseudo-SQL is:
select f1.puid from folder f1,folder f2, item_revision itr where f1.contents
= f2.puid and f2.type = ’override’ and f2.contents = itr.puid and
itr.object_name = ’X’;
The folder class appears twice in the from clause and therefore needs a class alias.
The POM enquiry APIs required to create this query are shown in figure 9-15.


int rows,cols;
void *** report;

/* Create a query*/
/*Create a class alias for the Folder class.*/

POM_enquiry_create_class_alias ( "a_unique_query_id", "Folder",1,"Folder_alias");
/* select the puid from Folder class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "Folder", 1, select_attr_list
);
/*Create the join expr f1.contents = f2.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_1","Folder","contents",
POM_enquiry_equal,"Folder_alias","puid"
);
/*Create the expr f2.type = ’override’.*/

POM_enquiry_set_string_expr ("a_unique_query_id","auniqueExprId_2","Folder_alias","type",
POM_enquiry_equal,"override"
);
/*Create the join expr f2.contents = itr.puid*/

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_3","Folder_alias",
"contents",POM_enquiry_equal,"Item_revision","puid"
);
/*Create the expr itr.object_name = ’X’.*/

POM_enquiry_set_string_expr ("a_unique_query_id","auniqueExprId_4","Folder_alias",
"object_name",POM_enquiry_equal,"X"
);






Figure 9-15. class_alias POM Enquiry APIs

Use of pseudo_class
For example, if you want to find the latest released version of the dataset ’X’, the
pseudo-SQL is:
select ds.puid from dataset ds, revisionAnchor rva where ds.rev_chain_anchor
= rva.puid and rva.revisions.PSEQ = 0 and ds.object_name = ’X’
The PSEQ attribute in the where clause is not a POM_attribute and the ’revisions’
is not a POM_class. Since the only classes you are allowed to query on are
POM_classes, you have to convert the revisions attribute of the revisionAnchor
into a POM_class. To do this, create a pseudo-class on the attribute revisions of
the revisionAnchor.
You can only create pseudo-classes for VLAs or LAs attributes.

/* Create variables for POM_enquiry_execute*/

int rows,cols;
void *** report;
/* Create a variable select_attr_list */

/* Create a variable int_val=0*/
const int int_val = 0;
/* Create a query*/
/* Create a pseudo-class for the revisionAnchor.revisions attribute.*/

POM_enquiry_set_pseudo_calias ( "a_unique_query_id", "RevisionAnchor","revisions",
"class_revisions");
/* Select the puid from Dataset class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "Dataset", 1, select_attr_list);
/* Create the expr rva.revisons.pseq = 0.*/

/* First create an int value.*/
POM_enquiry_set_int_value ( "a_unique_query_id","auniqueValueId", 1, &int_val,
POM_enquiry_bind_value
);
POM_enquiry_set_attr_expr ("a_unique_query_id","auniqueExprId_1","class_revisions","pseq",
POM_enquiry_equal,"auniqueValueId"
);
/* NOTICE: the ’pseq’ attribute is reserved keyword in iMAN/POM, it can be used as an

attribute of the pseudo-class. The same
apply to pval and puid. */
/* Create the expr ds.object_name = ’X’.*/

POM_enquiry_set_string_expr ("a_unique_query_id","auniqueExprId_2","Dataset",
"object_name",POM_enquiry_equal,"X"
);
/* Create the join expr ds.rev_chain_anchor = rva.puid */

POM_enquiry_set_join_expr ("a_unique_query_id","auniqueExprId_3","Dataset",
"rev_chain_anchor",POM_enquiry_equal,"revisionAnchor","puid");
/* Combine the expr_1 and expr_2 using AND.*/

/* Combine the expr_3 and expr_4 using AND.*/

/* Set the where clause of the query*/

/* Execute the query.*/

/* Delete the query*/

Figure 9-16. pseudo_class POM Enquiry APIs

Use of Set-Expression
INTERSECTION
For example, if you want to find all the objects that are common to two folders,
the pseudo SQL is as follows:
select f1.contents from folder f1 where f1.object_name=’Compare’ INTERSECTION
select f2.contents from folder f2 where f2.object_name=’Reference’
The pseudo SQL consists of two queries that are combined by the INTERSECTION
set operator. In this case, one of the queries must be the outer query and the other
one must be scoped to it. Therefore, the non-outer query must be created as a
subquery of the outer one.
/* Create variables for POM_enquiry_execute*/

int rows,cols;
void *** report;

const char * select_attr_list[] = {"contents"};
/* Create a query*/
/* Select the contents from Folder class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "Folder", 1, select_attr_list );
/* Now limit it to just the folder we want to see */

/* Folder names are not always unique so for a real example you should */
/* use the tag of the folder */
POM_enquiry_set_string_expr ("a_unique_query_id","auniqueExprId_1","Folder", "object_name",
POM_enquiry_equal, "Compare" );
/* Set the outer query where clause.*/

/* POM implements set queries as subqueries and so we need to create one */

/* Create a class alias for the Folder class. The folder class is appearing twice - once */
/* in the outer query and the other time in the subquery. */
POM_enquiry_create_class_alias ( "subquery_unique_id", "Folder",1,"Folder_alias");
/* Select the contents from other folder.*/

POM_enquiry_add_select_attrs ( "subquery_unique_id", "Folder_alias", 1, select_attr_list);
"object_name", POM_enquiry_equal, "Reference" );
/* Set the subquery where clause.*/

/* Add the set expression */

POM_enquiry_set_setexpr ("a_unique_query_id”, POM_enquiry_intersection, "subquery_unique_id");
/* Execute the outer query.*/

POM_enquiry_execute ( "a_unique_query_id",&row, &cols, &report);
Figure 9-17. Set-Expression INTERSECTION POM Enquiry APIs

DIFFERENCE
For example, if you want to find all the objects that are in a reference folder that do
not exist in a named folder, the pseudo SQL is:
select f1.contents from folder f1 where f1.object_name=’Reference’ DIFFERENCE
select f2.contents from folder f2 where f2.object_name=’Compare’
The pseudo SQL consists of two queries that are combined by the DIFFERENCE
set operator. In this case, one of the queries must be the outer query and the other
one must be scoped to it. Therefore, the non-outer query must be created as a
subquery of the outer one.

int rows,cols;
void *** report;

/* Create a query*/
/* select the contents from Folder class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "Folder", 1, select_attr_list );
/* Now limit it to just the folder we want to see */

/* Folder names are not always unique so for a real example you should */
/* use the tag of the folder */
POM_enquiry_set_string_expr ("a_unique_query_id","auniqueExprId_1","Folder", "object_name",
POM_enquiry_equal, "Reference" );
/*Set the outer query where clause.*/

/* POM implements set queries as subqueries and so we need to create one */

/* Create a class alias for the Folder class. The folder class is appearing twice - once */
/* in the outer query and the other time in the subquery. */
POM_enquiry_create_class_alias ( "subquery_unique_id", "Folder",1,"Folder_alias");
/* select the contents from other folder.*/

POM_enquiry_add_select_attrs ( "subquery_unique_id", "Folder_alias", 1, select_attr_list);
"object_name", POM_enquiry_equal, "Compare" );
/*Set the subquery where clause.*/

/* Add the set expression */

POM_enquiry_set_setexpr ("a_unique_query_id”, POM_enquiry_difference, "subquery_unique_id");
/*Execute the outer query.*/

POM_enquiry_execute ( "a_unique_query_id", &row, &cols, &report);
Figure 9-18. Set-Expression DIFFERENCE POM Enquiry APIs

UNION
For example, you have two forms: FORM1 and FORM2. FORM1 is an engineering
type form that has two attributes: weight and material. FORM2 is a production
type form and has two attributes: cost and effectivity_date.
If you want to find all engineering type objects that weigh more than wt1 and all
production type objects that cost less than cost1, the pseudo SQL is:
Select f1.puid From FORM1 Where f1.type = ’engineering’ And f1.weight > wt1
UNION Select f2.puid From FORM2 Where f2.type = ’Production’ And
f2.cost < cost1

/* create variables for POM_enquiry_execute*/

int rows,cols;
void *** report;

/* Create a query*/
/* Select the puid from FORM1 class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "form1", 1, select_attr_list);
/* Create the expr f1.type = ’engineering’*/

POM_enquiry_set_string_expr ( "a_unique_query_id","auniqueExprId_1","form1","object_type",
POM_enquiry_equal,"engineering");
/* Create the expr f1.weight > wt1*/

POM_enquiry_set_double_expr ( "a_unique_query_id","auniqueExprId_2","form1","weight",
POM_enquiry_greater_than,wt1);
/* Combine expr1 and expr2 using AND operator.*/

POM_enquiry_set_expr ( "a_unique_query_id", "auniqueExprId_3", "auniqueExprId_1",
POM_enquiry_and,"auniqueExprId_2" );
/* Set the where clause of the outer query*/

/* Create a subquery*/
POM_enquiry_set_sub_enquiry ("a_unique_query_id", "subquery_unique_id" )
/* Select the puid from FORM2 class.*/

POM_enquiry_add_select_attrs ( "subquery_unique_id", "form2", 1, select_attr_list
);
/* Create the expr f2.cost <cost1*/

POM_enquiry_set_double_expr ( "subquery_unique_id","auniqueExprId_5","form2",
"cost",POM_enquiry_less_than,cost1 );
/* Combine expr4 and expr5 using AND operator.*/

POM_enquiry_set_expr ( "subquery_unique_id", "auniqueExprId_6", "auniqueExprId_4",
/* Set the where clause of the subquery*/

/* Now we need to set the set-expression of the outer query. */

POM_enquiry_set_setexpr ( "a_unique_query_id" ,"setexpr",POM_enquiry_union ,
"subquery_unique_id" );
/* Execute the query.*/


Figure 9-19. Set-Expression UNION POM Enquiry APIs

Special Operators
POM_enquiry_substr
If you want to create the expression SUBSTR (item.desc,1,5)=’blob’, you can use
the enquiry APIs as shown in figure 9-20.
/*Create a variable int_list*/

const int int_list[]={1,5};
/*Create a string variable*/

const char *str_list[]={"blob"};
/* First we nned to create an int value:*/

POM_enquiry_set_int_value ( "a_unique_query_id","auniqueValueId_1",1,int_list,
POM_enquiry_const_value);
/* Create the expression SUBSTR ( item.desc, 1,5) using the int value.*/
POM_enquiry_set_attr_expr ( "a_unique_query_id", "auniqueExprId_1","item","desc",
POM_enquiry_substr,"auniqueValueId_1")
/* Create a string value = ’blob’.*/

POM_enquiry_set_int_value ( "a_unique_query_id","auniqueValueId_2",1,str_list,
/* Create the expression SUBSTR ( item.desc, 1,5) = ’blob’.*/

POM_enquiry_equal, "auniqueValueId_2");
Figure 9-20. SUBSTR POM Enquiry APIs
POM_enquiry_cpid_of
For example, if you want to find all the dataset objects of a folder, the pseudo SQL is:
Select contents From Folder Where cpid_of ( contents ) = dataset cpid
The way to implement this query in the old query system is to use a join between
dataset and folder contents. To avoid the performance penalty of using the join, you
can use the POM_enquiry_cpid_of special operator.
POM_enquiry_cpid_of can only be used with typed or untyped_reference
type attributes.

Figure 9-21 shows how to do this.
/*Find the cpid of dataset class by using:*/

POM_class_id_of_class ("dataset",&classid );
POM_class_to_cpid ( classid, &cpid );

int rows,cols;
void *** report;

/* Create a query*/
/* select the puid from folder class.*/

POM_enquiry_add_select_attrs ( "a_unique_query_id", "folder", 1, select_attr_list);
/*create an int value*/

POM_enquiry_set_int_value ( "a_unique_query_id", "auniqueValueId_1", 1, &cpid,
/* Create the expression cpid_of( contents ).*/

POM_enquiry_set_attr_expr ( "a_unique_query_id", "auniqueExprId_1", "folder", "contents",
POM_enquiry_cpid_of, "" );
/*Set the expression cpid_of ( contents ) = dataset cpid.*/

POM_enquiry_set_expr ( "a_unique_query_id", "auniqueExprId_2","auniqueExprId_1",
POM_enquiry_equal,"auniqueValueId");



Figure 9-21. cpid POM Enquiry APIs

POM_enquiry_upper and POM_enquiry_lower
If you want to create the expression UPPER(item.desc )= UPPER(’blob’), you can

use the enquiry APIs as shown in figure 9-22.
/*Create a string variable*/

const char *str_list[]={’blob’};
/* Create the expression UPPER( item.desc).*/

POM_enquiry_set_attr_expr ( "a_unique_query_id", "auniqueExprId_1","item","desc",
POM_enquiry_upper,"")
/* Create a string value = ’blob’.*/

POM_enquiry_set_int_value ( "a_unique_query_id","auniqueValueId_2",1,str_list,
/* Create the expression UPPER( item.desc) = UPPER(’blob’).*/

POM_enquiry_equal, "auniqueValueId_2");
Figure 9-22. UPPER and LOWER POM Enquiry APIs

When you apply the upper or lower operator to the left hand side of an
expression, the operator is applied automatically to the right hand side of
the expression.

POM_enquiry_countdist
If you want to create the expression COUNT(DISTINCT item.puid ), you can use
the enquiry APIs as shown in figure 9-23
/* Create the expression COUNT(DISTINCT item.desc).*/

POM_enquiry_set_attr_expr ( "a_unique_query_id", "auniqueExprId_1","item","puid",
POM_enquiry_countdist,"")
Figure 9-23. COUNT POM Enquiry APIs

You cannot use count ( * ). Instead use COUNT ( ALL class.puid )
by using the POM_enquiry_countall. To return only the number of
distinct rows, use COUNT (DISTINCT class.puid ), by using the
POM_enquiry_countdist.
The same apply to MAX, MIN, AVG, and SUM except that these apply to different
attributes of the class, not the puid.
POM_enquiry_in and POM_enquiry_not_in
These operators can be used either with a subquery or a list of values. Oracle
imposes some restrictions on the number of values allowed in the in-list when using
bind variables. These are:
• The number of bind values is limited to 254.
• If you create a query with more than MAX_BIND_VALUE bind variables, the
new query system converts the bind values into constants and construct a query
that can be successfully executed. However, the SQL statement is not cached
and therefore risks flooding the System Global Area (SGA).

Supported Operators
Table 9-2 shows the operators that are supported in the POM enquiry module.
Table 9-2. Supported Operators

Where it
Can Be
Operator Left Right Used
POM_enquiry_or expr expr WH
POM_enquiry_and expr expr WH
POM_enquiry_equal attr/expr expr/value WH
POM_enquiry_not_equal attr/expr expr/value WH
POM_enquiry_greater_than attr/expr expr/value WH
POM_enquiry_greater_than_ attr/expr expr/value WH
or_eq
POM_enquiry_less_than attr/expr expr/value WH
POM_enquiry_less_than_or_eq attr/expr expr/value WH
POM_enquiry_between attr/expr expr/value WH
POM_enquiry_not_between attr/expr expr/value WH
POM_enquiry_in attr/expr value/ WH
subquery
POM_enquiry_not_in attr/expr value/ WH
subquery
POM_enquiry_exists attr/expr subquery WH
POM_enquiry_not_exists attr/expr subquery WH
POM_enquiry_like attr/expr value WH
POM_enquiry_not_like attr/expr value WH
POM_enquiry_union query query -
POM_enquiry_difference query query -
POM_enquiry_intersection query query -
POM_enquiry_countdist attr null SH
POM_enquiry_countall attr null SH
POM_enquiry_max attr null SH
POM_enquiry_min attr null SH
POM_enquiry_avg attr null SH
POM_enquiry_sum attr null SH
POM_enquiry_plus attr/expr attr/expr/ SW
value
POM_enquiry_minus attr/expr attr/expr/ SW
value

Table 9-2. Supported Operators

Where it
Can Be
Operator Left Right Used
POM_enquiry_divide attr/expr attr/expr/ SW
value
POM_enquiry_multiply attr/expr attr/expr/ SW
value
POM_enquiry_substr attr/expr value SW
POM_enquiry_upper attr/expr null SW
POM_enquiry_lower attr/expr null SW
POM_enquiry_ascii attr/expr null SW
POM_enquiry_concat attr/expr S
POM_enquiry_ltrim attr/expr null SW
POM_enquiry_rtrim attr/expr null SW
POM_enquiry_length attr/expr null SW
POM_enquiry_is_null attr/expr null W
POM_enquiry_is_not_null attr/expr null W
POM_enquiry_uid_of attr null W
POM_enquiry_cpid_of attr null W
POM_enquiry_tonumber attr null W
POM_enquiry_todate attr null W
POM_array_length_equals attr null W
POM_array_length_not_equals attr null W
SWH means [S]elect [W]here [H]aving clauses and [-] means the operator is
applied to the outer query.

Use of POM Load by Enquiry

The POM can load the objects returned by a query. This has a number of benefits:
• If you want to load all the objects returned by a query, you can make just one call
which both executes the query and loads the objects.
• The loading of objects is more efficient than a normal POM_load_instances (or

loadInstances in CXPOM) and results in fewer SQL trips.
To use this functionality, follow the steps below:

1. Make sure all the objects you want returned are of the same class. The POM
does not support loading objects of different classes using this method.
2. Create the enquiry as described above ensuring you have only one SELECT
attribute, the puid of the class you want to load. You can order the results as
long as you are ordering by one of the attributes of the class you are loading.
3. Call the POM_load_instances_possible_by_enquiry function and pass in

the name of the enquiry and the class you want to load instances of. Output
values are two arrays of objects, one for the objects the POM was able to load
and the other for those that the POM failed to load because of Access Manager
rules or a consistency check failure.

Chapter
10 Workflow
Enterprise Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
EPM Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Action Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Predefined Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Defining Your Own Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
State Transition Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Business Rule Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Customizing a Procedure With EPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

Writing Your Own Action Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Steps to Follow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Action Handler Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Writing Your Own Rule Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
EPM_decision_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
EPM_rule_message_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Steps to follow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Rule Handler Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Registering Rule Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
Using Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
Validation Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Validation Rule APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17
EPM Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18

Perform Action Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18
Avoiding Infinite Loops in Perform Actions . . . . . . . . . . . . . . . . . . . . . . 10-18
Inbox Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
Cascade Release Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

Customizing Procedures With CR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Serial and Parallel Tasks in CR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21
Sending Mail After Signoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21

Chapter
10 Workflow
This chapter describes the Enterprise Process Modeling (EPM) module and the
Cascade Release (CR) application.
This section describes how to customize a procedure using the Enterprise Process
Modeling (EPM) module. The Cascade Release (CR) application is also discussed
as an illustration of a customized procedure. The bulk of the descriptions center on
EPM since CR is one example of how to use EPM. CR provides you with a canned
release authorization mechanism. This section introduces the object model for EPM,
state transitions, and the relationship between the interactive dialog window and
the areas that require programming to meet site-specific requirements.
Enterprise Process Modeling

The EPM module is a tool designed to facilitate the specification of processes
(procedures), resources, and data constrained by a company’s business rules. A
typical product information management (PIM) system can be viewed as a process
model consisting of procedures to be performed in a well defined sequence; a resource
model which addresses the users, groups, roles and applications a business uses;
and the data model which addresses the different types of data used to run the
business’s computer-aided applications. The company’s business rules determine
how the three models interact with one another. EPM addresses the procedures
portion of this model.
A procedure can be viewed as a task or group of tasks which, when performed in a
certain sequence with defined resources and rules, produces a defined output. The
fundamental element of a procedure is a task. Figure 10-1 shows a model of this.
Figure 10-1. Task Model

EPM was designed to support this model. EPM contains analogs to all the elements
of the task model shown above. The relationships are shown in figure 10-2.

Chapter 10 Workflow
Figure 10-2. Task Model Table

A task is always in some state and it can change from one state to another by
successfully performing an action. An action may have pre-conditions and business
rules imposed on it. Any of the imposed business rules must be satisfied before
the proposed action can be performed.
A business rule is a statement of some constraint on the performance of an action.
It may be derived from empirical data and knowledge or other procedures. Tasks
consume resources to produce outputs which, in EPM, are associated to the task by
attachments. Each of the EPM elements is discussed in more detail in the next
section.
EPM Object Model

EPM is comprised of the following components:
• Job
• Task
• Action
• Attachment
• Business rule
Figure 10-3 is a graphical representation of the EPM object model:
Figure 10-3. EPM Object Model
Jobs
A job is the runtime instantiation of a procedure. It is a collection of tasks just as
a procedure is a collection of task definitions. A procedure is the system definition
of a business process. Procedures are defined interactively through the Procedures
dialog window. You can instantiate a procedure and create a job programmatically
using the EPM_create_job function.

Workflow
Tasks
A task is a rudimentary element in our process model. Data is associated to it and
some action can be performed on it based upon a specific business rule. It is an
instance of a task definition. Just as task definitions make up a procedure, tasks
make up a job during runtime. Subtasks can also make up a task to form an
hierarchy of tasks.
You can use the EPM_ask_sub_tasks function to find the subtasks associated with
a certain task. Similarly, you can use the EPM_ask_sub_task function to find
one subtask attached to a task.
If you want to go up the hierarchy of tasks to find the parent of a given task, use the
EPM_ask_parent function. Use the EPM_ask_root_task function to get to the top
of the task hierarchy. To find out what tasks are assigned to a certain responsible
party, use EPM_ask_assigned_tasks.
The EPM_ask_description function is also available to get a short description of
a task in a character array. If you just want the name of the current task, use the
EPM_ask_name function to get a character array containing the name of the task.
Action Handlers
Action handlers are routines that act as the mechanism of the action to which
they are associated. The association between an action and handlers is defined
interactively in the Task Definition dialog window.
Actions can be either displayed during runtime or triggered programmatically. To
display the action string of the current action applied to a task during runtime, use
the EPM_task_action_string function. To trigger actions programmatically, use
the EPM_trigger_action function to trigger an action in a specific task. This is
useful in triggering a parallel task to start.
After writing your own handlers, you need to register them to the system using the
EPM_register_action_handler function. This makes the handler available for
use by the system administrator in implementing EPM procedures. The system
administrator can enable the system to find your custom handler and execute it
whenever the action with which the handler was associated is invoked on a task.

Chapter 10 Workflow
Predefined Actions
EPM comes with predefined actions that can occur on any task. These predefined
actions are as follows:
Assign Assigns a user or group to perform the work.

Start Starts a task if it has not been started.
Complete Marks a task as being completed.
Skip For a given job, skips this sub-task, but marks it complete for all
other tasks that depend on it being completed before they can start.
Suspend Suspends all work on this task until further notice.
Resume Resumes the task to the state it was in before it was suspended.
Perform Executes user-defined action handlers any time the user wishes.
These do not change the state of the task.
Defining Your Own Actions
You can define your own actions by modifying the iman_text.uil file in the
IMAN_ROOT/lang/ directory. For example, if you want to add the Mail action, you
need to add the following line to the iman_text.uil file:
EPM_action_1001 : exported "Mail"
The value of the number in the EPM_action_number line must be greater than
1000 because EPM_user_action is defined to be 1000 in the epm.h file. Compile
the iman_text.uil file using the UIL compiler after you finish your modification.
For maintainability, you might also want to define a MAIL macro in your local
header file. For example:
#define MAIL (EPM_user_action + 1)

Workflow
State Transitions
Some actions cause state transitions. For example, applying the Assign action to
a task that is in the Unassigned state causes a state transition to the Pending
state. Applying the Start action causes a state transition from Pending to Started.
Applying the Complete action can cause a state transition from Started to
Completed.
As the action handlers are executed, the task keeps track of its progress by setting
an attribute called state. You can inquire about the state of a task using the
EPM_ask_state function. Next use EPM_ask_state_string to get the string value
of the state. Possible states that a task can take are as follows:
• Unassigned
• Pending
• Started
• Completed
• Skipped
• Suspended
State Transition Example
As an example of using state transitions, assume that our task is to do circuit

analysis on a circuit design. During the circuit analysis procedure definition we
associate rule and action handlers with the Start action, the Perform action and
the Complete action of our task.
The Start action has rule handlers to check that all the files required for analysis
are present. The rule handlers associated with the Complete action check to
make sure the Perform action is invoked. The Perform action is where the actual
analysis program is called by an associated action handler.
The initial state of the task is Unassigned. To start the task, we initiate a job
in the workspace using the circuit analysis procedure. The Assign action of the
task is invoked automatically. If the assignment action is successful, the task state
transitions from Unassigned to Pending and the Start action is invoked. The
business rule handlers associated with the Start action are then executed.
Assuming that the files required for analysis are all present, there is rule compliance
with the Start action; therefore the task state transitions from Pending to Started.
EPM invokes the Complete action automatically. Since the Perform action has
not been invoked, there is no rule compliance in the Complete action; hence state
transition from Started to Complete does not occur.
Next, we invoke the Perform action and do the actual circuit analysis. Assuming
the circuit analysis is successful, we invoke the Complete action manually to finish
the job. At this point there should be rule compliance to the Complete action
business handler since the Perform action was done successfully prior to invoking
the Complete action. The task state then transitions from Started to Completed.

Chapter 10 Workflow
Attachments
Attachments are other objects that are associated with the task during runtime.
These objects are typically items that need approval, supporting data, forms that
need to be completed for the task, and so on. There are several built-in types of
attachments. For a complete list, see the Enterprise Process Modeling section of the
Integration Toolkit Function Reference manual.
If you want task comments to display in the thin client user interface, you
must use customize your workflow using ITK.
Use the EPM_ask_all_attachments function to get an array of all attachments

regardless of task type. To get attachments of a certain type, use the
EPM_ask_attachments function, passing one of the valid attachment types as
an argument. To add an attachment to a task, use the EPM_add_attachments
function. You can remove an attachment with the EPM_remove_attachments
function.
You can also define your own attachment types. This can be done by following a
similar procedure for adding new actions. Modify the iman_text.uil file to define
the EPM_attachment_number display name. The value of number must be in the
range of 1000 to 32000 (1000 < number < 32000). For example:
EPM_attachment_1001 : Exported "ECN"
For ease of maintenance, define the ECN macro in your local header file. For
example:
#define ECN (EPM_user_attachment +1)
Business Rule Handlers

Business rule handlers are programs that check compliance to business rules
before any action handlers can be executed within an action. Like action handlers,
the association between action and rule handlers is defined interactively in
the Task Definition dialog window. There are business rule handlers available
in the system that you can readily use or you can write your own. Use the
EPM_register_rule_handler function to register the rule handlers you have
written.

Workflow
Customizing a Procedure With EPM

A procedure can be customized with EPM in several ways. The simplest method is
to associate available action or rule handlers from the toolkit to specific actions to
obtain the desired result. With this method, you do not need to write a program
or function to customize a procedure. If none of the available handlers meet your
specific needs, then you can write a custom handler using the ITK. Such a custom
handler can then be used along with the Teamcenter-provided handlers to specialize
the behavior of a task.
A handler is a small ITK function designed to accomplish a specific job. There are
two kinds of handlers: rule handlers and action handlers. Rule handlers enforce
business rules. An action handler causes something to happen and usually is
responsible for a state transition.
If the rule handler returns an EPM_go, then the action handlers are executed and a
state transition occurs. If the rule does not return EPM_go, then the action handler
does not execute and the state transition does not occur.
Writing Your Own Action Handler

Since action handler programs are essentially ITK functions, they should be written
based on the same guidelines followed in ITK programs. The epm.h header file
must be included in your source code. The standard interface for an action handler
is as follows:
int sample_handler(EPM_action_message_t message)
The EPM_action_message_t is a typedef defined as:

typedef struct EPM_action_message_s
{
tag_t task;
EPM_action_t action;
EPM_state_t proposed_state;
IMAN_argument_list_t* arguments;
tag_t data;
} EPM_action_message_t;
The fields for EPM_action_message_s are as follows:

• task
Task on which the action was triggered.
• data
System data.
• action
Action that was triggered.
• proposed_state
State that the task changes to after actions are completed without errors.

Chapter 10 Workflow
• arguments
Argument specified in the procedure.
The action handler must return an int status code that can be compared to
ITK_ok to determine if the handler was executed successfully.
Steps to Follow
With the ITK programming standards in mind, follow the steps below to create
your own action handler:
1. Write the action handler program following the standard interface mentioned
earlier and the ITK programming standards.
2. Compile your program using the compile script in the IMAN_ROOT/sample

directory. The sample compile script writes the resulting object file in the current
directory. Modify the compile script if the default behavior is not sufficient.
3. Register your new handler to the system by writing a module

initialization function (or modifying it if one already exists) to call the
EPM_register_action_handler function for the action handler you have
written. Compile the module initialization function.
Complete step 4 only if this is the first handler you are registering.
You can skip this step for the subsequent handlers that you are going
to write.
4. Modify the user_gsshell.c file in the IMAN_ROOT/sample

directory to add a call to your module initialization function in the
USER_gs_shell_init_module function. Compile the user_gsshell.c file using
the IMAN_ROOT/sample/compile script.
5. Create the user exits library with the IMAN_ROOT/sample/link_user_exits

script. This script creates the libuser_exits sharable library from all of the
object files in your current directory.
Action Handler Example
The following is an example of an action handler:

int EPM_system(EPM_action_message_t msg)
{
int err = ITK_ok;
char* arg = 0;
if(IMAN_number_of_arguments(msg.arguments)>0)
{/* get first argument */
arg = IMAN_next_argument(msg.arguments);
system(arg);
}
return err; /*return an ITK error code if an error/
occurred*/
}

Workflow
The first call to the IMAN_next_argument function gets the first argument, given
the Arguments field from the structure, specified in the task definition windows for
this handler. Each successive call to IMAN_next_argument gets the next argument
on the list. Use the IMAN_init_argument_list function to start over at the
beginning of the list and get the first argument. All action handlers should return
either ITK_ok if no error occurred or the ITK error for the error that did occur.
Writing Your Own Rule Handler

The standard interface for a business rule handler is:
EPM_decision_t sample_rule_handler/
(EPM_rule_message_t message)
EPM_decision_t
The EPM_decision_t is a user-defined type defined as:

typedef enum EPM_decision_e
{
EPM_nogo,
EPM_undecided,
EPM_go
} EPM_decision_t;
The fields for EPM_decision_t are as follows:

• EPM_nogo
Constraints for rule or rule handler are not satisfied; action and state transition
should not occur
• EPM_undecided
Still unknown whether the decision is a go or no go because of insufficient or
pending data; action and state transitions should not occur
• EPM_go
Rule or handler passed; constraints satisfied
EPM_rule_message_t
The EPM_rule_message_t is a typedef defined as:

typedef struct EPM_rule_message_s
{
tag_t task;
EPM_action_t proposed_action;
IMAN_argument_list_t* arguments;
tag_t tag;
} EPM_rule_message_t;

Chapter 10 Workflow
The fields for EPM_rule_message_t are as follows:

• task
Task on which the action was triggered
• proposed_action
Action that was triggered
• arguments
Argument specified in the procedure
• tag
System data
Steps to follow
With the ITK programming standards in mind, follow the steps below to create
your own rule handler:
1. Write the rule handler program following the standard interface mentioned
earlier and the ITK programming standards.
2. Compile your program using the compile script in the IMAN_ROOT/sample

directory. The sample compile script writes the resulting object file in the current
directory. Modify the compile script if the default behavior is not sufficient.
3. Register your new handler to the system by writing a module

initialization function (or modifying it if one already exists) to call the
EPM_register_action_handler function for the rule handler you have written.
Compile the module initialization function.
Complete step 4 only if this is the first handler you are registering.
You can skip this step for the subsequent handlers that you are going
to write.
4. Modify the user_gsshell.c file in the IMAN_ROOT/sample

directory to add a call to your module initialization function in the
USER_gs_shell_init_module function. Compile the user_gsshell.c file using
the IMAN_ROOT/sample/compile script.
5. Create the user exits library with the IMAN_ROOT/sample/link_user_exits

script. This script creates the libuser_exits sharable library from all of the
object files in your current directory.

Workflow
Rule Handler Example
The following is an example of a rule handler:

EPM_decision_t
EPM_check_responsible_party(EPM_rule_message_t msg)
{
int s;
EPM_decision_t decision = EPM_nogo;
char * userName;
tag_t aUserTag, responsibleParty;
s=EPM_ask_responsible_party(msg.task, &responsibleParty);
if (responsibleParty == NULLTAG)
{
decision = EPM_go;
}
if (s == ITK_ok && decision == EPM_nogo)
{
s = POM_get_user (&userName, &aUserTag);
MEM_free (userName);
if (s == ITK_ok)
{
if (aUserTag == responsibleParty)
decision = EPM_go;
}
}
return decision
}

Chapter 10 Workflow
Registering Rule Handlers
All rule handlers must be registered. The following example illustrates how you
would register a rule handler.
The example shown in figure 10-4 uses the USER_epm_init_module function
which registers a function called EPM_check_responsible_party through the
EPM_register_rule_handler function as the check-responsible-party handler.
When defining tasks interactively, the registered name of the
handler-check-responsible-party should be used to add the handler to an action
instead of the full name of the function, EPM_check_responsible_party.
int USER_epm_init_module()
{
int s;
s = EPM_register_rule_handler("check-responsible-party", "",
EPM_check_responsible_party);
return s;
}
Register the USER_epm_init_module() function through USER_gs_shell_init_module().

The USER_gs_shell_init_module() function exists in user_gsshell.c located in the
user_exits directory. The registration is shown as follows:
USER_gs_shell_init_module()
{
...
USER_epm_init_module();
}
Figure 10-4. Module Initialization Function Example

Compile all of the above mentioned code and create a user exits library. For more
information about creating a user exits library, see the Integration Toolkit Function
Reference manual.

Workflow
Using Validation Rules

A validation rule is an instance of a Validation Data object with the following
additional runtime attributes:
• A validation agent that can be an NX CheckMate checker.
• The dataset types where the validation agent is applicable.
• Whether the check is mandatory or optional. A mandatory check must both run
and pass. An optional check must run but does not have to pass.
• Event names where the check is applicable. When applicable event names are
specified for a validation agent (checker), the check result is verified only when
these events happen. If no event name is specified, the checker applies to all
events. The event name can contain an asterisk as a wildcard. Event names
can be marked as exclusive.
• A list of parameter and value pairs. The parameter values need to be verified
from the validation result log file.
Validation rules are defined based on your business model. In a production

environment, you can define multiple validation rule files to suit different business
processes.

Chapter 10 Workflow
Validation Rule File
Validation rules can be defined in an XML file called a validation rule file. A
validation rule file defines all validation rules for a validation rule set. Follow these
guidelines when you create a validation rule file:
• The Rule_Set tag attributes name, description, user, and date are
mandatory. These attributes are mapped as Teamcenter validation rule set
object attributes when the XML rule set is imported.
• The Rule tag defines a rule.

– Checker tag
This tag is mandatory. Its name attribute is the checker class name, not
the display name.
– Mandated tag
This tag is mandatory. If a check is mandatory (the check must run and
pass), type yes between the opening and closing tag. If not, type no. When a
check is not mandatory, the check must run, but the result status is ignored.
– Datasets tag
This tag is mandatory. You must define the list of applicable dataset types.
– Events tag
This tag is optional. The events contain the event values where the check is
applicable. If you do not define an event value list, then the rule applies at
all times. The event values can contain an asterisk as a wildcard. The values
listed can be exclusive when the exclude attribute is set to yes.
If you define the class attribute for the Events tag, you set which target
revision attribute value should be tested against event values list.
– Parameter tag
Only parameters that logged in profile level (for a profile check result log file)
are supported. Child checker parameters must be promoted into the profile
level to be verified by the validation rule APIs.
• You can define rules in any order in the validation rule file.
• The same checker can be instanced in the definition of more than one rule
in the same rule file.
Figure 10-5 shows an example of a validation rule file.

Workflow
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="validation_rule.xsl"?>
<Rule_Set
name="Test_rule_set_1"
description="Power Train Event 0 at Milestone 3"
user="your_user_id" date="2005-12-25"
xmlns="http://www.plmxml.org/Schemas/PLMXMLSchemaValidationRule"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.plmxml.org/Schemas/
PLMXMLSchemaValidationRule validation_rule.xsd" >
<Rule>
<Checker name="mqc_check_dim_attach_solid"></Checker>
<Mandated>no</Mandated>
<Datasets>
<type>UGMASTER</type>
<type>UGPART</type>
</Datasets>
<Events class="ITEMREVISION:owning_group" exclude="yes">
<value>chassis.pe.company</value>
<value>powertrain.pe.company</value>
</Events>
</Rule>
<Rule>
<Checker name="mqc_examine_geometry"></Checker>
<Mandated>yes</Mandated>
<Datasets>
<type>UGPART</type>
</Datasets>
</Rule>
<Rule>
<Checker name="mqc_check_dim_attach_solid"></Checker>
<Datasets>
<type>UGPART</type>
</Datasets>
</Rule>
<Rule>
<Checker name="mqc_exam_geom_combo"></Checker>
<Datasets>
<type>UGPART</type>
<type>UGALTREP</type>
</Datasets>
<Events exclude="no">
<value>Status*3</value>
<value>Status_4</value>
</Events>
<Parameters>
<Parameter operation="=" title="Check Tiny objects"
value="TRUE></Parameter>
<Parameter operation="=" title="Check Misaligned Objects"
value="TRUE"></Parameter>
</Parameters>
</Rule>
Figure 10-5. Validation Rule File Example (Continued)

Chapter 10 Workflow
<Rule>
<Checker name="mqc_examine_geometry"></Checker>
<Datasets>
<type>UGPART</type>
</Datasets>
<Events exclude="no">
<value>S*</value>
</Events>
<Parameters>
<Parameter operation="=" title="Save Log in Part"
value="TRUE></Parameter>
</Parameters>
</Rule>
</Rule_Set>
Figure 10-5. Validation Rule File Example

Workflow
Validation Rule APIs
Figure 10-6 shows how to call validation rule APIs to perform a validation result
check with the validation rules.
validation_rule_t *validation_rules = NULL;

int num_rule = 0;
candidate_validation_result_t *candidates = NULL;
int num_candidates = 0;
/**********************************************
* Get Validation Rule list
**********************************************/
ifail =
VALIDATIONRULE_get_rules (
rule_item_revision,
NULL,
current_event,
&validation_rules,
&num_rule
);
/**********************************************
* Before calling VALIDATIONRULE_get_candidate_results() to get candidate
* result list, user may want to put codes here to resolve all unresolved
* rules.
**********************************************/
ifail =
VALIDATIONRULE_get_candidate_results(
target_objects,
count,
validation_rules,
num_rule,
&candidates,
&num_candidates
);
/**********************************************
* check validation result for each candidate
*/
for( int inx=0; inx<num_candidates; inx++)

{
ifail = VALIDATIONRULE_verify_result(
&(candidates[inx])
);
}
// Before exit, free up allocated memories

VALIDATIONRULE_free_rules(validation_rules, num_rule);
VALIDATIONRULE_free_results(candidates,num_candidates);
Figure 10-6. Validation Rule APIs Example

Chapter 10 Workflow
EPM Hints
This section outlines some helpful hints you can use when working with EPM.
Perform Action Handlers

The rule and action handlers associated with the perform action get called every
time an action with an action code greater than or equal to EPM_perform_action
is triggered. Choosing the Perform button calls the EPM_trigger_action function
with the action equal to EPM_perform_action.
Many existing ITK functions also call the EPM_trigger_action function to allow
you to customize Teamcenter. Figure 10-7 lists actions that are triggered inside
each ITK function.
Figure 10-7. ITK Functions
Avoiding Infinite Loops in Perform Actions

Infinite looping conditions can occur when performing actions if logic is not included
to test the values of the actions being triggered. For example, the following action
handler, my_action_handler, is executed when a Perform action is triggered:
int my_action_handler(EPM_action_message_t msg)
{
.........
.........
err = EPM_add_attachment (.................................);
.........
.........
return err;
}
When the err = EPM_add_attachment (..........) statement is executed,

my_action_handler is called again as a part of the EPM_add_attachment
call. This is because EPM_add_attachment calls EPM_trigger_action with
an action code of EPM_add_attachment_action. Since all action codes greater
than EPM_perform_action get sent to all of the perform action handlers, this
causes an infinite loop.

Workflow
To avoid this scenario, you should check the action being triggered inside each
handler. To avoid entering an endless loop in the example shown above, add:
if(msg.action > EPM_perform_action)
return ITK_ok;
as follows:
int my_action_handler(EPM_action_message_t msg)
{
if(msg.action > EPM_perform_action)
return ITK_ok;
......... /* initial lines of code for action */

......... /* handler initiation */
err = EPM_add_attachment (.................................);
......... /* final lines */

......... /* of code */
return err;
}
Inbox Queries
There are three queries that can be used to determine which tasks show up in the
Inbox:
• Show all but completed and skipped tasks.
• Show all but completed, skipped, and suspended tasks.
• Show only started tasks.
You can change which query workspace uses by modifying the k_inBox in the
flcommons.uih file, then recompiling the flwindow.uil and homeflwindow.uil
files. The following is found in the flcommons.uih file:
k_inBox0 :70; !all but completed and skipped tasks

k_inBox1 :70; !all but completed, skipped, suspended
k_inBox2 :70; !show only started tasks
k_inBox :70; !change this to change default query

Chapter 10 Workflow
Cascade Release Hints

Cascade release (CR) is an example of how to use EPM to model a process. It is an
EPM application which uses a sequential sign-off process model for release, hence
the name. This application can be used out of the box or can be extended to fit a
specific process. Figure 10-8 show the release model.
Figure 10-8. Release Model

The procedure contains different levels of sign-off arranged sequentially. The levels
are actually just tasks with subtasks predefined in the release-level template. Each
level is made up of two subtasks: select-signoff-team and perform-signoffs. The rule
handlers used in the CR release model ensure that all levels are in sequential order.
The model also assumes that the target and reference attachments are all attached
to the root task at runtime. The target attachments are the objects being released.
Customizing Procedures With CR

Customizing a CR procedure is the same as customizing any EPM procedure.
However, you must take the CR release model into consideration when designing
your handlers. CR provides a way of automatically generating procedures based
on the release-level template, release-procedure template and input from the
interactive procedure definition session.
Whenever a new release procedure is defined, a copy of the release procedure
template is taken. This copy is used as the default definition of the new release
procedure. Any modifications to the template are inherited by any release procedure
defined after the template is modified.

Workflow
Serial and Parallel Tasks in CR

In CR, subtasks are parallel tasks by default. To set the order of the tasks (in other
words, specify one or more as a serial task), you must add the check-completion
rule handler to task’s Start action with the names of the predecessor tasks (in
other words, tasks that should complete before this tasks starts) as arguments to
the rule handler.
For example, if you want Task A to start after Task B, you must add the
check-completion rule handler to the Start action of Task A with the argument
Task B as shown below:
Task 1
---Task A
Start
Rule check-completion Task B
---Task B
Without the check-completion rule handler, Task A and Task B both start when Task
1 is started (in other words, parallel tasks).
Consider also the following example where all subtasks (C, D, E and F) start as soon
as Task 2 is started by default:
Task 2
---Task C
---Task D
---Task E
---Task F
If you want Task E to wait for Task F to complete, you must add the check-completion
rule handler as follows:
Task 2
---Task C
---Task D
---Task E
Start
Rule check-completion Task F
---Task F
Sending Mail After Signoff

If you want to send mail when all signoffs have been made for a particular level, then
add your handler on the complete action for the release level you want. If you want it
to happen on every release level, then make the change in the release level template.

Chapter
11 Data Sharing of Data Objects
Object Import and Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Object Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Export of Released Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Exporting Objects – The Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Responsibilities and Restrictions When Exporting . . . . . . . . . . . . . . . . . . 11-3
Import Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Revisioned Objects – Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Revisioned Objects – Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Nonrevisioned Objects – Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Importing Objects – The Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Restrictions When Importing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Object Import and Export Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Multi-Site Collaboration . . . . . . . . . .......... .............. . . . . . . 11-7

Mapping Application-Specific IDs Using Object Directory Services
Extensions . . . . . . . . . . . . . . . .......... .............. . . . . . . 11-7
Legacy ITK Considerations . . . . .......... .............. . . . . . . 11-8
Caveats . . . . . . . . . . . . . . . .......... .............. . . . . . . 11-8

Chapter
11 Data Sharing of Data Objects
This chapter describes how to import and export objects as well as Multi-Site
Collaboration programming techniques.
Object Import and Export

You use the import/export object functionality to move data that is associated with
Teamcenter objects between Teamcenter sites with either read-only or read/write
privileges.
This functionality is in addition to the IMF_export_file and
IMF_import_file routines which are used to export and import files
between the Teamcenter and the operating system.
Object Types
The object types, including all their internal supporting data, that can be
imported/exported between Teamcenter sites are:
• Folders
You can choose to export any general folder. You cannot export pseudo folders.
Pseudo folders are folders displayed in your workspace that display objects with
a specialized relationship to an item or item revision.
• Datasets
When exporting, you can choose to export either all versions, the latest version,
or a specific version.
• Forms
When exporting, you can choose to export a form. The definition of the form
must be identical at both sites.
• Item
When exporting, if you choose an item, the item and all its related data (such as
the item revisions, BOMView and BOMView revisions, associated item master
and item revision master forms, and any exportable requirement, specification,
manifestation or reference objects) are exported. Additionally, if the selected
item has an assembly (structure), then all the items that make up the assembly
are exported.

Chapter 11 Data Sharing of Data Objects
You cannot choose part of an item to be exported. For example, you cannot choose
an item revision alone to be exported. You need to select the item which contains
this item revision, in order to export the item. Similarly, the same would be true
with BOMView and BOMView revision objects.
All Teamcenter files that the dataset represents are exported, including the
operating system files that these encapsulate and the dataset’s revision anchor.
When you export, there is an option to transfer the ownership to another site. If
the ownership is transferred to a particular site, then when the same objects are
imported at that particular site, they are imported with a read/write privilege. If the
ownership is not transferred, then the ownership of the objects still belongs to the
export site. When these objects are imported at another site, they are imported with
a read-only privilege. Any modifications attempted on them are not be allowed.
Object Ownership
When an object is imported, the owner is the user who performed the import. The
group is the group in which the owner logged into to perform the import. Even
though the user is the owner object, they might not be able to modify the object. This
occurs if the site ownership indicates that another site is the owner.
In general with import, object site ownership takes precedence in determining who
has the right to update the object.
Export of Released Objects

The following rules apply for released objects:
• Objects that are within a release process can be exported either with read/write
privileges or with read-only privileges. Objects that have been released can
be exported with read-only privileges.
• If such an object is imported at another site, it cannot be used in a release

process at that site if it was exported with read-only privileges. If it was exported
with read/write privileges, then it can be used in a release process.
• If an object is locked (in other words, it has been exported with read-only
privileges and is therefore locked at the receiving site) or it has been exported
with read/write privileges but not re-imported (therefore locked at the sending
site), it cannot be used in a release process.
All released objects are exported with their status (for example, Released
to Manufacture).
Exporting Objects – The Route

The route of exported objects is shown in figure 11-1.

Data Sharing of Data Objects
Figure 11-1. Export Route
Responsibilities and Restrictions When Exporting

The following enable you to determine the responsibilities and restrictions when
exporting:
• It is the responsibility of the user who is exporting objects to inform the system
manager which directories need to be copied and to which site.
• It is the responsibility of the system manager to set up the list of other sites
which are known to the local site.
• It is the responsibility of the system manager to send directories of the exported

objects to the receiving sites, (for example, using tape, ftp, and so on).
The following significant object types cannot be exported:

• Users.
• Other system administration objects.

Import Semantics
The importing of an object is straightforward unless the same object already exists
at the importing site. In this case the behavior of the objects is described as follows:
Revisioned Objects – Datasets
Although datasets do not need to have unique names, they do have unique internal
identifiers. Therefore, when a dataset is imported, the system knows whether it
already exists. If the dataset does exist which is the same revision, no import takes
place.
Revisioned Objects – Item
Items need to have unique ID’s. When an item is imported, be aware of the following
issues:
• It is the responsibility of the user who is exporting objects to inform the system
manager which directories need to be copied and to which site.
• If an item with the same ID does not exist in the database, then an item with
that ID is created and owned by the user doing the import.
• If an item with the same ID exists in the database, then the requirement,
manifestation, reference and specification objects of the importing item are
added on to the existing item.
Nonrevisioned Objects – Folders
These do not have unique names, therefore there are no problems when importing
objects.
Importing Objects – The Route

The route of imported objects is shown in figure 11-2.

Figure 11-2. Import Route
Restrictions When Importing

The following restrictions apply when importing an object:
• An imported object cannot be modified (but may be copied), unless it is exported
with read/write privileges.
• When an item is imported read-only, then the following rules apply:

– Existing requirements and specifications cannot be deleted, and new
requirements and specifications cannot be added.
– Existing manifestations and references can be cut, and new manifestations

and references can be added.
– Attributes on the imported objects cannot be modified.
– The item can be deleted from the database only if the item itself is selected.
You cannot delete any of the item revisions alone.
– The BOMView and BOMView revisions cannot be modified.
• When an item is imported with read/write privileges (with site ownership), then
the following rules apply:
– The item cannot be deleted from the database and none of its requirements,
specifications, manifestations and references can be removed. This is
because another site may have a reference to it.

– New requirements, specifications, manifestations and references can be

added.
– Attributes can be modified.
– If the item has been previously imported, the subsequent import does not
delete any references, but may add new ones. This occurs so that the import
does not wipe out any local references you may have added. It is important
to note that references deleted at the originating site are not removed from
the importing site. You may want to delete the item before re-importing it to
ensure that you get an exact copy of the original.
• Objects, when imported, are given new ACLs. For instance, the owner (as well as
their group) is updated to that of the importing user. However, if the object was
exported as read-only, the importing user is not able to modify the object.
Object Import and Export Interface

There are three ways to import or export an object:
• Using the ITK functions
• Using the user interface

Select your objects from the workspace window and pick the appropriate option
(Import or Export) from the Tools menu. Objects are selected as follows:
– If you select a (collapsed) folder, all objects inside that folder are exported or
imported that can be exported or imported.
– If you select many objects at one time, they can be exported or imported
in a single operation.
• There are command line interfaces to execute the export or import process
in batch mode for items only. They are item_export and item_import. For
additional information, see the Utilities Reference manual.
Imported objects are in the same folder structure as they were when
exported.

Multi-Site Collaboration
This section discusses ITK programming techniques and considerations unique to a
Multi-Site Collaboration environment.
Mapping Application-Specific IDs Using Object Directory Services

Extensions
You can use the Application Reference (APPREF) ITK module to map
application-specific unique IDs to a Teamcenter Engineering unique ID. The
APPREF functions populate and query the Publication Record class managed
by the Object Directory Services (ODS) with application-specific data. More than
one application-specific ID can be associated with one Teamcenter Engineering
item ID. The APPREF functions are called by the application that needs its IDs
mapped to Teamcenter Engineering. For example, NX Manager I-deas can call
APPREF functions to map its GUIDs to a Teamcenter Engineering item ID or UID.
For more information about the APPREF functions, see the Integration Toolkit
Function Reference.
The functions are called at ODS client sites which are sites that are configured to
communicate with an ODS site using publication and remote search operations.
The TC_appref_registry_site preference defines the ODS site that is used for
all APPREF operations. For more information about this preference, see the
Configuration Guide.
Table 11-1 shows the basic process and data flow for the APPREF module.
Table 11-1. Process and Data Flow

Step ODS Client Site ODS Site
1 At startup, the ODS server registers the
APPREF API handler.
2 Application calls the
APPREF API.
3 API calls the The ODS server calls the registered
distributed ITK APPREF API handler.
function.
4 APPREF API handler performs the
request and returns the results.
5 The distributed ITK
function returns the
results to the API.
6 The API returns
the results to the
application.

Legacy ITK Considerations

Before Multi-Site Collaboration, when exporting an object it was possible to omit
the destination or target site, which effectively produced an export file that could be
imported by any site. With the implementation of Multi-Site Collaboration, you are
now required to supply at least one target site.
Although this requirement has been addressed in the interactive Export dialog
window and the item_export utility, it may cause some problems in existing
user-written ITK programs that call OBJIO ITK functions to perform object export.
However, for those who want to continue using an existing ITK program without any
change, you can do so by performing the following steps:
1. Relink your ITK program with the current libraries.
2. In the Options dialog window, accessed from the Edit menu in My Navigator,
define the IMAN_default_export_sites preference with a list of the desired
target sites. For example:
IMAN_default_export_sites=
SITE1
SITE2
3. Define the IMAN_USE_DEFAULT_EXPORT_SITES environment variable

and set it to YES as follows:
export IMAN_USE_DEFAULT_EXPORT_SITES=YES
Unless this is defined, the site preference defined in step 2 is ignored.
4. Run the ITK program.
Caveats
The IMAN_default_export_sites preference is not used during interactive export

operations.
This procedure is only applicable when not transferring site ownership. If the
ITK program supports transfer of site ownership by calling the OBJIO_set_site
function, this call is re-directed to call the OBJIO_set_owning_site function,
thereby making the ITK program compliant with the Teamcenter requirements.
The OBJIO_set_site function is obsolete. Therefore, UGS highly recommends that
you modify any existing ITK programs to call the new OBJIO_set_target_sites
(when not transferring site ownership) or OBJIO_set_owning_site (when
transferring site ownership) functions.

Chapter
12 Customizing Forms and

Properties Display
Communication With the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Form UI Display Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Displaying a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Teamcenter Engineering Form Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Developing Automatic Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5

Step 1: Create the Form Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Step 2: Extend the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Developing Forms by Extending the Abstract Class . . . . . . . . . . . . . . . . . . . . 12-6

Step 1: Create the Form Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Step 2: Extend the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Step 3: Create the Form Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Step 4: Register the Form Panel with the Rich Client . . . . . . . . . . . . . . . . 12-6
Example of a Basic UI Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
General Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Form Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Form Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Developing Forms Using JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13

Using the Form Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
Developing Form Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
Developing Forms and Customizing the Properties Display Using XML Style
Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Using Predefined Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Modifying a Predefined Style Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Creating a New Style Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Style Sheet XML Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
XML Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
Display Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
Rendering Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26
Rendering Hints, Rendering Style, and JavaBeans . . . . . . . . . . . . . . 12-27
Customizing Property Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
Examples of XML Style Sheet Definitions and Renderings . . . . . . . . 12-30
Property Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-33

Chapter
12 Customizing Forms and

Properties Display
This chapter describes the processes used to create forms in the Teamcenter
Engineering rich client.
This chapter should be read from two perspectives. The first perspective is the
actual creation of forms within the rich client. It takes very little work and requires
no programming ability to create and display a form. The second perspective is that
of the programmer, which focuses on the techniques used to develop sophisticated
solutions.
A form is a logical storage mechanism that supports captured, informative, and
derived data. Captured data are the fields within a form in which users enter data;
these are generally required fields. Business rules often dictate that certain fields
be populated before the form is created. Informative data are read-only fields that
appear within the form and cannot be modified by the user. Derived data are the
fields within a form that are the sum or combination of other fields, or PDM data
that is composed and displayed within the form. Derived data typically cannot
be modified.
Forms capture information that users reference and view. These forms store data,
such as work order, ECO, or ECN information. Information contained in forms can
be used for queries. Companies typically use forms to:
• Capture and store information for work orders, ECOs, or ECNs. This is the most
common use of forms.
• Maintain processing information to support other features. For example, a form

can be developed to maintain the next available number when automatically
generating numbers. This type of form is used by administrators.

Chapter 12 Customizing Forms and Properties Display
Communication With the Server

Form data is obtained from the rich client kernel through form properties. When
the UI form is displayed, the properties are read from the server. Form properties
are different than object properties. Form properties are the data obtained from the
form on the server. Figure 12-1 shows the Teamcenter Engineering form model.
Figure 12-1. Form Model
Form UI Display Components

The rich client has changed the strategy of forms in Teamcenter Engineering.
Forms within the rich client are user interface representations only. Teamcenter
Engineering stores the information for the form; therefore, when the form is
loaded and displayed in the rich client, all data is obtained from the server and
placed into UI components. The base component for a rich client form is a JPanel
component that provides flexibility for the placement of forms within different
parent containers. Figure 12-2 shows a form panel.
Figure 12-2. Form UI Display Panel

Customizing Forms and Properties Display
Displaying a Form
When a form is displayed, the UI definition for the form is constructed, populated,
and placed within a container. In the rich client, a form can be displayed under two
paradigms: dialog and viewer. The dialog displays when the form is opened using
the Open menu or the form is double-clicked (figure 12-3). The viewer paradigm
is used when the form is selected and the Viewer tab is active (figure 12-4). The
contents of nonwritable form are displayed as read-only. If the user has write access,
then the form can be edited.
Figure 12-3. Form Displayed in a Dialog
Figure 12-4. Form Displayed in the Rich Client Viewer

A reusable Java component is used for form panel construction. Given the component
reference to the form, call the RenderingLoader.load(IMANComponent)
method, which constructs and returns the form panel. The form definition within
the rich client is flexible and supports a wide variety of applications. When a form
panel is loaded, the RenderingLoader looks to see if there is a registered form
panel for the component. If so, the registered form panel is returned. If not, an
automatic form is constructed and returned.

Teamcenter Engineering Form Types

The forms feature allows companies to create electronic versions of forms,
representing logically organized data fields. Forms persist to a POM class object.
The display is determined by the form properties in the POM class definition.
Teamcenter supports the following methods of form customization:
• Abstract Rendering
Allows you to write the form display by extending the AbstractRendering
class. This is the most flexible method of form customization. It is also the most
complex method and requires coding.
• JavaBean
Allows you to define forms using JavaBeans and an IDE (such as Eclipse) to
present form properties. Each bean knows how to display and save a specific
property type. This method is less complex than the abstract rendering method
but still requires some programming knowledge.
• XML Style Sheet

Allows you to define a set of properties to display, including the display order
and UI rendering component. The XML style sheet method is supported for both
the rich client and thin client.
• Automatic Forms
Allows you to display forms that have no associated interface definition. The
interface is created automatically as the form is displayed, based on the storage
fields identified within the form POM class.

Developing Automatic Forms

This section focuses on the creation and implementation of automatic forms. All
work is performed on the server, no work is required on the client. This form solution
works with existing Teamcenter Engineering implementations. Once the rich client
is installed, existing forms display automatically because they are considered to be
automatic forms and can display without customization. The rich client assumes
that forms are automatic if they are not registered on the client. If an error occurs
during form loading, the system throws an exception. All attempts are made to
display the data.
Use the following steps to create an automatic form:
1. Create a form type on the server side.
2. Create the POM storage in the Teamcenter Engineering schema.
Step 1: Create the Form Type

The form type can be created in Teamcenter Engineering using the install_types
command line utility or by using the Type application. All methods require you to
enter the form type name, POM storage.
Step 2: Extend the Schema

Extending the schema is beyond the scope of this document. For more information,
see Schema Editor Help.

Developing Forms by Extending the Abstract Class

Perform the following steps to create a UI form:
1. Create a form type on the server side.
2. Extend the schema.
3. Create the form panel.
4. Register the form panel with the rich client.
Step 1: Create the Form Type

The form type can be created in Teamcenter Engineering using the install_types
command line utility or by using the Type application. All methods require you to
enter the form type name, POM storage.
Step 2: Extend the Schema

Extending the schema is beyond the scope of this document. For more information,
see Schema Editor Help.
Step 3: Create the Form Panel

Create a Java object that extends from the AbstractRendering class,
which requires the implementation of two methods: loadRendering() and
saveRendering(). The loadRendering() method is invoked when the form is
constructed and reads the values from the IMANComponent class to populate
the form interface. The saveRendering() method writes the values from the UI
components to the IMANComponent class. Override the checkObject() method to
enable performance of checks prior to loading the form.
Example of a Basic UI Form, later in this chapter, shows a form containing four
properties, but the UI exposes only three to the user. This is because of the flexibility
of the form display system on the client. Often, there are form values that must be
filled in but not exposed to the user for data entry and display.
Step 4: Register the Form Panel with the Rich Client

Once a form class is written on the client, it must be registered in the
stylesheet_user.properties registry file to be recognized within Teamcenter
Engineering. The key within the stylesheet_user.properties file points to the
implemented AbstractRendering class definition and is comprised of the form
type name appended with .FORMJAVARENDERING. The associated client-side
definition file for the Item Revision Master form type is shown in figure 12-5.
ItemRevision\ Master.FORMJAVARENDERING=com.ugsolutions.iman.form.ItemRevisionMaster
Figure 12-5. Form Type Definition

The backslash character and a space (\ ) in the string create a space. If the backslash
character is not used, the space is misinterpreted and the form is displayed using
the automatic form display. Java interprets the key as item and does not parse past
the space, considering it the delimiter for the key/value combination.

Example of a Basic UI Form

This example focuses on the creation of a simple form within the user interface
(figure 12-6).
Figure 12-6. Basic UI Form and Components

1. Create the My Form type in Teamcenter Engineering.
2. Create the form UI definition (MyForm.java), as shown in figure 12-7.

package com.mycom.iman.form;
import javax.swing.*;
import com.ugsolutions.iman.kernel.*;
import com.ugsolutions.iman.stylesheet.*;
import com.ugsolutions.util.*;
public class MyForm extends AbstractRendering
{
private JTextField projectId;
private JTextField serialNo;
private IMANProperty piProperty;
private IMANProperty snProperty;
private IMANComponentForm form;
private IMANSession session;
/**
* This method is the constructor for MyForm given the IMANComponent of the
* form component.
*
* @param IMANComponentForm -The IMANComponentForm representing this form.
* @return void...Constructor
*/
public MyForm ( IMANComponentForm c)throws Exception
{
super ( c );
form = c;
session = c.getIMANSession();
loadRendering(); // Load the data from the database.

}
/**
* This method is used to provide the loading of the form properties
* from the database to the UI of the form itself.
*
* @return void
*/
public void loadRendering() throws IMANException
{
initializeUI(); // Construct the UI and it’s components
piProperty = form.getFormIMANProperty("project_id");
snProperty = form.getFormIMANProperty("serial_number");
projectId.setText ( piProperty.getStringValue() );
serialNo.setText ( snProperty.getStringValue() );
}
/**
* This method is used to provide the saving of the form properties
* from the form class definition to the database.
*
* @return void
*/
public void saveRendering()
{
try
{
piProperty.setStringValueData ( projectId.getText() );
snProperty.setStringValueData ( serialNo.getText() );
IMANProperty[] ps = new IMANProperty[2];
Figure 12-7. UI Definition (Continued)

ps[0] = piProperty;
ps[1] = snProperty;
form.setIMANProperties(ps);
}
catch ( IMANException ex )
{
}
}
/**
* This method is used to construct and initialize the UI of the form
* which will be setup to be populated with data.
*
* @return void
*/
private void initializeUI()
{
setLayout ( new VerticalLayout() );
JPanel mainPanel = new JPanel( new PropertyLayout());
mainPanel.setOpaque(false);
// Create all the text fields and combo boxes

projectId = new JTextField(26);
serialNo = new JTextField(20);
//Add components to Panel

mainPanel.add("1.1.right.center",new JLabel("Project ID"));
mainPanel.add("1.2.left.center", projectId);
mainPanel.add("2.1.right.center",new JLabel("Serial Number"));

mainPanel.add("2.2.left.center", serialNo);
add("unbound.bind", mainPanel);
}
}
Figure 12-7. UI Definition
3. Register the form with the rich client, by one of the following methods:
• Edit the stylesheet_user.properties file located in the portal.jar file.
• Create you own stylesheet_user.properties file and place it in the

following directory:
com\ugsolutions\iman\stylesheet
4. Add an entry to the stylesheet_user.properties file to register the form, as

follows:
My\ Form.FORMJAVARENDERING=com.my-forms-location.MyForm
In figure 12-7, the entry in the

com.ugsolutions.iman.stylesheet.stylesheet_user.properties package is:
My\ Form.FORMJAVARENDERING= com.mycom.iman.form.MyForm
My\ Form represents the form type of the form.

If you want to add a red triangle on the form to note a required field, add the
following code:
if (required)
{
propertyRenderer = new JLabel( propValue )
{
public void paint(Graphics g)
{
super.paint(g);
Painter.paintIsRequired(this, g);
}
};
}
General Comments
Example of a Basic UI Form is simplistic but shows the relationship of the different
methods and the purposes they serve. The source code in this example was created
manually.
The form UI is not limited to creation using an integrated development environment
(IDE) or to the use of any Java component. Third-party Java components can be
used within the form.
An IDE, such as Eclipse or Visual Café, can be used to generate the contents of the
form. Once created, you need only add the code required to read the property values
from Teamcenter Engineering and set the property values within the associated
component on the panel. Other components, such as LOVButton and DateButton,
make it easier to render the form properties.
If you upgrade from a previous version of Teamcenter Engineering that used the note
attribute in the form storage class, instances created from that class will continue to
use the note attribute. If you create a new storage class, it uses the string attribute,
and instances created from that class use the string attribute.
Starting with Teamcenter Engineering 2005, you should use the new style sheet
package (com.ugsolutions.iman.stylesheet) instead of the old form package
(com.ugsolutions.iman.form). The old form package will be deprecated
in a later release. If you want to still use the old custom forms in the new
package, move the entries you added to the form_user.properties file to the
stylesheet_user.properties file.

Form Performance Issues

System performance when forms are saved depends largely on the way the API
is used. All API components for saving and loading forms are found in the
IMANComponentForm component. The object retrieves form values and can
represent all types of data found in Teamcenter Engineering. It is patterned after
the IMANProperty object. The IMANComponentForm class is responsible for
handling the retrieval and storage of properties to a form. The IMANFormProperty
object handles the data representation of the value (or property).
It is more efficient to save all form properties in one call, because this minimizes
network traffic and limits the save action to one commit to the database. If each
property is saved individually, each requires a network call and a commit to the
database, which degrades system performance.
For example, a form containing 20 properties takes approximately two seconds
to save when all properties are saved in one call and approximately 25 seconds
to save when each property is saved individually. There are legitimate cases for
saving properties both individually and collectively. Therefore, take care when
deciding which API to use to achieve a desired result. The following examples
illustrate the different usages of the form API and assume a component f of type
IMANComponentForm:
• Obtaining one form property
IMANFormProperty p = f.getFormIMANProperty(“my_prop_name”);
• Obtaining all form properties

IMANFormProperty[] props = f.getAllFormProperties();
• Saving one form property

IMANFormProperty p = f.getFormIMANProperty(“my_prop_name”);
// Get the property to set
p.setStringValue ( “abc” ); // Set it.
At this point it is saved to the db.
• Saving several form properties

IMANFormProperty[] ps = f.getAllFormProperties();
// Get the property to set
ps[0].setStringValueData ( “abc” );
// Sets the value but is not saved.
ps[1].setStringValueData ( “def” );
// Sets the value but is not saved.
f.setIMANProperties(ps); // Now is saved to the db.
In summary, performance gains depend on how form data is saved. Whenever

possible, obtain an array of properties and set their values by using methods
such as setStringValueData() as opposed to the setStringValue() method. The
setStringValue() method sets the value and performs the save immediately. The
setStringValueData() method sets the value but relies on a subsequent call
to perform the commit. Finally, for an array of properties, make a call such as
setIMANProperties() to increase efficiency.

Form Events
When a form is displayed, the size is governed by the standard of preferred size for a
dialog. However, it may be necessary to control the dialog size prior to displaying
the form. In this event, implement the InterfaceRendererEvent interface within
the form display class. This interface forces the implementation of two methods:
dialogDisplayed (OpenFormDialog dlg, boolean state). The method is called
before the dialog is displayed. It is the place where the setBounds() method for
the dialog can be called.
When a form is displayed, the okToModify() method is invoked. If the form
is modifiable, it is constructed and displayed as designed. However, if the form
is not modifiable, logic is executed to determine what should or should not be
editable. When a read-only form is displayed, the components shown in table 12-1
are modified.
Table 12-1. Modified Components in Read-Only Forms

Component Read-Only Effect
JTabbedPane None
JSplitPane None
JPanel None
JLabel None
JScrollPane None
JProgressBar None
JTextComponent Edit ability set to False
All others Disabled
When a form is not modifiable, all Container objects, such as JTabbedPane, are
ignored and the remaining components are disabled. This is because Container
objects allow users to traverse and work through them to view the data. You may
want to control the read-only ability of a component within a form, in which case you
must override the read-only logic by implementing the InterfaceRendererEvent
interface and providing body to the setReadOnly() method.

Developing Forms Using JavaBeans

Perform the following steps to develop forms using JavaBeans.
1. Launch your IDE and create a new JPanel.
2. Add components to the new JPanel. To select a library to add components,

select the one that includes the portal.jar file. If the library containing the
portal.jar file is not listed, add it.
3. Locate and select the FormButton class.

The form JavaBeans are located in the com\ugsolutions\iman\form
directory.
4. Repeat the previous steps to add additional JavaBeans.
The form JavaBeans are now ready to use.

Using the Form Beans

You can create a JPanel component in which to contain the form beans, place them
on the panel, and connect them directly to the form properties by entering in the
property for the field. Once this is done, compile the form and register it with the
rich client.
Registration is accomplished by adding an entry in the form of
Form-Type-Name.FORMJAVARENDERING=Your-Form-Class to the
com.ugsolutions.iman.stylesheet.stylesheet_user.properties file. Once
registered, the rich client uses the custom form when the form type is opened.
For example, if the form type is MyFormType and the form display class is named
com.mycompany.forms.MyForm, the entry would be added to the properties
file, as follows:
My\ Form\ Type.FORMJAVARENDERING=com.mycompany.forms.MyForm
Often, a form must obtain the reference to the IMANComponentForm

component with which it is rendering. Each form bean has knowledge of the
IMANComponentForm class; however, for the JPanel component to recognize the
form, you must include a constructor that includes the IMANComponentForm
component. When you use your IDE to create the JPanel component, you may be
provided a default constructor, for example:
public MyPanel()
{
}
To reference the IMANComponentForm component, include a constructor

requesting a reference, as shown in the following example:
// IDE given
public MyPanel()
{
}
// User written
public MyPanel ( IMANComponentForm f )
{
}
When the form loads, the system looks first for the constructor with a reference
to the IMANComponentForm component. If one is found, it is used. If not, the
default constructor is used.
The properties of each form bean are described in Property Beans, later in this
chapter.

Developing Form Beans

Each form bean fundamentally knows how to load and save itself. When the form
is loaded and ready to be displayed, each form bean is notified to load itself and
its data. The form bean uses the defined property and obtains the value from the
Teamcenter Engineering database. When the user clicks the Save button, each form
bean is notified to save. When the form is loaded, the top-level container (the JPanel
component) that is registered for the form type is recursively cycled to look for the
InterfacePropertyComponent interface. When found, the beans are instructed
to either load or save. The form beans can be nested as deeply as desired within
containers and still be selected by the system.
To implement form beans, decide which UI class to subclass. Then,
identify a Teamcenter Engineering form bean and implement the
InterfacePropertyComponent interface, which contains two methods:
public void load ( IMANComponentForm ) throws Exception
public void save ( IMANComponentForm f ) throws Exception
Once you have created the component, all other JavaBean rules apply. For example,
you can attach icons for reference within an Integrated Development Environment
(IDE), such as Eclipse, and attach property rendering rules.
To perform checks prior to loading the form beans, override the checkObject
method as given follows:
public void checkObject() throws Exception
{
//required checks
}
All IDEs that support JavaBeans work with the form beans.
To increase the efficiency of form beans, UGS recommends that you also implement
the InterfaceBufferedPropertyComponent class. This requires a method that
has the following signature:
public IMANFormProperty saveProperty ( IMANComponentForm f )
throws Exception
This method should only use the setValue<type>Data calls to the form property
and return it. Therefore, all properties in the form bean system are collected and
saved in one call. This increases the efficiency of the form bean.
UGS provides both save() and saveProperty() methods to allow for flexibility in
form storage. All form beans delivered with Teamcenter Engineering utilize the
saveProperty() method. If you choose to override any of the base form beans, UGS
recommends that you override the saveProperty() method. If you override the
save() method in the base beans, Teamcenter Engineering uses your save() method
first over the saveProperty method.
This is accomplished using introspection. The bean is analyzed to determine if
there is an overridden save() method. If so, it is assumed that you want to use this
method over the saveProperty() method. This does not apply when you implement
your own form bean, because your form bean provides the implementation of the
save() method and is not considered to be overridden.

Developing Forms and Customizing the Properties Display Using XML

Style Sheets
Using XML style sheets enhances the display of forms and properties in the
Teamcenter rich client and thin client interface. You can customize the display by
editing the style sheet.
The style sheet is an XML document stored as a dataset of type
XMLRenderingStylesheet. When a style sheet is registered for a specific
object type or form, it defines the display of the object or form properties.
Registration information is stored in the type-name.RENDERING and
type-name.FORMRENDERING site preferences.
This section describes how to use and customize the XML style sheet.
Using Predefined Style Sheets

The Teamcenter installation provides several predefined style sheets that are
registered to display the properties of the following objects:
• Folder
• Form
• Item
• Item revision
• Group
• User
• Role
• Site
• Group member
• Volume
• EPM job
• IMAN file
• Tool
• Reservation
The registration information is stored in the preference; each object type has two
entries used to display regular properties, as follows:
type-name.RENDERING
The value of this key is the dataset name or the dataset UID used to display
properties of this type of object:
dataset-name/uid>.REGISTEREDTO

The value of this key is the type name for which this dataset is registered. Therefore,
the value for type-name.RENDERING will be the dataset name/UID and the value for the
dataset-name/uid.REGISTEREDTO will be the type name.
The following keys are used to display form properties:

type-name.FORMRENDERING
dataset-name/uid.FORM_REGISTEREDTO
You can verify the registration of forms in the rich client interface, as follows:
1. In one of the rich client applications, choose Options from the Edit menu.
Teamcenter displays the Options dialog window.
2. Click the Index link in the lower-right portion of the window. Teamcenter
displays the Preferences pane.
3. Enter form in the Search on preference name field and click the Search button
. Teamcenter displays the preferences that begin with form in the Preferences
list.
4. Click the form.REGISTEREDTO entry in the Preferences list. Teamcenter

displays the types to which the Form stylesheet can be applied in the right
pane of the window.
If no rendering registration is found for the currently selected type, the system
searches the hierarchy to determine if a rendering is registered to any of the parent
classes or parent types. If one is found, that rendering is honored.
Modifying a Predefined Style Sheet

To modify the predefined style sheets, you can either modify the existing dataset or
create a new dataset using the Save As option.
Perform the following steps to modify a predefined style sheet:
1. In My Navigator, perform a search for the dataset you want to modify. The
dataset type is XMLRenderingStylesheet.
2. To create a new dataset, select the XMLRenderingStylesheet dataset and

save it as a new dataset using the Save As option on the File menu. Teamcenter
displays the new dataset.
3. Select the dataset and click the Viewer tab. Teamcenter displays the contents of
the XML file in the Style Sheet Viewer.
4. Choose the object type to which this style sheet will be registered from the
Registered Type list.
5. Choose one of the style sheet type options, either Property or Form.
6. Edit the XML file, as required.
7. Click the Apply button to save the modifications.
8. Select an object that uses the style sheet and display the properties of the object
or open the form to verify the modifications to the style sheet.

Creating a New Style Sheet

You can create a new style sheet based on an existing XML dataset or create a new
dataset and associate it with an XML file. To create a style sheet from an existing
style sheet, follow the process described in Modifying a Predefined Style Sheet,
earlier in this chapter. To create a new style sheet, perform the following steps:
1. In My Navigator, create a new dataset of type XMLRenderingStylesheet.
2. Import the XML file as a named reference to the dataset as follows:

a. Right-click the dataset in the navigation tree, and choose Named References
from the popup menu. Teamcenter displays the Named References dialog
window.
b. Click the Import button. Teamcenter displays the Import File dialog window.
c. Locate and select the XML file in your operating system directory and click
Import. Teamcenter displays the XML file in the Named References dialog
window.
d. Click Close.
3. Register the style sheet by setting the Form.REGISTEREDTO preference.
Style Sheet Viewer

To access the Style Sheet Viewer (figure 12-8), select an XMLRenderingStylesheet
dataset in My Navigator and click the Viewer tab.
Figure 12-8. Style Sheet Viewer

If you are a user with DBA access, you can use the viewer to create, modify, and
register the XML definition for a certain type object. If you do not have DBA access,
you can view the XML definition, but you cannot modify it.
Registration information is stored in a site preference. The scope of the preference is
read as ALL, which allows customers to manually modify the registration to apply to
a specific, user, group, or role, and those preferences are read accordingly.
Style Sheet XML Definition

Figure 12-9 illustrates an example of the XML definition.
<?xml version="1.0" encoding="UTF-8"?>

<rendering>
<page format="OneColumn" title="General" titleKey="general">
<property name="project_id" />
<property name="serial_number" renderingHint="textfield" column="25" />
<separator />
<property name="item_comment" renderingHint="textarea" column="10" row="5" />
<property name="owning_user" />
</page>
<page title="Advanced" format="TwoColumn">

<firstcolumn>
<property name="user_data_1" renderingHint="lovbutton" renderingStyle="titled"
border="true" />
<separator />
<property name="user_data_2" renderingStyle="titled" />
</firstcolumn>
<secondcolumn>
<property name="user_data_3" renderingStyle="titled" border="true" />
<property name="previous_item_id" renderingStyle="titled" />
</secondcolumn>
</page>
</rendering>
Figure 12-9. XML Definition Example

Figure 12-10 and figure 12-11 illustrate how the XML code in figure 12-9 is rendered.
Figure 12-10. Form Rendering Example

Figure 12-11. Form Rendering Example
XML Elements
The XML file used to define the property display must include the elements and
attributes shown in figure 12-12:
<rendering version=”1.0”>
<page titleKey=”general” title=”General” format=”OneColumn”>
<property name="project_id" icon=”images/group.gif”/>
<property name="serial_number" renderingHint="textfield" renderingStyle=”headed”/>
<property name="item_comment" renderingHint="textarea" column=”30” row=”5”/>
<property name="user_data_1" renderingHint="lovcombobox" renderingStyle=”titled”
border=”true” />
<separator />
<property name=”user_data_1” />
<property name=”user_data_2” />
<break />
</page>
<page format="TwoColumn">
<firstcolumn>
<property name="item_id" />
<property name="item_revision_id"/>
<property name="object_name" />
<property name="object_string" />
<property name="object_type" />
<separator />
<property name="last_mod_user"/>
<property name="owning_group" />
</firstcolumn>
<secondcolumn>
<image />
</secondcolumn>
</page>
<page>
<all type=”property” />
</page>
</rendering>
Figure 12-12. XML File Elements

Table 12-2 describes the XML elements and attributes.

Table 12-2. XML Elements and Attributes
Element Description Attributes

rendering Root element Version
Version of the XML schema. When
an older version is detected, the
program automatically converts
the old scheme to the new one.
page Presented as a tab in titleKey
the dialog window. If
page is not defined in The key used to search for
the XML file, a default title in the locale file. If it is
page is created. This not defined, the string defined
is supported in both by title is used. This is a
the rich client and thin required attribute. This is
client. supported in both the rich
client and thin client.
title
The default string of the title
for this tab. This attribute
is used when the string in
title.key is not found in the
locale file. This is a required
attribute. This is supported in
both the rich client and thin
client.
format
The format to be used for
this page. This attribute
can have one of these
values: OneColumn or
TwoColumn. This attribute
is optional. If not defined,
the OneColumn form is
used. OneColumn and
TwoColumn are supported
in both the rich client and thin
client. For more information,
see Display Format, later in
this chapter.


property Property of the form name
or object. You must
include at least one Display name of the property.
property in the XML This is a required attribute.
definition; otherwise, This is supported in both the
the system displays an rich client and thin client.
empty panel.
icon
The icon for this property.
This attribute is optional.
The directory notion for the
image file is rich client only.
renderingHint
Specifies the component
used to render this property.
This is an optional attribute.
If not defined, the default
render is used based on
the property type. For a
list of rendering hints, see
Rendering Hints, Rendering
Style, and JavaBeans, later in
this chapter.


property renderingStyle
Defines the rendering style
used in the rendering
component. There are three
styles: headed, headless, and
titled. For more information,
see Rendering Style, later in
this chapter.
• Headed
This is the default
rendering style. The
property name is
displayed on the left
followed by the property
value renderer. This is
supported in both the rich
• Headless
This style renders only the
property value without
displaying the property
name in front of it. This is
supported in both the rich
• Titled
The property name is
displayed on the top of the
property value renderer.
This is supported in both
the rich client and thin
client.
border
Determines whether the
border is displayed. Valid
values are true and false.
This works only with the
titled style. This is supported
client.


property column
This attribute applies only to
the textfield and textarea
elements. It sets the number
of columns. This is supported
client.
row
This attribute applies only to
the textarea elements. It sets
the number of the rows for the
element. This is supported in
both the rich client and thin
client.
separator Adds a separator in None.
the panel. This is
supported in both the
rich client and thin
client.
break Inserts a break in None.
the panel. This is
supported in both the
rich client and thin
client.
firstcolumn Applies only to None.
the TwoColumn
format. The properties
defined within this
tab are added to the
left column of the
TwoColumn format.
This is supported in
both the rich client
and thin client.
secondcolumn Applies only to None.
the TwoColumn
format. The properties
defined within this
tab are added to the
right column of the
TwoColumn format.
This is supported in
both the rich client
and thin client.


image Attempts to find an None.
associated image.
This works only if the
selected object is an
item, item revision, or
dataset.
all Lists all properties type
of the defined object.
This is supported in Indicates whether to list all the
both the rich client object properties or only form
and thin client. properties. The valid values for
this attribute are property and
form.

Display Format
There are two display formats: OneColumn and TwoColumn.
OneColumn This is the format used in the current property display. Each row
displays one property (figure 12-13). This is the default format
if no format is defined.
Figure 12-13. OneColumn Display Format

TwoColumn Each row displays two properties (figure 12-14).
Figure 12-14. TwoColumn Display Format
Rendering Style
Each type of renderer supports three styles: headed, headless, and titled.
Headed Displays the property name on the left followed by the property
value renderer. This is the default rendering style.
This style has two components (figure 12-15), the
PropertyNameLabel JavaBean for the property name and the
PropertyrenderingHint JavaBean for the renderer (for example,
PropertyTextField or PropertyTextArea).
Figure 12-15. Headed Rendering Style

Headless Renders only the property value without displaying the property
name.
This style only contains one JavaBean, PropertyrenderingHint.
Titled Displays the property name above the property value renderer
(figure 12-16).
This style uses only the TitledPropertyrenderingHint
JavaBean, for example TitledPropertyTextField or
TitledPropertyTextArea.
Figure 12-16. Titled Rendering Style

Rendering Hints, Rendering Style, and JavaBeans
The JavaBeans used depend on the specified rendering hint and rendering style.
Table 12-3 lists the JavaBeans used based on the hint and style definition. All
renderer hints are supported in the rich client. If the rendering style is not defined,
the default style is headed.
Table 12-3. JavaBeans Based on Rendering Hint and Style
Renderer Supported in
Hint Thin Client? Rendering Style JavaBeans
textfield Yes Headed or headless PropertyTextField
Titled TitledPropertyTextField
textarea Yes Headed or headless PropertyTextArea
Titled TitledPropertyTextArea
checkbox Yes Headed or headless PropertyCheckbox
Titled TitledPropertyCheckbox
radiobutton Yes Headed or headless PropertyRadioButton
Titled TitledPropertyRadioButton
togglebutton No – Rendered Headed or headless PropertyToggleButton

as checkbox
Titled TitledPropertyToggleButton
datebutton Yes – Headed or headless PropertyDateButton

Rendered as
calendarbutton
Titled TitledPropertyDateButton
checkbox Yes – Rendered Headed or headless PropertyCheckboxOptionLov
optionlov using same
component as
string LOV
array
Titled TitledPropertyCheckbox
OptionLov

radiobutton Yes – Rendered Headed or headless PropertyRadioButton
optionlov using same OptionLov
component as
string LOV
array
Titled TitledPropertyRadioButton
OptionLov
togglebutton Yes – Rendered Headed or headless PropertyToggleButton
optionlov using same OptionLov
component as
string LOV
array
Titled TitledPropertyToggleButton
OptionLov
button Yes Headed or headless PropertyButton
Titled TitledPropertyButton
label Yes Headed or headless PropertyLabel
Titled TitledPropertyLabel
slider No Headed or headless PropertySlider
Titled TitledPropetySlider
panel Yes – Rendered Headed or headless PropertyPanel
using separators
Titled TitledPropertyPanel
objectlink Yes – Rendered Headed or headless PropertyObjectLink
as a textfield
Titled TitledPropertyObjectLink
lovbutton Yes – Rendered Headed or headless PropertyLOVButton
as regular LOV
Titled TitledPropertyLOVButton
lovcombobox Yes – Rendered Headed or headless PropertyLOVCombobox
as regular LOV
Titled TitledPropertyLOVCombobox
longtext Yes – Rendered Headed or headless PropertyLongText
as textarea
Titled TitledPropertyLongText

array Yes – Date, Headed or headless PropertyArray
String
(textarea),
String LOV,
typed reference
(UID) LOV are
supported
Titled TitledPropertyArray
Default Renderers
Table 12-4 displays the default renderer for each type. If the rendering hint is not
provided, the default renderer is used.
Table 12-4. Default Renderers

Type Default Render
String textfield if size < 60
textarea if 60 < size < 2500
longtext if size >= 2500
char Textfield
double textfield
float textfield
int textfield
short textfield
long textfield
Date datebutton
logical logical
note textfield if size < 60
textarea if size > 60
TypedReference/ objectlink
UntypedReference
All array type array
Any property with an LOV lovcombobox
attached
If there is an LOV attached to the property, the lovcombobox is used unless the
rendering hint does apply to an LOV.

Customizing Property Beans
Each rendering hint has a key defined in the stylesheet.properties file for the class
path of the JavaBean. You can plug in your own bean by overwriting the entry in the
properties file to replace the default JavaBean or you can add new entries for custom
JavaBeans. The key has following format:
rendering-hint.DEFINITION
This is for headed or headless beans.

rendering-hint_titled.DEFINITION
This is for titled beans.

For example:
textfield.DEFINITION=com.ugsolutions.iman.stylesheet.
PropertyTextField
textfield_titled.DEFINITION=com.ugsolutions.iman.stylesheet.
TitledPropertyTextField
Examples of XML Style Sheet Definitions and Renderings
Figure 12-17 shows an example of an XML definition for user properties.

<rendering>
<page title="General" titleKey="General" format="TwoColumn" >
<firstcolumn>
<property name="user_name" />
<property name="user_id" />
<property name="person" />
<separator />
<property name="default_group"/>
<property name="volume"/>
</firstcolumn>
<secondcolumn>
<property name="is_out_of_office" renderingStyle="Titled"
border="true"/>
<property name="is_member_of_dba" renderingStyle="Titled"
border="true"/>
</secondcolumn>
</page>
<page title="Workflow" titleKey="Workflow">

<property name="taskinbox" />
<property name="is_out_of_office" />
<property name="subscribed_inboxes" />
</page>
<page title="All">
<all type="property"/>
</page>
</rendering>
Figure 12-17. User Properties XML Definition

Figure 12-18 shows the User Properties dialog resulting from the XML definition in
figure 12-17.
Figure 12-18. User Properties Dialog

Figure 12-19 shows an example of an XML definition for item properties.

<rendering>
<page title="General" titleKey="General" format="TwoColumn">
<firstcolumn>
<property name="object_string" column="32"/>
<separator/>
<property name="object_name" column="32"/>
<property name="object_desc" />
<separator/>
<property name="owning_group" />
<property name="last_mod_user" />
</firstcolumn>
<secondcolumn>
<image/>
</secondcolumn>
</page>
<page title="Reservation" titleKey="Reservation">

<property name="checked_out" />
<property name="checked_out_user" />
<separator/>
<property name="checked_out_date" />
<property name="checked_out_change_id" />
<separator/>
<property name="reservation" />
</page>
<page title="Project" titleKey="Project">

<property name="proj_assign_mod_date" />
<property name="project_ids" />
<separator/>
<property name="project_list" />
</page>
<page title="All" titleKey="All">

<all type="property"/>
</page>
</rendering>
Figure 12-19. Item Properties XML Definition

Figure 12-20 shows the Item Properties dialog resulting from the XML definition in
figure 12-19.
Figure 12-20. User Properties Dialog
Property Beans
The following table lists JavaBeans that you can use to customize the properties
display:
JavaBean Description
PropertyNameLabel Renders the name of a property (figure 12-21). By specifying
the name property, it shows either the displayable name or real
name of the property according to the setting. This bean can be
used along with other beans that display the property value.
Figure 12-21. PropertyNameLabel

Properties:
property
Specifies the property name presented by the bean.
displayableName
Indicates whether the displayable name or real name is used.
colon
Indicates whether or not a colon is displayed after the name.

ProperyTextField Renders any nonarray type property, except reference/relation
type properties (figure 12-22). This bean wraps the rendering of
the given POM property into JTextField. Upon saving, the bean
attempts to convert the string to the corresponding property
type. If it cannot convert the string to the required type, an
exception is thrown.
Figure 12-22. PropertyTextField

Properties:
property
Specifies the property name presented by the bean. When a
component is provided, the property value is displayed inside
the text field.
mandatory
Indicates whether the property is required. If true, a red
astral is displayed in the upper-right corner of the field.
modifiable
Indicates whether the property is modifiable. If not
modifiable, the text field cannot be edited.
TitledProperty Displays the property name above the text field (figure 12-23).
TextField This bean is similar to the PropertyTextField bean and
actually contains two beans: PropertyNameLabel and
PropertyTextField.
Figure 12-23. TitledPropertyTextField

Properties:
bordered
Indicates whether a border is drawn around the text field.
In addition, you can apply the properties of the

PropertyTextField bean.

PropertyTextArea Renders any nonarray type property except reference/relation
type. This bean wraps the rendering of the given POM property
into the JTextArea, and is generally used for longer text (figure
12-24). Upon saving, it attempts to convert the string to the
corresponding type. If it cannot convert the string to the required
type, an exception is thrown.
Figure 12-24. PropertyTextArea

Properties:
property
Specifies the property name presented by the bean. When a
component is provide, the property value is displayed inside
the text area.
mandatory
astral is displayed in the upper-right corner.
modifiable
Indicates whether the property is modifiable. If not
modifiable, the text area cannot be edited.
TitledProperty Displays the property name above the text area (figure 12-25).
TextArea This bean is similar to the PropertyTextArea bean and
PropertyTextArea.
Figure 12-25. TitledPropertyTextArea

Properties:
bordered
Indicates whether a border is drawn around the text area.

PropertyTextArea bean.

PropertyButton Renders any nonarray type property into the text and icon of
the button (figure 12-26). The value of the property is displayed
as the button text. For the reference/relation type property, it
also attempts to display the icon associated with the reference
value. Users cannot change the button text; therefore, save does
not apply to this bean.
Figure 12-26. PropertyButton

Properties:
property
Indicates the property name presented by the bean. When
a component is provide, the property value is displayed as
the button text.
mandatory
TitledPropertyButton Displays the property name above the button (figure 12-27).
This bean is similar to the PropertyButton bean and
PropertyButton.
Figure 12-27. TitledPropertyButton

Properties:
bordered
Indicates whether a border is drawn around the button.
In addition, you can apply the properties of the PropertyButton

bean.
PropertyLabel Renders any nonarray type property and displays the value of
the property as the label text. Users cannot change the label
text; therefore, save does not apply to this bean.
Properties:
property
The property name presented by the bean. When a
component is provided, the property value is displayed as
the label text.

mandatory
TitledPropertyLabel Displays the property name above the label (figure 12-28). This
bean is similar to the PropertyLabel bean, and it actually
contains two beans: PropertyNameLabel and PropertyLabel.
Figure 12-28. TitledPropertyLabel

Properties:
bordered
Indicates whether a border is drawn around the label.
In addition, you can apply the properties of the PropertyLabel

bean.
PropertySlider Renders any numeric type property. For double or float types, the
value is cast to an integer. For string or note types, the value
is converted to an integer if possible. Upon save, the value set
on the slider is converted to the corresponding property type
and saved. Figure 12-29 illustrates an implementation of the
PropertySlider bean.
Figure 12-29. PropertySlider

Properties:
property
component is provided, the slider value is set according to
the property value.
mandatory
modifiable
Indicates whether the property is modifiable. If not, the
slider is disabled.

TitledPropertySlider Displays the property name above the slider (figure 12-30).
This bean is similar to the PropertySlider bean, and it
PropertySlider.
Figure 12-30. TitledPropertySlider

bordered
Indicates whether a border is drawn around the slider.
In addition, you can apply the properties of the PropertySlider

bean.
PropertyDateButton Renders the date type property (figure 12-31). For string or note
types, it attempts to convert the text value to a date if possible.
Figure 12-31. PropertyDateButton

Properties:
property
component is provided, the DateButton value is set
according to the property value.
mandatory
modifiable
Indicates whether the property is modifiable. If not, the date
button is disabled.
TitledProperty Displays the property name on the date button (figure 12-32).
DateButton This bean is similar to the PropertyDateButton bean, and
it actually contains two beans: PropertyNameLabel and
PropertyDateButton.
Figure 12-32. TitledPropertyDateButton

bordered

PropertyDateButton bean.
PropertyCheckbox Renders any nonarray type property, except reference/relation
type, using JCheckBox. A flag indicates whether the value is
saved only when the checkbox is selected or whether it is always
saved. There is a variable for the value to use on saving for a
selected button or for the deselected button. If the flag is set to
save regardless of whether the button is selected or deselected,
both the selected value to save and the deselected value to save
must be set. Figure 12-33 illustrates an implementation of the
PropertyCheckbox bean.
Figure 12-33. PropertyCheckbox

Properties:
property
The property name presented by this bean. When a
component is provided, the checkbox is selected if the
property value is same as the selected value.
mandatory
modifiable
Indicates if the property is modifiable. If not, the checkbox is
disabled.
selectedValue
Specifies the value used for saving when the checkbox is
selected.
deselectedVaue
Specifies the value to use for saving when the checkbox is
deselected.
saveOnlyWhenSelected
Indicates to save only when checkbox is selected or to always
save.

TitledProperty Displays the property name above the checkbox (figure 12-34).
Checkbox This bean is similar to the PropertyCheckbox bean and
PropertyCheckbox.
Figure 12-34. TitledPropertyCheckbox

bordered
Indicates whether a border is drawn around the checkbox.

PropertyCheckbox bean.
PropertyRadioButton The usage of this bean is same as that of the PropertyCheckbox
bean; however, rather than using JCheckBox, JRadioButton
is used. Figure 12-35 illustrates an implementation of the
PropertyRadioButton bean.
Figure 12-35. PropertyRadioButton

Properties:
property
component is provided, the button is selected if the property
value is the same as the selected value.
mandatory
modifiable
button is disabled.
selectedValue
Specifies the value used for saving when the button is
selected.
deselectedVaue
Specifies the value to use for saving when the button is
deselected.

Indicates to save only when the button is selected or to
always save.
TitledProperty Displays the property name above the button (figure 12-36). This
RadioButton bean is similar to the PropertyRadioButton bean.
Figure 12-36. TitledPropertyRadioButton

bordered

PropertyRadioButton bean.
PropertyToggleButton The usage of this bean is the same as the PropertyCheckbox
bean; however, this bean uses JToggleButton rather than
JCheckBox. Figure 12-37 illustrates an implementation of the
PropertyToggleButton bean.
Figure 12-37. PropertyToggleButton

Properties:
property
component is provided, the button is selected if the property
value is the same as the selected value.
mandatory
modifiable
button is disabled.
selectedValue
Specifies the value used for saving when the button is
selected.
deselectedVaue
Specifies the value to use for saving when the button is
deselected.

Indicates to save only when the button is selected or to
always save.
TitledProperty Displays the property name above the button. This bean is similar
ToggleButton to the PropertyToggleButton bean. Figure 12-38 illustrates an
implementation of the TitledPropertyToggleButton bean.
Figure 12-38. TitledPropertyToggleButton

bordered

PropertyToggleButton bean.
PropertyLOVButton Used for any property that has an LOV attached to it except
logical type. It uses LOVPopupButton to present this property
(figure 12-39).
Figure 12-39. LOVPopupButton

Properties:
property
component is provided, the button text is set to the property
value.
mandatory
modifiable
button is disabled.

lovName
Specifies the name of the LOV that the bean uses. If
undefined, the LOV information is retrieved from the
property descriptor.
TitledProperty Displays the property name above the LOV button (figure
LOVButton 12-40). This bean is similar to the PropertyLOVButton bean
and actually contains two beans: PropertyNameLabel and
PropertyLOVButton.
Figure 12-40. TitledPropertyLOVButton

bordered
Indicates whether a border is drawn around the LOV popup
button.

PropertyLOVButton bean.
PropertyLOV This bean is similar to the PropertyLOVPopupButton
Combobox bean; however, it uses LOVComboBox rather than
LOVPopupButton to present the property (figure 12-41).
Figure 12-41. PropertyLOVPopupButton

Properties:
property
The property name presented by the bean.

mandatory
modifiable
combo box is disabled.
lovName
Specifies the name of the LOV that the bean will use.
If undefined, the LOV information is retrieved from the
TitledProperty Displays the property name above the LOV combo box (figure
LOVCombobox 12-42). This bean is similar to the PropertyLOVCombobox
bean.
Figure 12-42. TitledPropertyLOVCombobox

bordered
Indicates whether a border is drawn around the LOV combo
box.
PropertyLOVCombobox bean.
PropertyCheckbox Presents each value in the LOV as a checkbox (figure 12-43). This
OptionLov bean is designed for any type property that has a LOV attached.
If the property is not an array, the checkboxes are added to a
button group; otherwise, they are not added to the button group
and multiple selections are allowed.
Figure 12-43. PropertyCheckboxOptionLov

Properties:
property
mandatory

modifiable
checkboxes are disabled.
lovName
Specifies the name of the LOV that the bean will use.
If undefined, the LOV information is retrieved from the
TitledPropertyCheckbox Displays the property name above the checkboxes (figure 12-44).
OptionLov This bean is similar to the PropertyCheckboxOptionLov
bean.
Figure 12-44. TitledPropertyCheckboxOptionLov

bordered
Indicates whether a border is drawn around the checkboxes.
PropertyCheckboxOptionLov bean.
PropertyRadioButton Same as the PropertyCheckboxOptionLov bean, except it
OptionLov uses buttons (figure 12-45.
Figure 12-45. PropertyRadioButtonOptionLov

TitledPropertyRadio Displays the property name above the buttons (figure 12-46).
ButtonOptionLov This bean is similar to the PropertyRadioButtonOptionLov
bean.
Figure 12-46. TitledPropertyRadioButtonOptionLov

PropertyToggleButton Same as PropertyCheckboxOptionLov, except it uses buttons
OptionLov (figure 12-47).
Figure 12-47. PropertyToggleButtonOptionLov

TitledPropertyToggle Displays the property name above the buttons (figure 12-48).
ButtonOptionLov This bean is similar to the PropertyToggleButtonOptionLov
bean.
Figure 12-48. TitledPropertyToggleButtonOptionLov

PropertyPanel This bean is a generic container that allows the integrator to
control how property values are stored and displayed. You must
override the load and save methods to implement this standard
behavior. You can combine one or more UI components within
JPanel to provide custom behavior.
For example, if a property in a form called status is an integer
and is either 1 or 2 meaning Running or Stopped, you may
want two toggle buttons with radio behavior to represent this
property. To accomplish this, use the PropertyPanel bean with
two JToggleButtons contained within.
You must override the load and save methods of the
PropertyPanel to determine the selection state from the two

buttons. The PropertyPanel is designed for special behavior
beyond the scope of the other property beans described in this
manual.
TitledPropertyPanel Displays the property name above the panel. This is the same
as the PropertyPanel bean.
PropertyObjectLink This bean renders reference type properties. A popup menu is
provided for users to modify the value (figure 12-49). If the value
is not modifiable, the popup menu is not available. When the
link is clicked, the system displays a dialog with properties of
this reference component.
Figure 12-49. PropertyObjectLink

Properties:
property
mandatory
modifiable
popup menu is not available.
TitledProperty Displays the property name above the link (figure 12-50). This
ObjectLink bean is similar to the PropertyObjectLink bean.
Figure 12-50. TitledPropertyObjectLink

bordered
Indicates whether a border is drawn around the link.
PropertyObjectLink bean.

PropertyLongText This bean can be used with any string or note type properties,
but is generally used to render text with lengths over 2500
characters. It contains a text area and a button. The long text
dialog is displayed by clicking the button, making it easier to
browse the text (figure 12-51).
Figure 12-51. PropertyLongText

Properties:
property
mandatory
modifiable
Indicates whether the property is modifiable. If not, the text
area cannot be edited and only the close button is available
in the long text dialog.

TitledProperty Displays the property name above the long text panel (figure
LongText 12-52). This bean is similar to the PropertyLongText bean.
Figure 12-52. TitledPropertyLongText

bordered
PropertyLongText bean.
PropertyLogicalPanel This bean is used to present a logical type property. It uses two
buttons, one for value true and another for false.
property
mandatory
modifiable
buttons are disabled.
TitledProperty Displays the property name above the field (figure 12-53). This
LogicalPanel bean is similar to the PropertyLogicalPanel bean.
Figure 12-53. TitledPropertyLogicalPanel

bordered
PropertyLongText bean.

PropertyArray Renders all array type properties. It is composed with a list box
and buttons to access the values in the list box (figure 12-54).
Based on the type of the property, a different renderer is used for
modifying or adding values. If the property is read only, users
cannot enter edit mode.
Figure 12-54. PropertyArray

property
mandatory

modifiable
Indicates whether the property is modifiable. If not, the edit
button is not available and the user cannot enter edit mode.
TitledPropertyArray Displays the property name above the property array (figure
12-55) and is similar to the PropertyArray bean.
Figure 12-55. TitledPropertyArray

bordered
Specifies whether a border is drawn around the panel.
In addition, you can apply the properties of the PropertyArray

bean.
PropertyImage This bean is limited to items, item revision, datasets, and BOM
view revisions. It walks down these objects to find a dataset
with a displayable image and displays that image. It uses the
same logic as Teamcenter Engineering Visualization to find
the image dataset and read the search order defined in the
imanviewer.properties file. For example, figure 12-56 shows
an image attached to the selected item revision.

Figure 12-56. PropertyImage

Chapter
13 Customizing Text and

Error Messages

Chapter
13 Customizing Text and Error

Messages
This chapter describes how to customize text and error messages.
You can define your own errors and error messages for display in Teamcenter
Engineering. Once these errors are defined, the appropriate error messages are
displayed or reported through the ITK for user-defined errors.
There are 999 user-defined error numbers restricted to a specified range. The
emh_const.h file contains the EMH_USER_error_base constant. Include the file
in your code and use this constant to define your error numbers. This minimizes
upgrade issues if the range of user-defined error numbers changes.
Prior to version 8.1, custom error strings were stored in UIH file. You
can convert UIH files to XML with the uih_to_xml utility, located in the
IMAN_ROOT\bin directory. For additional information, see the Utilities
Reference manual.
To write a custom error message for Teamcenter, follow these steps:
1. Update your code to include the emh_const.h file.
2. Add the #define statement for your error message in your code using the
following syntax:
#define USER_ERROR_NAME (EMH_USER_error_base + nnn)
where nnn is your error number. For example, you can define a connection
failure error with a number of 10 as follows:
#define CONNECT_FAILURE (EMH_USER_error_base + 10)
3. Compile your code.
4. Create the local shared library file.
5. Copy the IMAN_MSG_ROOT\IMAN_LOCALIZATION_DIR\ue_errors.xml file

to your IMAN_USER_MSG_DIR directory. To view XML structure and format,
see any of the XML files in the IMAN_MSG_ROOT\IMAN_LOCALIZATION_DIR
directory.

Chapter 13 Customizing Text and Error Messages
6. In your copy of the ue_errors.xml file, add a line to define the error string
corresponding to your custom message. Type the text within a pair of error tags
in the file. If you want to use a substitution marker, use %n$. For example:
<error id = "10">Unable to connect %1$</error>
7. Set the IMAN_USER_MSG_DIR environment variable in the

IMAN_DATA\iman_profilevars.bat file to point to the directory that contains
your ue_errors.xml file.

Chapter
14 Mechatronics
Mechatronics Fundamental Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Harness Model Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
Mechatronics API Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
API Use Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5

Creating Functionality and Functionality Revision Objects . . . . . . . . . . . . 14-5
Creating Interface Port Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Defining Ports for a Functionality Object . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Creating Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
Listing Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Disconnecting Ports From a Connection . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Removing Specific Ports From a Connection . . . . . . . . . . . . . . . . . . . . . . 14-9
Creating Process Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Creating Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Creating Signal-Process Variable Associations . . . . . . . . . . . . . . . . . . . . 14-10
Establishing Signal Associated System Relations . . . . . . . . . . . . . . . . . . 14-11
Removing the Relation Between a Signal/Process Variable and Associated
System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11
Maintaining Redundant Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
Removing Redundant Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
Setting Signal Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14
Setting Signal Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14
Setting Signal Line Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14
Embedded Software Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15

Chapter
14 Mechatronics
This chapter provides background information required to use ITK APIs to create
and manipulate Mechatronics objects.
Mechatronics Fundamental Objects

Teamcenter provides objects to work with functional representations, logical
representations and electrical representations of electromechanical products. Table
14-1 lists the objects that Teamcenter provides:
Table 14-1. Mechatronics Objects

Component Objects
Electrical components Functionality
FunctionalityRevision
Signals Signal
ProcessVariable
Electrical interfaces GDE
GDEOccurrence
Network_Port
Connection_Terminal
Electrical connections PSConnection
Network
Connection
GDELink
Routes RouteNode
RouteSegment
RouteCurve
RoutePath
RouteLocation
RouteLocationRev
Allocations Allocation

Chapter 14 Mechatronics
Table 14-1. Mechatronics Objects

Component Objects
AllocationMap
For more information about these objects, see the Integration for Wiring Harness
Design Tools manual.
The following relationships allow you to associate fundamental objects:
• Implemented By
• Realized By
• Connected To
• Routed By
• Device To Connector
• Assigned Location
• Associated System
• Redundant Signal
• Process Variable
For more information about these relationships, see the Integration for Wiring
Harness Design Tools manual.
To control the behavior of objects and actions on those objects, you can set the
following preferences:
• Connected_ToRules
• Implemented_ByRules
• Realized_ByRules
• APN_absolute_path_name_separator
• GDEOcc_display_instance_num_for_types
• GDELink_default_type
• TCENG_releasable_logical_types
• HRN_part_data_relation_primary
• HRN_wire_length_data_relation_primary
• HRN_fixing_assignment_relation_primary
• HRN_node_referenced_component_relation_secondary

Mechatronics
• HRN_associated_part_relation_secondary
Keep these preferences in mind when developing your ITK code. For more
information about these preferences, see the Integration for Wiring Harness Design
Tools manual or the Configuration Guide.
Object Model
The Mechatronics object model provides capabilities for representing all aspects of
an electromechanical product. In the context of wire harness modeling, Mechatronics
specifically provides objects to work with the functional representation, logical
representation, and electrical representation of electromechanical products.
Modeling an electromechanical product in Teamcenter involves working with the
objects highlighted in the Mechatronics object model. This model is depicted in
figure 14-1.
Figure 14-1. Object Model

Harness Model Support

The classes implemented to support wire harness data include routing and topology
related classes such as Route, Node, Segment and b_curve to capture the path
information associated with connections and devices implementing the connections.
Routes, segments and nodes contain a definition of the 2D or 3D routing topology
associated with connections, devices or other domain specific physical objects such as
wires. A route is defined as a course taken from a starting point to a destination. A
route defines the course either by using one or more segments or a set of nodes in
combination with curve objects, which define the shape of the route.
All route objects, such as segments, nodes, and curves, do not have any meaning
outside the context of the top level assembly (in other words, a BOMView revision).
Mechatronics API Modules

There are five ITK modules that you can use to customize objects to fit your needs:
• PSCONN
This module provides functions that allow you to manipulate connectivity data.
The functions are defined in the psconnection.h header file.
• GDE
This module provides functions that allow you to manipulate item elements. The
functions are defined in the gde.h header file.
• SIGNAL
This module provides functions that allow you to manipulate signals. The
functions are defined in the pssignal.h header file.
• ROUTE
This module provides functions that allow you to manipulate routes. The
functions are defined in the route.h header file.
• ALLOC
This module provides functions that allow you to manipulate allocations. The
functions are defined in the allocation.h header file.
There are example using some of the functions in the modules in the API Use
Examples section later in this chapter. You can also find sample programs using
these modules in the \samples\mechatronics directory. For more details about
the modules, see the Integration for Wiring Harness Design Tools manual. For more
details about the module’s functions, see the Integration Toolkit Function Reference
manual.
You can use PLM XML to export and import data used by the Mechatronics API
modules. For more information, see the Integration for Wiring Harness Design Tools
manual or the PLM XML Import Export Administration Help. You can also use the
modules in a Multi-Site Collaboration environment. For more information, see the
Integration for Wiring Harness Design Tools manual or Multi-Site Collaboration
Help.

Mechatronics
API Use Examples

This section provides examples for creating Mechatronics objects using ITK APIs.
Consider the climate control system illustrated in figure 14-2. This system can be
used in several contexts, such as an automobile or home. The system and its contents
have particular meaning when used in specific contexts. Similarly, all Mechatronics
objects have real meaning when used in specific contexts.
Figure 14-2. Climate Control System
Creating Functionality and Functionality Revision Objects

Functionality objects are represented by a type of an item.
The following example creates a functionality object and its corresponding
functionality revision object:
nt ifail = ITK_ok;
tag_t rev = NULLTAG;
tag_t item = NULLTAG;
ifail = ITEM_create_item( item_id,
item_name,
item_type,
item_revision_id,
&item,
&rev );
return ifail;
else
{
ifail = ITEM_save_item (item);
return ifail;
else
ifail = AOM_refresh(item, false);
}

Creating Interface Port Objects

An interface port must be created and added to the functionality before new ports
can be defined. Interface ports are represented by a type of item element object.
The following example creates an interface port:
int ifail = ITK_ok;
tag_t gde_obj = NULLTAG;
ifail = GDE_create ( gde_name,
gde_description,
gde_type,
&gde_obj );
return ifail;
else
{
ifail = AOM_save (gde_obj);
return ifail;
else
ifail = AOM_refresh(gde_obj, false);
}
Defining Ports for a Functionality Object

Once interface ports are created, you can define ports for a functionality by attaching
them to a revision of a functionality for a given context (view). All ports under a
given item revision are tracked using an item element BOMView revision (BVR)
associated with the item revision.
The following example creates the item element BVR and attaches the interface
port to the functionality revision:
int ifail = ITK_ok;

tag_t gde_bvr = NULLTAG;
tag_t gde_occ = NULLTAG;
/* Create GDEBVR under a functionality revision */
ifail = ITEM_rev_create_gde_bvr ( rev, view_type_tag, &gde_bvr);
return ifail;
/* Attach the interface port to functionality revision by creating GDEOccurrence
*/
ifail = GDE_create_occurrence ( gde_bvr,
gde_obj,
view_type_tag,
occurrence_type, /* can use NULLTAG */
quantity,
instance_no,
&gde_occ);
return ifail;
else
{
ifail = AOM_save (gde_bvr);
return ifail;
else
ifail = AOM_refresh(gde_bvr, false);
}
Figure 14-3. Defining Port Example

Mechatronics
Creating Connections
Assume that you have used the APIs described above to create Functionality_0
containing Functionality_1 and Functionality_2. Functionality_1 has Port1 and
Functionality_2 has Port2 (figure 14-4). You must connect Port1 and Port2 in a
given context.
Connections are only valid for the given context. A separate connection
call is required to associate a connection object with ports for each usage
of a connection occurrence.
Figure 14-4. Functionality Connections

The following example creates connections for Port1 and Port2:

int ifail = ITK_ok;

tag_t window = NULLTAG;
/* Create BOMWindow to display the product structure of Functionality_0 */
ifail = BOM_create_window ( &window );
return ifail;
ifail = BOM_set_window_pack_all ( window, TRUE );
return ifail;
ifail = BOM_set_window_top_line ( window,
functionality_1_item,
functionality_1_rev,
NULLTAG,
&topline );
/* Each of the components that used in the structure will be represented as a BOMLine.
We need to get BOMLines for Port1 and Port2 so that we can use them in making connection.
*/
tag_t *childs = NULL;
int count = 0;
ifail = BOM_line_ask_all_child_lines(topline, &count, &childs);

return ifail;
/* Look for BOMLines for Port1 and Port2 */

tag_t gdelineType = NULLTAG;
ifail = IMANTYPE_find_type (“GDELine”, (const char*)0, &gdelineType);
return ifail;
tag_t line_type_tag = NULLTAG;
tag_t line_for_port1_port2[2];
int line_found = 0;
char* object_name = NULL;
for ( int inx =0; inx < count; inx++ )

{
ifail = IMANTYPE_ask_object_type(childs[inx], &line_type_tag);
return ifail;
if (line_type_tag == gdelineType)
{
ifail = AOM_ask_value_string ( childs[inx], "bl_line_name", &obj_name );
/* Get the BOMLine for Port1 and Port2 */
if (! strcmp(obj_name, “Port1”) || ! strcmp(obj_name, “Port2”))
{
line_for_port1_port2[line_found] = childs[inx];
line_found++;
if (line_found >= 2)
break;
}
}
}
/* Create connection */
if (line_found > 0)
{
ifail = PSCONN_connect (connection_id,
connection_name,
connection_type,
connection_rev,
line_found,
line_for_port1_port2,
&connection_line_tag);
}
Figure 14-5. Creating Connections

Mechatronics
Listing Connections
The following example lists ports that are connected by a connection:
Ifail = PSCONN_list_connected_gdes( connection_line_tag,
&gde_line_count,
&gde_line_tags);
Disconnecting Ports From a Connection

This function does not delete the connection object, but it does break the linkage
between the ports and connection objects.
The following example disconnects all ports from a connection:
Ifail = PSCONN_disconnect ( connection_line_tag);
Removing Specific Ports From a Connection

The following example removes Port1 from the connection:
tag_t port_to_remove[*];
int port_count;
port_to_remove[0] = line_for_port1;
port_count = 1;
ifail = PSCONN_remove_from_connection ( connection_line_tag,
port_count,
port_to_remove);
Creating Process Variables

Process variables are a type of item element. The following example creates a
process variable:
int ifail = ITK_ok;
tag_t process_variable_obj = NULLTAG;
ifail = GDE_create ( process_variable_name,
process_variable_description,
“ProcessVariable”, // Type of gde
&process_variable_obj );
return ifail;
else
{
ifail = AOM_save (process_variable_obj);
return ifail;
else
ifail = AOM_refresh(process_variable_obj, false);
}

Creating Signals
Signal objects are created using the SIG_create_signal API as shown in the
following example:
int ifail = ITK_ok;
tag_t rev = NULLTAG;
tag_t signal = NULLTAG;
ifail = SIG_create_signal( signal_id,
signal _name,
signal _type,
signal _revision_id,
&signal,
&rev );
return ifail;
else
{
ifail = ITEM_save_item (signal);
return ifail;
else
ifail = AOM_refresh(signal, false);
}
Creating Signal-Process Variable Associations

Signals are sometimes generated due to a variation of the system variable, such as
temperature or pressure. In the climate control example (figure 14-2), the signal is
generated due to a variation in car temperature compared to a preset value.
To represent this variation, a signal can be associated with a process variable of
the current context using the SIG_set_signal_pvariable function, as shown in
the following example:
ifail = ITK_ok;
ifail = SIG_set_signal_pvariable( signal_line_tag, process_variable_line_tag );
if( ifail != ITK_ok )
return ifail;
In this example, the signal_line_tag and process_variable_line_tag tags

represent the signal line and process variable line in the current context.
The SIG_set_signal_pvariable function requires that you set the
SIG_asystem_pvariable_rules preference to the object type that is being passed in
as secondary.

Mechatronics
Establishing Signal Associated System Relations

For a signal to have meaning, it must be identified with the system (associated
systems) that processes the signal and its purpose. The purpose defines the role a
system plays in the existence of the signal within the specified context. The standard
Teamcenter installation provides the following set of roles:
• Source
• Target
• Transmitter
To set a source, target, or transmitter associated system programmatically, set

the corresponding preference for that associated system to include the type of the
secondary object being passed in to the function.
In the climate control example (figure 14-2), the electrical signal is generated by the
TempMeasure functionality and consumed by the TempRegulator functionality.
The association between signal and associated system is only valid in the
specified context.
The following example associates the signal to the system:

int ifail = ITK_ok;
ifail = SIG_set_associated_system( signal_line_tag,
asystem_line_tag,
role,
&relation_tag );
return ifail;
Similar to signals, process variables also have associated systems that

generate, consume, or transmit the process variable. The association
between process variable and associated system in a given context can be
set using the SIG_set_associated_system function.
Removing the Relation Between a Signal/Process Variable and

Associated System
The association between a signal or process variable and an associated system in a
specified context can be removed using the SIG_unset_associated_system or the
SIG_unset_associated_systems function.
You should use the SIG_unset_associated_system function to remove all
associated system relations, corresponding to valid associated system roles, between
a signal or process variable line tag and an associated system line tag. This function
does not take multiple inputs for the signal or process variable line or the associated
system line.

You should use the SIG_unset_associated_systems function to remove

associations between a signal or process variable line tag and one or more secondary
BOM lines for a specific role that is passed in to the function. If one or more of the
secondary BOM lines passed in is invalid, or if an association does not exist between
the signal or process variable line and one or more of the secondary BOM lines, that
secondary line is added to a failedLines array output variable, and the function
processes the next secondary BOM line. You must pass a valid non-null role in the
role argument (for example, source, target, or transmitter).
The following example removes all associated system relations between a signal
and associated system:
int ifail = ITK_ok;
ifail = SIG_unset_associated_system( signal_line_tag, asystem_line_tag );
return ifail;
In this example, the signal_line_tag and asystem_line_tag arguments represent

the tags of the signal and associated system lines in a specified context.
The following example removes a specific associated system relation corresponding
to the source role between a signal and secondary lines:
int ifail = ITK_ok;
logical hasFailures = false;

int numFailedLines = 0;
tag_t *failedLines = 0;
ifail = SIG_unset_associated_systems( priLineTag, numSecondaries,

secondaries, “source”, &hasFailures, &numFailedLines, &failedLines );
if( ( ifail != ITK_ok ) || ( hasFailures ) )
{
// process the failures
}
In this example, the priLineTag and secondaries arguments represent the tags
of the primary signal or process variable line and the secondary associated system
lines, respectively. The failedLines argument is an output array that holds the
failed secondary lines. The hasFailures argument is a logical argument that is set
to true if failures exist. The numFailedLines argument is an integer that holds
the number of failed removals.

Mechatronics
Maintaining Redundant Signals

To maintain proper system function, it is sometimes necessary to maintain duplicate
signals in a specific context.
For example, in the climate control example (figure 14-2), it is essential to maintain
a redundant TempFunctionality functionality in the rear of the car that generates
exactly the same signal as the functionality in the front of the car. This maintains
proper functioning of the climate control system.
Redundant signals are identified by associating duplicate signals with the primary
signal using the SIG_set_redundant call, as depicted in the following example:
int ifail = ITK_ok;
ifail = SIG_set_redundant_signal( primary_signal_line_tag,
redundant_signal_line_tag,
&relation_tag );
return ifail;
There can be multiple redundant signals for a given signal based on the
criticality of the function being regulated.
Removing Redundant Signals

Redundant signals associated with a primary signal in a given context can be
removed using the SIG_unset_redundant_signal call, as shown in the following
example:
int ifail = ITK_ok;
ifail = SIG_unset_redundant_signal( primary_signal_line_tag,
redundant_signal_line_tag );
return ifail;
In this example, redundant_signal_line_tag is the line tag of the redundant

signal in the given context.

Setting Signal Values

Signals represent changes in the values of process variables; therefore, they carry
values for the regulation of the process variables. These values can be fixed, for
example 5 volts, or they can be a range, for example 5–10 volts. Because the value
can vary from one revision to another, signal values are set on the signal revision
objects using the SIGREV_set_signal_value function, as shown in the following
example:
int ifail = ITK_ok;
ifail = SIGREV_set_signal_value( signal_revision, value );
return ifail;
In this example, signal_revision is the tag of the signal revision object and value is
the double value to be set on the signal revision.
Setting Signal Characteristics

Signals represent process variables that vary in a given context; therefore, the
value of the signal differs to represent the change. This variation in signal value
with respect to the process variable is defined as a signal characteristic, which is
represented either as an equation or as a human-readable text on each signal
revision.
Teamcenter does not interpret signal characteristics on a signal revision.
This is assumed to be part of the Teamcenter implementation at a given site.
The following example sets signal characteristics on a signal revision:

int ifail = ITK_ok;
ifail = SIGREV_set_signal_characteristics( signal_revision, characteristics );
return ifail;
Setting Signal Line Values

Values on signal revision objects represent a ranges or expected values that the
signal is expected to generate. The actual value of a signal exists within a specific
context. For example, in the climate control example (figure 14-2), the value on the
signal generated by the TempMeasure functionality depends on the exact condition
(temperature) inside a car. In addition, the value generated by the TempMeasure
functionality is different if the climate control system is used in a room or in a truck,
rather than in a car.
The following example sets signal line values:
int ifail = ITK_ok;
ifail = SIG_set_signal_line_value( signal_line_tag, value );
return ifail;
In this example, signal_revision represents the tag of the signal revision object and
value represents the double value to be set on the signal revision.

Mechatronics
Limitations
• Configuration and effectivity rules are not supported by GDELine.
• There are no precise and imprecise forms of GDELine.
• There is no BOM Compare on GDELines.
Embedded Software Manager

Embedded software is a critical component within electronics devices. It undergoes
upgrades and enhancements independent or part of electronic devices. The
Embedded Software Manager (ESM) in Teamcenter manages the software
components and their dependencies as well as the functional and physical
components and their dependencies in an integrated product development
environment. The ESM delivers four critical components to handle software
management: the embedded software manager itself, embedded software explorer,
the signal manager, and the signal explorer. The ITK functions corresponding to
these four components are broadly divided into the ESM_ functions and the SIG_
functions. For more information about the ESM, see Product Structure Editor Help.
The ESM is installed as an additional component during the Teamcenter Engineering
installation process and requires a separate license. For more information, see either
the Installation on UNIX and Linux Clients or Installation on Windows Clients
manuals.
Before using ITK to customize the ESM, ensure its related preferences are set to
the correct software categories, types, and dataset types. For more information,
see the Configuration Guide.
Table 14-2 lists the ESM module functions you can use to customize the Embedded
Software Manager. These functions support the management of software, processor,
and their dependencies. For more information about these functions, see the
Integration Toolkit Function Reference manual.
Table 14-2. Embedded Software Manager Functions

Function Definition
ESM_is_processor Given a BOM line tag, checks whether it is a
processor BOM line.
ESM_is_gateway Given a processor BOM line tag, checks whether
it is a gateway processor BOM line.
ESM_is_software Given a BOM line tag, checks whether it is a
software BOM line.
ESM_associate_processor_to_ Given a processor BOM line and an array of
software software BOM lines, associates processor and
software using the Embeds relation. To save
the associations, save the BOM window.

Table 14-2. Embedded Software Manager Functions

Function Definition
ESM_associate_processor_to_ Given a gateway processor BOM line and
processor an array of other processor BOM lines that
are accessed through the gateway processor,
associates the processors in the array with
the gateway processor using the GatewayOf
relation. To save the associations, save the BOM
window.
ESM_associate_software_to_ Given a software BOM line and an array of
software software BOM lines, associates software using
the Dependent On relation. To save the
associations, save the BOM window.
ESM_remove_processor_to_ Given a processor BOM line and an array of
software_association software BOM lines, removes the Embeds
relation association of the processor and software
lines. To save the associations, save the BOM
window.
ESM_remove_processor_to_ Given a gateway processor BOM line and an
processor_association array of associated processor BOM lines, removes
the GatewayOf relation association between
the processor lines. To save the associations,
save the BOM window.
ESM_remove_software_to_ Given a software BOM line and an array of
software_association software BOM lines, removes the Dependent
On relation association of the software lines. To
save the associations, save the BOM window.
ESM_ask_embedded_ Given a processor BOM line, gets an array
software_of_processor of software BOM lines that are associated to
processor with the Embeds relation.
ESM_ask_gateway_of_ Given a processor BOM line, gets an array of
processor gateway processor BOM lines that are associated
to it with the GatewayOf relation.
ESM_ask_processors_ Given a gateway processor BOM line, gets an
accessedby_processor array of processor BOM lines that are associated
to it with the GatewayOf relation.
ESM_ask_dependent_ Given a primary software BOM line, gets an
software_of_software array of secondary software BOM lines that are
dependent on the primary software.
ESM_ask_software_used_by_ Given a secondary software BOM line, gets an
software array of primary software BOM lines that are
used by the secondary software.
Table 14-3 lists the SIG module functions you can use to customize the Embedded
Software Manager. These functions support the management of signals and their
dependencies. For more information about these functions, see the Integration
Toolkit Function Reference manual.

Mechatronics
Table 14-3. Signal Manager Functions

Function Definition
SIG_set_associated_systems Sets the secondary lines as an associated system
based on the input role to the primary signal or
process variable line. This function requires you
to set the appropriate preference to the correct
type for the association to be created for that
type. If the preference exists, but does not have
a value, the corresponding association is not
created. For more information about the ESM
preferences, see the Configuration Guide.
SIG_unset_associated_ Removes associations between a signal or process
systems variable line tag and one or more secondary
BOM lines for a specific role passed in to the
function. If one or more of the secondary BOM
lines passed in is invalid, or if an association does
not exist between the signal or process variable
line and one or more secondary BOM lines, that
secondary line is added to a failedLines array
output variable, and the function processes the
next secondary BOM line. You must pass a valid
non-null role in the role string argument.
SIG_ask_signal_sources Finds all the sources of the signal or message
line tag using the associated_system relation.
SIG_ask_signal_targets Finds all the targets of the signal or message
line tag using the associated_system relation.
SIG_ask_signal_transmitters Finds all the transmitters of the signal or
message line tag using the associated_system
relation.
SIG_ask_device_sources Finds all the source devices that transmit
messages or signals to the target device,
represented by linetag. This function uses
the underlying associated_system relation
between source and message or signal.
SIG_ask_device_targets Finds all the targets devices that the device,
represented by linetag, transmits messages or
signals to. This function uses the underlying
associated_system relation between target
and message or signal.
SIG_ask_device_transmitted_ Finds all the messages or signals that are
signals transmitted by a source device, represented
by linetag. This function uses the underlying
associated_system relation between source

Table 14-3. Signal Manager Functions

Function Definition
SIG_ask_device_received_ Finds all the messages or signals that are
signals received by a target device, represented by
linetag. This function uses the underlying
associated_system relation between target
You might want execute some of the following tasks programmatically:

• Associate a processor with the software to be installed on it.
• Associate processors with a gateway processor.
• Associate software with other software dependent on it.

Mechatronics
Figure 14-6 is a code snippet that does the following:

• Takes a set of input BOM lines.
• Separates the gateway processor from the other processors.
• Creates the gateway relationship.
• Queries the relationship through the ESM_ask_ functions.
• Gets the processors that are accessed through this gateway processor.
• Removes the gateway associations.
All other create, ask, and removal methods follow a similar coding pattern.
// Get the gateway and the processor lines from the list of lines passed in
tag_t gateway_processor_line = NULLTAG;

for( jnx = 0 ; jnx < numBOMLines; inx++ )
{
If ( ESM_is_gateway( inputbomlines[inx] )
gateway_processor_line = inputbomlines[inx];
else
{
If ( ESM_is_processor( inputbomlines[inx] )
{
processorLines[num_processor_lines] = inputbomlines[inx[;
num_processor_lines++;
}
}
}
/// associate the gateway and the processor lines

int stat = ESM_associate_processor_to_processor(
gateway_processor_line, num_processor_lines,
processorLines, &hasFailures, &numFailedLines, &failedLines);
for( inx = 0; inx < numFailedLines; inx++)
{
//Perform any custom error reporting
}
….
// next, we query for all processors accessed through this gateway-
// in this example, if numFailedLines was 0, the lines in
// “processorLines” above, will match the lines in
// accessed_processor_lines. Note that the array is not a sorted list
stat = ESM_ask_processors_accessedby_processor(
gateway_processor_line, &num_accessed_lines,
&accessed_processor_lines);
// Now we remove the associations between the processors and gateway
stat = ESM_remove_processor_to_processor_association(
gateway_processor_line, num_processor_lines, processorLines,
&hasFailures, &numFailedLines, &failedLines);
Figure 14-6. Embedded Software Manager Example

Chapter
15 Traversal Engine
Basic Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Developing a Traversal Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3
Sample Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3

Chapter
15 Traversal Engine
This chapter describes the Traversal Engine module that allows you to develop
utilities that traverse Teamcenter Engineering structures, such as Product Structure
(PS), without the requirement to write a specific program.
The Traversal Engine (TE) is a module that is distributed as a shared library and as
callable subroutines (TE API calls). Typical common tasks include:
• Generate reports
• Release assemblies
• Transfer ownership of Teamcenter Engineering objects that constitute the

product structure
The Traversal Engine manages the traversal, while you are only required to
develop simple ITK programs. The Traversal Engine allows you to register these
functions at different stages of the traversal. These functions are executed at each
node and contain the information of the nodes, which can be processed. The core
module is programmed in object-oriented programing (OOP), so the framework can
be expanded by adding new classes at a later date, and can also be extended to
traverse any Teamcenter Engineering structure such as product structure or folders.
Presently the core module relates to product structure only. The ps_traverse utility,
located in the IMAN_ROOT/bin directory has also been developed to demonstrate
the use of TE.
Basic Features
The features of the Traversal Engine are:
• Represents the Teamcenter Engineering structure as a tree data structure with
each node representing the Teamcenter Engineering object.
• Provides user exits at different stages and allows the registration of user-defined
functions known as handlers and selectors.
• Allows the handlers and selectors to return statuses that determine the creation
of the tree and the traversal direction.
• Allows product structure configuration through revision rules and saved variant
rules during the creation of the tree.

Chapter 15 Traversal Engine
• Allows inputs from the command line and configuration file.
• Allows you to store and retrieve a float value with a key as a string, typically
used for summing up functionality.
With these features, you can develop programs that:

• Generate reports.
• Apply task release.
• Release assembly, set assembly precise, and other similar tasks
User Exits
Teamcenter provides user exits to register selectors and handlers that are executed
at different stages of the traversal activity, such as creation of the tree, traversing in
the forward direction, traversing in the reverse direction, and so on.
Selectors and handlers are user-defined functions that need to be developed following
a template. These functions return the decisions that determine the traversal
direction. These are registered at different stages of the traversal and are executed
during the creation and the traversal of the tree. The selectors are run during the
creation of the tree nodes. These determine the values stored in each node and
decide whether a particular branch needs to be traversed or not. The handlers are
run during the tree traversal. The handlers have the information of the node and
the information pertaining to the Teamcenter Engineering object that the node
represents.
For information regarding selectors, see the ITK Help. For information on
handlers, see Workflow Help.
Minimum Requirements
You need the following minimum requirements to run the Traversal Engine:
• The Teamcenter Engineering ITK development environment.
• To develop new programs in TE, knowledge of writing ITK programs is required.
Installation
To confirm that you have installed TE successfully, check if the following have been
added to their respective directories:
• The libitk.libraryextension library in the IMAN_ROOT/lib directory.
• ps_traverse executable in the $IMAN_ROOT/bin directory.
• The ps_traverse.cfg and te_template_itk_main.c files in the

IMAN_ROOT/sample/examples directory.

Traversal Engine
Developing a Traversal Program

Once you custom develop your selectors and handlers by using the ITK functions
and the TE API calls, you can compile them into an executable by using the compile
and linkitk scripts in the IMAN_ROOT/sample directory.
API calls are classified into:
• Initializing and terminating calls. TE modules have to be initialized to use any
TE call.
• Configure PS. These configure the PS using revision rule or saved variant. View
type to traverse also can be specified.
• Register handlers and selectors. These register the provided the functions as
selector or handler.
• Fill/Traverse. These create the tree and traverse the tree.
• User interface calls. These write messages to the log file and console and receive
input from the configuration file and the command line arguments.
Refer to the te.h header file in the IMAN_ROOT/include directory.
Sample Implementation
The te_template_itk_main.c file in the IMAN_ROOT/sample/examples directory
demonstrates TE functionality. It can be compiled and studied to understand how
new utilities can be developed.

Appendix
A Glossary

Appendix
A Glossary
This appendix defines Teamcenter Engineering terms.
Access Control List (ACL)

Access Manager component that contains a list of accessors and the privileges
granted, denied, and not set for each accessor.
Access Manager (AM)

Teamcenter Engineering application that enables the system administrator to grant
users access to Teamcenter Engineering objects.
ACL
See Access Control List (ACL).
Action Handler
Handler used to extend and customize task actions. Action handlers perform such
actions as displaying information, retrieving the results of previous tasks (inherit),
notifying users, setting object protections, and launching applications. See also
Task Handler.
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.
Active Mode
Management of application files in a way that allows their use by both an application
and Teamcenter Engineering. There are two categories of active interaction between
Teamcenter Engineering and an application: Encapsulation and Integration.
Compare with Passive Mode.
Aggregate Occurrence
Single occurrence using the quantity attribute to represent multiple uses of the same
component item. An aggregate occurrence is used where separate occurrences are
not required to distinguish individual uses (for example, transforms in NX). Rivets
are typically shown as an aggregate occurrence.
AIE
See Application Integration Environment.
ENG00043 A Integration Toolkit Programmer’s Guide A-1

Appendix A Glossary
AIWS
See Application Interface Web Service.
Allocation
Relationship between constituents of two structural views of a product, for example,
a relationship between constituents of the functional breakdown and the physical
breakdown of a product.
Alternate
Component that can be used interchangeably within an occurrence, typically for
manufacturing purposes. The preferred alternate is displayed in the structure.
AM
See Access Manager (AM).
Application Integration Environment

Teamcenter Engineering component for managing the import and export of
documents into Teamcenter Engineering. Application Integration Environment is
a common component across integrations that include applications in fields such
as CAE and ME.
Application Interface Web Service

Teamcenter Engineering extensions to a Web service such as gSOAP or WebLogic.
These extensions allow Teamcenter Engineering to share data in a collaboration
context with another application. Application Interface Web Service includes a
SOAP server. Application Interface Web Service components are installed and
deployed as part of the Web tier.
Architecture
Set of decisions, patterns, and principles for a product suite. The architecture
provides a framework for application development within that product suite and is
independent of specific functions.
Assembly
Compound object that is assembled from other objects and may add additional
information to their interpretation. In the context of an assembly, other assemblies
are called subassemblies, while noncompound objects are called components.
Attribute
Named storage variable that describes an object and is stored with the object. Users
can search the database for objects using the object’s attributes.
In an object, an attribute is a name/value pair; in the database, an attribute is a field.
Attribute Inheritance
Process by which a new class automatically inherits all the attributes defined for all
its parent classes.
Audit Definition
Object that creates audit logs to track selected properties for specified actions in
the database. These properties can include custom properties added by a system
administrator.
Audit Manager
Teamcenter Engineering application that enables a system administrator to
define audit definition objects, enable/disable audit trail logging, and control audit
A-2 Integration Toolkit Programmer’s Guide ENG00043 A

Glossary
log access. Audit definition objects create audit logs that users can view from
Teamcenter Engineering applications. Users can audit any Teamcenter Engineering
object and event type with an audit definition.
BLOB
Binary large object; attribute type of undefined structure. BLOBs are stored as
binary images within an object.
BOM
Bill of material. See also Design Bill of Material and Manufacturing Bill of Materials.
BOM View
Teamcenter Engineering object used to manage product structure information for
an item.
BOM View Revision (BVR)

Workspace object that stores the single-level assembly structure of an item revision.
Access can be controlled on the structure (BOM view revision) independently of
other data. BOM view revisions are only meaningful in the context of the item
revisions for which they are created.
Business Modeler
Teamcenter Engineering application that enables the system administrator to define
a set of business rules for administering the Teamcenter Engineering data model
behavior. The administrator can change the rules on the Teamcenter Engineering
data model using menus instead of writing code.
BVR
See BOM View Revision (BVR).
Class
Set of objects that share the same list of attributes but distinguishable by the value
the attributes acquire for specific objects. For example, the Automobile class can be
defined by the brand, color, and price, but each car associated to the Automobile
class has a different brand, color, and price combination.
Class Hierarchy
Structure defining subclasses that inherit the attributes of their superclasses, also
called their parents or ancestors.
Client
Role played by a software component of a system when it requests particular services
be performed on its behalf by another entity, a server. In the case of data migration,
the Migration Wizard is a client that gathers user input and requests services from
the TDS server. See also Server.
Client Tier
Teamcenter Engineering architectural tier that comprises the Teamcenter
Engineering clients, Teamcenter Engineering integrations with third-party
applications, such as Microsoft Office Integration and Teamcenter 2005 Integration

Appendix A Glossary
for AutoCAD, and the third-party applications themselves, such as Microsoft Office
and AutoCAD.
Closure Rule
In PLM XML, a rule that controls the scope of the PLM XML translation of data
imported to and exported from Teamcenter Engineering. Closure rules specify how
the data structure is traversed by specifying the relationships of interest and the
actions to occur when these relationships are encountered.
Component
Objects used to build up an assembly or subassembly.
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.
Configuration Rule
Rule that configures a structure. There are two kinds of configuration rules: revision
rule and variant rule.
Connection
Object that defines the connectivity between two or more terminals in a physical
model.
Corporate Server
Host computer at the center of a Teamcenter Engineering network. This host
contains the Teamcenter Engineering application root directory, Teamcenter
Engineering data directory, licensing, file managers (Teamcenter File Services and
File Management System), and volumes. For installations that include the Web
tier (four-tier architecture), the corporate server also contains the Teamcenter
Engineering server manager. Multiple application clients can map to or mount the
corporate server.
Dataset
Teamcenter Engineering workspace object used to manage data files created by other
software applications. Each dataset can manage multiple operating system files, and
each dataset references a dataset tool object and a dataset type object.
Dataset Tool
Teamcenter Engineering object that is the tool used to create or modify a dataset.
Dataset Type
Teamcenter Engineering object that contains a list of tools that can operate on a
dataset.
Derived Default
Default value that depends on a condition (for example, radio = stereo IF car type
= GLX). Compare with Fixed Default.

Glossary
Design Bill of Material

List of components and subassemblies used to define an assembly structure, and
the representation of the assembly structure itself. Compare with Manufacturing
Bill of Materials.
Direct Model Dataset

Dataset containing a JT (visualization) file.
Effectivity
Identification of the valid use of an aspect of product data tracked by date, event,
unit, or other scheme. You can specify a start definition, end definition, or both for
a particular effectivity.
Effectivity Rule
Rule used to set effective dates on released products and processes with a released
status.
Embedded Software Manager

Optional extension to PSE and My Navigator that allows you to manage embedded
software binaries as part of the product structure.
Encapsulation
Active-mode relationship between an application and Teamcenter Engineering in
which the application is brought into the Teamcenter Engineering environment.
Encapsulation allows you to launch the application using a Teamcenter Engineering
dataset object, export data to the application, work in the application, and import
data back into the Teamcenter Engineering database during a session. The import
and export operations between Teamcenter Engineering and the encapsulated
application are executed from within Teamcenter Engineering and the actual
transfer of files is transparent to the user. See also Active Mode and Integration.
Enterprise Process Modeling

Modeling used to accomplish workflow objectives. Enterprise process modeling
models workflow processes, allocates resources, and manages data according to
business rules.
Enterprise Tier
Teamcenter Engineering architectural tier that comprises a configurable pool of
Teamcenter Engineering C++ server processes and a server manager. Larger sites
can distribute the pool of server processes across multiple hosts. Smaller sites can
run the pool of servers on the same host as the Web tier.
Envelope
Teamcenter Engineering workspace object that represents a mail message sent by
a Teamcenter Engineering user. Envelopes can be used to send workspace object
references as well as text messages.
Equipment
Description of the equipment used to perform manufacturing operations.
ESM
See Embedded Software Manager.

Appendix A Glossary
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.
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.
Feature
Physical or geometric object associated with a product, component, or part.
Alternatively, a logical attribute of a product, component, or part. Examples: a weld
point, a signal, or a geometric pattern. A feature may be represented by a generic
design element (GDE) in a BOM. See also Generic Design Element.
File Management System (FMS)

System that manages uploading and downloading file data between clients and
volumes in both two-tier and four-tier architecture deployments. FMS provides
volume servers for file management, a shared server-level performance cache for
shared data access between multiple users, a client-based private user cache for
rich clients, and a transient data store mechanism for transporting reports, PLM
XML, and other nonvolume data between the enterprise and client tiers. FMS file
caching enables placing the data close to the user, while maintaining a central file
volume and database store.
Filter Rules
Rules that allow a fine level of control over which data is translated, in PLM XML
format, along with the primary objects by specifying that a user-written function be
called to determine the operation applied against a specified object.
Fixed Default
Default value for an option (for example, engine = 1200). A fixed default is attached
to an item revision, but is global to the BOM loaded in a Product Structure Editor
window. Compare with Derived Default.
FMS
See File Management System (FMS).
Folder
Graphical representation of an aggregation of objects, such as a group, class, or
subclass. For easy distinction in the class hierarchy, each of these aggregations has
a different type of folder icon associated with it: a group folder icon, a class folder
icon, or a subclass folder icon.
Form
Teamcenter Engineering workspace object used to display product information
(properties) in a predefined template. Forms are often used to create an electronic
facsimile of a hardcopy form in Teamcenter Engineering. See also Master Form.

Glossary
Four-Tier Architecture
Teamcenter Engineering architecture that includes four tiers: resource tier, client
tier, Web tier, and enterprise tier.
Four-Tier Deployment
Deployment of the Teamcenter Engineering four-tier architecture. The Web tier,
enterprise tier, resource tier, and client tier can each be hosted on the same or
separate computers.
GDE
See Generic Design Element.
Generic Design Element

BOM item that cannot have different revisions. See also Feature.
Group
Type of class that does not have a list of attributes associated with it; highest level
in the classification hierarchy.
Harness
Assembly of insulated conductors formed to a predetermined pattern or
configuration; also called a wiring harness.
Hierarchy
Structure in which each node can have only one parent but possibly multiple siblings
and children.
Imprecise Assembly
Single-level assembly that has items as the components. The revision is determined
by the revision rule settings. Compare with Precise Assembly.
Instance
Single data object that is associated to a class. The instance can correspond to a
line in the BOM.
Integration
Active-mode relationship between an application and Teamcenter Engineering in
which Teamcenter Engineering is brought into the application. The application
drives Teamcenter Engineering to provide the functionality, such as implicit
checkout when data is modified, and reading and writing data directly from
Teamcenter Engineering in a secured way. Data is exported (pushed) and imported
(pulled) as needed.
Interface Port
Single access point to the functionality of a piece of equipment, for example, a USB
port that provides an interface to a computer.

Appendix A Glossary
Internal Extension
Extension delivered as part of the Teamcenter product, also known as a canned
method.
Item
Workspace object generally used to represent a product, part, or component. Items
can contain other workspace objects including other items and object folders.
Item Revision
Workspace object generally used to manage revisions to items.
List of Values (LOV)

Teamcenter Engineering application that enables creation of lists of values to ensure
consistent data entries in the rich client. Teamcenter Engineering often requires a
specific format for data entries, rather than user-defined text entries. A list of values
provides users with a dropdown list of allowable entries.
LOV
See List of Values (LOV).
Manufacturing Bill of Materials

Defines how the product is manufactured, rather than how it is designed. Compare
with Design Bill of Material.
Master Form
Teamcenter Engineering workspace object used to display product information
(properties) in a predefined template. Master forms are used to display product
information in a standardized format.
Mechatronics
Integration of mechanical engineering with electronics and intelligent computer
control in the design and manufacture of products and processes.
Multi-Site Collaboration
Teamcenter Engineering capability that allows the exchange of data objects among
several Teamcenter Engineering databases. Transfer of objects among databases
is controlled by daemon processes running on designated servers. Objects are
replicated by exporting them from their original database and importing them into
the requesting database. Configuration of Multi-Site Collaboration is optional.
My Navigator
Teamcenter Engineering rich client application that is the main access point for
managing product information. My Navigator provides the functionality for creating
objects in the Teamcenter Engineering database, querying the database for objects,
checking in and checking out objects, and managing tasks. Users can also open
objects, automatically launching the related application.
Each user has a personal My Navigator window that displays product information as
graphical objects. Although users share product information across the enterprise,
they organize this information individually in personal workspaces.

Glossary
Named ACL
Named group of access controls. See also Access Control List (ACL).
Named Reference
File types that are managed by a dataset. Datasets are the only workspace objects
that use named references.
Node
Point of interest in a harness. It may represent the beginning or end of a segment.
Note
Assembly-related textual data associated with an occurrence. A note specifies a
value associated with the assembly-component relationship. For example, the torque
value for a bolt of 10 Ft Lb in one assembly and 15 Ft Lb in another assembly.
Note Type
Type created by the system administrator that is associated with an occurrence in a
product structure and enables users to specify a note.
Occurrence
Hierarchical structure relationship between the immediate parent assembly and
its child component item or item revision in a precise assembly. Sometimes called
relative occurrence.
Organization
Teamcenter Engineering application that enables a system administrator to create
and manage critical Teamcenter Engineering files and database entries. It is the
point of access for creating a company’s virtual organization and for performing
system administration activities such as volume creation, maintenance, and site
administration. Organization enables creation and management of person, user,
role, and group definitions; definition of the hierarchical structure of the Teamcenter
Engineering organization; management of data volumes; and establishment and
maintenance of Teamcenter Engineering sites.
Owner
User that owns an object, initially the user who created it. Ownership can be
transferred from the owner to another user. An object owner usually has privileges
that are not granted to other users (for example, the privilege to delete the object).
Owning Group
Group that owns an object, usually the group of the user creating the object. Because
users commonly share data with other members of a group, additional privileges may
be granted to the owning group (for example, the privilege to write to the object).
Owning Site
Multi-Site Collaboration site where the master object resides. The owning site is the
only site where the object can be modified.

Appendix A Glossary
Passive Mode
Management of application files from outside an application. Users do not have
access to Teamcenter Engineering while running the application in passive mode.
Data must be exported (pushed) from Teamcenter Engineering to the application
before it can be worked on and then imported (pulled) into Teamcenter Engineering
after it has been modified. Compare with Active Mode.
Persistent Object Manager (POM)

Interface between Teamcenter Engineering objects and the Relational Database
Management System (RDBMS). The persistent object manager provides definition of
classes by inheritance from existing classes and definition of attributes, manipulation
of in-memory objects and support for their saving and retrieval to and from the
underlying RDBMS, support for applications accessing the same data concurrently,
protection against the deletion of data used by more than one application, and
support for the access control lists attributed to objects.
Person
Definition containing real-world information about each Teamcenter Engineering
user, such as name, address, and telephone number. Person definitions are stored
as simple text strings so that they can be easily changed and updated. The name
must be unique.
Piece Part
Part with no structure (no associated BOM view revision).
PLM XML
UGS format for facilitating product life cycle interoperability using XML. PLM XML
is open and based on standard W3C XML schemas. Representing a variety of product
data both explicitly and via references, PLM XML provides a lightweight, extensible,
and flexible mechanism for transporting high-content product data over the Internet.
POM
See Persistent Object Manager (POM).
Port
Occurrence of an interface port that represents the access point of a functional
module in a given context, for example, a USB 2.0 port on a computer processor.
Precise Assembly
Single-level assembly that has item revisions as the components. The item revision
is configured by a precise entry in a revision rule. Compare with Imprecise Assembly.
Preference
Configuration variable stored in a Teamcenter Engineering database and read when
a Teamcenter Engineering session is initiated. Preferences allow administrators and
users to configure many aspects of a session, such as user login names and the
columns displayed by default in a properties table.
Process
Automation of a business procedure, describing the individual tasks and task
sequences required to complete a business procedure.

Glossary
Product
Item or assembly (hierarchy of components and subassemblies) to be manufactured.
Product Structure
Hierarchy of assembly parts and component parts with a geometric relationship
between them, for example, a bill of materials (BOM). Variant and revision rules
define the generic BOM. This BOM can then be loaded to display the configured
variant.
Product Structure Editor

Teamcenter Engineering application that enables creation of generic product
structures that can be configured to show the product structure that is in production,
effective on a certain date, used by a particular customer, and so forth. Product
Structure Editor enables creation and modification of a product structure and its
associated occurrence data, display of a product structure in a multilevel indented
bill of materials (BOM) format, and viewing graphics tightly coupled to the structure
for easy identification of a component by location in the structure or in the graphics
viewer.
Properties File
File containing the attributes (keys and values) that specify how an application is
to behave in the Teamcenter Engineering rich client.
PSE
See Product Structure Editor.
Pseudo Folder
Special container in Teamcenter Engineering that stores and displays item and
item revision relations in My Navigator.
Registry File
Properties (.properties) file that contains the user-defined configuration settings
(keys and values) that are relative to how the application displays and performs in
the Teamcenter Engineering rich client. Each application registered in the rich
client has a .properties file known as a registry file.
Relation
Description of an association between a Teamcenter Engineering object and a piece
of information that describes or is related to the object.
Resource
Item used to perform an operation or define a process. Examples of resources include
robots, tools, and machines. Both standard equipment and custom tools can be
identified as resources.
Resource Tier
Teamcenter Engineering architectural tier comprising the database server, database,
file servers, and volumes.
Revision Rule
Parameter set by the user that determines which revision of an item is used to
configure product context.

Appendix A Glossary
Rich Client
Java-based user interface to Teamcenter Engineering installed on user workstations.
The rich client accesses Teamcenter Engineering databases using a remote or local
server.
Root
Starting point of a hierarchy. Hierarchies are usually displayed as hanging trees
with the root of the structure at the top and the leaves at the bottom.
Route
Course taken by wire or connection from a starting point to a destination.
Rule Handler
Handler used to integrate workflow business rules into Enterprise Process Modeling
processes at the task level. Rule handlers attach conditions to an action. See also
Task Handler.
Schema Editor
Teamcenter Engineering application that provides a graphical means for system
administrators to create, modify, and view Teamcenter Engineering database schema
definitions and attributes in Teamcenter Engineering rich client.
Segment
Section of a connection where no intermediate electrical contacts appear.
Sequence Number
Number that identifies individual occurrences (or groups of occurrences) within
a single-level assembly. Components are ordered by sequence number within an
assembly.
Server
System software component that performs a specifically defined set of software
services on behalf of one or more clients. In a typical Teamcenter Engineering
installation, servers are centralized on dedicated hosts that support a large number
of clients. Clients are distributed on hosts connected to the servers via various
networking techniques. See also Client.
Server Manager
Process that manages a pool of Teamcenter Engineering server processes in a
deployment of the four-tier architecture. The server manager starts and times out
a configurable number of server processes to communicate with the Teamcenter
Engineering database. A server assigner process assigns available server processes
to user sessions. The server manager communicates with the Web tier application
using either TCP or multicast protocol.
Signal
Physical (electrical) means of transferring a message from one system to another.
Site
Individual installation of Teamcenter Engineering comprising a single Teamcenter
Engineering database, all users accessing that database, and additional resources
such as hardware, networking capabilities, and third-party software applications
(tools) required to implement Teamcenter Engineering at that site.

Glossary
Site ID
Unique identifier of a Teamcenter Engineering site. The site ID is used to generate
internal identifiers for Teamcenter Engineering objects that must be unique
throughout an enterprise. Once established, site IDs should not be modified.
Site Name
Unique name of a Teamcenter Engineering site stored in the database as a
user-defined character string.
Site Preference
Teamcenter Engineering preference that applies to the entire site.
SQL
See Structured Query Language.
Structure
Representation of multiple objects and their interdependencies. For example, a
classification structure represents classes and their inheritance dependencies,
and an assembly structure represents how components and subassemblies are
associated to build up an assembly. The structure can be viewed in several
applications, including Product Structure Editor, Manufacturing Structure Editor,
Part Manufacturing Planner, Collaboration Context, and Resource Manager.
In Resource Manager, most structures are hierarchical. For example, they acquire
the form of a tree where each node can have only one parent but multiple siblings
and children.
Structured Query Language

ANSI standard command and embedded language for manipulating data in a
relational database.
Subclass
In the Classification Search dialog, subclass instances represent a subset of
attributes corresponding to a class. Subclasses inherit the attributes of their parent
classes. Unlike classes, which inherit every attribute of their parent classes and
cannot be edited, users can define the inherited attributes assigned to a subclass.
Teamcenter Engineering user who is a member of the system administration group.
Task
Fundamental building block used to construct a process. Each task defines a set of
actions, rules, and resources used to accomplish that task.
Task Handler
Small Integration Toolkit program or function. Handlers are the lowest level
building blocks in Enterprise Process Modeling. They are used to extend and
customize tasks. There are two kinds of handlers: action handlers and rule handlers.
TCFS
See Teamcenter File Services (TCFS).

Appendix A Glossary
Teamcenter Engineering Application Root Directory

Directory location of the Teamcenter Engineering shared binary executables. The
IMAN_ROOT environment variable defines this location. Generally, the contents of
this directory change only with a new version of Teamcenter Engineering.
Teamcenter Engineering Data Directory

Directory location of the Teamcenter Engineering shared data subdirectories and
files. The IMAN_DATA environment variable defines this location. Each data
directory is associated with a single database instance.
Teamcenter Engineering Data Integration Services Adapter

Teamcenter Engineering software component that integrates Teamcenter
Visualization with both the thin client (HTML and DHTML) and the rich client.
Teamcenter Engineering Option

See Preference and User Preference.
Teamcenter Engineering Visualization

Optional Teamcenter Engineering rich client component that provides
enterprise-wide product visualization capabilities and is embedded in the rich
client interface. Four Teamcenter Engineering Visualization products provide
different visualization capabilities. Teamcenter Engineering Visualization Base
provides basic 2D and 3D viewing. Teamcenter Engineering Visualization Standard,
Teamcenter Engineering Visualization Professional, and Teamcenter Engineering
Visualization Mockup provide increasing functionality.
Teamcenter File Services (TCFS)

File services that enable the Organization application to create volumes and perform
other administrative functions. TCFS also supports file access for legacy versions
of NX and Teamcenter Visualization.
Teamcenter Security Services

Services that eliminate prompts for login credentials when users switch Teamcenter
products within a user session. Authentication is performed by an external identity
service provider, such as Lightweight Directory Access Protocol (LDAP), instead
of the Teamcenter product. At a site that deploys multiple Teamcenter products
and Teamcenter Security Services, users log in once to access all participating
Teamcenter products.
Teamcenter Visualization
UGS software suite that provides enterprise-wide product visualization capabilities.
Teamcenter Visualization can be configured for use with both the Teamcenter
Engineering rich client and thin client as a standalone application. Configuring
Teamcenter Visualization for use with the rich client or thin client requires installing
and configuring Teamcenter Engineering Data Integration Services Adapter.
The software suite includes Teamcenter Visualization Base, Teamcenter
Visualization Standard, Teamcenter Visualization Professional, and Teamcenter
Visualization Mockup.
Thin Client
Teamcenter Engineering user interface that provides a streamlined browser-based
view of product information stored in a Teamcenter Engineering database. The
thin client is configured in the Web tier, which creates and serves its Web pages
to the client.

Glossary
Top Level
Object at the root of a product structure where a process plan is being developed.
The top level can be either an end product being manufactured or a subassembly
used in the end product (for example, an engine for a tractor where the tractor is
the end product).
Transfer Mode
Objects composed of rules that configure PLM XML import and export operations.
Transfer mode allows users to import and export data with little knowledge other
than the name of the transfer mode object.
Type
Teamcenter Engineering application that enables a system administrator to create
and maintain user-defined display names for database object types (item, form,
dataset, tool, alias, folder, status, view, note, unit of measure, relation, and storage
media). An administrator can create multiple user representations that are
identified as belonging to a type of object class in Teamcenter Engineering.
User
Definition that is the mechanism by which Teamcenter Engineering identifies and
interacts with each user. User definitions contain a name (derived from the person
definition), user ID, operating system name, and password.
User Preference
Teamcenter Engineering preference applying to a specific user.
Value
Content of a field or variable. It can refer to alphabetic, numeric, or alphanumeric
data.
Variant BOM
BOM configured by applying a variant rule.
Variant Condition
Condition set on an occurrence to specify the option values required to configure that
occurrence (for example, Load IF engine = 1200).
Variant Rule
Collection of option values used in determining the variant of the BOM to be
configured (for example, car type = GLS, engine = 1200, gearbox = manual).
View Type
Attribute of a BOM view revision. The view type specifies the BOM view revision’s
intended use (for example, design or manufacture). The view type distinguishes one
BOM view revision from another BOM view revision of the same item revision.
Visualization
Ability to display a realistic, real time, graphical visualization of geometric data.

Appendix A Glossary
Volume
Operating system directory controlled by Teamcenter Engineering and used to store
the files managed by Teamcenter Engineering. When a user performs an action that
causes Teamcenter Engineering to create a file, the file is created in the Teamcenter
Engineering volume. Users cannot directly access the files in Teamcenter
Engineering volumes; they must do so via a Teamcenter Engineering session.
Web Tier
Teamcenter Engineering architectural tier that comprises a Java application
running in a Java 2 Enterprise Edition (J2EE) application server. The Web tier
is responsible for communication between the client tier and enterprise tier. The
Web tier application also includes the Application Interface Web Service (AIWS),
WebDAV service, Teamcenter Engineering DIS Adapter, and thin client.
Workflow
Automation of the concept that all work flows through one or more business
processes to accomplish an objective. Using workflow, documents, information, and
tasks are passed between participants during the completion of a particular process.
Workflow Designer
Teamcenter Engineering application that enables administrators to graphically
design workflow process templates, incorporating company business practices and
procedures into the templates. Teamcenter Engineering users initiate workflow
processes using these templates.
World
All users regardless of group or role.

Index
A BOM compare . . . . . . . . . . . . . . . . . . . 8-14

Access control list . . . . . . . . . . . . . . . . 9-19 Aggregate element uniqueness . . . . . 8-21
Access control object model . . . . . . . . . . 4-8 Auto pack . . . . . . . . . . . . . . . . . . . . 8-18
Access Manager . . . . . . . . . . . . . . . . . . 7-2 Cache method type . . . . . . . . . . . . . . 8-23
Access Manager, custom privileges . . . . . 7-2 Caching . . . . . . . . . . . . . . . . . . . . . 8-18
ACL, see Access control list Column output order . . . . . . . . . . . . 8-23
Action handler . . . . . . . . . . . . . . . . . . . 7-4 Compare aggregate method type . . . . 8-23
Action handlers . . . . . . . . . 10-3, 10-7, 10-18 Compare object method type . . . . . . . 8-23
Adding canned methods . . . . . . . . . . . . 6-40 Defining a BOM compare . . . . . . . . . 8-15
Adobe Acrobat Reader . . . . . . . . . . . . . . 14 Display elements . . . . . . . . . . . . . . . 8-20
AIE . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Element application flags . . . . . . . . . 8-22
AIWS . . . . . . . . . . . . . . . . . . . . . . . 2-2, 3-1 Element display aliasing . . . . . . . . . 8-18
Allocation object . . . . . . . . . . . . . . . . . 14-1 Element display suppression . . . . . . . 8-18
AllocationMap object . . . . . . . . . . . . . . 14-1 Element naming . . . . . . . . . . . . . . . 8-18
Application encapsulation object Element ordering modifier . . . . . . . . 8-21
model . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Execution . . . . . . . . . . . . . . . . 8-20, 8-25
Application Integration Environment . . . 3-2 Free cache method type . . . . . . . . . . 8-23
Application Interface Web Service . . 2-2, 3-1 Method types . . . . . . . . . . . . . . . . . . 8-23
Architecture . . . . . . . . . . . . . . . . . . . . . 2-1 Mode . . . . . . . . . . . . . . . . . . . . . . . 8-15
Attachments . . . . . . . . . . . . . . . . . . . . 10-6 Non-property elements . . . . . . . . . . . 8-24
Attribute . . . . . . . . . . . . . . . . . . . . . . 6-30 Object output order . . . . . . . . . . . . . 8-22
Attribute expressions . . . . . . . . . . . . . 9-34 Output . . . . . . . . . . . . . . . . . . . . . . 8-28
Attribute manipulation . . . . . . . . . . . . 9-11 Output suppression . . . . . . . . . . . . . 8-31
Audit Manager . . . . . . . . . . . . . . . . . . . 7-4 Performing . . . . . . . . . . . . . . . . . . . 8-27
Automatic forms . . . . . . . . . . . . . 12-4–12-5 Report output . . . . . . . . . . . . . . . . . 8-30
Creating the form type . . . . . . . . . . . 12-5 UI suppression . . . . . . . . . . . . . . . . 8-18
Extending the schema . . . . . . . . . . . 12-5 UIF name method type . . . . . . . . . . . 8-23
UIF value method type . . . . . . . . . . . 8-23
User exits . . . . . . . . . . . . . . . . . . . . 8-28
B Virtual unpack . . . . . . . . . . . . . . . . 8-18
b_curve class . . . . . . . . . . . . . . . . . . . 14-4 Visitor . . . . . . . . . . . . . . . . . . . . . . 8-32
Base action . . . . . . . . . . . . . . . . . . . . . 6-33 BOMView . . . . . . . . . . . . . . . . . . . . . . . 4-6
Batch ITK programs . . . . . . . . . . 5-21, 5-23 BOMView revision . . . . . . . . . . . . . . . . 4-6
Best practices . . . . . . . . . . . . . . . . . . . 6-50 Business Modeler . . . . . . . . . . . . . . . . . 7-5
Bill of materials, see BOM BMOperation class . . . . . . . . . . . . . . 7-18
BMOperation class . . . . . . . . . .. . . . . 7-18 BusinessRuleDescriptor class . . . . . . 7-19
BOM . . . . . . . . . . . . . . . . . . . .. . . . . . 8-1 Classes . . . . . . . . . . . . . . . . . . . . . . 7-18
Editing the BOM . . . . . . . . . .. . . . . . 8-3 Extension class . . . . . . . . . . . . . . . . 7-18
Occurrence sequencing . . . . . .. . . . . . 8-3 ExtensionDescriptor class . . . . . . . . . 7-18
Occurrences . . . . . . . . . . . . . .. . . . . . 8-9 ExtensionPoint class . . . . . . . . . . . . 7-18
Options . . . . . . . . . . . . . . . . .. . . . . . 8-9 Extensions . . . . . . . . . . . . . . . . . . . . 7-7
Producing a report . . . . . . . . .. . . . . . 8-2 PropertyBMOperation class . . . . . . . 7-19
Product structure relationship . . . . . 8-43 TypeBMOperation class . . . . . . . . . . 7-19
Variations . . . . . . . . . . . . . . .. . . . . . 8-9 User exits . . . . . . . . . . . . . . . . . . . . . 7-5
ENG00043 A Integration Toolkit Programmer’s Guide Index-1

Index
Business rule handlers . . . . . . . . . . . . 10-6 ImanVolume . . . . . . . . . . . . . . . . . . 6-19

BusinessRuleDescriptor class . . . . . . . . 7-19 Item . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Item revision . . . . . . . . . . . . . . . . . . 6-11
C ItemMaster . . . . . . . . . . . . . . . . . . . 6-24
Person . . . . . . . . . . . . . . . . . . . . . . 6-17
Canned methods POM_application_object is Abstract . . . 6-7
Adding . . . . . . . . . . . . . . . . . . . . . . 6-40 POM_group . . . . . . . . . . . . . . . . . . . . 6-3
Client side changes . . . . . . . . . . . . . 6-48 POM_member . . . . . . . . . . . . . . . . . . 6-6
Server side changes . . . . . . . . . . . . . 6-41 POM_object is Abstract . . . . . . . . . . . 6-2
Cascade Release . . . . . . . . . . . . . . . . 10-20 POM_system_class is Abstract . . . . . . 6-3
Caveats . . . . . . . . . . . . . . . . . . . . . . . . 1-2 POM_user . . . . . . . . . . . . . . . . . . . . . 6-4
Check reference . . . . . . . . . . . . . . . . . 9-14 RevisionAnchor . . . . . . . . . . . . . . . . 6-23
Class . . . . . . . . . . . . . . . . . . . . . . . . . 6-30 Role . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Class hierarchy . . . . . . . . . . . . . . . 4-11, 5-3 Signoff . . . . . . . . . . . . . . . . . . . . . . 6-16
Class of instances . . . . . . . . . . . . . . . . 9-11 Status . . . . . . . . . . . . . . . . . . . . . . . 6-16
Classes Tool . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Business Modeler . . . . . . . . . . . . . . . 7-18 Unit of measure . . . . . . . . . . . . . . . . 6-25
IMANComponentForm . . . . . . . . . . 12-11 User . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
IMANFormProperty . . . . . . . . . . . . 12-11 WorkspaceObject is Abstract . . . . . . . . 6-8
Client tier . . . . . . . . . . . . . . . . . . . . . . 2-1 Create instance . . . . . . . . . . . . . . . . . . . 9-7
Code conventions . . . . . . . . . . . . . . . . . 12 Creating form panels . . . . . . . . . . . . . . 12-6
com.ugsolutions.iman.stylesheet. Custom hooks . . . . . . . . . . . . . . . . . . . 5-24
stylesheet_user.properties . . . . . . . . 12-14 Custom library . . . . . . . . . . . . . . . . . . 5-24
Command line entry conventions . . . . . . 12 CUSTOM_execute_callbacks . . . . . . . . 5-31
Command line switches . . . . . . . . . . . . . 1-2 CUSTOM_execute_callbacks_
Compatibility . . . . . . . . . . . . . . . . . . . . 1-1 from_library . . . . . . . . . . . . . . . . . . . 5-32
Compiling . . . . . . . . . . . . . . . . . . . . . 5-17 CUSTOM_register_callbacks . . . . . . . . 5-30
Compiling batch programs . . . . . . . . . . 5-23 CUSTOM_register_exit . . . . . . . . . . . . 5-30
Compiling commands . . . . . . . . . . . . . 5-13 Customization . . . . . . . . . . . . . . . . . . 6-50
Components Adding a compound property . . . . . . . 6-57
JPanel . . . . . . . . . . . . . . . . . . . . . 12-14 Adding a new relation type . . . . . . . . 6-52
Connection object . . . . . . . . 14-1, 14-7, 14-9 Adding a persistent property . . . . . . . 6-53
Connection_Terminal object . . . . . . . . . 14-1 Adding a property from a relation . . . 6-55
Conventions Adding a runtime property . . . . . . . . 6-56
Caution icons . . . . . . . . . . . . . . . . . . . 11 Adding a subclass . . . . . . . . . . . . . . 6-51
Code . . . . . . . . . . . . . . . . . . . . . . . . . 12 Common scenarios . . . . . . . . . . . . . . 6-50
Command line entries . . . . . . . . . . . . 12 Customizing the master suffix . . . . . . 6-58
File contents . . . . . . . . . . . . . . . . . . . 12 Customizing type behavior . . . . . . . . 6-57
Names . . . . . . . . . . . . . . . . . . . . . . . 11 Display names . . . . . . . . . . . . . . . . . 6-61
Note icons . . . . . . . . . . . . . . . . . . . . . 11 Hiding properties . . . . . . . . . . . . . . . 6-61
Syntax definitions . . . . . . . . . . . . . . . 13 Hints . . . . . . . . . . . . . . . . . . . . . . . 6-59
Values . . . . . . . . . . . . . . . . . . . . . . . . 11 Memory allocation . . . . . . . . . . . . . . 6-59
Warning icons . . . . . . . . . . . . . . . . . . 11 Messages . . . . . . . . . . . . . . . . . . . . 6-60
Copy instance . . . . . . . . . . . . . . . . . . . . 9-7 Method arguments . . . . . . . . . . . . . . 6-59
Core classes . . . . . . . . . . . . . . . . . . . . . 6-1 New type . . . . . . . . . . . . . . . . . . . . . 6-51
Dataset . . . . . . . . . . . . . . . . . . . . . . 6-12 Tools and techniques . . . . . . . . . . . . 6-50
DatasetType . . . . . . . . . . . . . . . . . . 6-22 Value caching . . . . . . . . . . . . . . . . . 6-60
DistributionList . . . . . . . . . . . . . . . . 6-16 Workspace columns . . . . . . . . . . . . . 6-62
Envelope . . . . . . . . . . . . . . . . . . . . . 6-10
Folder . . . . . . . . . . . . . . . . . . . . . . . 6-10 D
Form . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Group . . . . . . . . . . . . . . . . . . . . . . . . 6-4 Data definition services . . . . . . . . . . . . . 9-3
GroupMember . . . . . . . . . . . . . . . . . . 6-6 Data manipulation services . . . . . . . . . . 9-7
ImanFile . . . . . . . . . . . . . . . . . . . . . 6-20 Class of instances . . . . . . . . . . . . . . . 9-11
Index-2 Integration Toolkit Programmer’s Guide ENG00043 A

Index
Copy instance . . . . . . . . . . . . . . . . . . 9-7 Business Modeler . . . . . . . . . . . . . . . . 7-7

Create instance . . . . . . . . . . . . . . . . . 9-7
Delete instances . . . . . . . . . . . . . . . . . 9-9 F
Inquiries to find instances . . . . . . . . . 9-11
Instances of class . . . . . . . . . . . . . . . 9-10 File contents conventions . . . . . . . . . . . . 12
Load instances . . . . . . . . . . . . . . . . . . 9-8 File Management System . . . . . . . . . . . 2-2
Order instance . . . . . . . . . . . . . . . . . 9-10 File relocation . . . . . . . . . . . . . . . . . . . 6-26
Reference of instance . . . . . . . . . . . . 9-10 Files
Refresh instances . . . . . . . . . . . . . . . . 9-9 com.ugsolutions.iman.stylesheet.
Save instances . . . . . . . . . . . . . . . . . . 9-8 stylesheet_user.properties . . . . . 12-14
Select instance . . . . . . . . . . . . . . . . . 9-10 stylesheet_user.properties . . . . . . . . . 12-6
Unload instance . . . . . . . . . . . . . . . . . 9-9 Folder class . . . . . . . . . . . . . . . . . . . . 6-10
Data types . . . . . . . . . . . . . . . . . . . . . 5-12 Form beans
Dataset class . . . . . . . . . . . . . . . . . . . 6-12 Developing . . . . . . . . . . . . . . . . . . 12-15
Dataset object model . . . . . . . . . . . . . . . 4-7 Location . . . . . . . . . . . . . . . . . . . . 12-13
DatasetType class . . . . . . . . . . . . . . . . 6-22 Using . . . . . . . . . . . . . . . . . . . . . . 12-14
Debug . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Form class . . . . . . . . . . . . . . . . . . . . . 6-15
Default behavior . . . . . . . . . . . . . . . . . 6-29 Form Events . . . . . . . . . . . . . . . . . . . 12-12
Delete instances . . . . . . . . . . . . . . . . . . 9-9 Form object model . . . . . . . . . . . . . . . . . 4-7
Developing forms using XML style Form properties
sheets . . . . . . . . . . . . . . . . . . . . . . . 12-16 Obtaining . . . . . . . . . . . . . . . . . . . 12-11
dialogDisplayed () method . . . . . . . . . 12-12 Saving . . . . . . . . . . . . . . . . . . . . . 12-11
Displaying form properties . . . . . . . . . 12-17 Form property display keys . . . . . . . . 12-17
Displaying regular properties . . . . . . . 12-16 Format of functions . . . . . . . . . . . . . . . . 5-1
DistributionList class . . . . . . . . . . . . . 6-16 Forms
Documentation . . . . . . . . . . . . . . . . . . . 14 Abstract rendering . . . . . . . . . . . . . . 12-4
Online help . . . . . . . . . . . . . . . . . . . . 14 Automatic . . . . . . . . . . . . . . . . . . . . 12-4
Printable files . . . . . . . . . . . . . . . . . . 14 Comments . . . . . . . . . . . . . . . . . . . 12-10
Customizing . . . . . . . . . . . . . . . . . . 12-8
E Definition . . . . . . . . . . . . . . . . . . . . 12-8
Developing
Enterprise Process Modeling Abstract class extension . . . . . . . 12-6
customizing . . . . . . . . . . . . . . . . . . . 10-7 Automatic . . . . . . . . . . . . . . . . . 12-5
Enterprise Process Modeling module . . 10-1 JavaBeans . . . . . . . . . . . . . . . 12-13
Enterprise Process Modeling object Developing using XML style
model . . . . . . . . . . . . . . . . . . . . . . . . 10-2 sheets . . . . . . . . . . . . . . . . . . . 12-16
Enterprise tier . . . . . . . . . . . . . . . . . . . 2-2 Display components . . . . . . . . . . . . . 12-2
Envelope class . . . . . . . . . . . . . . . . . . 6-10 Displaying . . . . . . . . . . . . . . . . . . . . 12-3
EPM, see Enterprise Process Modeling JavaBean . . . . . . . . . . . . . . . . . . . . 12-4
Errors . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Model . . . . . . . . . . . . . . . . . . . . . . . 12-2
Customizing . . . . . . . . . . . . . . . . . . 13-1 Performance issues . . . . . . . . . . . . 12-11
Defining . . . . . . . . . . . . . . . . . . . . . 13-1 Types . . . . . . . . . . . . . . . . . . . . . . . 12-4
Examples XML style sheet . . . . . . . . . . . . . . . . 12-4
UI form . . . . . . . . . . . . . . . . . . . . . . 12-6 Four-tier architecture . . . . . . . . . . . . . . 2-1
Executing multiple customizations . . . . 5-29 Function format . . . . . . . . . . . . . . . . . . 5-1
Export objects . . . . . . . . . . . . . . . 11-1–11-2 Functionality object . . . . . . . 14-1, 14-5–14-7
Object types . . . . . . . . . . . . . . . . . . 11-1 FunctionalityRevision object . . . . . . . 14-1,
Restrictions and responsibilities . . . . 11-3 14-5–14-6
Route . . . . . . . . . . . . . . . . . . . . . . . 11-2
Exporting symbols . . . . . . . . . . . . . . . 5-16 G
Extension class . . . . . . . . . . . . . . . . . . 7-18
ExtensionDescriptor class . . . . . . . . . . 7-18 GDE object . . . . . . . . . . . . . . . . . . . . . 14-1
ExtensionPoint class . . . . . . . . . . . . . . 7-18 GDELink object . . . . . . . . . . . . . . . . . 14-1
Extensions GDEOccurrence object . . . . . . . . . . . . . 14-1

Index
Generic shell . . . . . . . . . . . . . . . . . . . . 3-2 L

Getting attributes of loaded instances . . 9-13
Group class . . . . . . . . . . . . . . . . . . . . . 6-4 libuser_exits.dll . . . . . . . . . . . . . . . . . 5-16
GroupMember class . . . . . . . . . . . . . . . . 6-6 License agreement . . . . . . . . . . . . . . . . 1-1
Groups . . . . . . . . . . . . . . . . . . . . . . . . 9-15 Linking
batch programs . . . . . . . . . . . . . . . . 5-23
server exits in Windows . . . . . . . . . . 5-17
H Standalone programs . . . . . . . . . . . . 5-13
.h files . . . . . . . . . . . . . . . . . . . . . . . . 5-10 user exits in UNIX and Linux . . . . . . 5-14
Harness model support . . . . . . . . . . . . 14-4 user exits in Windows . . . . . . . . . . . 5-15
Hierarchy of classes . . . . . . . . . . . 4-11, 5-3 linkitk . . . . . . . . . . . . . . . . . . . . . . . . 5-14
List of Values . . . . . . . . . . . . . . . . . . . . 7-1
Exhaustive . . . . . . . . . . . . . . . . . . . . 7-1
I Instance properties . . . . . . . . . . . . . . 7-1
Icon conventions . . . . . . . . . . . . . . . . . . 11 Range . . . . . . . . . . . . . . . . . . . . . . . . 7-1
ImanFile class . . . . . . . . . . . . . . . . . . 6-20 Runtime properties . . . . . . . . . . . . . . 7-1
ImanVolume class . . . . . . . . . . . . . . . . 6-19 Suggested . . . . . . . . . . . . . . . . . . . . . 7-1
Import objects . . . . . . . . . . . . . . . . . . . 11-1 Type properties . . . . . . . . . . . . . . . . . 7-1
Interface . . . . . . . . . . . . . . . . . . . . . 11-6 Load instances . . . . . . . . . . . . . . . . . . . 9-8
Object types . . . . . . . . . . . . . . . . . . 11-1 loadRendering() method . . . . . . . . . . . . 12-6
Restrictions . . . . . . . . . . . . . . . . . . . 11-5 Logging . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Route . . . . . . . . . . . . . . . . . . . . . . . 11-4 LOV, see List of Values
Semantics . . . . . . . . . . . . . . . . . . . . 11-4
Inbox queries . . . . . . . . . . . . . . . . . . 10-19 M
Include files . . . . . . . . . . . . . . . . . . . . 5-10
Inheritance . . . . . . . . . . . . . . . . . 4-13, 6-37 Manifestation . . . . . . . . . . . . . . . . . . . . 4-4
Initializing modules . . . . . . . . . . . . . . 5-12 Manual set . . . . . . . . . . . . . . . . . . . . . . 14
Inquiries to find instances . . . . . . . . . . 9-11 Master form . . . . . . . . . . . . . . . . . . . . . 4-3
Instances of class . . . . . . . . . . . . . . . . 9-10 Mechatronics
Interface components API modules . . . . . . . . . . . . . . . . . . 14-4
InterfaceBufferedPropertyComponent . . 12-15 API use . . . . . . . . . . . . . . . . . . . . . . 14-4
InterfacePropertyComponent . . . . . 12-15 Fundamental objects . . . . . . . . . . . . 14-1
InterfaceRendererEvent . . . . . . . . . 12-12 Harness model support . . . . . . . . . . . 14-4
Interface Port object . . . . . . . . . . . . . . 14-6 Object model . . . . . . . . . . . . . . . . . . 14-3
InterfaceBufferedPropertyComponent Objects . . . . . . . . . . . . . . . . . . . . . 14-1,
component . . . . . . . . . . . . . . . . . . . 12-15 14-5–14-7, 14-9–14-11, 14-13–14-14
InterfacePropertyComponent Preferences . . . . . . . . . . . . . . . . . . . 14-2
component . . . . . . . . . . . . . . . . . . . 12-15 Relationships . . . . . . . . . . . . . . . . . . 14-2
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Memory management . . . . . . . . . . . . . 5-10
Modifying . . . . . . . . . . . . . . . . . . . . . 4-6 Message . . . . . . . . . . . . . . . . . . . . . . . 6-30
Item and item revision object model . . . . 4-1 Message ID . . . . . . . . . . . . . . . . . . . . 6-37
Item class . . . . . . . . . . . . . . . . . . . . . . 6-11 Message identification . . . . . . . . . . . . . 6-34
Item revision . . . . . . . . . . . . . . . . . . . . 4-3 Messages
Modifying . . . . . . . . . . . . . . . . . . . . . 4-6 Customizing . . . . . . . . . . . . . . . . . . 13-1
Item revision class . . . . . . . . . . . . . . . 6-11 Defining . . . . . . . . . . . . . . . . . . . . . 13-1
Item type . . . . . . . . . . . . . . . . . . . . . . . 4-6 Method . . . . . . . . . . . . . . . . . . . . . . . 6-30
ItemMaster class . . . . . . . . . . . . . . . . 6-24 Method registration . . . . . . . . . . . . . . . 6-34
ITK . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Methods . . . . . . . . . . . . . . . . . . . 6-29, 6-33
Actions . . . . . . . . . . . . . . . . . . . . . . 6-33
J dialogDisplayed () . . . . . . . . . . . . . 12-12
Inheritance . . . . . . . . . . . . . . . . . . . 6-33
Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 loadRendering() . . . . . . . . . . . . . . . . 12-6
Journal files . . . . . . . . . . . . . . . . . . . . . 5-4 okToModify() . . . . . . . . . . . . . . . . . 12-12
JPanel component . . . . . . . . . . . . . . . 12-14 Property . . . . . . . . . . . . . . . . . . . . . 6-37

Index
RenderingLoader.load() . . . . . . . .. . 12-3 Class_id . . . . . . . . . . . . . . . . . . . . . 9-13

save() . . . . . . . . . . . . . . . . . . . . .. 12-15 Concepts . . . . . . . . . . . . . . . . . . . . . . 9-1
saveProperty() . . . . . . . . . . . . . . .. 12-15 Copy instance . . . . . . . . . . . . . . . . . . 9-7
saveRendering() . . . . . . . . . . . . . .. . 12-6 Create groups . . . . . . . . . . . . . . . . . 9-15
setBounds() . . . . . . . . . . . . . . . . .. 12-12 Create instance . . . . . . . . . . . . . . . . . 9-7
setFormProperties() . . . . . . . . . . .. 12-11 Create members . . . . . . . . . . . . . . . 9-15
setReadOnly() . . . . . . . . . . . . . . .. 12-12 Create users . . . . . . . . . . . . . . . . . . 9-15
setStringValue() . . . . . . . . . . . . . .. 12-11 Data definition services . . . . . . . . . . . 9-3
setStringValueData() . . . . . . . . . .. 12-11 Data manipulation services . . . . . . . . . 9-7
Modifying attributes in the database . . 9-12 Delete groups . . . . . . . . . . . . . . . . . 9-16
Modifying the properties file . . . . . .. . 6-48 Delete instances . . . . . . . . . . . . . . . . . 9-9
Moving files . . . . . . . . . . . . . . . . . .. . 6-26 Delete members . . . . . . . . . . . . . . . . 9-16
Multi-Site Collaboration . . . . . . . . .. . 11-7 Delete users . . . . . . . . . . . . . . . . . . 9-16
Enquiry . . . . . . . . . . . . . . . . . . . . . 9-33
N Environment . . . . . . . . . . . . . . . . . . 9-21
Errors . . . . . . . . . . . . . . . . . . . . . . . 9-21
Name conventions . . . . . . . . . . . . . . . . . 11 Functions . . . . . . . . . . . . . . . . . . . . 9-23
Naming conventions of variables . . . . . . 5-3 Getting attributes of loaded
Network object . . . . . . . . . . . . . . . . . . 14-1 instances . . . . . . . . . . . . . . . . . . 9-13
Network_Port object . . . . . . . . . . . . . . 14-1 Groups . . . . . . . . . . . . . . . . . . . . . . 9-15
Node class . . . . . . . . . . . . . . . . . . . . . 14-4 Index . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Note attribute . . . . . . . . . . . . . . . . . . 12-10 Inheritance . . . . . . . . . . . . . . . . . . . 9-24
Initialize groups . . . . . . . . . . . . . . . . 9-16
O Initialize members . . . . . . . . . . . . . . 9-16
Initialize users . . . . . . . . . . . . . . . . . 9-16
Object model . . . . . . . . . . . . . . . . . . . . . 4-1 Inquiries . . . . . . . . . . . . . . . . . . . . . 9-17
Access control . . . . . . . . . . . . . . . . . . 4-8 Inquiries to find instances . . . . . . . . . 9-11
Application encapsulation . . . . . . . . . . 4-9 Instance . . . . . . . . . . . . . . . . . . . . . . 9-2
Dataset . . . . . . . . . . . . . . . . . . . . . . . 4-7 Instances of class . . . . . . . . . . . . . . . 9-10
Form . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Load instances . . . . . . . . . . . . . . . . . . 9-8
Item and item revision . . . . . . . . . . . . 4-1 Loading . . . . . . . . . . . . . . . . . . . . . . 9-63
Product structure . . . . . . . . . . . . . . . . 4-1 Login . . . . . . . . . . . . . . . . . . . . . . . 9-21
System administration . . . . . . . . . . . . 4-8 Modifying attributes in the
Object-oriented data . . . . . . . . . . . . . . 4-13 database . . . . . . . . . . . . . . . . . . . 9-12
Object-oriented language . . . . . . . . . . . 4-14 Order instance . . . . . . . . . . . . . . . . . 9-10
okToModify() method . . . . . . . . . . . . . 12-12 Password . . . . . . . . . . . . . . . . . . . . . 9-20
Online help . . . . . . . . . . . . . . . . . . . . . . 14 Reference of instance . . . . . . . . . . . . 9-10
ORDER BY clauses . . . . . . . . . . . . . . . 9-34 Refresh instances . . . . . . . . . . . . . . . . 9-9
Order instance . . . . . . . . . . . . . . . . . . 9-10 Rollback . . . . . . . . . . . . . . . . . . . . . 9-20
Save instances . . . . . . . . . . . . . . . . . . 9-8
P Security . . . . . . . . . . . . . . . . . . . . . 9-18
Select instance . . . . . . . . . . . . . . . . . 9-10
Persistent Object Manager, see POM Set group . . . . . . . . . . . . . . . . . . . . 9-17
Person class . . . . . . . . . . . . . . . . . . . . 6-17 Set user status . . . . . . . . . . . . . . . . . 9-17
Pointer variable . . . . . . . . . . . . . . . . . 5-10 Setting attributes of loaded
POM . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 instances . . . . . . . . . . . . . . . . . . 9-13
Attr_id . . . . . . . . . . . . . . . . . . . . . . 9-13 SQL . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Attribute . . . . . . . . . . . . . . . . . . . . . . 9-2 Starting . . . . . . . . . . . . . . . . . . . . . 9-19
Attribute manipulation . . . . . . . . . . 9-11 Stopping . . . . . . . . . . . . . . . . . . . . . 9-19
Audit trail . . . . . . . . . . . . . . . . . . . . 9-21 System utilities . . . . . . . . . . . . . . . . 9-19
Check reference . . . . . . . . . . . . . . . . 9-14 Tag . . . . . . . . . . . . . . . . . . . . . . 9-3, 9-13
Class . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Timeouts . . . . . . . . . . . . . . . . . . . . . 9-20
Class of instances . . . . . . . . . . . . . . . 9-11 Unload instance . . . . . . . . . . . . . . . . . 9-9

Index
Users . . . . . . . . . . . . . . . . . . . . . . . 9-15 Product structure . . . . . . . . . . . . . . . . 8-34

Variable length array . . . . . . . . . . . . 9-14 BOM relationship . . . . . . . . . . . . . . 8-43
POM enquiry . . . . . . . . . . . . . . . . . . . 9-33 BOMView class . . . . . . . . . . . . . . . . 8-34
API . . . . . . . . . . . . . . . . . . . . . . . . . 9-39 BOMView Revision class . . . . . . . . . 8-35
Attribute expressions . . . . . . . . . . . . 9-34 Classes . . . . . . . . . . . . . . . . . . . . . . 8-34
Basic concepts . . . . . . . . . . . . . . . . . 9-34 Model . . . . . . . . . . . . . . . . . . . . . . . 8-41
Building expressions . . . . . . . . . . . . 9-39 Note type class . . . . . . . . . . . . . . . . 8-40
Class alias . . . . . . . . . . . . . . . . . . . . 9-38 Occurrences class . . . . . . . . . . . . . . . 8-36
class_alias . . . . . . . . . . . . . . . . . . . . 9-49 View type class . . . . . . . . . . . . . . . . 8-39
Creating queries . . . . . . . . . . . . . . . 9-35 Where used reports . . . . . . . . . . . . . 8-42
DIFFERENCE set operator . . . . . . . 9-54 Product structure object model . . . . . . . . 4-1
Escape character . . . . . . . . . . . . . . . 9-38 Product structure objects . . . . . . . . . . . 6-25
Expression . . . . . . . . . . . . . . . . . . . 9-38 Properties . . . . . . . . . . . . . . . . . . . . . 6-29
FROM clause . . . . . . . . . . . . . . 9-39, 9-43 Attribute-based . . . . . . . . . . . . . . . . 6-32
Function expression . . . . . . . . . . . . . 9-38 Compound . . . . . . . . . . . . . . . . . . . . 6-32
GROUP BY clause . . . . . . . . . . 9-39, 9-47 Customizing . . . . . . . . . . . . . . . . . . 6-32
HAVING clause . . . . . . . . . . . . 9-39, 9-47 Reference-based . . . . . . . . . . . . . . . . 6-32
INTERSECTION set operator . . . . . . 9-53 Relation-based . . . . . . . . . . . . . . . . . 6-32
Join . . . . . . . . . . . . . . . . . . . . . . . . 9-37 Runtime . . . . . . . . . . . . . . . . . . . . . 6-32
Loading . . . . . . . . . . . . . . . . . . . . . . 9-63 Properties display
Logical expression . . . . . . . . . . . . . . 9-38 Customizing . . . . . . . . . . . . . . . . . . 12-8
ORDER BY clause . . . . . . . . . . 9-39, 9-45 Customizing using XML style
ORDER BY clauses . . . . . . . . . . . . . 9-34 sheets . . . . . . . . . . . . . . . . . . . 12-16
POM_enquiry_countdist . . . . . . . . . . 9-60 Properties file, modifying . . . . . . . . . . . 6-48
POM_enquiry_cpid_of . . . . . . . . . . . 9-57 Property . . . . . . . . . . . . . . . . . . . . . . . 6-30
POM_enquiry_in . . . . . . . . . . . . . . . 9-60 Property beans
POM_enquiry_lower . . . . . . . . . . . . . 9-59 PropertyArray . . . . . . . . . . . . . . . . 12-51
POM_enquiry_not_in . . . . . . . . . . . . 9-60 PropertyButton . . . . . . . . . . . . . . . 12-36
POM_enquiry_substr . . . . . . . . . . . . 9-57 PropertyCheckbox . . . . . . . . . . . . . 12-39
POM_enquiry_upper . . . . . . . . . . . . 9-59 PropertyDateButton . . . . . . . . . . . . 12-38
Pseudo class . . . . . . . . . . . . . . . . . . 9-38 PropertyImage . . . . . . . . . . . . . . . . 12-52
pseudo_class . . . . . . . . . . . . . . . . . . 9-51 PropertyLabel . . . . . . . . . . . . . . . . 12-37
SELECT attributes . . . . . . . . . . . . . 9-34 PropertyLogicalPanel . . . . . . . . . . . 12-49
SELECT clause . . . . . . . . . . . . 9-39, 9-42 PropertyLongText . . . . . . . . . . . . . 12-48
Set expression . . . . . . . . . . . . . . . . . 9-38 PropertyLOVButton . . . . . . . . . . . . 12-43
Subqueries . . . . . . . . . . . . . . . . . . . 9-47 PropertyLOVCombobox . . . . . . . . . 12-44
Supported operators . . . . . . . . . . . . . 9-61 PropertyNameLabel . . . . . . . . . . . . 12-33
UNION set operator . . . . . . . . . . . . . 9-55 PropertyObjectLink . . . . . . . . . . . . 12-47
Where clause . . . . . . . . . . . . . . . . . . 9-34 PropertyPanel . . . . . . . . . . . . . . . . 12-47
WHERE clause . . . . . . . . . . . . 9-39, 9-43 PropertyRadioButton . . . . . . . . . . . 12-41
POM_application_object is Abstract PropertyRadioButtonOptionLov . . . 12-45
class . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 PropertySlider . . . . . . . . . . . . . . . . 12-37
POM_group class . . . . . . . . . . . . . . . . . 6-3 PropertyTextArea . . . . . . . . . . . . . 12-35
POM_member class . . . . . . . . . . . . . . . . 6-6 PropertyTextField . . . . . . . . . . . . . 12-34
POM_object is Abstract class . . . . . . . . . 6-2 PropertyToggleButton . . . . . . . . . . 12-42
POM_system_class is Abstract class . . . . 6-3 PropertyToggleButtonOptionLov . . . 12-46
POM_user class . . . . . . . . . . . . . . . . . . 6-4 TitledPropertyArray . . . . . . . . . . . . 12-51
Port object . . . . . . . . . . . . . 14-6–14-7, 14-9 TitledPropertyButton . . . . . . . . . . . 12-36
Post-action . . . . . . . . . . . . . . . . . . . . . 6-33 TitledPropertyCheckbox . . . . . . . . . 12-40
Pre-action . . . . . . . . . . . . . . . . . . . . . . 6-33 TitledPropertyCheckboxOptionLov . . 12-45
Precondition . . . . . . . . . . . . . . . . . . . . 6-33 TitledPropertyDateButton . . . . . . . 12-39
Privileges . . . . . . . . . . . . . . . . . . . . . . . 7-2 TitledPropertyLabel . . . . . . . . . . . . 12-37
Process Variable object . . . 14-1, 14-9–14-10 TitledPropertyLogicalPanel . . . . . . 12-49

Index
TitledPropertyLongText . . . . . . . . . 12-49 Requirement . . . . . . . . . . . . . . . . . . . . . 4-4

TitledPropertyLOVButton . . . . . . . 12-43 Resource tier . . . . . . . . . . . . . . . . . . . . 2-2
TitledPropertyLOVCombobox . . 12-44–12-45 Restrictions . . . . . . . . . . . . . . . . . . . . . 1-2
TitledPropertyObjectLink . . . . . . . . 12-47 Reverse engineering . . . . . . . . . . . . . . . 1-1
TitledPropertyPanel . . . . . . . . . . . . 12-47 Revision . . . . . . . . . . . . . . . . . . . . . . . . 4-5
TitledPropertyRadioButton . . . . . . . 12-41 RevisionAnchor class . . . . . . . . . . . . . . 6-23
TitledPropertyRadioButtonOptionLov . . 12-46 Revisioning scheme . . . . . . . . . . . . . . . 6-28
TitledPropertySlider . . . . . . . . . . . 12-38 Rich client . . . . . . . . . . . . . . . . . . . . . . 2-1
TitledPropertyTextArea . . . . . . . . . 12-35 Role class . . . . . . . . . . . . . . . . . . . . . . 6-16
TitledPropertyTextField . . . . . . . . . 12-34 Route class . . . . . . . . . . . . . . . . . . . . . 14-4
TitledPropertyToggleButton . . . . . . 12-42 RouteCurve object . . . . . . . . . . . . . . . . 14-1
TitledPropertyToggleButtonOptionLov . . 12-46 RouteLocation object . . . . . . . . . . . . . . 14-1
Property init_module function . . . . . . . 6-38 RouteLocationRev object . . . . . . . . . . . 14-1
Property methods . . . . . . . . . . . . 6-37, 6-40 RouteNode object . . . . . . . . . . . . . . . . 14-1
PropertyArray bean . . . . . . . . . . . . . . 12-51 RoutePath object . . . . . . . . . . . . . . . . . 14-1
PropertyBMOperation class . . . . . . . . . 7-19 RouteSegment object . . . . . . . . . . . . . . 14-1
PropertyButton bean . . . . . . . . . . . . . 12-36 Rule handlers . . . . . . . . . . . . . . . . . . . 10-9
PropertyCheckbox bean . . . . . . . . . . . 12-39 Running ITK programs . . . . . . . . . . . . 5-20
PropertyDateButton bean . . . . . . . . . 12-38
PropertyImage bean . . . . . . . . . . . . . 12-52
PropertyLabel bean . . . . . . . . . . . . . . 12-37 S
PropertyLogicalPanel bean . . . . . . . . 12-49
Save instances . . . . . . . . . . . . . . . . . . . 9-8
PropertyLongText bean . . . . . . . . . . . 12-48
save() method . . . . . . . . . . . . . . . . . . 12-15
PropertyLOVButton bean . . . . . . . . . 12-43
saveProperty() method . . . . . . . . . . . . 12-15
PropertyLOVCombobox bean . . . . . . . 12-44
saveRendering() method . . . . . . . . . . . 12-6
PropertyNameLabel bean . . . . . . . . . 12-33
Segment class . . . . . . . . . . . . . . . . . . . 14-4
PropertyObjectLink bean . . . . . . . . . . 12-47
SELECT attributes . . . . . . . . . . . . . . . 9-34
PropertyPanel bean . . . . . . . . . . . . . . 12-47
Select instance . . . . . . . . . . . . . . . . . . 9-10
PropertyRadioButton bean . . . . . . . . . 12-41
Server exits . . . . . . . . . . . . . . . . 5-17, 5-28
PropertyRadioButtonOptionLov
Service Oriented Architecture . . . . . . . . 3-1
bean . . . . . . . . . . . . . . . . . . . . . . . . 12-45
setBounds() method . . . . . . . . . . . . . . 12-12
PropertySlider bean . . . . . . . . . . . . . 12-37
setReadOnly() method . . . . . . . . . . . . 12-12
PropertyTextArea bean . . . . . . . . . . . 12-35
Setting attributes of loaded instances . . 9-13
PropertyTextField bean . . . . . . . . . . . 12-34
Signal object . . . . . . . . . . . . . . . . . . . 14-1,
PropertyToggleButton bean . . . . . . . . 12-42
14-10–14-11, 14-13–14-14
PropertyToggleButtonOptionLov
Signoff class . . . . . . . . . . . . . . . . . . . . 6-16
bean . . . . . . . . . . . . . . . . . . . . . . . . 12-46
SOA, see Service Oriented Architecture
PSConnection object . . . . . . . . . . . . . . 14-1
Specification . . . . . . . . . . . . . . . . . . . . . 4-5
Status class . . . . . . . . . . . . . . . . . . . . 6-16
R stylesheet_user.properties file . . . . . . . 12-6
Subclasses . . . . . . . . . . . . . . . . . . . . . 4-13
Subtype . . . . . . . . . . . . . . . . . . . . . . . 6-30
Reference . . . . . . . . . . . . . . . . . . . . . . . 4-5
Subtypes . . . . . . . . . . . . . . . . . . . . . . 6-29
Reference of instance . . . . . . . . . . . . . . 9-10
Superclasses . . . . . . . . . . . . . . . . . . . . 4-13
Refresh instances . . . . . . . . . . . . . . . . . 9-9
Supplier custom hooks . . . . . . . . . . . . . 5-24
Registering custom callbacks . . . . . . . . 5-25
Syntax definition conventions . . . . . . . . . 13
Registering customizations . . . . . . . . . 5-30
System administration object model . . . . 4-8
Registering runtime properties . . . . . . . 5-34
System logs . . . . . . . . . . . . . . . . . . . . . 5-6
Registering server exits
System utilities . . . . . . . . . . . . . . . . . . 9-19
customization . . . . . . . . . . . . . . . . . . 5-28
Registering user exits customization . . . 5-26
Registration . . . . . . . . . . . . . . . . 6-37–6-39 T
Regular property display keys . . . . . . 12-16
Relations . . . . . . . . . . . . . . . . . . . . . . . 4-3 tag_t . . . . . . . . . . . . . . . . . . . . . . . . . 5-12

Index
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Example . . . . . . . . . . . . . . . . . . . . . 12-6

Teamcenter Engineering Data Integration Extending the schema . . . . . . . . . . . 12-6
Services Adapter . . . . . . . . . . . . . . . . . 2-2 Registering the panel . . . . . . . . . . . . 12-6
Teamcenter File Services . . . . . . . . . . . . 2-2 Unit of measure class . . . . . . . . . . . . . 6-25
Thin client . . . . . . . . . . . . . . . . . . . . . . 2-1 Unload instance . . . . . . . . . . . . . . . . . . 9-9
Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Unpublished APIs and extension
TitledPropertyArray bean . . . . . . . . . 12-51 points . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
TitledPropertyButton bean . . . . . . . . 12-36 User class . . . . . . . . . . . . . . . . . . . . . . . 6-5
TitledPropertyCheckbox bean . . . . . . 12-40 User exits . . . . . . . . . . . . . . 5-14–5-15, 5-26
TitledPropertyCheckboxOptionLov Business Modeler . . . . . . . . . . . . . . . . 7-5
bean . . . . . . . . . . . . . . . . . . . . . . . . 12-45 Users . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
TitledPropertyDateButton bean . . . . . 12-39
TitledPropertyLabel bean . . . . . . . . . 12-37 V
TitledPropertyLogicalPanel bean . . . . 12-49
TitledPropertyLongText bean . . . . . . . 12-49 Value conventions . . . . . . . . . . . . . . . . . 11
TitledPropertyLOVButton bean . . . . . 12-43 Variable length array . . . . . . . . . . . . . 9-14
TitledPropertyLOVCombobox Variables . . . . . . . . . . . . . . . . . . . . . . . 5-3
bean . . . . . . . . . . . . . . . . . . . 12-44–12-45
TitledPropertyObjectLink bean . . . . . 12-47 W
TitledPropertyPanel bean . . . . . . . . . 12-47
TitledPropertyRadioButton bean . . . . 12-41 Web tier . . . . . . . . . . . . . . . . . . . . . . . . 2-2
TitledPropertyRadioButtonOptionLov Where clause . . . . . . . . . . . . . . . . . . . 9-34
bean . . . . . . . . . . . . . . . . . . . . . . . . 12-46 Where used reports . . . . . . . . . . . . . . . 8-42
TitledPropertySlider bean . . . . . . . . . 12-38 Workflow
TitledPropertyTextArea bean . . . . . . . 12-35 Action handlers . . . . . . . 10-3, 10-7, 10-18
TitledPropertyTextField bean . . . . . . . 12-34 Attachments . . . . . . . . . . . . . . . . . . 10-6
TitledPropertyToggleButton bean . . . . 12-42 Business rule handlers . . . . . . . . . . . 10-6
TitledPropertyToggleButtonOptionLov Cascade Release . . . . . . . . . . . . . . 10-20
bean . . . . . . . . . . . . . . . . . . . . . . . . 12-46 Customizing with Enterprise Process
Tool class . . . . . . . . . . . . . . . . . . . . . . 6-14 Modeling object model . . . . . . . . . 10-7
Traversal Engine module . . . . . . . . . . . 15-1 Enterprise Process Modeling
Compiling . . . . . . . . . . . . . . . . . . . . 15-2 module . . . . . . . . . . . . . . . . . . . . 10-1
Installing . . . . . . . . . . . . . . . . . . . . 15-2 Enterprise Process Modeling object
Linking . . . . . . . . . . . . . . . . . . . . . . 15-2 model . . . . . . . . . . . . . . . . . . . . . 10-2
Minimum requirements . . . . . . . . . . 15-2 Inbox queries . . . . . . . . . . . . . . . . . 10-19
Programming . . . . . . . . . . . . . . . . . 15-2 Jobs . . . . . . . . . . . . . . . . . . . . . . . . 10-2
User exits . . . . . . . . . . . . . . . . . . . . 15-2 Rule handlers . . . . . . . . . . . . . . . . . 10-9
Type . . . . . . . . . . . . . . . . . . . . . . . . . 6-30 Task Model . . . . . . . . . . . . . . . . . . . 10-1
TypeBMOperation class . . . . . . . . . . . . 7-19 Tasks . . . . . . . . . . . . . . . . . . . . . . . 10-2
Types . . . . . . . . . . . . . . . . . . . . . . . . . 6-29 WorkspaceObject is Abstract class . . . . . 6-8
Types, properties, and methods Writing property methods . . . . . . . . . . 6-40
definitions . . . . . . . . . . . . . . . . . . . . . 6-30
X
U XML style sheets
UI forms Customizing the properties
Creating the form panel . . . . . . . . . . 12-6 display . . . . . . . . . . . . . . . . . . . 12-16
Creating the form type . . . . . . . . . . . 12-6 Using predefined . . . . . . . . . . . . . . 12-16

IntegrationToolkitProgrammerGuide V10

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IntegrationToolkitProgrammerGuide V10

Transféré par

Droits d'auteur :

Formats disponibles

Teamcenter® 2005 SR1

engineering process management

Manual Teamcenter Engineering Publication

©2006 UGS Corp.

2 Integration Toolkit Programmer’s Guide ENG00043 A

Introduction to Integration Toolkit Programming . . . . . . . . . . . . . . . . . 1-1

General Caveats and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Part I: ITK Concepts

Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Client Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Application Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Teamcenter Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Using ITK Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

ENG00043 A Integration Toolkit Programmer’s Guide 3

Part II: ITK Modules

Core Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Core Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

List of Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Product Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Bill of Materials (BOM) Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Persistent Object Manager Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Persistent Object Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Enterprise Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Data Sharing of Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Object Import and Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Customizing Forms and Properties Display . . . . . . . . . . . . . . . . . . . . . 12-1

Communication With the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

4 Integration Toolkit Programmer’s Guide ENG00043 A

Customizing Text and Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Traversal Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

2-1. Four-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

ENG00043 A Integration Toolkit Programmer’s Guide 5

6-6. Adding an Attribute to a New Subclass . . . . . . . . . . . . . . . . . . . . . . . . 6-54

6 Integration Toolkit Programmer’s Guide ENG00043 A

11-1. Export Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

ENG00043 A Integration Toolkit Programmer’s Guide 7

12-52. TitledPropertyLongText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-49

8-1. Variant Expression Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10

8 Integration Toolkit Programmer’s Guide ENG00043 A

This document supplements the Teamcenter Engineering Help Library.

Chapter 1 Introduction to Integration Toolkit Programming defines

ENG00043 A Integration Toolkit Programmer’s Guide 9

Chapter 8 Product Structure Management describes the modules that

10 Integration Toolkit Programmer’s Guide ENG00043 A

Note, Caution, and Warning Icons

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

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:

ENG00043 A Integration Toolkit Programmer’s Guide 11

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

12 Integration Toolkit Programmer’s Guide ENG00043 A

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

ENG00043 A Integration Toolkit Programmer’s Guide 13

Teamcenter Engineering Documentation

Software Copyright and Trademark Notices

14 Integration Toolkit Programmer’s Guide ENG00043 A