Removal

Patterns that are triggered on directly discovered data can specify specific rules for removing nodes and relationships previously created by the same pattern. If there are no removal specifications, removal for nodes created by such patterns is based on aging. Removal for nodes created by patterns triggered from other data (such as other inferred nodes) is based on existence of the originally triggering nodes.

Note

For patterns as well as the overall functioning in BMC Discovery, if the system scans the infrastructure and captures some data but in a subsequent scan fails to obtain the same data, it does not immediately remove the old data. For example, a scan in the past may have captured a host and its installed packages. But the latest scan may fail to retrieve the packages. This does not mean that the host now has no installed packages. The system records the failure in DDD and leaves the existing data as the best-known information. In a subsequent scan if the system successfully gets a list of packages, and some packages that were previously present are now absent, then the system updates the data by removing the relationships to non-existing packages.

Removal syntax

Removal blocks take the form:

*removal*
on _name_ := _node_kind_ _removal_condition_ [ where _condition_ ];
// removal body...
*end* *removal*;

An example is:

*removal*
on *si* := *SoftwareInstance* *aged*;
// This SoftwareInstance has a flag to indicate it should
// not be removed.
*if* *not* si.keep_me *then*
model.destroy(si);
*end* *if*;
*end* *removal*;

If a pattern creates multiple nodes, the removal block is executed for each of them when the removal condition is met. More than one removal block can be specified to support patterns that create more than one kind of node, and to support different blocks where the node kind is the same, but the conditions are different.

Once a pattern has at least one removal block, the normal automatic aging of all the inferred nodes the pattern creates is disabled. Explicit removal rules must be provided for all the created nodes.

Removal conditions

Removal conditions specify when the removal block will be executed. Two removal conditions are currently supported: aged and unconfirmed.

aged

aged caters for the case where something is about to be aged out, but you want to do additional checks to see if the system should actually delete it. In other words, you want to override the default aging behavior in order to make the system not delete something that it otherwise would do.

An example is where you have an SI modeled on a process that only runs rarely: it's likely that at some point the SI will be about to age out because that process hasn't been seen in a while, but what's actually happened is that the process has run, just not at the time that the host was discovered.
If aged is specified, the removal block is executed at the time the node in question would normally be removed due to aging; that is, it has not been confirmed for a while according to the aging parameters.

Because only root nodes and first-order SIs are removed through aging, it is important that you maintain your other nodes created in patterns. These nodes are not maintained automatically by BMC Discovery. For more information about data aging settings and the guidelines around modifying them, see Configuring-model-maintenance-settings.

unconfirmed

unconfirmed caters for the case where you want to remove something as soon as possible after it disappears from your environment. In other words, you want to override the default aging behavior in order to remove something before the system would have done.

An example is where you have a policy engine checking your CMDB to ensure that a given computer system is running a given piece of software. Thus, if that software is not seen when you discover the host then that indicates a policy violation, and you need to instantly delete the software instance from the data store (and thus from the CMDB) so that your policy engine can notice its absence.

If unconfirmed is specified, the removal block executes every time a scan of the relevant host is performed without the node in question being confirmed.

The where clause

The optional where clause can be used to only trigger execution of the removal block when the inferred node matches the criteria. The conditions take the same form as those in the trigger block (see trigger conditions).