Server Administration > About Mapped Names of Administrative Objects in Windchill RV&S
About Mapped Names of Administrative Objects in Windchill RV&S
Mapped names are system or user defined names for administrative objects. Mapped names help the administrator identify the admin objects to which they are mapped. They are particularly useful when integrating the solution with other applications such as ThingWorx Flow and when providing OSLC support. During integration, the administrator can refer to the admin objects using the mapped names.
Mapped names are auto-generated the first time you import the solution. Windchill RV&S13.2.0.0 and later versions provide you the ability to customize the mapped names of administrative objects such as fields, types, states, test verdicts, or dynamic groups as per your requirements.
You can customize mapped names when:
You create or edit fields, types, states, test verdicts, and dynamic groups through the CLI, API, or GUI.
You export mapped names of fields, types, states, test verdicts, and dynamic groups using the im exportmappednames CLI command. The mapped names are exported to an XML file. You can then customize these mapped name based on your requirement and import them back into the system using the im importmappednames command. For more information see im exportmappednames and im importmappednames.
Considerations for Creating or Editing Mapped Names of Admin Objects
You cannot change mapped names of system fields. For example, "created by" is a system field. For such fields the system displays the mapped names as the original name createdby without special characters or spaces. This is true for all the system fields.
Mapped names must be in English and alpha numeric. They can contain letters from uppercase A-Z, lowercase a-z, and numbers 0-9. Spaces or special characters in mapped names are not allowed.
Mapped names must be unique among types, fields, states, test verdicts, or dynamic groups.
Mapped names must be between 1 to 100 characters long.
If you are creating a new field, type, state, test verdicts, or dynamic group using CLI, API, or GUI then:
If you do not specify any mapped names for the admin object, it is auto generated.
If you specify a mapped name that is same as an existing mapped name, then the system auto generates a mapped name based on the following format: admin object{internal_ID}{current-timestamp}. For example, if there is conflict with an auto generated mapped name for a dynamic group with name "Dynamic Group12", the new mapped name for the dynamic group would be: DG1211231121923
When upgrading the server, the mapped names for admin objects type, field, state, and dynamic groups used on the old server are carried forward to the upgraded server. However, if test verdicts are being upgraded, then the system generates new mapped names for test verdicts using the format V{internal_ID}{current-timestamp}.
During migration, when importing the admin provided objects from staging to production, the mapped names of the admin objects, Types, States, Dynamic Groups, Test Verdicts, and Fields are carried forward without any changes from staging to production.
Was this helpful?