Naming rules

Edit online

Naming rules define a set of criteria to uniquely identify a CI. These rules are used to link authorized CIs to actual CIs. In automated linking of assets and CIs (not described here) naming rules are to link authorized assets to authorized CIs.

This section provides an overview of the naming rules and how to design them.

Naming rule characteristics

The naming rules used to link authorized to actual CIs are designed to mimic the Common Data Model (CDM) naming rules, which include the following:
  • There are multiple naming rules per CI type.
  • Each naming rule is assigned a priority within a CI type.
  • Naming rules consist of one or more parts:
    • An alphanumeric attribute
    • A relationship to another CI (for example, a parent CI)
  • A naming rule succeeds in identifying a CI if all parts of the naming rule are true.
  • Naming rules are processed in ascending order priority until a naming rule succeeds.
Refer to the Common Data Model (CDM) documentation for more information on CDM naming rules.
Note: A limitation of this feature is that you cannot set up a NOT operator like the NOT operator that the Common Data Model uses in its naming rules.

Naming rule MBOs

The product naming rules consist of the following Maximo business objects (MBOs). (You can view a sample naming rules XML file, NamingRuleSample.xml, on the developerWorks Process Automation Community site.)
NMRGROUP
NMRGROUP defines a collection of naming rules that can be assigned to one or more CI types. For example, you might choose to define an NMRGROUP called computersystems and assign that group of naming rules to the following CI types: WINDOWSCOMPUTERSYSTEM, AIXCOMPUTERSYSTEM, LINUXCOMPUTERSYSTEM, and so on.
  • NMRGROUP.NMRGROUPNUM: The unique identifier for a naming rule group.
NMR
NMR defines a naming rule that is associated with a particular naming rule group. There can be one or more naming rules for a naming rule group.
  • NMR.NMRGROUPNUM: Identifies the naming rule group that the naming rule is part of.
  • NMR.NMRNUM: Unique identifier for a naming rule.
  • NMR.PRIORITY: The priority in which a naming rule is processed. Priority is respected within the naming rules of a particular naming rule group.
NMRATTR
NMRATTR defines the details of the naming rule. An NMRATTR row can identify either an alphanumeric attribute or a relationship condition, but not both.
  • NMRATTR.NMRNUM: Identifies the naming rules that the naming rule part is associated with.
  • NMRATTR.NMRATTRNUM: Allows unique identification for a naming rule part.
  • NMRATTR.ISATTR: True means the NMRATTR represents an alphanumeric value and false means the NMRATTR represents a relationship to another CI.
  • NMRATTR.ATTRID: The attribute name used as part of the naming rule (for example, computersystem_fqdn). This applies only if ISATTR is true.
  • NMRATTR.RELATIONNUM: The relationship (RELATION.RELATIONNUM) used to identify a related CI to a matching criteria in a naming rule. This works in conjunction with NMRATTR.RELATIONGROUPMAPPING and applies only if ISATTR is false.
  • NMRATTR.RELATIONGROUPMAPPING: The NMRGROUPNUM used to identify which set of CI types to look at when searching for a related CI. This works in conjunction with NMRATTR.RELATIONNUM and applies only if ISATTR is false.
NMRGROUPMAPPING
NMRGROUPMAPPING assigns an authorized CI type to a naming rule group. An authorized CI type can be associated to only one naming rule group.
  • NMRGROUPMAPPING.NMRGROUPNUM: The naming rule group that the authorized CI type is assigned to.
  • NMRGROUPMAPPING.CLASSSTRUCTMAPID: The authorized CI type to be assigned to a naming rule group.
NMRCLASSMAPPING
NMRCLASSMAPPING maps a CI classification to an actual CI classification. This allows the naming rule engine to determine which actual CIs should be evaluated for a match.
  • NMRCLASSMAPPING.CLASSSTRUCTMAPID: The authorized CI type.
  • NMRCLASSMAPPING.LINKCLASSSTRUCTMAPID: The actual CI type.

Guideline for designing your naming rules

Configuring proper naming rules is the key to successful linking of authorized CIs to actual CIs. Use the following guidelines to create and import the naming rules.
  1. Identify which CI types have CIs that need to be linked.
  2. For each CI type, refer to the CDM (Common Data Model) documentation and review the naming rules. The CDM has carefully defined naming rules for each CI type to ensure that CIs can be uniquely identified. The authorized naming rules can be set up similarly to the CDM. This should be the starting point for naming rule design.
  3. Evaluate data in your system. Randomly check CIs of each type to see if the CDM naming rules will match the appropriate CIs to actual CIs.
  4. If CIs are imported from another data source, you may need to define naming rules that differ from the CDM definitions. For example, an authorized computer system may not have any alphanumeric attributes and the only way to determine its corresponding actual CI is to use a relationship to another CI, such as ipaddress. For these custom situations, you should define your own custom naming rules. Here are some best practices:
    • Avoid rules that create circular traversal of CIs. Like the CDM naming rules, you can define rules that use a related CI as part of the link criteria. If your rules create a situation where a CI A depends on CI B and that CI B depends on CI A, an error message will be displayed to notify you that a circular dependency exists in the naming rules.
    • If possible, prioritize the rules that have the greatest likelihood of succeeding first to maximize performance.
    • To maximize performance further, give rules that do not rely on related CIs a higher priority than the rules that do rely on related CIs.
    • Use preview mode to review the CIs that will be linked before actually creating the links.
  5. Refer to NamingRuleSample.xml, located on the developerWorks Process Automation Community site, to view the format of naming rules XML file that is used to import the naming rules. The sample follows the Common Data Model for some key CI types, and the CI types are based on the best practice promotion scopes, as imported from the Deployer's Workbench.
    1. Start with the predefined CI types in the sample. Look at the NMRGROUPMAPPING and NMRCLASSMAPPING and modify the HIERARCHYPATHs if needed to match your own CI types.
    2. Following the same format, create additional NMRGROUPs and modify NMR and NMRATTR as needed for predefined CI types.

For more information about the objectstructure XML format, consult the “Integrating” section of the product information center.