Name allocation manager default business rules

Naming Rules

A naming rule defines the format used to generate names. It consists of a set of naming parts, with each part corresponding to an attribute or property of the object type to which the rule is applied.

A sequence is a naming part of type that can be added to a collection to generate an auto-increment value each time a new name of a type is created.

Naming rules are stored in a library located in the CONNECT folder, that is accessible across all scopes within the NAM tenancy. Any changes you make to a naming rule, or its Type Mappings are automatically reflected in all scopes that use the naming rule. Naming rules can also be grouped into Rule sets. 

Note:
Use caution when modifying Naming rules or Type mappings, or when a rule is shared across multiple scopes. This prevents unintended impacts across different scopes.

Business Rules

The following business rules apply:

• The Fixed and Digits properties of the naming part have been removed. Previously, these properties ensured that the number of digits matched the exact value specified in the Digits field. This is achieved with the Min length, Max length, Padding, and pad up to properties.

• The Required attribute for naming parts has been removed. It specified whether a value for the part was mandatory or optional. It is now determined by the Min length property.

• The Part of uniqueness field is no longer in name part. To replicate the functionality, use the Sequence criteria field within the Primary Sequence in the Update naming part window.

• Engineering supports only a Primary sequence for a naming rule; Secondary sequences are not supported.

• The text-type counter only accepts uppercase characters. 

• Any allocation requests that violates Min and Max length are rejected. 

Scopes 

A scope represents an application, project, asset, or any other defined context. Name contexts are created within each scope, to establish boundaries for groups of names. These groupings are based on the attribute or property that the client application uses to store or reference the generated name.

A Name Context ensures that a fully qualified name is unique within a context. Each refers to a rule set and a collection of individual naming rules, enabling flexibility in how names are generated and validated.

A Name Context includes multiple naming rules for the same class to support conditional execution of a naming rule.

If you delete a Name Context, it removes all allocated names and associated sequences. It is then removed from the scope.

If you delete a scope, you also delete all name contexts and any names or sequences allocated within it.

A scope can support up to 10 million name allocations based on calculated estimates. This figure has not been validated in real world testing, and there may be discrepancies in the actual number of allocations for a scope. 

Note:
Multiple naming rules for the same class are not supported from Engineering. Preserve Name is supported in compare and update operations.

There is no check for a name context with assigned names before it is deleted. Due to this, if you delete a Name Context, it may result in unintended data loss.

As no check is performed to confirm whether a scope has names assigned to it before deletion, you should be cautious when deleting a scope to prevent accidental loss of important data.

It is recommended that you distribute name allocations across multiple scopes instead of using a single scope. This improves performance and maintainability with a reduced risk of unexpected issues.

Integration with Engineering

Name allocation manager seamlessly integrates with AVEVA Unified Engineering (Engineering).

Note:
To apply NAM settings or create Type Mappings within the Engineering Config module, the logged-in user must hold the Config Admin role in NAM.

Since an Engineering project can only be connected to one scope, referenced projects should not be connected to a scope. For example, MLP should not be connected to a scope, because it connects all projects that reference it to the same scope.

The following business rules have been established:

• If a naming rule part is not unique in the tag renaming process, it does not retain its counter. The system then assigns the next available counter value.

• For Preserve name to function, a naming rule must be defined for the top-level class. The rule must contain a single name part and be placed in a Name context mapped to the Name attribute. The naming rule was created to support the business logic required for the Preserve name option during compare update.

• Type Mappings are resolved with the class URI defined in the conceptual model and it provides unique URIs. For example, if the MLP project is referenced by multiple projects, the data models are identical. You can export a data model from one project into another, to create a cloned model. When you modify the clone, it preserves the unique identifiers of the classes imported from the original model. Although Type mappings may function correctly, discrepancies can occur if the cloned model is not the same as the referenced MLP project. It is recommended that you create a new set of naming rules for the variant project.

• Duplicate names are not generated for any naming rule when you enable the Prevent duplicate names option for a name context. In earlier versions of Engineering, unique names were generated for naming rules that wrote to the Name attribute or included a sequence.

• The system guarantees consistent and predictable sequence allocation across naming rules in Name Context, provided all preconditions for the First and Next sequence options are met.

Preconditions for name generation

A name is generated only if all the following conditions are satisfied:

• A name is generated with a minimum and maximum length validation. For example, if the maximum length is set to 3, the sequence generated must not exceed 999. If you have already assigned the value 999, then it fails validation if you allocate with the Next option.

• Sequence reservation criteria validation.

• When all preconditions are met, name allocation with both First and Next option succeeds.

• If you use a naming rule without a sequence and do not provide values for its configured name parts in the Engineering client, the system does not send a name allocation request to NAM. The tag is created without a name, and you must rename it by entering the appropriate name part values.

• If you delete the type mappings for a class, the deletion applies to every Scope and name context that references the naming rule whose Type Mappings you removed. This is because naming rules and their type mappings are shared references across all scopes and Name Contexts.

• If you delete a Name context in the web UI, and a corresponding Name context is mapped to a writable attribute in the Engineering configuration, you must navigate to the Name Context Mappings screen in Engineering Config and select Save. This removes the Name context from the project.

Connection of second scopes

When adding a second or subsequent scope to a solution, the following considerations apply:

Type Mapping Reuse - Type Mappings are associated to naming rules stored in a shared library. Type Mappings that you define for the first scope with a data model are automatically applied to subsequent scopes that use the same naming rules. This removes redundant Type Mappings.

Automatic Type Mappings Import - When a project is connected to a second scope, the system automatically imports the Type mappings defined in the first scope. The mappings are only activated when you open the Type Mappings window within the project.

Name Context Mapping Requirement - Name contexts are scope-specific and must be mapped to a writable attribute for each scope. The Type Mappings window displays when you have mapped all Name contexts in the scope to Write attributes.

Database selection - When you open the Name Context window, the system prompts you to specify the Engineering database in which the Name Context Mappings are stored.

Shared Type Mappings - Type Mappings are shared across scopes. When you update them in a project they automatically update in other projects with the same naming rules. If this is not required, use cloned naming rules to isolate type mappings for specific projects.