This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Discovery 11.3
Best practices for custom TPL patterns and syncmappings.
TPL patterns are generally used to update or add data to the datastore. It is powerful, and there are no built-in checks or warnings to stop a user from creating or updating any node or attribute. However, some things that are possible could lead to unexpected behaviour, or even a completely broken appliance.
- Never attempt to update Directly Discovered Data (such as HostInfo, DeviceInfo, DiscoveryAccess, or DiscoveredFile)
- The only exception to this is the simple_identity attribute on the DiscoveredProcess node
- Never attempt to update system nodes (such as the Pattern node)
- It is allowed to update Host nodes, but do not update core product attributes; instead use custom attributes
- Updating attributes such as serial number or hostid are particularly dangerous as it will affect how Discovery uniquely identifies a host
- When possible, try to attach a new Detail node instead of adding custom attributes directly to a non-Detail node. See https://docs.bmc.com/docs/discovery/113/detail-node-788110429.html .
- Custom attributes should be used to store customer-specific data
- Custom attribute names should be all-lowercase, with no spaces or special characters (underscores are OK)
- When possible, do not modify TKU patterns or syncmappings. It's better to extend or override these 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 ...".
- Use the "stop" function early and often to avoid deeply-nested if statements. Some examples:
rancmd := discovery.runCommand(host, "cat /etc/myfile");
if not rancmd then