By default, the following NX database attributes are the hard-coded database attributes. Their mappings cannot be modified:

Title	Description	Corresponding Teamcenter attribute
DB_PART_NO	Part Number	Item ID
DB_PART_REV	Part Revision	Item Revision ID
DB_PART_TYPE	Part Type	Item Type
DB_PART_NAME	Part Name	Item Name
DB_PART_DESC	Part Description	Item Description
DB_UNITS	Part Unit of Measure	Item Default Unit of Measure

You cannot override or remove the hard-coded mappings, but you can create additional, custom mappings

When writing a mapping, you need to know how to find out what is a valid step from each object to the next. This can involve finding out:

• What properties an object has

• What Generic Relationship types exist

• What Named Reference types exist

• What Roles exist

• What Release Levels exist and what Roles are associated with them

For information about these items, see the Teamcenter Administering Teamcenter book, Application Administration Guide. Go to Configuring Teamcenter Integration for NX, Configuring attribute mapping, Mapping Teamcenter attributes to NX part attributes.

The mapping file contains the mapping of attributes from NX to Teamcenter. It is a text file used as the source for importing the mappings into Teamcenter. Its location (file name and path) is specified when you run the export_attr_mappings utility to import the mappings (described in the next section). For an example, see Example Layout of a Mapping File.

Once you have created your mappings, you need to import them to Teamcenter in order to store them in the database so that everyone can pick them up. We recommend that initially you import them as test mappings; these are not picked up by other users, but you can pick them up by setting a preference value to run in a special test mode, and check to see that they work correctly before making them generally available.

To import the mappings, run:

%TC_ROOT%\bin\export_attr_mappings
-file=<text file>
[ -test ]
[ -dryrun ]
[ -u=<username> ]
[ -p=<password> ]
[ -g=<group> ]

where:

• <text file> is the file to read from. Includes file name and path.

• -test indicates to import as test mappings.

• -dryrun indicates just to parse the file, not actually to save the mappings.

• <username>, <password> and <group> are login arguments.

  Note:

   NOTE  Importing mappings completely replaces the existing ones (either the test ones or the real ones).

  Note:

   NOTE  Only a System Administrator may run this.

To check your test mappings,

• Set the Preference IMAN_USE_TEST_ATTR_MAPPINGS to any value (either as an environment variable or in your Teamcenter preferences).

• Log in as a System Administrator (non-SAs are not permitted to access test mappings).

When running with test mappings, Teamcenter provides extra information in the syslog file about invalid mappings, with lines like this, which can help you fix incorrect mappings::

Ifail 60003 meaning "Unresolvable mapping definition "%1$s"": failed to resolve mapping "DB_UNITS" : "Item.uom_tag.symbol" for rev0 00000f02 of dataset 00000f05

Such lines do not necessarily indicate an incorrect mapping (in this example, the mapping failed simply because this particular Item had no Default Unit Of Measure), but if a mapping fails more often than you think it should, this can help you to decide whether it is invalid.

After verifying your new mappings, you can then re-import them as real mappings, so that all users then pick them up.

Once you have imported your mappings, you can discard the text file. If you want to edit the mappings in future, you can export them again with:

%TC_ROOT%\bin\export_attr_mappings
-file=<text file>
[ -test ]
[ -u=<username> ]
[ -p=<password> ]
[ -g=<group> ]

where:

• <text file> is the file to write to. Includes name and path.

• -test indicates to export the test mappings.

• <username>, <password>, and <group> are login arguments.

  Note:

   NOTE  Only a System Administrator can run this.

When mapping attributes there are different ways that it can be accomplished, however it is suggested that you use the following methods for best results:

• Do not attach LOVs to the hard-coded attributes.

• Use long-hand notation in all cases.

• Synchronize only a few attributes to the Item Master form (if any at all).

• Make the names of the mapped attributes (those on the NX side) the same as the displayed names of the corresponding attributes in Teamcenter (shown during a search). Then the attribute names seen in an NX search and a Teamcenter search are the same.

  For example, if mapping attribute user_id of Item, the mapping statement in the attribute mapping file would be as follows:

  • owning_user : Item.owning_user.user_id /master=iman
         /description=”Item owning user id”

  where owning_user is the name of the mapped attribute on the NX side and its displayed name on the Teamcenter side is Owning User.

When the List of Values (LOV) is defined as Exhaustive in Teamcenter, the LOV attribute must have a value during an NX Save As operation. If the LOV attribute value is empty, an error is displayed and the part doesn't save. The recommended LOV type to use is Suggestive. This allows the LOV attribute to be selected as empty.

If the LOV is defined as Suggestive and you set the mapping file qualifier to /required, the value can be empty, but it still needs to be selected. If you do not touch the LOV attribute, the value is <no value set> and the part does not save and a warning message is displayed during a Save As operation.

You must use long-handed notation when writing definitions for LOVs.

LOVs defined as Hierarchical are not supported.