Best practices for custom TPL patterns and syncmappings

General principles:

• Don't create/delete/modify: 
  • Directly Discovered Data nodes (such as HostInfo, DeviceInfo, DiscoveryAccess, or DiscoveredFile). The only exception to this is the simple_identity attribute on the DiscoveredProcess node.
  • system nodes (Pattern, PatternModule, KnowledgeUpdate ...)
• It's not recommended to create/delete/modify Group nodes could lead to conflicts with manual edits.
• When updating inferred nodes (Hosts, SIs ...), it is recommmended to add the new data in Detail nodes or custom attributes. It recommended to name them with lower case characters and no special characters (excepted underscores). For example: my_special_custom_attribute.
• It is not recommended to update the existing attributes of inferred nodes. Especially the ones used by Discovery and CMDB to distinguish them (like names, os, serial number, hostid ...).
  • In the special case of a syncmapping pattern that replaces BMC_ComputerSystem.Name with Host.hostname, it can easily lead to 
• When possible, do not modify default TKU patterns or syncmappings. It's better to extend or override them with new patterns.
  • In the case of syncmapping patterns, use extensions. For example: instead of modifying CMDB.Host_ComputerSystem, create instead a new TPL file that contains "mapping from Host_ComputerSystem.host ...".
  • In the other cases, use the article below:
    Discovery: Best practices for customizing a TKU discovery pattern / How to minimize the maintenance cost.
• Use the "stop" function early and often to avoid deeply-nested if statements.  Some examples: