Lifecycle of an application model
Once you have created an application model using Start Anywhere Application Modeling (SAAM), its state changes over time. Some changes are as a result of user actions including editing and publishing; other changes are a result of automatic updates performed by BMC Discovery.
Effect of publishing an application model
An application model only becomes visible as a Business Application Instance node when it is published. Once it is published, it appears in reports of applications within BMC Discovery, and is available for export to external systems and synchronization into the CMDB. When you publish an application model, three significant things happen:
- A Business Application Instance (BAI) node is created.
- Structural relationships (with specification SoftwareContainer:SoftwareContainment:ContainedSoftware:) are created between the BAI node and each of the top nodes within the model.
- Direct short-cut relationships (with specification AggregateSoftware:HostedSoftware:Host:Host) are created between the BAI node and each Host node on which at least one included piece of software is running, even if the Host nodes are themselves excluded from the model.
The structure of the application model reflects the connectivity and impact flow between the constituent parts of the application. Often the best way to visualize the structure is with the Impact layout, in which nodes are placed above nodes that impact them.
In this example, you can see Host nodes at the bottom of the visualization, which impact items of software, which impact other items of software, which in turn impact a load balancer pool, which impacts a group of externally visible load balancer services. To the sides of the load balancer services, you also see the two physical load balancer instances, that also impact the services. The Business Application Instance node is directly impacted by the load balancer services that are at the top of the visualization, so it is only those that are given SoftwareContainment relationships to the BAI. In this example, all the top nodes are in a single group, but in general, any node in the model that does not have anything above it is considered a top node, and is given a SoftwareContainment relationship to the BAI.
Short-cut Host relationships
It is very common to view the IT infrastructure from a host-based point of view, meaning that it is often useful to quickly answer the question of which applications run on a particular host, or which hosts are involved in a particular application. BMC Discovery therefore automatically maintains short-cut relationships between a BAI node and all the Host nodes upon which parts of it are running. These have specification AggregateSoftware:HostedSoftware:Host:Host. (The same relationship is also used for second-order Software Instances, which are ones that are composed of other Software Instances.) They are used in various reports, and in the links shown in the node view:
These short-cut relationships are distinct from the structural relationships, and they are always created. If you explicitly remove a Host from a model definition, but a Software Instance (or other software node) running on the Host is included in the model definition, the Host will still be given the AggregateSoftware relationship to the BAI, because the Host is involved in providing the application.
Editing a published model
When you edit a published model, the Model Definition node and all its corresponding structure is copied into a Revision. Any changes you make do not affect the published BAI node until you choose to publish the changes. When you publish changes, the changes are applied to the main model definition, and the BAI node is updated.
As soon as a model definition is saved, whether it is published or not, it becomes active for automatic updates as BMC Discovery scans. Every time a device finishes scanning, the system considers if any nodes hosted by that device are either already involved in model definitions, or are newly related to nodes that are. Any model definitions that are potentially affected are updated in the following manner:
- The system starts with all the nodes included in the model, except hosting nodes (such as Host and Load Balancer Instance) that often contribute to multiple applications.
- Evaluate the software-connected visualization using those nodes as the starting points.
- If any nodes are found that were not already included in the model definition:
- If the node was previously removed from the model, it stays removed.
- If the node is a new sibling of a removed Software Component or Database, it is added as a removed node in the model.
- Otherwise, the node is added as included in the model.
- If the model is published, the Business Application Instance node's top SoftwareContainment relationships and Host short-cut relationships are refreshed.
BMC Discovery keeps track of the changes it makes in this way. It creates Activity Records to represent the changes it makes. It also remembers which nodes in the model were saved by a user, and which were automatically added. You can use visualization background shading to display whether nodes were user-saved or automatically added. Choose Display > Background shading > Application Model updates:
In this example, you can see that a new server was added to the application, alongside the existing ones.
When a published model has a revision in progress, the published model and the pending revision are both automatically updated using the same rules. If the pending revision is quite different from the published model, the automatic updates can also be quite different between the two variants.
Sometimes, automatic model updates would change a model a great deal, either in one single change or as a result of a gradual expansion over time. When BMC Discovery detects that an update would cause a large change, it suppresses most of the change, and sets the application model into a state of Review Suggested.
A model enters the review suggested state if one of three things happens:
- The number of items in the model becomes more than twice the number that were present the last time the user saved the model
- More than 10 new items are newly connected to one single existing item
- The model becomes completely empty
Note that these are counts of items, not nodes. An item is something that is shown as a single icon in the visualization. It may be one node, or it may be a collection of many nodes, for example a SoftwareInstance containing a number of SoftwareComponents.
When the model enters Review Suggested, only new items directly connected to items that were previously in the model are added – any nodes down-stream of those new nodes are suppressed. This means that you may see fewer newly-added items than the thresholds. For example, if a SoftwareInstance in the model gains a new communication relationship to another SoftwareInstance, and that new SofwareInstance is in turn connected to 20 other items, the number of new items is 21, far more than the threshold of 10. The model enters Review Suggested, but only the one directly-connected SoftwareInstance is added to the model.
Once the model is in Review Suggested, Discovery no longer updates it during scanning. The same logic is used for published and unpublished models.
The visualization shows the nodes that were added at the time the model entered Review Suggested with a red highlight:
A Review suggested message is displayed with a more info link that provides general help on the review suggested state, and a changed link which shows the Activity stream at the bottom of the page.
In the Activity stream the associated Activity Record is highlighted and gives a summary of the nodes that were not added:
You must clear the Review suggested state to continue the model's automatic maintenance. To do this, click Review and enter the model editor. The editor also displays a Review suggested heading with a link to a popup dialog providing advice on common steps to resolve the Review suggested state. A useful tool when editing a model in the Review suggested state is the right-click Select all 'review suggested' nodes.
Once in the editor, there are a number of steps you could take, according to whether the new nodes belong in the application or not:
- Remove the added nodes from the model, by right-clicking an individual node and choosing Remove node, or by selecting a number of nodes before right-clicking and choosing Remove selected. The node, and the nodes down-stream of it will not be added again.
- Define a do-not-follow rule or never-show rule by right clicking on appropriate nodes. Any nodes that match the new rule will not be added to this or any other model definition in future.
- Right click on a newly added node and choose Force to shared. The node will be added to the model, but anything down-stream of it will not be.
- Explore the suppressed nodes that were not added by clicking the blue plus icon for an added node and, if need be, the plus icons of newly-displayed nodes. You may wish to remove some or all of the nodes from the model. Notice how when showing the background highlighting, nodes that are revealed this way do not have a background highlight, indicating that they are not currently part of the model.
Whatever actions you take inside the editor, once you Publish in a published model, or Save in an unpublished one, the Review Suggested state is cleared, and automatic updates of the model resume. On the next scan, other related nodes that were suppressed will be added or, depending on the condition that led to the Review Suggested state, the model may enter Review Suggested again, with another "layer" of new related nodes added.
Re-Evaluating a Model
BMC Discovery normally maintains application models automatically, so they should always be up to date with the current data. However, certain events such as changes to nodes that are considered shared, resolution of models in review-suggested without subsequent scanning, and upgrades from earlier releases, can mean that models are in a different state to how they would be if they were newly updated.
When editing a model, you can choose Actions > Re-evaluate model. That updates the model in the view according to the same rules as updates at scan time, calculating a new visualization with all the non-hosting nodes as starting points, except that it only starts from the nodes saved by the user. If the re-evaluated model is a better reflection of the application than the previous view, it can be published by clicking Publish, or saved for further edits with Save. If the previous view was preferable, click Cancel changes to discard the change.