Software Instance node

A Software Instance (SI) node represents an instance of an off-the-shelf software product or equivalent proprietary item of software. It can correspond to one single running process or a group of processes (possibly on multiple hosts). A Software Instance often corresponds to a licensable entity. Where possible, versions of Software Instances are retrieved and stored. They are created, maintained and destroyed by patterns. Software Instance nodes always have a relationship to the Pattern node corresponding to their maintaining pattern.

A first order Software Instance is one which models a piece of software running directly on the OS.
A second order Software Instance is one which model software formed from first order Software Instances.

Why an SI and not a Runtime Environment?

Software Instances represent pieces of software running on a host. A Runtime Environment represents something supporting running software. For example, Weblogic is represented by an SI, and Java by a Runtime Environment node. However, it is still important to keep track of the supporting Runtime Environments and their versions as some might require updates.

Virtual machines modeled by Virtual Machine nodes in BMC Discovery 11.2 and later

In versions of BMC Discovery before 11.2, SI nodes were used to represent virtual machines. In BMC Discovery 11.2, they are now modeled using a Virtual Machine node which makes it easier to find and relate VMs to their containers and Hosts.

Software Instance Lifecycle

The lifecycle of a SI node depends upon the details of the pattern that maintains it. This is determined by a combination of the pattern trigger condition, whether the pattern specifies an explicit key for the Software Instance and the logic contained in the pattern itself. In all cases, if a pattern is deleted, the SI nodes it is maintaining are immediately destroyed (as are all other nodes it might be maintaining).

Patterns can trigger on a Directly Discovered Data node, see Directly Discovered Data Trigger. They can also trigger or on the creation or modification of other SI nodes, see Software Instance Trigger.

Directly Discovered Data Trigger

Creation/update

If a pattern triggers on a Directly Discovered Data node, such as a Discovered Process node or a Discovered Listening Port node, it might choose whether to specify keys for the SI nodes it creates and maintains. If a key is specified then the decision whether to create a new SI node or to update an existing one depends on the key. If a SI node with the specified key exists, that node is updated, even if the node was previously maintained by a different pattern. In this case, the pattern takes over as the maintainer of the Software Instance. If a node with the specified key does not exist, a new SI node is created. In both cases, the Software Instance node is linked to the pattern with a maintainer relationship.

If a key for the Software Instance node is not specified by the pattern, the system creates or updates a group SI with an automatically generated key. The key is based upon the key of the hosting node (Host or Cluster) upon which the SI is running, the specified type of the SI and, optionally, a key group that can be used to separate the nodes into a number of groups. The count attribute is set to the number of instances in the group identified in the collection of Directly Discovered Data. Each time the host is scanned, the count attribute is changed to represent the number of instances seen in that scan.

Removal

The Software Instance node, including in a clustered environment, can be destroyed either manually or automatically.

To remove a SI node manually, find the necessary SI, select it in the list and pick Destroy from the Actions list.

The Software Instance is automatically removed in the following scenarios:
The age_count attribute of the (first order) SI node contains information about when the SI node was last confirmed by its maintaining pattern. If the age_count is positive, it represents the number of consecutive scans of the Host node in which the Software Instance was confirmed. If the age_count is negative, it represents the number of consecutive scans in which the SI node was not confirmed. The last_update_success and last_update_failure attributes contain the date and time at which the Software Instance node was last confirmed, and not confirmed, respectively.

In a clustered environment, the SI node is automatically destroyed when the Cluster node that contains the SI is deleted or when aging determines that the instance can be deleted.The aging of clustered Software Instances is performed slightly differently than normal SIs. This is because clustered SIs can be running on different hosts at different times due to a failover, or it can be running on multiple hosts of the cluster. Therefore, the age count for a clustered SI is stored on each Hosted Software relationship with a host of the cluster. If a cluster is configured to support a failover software, a flag is maintained to indicate whether the software is actively running on this host. When the age count of all Hosted Software relationships for a clustered SI exceeds the aging threshold, only then the SI node is destroyed.

If the pattern does not have a removal block, SI nodes are removed using an aging strategy based on the age_count and last_update_success attributes. The default aging parameters are the same as for a Host node, that is, if a SI node has not been seen for at least 7 scans, over a period of at least 10 days, it is destroyed. The parameters can be changed in the options, see Configuring model maintenance settings for more information.

The default aging strategy only applies to Software Instance nodes created from patterns triggering on the following node kinds and maintaining the Software Instances:

DiscoveredProcess
DiscoveredService
DiscoveredListeningPort
DiscoveredSoftware

If the SI is triggered on anything else, for example, a discovered file, then aging must be implemented in the pattern using a removal block.

If the pattern maintaining a node does have a removal block, the block can override the default aging scheme to destroy its nodes either earlier or later than normal. For TKU patterns, refer to the documentation accompanying each pattern for details of special removal behavior.

Regardless of the presence or absence of a removal block in the pattern, if the Host corresponding to a DDD-triggered Software Instance node is destroyed, the Software Instance node is immediately destroyed (see How nodes get removed).

Software Instance trigger

Creation/update

When patterns trigger on the creation or modification of other Software Instance nodes, the behavior is simpler. In this situation, the pattern must provide a key for each Software Instance node. The key is used to find an existing Software Instance node to update, or to create a new one. In both cases, the node is linked to the pattern with a maintainer relationship.

Removal

Software Instance nodes created as a result of Software Instance triggers are destroyed using the Cascade removal type; when the triggering Software Instance node is destroyed, the destruction is cascaded to the higher-level Software Instance node. See Cascade Removal.

It is possible for other triggers to be used. If any other trigger is used, BMC Discovery has no automatic removal behavior. Patterns must be used to explicitly destroy any Software Instance nodes created as a result of other triggers.