Default language.

  Important This documentation space contains information about the SaaS version of BMC Helix Discovery. If you are using the on-premises version of BMC Helix Discovery, see BMC Helix Discovery 24.3 (On-Premises).

TPL recommendations

The core purpose of TPL is to make it easy to describe the most common structures to be modeled, while remaining powerful enough to describe the vast majority of modeling situations. While the power of TPL enables you to describe the vast majority of modeling situations, it does not prevent you creating patterns that cause unwanted, or unexpected behavior.

Warning

Custom patterns allow a wide range of operations which cannot be controlled by BMC. It is solely the customer’s responsibility to ensure that the creation and execution of custom patterns can be run safely. BMC disclaims any responsibility for damages caused by custom patterns intentionally or unintentionally in the customer’s own environment.

This page details recommendations for using TPL. Following these recommendation will prevent unwanted behavior.

Never create or modify DDD nodes

You should only ever add additional attributes to inferred nodes. You must never create or update DDD nodes.

Never modify system created attributes

When writing custom TPL you should never modify system created attributes. Rather, you should add new attributes using _tw_meta_data_attrs as described in adding custom attributes.

System created attributes are those present in the default taxonomy. You can see whether your taxonomy is customized by checking for additional custom files on the Files tab of the Taxonomy page.

Use related.host rather than model.host

The related.host function should be used rather than the deprecated model.host function. The model.host function, with a lower-case "h" has an unfortunate clash with model.Host with an upper-case "H", which creates or updates an existing Host node.

Avoid modifying TKU patterns

When writing TPL patterns it is recommended that you do not modify TKU patterns. If you do modify a TKU pattern, it will be overwritten when you install a later TKU. When writing a pattern to override a TKU pattern, you should use the overrides statement in the pattern declaration.

Avoid custom pattern module name collision

Custom pattern does not trigger if the custom module name collides with a TKU module name. There is no error or warning; it just silently fails when scanning. To avoid this you can add a name, for example the company name, ACME_ at the beginning of any custom pattern name, custom module name, and custom attribute name.