Data Exchange
Data Exchange
Data Exchange
Teamcenter 12.0
Data Exchange
PLM00094 • 12.0
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Getting started with Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Teamcenter Data Exchange interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Data Exchange use cases and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Teamcenter upgrade and other transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Data Exchange concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Briefcase file exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
4th Generation Design data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
PDX export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Teamcenter variant schema exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Special characters in Teamcenter import files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Requirement objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Vendor management objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Multiple language support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Bulk loading data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Configured BOM export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
TC XML Data Exchange compatibility for Product Configurator . . . . . . . . . . . . . . . . . . . 1-20
Multifield key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Installing Teamcenter Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Planning your installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Installation worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Teamcenter server installation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Teamcenter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Teamcenter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Install Teamcenter Integration Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Teamcenter Integration Framework configuration process . . . . . . . . . . . . . . . . . . . . . . . 1-26
Define remote sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Define Teamcenter preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Configure attribute mapping for 4GD major revisioning . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
File Management System (FMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Configuring Teamcenter Integration Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Transfer modes in Teamcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Transfer option sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Set a rule to allow transfer of ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Define users, groups, and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Closure rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Verifying the transfer configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Verify FMS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Verify transfer from Teamcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Figures
Tables
Note
When exporting a Pro/ENGINEER/PTC Creo assembly or part that contains a family
table instance, you must export all associated family table instances prior to exporting the
assembly. Otherwise, the remote Teamcenter site does not include any nested family
table instances for the part.
When you transfer objects with attached licenses, the license must exist in the importing
system for the license to be attached to the imported object. Synchronizing license
associations between systems is not supported. Therefore, if a licenses is detached from
an object at the owning site, the license does not get detached from the replica object.
Note
Object Directory Service (ODS) operations are not supported between Teamcenter and
Teamcenter Enterprise sites. All Data Exchange operations related to ODS are supported
only for Teamcenter-to-Teamcenter operations. This includes publishing objects to the
ODS, remote search operations, and remote import operations based on remote search
results.
Basic concepts
• Exchange data between your site and Teamcenter supplier sites that are online (connected) or
offline (unconnected).
• Exchange data between Teamcenter sites that are not connected (offline) using briefcase files.
• Exchange data with suppliers that are not using Teamcenter (unmanaged sites) using briefcase
files.
• Upgrade multiple Teamcenter sites with disparate data models to the current version of
Teamcenter.
• Transfer data from non-Teamcenter data sources to your Teamcenter site. This can be done
using the bulk load feature or with a custom connector integration.
• Standardizing organizations, access rules, naming and deep copy rules, work processes, and so
forth.
Note
Site standardization can be joined with site consolidation.
• Populating new sites using Data Exchange, transforming or mapping data as needed.
You can also use the integration framework components to transition third-party or custom systems,
such as non-Siemens PLM Software PLM or PDM systems, to Teamcenter. High-level considerations
for the transition process are:
Note
It is important that you carefully consider your specific requirements during the planning
phase of a transition.
These descriptions provide very high-level considerations. Contact Siemens PLM Software
services for assistance in determining the best approach for your companies requirements.
• Leveraging connectors developed by Siemens PLM Software partners for third-party competitive
systems, such as, ENOVIA or Inventor.
• Export
Export is the Data Exchange function used to send data to a remote site. While exporting the
data, you can either transfer the data with ownership or transfer the data for reference. If you
transfer the data for reference, the ownership is retained by the exporting site and a replica is
exported to the remote site.
• Import
When a user exports data from a remote site to a Teamcenter site, the site imports the data
automatically.
• Replica
Replication is the act of creating an exact copy of an object, known as a replica, at a specific site.
Replicas are objects that are owned by a remote site. Whenever a master object is modified,
you must update the replicas by synchronizing them to the master. A replica is a nonwriteable
object and cannot be updated except by the owning site. When an object is replicated, you
cannot delete the master object unless all the replicas are deleted.
A replica is represented by a symbol with two green dots.
• Synchronization
When a master object is replicated at other sites, you must update the replicas whenever the
master object is modified. The process of updating replicas is referred to as synchronization. The
synchronizer is responsible for ensuring that a previously replicated data is synchronized.
Manual synchronization is performed by a user. It is a re-export or re-import of the object with the
same transfer formula. Automatic synchronization is supported for push cases and is initiated by
integration framework making a call to transfer updated objects.
Caution
When manually synchronizing a replica, both the owning site and replica site must be
online to receive replica deletion notification.
Note
Data Exchange does not support automatic pull synchronization.
A closure rule clause ( ) controls the scope of the data transfer. It defines the rules for
gathering objects during the export action. 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.
Teamcenter also has many internal closure rules that handle out-of-the-box data model traversal.
These are normally imported during installation or upgrade. They must not be changed. For
instance, the inclusion of the BOM and Absolute Occurrence network is handled by internal
closure rules.
• Transfer mode
A transfer mode ( ) is a logical grouping of closure rule clauses. You select a transfer mode
when creating closure rule clauses. Transfer modes allow users to export and import data by
knowing only the transfer mode name that they must use, for example, ToSiteA or FromSiteB.
• Transfer option
Specifies the different options you can choose to use when Teamcenter transfers an object.
The different transfer options are:
A transfer option set (TOS) ( ) is a stored set of transfer options used for remote data export.
A transfer option set displays all of the unique options in the closure rule conditional clauses for
the selected transfer mode. The Description column of the TransferOptionSet pane in the PLM
XML/TC XML Export Import Administration application describes the purpose of the options
included in the standard Teamcenter transfer option sets.
• Factor
A factor is a logical concept defined by a set of objects at the exporting site that map to a similar
logical concept defined by a different set of objects at the importing site. You define a factor using
a closure rule. Closure rules help optimize Data Exchange performance.
• Export protection
The export protection capability of Data Exchange sends export-protected objects as stubs.
• Replica deletion
The replica deletion capability deletes the export record of an object on the master site when a
replica is deleted on the remote site.
• Stub replication
The stub replication capability ensures that when a master object replica is sent to another site,
the exporter creates an export record for this new site and tags it as stubbed.
• Audit monitoring
The integration framework provides an audit log of transactions during transfers between
Teamcenter Enterprise and Teamcenter that is maintained in the integration framework database.
The following transactions are logged:
o Fnd0LicenseChangeAudit
o Fnd0LicenseExportAudit
o Fnd0OrganizationAudit
• Administrative objects
The TC XML framework processes Teamcenter administrative objects differently from other
objects. For example, during the import process, if an administrative object identified in the
TC XML file is not found at the importing site, the import fails whether or not the exporting
user selected the Continue On Error option. Objects of the following classes are considered
administrative objects by the framework:
o ADA_License
o ClosureRule
o Condition
o CondValAgent
o CondValAgentRevision
o CondValData
o CondValDataRevision
o Filter
o Fnd0AlgebraicFormula
o FunctionalityRule
o Group
o GroupMember
o IdContext
o ImanType
o NoteType
o PIEActionRule
o POM_imc
o PropertySet
o PSOccurrenceType
o PSViewType
o ResourcePool
o RevisionRule
o Role
o TransferMode
o TransferOptionSet
o TC_Project
o UnitOfMeasure
o User
o VerificationRule
There may be times when a Teamcenter site that shares data with other sites is not online. The
Siemens PLM Software briefcase functionality also allows you to transfer the data in the archived
file format between the offline sites.
You can export incremental change information in a briefcase file. The incremental change data
export is based on object timestamps. The importing site determines objects are successfully
imported reports the status to the exporting site that uses the information to update the import/export
record (IXR) of the objects at the exporting site. Therefore, exporting an incremental change
briefcase file is a two-step process.
For the import to succeed, the system administration objects, such as effectivity and revision rules,
used to configure the exported structure must exist at the importing site. The import process searches
for the system objects at the local site by name, the contents of the objects is not verified. If a local
system object is not found the import process logs an error in the import log file.
During the export process, if a revision rule results in an imprecise line, the exporter includes the latest
revision. Unconfigured lines and any unchanged objects configured by incremental change that have
already been exported are exported as stubs (BOMLine objects as full objects with PSOccurrence
objects as stubs). Additionally, new BOM lines added to a structure that are not tracked by
incremental change are exported as stubs and all substructure to the BOM lines are ignored.
Any BOM line not tracked by incremental change that is deleted from an exported structure is not
included in the exported briefcase file. The importer deletes (inferred delete) the object at the
importing site when the structure exists at the importing site.
You can export a briefcase file with multiple root objects that are configured by a single revision rule or
with each having a different revision rule (collaboration context). A structure context is a configurable
structure that consists of one or more root objects sharing the same configuration. A collaboration
context is a container object containing one or more structure contexts, each of can have a different
configuration. The configuration of the structure context is defined by a configuration context, and
may include revision rules, variant rules and closure rules.
Closure rules are also system administration objects. The closure rules for a collaboration context
must exist at the importing site or be imported separately prior to importing a briefcase file containing
the collaboration context objects.
Collaboration and structure objects are workspace objects. They cannot be revised, but they can
be managed with incremental changes. The change object affects the structures contained in the
collaboration context object. However, you cannot export incremental change data affecting objects
specific to the manufacturing data model in a briefcase file.
Transfer mode (determines User selected (TM and TOS) User selected TM only (no
content) options)
Incremental (delta) export Yes No
support
Application interoperability Teamcenter 2007 MP1 or later Teamcenter and other PLM
only XML compatible applications
Toolkit/SDK support None planned PLM XML SDK
Briefcase Browser supports both NX and CATIA CAD data. You can have only one plug-in installed
at a time. However, there are some differences in the functionality between the plug-ins for the
CAD formats.
• For CATIA CAD data, drawing files in Briefcase Browser are confined to the data model where
the drawing is related to an item revision of the same item.
• The CATIA schema is validated strictly by the rules of the supplied schema.
• When you open a partial briefcase file in Briefcase Browser, there may be differences in the
structure view from what is displayed in Teamcenter, for example, Briefcase Browser shows
unselected NX siblings as stubs, however the CATIA plug-in ignores them.
• For CATIA data you can export a partial BOM export and assemblies with variant rules.
• BOMViewRevision
• Dataset
• Form
• Item
• ItemRevision
Tip
The view type data is not exported with the PSBOMView data in TC XML. The import
process uses the default view type when importing PSBOMView data.
Therefore, when transferring PSBOMView data using a briefcase file, tcxml_export and
tcxml_import, or any utility that uses TC XML metadata, set the PSE_default_view_type
preference at the target site to the view type value of the assembly at the source site.
Usually, this is the same as the source sites default view type.
This import behavior is designed to be consistent with Structure Manager.
The following table identifies the related objects that are checked out to a site:
The checkout to site functionality also supports tiered suppliers. A supplier that is a hub site (tier-1
supplier) can use the Check-Out to site command to check out objects to one of their suppliers
(tier-2 supplier) for modifications. The owning site attribute is set to the exporting site (tier-1 supplier),
allows the importing site to modify the data and send it back to the hub site.
Note
If a tier-2 supplier does not use the Check-In from site command before sending an
object back to the tier-1 supplier, the tier-1 supplier must perform the Check-In from site
command twice on the object to release the lock.
A site that has checked out an object to a site can cancel the site checkout to restore the reservation
object to its precheckout state. Datasets are not restored to their precheckout state but the site
checkout lock is removed.
Remote checkout and the Check-Out to site command are mutually exclusive and Teamcenter
disables the commands to prevent the other action.
Note
The Briefcase Browser application does not support briefcase files containing 4GD data.
• Member-owned memberships are exported along with the member that owns them.
o If PtnC is the root object, the PtnC and linkBC objects are exported as full objects.
• Member-owned memberships are exported along with the member that owns them.
o If Ptn2 is the root object, the Link1 and Ptn2 objects are exported as full objects.
o If member1 is the root object, the member1 object and its contents, and the membership1
object are all exported as full objects.
• POM revisioning
The revisable setting for business objects at both the source and destination systems must be
consistent. Therefore, a class that has revisioning enabled at an exporting site has to have
revisioning enabled at the importing site; otherwise, the import fails. Only the latest version of a
revisable object is transferred for both managed and unmanaged use cases.
• Partitions
You can add a design element under a replicated partition. The master partition does not
have the knowledge of all design elements under the replicated partition. This behavior is
acceptable as long as either a well-defined best practice approach is exercised so your users
can assume the master partition is always up to date within a given time interval, or a central
authority, implemented in the future, can be consulted to determine what data is up to date. For
a parent-child link owned by child partitions, users must make sure the partition hierarchy is
constructed at one site and then replicated to all other sites.
• Compatibility
Forward and backward compatibility between Teamcenter versions requires the Teamcenter
schemas to be compatible at both the exporting and importing sites. Therefore, you cannot export
4GD data from earlier Teamcenter versions that do not support the 4GD data model.
Exported objects are listed as the master object in the export log. The imported objects are listed as
new objects in the import log.
When importing the same object after the initial import, the imported object is listed as updated in
the import log.
For roots objects designated as not exportable, the object is listed as
STUB_INSUFFICIENT_PRIVILEGE in the export log and a stub object is created at the importing site.
The following TC XML options apply to 4GD object replication.
• Cpd0DesignElementImpl
Causes a category change for these objects:
• Workset
Deletes the Subsets that are not in the imported TC XML file.
For the subassembly, infer delete is controlled by the BVR and PSOccurrence objects.
• SubsetInstance in a Workset
Deletes the search criteria if it is different from that in the imported TC XML file.
Deletes the realization maps that are not in the TC XML file.
• Partition
Deletes the search criteria if it is different from that in the imported TC XML file.
Deletes the child-parent links that not in the imported TC XML file.
Deletes the memberships that are not in the imported TC XML file.
Configured export
1. Constructs the BOMWindow object for the given root object and configuration context (revision
rule, variant rule, and effectivity).
2. Gets the top line from BOMWindow object. For a Workset object, this is the WorksetLine object.
4. Serializes the traversed data with properties defined by the property set.
PDX export
Data Exchange exports data in PDX format as a PDX package. This package can be viewed by
PDX viewer applications or used by other systems that support the PDX data format. You can also
create a PDX package using a workflow process by specifying the workflow handler provided for
PDX packages.
Data Exchange exports the Teamcenter data in an XML format (TC XML) that is converted to PDX
format by a style sheet (XSLT). Teamcenter uses features of the Teamcenter integration framework
and Teamcenter briefcase to perform the export. Teamcenter schedules the export job and also
transforms the TC XML data to PDX data using XSLT. Teamcenter briefcase packages the contents
and uploads the PDX package to Teamcenter. The following figure shows how the Teamcenter
components interact to export a PDX package.
The site definition distinguishes a PDX export from a standard briefcase export. When you define a
site as a target for PDX export, you must identify:
• The integration framework deployment URL.
• The transfer option set used for exporting the TC XML data using the
TC_gms_export_transfermode_for_<site-name> site-level preference, for
example:
TC_gms_export_transfermode_for_Pune = TIEPDXExportDefault
• The style sheet that is applied to this TC XML file in the data mapping step in integration
framework.
Teamcenter objects that can be exported to PDX and how they are mapped to PDX objects by the
out-of-the-box (OOTB) mapping file are described in Standard PDX mapping.
For Teamcenter 10.1.4 and later versions, when you export a variable length array (VLA) of string
type in a TC XML file, the export process inserts a slash (\) character before the predefined separator
character and any slash characters in property values. The predefined separator character is defined
in the GMS_tcxml_string_separator preference and is a comma (,) by default.
For example, when exporting the following VLA string property values:
prop[0] “ab,c”
prop[1] “d\ef”
A slash character is prefixed to the slash and comma (default separator) in the strings. During the
import process, the tcxml_import utility parses the property correctly and the values are the same
at both the exporting and importing site. In prior versions of Teamcenter, the output file contained
three values ("ab", "c", and "d\ef") and the import process could not properly parse them into
values that matched the exporting site values.
Requirement objects
Data Exchange can transfer requirement objects and their associated data between Teamcenter
sites, with or without ownership, and can synchronize replicated data. However, if you require remote
check out and check in actions, you must use Multi-Site Collaboration.
You can transfer to other sites (export/import) custom notes along with their Trace link using Data
Exchange and the associated TC XML utilities. You can also export notes on Trace links to other
sites using PLM XML.
Note
PLM XML import of notes on trace links is not supported. Notes on trace links is not
supported for briefcase file transfers.
Transferring notes on trace links requires you to use the REQ_export_notesonlinks transfer mode.
hold localized values for attributes that are designated by the localizable proper constant for the
attribute. The bmide_generatetcxmlschema Java utility provides the modification to the schema.
The upgrade process runs this utility at the end of the database installation or upgrade. The utility
retrieves a list of languages that are supported by the database and provides attributes to hold
localized values for the attributes that have the localizable property constant set to true. It adds
localized attributes to the schema for the primary language of the database and for each approved
nonprimary language.
Note
The URIs that appear in the headers of PLM XML and TC XML files serve as namespace
names, are unique identifiers for an XML vocabulary. Although they are URIs, they are not
used to identify and retrieve web addresses.
The TC XML file used to transfer objects from and to a multilingual site, contains elements that
identify the site master language, all required languages, and any allowed languages for the site. For
exports, unapproved locale attribute values are not included in the TC XML file, and a message is
written to the exporter log file indicated the attribute value was not exported. For imports, the locale
information in the TC XML file and locale information that Data Exchange obtains from the importing
system is used to determine if localized values in the TC XML file are supported in the importing
system. Values for unsupported locales are ignored, and a message is written to the importer log file
indicating the attribute value was not imported.
Consider the following when transferring objects with localized attributes and when monolingual and
multilingual sites participate in your Data Exchange environment:
• When transferring objects between multilingual sites that have different site master languages,
the import succeeds only if the importing site supports the site master language contained in the
TC XML file, and the TIE_allow_import_with_different_SML preference at the importing site
is set to true or ON.
• Data Exchange transfers are supported between multilingual sites and monolingual sites with the
following restrictions:
o For objects transferred from monolingual to multilingual sites, Data Exchange uses the site
master language specified in the transfer formula to import the localizable attributes. If the
transfer formula does not contain the site master language, the site master language of the
importing (multilingual) site is used to import the localizable attributes. In this case, the
locale of the monolingual site must match the site master language of the multilingual site
for the import to succeed.
o For objects transferred from multilingual to monolingual sites, Data Exchange ignores the
locale information in the TC XML file. Required attribute values are stored in the importing
site. Therefore, the site master language at the multilingual site must be supported at the
monolingual site, and all localized attributes must have a site master language representation
at the multilingual site.
• The Teamcenter databases must be character set compatible. For example, transfers between
sites using the UTF-8 character set and sites using non-UTF-8 characters (such as Shift-JIS) are
not supported.
• You can transfer objects with ownership between multilingual sites that have their required
languages common to both sites. The tcxml_import and tcpxml_export utilities support
arguments that allow you to specify allowed and required languages.
Caution
When attribute values contain commas in the strings at either of the sites, you must
change the default value for the GMS_tcxml_string_separator preference at both
sites to prevent data corruption at the importing site.
• You can synchronize objects between multilingual sites and between monolingual and multilingual
sites.
• Session options
You can export both precise and imprecise assemblies with related notes, attachments, absolute
occurrences and overrides, alternates and substitutes, and generic design elements (GDE) lines.
Multifield key
Multifield keys are identifiers assigned to each object to ensure their uniqueness in the database.
Data Exchange supports multifield keys definitions for objects that it transfers. Teamcenter
administrators can add multiple properties to define a key. The multifield key is composed of a
domain name (the name of the business object type) and a combination of the object’s properties.
This ensures a unique identifier across all the objects in the domain. You configure multifield keys for
objects using the Business Modeler IDE.
• Install and deploy a Teamcenter web tier application with the required Data Exchange solutions.
• (Optional) Install Security Services if you want single sign-on (SSO) functionality.
Installation worksheets
Use these worksheets to record important information about your network. You need to record this
information for reference on the worksheet and also get values here when they are needed.
Worksheet 2 – Teamcenter server information (use a separate sheet for each site)
Administrator password
Worksheet 2 – Teamcenter server information (use a separate sheet for each site)
Site ID
TC_gms_server
TC_SSO_login_URL
Worksheet 2 – Teamcenter web tier information (use a separate sheet for each site)
Context parameters
DEPLOYABLE-FILE-NAME
LogVolumeName
LogVolumeLocation
KeyGen value
FMS_HOME directory
Site 1 parameters:
siteid
fscid
fscaddress
Site 2 parameters:
siteid
fscid
fscaddress
Site 3 parameters:
siteid
fscid
fscaddress
Site ID
fsc.uris
Prerequisites
You must have a Teamcenter server installed that contains several optional components. Depending
on the use cases that Data Exchange must support, you may need other products, such as
Teamcenter Integration for NX I-deas and the Content Migration Manager (CMM). These products are
documented in their own documentation set provided with the product. The following figure shows a
sample deployment scenario with two Teamcenter sites participating in the Data Exchange network.
• Four-tier architecture
• FMS
It is recommended that you also install Security Services. This provides single sign-on functionality
for Teamcenter products.
Teamcenter configuration
Teamcenter configuration
Configuring Teamcenter for Data Exchange involves performing the following tasks:
1. Define sites.
4. Set Access Manager (AM) rules to allow transfer of ownership between Teamcenter sites.
5. Update preferences.
d. Set the Teamcenter Enterprise site logon credentials (user name and password) for the
Teamcenter Integration Framework user.
e. Set the Teamcenter site logon credentials (user name and password) for the Teamcenter
Integration Framework user.
c. Select the map control files that define the mapping between the two sites.
g. Select the map control files that define the mapping between the two sites.
1. Select the top-level sites node from the Organization List tree.
2. In the Sites pane, type a descriptive name for the site in the Site Name box. For the deployment
example, Teamcenter site 1 defines two remote sites: TcHost1 and the TcHost2.
3. Type a unique identifier in the Site ID box. For the deployment example, 457655709 and
457141260.
Caution
Each site must be defined at other sites using exactly the same site ID in each
definition. For Teamcenter sites, this value is defined during the installation process.
4. Type the URL for your Teamcenter Integration Framework web server in the TcGS URL box.
7. Select the Allow deletion of replicated master objects to this site check box.
8. Click Create.
Note
This example uses the TIE default (TIEImportDefault) transfer mode. For mapping
attributes for Multi-Site transfers, use the MultiSiteDefaultTM transfer mode.
2. Ensure the wso_thread property of the Mdl0ConditionalElement object is set in the property
set of transfer mode you use for the data transfer. Include the following clause in the property set:
CLASS Mdl0ConditionalElement ATTRIBUTE wso_thread DO
After you perform these commands, you can also use the tcxml_import utility to transfer data using
LL TIE by specifying the XSLT file to use or the option set to use. For example, to specify the XSLT tile:
tcxml_import -u=admin-user -p=admin-password -g=dba -xsl=xslt-file-name
-file=tcxml-import-file-name -low_level
The transfer mode associated with the transfer option has the XSLT file attached in the first step of
this procedure.
FMS keys
Data Exchange uses File Management System (FMS) keys to digitally sign and verify FMS tickets
during file transfers. FMS keys can use different keys for different ticket types; however, this is not
a best practice for Data Exchange.
FMS provides a script (keygen) that runs a Java utility for generating a key. This utility requires that
you have the FSC_HOME and JAVA_HOME environment variables set.
Data Exchange creates tickets with the delete flag set to false to allow a paused transaction to be
resumed. Therefore, you must periodically delete completed transactions from the transient volumes.
2. Copy this key value into a text file. For this example, the file name is FMS.key. This key value
must be the first non-UNIX style comment line in the file.
# This file (FMS.key) contains a 128–bit key for FMS tickets
f6968bd55d740f44ebacaba09c1313c4
3. Copy this text file to the FSC_HOME directory of each host running an FSC.
4. Install the generated key in the Teamcenter database using the install_encryptionkeys utility:
install_encryptionkeys -u=infodba -p=infodba—password -g=dba -f=modify
The commands output must match the key value in the FMS.key file.
6. Verify FMS access for your Teamcenter site using the fscadmin utility:
fscadmin -s URL-for-FSC -k common-key-file ./status
For example:
You must edit the FMS_master.xml file for each site to reference the key files that you create and
to configure the FSCs from different sites to communicate with each other. The mulitsiteimport
element is used to set the attributes for each site in the Data Exchange network. The following
figures show a possible configuration for a Data Exchange network that has two Teamcenter sites
(TcHost1 and TcHost2). You canconfigure FMS in several ways to obtain different performance
and failure tolerance characteristics.
Note
Locate the transientvolume element in this file and note the id value.
2. In the configuration interface, choose Configure→Wizard, select Configure a site, and click
the Next.
3. Select Teamcenter from the Create new site configuration list and click Next.
4. Type the Teamcenter site ID, for example, 457706589, in the Site ID box and click Next.
6. For the user that Teamcenter Integration Framework uses to log on to the Teamcenter site, type
the user name in the Site User Name column and the associated password in the Site User
Password column for the IFAdmin principal.
Perform this same process for the enterprise site entering the location for your Teamcenter Enterprise
mti.jar and mtiems.jar files, Teamcenter site ID, MUX host name, MUX port number, and the
Teamcenter Enterprise thin client web application URL.
You must define the control file to use for mapping from one site to another (one for each direction)
in the datamapper.xml file. This files defines a source and target site and the control file used
for that direction of transfer.
The map control files you use depend on the Teamcenter Enterprise solutions (data
model) you intend to support for data transfers. The standard map control files
(TC_Enterprise_to_Teamcenter_control.txt and Teamcenter_to_TC_Enterprise_control.txt) are
provided in specific locations within the datastore. There are also standard map control files for
transferring stub objects between systems in the MapControlFiles folder.
You can configure data mapping using the Teamcenter Integration Framework configuration interface
that is available from the Configure→Sites and Monitoring menu option in the Teamcenter
Integration Framework interface. The Teamcenter Integration Framework configuration interface has
embedded help available to assist you. Using the Teamcenter Integration Framework configuration
interface prevents typing errors for the elements and attribute names and is the recommended
method for configuring data mapping.
1. Log on to Teamcenter Integration Framework and choose Configure →Sites and Monitoring.
4. Select the Teamcenter site under Select source site and click Next.
5. Select the Teamcenter Enterprise site under Select target site and click Next.
6. Select the following files from the Available Transforms list (use ctrl+click to select multiple files)
and click the right arrow button to move them to the Selected Transforms list:
TcStubtoTcObj.xsl
Teamcenter_to_TC_Enterprise_control.txt
TcEntObjtoTcEntStub.xsl
RemoveFlaggedObj.xsl
RemoveFlaggedRel.xsl
7. Click Next, confirm your source and target site IDs and click Save.
9. Select the Teamcenter Enterprise site under Select source site and click Next.
10. Select the Teamcenter site under Select target site and click Next.
11. Select the following files from the Available Transforms list (use ctrl+click to select multiple files)
and click the right arrow button to move them to the Selected Transforms list:
TcStubtoTcObj.xsl
Teamcenter_to_TC_Enterprise_control.txt
TcEntObjtoTcEntStub.xsl
RemoveFlaggedObj.xsl
RemoveFlaggedRel.xsl
12. Click Next, confirm your source and target site IDs and click Save.
13. Select the Teamcenter site under Select source site and click Next.
14. Select the Teamcenter Enterprise site under Select target site and click Next.
15. Select the following files from the Available Transforms list (use ctrl+click to select multiple files)
and click the right arrow button to move them to the Selected Transforms list:
TceStubtoTceObj.xsl
TC_Enterprise_to_Teamcenter_control.txt
TcEntObjtoTcEntStub.xsl
RemoveFlaggedObj.xsl
RemoveFlaggedRel.xsl
16. Click Next, confirm your source and target site IDs and click Save.
• When you transfer objects with attached licenses from Teamcenter Enterprise to Teamcenter, the
importer checks the license status in Teamcenter and prevents attachment of a license with an
expired or locked status. To allow attachment of an expired or locked license, you must set the
GMS_expired_or_locked_ada_licenses_bypass preference value to TRUE.
Use the following process to create a map control file containing the WrkImAda_add_license_list_ada
factor.
1. If you will be attaching an expired or locked license, create the
GMS_expired_or_locked_ada_licenses_bypass preference and set its value to TRUE. (This
preference is not created by the Teamcenter installation process, so you you must create
the preference.)
Siemens PLM Software recommends that you use the following values when creating this
preference:
• Protection Scope: Site
• Environment: Disabled
• Category: TC XML Import Export.Import
Select Logical from the Type list and Single from the Multiple box.
2. Copy the WrkImAda_add_license_list_ada directory and its contents from the following location:
TC_DATA
mapping_designer_projects
ADA
TC_Enterprise_to_Teamcenter_ADA_SA
Factor
TC_DATA
mapping_designer_projects
Foundation
TC_Enterprise_to_Teamcenter_Foundation
Factor
4. Open the Factors Search view and search for the WrkImAda_add_license_list_ADA to
confirm that it is in the project.
2. In the configuration interface, choose Configure→FMS, type the site running FMS in the Site
ID box and the URL for the host name and port number for the FMS server cache in the FSC
URIs box, for example:
Site ID: 457706589
FSC URIs: http://MILLABV2:4544
Click Save.
Caution
Before performing any TC XML exports, you must remove any references to obsolete
attributes and classes from custom closure rules or property sets. Additionally, you should
remove any deprecated attributes and classes from custom closure rules or property sets.
To identify deprecated and obsolete classes and attributes, see the Teamcenter README
file for the current version.
Note
If you are using the CATIA integration and are transferring assemblies with CAD data,
you must add the following property set clause to the transfer mode you use to transfer
the assemblies:
CLASS.POM_catia_absocc:ATTRIBUTE.IsContext:DO
If you do not add this clause, the transfer fails during import with an error message
indicating the export failed at the data import step, and the log file shows the IsContext
attribute of the POM_catia_absocc class is empty.
Caution
The forceExportReplica option must be set to TRUE only when you are transferring non
BOM data. For BOM relevant data, this option should not be used or, if set, it must be
set to FALSE.
A transfer option set (TOS) is defined as a local TOS (for export transfers) or a remote TOS (for import
transfers). Data Exchange uses this TOS to pull (import) data from the remote system. The TOS has
no associated transfer mode, because the transfer mode (TM) and closure rules are defined at the
remote site. The remote site TOS is used to populate the export Teamcenter XML (TC XML) file.
Closure rules are filtered based on the options in the remote TOS.
Use the PLM XML/TC XML Export Import Administration application to create a transfer option set.
Note
A remote TOS is normally imported from a remote site to ensure that it matches the TOS
on the remote site. Although you can create a remote site TOS and manually synchronize
it to the remote site, it is recommended that you use the import (tcxml_import) and export
(tcxml_export) utilities instead to provide your remote TOS. Once a TOS is imported, you
must not change the TOS name or site reference; however, you can add or remove options
as long as the TOS at the remote site is updated to reflect the changes you make.
For remote transfer option sets, you define only the TOS name. The name must match the TOS name
defined in the remote system. You must define a local transfer option set for exporting data to another
site. A local TOS requires that you define an option row in the options table for each symbol that is
defined in the associated closure rule clause.
You can determine the options included in a TOS and get a description of their purpose in the PLM
XML/TC XML Export Import Administration application.
You can also modify the option settings, remove or add new options, and create new options in this
application. The best practice is to create a new TOS and not to modify the Siemens PLM Software
supplied transfer option sets. The standard transfer option sets are overwritten when you do a
Teamcenter upgrade; any modifications you made are lost.
If you add custom options, you must customize Teamcenter to handle them.
If you intend to transfer CATIA alternate shape representation objects between Teamcenter sites, you
must add the following property set clauses to the TIEPropertySet property set at the exporting site:
CLASS.POM_alternateSR_userdata:ATTRIBUTE.Shapes_Files:DO
CLASS.POM_alternateSR_userdata:ATTRIBUTE.Shapes_Names:DO
These property clause entries export the Shapes_Name and Shapes_Files attributes for the
POM_alternateSR_userdata object.
Teamcenter stores two versions of a dataset by default (version 0 and version latest; version 0 is a
copy of latest version). When exporting an item or item revision that contains an IMAN_specification
relation to a dataset, Teamcenter exports two datasets pointing to the same ImanFile object. You can
change the export behavior to export only version 0 of the dataset with the latest version exported as
a stub. To do this, you must add the opt_from_tc_ds0_only option to your transfer option set and
set its value to True.
Caution
Do not set this option to TRUE when you are transferring objects through a briefcase file. If
this option is not set to FALSE , the briefcase import fails.
1. In the Teamcenter rich client, open the PLM XML/TC XML Export Import Administration
application and select TransferOptionSet in the option pane beneath the tree pane.
2. Select the name of the transfer option set you want to use when transferring item or item revisions
with related datasets.
4. Select the first column (Option) of the new row (at the bottom of the list) and type
opt_from_tc_ds0_only in the Option box.
5. Press the Tab key and type Zero version export in the Display Name box.
6. Press the Tab key and select True from the Default Value list.
7. Press the Tab key and type Export zero version dataset only in the Description box.
8. Press tab and type Dataset Options in the Group Name box.
9. Click Create.
The following setup is required to ensure that the Teamcenter Enterprise owner attribute is mapped
to Teamcenter owning user and owning group.
2. In Teamcenter, create a user for every team and vault in Teamcenter Enterprise. General users
can also be created for testing mapping between the sites.
3. In Teamcenter, create a group for every team and vault in Teamcenter Enterprise with the
corresponding users created previously members with this as their default group.
This configuration ensures the following standard mapping does not cause an error on import.
Closure rules
Data Exchange provides standard closure rules that are used by the standard transfer modes
provided. To create additional closure rules, use the PLM XML/TC XML Export Import Administration
application. A closure rule must contain clauses for each type of data a site exports to another site.
You can provide conditional clauses in a closure rule. The closure rule qualifies only if the conditional
clause evaluates to TRUE. You can include symbols in a conditional clause. The symbols can be
referenced from the transfer option set and can be presented to your users as options they can turn
on and off. You enter a symbol in the conditional clause as a string that begins with a $ character,
for example:
If $HPGL
Closure rules are a component of a transfer mode and therefore must be created before the transfer
mode. Closure rules can use various action directives, such as the SKIP_GRM action that Teamcenter
uses to skip the Generic Relationship Management (GRM) objects for exports. Alternatively, the SKIP
action skips the secondary objects but includes the primary and GRM objects in the export.
For additional information about managing closure rules, see the PLM XML/TC XML Export Import
Administration.
The default closure rules used by Data Exchange to determine objects in scope changed at
Teamcenter 9.1. The following table shows the differences.
2. If an FSC for a site is not running, check the FMS configuration using the fscadmin utility against
the configuration requirements. For example:
fscadmin -s http://cvg101:4001 -k=FMS.key ./config
3. Select the item check box and choose Tools→Export→To Remote using Global Multi-SIte.
4. In the Export to Remote Site using Global Multi-Site dialog box, if the default site is not the
desired destination, click the select target site button . In the Select Target Site dialog box,
select the site listed in the Selected Sites list and click move left , select the destination site
from the Available Sites list, click move right , and click OK.
5. In the Export to Remote Site using Global Multi-Site dialog box, select the Immediate check
box and click OK.
Default
Transfer option Description value
opt_exp_cfgbom Starts the configured BOM export and controls False
the traversal flow to prevent the export of
persistent objects related to lines that are
configured out.
opt_rt_only Controls whether the exported data contains False
only runtime objects or both runtime and related
persistent objects.
opt_exp_cnf Exports the variant configuration data when the False
structure is configured by only a revision rule (no
variant rule is applied). A structure configured
this way contains more lines than are found in a
realizable product (150 percent BOM).
The export of a configured BOM using incremental change (IC) is covered as part of the revision
rule configuration. Additionally, you can control the visibility of components in the constructed BOM
with the options in the following table.
Default
Session option Description value
processUnconfiguredByOccEff Controls export of the BOMLine object False
configured out by occurrence effectivity.
Note
For Teamcenter 9.1 and later, exporting incremental changes that are applied in context of a
sublevel is not supported. Changes must be done by selecting the topline context explicitly.
Note
When synchronizing nonworkspace objects using high-level configured TC XML,
Teamcenter exports full objects even when you select the modified objects only option.
You can use low-level TC XML configured export as an alternative.
If you select the modified objects only option during an unconfigured export, Teamcenter
determines the objects requiring synchronization based on the correct parents IXR,
resulting in export of only the modified objects.
However, when there are no physical structure changes (for example, only effectivity or
revision rule changes,) both high-level and low-level TC XML export functions cannot
identify the synchronization candidates, causing full objects to be exported.
You can export a configured BOM using Global Services from My Teamcenter or without using Global
Services. You can also export a configured BOM from a command line using the tcxml_export utility.
You must be a user with administrator privileges to use the utility.
• VariantExpressionBlock
• ConfigurationCNF
• ConfigurationExprLiteral
• ConfigurationFamily
Legacy and classic variants are supported; modular and hybrid variants are not supported. You must
select the opt_exp_cnf transfer option (set to True) for this type of export.
Delta export
BOMLine objects can be updated by many workflows and actions such as:
• BOMLine updates in Structure Manager
• Computer aided design (CAD) application updates to occurrences and end items
Because BOMLine objects are runtime objects, updates must be sent on a regular basis to provide
the proper representation of a BOM in the data caches. To accomplish these updates efficiently,
Data Exchange provides the ability to:
• Assign a stable identity to runtime objects that have been exported. The identity is stored in the
accountability table.
• Identify changed (dirty) BOMLine objects by combining the date in the recipe, accountability, and
scratch tables. Edits to Teamcenter data are stored in the scratch table.
• Reconfigure changed BOMLine objects by using their occurrence thread chain. These changes
are stored in the scratch table.
Unless you specify a root object as an input for the tcxml_export utility, a delta export contains all
changes to all exported configured structures. No specific root object is used. To specify a root object,
you must use the -inputfile or -inputduidfile arguments with the -sync argument.
The process for a delta export of a specific configuration is described in Synchronize changes for a
specific BOM configuration.
• Variant rule
VRule1
BOMWindow
• Export options
Export suppressed bomlines
2. In Teamcenter, make changes to the product structure such as adding, deleting, or modifying
child components.
3. Delta export the configured assembly by specifying the top item ID and the same configuration
rules as the initial export.
tcxml_export –u=tcadm –p=admpw> –g=dba –low_level -sync
-inputfile=d:\temp\inp.txt –svrule=VRule1 –processSuppressedOcc
–optionset=TIEConfiguredExportDefault_LL –file=d:\temp\out_sync.xml
2. In the Export To Briefcase dialog box, click the Select target remote site(s) button ( ) and
select the site desired remote sites.
5. Select the desired revision rule form the Revision Rule list.
6. Select the desired variant rule form the Variant Rule list.
7. Select or type the desired directory in the Export Directory box and type the desired file name in
the Export File Name box.
2. In the Export To Briefcase dialog box, click the Select target remote site(s) button ( ) and
select the site desired remote sites.
4. Select the desired revision rule from the Revision Rule list.
5. Select the desired variant rule from the Variant Rule list.
• Select Show progress indicator to open the progress pane that shows the steps of the
transfer as they are performed.
• Select Send email notification to have Teamcenter send an email to you when the transfer
is completed.
The utility generates the output file in the same directory as the input file with the same filename
appended with Gsid. For example, the following outputs a file named jcb_llaGsid.xml in the
D:\Temp directory:
D:\workdir>java -Xms30m -Xmx500m PUID2GSIDTCXMLConverter D:\Temp\jcb_lla.xml
Note
You may need to increase the Java virtual memory (JVM) size depending on the size of
the input file.
Note
The 4GDPIEDataExportDefault transfer mode is the default transfer mode for transferring
4GD data to PLM XML.
• Cpd0DesignElement
• Cpd0DesignFeature
• Cpd0Workset
• Mdl0SubsetDefinition
• Ptn0Partition
• Partition
Caution
Exporting 4GD data in PLM XML format requires the out-of-the-box (OOTB) closure rules
and property sets defined in the 4GDPIEDataExportDefault transfer mode. If you need
a custom transfer mode, Siemens PLM Software recommends that you copy the OOTB
transfer mode and add any required closure rules or property sets to the transfer mode. Do
not delete any of the OOTB clauses, this can cause incorrect data in the exported PLM XML
• The configuration (revision rule, variant rule, effectivity, and so forth) on a subset element is
used when you export a workset.
• The configuration on the 4GD application view is ignored for the export.
• If some objects are not accessible, the corresponding elements/attributes may be missing in the
PLM XML file. This may cause the schema validation to fail.
• If you set the TIE_debug value to 2, no error occurs if some objects in the export are not
accessible. The inaccessible objects are identified as configured out in the log file.
• The 4GDPIEDataExportDefault transfer mode is supported only for 4GD exports. Do not use it
for BOM exports, this causes undefined behavior.
• 4GD subset items cannot be directly exported to 4GD PLM XML using the
4GDPIEDataExportDefault transfer mode. To export subset items, either use the PLM XML
ConfiguredDataExportDefault transfer mode instead of 4GDPIEDataExportDefault or open
the item in Structure Manager and export it as a BOM structure.
Note
By default, design features and attribute groups are not exported with a workset structure
because the opt_4gd_exp_weld and opt_4gd_exp_ag options are set to FALSE in
the TIEPLMXMLExportInternal option set. If you want these exported with the workset
structure, change the options to TRUE.
Imported objects are merged with your existing 4GD data. By default, if an imported object already
exists, the existing 4GD object is updated to match the imported object. Importing 4GD PLM XML
requires the 4GDPIEDataImportDefault transfer mode delivered with Teamcenter.
Imported 4GD PLM XML must adhere to the PLM XML standard and its restrictions. A 4GD PLM
XML file is identified to Teamcenter and differentiated from a standard PLM XML file by its Header
element's child Application element having its name attribute set to 4G. For example:
<Header id="id1" traverseRootRefs="#id2" transferContext="4GDPIEDataExportDefault">
<Application id="id19" name="4G" version="0"/>
</Header>
If you are exchanging 4GD data between Teamcenter sites, export and import data using TC XML. If
you are importing BOM data that does not include 4GD data, import using standard PLM XML.
Limitations
• Add and Modify elements (used in delta PLM XML) are not imported in 4GD PLM XML.
• The PLM XML schema allows an element in one file to reference another PLM XML file. Such
references are not supported when importing 4GD PLM XML files. In these cases, import the
XML files separately.
• Importing closure rules is not supported. All the data in a 4GD PLM XML file is imported and is
not filtered by import closure rules.
• Only major revisions are imported. Change space and minor revisions are not supported for
import.
• Run-time properties are not imported. Persistent attributes in UserData are imported.
• Business Modeler IDE extensions for operations on business objects (such as creating and
saving) are not honored or executed when importing.
• Revising objects during importing (that is, importing a new revision of an existing object and
copying or linking the related data from the old revision to the new revision) is not supported.
The 4GDPIEDataImportDefault transfer mode is the default transfer mode for importing 4GD PLM
XML. The following 4GD PLM XML elements are mapped to the listed 4GD object types on import.
The following PLM XML elements are mapped to the listed Teamcenter object types.
1. In the rich client, select the object that you want to export.
3. In the Export to Remote Site using Global Multi-Site dialog box, select a destination site
from the Site Selection list.
(Optional) Type a description in the Reason box. The reason text is stored for future reference.
Select the desired check boxes:
4. In the Remote Export Options dialog box, select the desired check boxes:
Note
The options available in this dialog box depend on the variables in the selected option
set.
If you are exporting a Requirements object, you must select the Include All Files
check box.
Specific Release Exports only the latest revision with the specified release status
Status Only selected from the list.
Product structure
options Description
Include Entire BOM Includes all components if the item selected is an assembly. The
revision selectors allow you choose revision to export with the selected
item and its component items, if applicable. You can choose only one
revision selector.
The TC_bom_level_export preference controls whether this option
is available.
Transfer Top-Level Transfers the selected assembly item and export all components with
Item Only no site ownership transfer.
Caution
Data Exchange ignores the Continue On Error option for
administrative objects and checks for the objects in the
importing database before the actual import process begins.
If they are not found, the import fails even when you select
this option.
Import to Teamcenter
Teamcenter imports data during synchronization actions (pull) or when you select from an ODS
server that you want to pull from a remote site. The following procedure shows how you import
objects in the rich client:
1. In My Teamcenter, search for the remote objects and select the objects you want to import.
2. Choose Tools→Import→Remote.
3. (Optional) In the Remote Import using Global Multi-Site dialog box, type a description in the
Reason box. The reason text is stored for future reference.
5. Click Yes.
• Item
• ItemRevision
• PSBOMView
• PSBOMViewRevision
• Form
3. In the Check-out To Site dialog box, choose the desired remote site for the Target Site list.
Optionally, type a change ID and comments in the respective boxes.
4. Click the Explore Selected Component(s) button , select related objects to check out, and
click OK. To select all related objects, click the Select All Components button .
5. Click Yes.
Data Exchange does not support site checkout of Schedule, ScheduleRevision, ScheduleTask,
ScheduleTaskRevision objects, and their related objects.
After you import the briefcase package (see Import the package file) that has objects checked out
to a site (see Check out to a remote site), you can check in the objects to your site. You can also
check in a replica object. When an object is checked in to a site:
• If it was checked out to another site, the reservation object is restored to its precheckout state.
• If the object was not checked out to another site, the reservation object is removed.
1. In My Teamcenter, select the objects that you want to check in to your site.
3. Click Yes.
Ownership of new objects added at supplier site is determined based on the following criteria:
• New objects created at a supplier site that are part of an existing island from the OEM are owned
by the OEM. For example, a dataset/version added to an Item/ItemRevision object at a supplier
site that is owned by the OEM is also owned by the OEM.
• New objects created at a supplier site that are part of a new island at supplier site are owned by
supplier, for example, adding a new Item object (component) at a supplier site to an assembly
owned by the OEM.
Note
Islands are logical groups of objects where the primary object is an item. For example,
the following objects are part of an island.
• Item (primary object of an island)
• ItemRevision
• Dataset
• Form
• Relation
• PSOccurrence
• If the object was not checked out to another site, the reservation object is removed.
• Datasets are not restored to their precheckout state. The only action is the site checkout lock is
removed.
Property
Primary object Related property or action
class type Primary object Relation type object type
CLASS Item Attribute checked_out DO
CLASS Item Attribute checked_out_user DO
CLASS Item Attribute object_type DO
Property
Primary object Related property or action
class type Primary object Relation type object type
CLASS ItemRevision Attribute checked_out DO
CLASS ItemRevision Attribute checked_out_user DO
CLASS ItemRevision Attribute object_type DO
CLASS Dataset Attribute object_type DO
You can provide a list of values (LOV) for the Partition and Template for a bid package that allows
users to select what is appropriate for their package. These Partition and Template LOVs must be
present in Teamcenter before they can be used during SRM export from Data Exchange.
Also, when you export an SRM object that has custom item or subitem types, the item type is
exported as an attribute on a standard Teamcenter item object parent for the item. This maintains the
information during transfers between systems. To support this feature, you must update the RFx
maintained properties and XML file to store the types and subtypes supported by Teamcenter.
Export to SRM
Before you can export objects to Supplier Relationship Management (SRM), you must configured
Data Exchange to enable SRM export.
1. In the rich client, select the part or assembly object that you want to export.
7. (Optional) Select a transfer option set from the Option Set list.
• If your exports do not require site checkout, set the opt_skip_sco_checks option to True.
• If your exports do not require ACL checks, set the skipPrivilegeCheck option to True.
• If your exports do not require the infer delete feature, set the inskipAddExcludedGRMs option
to True.
Note
ODS operations are not supported between Teamcenter and Teamcenter Enterprise
sites. All Data Exchange operations related to ODS are supported only for
Teamcenter-to-Teamcenter operations. This includes publishing objects to the ODS,
remote search operations, and remote import operations based on remote search results.
• To Default ODS…
Teamcenter displays the Publish to Default ODS dialog box. At this time, you can publish to
the default ODS (step 3) or select a site (step 4).
4. Click to select the site names that you want to publish to.
Teamcenter displays the Site Selection dialog box. The sites that are available are listed under
Available Sites.
5. Select the sites that you want to add to the Selected Sites list and click .
6. Click OK to apply your changes and close the Site Selection dialog box.
7. Click Yes.
3. In the Publish to Publication List dialog box, publish to a list of sites in one of these ways:
• Click Yes to publish to the sites that are in the list.
• Click to select the site names that you want to publish to.
Teamcenter displays the Site Selection dialog box. The sites that are available are listed
under Available Sites.
a. Select the sites that you want to remove from the Selected Sites list and click .
b. Click OK to apply your changes and close the Site Selection dialog box.
c. Click Yes.
3. In the Change Search dialog box, click the System Defined Searches tab.
Caution
You must select the Vendor Management feature during Teamcenter installation to create
the TIEPDXPropertySet property set that PDX export requires.
Teamcenter Environment Manager (TEM) imports the defaultTransfermodes.xml file
that contains the definitions of all standard transfer modes. The importer validates the
clauses of a property set. Because the TIEPDXPropertySet property set contains vendor
management-related clauses, if you do not select the Vendor Management feature, the
validation fails when the vendor management-related clauses are encountered. This
prevents the PDX export feature from being fully functional.
1. Map your Teamcenter objects and their attributes to PDX objects and their attributes. Teamcenter
provides a default mapping of standard Teamcenter objects to PDX objects (see Standard PDX
mapping) and a default style sheet for transforming standard objects to PDX objects.
a. Map any custom subtypes or data model changes.
b. If the default PDX transfer option set and transfer mode are not appropriate for mapping your
PDX package due to new subtypes or data model changes, define an appropriate transfer
option set and transfer mode.
A. Copy the default transfer mode file. It is recommended that naming the transfer mode file
be based on the business process.
B. Update the transfer mode to reference the information that must be exported in a PDX
package.
For details on how to change the closure rule, filter rule, property set, and revision rule,
see the PLM XML/TC XML Export Import Administration.
c. Create a custom style sheet to transform the custom subtypes or data model differences.
A. Copy the standard PDX style sheet (Tc2PDX.xsl file) located in the data directory of your
TC_DATA directory of your Teamcenter installation.
Siemens PLM Software recommends renaming the style sheet, for example,
WidgetCorpTc2PDX.xsl.
B. Change the style sheet to transform the information required in your exported PDX
package.
2. Define the transfer option sets that Teamcenter displays in the PDX export dialog box.
These are controlled by the TC_gms_export_transfermode_for_target-site-name
and TC_gms_export_default_transfermode preferences. If both are defined, the
TC_gms_export_transfermode_for_target-site-name preference takes precedence. The
transfer mode value of the preference defines the options that the dialog box displays.
a. Select the top-level sites node from the Organization List tree.
b. In the Sites pane, type a descriptive name for the site in the Site Name box, for example,
PDX site 1: PDX1.
Caution
Each site must be defined at other sites using exactly the same site ID in each
definition.
Note
The TcGS URL box is read only until you select the Uses TCXML Payload check
box.
e. For Teamcenter Integration Framework based export, type the URL used to contact the
Teamcenter Integration Framework web server port in the TcGS URL box, for example:
http://hostname:8080/tcif
g. Click Create.
4. For non-Global Services based export, attach the customized Tc2PDX.xsl style sheet to the
default PDX TIEPDXExportDefault transfer mode:
a. In a Teamcenter command shell, use the plmxml_tm_edit_xsl utility to attach the style sheet
to the transfer mode, for example:
plmxml_tm_edit_xsl -u=infodba -p=infodba
-transfermode=TIEPDXExportDefault
-xsl_file=C:\TC\tcdata\data\WidgetCorpTc2PDX.xsl
-action=attach
b. Use the utility to verify the style sheet is attached correctly, for example:
plmxml_tm_edit_xsl -u=infodba -p=infodba
-transfermode=TIEPDXExportDefault -action=list
• Set the PDX_pkg_file_name preference at the site location. The following keywords are
the only keywords supported by PDX_pkg_file_name. The keywords are case sensitive
and other values are treated as constants.
PDX-string PDX-string is a string constant prefixed to the package file name of
each exported package. You can use this to identify the package as
desired, such as by the originating site.
ItemId Includes the item ID of the exported object as part of the package
file name.
ItemName Includes the item name of the exported object as part of the package
file name.
RevId Includes the revision ID of the exported object as part of the package
file name.
TargetSite Includes the site name the object exported to as part of the package
file name.
TimeStamp Includes the time stamp information at the time the object is exported
as part of the package file name.
6. Set the PROCESS_WARM and PROCESS_TARGET parameter in the server pool properties
file (serverPoolconfiguration-ID.properties) to ensure there is a sufficient number of tcservers
available. The following are recommended minimum values for PDX export functionality:
PROCESS_WARM=5
PROCESS_TARGET=0700 10, 1700 10
8. Provide your users with the transfer option set name they must select when they are exporting a
PDX package.
Subtyped objects
The following table and figures show how the standard style sheet maps elements of TC XML data
to elements of PDX data. If these Teamcenter objects are subtyped, their corresponding sections
have to be duplicated as shown in the second figure. The standard style sheet makes extensive
use of templates (to generate BOMLine elements, Attachment elements, and so forth). Your
customizations must preserve their functionality.
<xsl:if test=”count(//tc:Item)>0
or count(//tc:Part))>0
or count(//tc:CommercialPart))>0”>
<xsl:element name=”Items”>
<xsl:for-each select=”tc:TcXML/tc:Item”>
⋮
<xsl:for-each select=”tc:TcXML/tc:Part”>
⋮
<xsl:for-each select=”tc:TcXML/tc:CommercialPart”>
⋮
</xsl:element>
</xsl:if>
<xsl:if test=”count(//tc:EngChange)>0”>
<xsl:element name=”Changes”>
<xsl:for-each select=”tc:TcXML/tc:EngChange”>
⋮
</xsl:element>
</xsl:if>
<xsl:if test=”count(//tc:ManufacturerPart)>0”>
<xsl:element name=”ManufacturerPart”>
<xsl:for-each select=”tc:TcXML/tc:ManufacturerPart”>
⋮
</xsl:element>
</xsl:if>
<xsl:element name=”History”>
⋮
</xsl:element>
<xsl:if test=”count(//tc:Vendor)>0”>
<xsl:element name=”Contacts”>
<xsl:for-each select=”tc:TcXML/tc:Vendor”>
⋮
</xsl:element>
</xsl:if>
<xsl:if test=”count(//tc:Item)>0
or count(//tc:Part))>0
or count(//tc:MyCustomPart))>0
or count(//tc:CommercialPart))>0”>
<xsl:element name=”Items”>
<xsl:for-each select=”tc:TcXML/tc:Item”>
⋮
<xsl:for-each select=”tc:TcXML/tc:Part”>
⋮
<xsl:for-each select=”tc:TcXML/tc:MyCustomPart”>
⋮
<xsl:for-each select=”tc:TcXML/tc:CommercialPart”>
⋮
</xsl:element>
</xsl:if>
<xsl:if test=”count(//tc:EngChange)>0”>
<xsl:element name=”Changes”>
<xsl:for-each select=”tc:TcXML/tc:EngChange”>
⋮
</xsl:element>
</xsl:if>
<xsl:if test=”count(//tc:ManufacturerPart)>0”>
<xsl:element name=”ManufacturerPart”>
<xsl:for-each select=”tc:TcXML/tc:ManufacturerPart”>
⋮
</xsl:element>
</xsl:if>
<xsl:element name=”History”>
⋮
</xsl:element>
<xsl:if test=”count(//tc:Vendor)>0”>
<xsl:element name=”Contacts”>
<xsl:for-each select=”tc:TcXML/tc:Vendor”>
⋮
</xsl:element>
</xsl:if>
Custom attributes
The custom attributes of Teamcenter objects must be mapped either to attributes of PDX elements or
to AdditionalAttributes PDX elements. This involves adding these tags as shown in the following
figure for the attachment element.
<xsl:attribute name="fileSize⋮>
<xsl:value—of
select=⋮//tc:ImanFile/tc:GSIdentity(@elemId=$dsId)/../@byte_size"/>
</xsl:attribute>
<xsl:attribute name="versionIdentifier⋮>
<xsl:value—of
select=⋮//tc:GSIdentity(@elemId=$imsoId)/../@version_number"/>
</xsl:attribute>
<xsl:attribute name="attachmentModificationDate⋮>
<xsl:value—of
select=⋮//tc:ImanFile/tc:GSIdentity(@elemId=$dsId)/../@last_mod_date"/>
</xsl:attribute>
<xsl:attribute name="extraAttribute⋮>
<xsl:value—of select=⋮Yes"/>
</xsl:attribute>
<xsl:element name="AdditionalAttributes⋮>
<xsl:element name="AdditionalAttribute⋮>
<xsl:attribute name="name⋮>
<xsl:text>CustomAttribute1</xsl:text>
</xsl:attribute>
<xsl:attribute name="value⋮>
<xsl:value—of
select=⋮//tc:ImanFile/tc:GSIdentity(@elemId=$dsId)/../@myCustomAttri
bute"/>
</xsl:attribute>
</xsl:element>
</xsl:element>
The style sheet must be extended for any other PDX specification elements that you want in addition
to these (for example, SupplierPart). Use the standard style sheet as a reference for adding the
additional elements.
The PDX export feature is available within the rich client from the Tools menu. PDX export can be
used within a workflow and a PDX package can be accessed within a workflow the same as any
dataset.
The Teamcenter objects that can be exported to PDX and how they are mapped to PDX objects by
the out-of-the-box (OOTB) mapping file, are described in Standard PDX mapping.
Note
Unmanaged sites are not listed as available export sites for PDX.
a. (Optional) Type the reason you are exporting the package in the Reason box.
b. Click Select target remote site to the right of Target Sites to select the export destinations
for the objects.
c. Select the PDX option set from the Option Set list.
Progress Indicator Displays the progress pane automatically when the process starts.
email Notification Requires Data Exchange to send an email when the transfer is
complete to the address associated with the requesting user.
e. (Optional) Click export options to select the transfer options for the PDX package.
Note
The options available in this dialog box depend on the variables in the selected
option set.
4. Click Yes.
After the export completes, open your Mailbox to locate the PDX package. You can copy the
package to another location in Teamcenter or download the package to the file system.
A PDX package is a dataset that is accessible from a workflow process like any dataset. You can
attach or refer a PDX package to another object in a workflow process. You can copy a document
to be sent as a reference document in the process dialog box.
1. Click Search on the toolbar or select Advanced from the search menu at the top of the
navigation pane.
Note
The software ships with Item selected as the default search.
3. In the Change Search dialog box, click the System-defined Searches tab, select Dataset
search from the list, and click Change Search.
4. In the Search pane, select PDX from the Dataset Type list and click execute.
Note
The Abort button in the upper left corner is active while a query is running, but it
cannot stop the database query process once it starts.
If you have the proper privileges, you can delete a PDX package by selecting the package and
pressing the delete key.
2. In the Named References dialog box, select the PDX package file in the Name column and
click Export.
3. Type, or browse to, the location where you want to place the PDX package and click Export.
• Requires data push (manual file transfer, such as email attachment) unless you are using the
Supplier Collaboration solution.
• Supports round-trip exchange of CAD data (stubs for remote objects not checked out to site
in the briefcase file).
For briefcase packages containing NX data, when a supplier owns the object locally or the object is
checked out to the supplier site, infer delete is allowed for occurrences in any type of export. This
includes exports with incomplete, variant, or partial CAD data. For briefcase packages with CATIA
data, infer delete of occurrences is not allowed for exports with incomplete, variant, or partial CAD
data.
Exports to unmanaged sites do not create an export record (IXR) in the database. For performance
reasons, the briefcase accountability table is used instead for unmanaged exports. Therefore, the
object is displayed in Teamcenter with no value in the Exported To column in the rich client.
You must set the include_all_objects option in the CustomMappings.xml file to true if you are
adding objects to a CAD part in the CAD application. Otherwise, the new objects are not shown when
you import the briefcase file into Teamcenter.
Unmanaged sites exchanging NX data must supply English characters for the item ID, revision, and
name attribute values. Other locales are not supported in this use case.
If your site is a managed Teamcenter site, you must perform the migration procedure before using
Briefcase Browser at your site.
Caution
Briefcase Browser does not support the Item:sci0IsIMDSObject property added by the
International Materials Data System (IMDS) template. Therefore, if you are exchanging
data with an unmanaged site, you cannot have this template installed in Teamcenter or you
must manually remove the property occurrences from the briefcase file.
Note
Briefcase Browser cannot operate on NX alternate representations (UGALTREP objects).
Therefore, for performance reasons this clause is not included in the unmanaged transfer
option set. If you want this data to display in Briefcase Browser, add the follow clause to
the TIEUnmanagedExportforNX transfer option set:
CLASS.ItemRevision:TYPE.UGALTREP:RELATIONP2S.IMAN_UG_altrep:Process+traverse: $opt_nx_altrep=="true"
Note
By default, when you import a briefcase file created from an NX
assembly or part, Teamcenter does not parse the clone output log
file (ug_clone_import_console_output.log for the ug_clone utility or
tcin_import_import_console_output.clone for the tcin_import utility). If you require
parsing of the clone output log file for debugging, you must set the BC_NX_DEBUG
environment variable value to TRUE at the importing site. However, do this only if
absolutely necessary as this may cause an error to occur during the import.
Note
To export an assembly that is either:
• Cloned from a replica or an assembly that is checked out to a remote site
• Created using the Save As command on a replica or an assembly that is checked
out to a remote site
You must set the opt_based_on option to FALSE in the transfer option set or clear the
Include IMAN_based_on checkbox in the Export to Briefcase dialog box.
Symbol Privilege
Read
Write
Export
Import
Transfer out
Transfer in
If these access privileges are not set, the transfer back to Teamcenter fails because the Teamcenter
user does not have the required object access privilege.
You must create and set the GMS_tcxml_string_separator preference at the exporting site location
to allow a Teamcenter 2007 version prior to MP4 to import a briefcase package file from the site.
1. Log on to Teamcenter as a user with administrator privileges.
3. Click the Create a new preference defiintion button ( ) and type GMS_tcxml_string_separator
in the Name box.
4. Select GMS Offline.Import from the Category list and Site from the Protection Scope list.
7. Click Save.
To enable object-based site checkout of objects in export briefcase files, you create the
Object_based_site_check_out logical preference and set its value to true.
When object-based site checkout is enabled, if you select an item revision as the root object, the
selected revision, its helper objects, and the related item and its helper objects are candidates
for site checkout. If an item is selected for site checkout, based on the revision rule selected, the
corresponding item revision and its helper objects are candidates for site checkout.
By default, Teamcenter uses the TIEUnconfiguredExportDefault option set for traversal. You can
use a different option set by creating the option_set_for_site_check_out preference and setting its
value to the desired option set.
This also applies to Cancel check out and Site check in.
2. Log on to Teamcenter as a user with dba privileges and open the Organization application.
3. Define a site for the unmanaged site. Select the Uses TCXML Payload, Is Offline, and Is
Unmanaged options.
4. Ensure the following preference values are set at the site location:
TC_gms_export_default_transfermode=TIEExportDefaultTM
TC_gms_import_default_transfermode= TIEImportDefault
TC_show_checkedout_icon = TRUE
BRIEFCASE_export_CAD_incomplete = FALSE
You can set this to TRUE if you want to allow incomplete CAD exports. Siemens PLM
Software recommends the following settings:
• Protection Scope
User
• Category
General
• Environment
Disabled
• Multiple
Single
• Value
FALSE
BRIEFCASE_import_validation_rule_item = item_id/rev_id
item_id/rev_id indicates the item that contains the dataset validation rules. For example, set
the value to 000123/B for the dataset attached to item (item_id) 000123 revision (rev_id)
B as the validation rule dataset.
Siemens PLM Software recommends the following settings:
• Protection Scope
User
• Category
General
• Environment
Disabled
• Multiple
Single
The package name is the OEM site name. It contains the CustomMappings.xml file with the OEM
site ID set as the target site ID. It also contains the TCXML.xsd schema file, generated from the
OEM and the OEM configuration file.
site-id.properties
Defines the unmanaged site ID. This value can be any numeric sequence not starting with a zero
and is not required to meet Teamcenter site ID requirements. If this file is not present, Briefcase
Browser does not allow you to create a briefcase file. You can create or modify this file manually
or use the Preference dialog box in Briefcase Browser.
Note
The uniform resources identifiers (URIs) that appear in the headers of PLM XML and
TC XML files serve as namespace names, are unique identifiers for an XML vocabulary.
Although they are URIs, they are not used to identify and retrieve web addresses.
CustomMappings.xml
Defines information about the Teamcenter (OEM) site that you exchange briefcase files with.
This information includes:
• The site name.
• If your site must use the auto_baseline (baseline) feature when exchanging updated
briefcase data.
• If your site must create all replica objects as stubs (include_all_objects=false). When
writing reference objects as stubs, Briefcase Browser does not package any corresponding
CAD data in the briefcase package. If this value is set to true, Briefcase Browser writes all
objects as full objects in the briefcase file reference replica parts.
• If your site must include full objects for all checked-out parts and locally owned parts
(include_modified_objects_only=false). If this value is set to true, Briefcase Browser
writes local parts as full objects and parts checked out to your site as full objects if they are
modified since the file was last saved, including their parent and grandparent objects. If
objects checked out to your site have not been modified, they are written as stub objects and
the corresponding part files are not included in the briefcase package.
• The separator character the site requires between the item ID and revision.
• Define the release status values the managed (OEM) site allows you to assign to parts or
assemblies you create in the release_status_name elements. Briefcase Browser displays
the values that you supply in release_status_name elements in the Release Status Name
list in the Preferences dialog box. The value you select in the Preference dialog box is
assigned as the release status of any new CAD parts or assemblies you create. The value
must match one of the valid values for Teamcenter release status at the OEM site.
<helper_object_map custom_type="Part--Master"
ootb_type="Item--Master"/>
<helper_object_map custom_type="Part--Revision--Master"
ootb_type="ItemRevision--Master"/>
</item_type_mapping>
</custom_mappings>
The auto_baseline attribute indicates the whether or not your Briefcase Browser provides
autobaseline functionality. If this is set to true, the baseline feature is enabled. The template
file has this value set to true. If it is set to false, Briefcase Browser does not automatically
revision objects. If the attribute is not defined in this file, Briefcase Browser performs automatic
revisions as if the attribute was set to true.
If the briefcase file you are exchanging must contain precise assembly structures, you set the
is_precise attribute to true. Set this value to false when imprecise assembly structures are
allowed.
If you intend to add objects to CAD parts in the CAD application, you must set the
include_all_objects attribute to true to include them when you save the briefcase file for
exporting back to Teamcenter.
You can have any number of release status elements. These become the selection list for
Release Status in your Briefcase Browser preferences dialog box.
You map custom CAD parts types to OEM types by assigning a custom Item type to the items
in the TC XML data created for your CAD part. You define the subtype of the Item type as a
helper object, for example:
<helper_object_map custom_type="CADPart" ootb_type="Item"/>
This causes the TC XML data generated for custom CADPart supplier owned parts to be created
as Item objects at the OEM site.
Note
The custom item type must be defined in the schema (TCXML.xsd) file used by
Briefcase Browser.
You can have multiple custom types defined in this file. Briefcase Browser locates the matching
custom in the file and maps the file to the defined OEM object. If a custom type part is not found
in the CustomMappings.xml file, the first custom type defined in used. If there are no custom
types defined, Briefcase Browser maps the part to the standard Teamcenter.
CustomDatasetMappings.xml
This XML file contains valid dataset extensions and relation types supported for Non-CAD files.
Each dataset extension specifies whether it is a master, dataset name, ref_names, and relation
to be used while generating TC XML. Each relation type specifies the display relation for the Add
Dataset dialog box and the actual relation to be used for generating TC XML. If this file is not
found, an OOTB file is used. You can add additional non-CAD types to this file.
Caution
If your system has CAD dataset types other than the master dataset, and the dataset
type follows the model file naming convention, you must add an entry representing the
dataset. Add the entry with the is_master attribute set to False, for example:
<cad_data_set_mapping is_master="False" dataset_type="UGPART"
ref_names="UGPART" relation=""/>
This prevents a error form occurring when you open or synchronize an updated CAD
assembly in Briefcase Browser.
cad_to_tc_attribute_map.xml
Defines the mapping of user-defined NX attributes to qualified Teamcenter object attributes.
The user-defined attributes must be part of the configured TC XML schema (TCXML.xsd file).
This allows you to define attributes for qualified objects in addition to the required attributes, for
example:
Caution
You can map only one CAD part attribute to one Teamcenter attribute (1-to-1 map).
Mapping a CAD part attribute to multiple Teamcenter attributes or a single attribute to
multiple item types can cause corrupt or lost data.
<!-- Only one CAD2TC_attribute_mappings that can contain more than one
attribute map. These mappings will hold a list of CAD attributes
that map to teamcenter attribute -->
<CAD2TC_attribute_mappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="cad_to_tc_attribute_map.xsd">
<!-- cad_part_attr should be unique for each attribute_mapping -->
<attribute_mapping cad_part_attr="PART_MATERIAL" tc_attr="nisPartMaterial"
tc_type="CAD--Revision--Master"/>
<attribute_mapping cad_part_attr="PART_THICKNESS" tc_attr="nisPartThickness"
tc_type="CAD--Revision--Master"/>
<attribute_mapping cad_part_attr="CALC_WEIGHT" tc_attr="nisCalculationWeight"
tc_type="CAD--Revision--Master"/>
<attribute_mapping cad_part_attr="CALCULATIVE_COEFFICIENT"
tc_attr="nisCalculativeCoefficient"
tc_type="CAD--Revision--Master"/>
<attribute_mapping cad_part_attr="Z_CENTROID" tc_attr="nisGravityZ"
tc_type="ItemRevision--Master"/>
<attribute_mapping cad_part_attr="Y_CENTROID" tc_attr="nisGravityY"
tc_type="CAD--Revision--Master"/>
<attribute_mapping cad_part_attr="X_CENTROID" tc_attr="nisGravityX"
tc_type="CAD--Revision--Master"/>
</CAD2TC_attribute_mappings>
visible-attributes.xml
Defines the attributes that are displayed in Briefcase Browser properties views. By default,
Briefcase Browser displays all qualified attributes. If this file is present, Briefcase Browser limits
the attributes in the properties views to the attributes defined in this file. The following is sample
content for this file:
<visible_attributes>
<group name="Item">
<attribute ootb_type="Item" name="item_id"/>
<attribute ootb_type="ItemRevision" name="object_name"/>
<attribute ootb_type="ItemRevision" name="object_description"/>
</group>
<group name="Admin">
<attribute ootb_type="POM_imc" name="POM_imc"/>
<attribute ootb_type="Group" name="Group"/>
<attribute ootb_type="User" name="User"/>
</group>
</visible_attributes>
attributes_text_locale.xml
Defines the localized values for the language indicated by the name of the directory containing
the file. The directory name consists of a two-character locale and two-character country code
such as en_US. The language directories must be in the lang directory in the site’s configuration
directory.
For example, the following shows the US English (en_US) and the Japanese localization (ja_JP)
directories:
configurations
default
dashboard_supplier
lang
en_US
ja_JP
Briefcase Browser reads the TC XML file content and displays the object property names as
defined in the file. The properties are database field names that may not be readable by your
users. You can use this file to map the database field names to usable localized names.
Note
Your attributes_text_locale.xml files must be UTF-8 encoded. They must also
contain the following element as the root XML element in the file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
If the property names do not display in your locale language, use a different text editor
for UTF-8 encoding.
The following is sample content for this file in the Japanese locale:
Sample files are provided for each of these configuration files in the
example\bbworkspace\exmple\configurations\example directory.
3. Click the Create a new preference defiintion button ( ) and type Briefcase_tcmail_notification
in the Name box.
4. Select GMS Offline.Import from the Category list and Site from the Protection Scope list.
5. Type Controls creation of automatic envelope for briefcase package the mailbox folder in
the Description box.
7. Click Save.
To turn this feature off, set the preference value to FALSE or delete the preference.
Note
Previewing a briefcase in the rich client is not supported when the rich client is installed on
UNIX operating systems. It is supported only when the rich client is installed on Windows
or Linux operating systems.
1. If you have not configured the viewer or need to change the configuration for the package
content, choose Window→Preferences.
a. Click Explorer in the Preferences dialog box. Note the location of the default configuration.
This is the location that contains the configuration that the viewer uses.
b. Browse to the site configuration files directory (TC XML schema file, custommappings.xml
file, and so forth).
Note
You can also click Comparison Preferences in the Briefcase Preview pane to
open the Preferences dialog box.
2. In the Options dialog box, click Filters and type GMS_offline_use_TcGS in the Filters box.
3. Click Edit, type false in the Value box, and click Save.
4. If you want to change the default value (Latest Working) for the revision rule used to configure
a partition:
a. Type TC_config_rule_name in the Filter box.
b. Click Edit, type the revision rule name in the Value box, and click Save.
Note
The exporting user can override the default revision rule value by selecting the
desired rule name from the Revision Rule list.
2. Ensure that any shared data is not checked out to a remote site.
b. At the supplier site, create a baseline of the supplier data that has been sent to the OEM site.
All new revisions occur in the migrated unmanaged site. Shared objects have multiple revisions,
and OEM replica parts are not baselined.
4. If the supplier site is a hub site, in the Organization application, clear the Is a Hub check box
for the supplier site.
5. At the supplier site, export all supplier owned objects to a briefcase file.
a. Choose Tools→Export→To Briefcase.
b. Select the unmanaged site and click the Display/Set remote export options button .
c. In the TIEConfiguredExportDefault dialog box, select the Replica Bypass check box.
Note
You may have to scroll down to access the check box.
• Supplier-owned data.
7. Install Briefcase Browser at the supplier site being migrated using the same site ID as the
managed site for the unmanaged site.
8. In Briefcase Browser, extract all briefcase files in the migration working directory.
10. In the Organization application at the OEM site, modify the previously managed supplier site by
selecting the Unmanaged option for the site.
11. At the unmanaged supplier site, use Briefcase Browser to add parts to new assemblies. You can
copy the required .prt files to a new working directory and create briefcase files based on them.
12. Transfer briefcase files to the OEM and import them into Teamcenter using Tools→Import→From
Briefcase.
2. In the Options dialog box, click Filters and type GMS_offline_use_TcGS in the Filters box.
3. Click Edit, type false in the Value box, and click Save.
4. If you want to change the default value (Latest Working) for the revision rule used to configure
a partition:
a. Type TC_config_rule_name in the Filter box.
b. Click Edit, type the revision rule name in the Value box, and click Save.
Note
The exporting user can override the default revision rule value by selecting the
desired rule name from the Revision Rule list.
2. For each object that the unmanage site must update that they do not locally own, select the object
and choose Tools→Site Check-In/Out Check-out To Site.
Tip
Because the types of non-CAD datasets you may want to export are various, for
performance reasons, unmanaged site exports do not have support for any specfic
non-CAD datasets out-of-the-box. If you need to include non-CAD datasets in the
export, you must add a clause to the transfer options set you are supporting to allow
the export of datasets required.
For example, to add support for Microsoft Word (MSWORD) datasets to your export,
include the following clause in the closure rules for the transfer option set:
ItemRevision:MSWORD:Iman_reference.*
4. (Optional) Type an identifier in the Change ID box and a comment in the Comments box.
5. Select the select the item revision associated with the top level of the assembly structure that
you want to export and choose Tools→Export→To Briefcase.
Teamcenter displays the Export to Briefcase dialog box.
8. Select the option set you want to use for this transfer from the Option Set list. Select the standard
option (TIEConfiguredExportDefault) for configured exports or one of the other available option
sets. For transfers containing NX data, select TIEUnmanageExportForNX.
9. Type or navigate to the desired directory in the Export Directory box. This is the location where
you can access the generated briefcase file for transfer to the unmanaged site.
10. Select the desired revision from the Revision Rule list.
Note
Unmanaged sites do not have the ability to manage dataset versions, this means the
latest version, and only the latest version, is required. Therefore, the Dataset version
0 only option is selected by default and is read-only.
If you select the Include modified objects only session option, unchanged objects
are exported as stubs, unless a new or changed dependent object appears under the
selected root object. The export process recognizes a change to the lsd attribute of
the item causing a full export of all revisions.
Note
If you are transferring an assembly with at least one part marked for ownership transfer
to the importing site (not the entire assembly), you should transfer the parts that have
ownership transferred in a separate briefcase file. Otherwise, you must create closure
rules to prevent transfer of ownership of other parts in the assembly to the importing
site.
2. In the Validation Rule Editor, create a new rule set with the checker attribute value set to
mqc_upodate_all_features and the Dataset Types attribute value set to UGMASTER.
4. In Teamcenter, create a validation rule set dataset and import the rule file you created into the
new validation rule set.
6. Import the briefcase file and verify the validation forms for the imported item revision are present.
2. Navigate to or type the path and file name of the briefcase file in the Briefcase File box. Select
TIEImportOptionSetDefault from the Option Set list.
3. Click the Display/Set export options button and select the desired options.
4. (Optional) Select the Site Check-In after import box. If you select this box, all objects that are
checked out to the unmanaged site are checked in during the import process. Otherwise, you
must check them in individually after they are imported.
Note
Teamcenter 8 and later recognizes both bcz and ugs extensions as briefcase files. If
you are exporting to a Teamcenter site prior to Teamcenter 2007 MP4, the importing site
recognizes only the ugs extension as a briefcase file.
3. In the Export to Remote Site Via Global Services dialog box, if the desired destination site is
not in the Target Sites box:
b. In the Remote Sites dialog box, select the desired site from the Available Sites list, or select
Any Site to create a standard package file, and click .
c. Select the sites in the Selected Sites list that you are not the desired site and click .
d. Click OK.
4. Select the desired transfer option set from the Transfer Option Set list.
Note
The Transfer Ownership check box is on this secondary dialog box. Therefore, this
step is not optional if you want to transfer ownership and it is not selected by default.
7. In the Export Options dialog box, select the desired check boxes:
Note
The options available in this dialog box are dynamic and depend on the variables in
the selected transfer option set.
Product structure
options Description
Include Entire BOM Includes all components if the item selected is an assembly. The
revision selectors allow you choose revision to export with the selected
item and its component items, if applicable. You can choose only one
revision selector.
The TC_bom_level_export preference controls whether this option
is available.
Transfer Top-Level Transfers the selected assembly item and exports all components with
Item Only no site ownership transfer.
Note
If a change is made to any dependent revision in an
assembly, the last modified date of the assembly is updated.
Therefore, the assembly and all its dependent revisions are
exported as full objects.
Continue On Error Allows the remote import or export objects operation to continue if
errors are encountered while importing/exporting optional objects. All
objects are considered optional except the following:
Requirements
Specifications
Item Master
Item Revision Master
This option is disabled if the Transfer Ownership option is set.
8. Click OK.
9. Select the briefcase package file and export the package to the file system.
Caution
If you are exporting to a Teamcenter site prior to Teamcenter 2007 MP4, the importing site
recognizes only the ugs extension as a briefcase file. Teamcenter 12 generates briefcase
files with a bcz extension. Therefore, you must change the extension of the package file
to ugs before transferring it. Teamcenter 12 recognizes both bcz and ugs extensions as
briefcase files.
6. Use email, FTP, or some other manual method to transfer the package file to the importing site.
2. In the Import from Offline Package dialog box, type the path to the briefcase package file
or click the browse button and select the file.
4. Click OK.
Teamcenter imports the briefcase package file.
• Metadata transfer and ownership transfer that are two distinct processes.
• Synchronization:
o For the modified objects, the complete island of data is exported.
o For unconfigured data, the synchronization applies to the complete data in the accountability
table. The synchronization cannot limited to a particular root object.
• For configured BOM objects, you can synchronization either a specified assembly configuration
or all the configurations. However, BOM synchronization does not support product structure unit
or date effectivity changes.
Caution
To avoid a possible 515106 error (A relation cannot be saved because it violates a
unique index), you must translate the TC XML import file when you are exporting from an
earlier version of Teamcenter to the current version. If you use the site consolidation default
import transfer mode (SiteConsolidationDefaultTMImport), Teamcenter translates the
import file for you automatically during the import process.
If you use custom transfer modes to import data, you must attach the
Mapping_of_copy_stable_id.xsl style sheet to the custom transfer mode to translate the
import file during the import process. This file is located in the TC_DATA directory. Use the
plmxml_tm_edit_xsl utility to attach the style sheet to the transfer mode.
Use the following transfer option sets to leverage low-level TC XML with Briefcase:
• TIEUnconfiguredLLBCZExportDefault for unconfigured Briefcase export using TC XML.
When using these transfer option sets, be aware of the following items:
• Anchors are exported and imported.
• When importing objects that already exist at the target site, but the target site is not the owning
site, the last save dates (lsd) of the objects are compared. If the lsd of the object in the TC
XML is more recent than that of the existing object at the target site, the object is updated. If
the lsd values are the same, or if the lsd of the object in the TC XML is older, the object is not
updated at the target site.
In the Mapping Designer tool, you can create a new project or open an existing one, such as the
standard sample projects. All the mapping information between a source and a target site are stored
in the form of a Mapping Designer project. A project contains the following information:
Each factor contains source and target objects, their selected properties, instance filtering rules,
and factor dependencies. A factor defines conceptual element of the source or target systems.
Defining factors and specifying the transformation for each factor separately simplifies the
mapping process and allows a more manageable definition.
This is the master transform file used by the mapping engine. It references the factors that are
defined and their corresponding transformations (XSLT).
These identifiers help Mapping Designer track generic system the source and target schema belong
to. A Mapping Designer project retrieves this from the schema files and stores it as project properties.
The property names are sourceendpoint and targetendpoint. The factors created/stored in
the project individually store this information, so each factor identifies that it is valid for a specific
sourceendpoint and targetendpoint property. This information is helpful when a factor is being
imported.
Mapping data between different systems results in the possibility that data can be lost under certain
circumstances. An example of this possibility is when the following conditions exist:
• The object is subsequently determined to have been transferred in error and the transfer is
undone.
This situation could result in the loss of data because when an object is transferred from Teamcenter
Enterprise to Teamcenter, some attributes are dropped during the mapping processing. This is due
to data model incompatibility and because some Teamcenter Enterprise attributes are not needed
in Teamcenter (or vice versa). When ownership is transferred back to Teamcenter Enterprise from
Teamcenter, data loss could occur because when an attribute is not sent to Teamcenter, there is no
way for it be repopulated in Teamcenter Enterprise on the reverse trip.
Prepare Teamcenter, Obtain and create a bulk import utility System administrator
legacy data, and the key and configure a logical volume for
associated physical files physical files in Teamcenter.
for import into Teamcenter
Validate the import file Validate your TC XML import file meets System administrator
Teamcenter requirements. Correct any
validation errors.
Bulk load objects Load data and correct any issues that System administrator
occur using bulk load repeat files.
The following figure shows the bulk load business process and roles:
• Supports the following business objects and their subclasses and subtypes:
Item, ItemRevision, and the related master forms
ImanRelation
Dataset and ImanFile
PSBOMView, PSBOMViewRevision, PSOccurrence, and PSOccurrenceNotes
ReleaseStatus
• Allows mapping a CSV column value into any standard or custom business object and its
attributes. A single column value can be mapped to single or multiple objects and their attributes.
• Provides a column lookup feature. You can use this feature to replace the column value with
a new value from an external file. For example, if the owning_user attribute values on the
source system are different from the values in Teamcenter, the source system values and their
replacement values can be provided in an input file and the converter replaces them during
conversion.
• Groups objects into islands according to Teamcenter islands of data export/import process.
Multiple islands can be combined together based on a preference for better import performance.
• Supports data conversion in a modular method using CSV files. Item and item revision related
information are processed separately and similarly BOM, relation, and dataset related information
can be processed individually.
• Provides various validations, and violations are captured in a log file as errors or warnings.
o Validates that business object names and attributes used in column headers are valid in the
schema.
o Validates that Item, Dataset, ImanRelation, and PSBOMView type names are valid in the
schema.
o Validates that ReleaseStatus, PSViewType, and NoteType values are valid in schema.
o Validates that LOV values on attributes and length of string attributes are valid.
o Checks for different revisions of the same item having different item types.
• Allows you to set chunking of large XML files based on a size defined in a preference.
• Provides a progress indicator during conversion and an HTML report for data, performance,
and errors.
• Supports CSV files of any size configured by a preference to unload objects from memory after
certain number of lines in the file is reached. This provides scalability.
• Supports data extraction from Business Modeler IDE template XML files for standard and
custom data models.
Caution
If you open a CSV file in Excel to view its contents, do not save the file as CSV
from Excel. Excel may add extra characters when the file is saved that prevent the
CSV2TCXML utility form converting it successfully,
Note
The CSV2TCXML utility does not support infer-delete of objects.
Open the csv2tcxml_column_names.txt file. Examine this file to understand all possible CSV
column names for item, dataset, imanrelation, and psoccurrence types including the standard and
custom attributes. This file also lists the attribute type (integer, double, string, and so forth) for each
column name, and allowed values if that attribute is a list of values (LOV).
Design Intent
The owning_user column is not a required column in the input CSV file. If you omit this
column, the converter uses infodba as the default value. However, if you include this
column, the values must match an existing User object's user_id attribute value (not
user_name) in the importing site's database.
Also, the owning_group is not a required column. If you omit this column, the converter
uses dba as the default value. However, if you include this column, the values must match
an existing Group object's name attribute value in the importing site's database.
For the following columns, the column name represents a reference attribute. However, the value you
use in the column is a string, not a reference. For example, the value to use in a CSV file for the
owning_user column must match the value of an existing User.user_id attribute in the Teamcenter
database where you want to import the XML file.
You can migrate bulk data from legacy/enterprise systems to Teamcenter by extracting the data in
a format similar to a comma-separated values (CSV) file (using SQL or other tools in that system)
and converting it into TC XML using the converter. By default, the separator is a pipe character (|)
instead of a comma. The output TC XML file can be imported into Teamcenter using the bulk load
function of the tcxml_import utility.
1. Start a Teamcenter command shell as a Teamcenter administrator and change to the
TC_DATA\csv2tcxml_perl directory.
3. Open the csv2tcmxl_config.txt file and add appropriate values to the following variables:
source_site=site-id Defines the site ID of the exporting site. This site must be defined in
Teamcenter prior to importing the migrated objects.
volume=volume-nameDefines the name of the volume where Teamcenter stores the files related
to imported datasets.
sdpath= Defines the operating system directory containing the volume where
Teamcenter stores the files related to imported datasets. Provide the name
only, do not include the path.
4. Modify and add additional configuration variables that you need in the csv2tcmxl_config.txt file.
The file contains descriptions of the most commonly used variables and their default value if they
have one. Some of the less commonly used variables are commented out by default. To add
these variables, uncomment them and provide a default value.
Note
You can override any of the variable values in this file temporarily by adding them
into the command line arguments when you type the command. Use the format
argument-name=argument-value.
o For Item object files, add an Item:object_type column in the first (header) row and
populate the column in all other rows with the name of the Teamcenter Item subclass.
o For BOM or GRM object files, add parent_type and child_type columns in the header
row and populate the column in all other rows with the object type for the parent
(assembly) and child (component) objects.
• If the input data contains two or more objects with the same item_id value and they are
of the same class, determine another attribute that is unique and set the mfk_columns
variable as follows:
mfk_columns|name-of-unique-attribute,parent_type,child_type,parent_mfk,child_mfk
Ensure that the following columns are present in the CSV file:
o For Item object files, add Item:object_type and a column for the unique attribute in the
first (header) row. Populate the column in all other rows with the name of the Teamcenter
Item subclass and the unique attribute.
o For BOM or GRM object files, add parent_mfk and child_mfk columns in the header
row and populate the columns in all other rows with the multifield key value for the
parent and child items.
• If you use an attribute other than object_type in the mfk_column variable and:
o The attribute is defined at an abstract parent class.
o You want to use only one configuration file for all migrations (alternative to redefining
the mfk_column variable for each class).
For example, the data you are migrating uses several Item subclasses, each with a common
parent class that defines the TDM_ID attribute. This attribute is used as part of the multifield
key for all the child classes. To specify the TDM_ID attribute as part of the multifield key
for all the child classes, set the variable as:
mfk_columns|$CLASS:TDM_ID,parent_type,child_type,parent_mfk,child_mfk
When the converter encounters $CLASS in the mfk_columns variable, it checks for an
attribute by that name for the class and replaces $CLASS with the object_type value.
lookup_columns
Specifies the name of a separate lookup file or files for the specified attribute or attributes.
For example, to specify lookup files for the object_type and owning_user attributes, set the
variable as follows:
lookup_columns|Item:object_type,owning_user
The converter looks for files named Item_object_type.txt and owning_user.txt. Any colon (:)
characters in the attribute name are converted to underscore (_) characters. The converter uses
the contents of the files to replace the values in the output TC XML file.
The lookup text files must contain separate lines formatted as old-value|new-value.
puid_lookup_file
Specifies a lookup file containing separate lines of puid/item_id value pairs for standard key
values or puid/item_id/object_type value sets for multifield key values. For example, for
standard key values, the lines are formattted as:
puid-value|item_id-value!
puid-value|item_id-value!A
Instead of generating PUID values during the conversion process, the converter uses the file to
obtain existing PUID values. Use this when the importing site has existing data, either created
locally or previously migrated without using the converter, and you must migrate additional data
that must be related to the existing data.
You can generate the lookup file by running a simple SQL script to extract puid and item_id
values from the Teamcenter database.
skip_special_chars
Specifies whether the converter processes XML special characters, such as (the XML
numeric representation of \n) in the CSV file. By default, the converter processes them. To skip
the processing of these special characters and pass them through unchanged in the ouput TC
XML file, set the variable as:
skip_special_chars|1
disable_attr_truncation
Specifies whether the converter truncates string attribute values to the maximum length as
specified in the ATTR_LENGTH value in the csv2tcxml_datamodel.txt file. The converter
also generates a warning when an attribute string is truncated. To disable the truncation, set
the variable as:
disable_attr_truncation|1
The following listing shows a sample dataset.csv file containing dataset information:
!Item:item_id|ItemRevision:item_revision_id|Dataset:dataset_type|Dataset:object_name|
ImanRelation:relation_type|owning_user|owning_group|creation_date|last_mod_date
18-0003|A|Text|AssmText|IMAN_reference|migration|dba|2000/02/04-19:24:23|2000/02/04-20:12:23
18-0004|A|DirectModel|CompJT|IMAN_Rendering|swaminat|dba|2000/02/04-19:24:23|2000/02/04-20:12:23
18-0005|B|UGPART|CompPart|IMAN_UG_altrep|mholt|dba|2000/02/04-19:24:23|2000/02/04-20:12:23
18-0006|G|MSWordX|CompDoc|IMAN_requirement|migration|dba|2000/02/04-19:24:23|2000/02/04-20:12:23
The following listing shows a sample bom.csv file containing BOM information:
parent_item|parent_rev|child_item|child_rev|PSOccurrence:seq_no|PSOccurrence:qty_value
18-0003|A|18-0004|A|10|1
18-0003|A|18-0005|B|20|5
18-0003|A|18-0006|G|30|3
The following listing shows a sample grm.csv file containing relation information:
!parent_item|parent_rev|child_item|child_rev|ImanRelation:relation_type
18-0003|A|18-0004|A|IMAN_reference
18-0003|A|18-0005||IMAN_requirement
18-0003||18-0006|G|TC_Attaches
18-0003||18-0006||IMAN_based_on
The utility requires the following format in the CSV file by default:
• The pipe character (|) is the column separator.
• The exclamation character (!) is the first character in the line that defines header/column names.
• The comma character (,) is the variable length array (VLA) attribute value separator.
• Date values are formatted as YYYY/MM/DD-hh:mm:ss. The utility converts the dates to
Teamcenter format, YYYY-MM-DDThh:mm:ssZ. The time may be omitted, in which case the utility
appends T00:00:00Z to the date information.
For example, if the date supplied is 2000/02/04-19:24:23, the utility converts it to
2002-02-04T19:24:23Z. If the date supplied is 2000/02/04, the utility converts it to
2002-02-04T00:00:00Z
o For BOM files, a PSOccurence object and its related objects and attributes.
o For GRM files, a generic relation management rule and its related objects and attributes.
o For dataset files, a dataset object and its related objects and attributes.
• There cannot be duplicate dataset types with the same dataset name under any item revision.
Note
Empty characters at the end of an item_id attribute are skipped during the creation and
lookup to prevent duplication failures.
If the default column separator (|) is not suitable because it appears in some attribute values, there
are two options:
• If there is another character that is guaranteed not to be in any attribute value, specify the
column_sep configuration variable in the configuration file for the utility. For example, if the hash
(#) character can be used, set the variable as column_sep|#.
Note
o The separator character may be multiple characters. For example, you can specify
the variable value as column_sep|##.
o The pipe character must be used in the first (header) line, regardless of the value
specified in the column_sep variable.
• If there is not a single character available that is guaranteed to be unused, use the default
pipe (|) character as the separator and use the XML numeric character references for any
special characters. For example, to embed a linefeed character in an attribute value, use code
. The csv2tcxml converter copies the attribute value without converting the &#xx; value.
The tcxml_import utility converts it to the proper character during the import process.
The csv2tcxml converter and tcxml_import utility require the following special characters be
replaced by their XML equivalents in attribute values in the input file:
You must also set the skip_special_chars configuration variable to 1 in the csv2tcmxl_config.txt
file.
If you are migrating Item class objects to a custom Item subclass, and the subclass defines an
attribute that points to another Item or ItemRevision object, you must prefix the attribute with the
dollar character ($) in the first line of the CSV file. This is also true if the attribute points to a Item
subclass or ItemRevision subclass.
For example, the VendorPart custom Item subclass contains the vendor_ref attribute. This attribute
points to the Vendor custom Item subclass. You must:
• Define the column in the first line of the input file as |$VendorPart:vm0vendor_ref|.
This causes the csv2tcxml converter to use the column value in the following lines of the file as
a PUID value.
• Add valid PUIDs (item_id) values of the required Vendor objects to the column.
csv2tcxml.perl utility
Converts a file formatted similar to a CSV file into a TC XML file that can be imported into a
Teamcenter site. You use this utility to migrate data from a legacy system into Teamcenter using the
bulk load function of the tcxml_import utility.
Note
The csv2tcxml_config.txt file contains default values for many of the arguments.
You can override any of the variable values in this file temporarily by adding them
into the command line arguments when you type the command. Use the format
argument-name=argument-value.
Syntax
Arguments
split
Indicates that the input file is processed as a set of subfiles. The converter processes the number
of lines indicated by the split-file-integer argument as a subfile. The next set of lines are then
processed until it has processed all lines in the indicated file. This allows more efficient use of
memory for very large files and can prevent memory limit errors.
file-name
Defines the name of the TC XML output file that you use to import the legacy data into the target
Teamcenter site. This argument is required unless you are generating reports.
reports
Generates the HTML report from the log files in the indicated directory. This report shows
summary information, breakup of the objects created, performance of the conversion with time
taken for each step, and the number of errors and warnings the converter generated. It also
includes a link to the log file.
input-directory
Indicates the directory containing the log files used to generate the HTML report.
split-file-integer
Indicates the number of lines to process as a subfile when you specify the split argument. If you
do not specify a split value, the converter uses 100,000 as the default value.
Examples
• To read the input CSV file and generate a puid-based TC XML file for items:
perl csv2tcxml.perl items.csv
• To read the input CSV file and generate a puid-based TC XML file for datasets that does not
contain item or revision information in the file:
perl csv2tcxml.perl dataset.csv item=exist
• To read the input CSV file and generate a puid-based TC XML file for datasets that does not
contain BOM or GRM information in the file:
perl csv2tcxml.perl bom.csv item=exist
In the .csv file, add the following column name and provide a value in each row to create the
custom form.
!Item:item_id|ItemRevision:item_revision_id|CustomFormName
100223|A|cost-frm-1
100778|A|cost-frm-2
• To process multiple imports for an assembly, include the occurrence ID (occ_id) property. A
unique occ-id column must be provided if the BOM data is updated multiple times as shown
in the following example:
!parent_item|parent_rev|child_item|child_rev|occ_id
car|A|wheel|A|front-left
car|A|wheel|A|front-right
car|A|wheel|A|rear-left
car|A|wheel|A|rear-right
The converter generates an HTML report for each CSV file conversion. The report contains summary
information showing the output TC XML file size and total number of elements processed. It also
displays a pie chart with breakup of the objects created in the output TC XML file, a performance chart
with the time taken for each step of the conversion, and a column chart with the number of errors and
warnings generated during conversion and a link to the log file.
The converter defines one ImanFile object for each Dataset object. To define additional Form objects
to associate with a particular dataset subclass, define an extra configuration variable as follows:
Dataset-class_FORMS|form-storageclass1:form1;storageclass2:form2;…
For example, the UGPART dataset subclass has two Form objects associated with it. Define the
extra configuration variable as:
UGPART_FORMS|UGPartAttr:UGPART-ATTR;UGPartAttributesForm:UGPARTATTRIBUTES
You can also define multiple ImanFile objects associated with the same Dataset object. To do this,
list the file names as comma-separated values in the ImanFile:file_name column. The converter
creates one ImanFIle object for each file name specified.
You can associate ReleaseStatus values with migrated Item and ItemRevision objects by adding a
release_status_list column to the first line (header) of the CSV file. Populate the following lines
in the column with one or more values that correspond to existing ReleaseStatus objects at the
importing Teamcenter site. You can optionally specify a timestamp (date and time) value for the
ReleaseStatus object. To do this, define a ReleaseStatus:date:released column and populate it
with one or more timestamp values. The value is used with the corresponding release_status_list
value. The converter processes multiple values in the release_status_list and date_released
columns as follows:
• If there is one value in the release_status_list column and one value in the date_released
column, the date_released value is used for the ReleaseStatus.date_released attribute value.
• If there are one or more values in the release_status_list column and no value in the
date_released column, or no date_released column defined in the CSV file, the ReleaseStatus
objects are created without a date_released attribute. This is valid because a date_released
attribute is not required for ReleaseStatus objects.
• If there are two values in the release_status_list column and one value in the date_released
column, the date_released value is used for both ReleaseStatus objects.
• If there are two values in the release_status_list column and two values in the date_released
column, the first date is used for the first ReleaseStatus object and the second date is used for
the second ReleaseStatus object.
Names for column headers are defined in the csv2tcxml_column_names.txt file. To use classes and
attributes other than the standard Item, ItemRevision, BOM, and relation (GRM) classes, you must:
• Identify how elements of the new class are related to other objects.
For example, the Effectivity class stores information about part effectivities, either by part revision
or by structure. For revision effectivity, the Effectivity object is related to a ReleaseStatus object.
For structure effectivity it is related to a PSOccurrence object. These relationships are defined
in the csv2tcxml_mapping.txt file as follows:
reveff_units|Effectivity:effectivity_units<-ReleaseStatus:effectivities
reveff_dates|Effectivity:effectivity_dates<-ReleaseStatus:effectivities
assmeff_units|Effectivity:effectivity_units<-PSOccurrence:effectivities
assmeff_dates|Effectivity:effectivity_dates<-PSOccurrence:effectivities
The first column, from the start of the line up to the pipe (|) character, specifies the column name
to use in the CSV file. The next column, from the | to <- specifies the attribute name that holds
the value specified in the CSV file for that column. The final column specifies how the Effectivity
object is related to other objects. For revision effectivities, the ReleaseStatus effectivities attribute
points to the Effectivity object. For structure effectivities, the PSOccurrence effectivities object
points to the Effectivity object.
The following sample CSV file listing defines an Effectivity object when used with the previous
mapping shown for the csv2tcxml_mapping.txt file:
!parent_item|parent_rev|child_item|child_rev|assmeff_units|Effectivity:effectivity_protection
061714-0005|A|061714-0006|A|1 10 20 30|false
Because the CSV file specifies the parent_item, parent_rev, child_item, and child_rev attributes,
the converter creates the PSBOMView, PSBOMViewRevision, and PSOccurrence BOM objects.
The csv2tcxml_mapping.txt file specifies the assmeff_units column as the Effectivity object,
therefore the converter creates an Effectivity object. Because the mapping file also specifies how the
Effectivity object is related, the PSOccurrence.effectivities attribute points to the Effectivity object.
Note
The last column, Effectivity:effectivity_protection, is required in the CSV
file for Effectivity objects. To see all required attributes for a class, see the
csv2tcxml_required_attrs.txt file.
For effectivities, the effectivities attribute of the ReleaseStatus or PSOccurrence object points
directly to the Effectivity object. However, if a relation (GRM) class points to the new object, you
must use the following format:
column-name|object-to-create:attribute-name <- GRM-name <-related-object
For example, to specify that CompanyObject objects are related to an Item object by the
ContactInCompany relation, add the following to the csv2tcxml_mapping.txt file and add the
comp_contact column to the CSV file:
comp_contact|CompanyContact:first_name<-ContactInCompany<-Item
Island of data
An Island of data concept is used to bulk load data into Teamcenter. Loading data in islands maintains
the integrity of data relationships and allows recover from import failures during the bulk load. The
following definitions help you understand this concept:
Island The fundamental unit of data. It consists of a principal object and the additional
objects on it depends for its correct functional definition and usage within
Teamcenter.
Principal object The initial object used to start the traversal to determine an island of data.
Dependent object An object that must be included in the set of objects implied by the principal
object and the closure rules to correctly form the island of data. Dependent
objects may not exist in a particular island.
The following diagram shows how an island can be defined:
Island of data
TC XML format
The TC XML format is defined by the TC XML schema. The TC XML schema is autogenerated at
installation and upgrade, and the resulting TCXML.xsd file is placed in the TC_DATA directory on the
Teamcenter server. You can also use the Business Modeler IDE to export a TC XML schema file
of your current Teamcenter schema.
In a TC XML file, the root element is TCXML and the namespace (xmlns) attribute is
http://www.tcxml.org/Schemas/TCXMLSchema, as shown in the following figure.
Note
The URIs that appear in the headers of PLM XML and TC XML files serve as namespace
names, are unique identifiers for an XML vocabulary. Although they are URIs, they are not
used to identify and retrieve web addresses.
A TC XML file has a flat structure (no hierarchy). Elements in the TC XML file have:
• The leaf‐class name as its element name.
Note
The elemId attribute value must have id followed by a number, for example, elemId
= ”id90”.
Object references in a TCXML file are formed by prefixing the hash character (#) to the elemId value.
TC XML data is grouped into islands; an island ties logically related objects together. The data
migration solution can form simple islands, like [Item, ItemRev, MasterForm] or [Dataset,
RevAnchor, ImanFile], and the fast import processes the islands one‐at‐a‐time. The following figure
shows an example of how to structure TC XML data islands for best results:
XML elements for organizational (User, Group, Site, and so forth) and administrative (Types, Rules)
objects are assigned an island_id attribute value of 0 and contain the candidate key attribute.
The organizational and administrative objects are not replicated; they are looked up at the target site
based on their candidate key.
The XML elements for objects that can be replicate have a list of attributes defined in the schema
with the parent_uid attribute that indicates the principal object. The list of attributes includes the
ones defined directly on the leaf class plus those that are defined on each parent class up to and
including the POM_object class. In an island, the principal object has an empty parent_uid
attribute and all the dependent objects have the parent_uid value set to the puid of the principal
object (parent_uid=puid).
The objects of one island must appear together in the TC XML file. If they are scattered or otherwise
in error, the import of that island fails. (Other islands will be imported.) After the import of an island
fails, correct the issues and reimport the failed island.
pairs, and session option name-value pairs. The originatingSite attribute contains the site-id value
representing the legacy system and must be unique (cannot be the same as the Teamcenter site).
This site must be defined in the Organization application of the importing Teamcenter site.
Note
Prior to Teamcenter version 10.1.5, an authorization key was required to use the
bulk load capabilities of the tcxml_import utility. This key value was set in the
SITCONS_AUTH_KEY environment variable. This key is no longer required for the bulk
load capabilities.
Additionally, the -bypass_inferdelete argument is no longer required for bulk loading data.
Fast import of objects using the tcxml_import utility uses data files that conform to the low-level (LL)
TC XML format. The bulk load process also uses the LL TC XML format. The use of stub objects and
inferred delete are handled differently in this format.
For LL TC XML imports, an entire island of data must be full elements regardless of whether an
object is locally owned or a replica. Stub objects are used to solve island interdependencies and
are represented by POM_stub objects in the Teamcenter database. They are not used to represent
objects that have already been sent to the target site as it does in HL TC XML imports. Consequently,
if you transfer a new revision to Teamcenter using LL TC XML, all predecessor revisions must be
transferred as full objects. These may have further related objects and so on. If they are not full
objects, an inferred delete of the stub objects occurs.
int TIE_get_hashed_uid
(
int ownSiteId, (I) Site Id of Legacy system
const char* hashKey, (I) Hash Key
char** hashedUID (OF) Valid Teamcenter UID for given hash key
);
2. Use the tcxml_validate utility to validate the TC XML file generated by the custom mapping
solution. The validator log reports potential errors within TC XML file. Fix the root cause of any
errors within the custom mapping logic. This validation focuses on data samples (~2500 element
XML files) extracted from legacy systems to be executed in a test lab environment.
3. Use the tcxml_import utility to import the TC XML files generated by the custom mapping
solution. After all aspects of the translation/mapping are correct, the full TC XML file can imported
at the highest speed possible, without any additional validation.
Caution
The importing user must have write access to the location where the utility logs the
information about the import. You can ensure that this requirement is met by including
the -log argument with a path to a location that is write accessible to the importing
user. You may optionally include a file name for the log file in the path.
When attribute values contain commas in the strings at either of the sites, you must
change the default value for the GMS_tcxml_string_separator preference at both
sites to prevent data corruption at the importing site.
Tip
The view type data is not exported with the PSBOMView data in TC XML. The import
process uses the default view type when importing PSBOMView data.
Therefore, when transferring PSBOMView data using a briefcase file, tcxml_export and
tcxml_import, or any utility that uses TC XML metadata, set the PSE_default_view_type
preference at the target site to the view type value of the assembly at the source site.
Usually, this is the same as the source sites default view type.
This import behavior is designed to be consistent with Structure Manager.
For reference information useful for bulk loader customizations, see the following topics:
• Teamcenter core data dictionary
Caution
You must set the GMS_USE_FNV_HASH preference to true to enable the use of the FNV
hashing API to create Teamcenter UIDs for the legacy objects.
Note
If you use the bulk load function to load objects that will be referenced by Data Exchange,
the GSIdenity element must match the element used by the Data Exchange process.
The XML elements for organizational (User, Group, Site, and so forth) and administrative (Types,
Rules) objects:
• Are assigned 0 for the island_id attribute
In a GSID-based TC XML file, the organizational objects are referred by the child GSIdentity
element’s elemId attribute of the corresponding organization object. For example, the owning_group
attribute of the Item element in the following figure, points to the child GSIdentity element’s elemId
attribute of the Group object.
• definitive
Points to the source site POM_imc element in the TC XML file.
• object_class
Indicates the class of the object represented by the stub.
• object_uid
Points to the GSIdentity element of the object represented by the stub. If the actual object is
not present in the TC XML file, the object_uid refers to its own GSIdentity element uniquely
identifies the object as being represented by the stub. In this case, the attributes of the
GSIdentity element of the POM_stub element are used to compose the object_uid attribute.
The owning_site
Note
If the import process sees that the actual object exists in the Teamcenter database for the
stub, it skips creation of the stub.
Bulk load process creates an item with an item_id value of 000032 in Teamcenter site
-2132200621 as a local object.
Bulk load process skips the item with an item_id value of 000032 because it already exists
at Teamcenter site -2132200621 and the lsd attribute value is the same in the TC XML file
and the database.
Bulk load process updates the item with an item_id value of 000032 because it already
exists at Teamcenter site -2132200621 and the lsd attribute value in the TC XML file
is later than the value in the database.
Note
When using the bulk load utility (txcml_import), the utility sets appropriate values for
attributes that are not mandatory. This type of activity must be done for other classes of
interest as part of the customization work.
Item attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
configuration_object_tag No
creation_date No
date_released No
ead_paragraph No
elemId Yes
global_alt_list No
gov_classification No
has_variant_module No
ip_classification No
is_configuration_item No
is_vi No
island_id Yes
item_id Yes
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
license_list No
lsd No
object_application Yes Typically set to Teamcenter.
object_desc No
object_name Yes
object_properties No
Item attributes
Attribute Mandatory Comments
object_type Yes
Points to the Group element
owning_group Yes
in the TC XML file.
owning_organization No
owning_project No
Points to the POM_imc
owning_site Yes
element in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
parent_uid Yes
Class-id. Fast import
pid No
ignores this attribute.
preferred_global_alt No
process_stage_list No
project_list No
puid Yes
release_status_list No
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
timestamp No
uom_tag No
wso_thread No
Anchor elements
Attribute Mandatory Comments
acl_bits No
archive_date No
archive_info No
backup_date No
creation_date No
elemId Yes
immune_objects No
island_id Yes
Anchor elements
Attribute Mandatory Comments
keep_limit Yes Typically set to 3.
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
lsd No
managed_objects No
object_properties No
Points to the Group element
owning_group Yes
in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
parent_uid Yes
puid Yes
ItemRevision attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
creation_date No
date_released No
declared_options No
ead_paragraph No
elemId Yes
gde_bvr_list No
gov_classification No
has_variant_module No
ip_classification No
island_id Yes
item_revision_id Yes
Holds the PUID value of the
items_tag Yes
corresponding Item.
ItemRevision attributes
Attribute Mandatory Comments
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
license_list No
lsd No
object_application No
object_desc No
object_name Yes
object_properties No
object_type Yes
Points to the Group element
owning_group Yes
in the TC XML file.
owning_organization No
owning_project No
Points to the POM_imc
owning_site Yes
element in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
parent_uid Yes
The class-id. Fast import
pid Yes
ignores the attribute.
process_stage_list No
project_list No
puid Yes
release_status_list No
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
Holds the PUID value of
sequence_anchor Yes the corresponding Anchor
element.
sequence_id Yes Typically set to 1.
sequence_limit Yes Typically set to 3.
timestamp No
used_options No
variant_expression_block No
wso_thread No
Form attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
creation_date No
data_file No
date_released No
ead_paragraph No
elemId Yes
form_file Yes Typically set to n/a.
gov_classification No
ip_classification No
island_id Yes
last_mod_date No
Points to the User element
last_mod_user
in the TC XML file.
license_list No
lsd No
object_application Yes Typically set to Teamcenter.
object_desc No
object_name Yes
object_properties No
object_type Yes
Points to the Group element
owning_group Yes
in the TC XML file.
owning_organization No
owning_project No
Points to the User element
owning_user Yes
in the TC XML file.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
parent_uid Yes
The class-id. Fast import
pid Yes
ignores the attribute.
process_stage_list No
Form attributes
Attribute Mandatory Comments
project_list No
puid Yes
release_status_list No
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
timestamp No
wso_thread No
ImanRelation attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
lsd No
object_properties No
Points to the POM_imc
owning_site Yes
element in the TC XML file.
parent_uid Yes
The class-id attribute. Fast
pid Yes
Import ignores the attribute.
Holds the PUID value of
primary_object Yes the primary object of the
ImanRelation object.
puid Yes
Points to the corresponding
relation_type Yes ImanType element in the
TC XML file.
timestamp No
user_data No
PSBOMView attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
creation_date No
date_released No
ead_paragraph No
elemId Yes
gov_classification No
ip_classification No
island_id Yes
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
license_list No
lsd No
object_application Yes Typically set to Teamcenter.
object_desc No
object_name Yes
object_properties No
Points to the POM_imc
owning_site Yes
element in the TC XML file.
object_type Yes
Points to the Group element
owning_group Yes
in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
parent_item Yes
parent_uid Yes
The class-id attribute. Fast
pid No
Import ignores the attribute.
process_stage_list No
project_list No
puid Yes
release_status_list No
PSBOMView attributes
Attribute Mandatory Comments
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
timestamp No
wso_thread No
PSBOMViewRevision attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
Points the PUID value
bom_view Yes of the corresponding
PSBOMView element.
creation_date No
date_released No
ead_paragraph No
elemId Yes
gov_classification No
island_id Yes
is_precise Yes Typically set to 0.
ip_classification No
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
license_list No
lsd No
object_application Yes Typically set to Teamcenter.
object_desc No
object_name Yes
PSBOMViewRevision attributes
Attribute Mandatory Comments
object_properties No
object_type Yes
Points to the Group element
owning_group Yes
in the TC XML file.
owning_organization No
owning_project No
Required for LL TC XML.
owning_site Yes Points to the POM_imc
element in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
parent_uid Yes
pid Yes
process_stage_list No
project_list No
puid Yes
release_status_list No
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
struct_last_mod_date Yes
timestamp No
wso_thread No
PSOccurrence attributes
Attribute Mandatory Comments
alternate_etc_ref No
Points the PUID value of the
child_item Yes
corresponding item.
child_bv No
effectivities No
elemId Yes
island_id Yes
lsd No
notes_ref No
object_properties No
PSOccurrence attributes
Attribute Mandatory Comments
Points the PUID value
of the corresponding
occ_thread Yes
PSOccurrenceThread
element in the TC XML file.
occ_flags No
occ_type No
occurrence_type No
order_no No Typically set to 10.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
Points the PUID value
of the corresponding
parent_bvr Yes
PSBOMViewRevision
element in the TC XML file.
Required for low-level TC
parent_uid Yes
XML schema.
pid No
pred_list No
puid Yes
qty_value No Typically set to -1.
seq_no Yes Typically set to 10.
timestamp No
uom_tag No
used_options No
variant_condition No
xform No
PSOccurenceThread attributes
Attribute Mandatory Comments
clone_stable_occ_uid No
elemId Yes
island_id Yes
lsd No
object_properties No
Points to the POM_imc
owning_site Yes
element in the TC XML file.
PSOccurenceThread attributes
Attribute Mandatory Comments
parent_uid Yes
The class-id attribute. Fast
pid Yes
import ignores this attribute.
puid Yes
timestamp No
Dataset attributes
Attribute Mandatory Comments
acl_bits No
active_seq No
archive_date No
archive_info No
backup_date No
creation_date No
Points to the DatasetType
dataset_type Yes
element in the TC XML file.
date_released No
ead_paragraph No
elemId Yes
format_used No
gov_classification No
ip_classification No
island_id Yes
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
license_list No
local_path No
lsd No
markup_acl No
markup_create_tool No
markup_official No
markup_status No
Dataset attributes
Attribute Mandatory Comments
object_desc No
object_name Yes
object_properties No
object_type Yes
owning_organization No
owning_project No
Points to the Group element
owning_group Yes
in the TC XML file.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
parent_uid Yes
pid No
process_stage_list No
project_list No
puid Yes
ref_names No
Holds the PUID value of
ref_list Yes the corresponding ImanFile
element in the TC XML file.
ref_types No
release_status_list No
Holds the PUID value
of the corresponding
rev_chain_anchor Yes
RevisionAnchor element
in the TC XML file.
revision_limit Yes Typically set to 1.
revision_number Yes Typically set to 0.
system_managed No
Points to the Tool element
tool_used Yes
in the TC XML file.
timestamp No
user_class No
Dataset attributes
Attribute Mandatory Comments
wso_thread No
RevisionAnchor attributes
Attribute Mandatory Comments
acl_bits No
archive_date No
archive_info No
backup_date No
creation_date No
elemId Yes
highest_rev Yes Typically set to 1.
id No
island_id Yes
keep_limit Yes Typically set to 3.
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
lsd No
object_properties No
Points to the Group element
owning_group Yes
in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
parent_uid Yes
pid Yes
puid Yes
rev No
Holds the values of the
revisions Yes corresponding Dataset
revisions.
timestamp No
ImanFile attributes
Attribute Mandatory Comments
acl_bits No
archive_date No
archive_info No
backup_date No
creation_date No
destination_volume_tag No
elemId Yes
file_name Yes
hsm_info No
island_id Yes
last_mod_date No
Points to the User element
last_mod_user Yes
in the TC XML file.
lsd No
machine_type No
object_properties No
original_file_name No
Points to the Group element
owning_group Yes
in the TC XML file.
Points to the User element
owning_user Yes
in the TC XML file.
Points to the POM_imc
owning_site Yes
element in the TC XML file.
parent_uid Yes
The class-id attribute. Fast
pid Yes
import ignores this attribute.
puid Yes
relative_directory_path No
released_version No
Contains the relative path
sd_path_name Yes of the legacy file from the
logical volume root.
status_flag No
store_and_forward_flag No
text_flag No
time_last_modified No
ImanFile attributes
Attribute Mandatory Comments
timestamp No
translate No
Points to the ImanVolume
volume_tag Yes
element in the TC XML file.
vm_info No
User attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
user_id Yes Candidate key
Group attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
name Yes Candidate key
Tool attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
Candidate key
object_name Yes
ImanType attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
ImanType attributes
Attribute Mandatory Comments
type_name Yes Candidate key
ImanVolume attributes
Attribute Mandatory Comments
elemId Yes
island_id Yes
Candidate key
volume_name Yes
DataseType attributes
Attribute Mandatory Comments
elemId Yes
Candidate key
datasettype_name Yes
island_id Yes
Top_item/A;1(view)
Child_1/A;1
Child_2/A;1
The expanded view of the Top_item object and its children includes the dataset object attached
to the Child_1 object:
Pre-import validation
Required schema
The tcxml_validate utility uses the LLTCMXML.xsd schema to validate the input files. This file must
be in the TC_DATA directory. To generate this file and enable schema validation:
Note
The URIs that appear in the headers of PLM XML and TC XML files serve as namespace
names, are unique identifiers for an XML vocabulary. Although they are URIs, they are not
used to identify and retrieve web addresses.
1. Use the bmide_generatetcplmxmlschema utility to generate the file for your Teamcenter site,
for example:
bmide_generatetcplmxmlschema -u=infodba -p=infodba -g=dba
-schema_type=llschema
The utility may take a few minutes to finish and displays some information in the command
shell, for example:
C:\apps\tc\tc900\TR\bin>bmide_generatetcplmxmlschema -u=infodba -p=infodba -g=dba
-schema_type=llschema
Extracting....
Extraction Completed.
Extracting Localizations....
Localization Extraction Completed.
Please refer [C:\Temp\2\business_model_extractor_2011_05_11_13-25-45.log] for
log information
Siemens and the Siemens logo are registered trademarks of Siemens AG. UGS,
Teamcenter and UGS Teamcenter are trademarks or registered trademarks
of UGS Corp. or its subsidiaries in the U.S. and other countries. This
software and related documentation are proprietary to UGS Corp.
Copyright ⌐ 2007 UGS Corp. All rights reserved.
Note
You cannot use the tcxml_validate utility on very large TC XML files. It is limited to files
containing approximately 2500 elements.
Tip
The tcxml_validate utility is intended as a tool used to perfect your custom mapping
solution. It is not intended to be used on all TC XML files before they are imported.
For a complete description of the tcxml_validate utility, including syntax and examples, see the
Utilities Reference.
Caution
On Windows systems, when schema validation is used and the TC XML elements have
some mandatory attributes missing, an exact error message is not included in the log
file. However, the log file contains the line number and column number of the missing
attributes in the file, for example:
TIEFastImportSAXHandler Error: [] encountered in xml at line
[17] and column [898]. May have encountered some invalid
characters or missing some required attributes - but anyway
attempting to continue processing...
To determine the missing mandatory attributes, check the element listed in the indicated
line and see the appropriate object table in Teamcenter core data dictionary.
Note
The -h (help) argument output and the syntax defined for this utility in the Utilities
Reference contain arguments not listed here. Those arguments are for regular imports
of TC XML data, not bulk loading of legacy data, and are ignored when the –bulk_load
argument is used.
Syntax
tcxml_import [-u=user-id {-p=password | -pf=password-file} -g=group]
-file=xml-file-name -site=site-name
-bulk_load
[-h]
Arguments
-u
Specifies the user ID.
This is generally infodba or another user with administration privileges. If this argument is used
without a value, the operating system user name is used.
Note
If Security Services single sign-on (SSO) is enabled for your server, the -u and -p
arguments are authenticated externally through SSO rather than being authenticated
against the Teamcenter database. If you do not supply these arguments, the utility
attempts to join an existing SSO session. If no session is found, you are prompted to
enter a user ID and password.
-p
Specifies the password.
If used without a value, the system assumes a null value. This argument is mutually exclusive
with the -pf argument.
If this argument is not used, the system assumes the user-id value to be the password.
-pf
Specifies the password file. This file can be created manually, or using Teamcenter Environment
Manager.
• If created manually, the file must be a single-line ASCII file containing the password in clear
text.
• If created through Teamcenter Environment Manager, the wizard prompts you for a password
and creates the password file during installation.
If used without a value, the system assumes a null value. If this argument is not used, the system
assumes the user-id value to be the password.
This argument is mutually exclusive with the -p argument.
-g
Specifies the group associated with the user.
If used without a value, the user's default group is assumed.
-file
Specifies the input TC XML file containing the objects to be imported into Teamcenter.
-site
Specifies the master exporting site from input TC XML data is generated.
-bulk_load
Performs a fast import using POM level APIs of a file containing legacy data objects. The file must
conform to the TC XML low-level data format. You must specify the -file and -site arguments. If
you specify any other optional arguments they are ignored. See restrictions.
-h
Displays help for this utility.
Restrictions
1. Using POM level APIs ensures the overall integrity of the data (referential integrity, type safety,
and so forth). However, the tcxml_import utility does not verify adherence to business rules.
You must identify these types of errors and fix them during the pre-import process.
2. When importing a PSOccurrence object, the import file must contain the following attributes:
• xform
• notes_ref
• child_bv
• variant_condition
• alternate_etc_ref
3. When importing a workspace object, the following properties must be present in the import file:
• uom_tag
• configuration_object_tag
Examples
• To import legacy objects from the Item32.xml file into the Teamcenter site where you run the utility:
tcxml_import —u=infodba –p=infodba –file=D:\Temp\Item32.xml
–bulk_load –site=-2140766078
The following files are created at the same location as the input XML file:
o Item32_importer.log
Contains the import process details.
o Item32_pretraverse.log
Contains the results of pre-traversal performed at the importing site.
o Item32_import_results.txt
Contains the import status (success or failure of island).
o Item32_repeat.xml
Note
This file is created only when failures occur during the import process.
Contains data for the failed islands, along with all organizational elements and headers.
Additionally it has a comment tag to display the failure message.
• To upload dataset files from a local directory into the importing site when the Item32.xml file
contains ImanFile elements:
tcxml_import —u=infodba –p=infodba –file=D:\Temp\Item32.xml –bulk_load
Why is there a different referencing scheme used within the TC XML format?
For example, for the owning_user the element id is used, for the referencing items_tag, the uid of
the parent id is used. Also the parent_uid attribute is mentioned twice as items_tag and parent_uid.
To be able to separate the users/objects/relations in the loads it would be best to reference everything
by the Teamcenter UID.
<ItemRevision acl_bits="0" active_seq="1" archive_date="" archive_info="" backup_date=""
creation_date="2010-06-29T15:43:21Z" date_released="" declared_options="" ead_paragraph=""
elemId="id17" gde_bvr_list="" gov_classification="" has_variant_module=""
ip_classification="" island_id="4" item_revision_id="A" items_tag="AVDxiag7I45M1A"
last_mod_date="2010-06-29T15:46:31Z" last_mod_user="#id5" license_list=""
lsd="2010-06-29T15:46:31Z" object_application="Teamcenter" object_desc="" object_name="child1"
object_properties="0" object_type="ItemRevision" owning_group="#id1" owning_organization=""
owning_project="" owning_user="#id5" parent_uid="AVDxiag7I45M1A" pid="758"
process_stage_list="" project_list="" puid="AVMxiag7I45M1A" release_status_list=""
revision_limit="1" revision_number="0" sequence_anchor="AVOxiag7I45M1A" sequence_id="1"
sequence_limit="3" structure_revisions="QFJxiag7I45M1A" timestamp="QNMxiag7I45M1A"
used_options="" variant_expression_block="" wso_thread=""/>
Answer — Organization and administrative objects, such as User and Group, cannot be referenced
by a UID. They have to be looked up based on their candidate key. So there is an XML element for
the organization object with just the candidate key and element ID and all the references use the
elemId attribute to point to it.
Answer — The import process collects all the objects that have the same island-id attribute and
saves them at once.
Answer — The import process relies on originating site information and the session options in
the Header element. This information is read in the first pass of the XML parsing and used in the
second pass when the actual import happens.
How can we find out attributes in the TC XML are mandatory and if empty attributes can
be left out?
Answer — The fast import sets null values for missing attributes that do not have an initial value.
However, there is no straightforward way to arrive at a set of attributes that are required to be
populated for a given class. The tcxml_validate utility reports if the required typed and untyped
references are missing from the TC XML. In addition, the list of mandatory attributes for core
Teamcenter classes documented in Teamcenter core data dictionary. For other classes of interest,
similar exercise must be done as part of the customization work.
Answer — The timestamp indicates when the object was last modified. The timestamp attribute
takes the form of a UID – not a date or time as might be expected. Because a UID encodes a
representation of time, it is sufficient to store a UID for this purpose. This attribute can be omitted
from the TC XML. Fast import internally generates and sets the timestamp for an object.
For generating the UID with TIE_get_hashed_uid an external ID coming from the legacy system
is needed, as well as a siteID identifying the legacy system. Are there any requirements to the
format of that external ID (field type, characters, field length, and so forth)?
Is the hashed UID the same external ID that is also used for the enhancement of creating the
UID internally inside the bulk loader process? Or what is the format of the GSID needed?
Answer — The GSID contains label, sublabel, and split_token attributes to allow for many-to-many
mappings. If the external ID is composed such that it is unique across the legacy data model it can be
used to populate the label attribute.
Must the elemId and island_id attributes be unique in a file or do they have to be unique
over all data loaded?
Answer — The elemId and island_id attributes are unique per file.
Answer — Process execution problems may occur due to available memory or maximum time-to-live
(ttl) expiration when running in the Apache ODE in memory. This issue is usually encountered when
you are running the ODE on a JBoss 5.1 application server and the ODE uses an Oracle database.
To run an ODE process in memory, uncomment or add the <in-memory>true</in-memory> element
to the ode-working-dir/processes/data-transfer/deploy.xml file. For more information about ODE
processes, see the following URL:
http://ode.apache.org/creating-a-process.html
If your processes may exist for longer than 10 minutes, configure the in-memmory ttl to longer than
10 minutes using the ode-axis2.mex.inmem.ttl property. This properties value is set in milliseconds
in the ode-working-dir/conf/ode-axis2.properties file. For example, the following set the ttl to 30
minutes:
ode-axis2.mex.inmem.ttl=1800000
• Practicing upgrade of a production environment using actual production data prior to rolling out
the upgrade to the production sites.
The following graphics show the allowed and prohibited site imports using low-level bulk load.
created using the default (production environment) and it is subsequently determined that it must
be a test environment.
2. Install a Teamcenter environment that matches the solutions and features in your current
Teamcenter environment.
Follow the steps for installing a Teamcenter corporate server in the appropriate server installation
guide.
3. In the Foundation panel, accept the default Create and populate database option.
Follow the instruction for the Foundation Database and Volume Information in the appropriate
server installation guide.
• -class
• -folder
• -item
• -item_key
• -inputfile
• -inputuidfile
• -uid
Tip
If there are no changes to the Organization objects associated with the data you
are extracting, you can prevent unnecessary export of the Organization objects by
clearing the Export All Properties of Organization Object option.
The Bulk Extract data to Briefcase option is selected by default and is read-only. Only the
Teamcenter site administrator can edit the read-only check boxes.
Teamcenter exports briefcase files in a compressed format to decrease the file size.
Compressing the file can be time consuming. If you want to decrease the time it takes to
create the briefcase file and are not concerned with the size of the file you are extracting,
select the Export Uncompressed Briefcase check box. This option can be set as the default
option in the option set you use to bulk extract data by setting the (opt_uncompressed_bcz
option value to TRUE.
Teamcenter creates a briefcase (.bcz) file in the directory location and displays the Export
Completed dialog box indicating if the export is successful.
If you clear both options, all replica objects are imported as replicas in the test environment. You
must be careful when you import objects from different production environments that participate in a
Multi-Site environment. This may cause site ownership conflicts.
• The -optionset= argument value set to a transfer option set that has the opt_bulk_load_bcz
options set to TRUE
c. If you want to change the editable BulkLoadDefault import options, click the Display/Set
import options button .
Teamcenter displays the BulkLoadDefault dialog box.
The Bulk Load from Briefcase option is selected by default and is read-only. Only the
Teamcenter site administrator can edit the read-only check boxes.
Teamcenter displays the Remote Export Options Settings dialog box. If the settings are
correct, click Yes to continue.
Teamcenter imports the product data from the briefcase file into your test environment.
The DataMapper.xml file defines mappings for the mapper framework. The <maximum-concurrency
> element controls the number of simultaneous mappings that may run in an application. The mapper
service provides convenient access to mapping functionality. The service uses this DataMapper.xml
file to determine the type of mapping requested. Mapping is keyed on action type and source and
destination systems, for example:
<action name="dataTransfer">
<map source="1" target="1">
The mapping service provides support for no-op mappings and chained mappings. A no-op mapping
is declared as an empty <map> element, that is, without any <mapper> child elements. Chained
mappings are defined by creating a <map> element with multiple <mapper> child elements. Each
child element represents a mapper service. Between these sibling mapper elements, the output of
a previous service is the input of the next service in the chain.
Control file mapping is a service that wraps the mapping functionality provided by the mapper engine.
The input for this mapping is a File Management System (FMS) ticket from the input system. The
control file for the mapping is stored in the Global Services datastore. The output of the mapping is
streamed into the target system. FMS ticket(s) of the output and log information are returned. This
action is the dataTransfer action for standard mappings, for example:
<mapper service="CtrlFileMapService">
/bin/ctrl.file (points to datastore location)
</mapper>
XSLT mapping provides a configured way to map XSLT. The mapper config file provides the XSLT for
the mapping, for example:
<mapper service="XSLTMapService">
/bin/map.xslt (points to datastore location)
</mapper>
Java mapping provides a convenient way to hook in custom mapping. Any implementing class
must implement to the ImapService interface. The DataMapper.xml file defines the implementing
class to be called for Java mapping, for example:
<mapper service="JavaMapService">
com.teamcenter._globalservices.service.QueryAuditService
(defines the class to invoke)
</mapper>
Tip
Wild card quick configuration guidelines:
The DataMapper.xml configuration file accepts wild card (*) entries for MAP node's
SOURCE and TARGET attributes. Entries with wild cards are used as a fall back in cases
when an entry bearing specific site source and target site IDs does not exist. It is important
to note that multiple map entries with the same combination of SOURCE and TARGET
attribute values must not conflict with each other. Specifically, the following example pair of
entries is NOT allowed, and results in an error:
<map source="X" target="*"> ... </map>
<map source="*" target="Y"> ... </map>
These components interact with the integration framework to transfer objects between sites.
Supported objects
The importer and exporter use the TC XML schema to import and export objects. The following
objects are supported by the TC XML framework:
Teamcenter base objects:
• Alias
• Dataset
• Form
• Folder
• IdContext
• Identifier
• ImanFile
• ImanRelation
• Item
• ItemRevision
• ReleaseStatus
• POMObject
• Table
• TableCellBCD
• TableCellDate
• TableCellDouble
• TableCellHex
• TableCellInt
• TableCellLogical
• TableCellSED
• TableCellString
• TableDefinition
• TableLabel
• ValidationData
• ValidationResult
• BidPackage
• BidPackageContent
• BidPackageLineItem
• BidPackageRevision
• Vendor
• VendorIdentifier
• VendorRevision
• VendorRole
• VMRepresents
• ParmDefDateRevision
• ParmDefDbl
• ParmDefDblRevision
• ParmDefHex
• ParmDefHexRevision
• ParmDefInt
• ParmDefIntRevision
• ParmDefSED
• ParmDefSEDRevision
• ParmDefStr
• ParmDefStrRevision
• ParmGrpDef
• ParmGrpDefRevision
• ParmGrpVal
• ParmGrpValRevision
• ParmValBCD
• ParmValBitDef
• ParmValBool
• ParmValDate
• ParmValDbl
• ParmValHex
• ParmValInt
• ParmValSED
• ParmValStr
• ProductVariant
• ProductVariantIntent
The following objects are not supported, but the references to these objects from supported
Teamcenter objects are exported through properties. These objects must be defined at the importing
site using the Business Modeler IDE.
Teamcenter base objects:
• Project
• Tool
• UnitOfMeasure
• POM_imc
• Role
• User
The importer supports transfer of the following CATIA objects from Teamcenter Enterprise:
• Basic document-centric classes
• V5 CGR files
• Design Tables
The importer supports transfer of the following Pro/ENGINEER objects from Teamcenter Enterprise:
• Basic document-centric classes
• Family tables
• CGM files
• Suppressed parts
The exporter supports transfer of CAD neutral files and metadata to Teamcenter Enterprise.
Parts (assemblies/components) that have documents without any attachments are imported into
Teamcenter as empty datasets without any named references.
The following CAD data is not supported for transfer by the importer or exporter:
• Absolute occurrences
• Effectivities
Scoper
When the exporter or importer receives a request to transfer data, it determines the transfer mode
from the option set object. It then creates the traversal object based on the transfer mode scope
(import, export) and the schema format. PLM XML or TC XML). The basic behavior of a traversal
object is to provide two methods, process and traverse. The process method processes the present
object in hand and calls the traverse method. The traverse method navigates to the next object and
then calls the process method. This operation iterates until no more objects are available to process.
The scoper evaluates the transfer mode closure rules and the options provided by the exporter and
returns only the objects that are identified for process in a closure rule clause. This list is sent to the
exporter or importer for serialization or deserializaton.
Data mapper
Product life cycle management systems track product object data and relationships. To move
data from one system to another, an object's attributes and its relationship to other objects must
be converted or mapped to the representation in the other system. For moving data from one
Teamcenter system to another, you only need to map customizations as the standard Teamcenter
object attribute and relationships are the same in both systems.
Teamcenter provides a standard mapping process for moving data between Teamcenter Enterprise
and Teamcenter systems. This standard mapping does not map all object attributes. Attributes that
are not used in the destination system are not mapped. Attributes that are used only to provide
system functionality that can be achieved through another method and are not displayed to the
user, are also not mapped. Due to customizations to support a unique business process, you may
need to map some of these standard attributes.
Reference elements can be mapped to multiple objects and will accept any number of mappings. A
reference element must map to a string that matches the string of characters prepended by plm: for
the object that it is mapped to.
For a GSIdentity object, the class attribute is information only and not the class name in the receiving
system.
Data synchronizer
The data synchronizer uses recipes defined by initial replication to determine if replicated data is
up-to-date or needs to be updated. You can use the synchronization functionality to see if data that is
replicated on your site is outdated and update it as desired. You can also push data that has changed
to sites where replicas exist. The synchronization function cannot be used to update the following:
• Meta model data such as types
Candidates for synchronization are determined by comparing the master's last modification date to
the replica's last export date. Through a customization, you can also identify candidates automatically
providing an event trigger that calls an API that flags replicated objects as out-of-date.
A recipe is a combination of import export options that is encoded as transfer formula strings. This
transfer formula is stored as part of the ImanExportRecord object as a string identifying the name of
the transfer formula and an integer field for the associated transfer formula variables presented in the
form of a map. The map contains a key string and a value string. This allows generalized behavior of
these options. The following options that can be used to form the transfer formula:
• All Item Revisions
• Revision Rule
• Release Status
• Export File
• Excluded GRM
Recipes for individual components are stored, but when components are imported in multiple
assemblies, only the last recipe is stored, as shown in the following use cases:
2. User B, at site 2, imports assembly Y ( also includes component Z) from site 1 with the
include_relation value set to Rendering.
The recipe is overwritten and item revision Z/A has the Rendering relationship.
2. User B, at site 2, imports the same item X with revision selector set to Latest Working.
2. User B, at site 2, imports the same item X with revision selector set to Latest Working.
Identity manager
Data Exchange uses the GSIdentity object to provide a unique identity for items that are moved
between systems that have their own identity mechanism. Due to differences in data models and
the intended item's use, the GSIdentity object may be unique from the system ID for the item, such
an OBID or UID. Some objects may have several equivalent objects in the destination systems.
Therefore, the GSIdentity object for the exported object may equate to multiple objects in the
destination system that must reflect the original GSIdentity attributes.
The GSIdentity class is a subclass of the POM class and contains the following attributes:
• system
Provides a token indicating the data origination, for example, Teamcenter Enterprise or
Teamcenter.
• label
Contains a textual representation for the data's UID or OBID in its native system.
• sub-label
Contains the UID or OBID of helper objects in many-to-one mappings.
• class
Contains the calling class name.
• split_token
Contains information the translator uses to identify the individual components for one-to-many
mappings.
• context
Tracks the attribute name when an attribute in one system becomes the full object in another
system. It may also identify (usually as an index) a runtime object that becomes a persistent
object in the receiving system. This occurs when the runtime object has uniqueness only in
the context of a persistent object. In many instances, neither of these two cases apply and
this attribute is empty.
• factor_id
Contains a unique string that identifies a group of Teamcenter Enterprise objects that belong
together.
• atomic
Provides a token that indicates whether the label is simply the UID or OBID of an object or
something more complex.
The GSIdentity object is persisted and associated with the transferred object created in the new
system. Objects have only one identity. The composition of GSIdentity data provides a key that
remains consistent and unique for the data's life or may be changed systematically if the mapping
algorithm is altered. The collect_garbage utility can be used to remove GSIdentity objects from the
database for objects that have been deleted.
Ownership manager
The ownership manager controls ownership of objects that are transferred among systems and
participates in import and export operations. When a part is processed for transfer of ownership,
ownership of all part revisions is transferred to the receiving site. A transfer of ownership can be for
the top-level parts only or for an assembly and all its child parts. If ownership of a replicated object is
transferred to a new site, the export records for the object are transferred to the receiving site so that
the owning site is always aware of existing replicas and all replicas are updated with the new site
ownership data.
When ownership of an object that is published to an ODS is transferred to another site, the ODS
publication record is updated with the new owning site.
During the ownership transfer process, objects at the exporting site are locked to prevent modifications
and are flagged as in the Ownership Transfer Pending state. This flag is cleared after the exporting
site receives a message from the importer that the transfer is complete and the exporting site
marks the objects it has as replicas. If the ownership transfer process terminates unexpectedly, the
ownership may be in an inconsistent state. The ensure_site_consistency utility allows you to report
objects that are in the Ownership Transfer Pending state and to correct inconsistent ownership.
The following is an example process for exporting an object with transfer of ownership:
1. The user selects objects to be exported from site 1 to site 2.
3. The exporter processes the objects to be exported, for example, remove objects with no export
privilege, add helper objects, process closure rules, and so forth.
4. The ownership manager processes this list and removes objects in workflow, removes shared
objects, adds additional objects to maintain ownership consistency, for example, all item revisions
for an item.
5. The exporter adds export records for the objects to the list of objects.
7. The exporter processes the object list and generates a TC XML file.
8. The importer at site 2 imports the objects from the TC XML file including export records.
9. The ownership manager sets the site ownership for imported objects as site 2. Objects imported
as replicas are left out.
10. The importer keeps track of objects for transfer of ownership is successful.
11. Site 2 generates a TC XML file with success/failure state for ownership transfer for each object
and sends it back to site 1.
12. Site 1 reads the objects in the TC XML file and sends a request to the ownership manager
to unlock them.
13. The ownership manager unlocks all objects from this list and also changes the owning_site
attribute for objects whose ownership was successfully transferred.
14. The ownership manager sends a message to Object Directory Service (ODS) regarding
ownership changes.
15. Teamcenter integration framework sends messages to sites where replicas and stubs are located
regarding ownership changes.
16. The ownership manager deletes the export records for these objects.
• If a user performs a local object checkout, only that user can change the object.
• If an object is checked out to remote site, users at the local site cannot change the object.
The following is the process Teamcenter uses for packaging a briefcase file:
1. Export the data files referenced in the TC XML files to the transient volume.
2. Update the TC XML files to contain the relative path to the data files instead of FMS file tickets.
3. Create the briefcase file using the TC XML data and the data files, and include the following
information in the briefcase file as attributes:
• Exporting site
• Target site
• Teamcenter version
4. Create a briefcase dataset object with the briefcase file and log file attached to it as named
references, and attach the briefcase dataset object to a Teamcenter mail that is sent to the
exporting user.
Briefcase also can be used to schedule an export through Teamcenter Integration Framework or
Global Services, allowing the export to proceed in the background so that you can immediately gain
rich client session control for other purposes.
The briefcase feature does not support transfer of ownership but does support check out to site to
allow modification of objects by suppliers
Security Services
Security Services allows a user to sign on one time for access to multiple Teamcenter products.
Teamcenter Data Exchange support this functionality when its components are properly configured to
use single sign-on (SSO).
ldapsync utility
Teamcenter provides a batch utility that maps data constructs from an LDAP repository to objects in
the Teamcenter database. You can create, update, and deactivate Teamcenter objects by making
changes to the appropriate LDAP entries and then running the ldapsync utility. This tool is not
required by Data Exchange, however it can simplify your security configuration by synchronizing your
Teamcenter security objects to your LDAP configuration.
Even if you are not using Data Exchange, you can use this utility to synchronize your LDAP
configuration and Teamcenter security objects.
You can control the following default behavior of the utility using Teamcenter preferences set at
the user location:
• If an object exists in the LDAP repository but not in the Teamcenter database; it is created in the
database.
• If an object exists in the Teamcenter database but not in the LDAP repository; it is deactivated
in the database.
• If an object exists in both locations, the ldapsync utility compares the last modified timestamp in
the LDAP repository to the last synchronized timestamp in the Teamcenter database and updates
the object in the database when the LDAP timestamp is more recent.
Object nodes
The ldapsync utility recognizes the following four types of entries or nodes in an LDAP repository:
• user
• group
• role
• undefined
Company - ignored by
ou=ABC, dc=com ldapsync
Group =
Group - synched
Engineers
Role = Role =
Roles - synched
Design Coder
Users - synched
User-C User-F
User-B User-E
User-A User-D
Object nodes
The first three map directly to their equivalent objects in Teamcenter, with user nodes mapping to
both Teamcenter person and Teamcenter user objects. The ldapsync utility also constructs group
memberships from the combination of a user, role, and group node. Undefined nodes are useful
within LDAP for providing clarity to the overall structure. For example, nodes of object class ou
(organizational unit) can be used to segregate users by geographical location without affecting
the ldapsync utility output.
There is no way to easily determine how many indirect parents a node may have; however, this
information has no known value at this time.
Group membership
The ldapsync utility determines group memberships by mapping user, group, and role nodes,
on a one-to-one basis, to their appropriate Teamcenter objects. Group memberships result
from the relationship of these nodes in the LDAP repository. The minimum requirement for a
group membership is a group node and a user node. If a default role for a group is specified, a
role node is optional. The parent→child→grandchild relationship in LDAP is represented as
group→optional-role-node→user. Intervening undefined nodes, such as organizational units (ou)
are ignored in the path, an example of this in the LDAP repository is:
group→ou1→ou2→role→ou3→user
• LDAP_admin_pw
Specifies the password for the LDAP administrator identified by the LDAP_admin_dn preference.
If you do not set this preference, you must include a password using the –l argument for the
ldapsync utility. Because this password is stored in the database in plain text, it is recommended
that the associated account have read-only access to the LDAP.
• LDAP_cert_db_path
Specifies the path to the directory containing the cert8.db (certification database) file. the
ldapsync utility uses this value only when the LDAP_use_ssl preference is set to true.
• LDAP_port_number
Defines the port number used when connecting to the LDAP directory server. It is used with the
value set in the LDAP_service_hosts preference to define an LDAP directory server connection.
• LDAP_service_hosts
Lists the host or hosts that provide LDAP directory services for this installation. Valid inputs are
host names or IP addresses. This value is used with the value set in the LDAP_port_number
preference to define LDAP directory server connections.
• LDAP_use_ssl
Specifies whether a connection to the LDAP directory uses SSL encryption. This preference
contains a logical value set to false by default. If you set this preference to true, you must
also set the LDAP_cert_db_path preference.
3. Verify the SSL port can be accessed using an LDAP browser utility.
Your network security administrator must perform the first three steps and they may assist you with
step four. To register the directory server as trusted (step 4):
Note
For information about how to perform any of these steps, see the Mozilla web site.
1. Download the certutil executable from the Mozilla web site. The executable is packaged in the
NSS and NSF download packages.
LDAP
inetOrgPerson
Each attribute map can contain string values for the following:
o Teamcenter attribute name
o Mapped LDAP attribute
o Default value used if there is no mapped LDAP attribute or if the mapped LDAP attribute
value is null
The LDAPLastUpdate attribute is used for synchronization checks but is not set in the
Teamcenter role object.
Caution
The LDAPUserGroup and LDAPUserRole attributes are required in Teamcenter.
Therefore, you must specify either a mapped LDAP attribute or a default value for
these attributes.
• LDAP_person_attr_mapping
Defines the mapping of LDAP objects to Teamcenter person attributes using sets of three
strings, for example:
Note
This example uses generic person attribute values (PA1–PA10)
LDAP_person_attr_mapping=
LDAPPersonName
cn
%REPLACE_ME%
LDAPLastUpdate
modifyTimestamp
%REPLACE_ME%
PA1
postaladdress
%REPLACE_ME%
PA2
localityName
%REPLACE_ME%
PA3
st
%REPLACE_ME%
PA4
postalCode
%REPLACE_ME%
PA5
co
%REPLACE_ME%
PA6
o
%REPLACE_ME%
PA7
employeeNumber
%REPLACE_ME%
PA8
physicalDeliveryOfficeName
%REPLACE_ME%
PA9
mail
%REPLACE_ME%
PA10
telephoneNumber
%REPLACE_ME%
Each attribute map can contain string values for the following:
o Teamcenter attribute name
o Mapped LDAP attribute
o Default value used if there is no mapped LDAP attribute or if the mapped LDAP attribute
value is null.
Default
Attribute name LDAP attribute value Description
LDAPPersonName cn Does not Person name
apply
LDAPLastUpdate modifyTimestamp None Last update
timestamp
PA1 postaladdress None Address
The LDAPLastUpdate attribute is used for synchronization checks but is not set in the
Teamcenter role object.
• LDAP_base_dn
Defines the distinguished name (DN) of one or more nodes in the external LDAP directory where
the user and person synchronization process starts. Use this to limit the extent of the ldapsync
utility user and person search for performance reasons or to partition users in a single LDAP
directory server instance for use with multiple Teamcenter installation. If the LDAP directory
server does not have this type of organization, set this value to the lowest level DNs that
encompass all Teamcenter users.
The following are examples of a high level DN and a more specific DN, respectively:
dc=siemens,dc=com
ou=Engineering Groups,ou=specials users,db=siemens,dc=com
• LDAP_ignore_users
Defines Teamcenter user IDs that the ldapsync utility does not process. The default value
is infodba.
Note
The ldapsync utility never processes the infodba user even if it is not included
in this list.
This allows you to include a list of user IDs that exist in Teamcenter for administrative purposes
that do not have corresponding entries in the LDAP repository.
• LDAP_user_object_class
Defines the LDAP object class you use to indicate Teamcenter users to synchronize. If you use
multiple classes to represent Teamcenter users, specify the common base class. The default
value is inetOrgPerson.
• LDAP_user_query_filter
Defines the set of conditions an LDAP object must satisfy to match a Teamcenter user object for
synchronization. Use LDAP query filter syntax for this preference value. The default value is
uid=*.
modifyTimestamp
%REPLACE_ME%
LDAPGroupDBA
%REPLACE_ME%
0
LDAPGroupRole
%REPLACE_ME%
%REPLACE_ME%
Each attribute map can contain string values for the following:
Default
Attribute name LDAP attribute value Description
LDAPGroupDBA Undefined None Group DBA
privilege
LDAPGroupDesc description None Group
description
LDAPGroupName cn Does not Group name
apply
LDAPGroupRole Undefined None Default role
LDAPLastUpdate modifyTimestamp Does not Last update
apply timestamp
The LDAPLastUpdate attribute is used for synchronization checks but is not set in the
Teamcenter role object.
• LDAP_group_base_dn
Defines the distinguished name (DN) of one or more nodes in the external LDAP directory where
the group synchronization process starts. Use this to limit the extent of the ldapsync utility group
search for performance reasons or to partition groups in a single LDAP directory server instance
for use with multiple Teamcenter installation. If the LDAP directory server does not have this type
of organization, set this value to the lowest level DNs that encompasses all Teamcenter groups.
The following are examples of a high level DN and a more specific DN, respectively:
dc=siemens,dc=com
ou=Engineering Groups,ou=groups,db=siemens,dc=com
• LDAP_group_object_class
Defines the LDAP object class you use to indicate Teamcenter groups to synchronize. If you use
multiple classes to represent Teamcenter groups, specify the common base class. The default
value is groupOfUniqueNames.
This allows you to define specific subclasses in LDAP to differentiate groups and roles. If your
groups and roles have the same object class, use the LDAP_object_type_attr preference
instead.
• LDAP_group_query_filter
Defines the set of conditions an LDAP object must satisfy to match a Teamcenter group object for
synchronization. Use LDAP query filter syntax for this preference value. The default value is cn=*.
• LDAP_role_attr_mapping
Defines the mapping of LDAP objects to Teamcenter role attributes using sets of three strings, for
example:
LDAP_role_attr_mapping=
LDAPRoleName
cn
%REPLACE_ME%
LDAPRoleDesc
description
%REPLACE_ME%
LDAPLastUpdate
modifyTimestamp
%REPLACE_ME%
Each attribute map can contain string values for the following:
The LDAPLastUpdate attribute is used for synchronization checks but is not set in the
Teamcenter group object.
• LDAP_role_object_class
Defines the LDAP object class you use to indicate the Teamcenter roles to synchronize. If you
use multiple classes to represent Teamcenter roles, specify the common base class. The default
value is groupOfUniqueNames.
This allows you to define specific subclasses in LDAP to differentiate groups and roles. If your
groups and roles have the same object class, use the LDAP_object_type_attr preference
instead.
• LDAP_group_query_filter
Defines the set of conditions an LDAP object must satisfy to match a Teamcenter role object for
synchronization. Use LDAP query filter syntax for this preference value. The default value is cn=*.
• LDAP_member_type_attr
Defines the LDAP attribute that contains membership type (indirect or direct) for this object. The
LDAP object must have an attribute that matches the value of this preference that contains a
logical value indicating whether the object has indirect (false) or indirect (true) children. For
example, if you set this to memberType, the LDAP object must have an attribute by that name
that is set to true for indirect children or false for direct children.
This preference applies to objects representing either groups or roles defined in LDAP.
If you set this preference, you must also set the LDAP_member_list_attr preference.
• LDAP_object_type_attr
Defines an LDAP attribute that contains the object type for this object. This applies to group or
role objects defined in LDAP. The object name must reference a string attribute defined in the
LDAP group object that is set to either group or role. For example, if you set the preference value
to objectType, your LDAP must have an attribute by that name that is set to either group or role.
• LDAP_sync_group_flags
Defines the synchronization for groups using the flags described in the following table. The
deactivate flag is not valid for this preference. The default value is scue.
• LDAP_sync_member_flags
Defines the synchronization for members using the flags described in the following table. The
deactivate flag is not valid for this preference. The default value is scue.
• LDAP_sync_role_flags
Defines the synchronization for roles using the flags described in the following table. The
deactivate flag is not valid for this preference. The default value is scue.
• LDAP_sync_user_flags
Defines the synchronization for users using the flags described in the following table. The default
value is scdue.
2. Add the unique object class to the group or role that you want to define.
3. Set the ldapsync preferences. For this example, set the following preferences:
LDAP_group_object_class: groupOfUniqueGroupNames
LDAP_role_object_class: groupOfUniqueRoleNames
2. Define a unique attribute within the object class in the LDAP server. For example, add the
objectType attribute to the groupOfUniqueNames object class.
2. Add the attribute to a group or role with the attribute value set to the other DN directory. You can
configure multiple LDAP_child attributes under each group or role.
Caution
To avoid an infinite loop, ensure the DN you provide in the LDAP_child attribute does
not point back to the original DN.
3. Set the LDAP_member_type_attr attribute as for direct or indirect searching and the
LDAP_member_list_attr attribute to the unique attribute. For example, if you add the
LDAP_child attribute and are using indirect searching:
LDAP_member_type: true
LDAP_member_list_attr: LDAP_child
Note
The utility must be run from a command prompt with the proper environment settings.
Replace userid and password with a Teamcenter administrative user ID and password. Replace
ldap-password with the password for the DN of an LDAP user who has search and read
permissions in the LDAP directory service.
Note
The –l=ldap-password argument is not required for the ldapsync utility if you set the
LDAP_admin_pw preference.
LDAP_ignore_users infodba
LDAP_member_list_attr uniqueMember
LDAP_object_type_attr Object-type
LDAP_person_attr_mapping LDAPPersonName
cn
%REPLACE_ME%
LDAPLastUpdate
modifyTimestamp
%REPLACE_ME%
PA1
postalAddress
%REPLACE_ME%
PA2
localityName
%REPLACE_ME%
PA3
st
%REPLACE_ME%
PA4
postalCode
%REPLACE_ME%
PA5
co
%REPLACE_ME%
PA6
o
%REPLACE_ME%
PA7
employeeNumber
%REPLACE_ME%
PA8
physicalDeliveryOfficeName
%REPLACE_ME%
PA9
mail
%REPLACE_ME%
PA10
telephoneNumber
%REPLACE_ME%
LDAP_port_number port-number
LDAP_role_query_filter (cn=*)
LDAP_service_hosts LDAP-hostname
LDAP_sync_group_flags scue
LDAP_sync_member_flags scde
LDAP_sync_role_flags scue
LDAP_sync_user_flags scdue
LDAP_use_ssl FALSE
LDAP_user_object_class inetOrgPerson
LDAP_user_query_filter (uid=*)
LDAP_ignore_users infodba
LDAP_member_list_attr uniqueMember
LDAP_member_type_attr
LDAP_person_attr_mapping LDAPPersonName
cn
%REPLACE_ME%
LDAPLastUpdate
modifyTimestamp
%REPLACE_ME%
PA1
postaladdress
%REPLACE_ME%
PA2
localityName
%REPLACE_ME%
PA3
st
%REPLACE_ME%
PA4
postalCode
%REPLACE_ME%
PA5
co
%REPLACE_ME%
PA6
o
%REPLACE_ME%
PA7
employeeNumber
%REPLACE_ME%
PA8
physicalDeliveryOfficeName
%REPLACE_ME%
PA9
mail
%REPLACE_ME%
PA10
telephoneNumber
%REPLACE_ME%
LDAP_port_number port-number
LDAP_role_query_filter (cn=*)
LDAP_service_hosts LDAP-hostname
LDAP_sync_group_flags scue
LDAP_sync_member_flags scde
LDAP_sync_role_flags scue
LDAP_sync_user_flags scdue
LDAP_use_ssl FALSE
LDAP_user_object_class user
LDAP_user_query_filter (sAMAccountName=*)
Headquarters
Europe
Granite Park One
Stephenson House
5800 Granite Parkway
Sir William Siemens Square
Suite 600
Frimley, Camberley
Plano, TX 75024
Surrey, GU16 8QD
USA
+44 (0) 1276 413200
+1 972 987 3000
Asia-Pacific
Americas
Suites 4301-4302, 43/F
Granite Park One
AIA Kowloon Tower, Landmark East
5800 Granite Parkway
100 How Ming Street
Suite 600
Kwun Tong, Kowloon
Plano, TX 75024
Hong Kong
USA
+852 2230 3308
+1 314 264 8499