Names of Administrative Objects

Although you can rename schema elements to support your business processes, many administrative objects are referenced within expressions in policy accesses. If these objects are renamed after the installation is complete, you must update any expressions that reference the object names to reflect the changed name. Before renaming any administrative objects, you should search the policy definitions to determine if that object is used in any filter expression.

When changing names of administrative objects, change only the administrative object name, not the symbolic name.

The expressions used in policy access filters do not recognize symbolic names so when an expression references an administrative object, the standard name for the object is used and not the symbolic name. One exception is when the expression calls a JPO and an administrative object, often a role, is passed into the JPO for input. In this case, the JPO recognizes symbolic names and so they are used. Administrative objects used in expressions in this way, as input for a JPO, are not affected. Since administrative object symbolic names do not change, expressions that include symbolic names should not need updating.

The system identifies administrative objects using symbolic names rather than standard object names.

Symbolic names have this syntax:

[administrative object type name]_[original object name with no spaces]

For example, the symbolic name of the Originator attribute is attribute_Originator. The symbolic name of the Product Manager role is role_ProductManager. If you change the name of the Originator attribute to Creator, the symbolic name remains attribute_Originator, allowing the system to identify the attribute even though the name has changed.

Do not change the symbolic name for an administrative object. If you do, objects in the schema will no longer be able to reference the object. Additionally, new app versions will be unable to identify the object for updating.

Whenever you refer to an administrative object within a program (Tcl or JPO program), you must use the object's symbolic name and not the standard name ("policy_Person", not "Person"). You must also use the symbolic name when specifying an administrative object as an input parameter that is to be passed to a program. For example, when specifying the eService Safety Vault, an attribute whose value is passed to the eServicecommonObjectGenerator.tcl program, you must use the symbolic name for the vault.

The symbolic names for all administrative objects are stored as properties of a program object called eServiceSchemaVariableMapping.Tcl. Each property assigns a symbolic name to an administrative object. For example, this diagram shows the properties that assign a symbolic name to an attribute, type, and vault object.

For samples of Java code that get the symbolic name for an administrative object, see the Legacy ENOVIA Web Apps Customization Guide.

For instructions on how to view symbolic name properties, see Viewing Administrative Properties.

Using fixed symbolic names to track administrative objects has several advantages:

• You can easily change the name of administrative objects. As long as the symbolic name does not change, the system can identify renamed objects. The only exception is program objects that are installed with Collaboration and Approvals and apps. You should not change the name of any program object that is prefixed with "eService" or "emx".
• When you do change a name, other administrative objects in the schema that reference the object can still identify the object. For example, if you change the name of the Originator attribute to Creator, the types that use the attribute called Originator will now use the attribute called Creator because its symbolic name is still attribute_Originator.
• Because names can be changed without causing problems, the system changes names to prevent name collisions between objects in your existing database and objects in Collaboration and Approvals. If the installation program finds an existing object with the same name as a Collaboration and Approvals object, it adds a prefix to the name of the Collaboration and Approvals object. The prefix is "eService" and the version number of the installation. For example, if you install the version V6R2013 Collaboration and Approvals onto a database that contains a Part type, the installation program renames the Part type within the Collaboration and Approvals to "eServiceV6R2013~Part".
• When upgrading to a new version, the system reliably finds the correct object to update, even if you have renamed the object and even if you have replaced the Collaboration and Approvals object with your object. As long as the symbolic name is assigned to the object you want to use, the installation program can update the object.

Like administrative objects, the system identifies policy states using symbolic names. For example, the symbolic name for the Active state of the Person policy is state_Active. Symbolic names for states are stored as properties on the policy object.

This diagram shows all the properties for several administrative objects including the properties for a policy.

Apps are designed to let you use your exact business terminology rather than cryptic words that have been modified to conform to the computer system limitations.

Names are case-sensitive and spaces are allowed. You can use complete names rather than contractions, making the terminology in your system easier for people to understand. Generally, name lengths can be a maximum of 127 characters. Leading and trailing spaces are ignored.

You should avoid using characters that are programmatically significant to the apps. These characters are specified as follows for Administrative Object Names:

@ , * ? [ ] # $ { } \\\" < > | ' 

These characters are specified as follows for Administrative Object Descriptions, and other related Text fields:

# $ { }

To configure the system to allow the use of the above-listed special characters, see Bad Characters Properties.

Also, do not prefix any administrative object (types, relationships, attributes, programs, wizards, and so on.) with "eService".

Users should never use special characters for companies, business units, or persons, or for any attribute whose value is used in a Tcl or MQL script.

You need to follow specific rules when changing administrative object names.

• Collaboration and Approvals uses string resource properties to manage internationalization of schema names. The string resource IDs for administrative objects are defined using the actual administrative object name. Therefore, if you change an administrative object name and want the name to be displayed on internationalized versions of apps, you need to update the string resource ID in addition to the value for the ID. For instructions, see Studio Modeling Customization Guide: Translating Schema.
• Do not use underscore _ in administrative object names because that is used in symbolic names and could affect parsing of the string.
• Labels and other text for UI components, such as Actions menus, page headings, and tree category labels, that contain words that are the same as administrative object names are NOT updated automatically when schema is renamed. Onscreen text for UI components are defined, like other onscreen text, using string resource properties. Therefore, the string resource value must be changed to change the UI component text. Macros and expressions are not used for UI component text because they cannot be internationalized.

For example, suppose you rename the Part type to Item type. Onscreen text defined by retrieving data from the database, such as a select expression, shows the updated name, Item. If you updated the internationalized string resource ID and value, international versions also display the updated type name. However, a menu with the label "Create Part" will not be updated because the label is defined using a string resource and not using a macro or select expression. To update the menu label, you need to change the value for the string resource from "Create Part" to "Create Item". For instructions about changing onscreen text using string resource properties, see Changing Onscreen Text and Other Strings.

Do not change the names of program objects installed with the apps. The names for these programs are prefixed with "eService[name of install directory]". Programs in the Schema directory are prefixed with "eService" or the app name only. Do not change this prefix and do not create custom programs using the eService or emx prefixes. If you need to modify the name of an app program, clone the program and change the name of the cloned program.

If you rename objects that are referenced in policy expression accesses, you must update any expressions that reference the object names.

The tilde (~) and pipe (|) characters are reserved for use in the programming code for apps. Do not use these characters when entering data for any field in Collaboration and Approvals or any app, including fields in app Web pages. This restriction includes names, descriptions, comments, and all other attributes and properties.

You also need to follow specific rules when naming program objects.

• Do not prefix program objects with any of these strings: bid, bom, build, common, draw, engchg, prodcfg, pom, profile, softchg, softrqmt, supplyacc, ui, or eService.
• Do not prefix any administrative objects (types, relationships, attributes, programs, wizards, and so on) with "eService".