This section describes how to do the following:

• Create and edit a view
  • Name and add a description for the view
  • Define the scope rule for a view to filter the items that it includes.
• Select a view from the set of views in the system, in order to manage the items in that view.
• Delete a view, to remove it from the system permanently.

The Views Page

Lifecycle Management views are displayed under the Change page in the Foundation UI.
To display a list of views:

1. Log in to the Foundation UI as a member of either the lifecycle-management-user or lifecycle-management-administrator groups.
2. Click the "Change" tab at the top-right of the display. If the "Change" tab is already selected, you can click "Manage Views" in the navigation bar below the large tabs instead.
   The following page is displayed:
   
   

This page is divided into two sections, "My Favorites" and "Other views", which together contain an entry for each view currently set up on the appliance.

Initially, only views in the first section are displayed. To show the remaining views, click the "(Show)" link next to "Other views".
Each user can have a different set of favorite views, and changing this set does not affect other users. You can mark any view as one of your favorites by clicking the "Add to Favorites" link next to it. A favorite view can be placed into the "Other views" section by selecting the "Remove from Favorites" link next to it.

The table below summarizes the details that can be displayed in the entry for each view.

A view can be edited or deleted using the "Edit" and "Delete" links shown next to a view. Editing a view is described in more detail in the following section.

The Edit and Delete links next to each view will only be shown to Foundation users who are members of the lifecycle-management-administrators group. See Permitting users to Access Lifecycle Management for more information.

Creating or Editing a View

Creating a new view and editing an existing view are similar operations carried out using the same page in the Lifecycle Management interface.

To open the page for creating a new view:

1. Log in to the Foundation UI, as a member of the lifecycle-management-administrator group.
2. Click the "Change" tab at the top-right of the display.
3. Click "Create View" in the navigation bar below the large tabs.

To open the page for editing an existing view:

1. Log in to the Foundation UI, as a user that is a member of the lifecycle-management-administrator group.
2. Click the "Change" tab at the top-right of the display. If the "Change" tab is already selected, you can instead click "Manage Views" in the navigation bar below the large tabs.
3. Locate the view you want to edit. If the view is not marked as one of your favorites, you will need to click "(Show)" next to "Other Views" in order to display all of the views on the appliance.
4. Click the "Edit" link on the right hand side of the view's details panel.

Editing a view and adjusting its scope rule can cause items to be permanently destroyed. This happens if the scope rules are changed and paths that used to be in the view being edited no longer are in that view.

There are two important differences between creating and editing a view. Creating a view involves creating new items for which connected sequences of nodes already exist in the Foundation data store, and associating items that already exist as members of other views with this view, if they share the view's type and satisfy its scope rule.

Editing a view performs both of the above activities, but if its scope rule is changed, items previously included in the view may need to be removed. This can cause those items associated with them to be permanently destroyed. For further information on the effect of deleting items, see Deleting a View.

Since changing a view's type means removing all of its items, and considering a completely different set of items to add, the view type cannot be changed once a view has been created.

The "Create new view" page is displayed below.

The table below summarizes the fields on this page.

View Types

A view's type determines the kind of dependencies the view will contain.

It defines the particular sequence of node and kinds of relationship whose connection in the Foundation data store triggers a potential dependency to be built.

The view type also determines what kinds of nodes must be linked, and in what order, for that dependency to be created.

A view type can constrain how items are built not just by defining the roles and relationships that may be followed from node to node, but by placing constraints on the attributes of the nodes at either end. This is just like "where" clauses in scope rules and Foundation search service queries. These constraints are fixed, although scope rules can be applied to views of these types as normal.

The dependency is built if a view with a corresponding view type exists and its scope rule is satisfied by that dependency. Every dependency has a single associated view type. This means that since a view contains dependencies of a single view type, two views with different view types can never contain overlapping sets of dependencies.

Dependencies that may appear to be the same or overlapping but that have different view types have entirely independent state. This means that alerts on them can be raised and cleared independently, they may be separately owned, and so on. Even if two view types were similar enough that a sequence of connected nodes could form a dependency in each, two separate dependencies would be created.

This release of Lifecycle Management supports five view types, described below. For further details of the node and relationship kinds included in each, see View Types.

Direct Application to Host Dependencies

This view type builds dependencies that represent direct dependencies between business applications and hosts. They record the relationship between applications and the underlying physical and virtual host resources without regard to particular pieces of software that allow these relationships to be inferred. Such views are useful for authorizing, monitoring and performing export control on the basis of application dependency maps. Items in this view follow this pattern:

< BAI - HostedSoftware - Host >

Full Application and Software Dependencies on Host and Cluster

This view type builds dependencies that trace out the containment and dependency relationships between business applications, running software, hosts and clusters. Views containing such dependencies are useful for fine-grained monitoring of application resource dependencies and for verifying and enhancing application models. Items in this view follow this pattern:

XXX BAI - SI - Host, virtual example, cluster example

Full software dependencies on host and cluster

This view type builds items that trace out the dependency relationships from software to the hosts, clusters and host containers on which it runs. It is identical to the "Full application and software dependencies on host and cluster" view except that the items it creates do not include or require BusinessApplicationInstances.

Views containing such items are useful for examining the footprint of software that has not been explicitly modeled as part of a business application. Items in this view follow this pattern:

SI -> [... -> sub-SI ] -> Host [ -> Cluster/HostContainer ]

Virtual host to physical host

This view type builds items containing virtual hosts, the virtualization software on which they depend, and in turn the physical host on which that runs. Views containing such items can be used to monitor the underlying dependencies of your virtualized infrastructure and constrain virtual machine sprawl. Items in this view follow this pattern:

Host -> Virtualisation SI -> Host

Host Only

This view type builds dependencies that correspond directly with individual hosts, without regard for their connections to the software or applications that they may run. Use this view type to create views for monitoring and performing export control from an infrastructure-only perspective.

Scope Rules

A view's scope rule can be used to filter the dependencies that a view contains by expressing constraints on the nodes that make up those dependencies. This means that you can use views to partition how the monitoring of change in the IT infrastructure is managed and how its associated data is exported. For example, scope rules may constrain a view's contents by geographic area, by production environment, or along lines of business.

Dependencies that do not match the view type and scope rule of any views on the appliance are never created. This has the advantage that system resources are saved on maintaining dependencies in which users have no interest.

A scope rule is a simple list of zero or more requires statements, whose format is described below. A requires statement checks that nodes and relationships of a particular kind are present in the dependency, and can also apply an optional where clause, which is identical in syntax to a Foundation search service where clause.

To apply multiple conditions to different types of node or relationship, list them one after the other. If you supply multiple conditions, a dependency will be required to match all of them: that is, the clauses form a logical and.

An empty scope rule is valid, and matches all dependencies. In this case, the view will contain all dependencies of that view type that could be created from the Foundation data store.

You may only specify at most one requires statement for each node or relationship kind: use the Boolean operators and, or and not in a where clause to combine multiple conditions on a single kind.

A requires statement for a particular node kind or relationship kind must match every node of that kind in a dependency for that dependency to be included in a view. For example, when a dependency includes both a virtual host and its underlying physical host, a requires statement for hosts must match both hosts in the dependency for the dependency to be included in the view.

Notation:
Square brackets [] mean optional components, a|b means "a or b not both".

The format of a requires statement is:

requires [unchecked] nodekind|relationshipspec [where whereclause ]

In these statements nodekind|relationshipspec must be one of the following:

• A single node kind, e.g. Host.
  The requires statement means that for the scope rule to match a dependency, a node of that kind must exist among the dependency's components, and if a where clause is specified, every node of that kind in the dependency must match it.
• A single relationship specification of the format kind:role:rel:role:kind.
  The kind fields refer to kinds of the two nodes that relationship links, and role to their corresponding roles in the relationship. Leaving the role and kind fields blank means they act as wildcards. The dividing colons must be included in all cases. The relationship kind rel must be supplied.
  The requires statement means that for the scope rule to match a dependency, a relationship of the given kind rel must exist among the dependency's components, and any supplied kinds and roles must also match. If a where clause is specified, every relationship of that specification in the dependency must match it.
  The optional where clause has the same format as a Foundation search service where clause, with only a few exceptions:
• The clause body after the where keyword must be enclosed in round brackets.
• Some use of key expressions and nodecount expressions can cause unexpected results - see the discussion in Evaluation of Scope Rules.

The optional keyword unchecked is described in the following section.

Scope Rule Examples

This section gives a number of example scope rules that satisfy some common filtering requirements for views.

Note: For further information on the Foundation Search Service and how to apply conditions using where clauses, see the Search and Reporting Service document.

Filtering by Infrastructure Properties

The scope rules in this section can be used to match dependencies on the basis of the properties of their infrastructure components. They express these conditions in terms of the Host node kind. Because all three of Lifecycle Management' supported view types require a Host in order to form a dependency, these scope rules are suitable for each of them.

Scope rules evaluating simple Host attributes:

• Dependency must include a host, and all hosts in dependency must be running Unix-variant operating systems:

  requires Host where os_class = "unix"

• Dependency must include a host, and all hosts in dependency must be running a variant of Linux

  requires Host where os_type has subword "linux"

  Scope rules evaluating Host network connectivity:

• Dependency must include a host, and all hosts in dependency have multiple network interfaces

  requires Host where nodecount (traverse :::NetworkInterface) > 1

• Dependency must include a host, and all hosts in dependency are attached to a specific switch or switches

  requires Host where nodecount (traverse :::NetworkInterface traverse :::PortInterface traverse :::Switch where name = "MySwitch")

• Path must include a BusinessApplicationInstance, and each must have a type matching the given value

  requires BusinessApplicationInstance where type has subword "Oracle"

• Path must include a BusinessApplicationInstance, and each must have a given name, and its version must be 7.0 or greater

  requires BusinessApplicationInstance where type has subword "Foundation" and version >= "7.0"

• Path must include a SoftwareInstance, and each must have a given type.

  requires SoftwareInstance where type has subword "Foundation Discovery Service"

• Paths must include a SoftwareInstance marked as a transient process or maintained by a pattern with explicit removal criteria.

  requires unchecked SoftwareInstance where transient or __explicit_removal

  Scope rules evaluating Host virtualization:

• Dependency must include a host, and all hosts in dependency must be virtual (but see note below).

  requires Host where (virtual)

• Dependency must include a host, and all hosts in dependency must either be a VMWare virtual machine or a physical host.

  requires Host where (not virtual or #ContainedHost:HostContainment:HostContainer:SoftwareInstance.type has subword "vmware")

The "Full application and software dependencies on host and cluster" view type can include dependencies showing the dependency of a virtual host on the software providing its virtual machine platform and on its underlying host. Dependencies may display multiple nested levels of virtualization representing virtual machines running in other virtual machines. Since a requires statement, if present, is applied to all nodes of a kind in the dependency, scope rules may need to take care to express conditions that apply to both the virtual and physical host or distinguish between them by testing the virtual attribute or using the fact that the final, physical host does not have a HostContainment relationship linked to it. This is illustrated in the examples above.

Filtering by Software or Business Application Properties

The scope rules given below can be used to match dependencies on the basis of the properties of their software or business application components.

Evaluating attributes of BusinessApplicationInstance nodes:

• Dependency must include a BusinessApplicationInstance, and each must have a type matching the given value:

  requires BusinessApplicationInstance where type has subword "Imagine"

  This example would match any version and any edition of Imagine, including ones for which a version could not be identified.

• Dependency must include a BusinessApplicationInstance, and each must have a given name, and its version must be 7.0 or greater:

  requires BusinessApplicationInstance where type has subword "Foundation" and version >= 7.0

  The following scope rules express a condition on SoftwareInstance nodes:

• Dependency must include a SoftwareInstance, and each must have a given type:

  requires SoftwareInstance where type has subword "Foundation Discovery Service"

• Dependencies must include a SoftwareInstance marked as a transient process or maintained by a pattern with explicit removal criteria:

  requires SoftwareInstance where transient or __explicit_removal

Requiring a SoftwareInstance node means that, without modification, they suit only views using the "Full application and software dependencies on host and cluster" view type. However, it is possible to use key expressions to test conditions on nodes that are not directly included in a dependency.

In order to demonstrate this, the following example transposes the above scope rules to be a condition on "BusinessApplicationInstance" nodes using a nodecount clause. This means that it is suitable for views using the "Direct application to host dependencies" view type. The Host network connectivity examples above are further examples of this.

• Dependency must include a BusinessApplicationInstance, composed of a SoftwareInstance with the given type:

  requires BusinessApplicationInstance 
  where nodecount (traverse :::SoftwareInstance where type has subword "Foundation Discovery Service")

See the discussion in the next section on using key expression and nodecount expressions in scope rules.

Validating Scope Rules

Whenever a user attempts to create or edit a view, Lifecycle Management validates the scope rule. It performs a number of checks:

• First, it ensures that the scope rule is syntactically valid. An empty scope rule is valid.
• Second, each requires expression is evaluated to check that it refers only to elements that are present in Foundation's taxonomy.
  • If the requires expression refers to a node kind, it ensures that it exists.
  • If the requires expression refers to a relationship specification, it ensures the relationship kind and any specified node and role kinds exist.
  • Finally, if the requires expression has a where clause, it attempts to verify that any attribute it specifies is valid for the given node or relationship kind.

If any of these validation steps fail, you will not be able to apply the changes until you have resolved the problem. Details of the error will be displayed on the page.

If you intend to set up scope rules that refer to attributes or node kinds not present in the Foundation Taxonomy, you may use the unchecked keyword after the appropriate requires keyword in order to skip these validation checks.

Evaluation of Scope Rules

Scope rules are evaluated in two ways:

• At the point changes to Foundation's data store mean that a new dependency could be created. The scope rules of those views are evaluated. The dependency is associated with each of the views whose scope rule matches.
• When a new view is created, or an existing view edited, all dependencies that share its view type, and any dependencies that could have been previously created had a suitable view existed, are evaluated using the view's scope rule, and added to the view if they match.

Scope rules are currently evaluated only when nodes and relationships are created or unlinked in the Foundation data store. They are not re-evaluated when attributes on nodes are updated.

This means that views may contain dependencies that originally matched its scope rule when the dependency was first created, but no longer do so.

Similarly, a dependency that when first created was not associated with a view may be updated in such a way that means their conditions would have matched that view's scope rule but the dependency will not be added to the view.

Editing a view, even without explicitly changing its scope rule, reconciles its contents and adds or removes (as appropriate) dependencies that fall into these categories.

If a scope rule uses key expressions or nodecount expressions containing traversals, a dependency will only match the scope rule if those conditions hold at the time that a dependency is considered to be created or becoming a member of the view.

The following example shows a view with "Host only" view type and the following scope rule:

requires Host where nodecount (traverse Host:HostedSoftware:RunningSoftware:BusinessApplicationInstance where type = "...")

The intended result is to contain dependencies corresponding to single Host nodes running a specific business application.
However, when Foundation creates the Host node as a result of discovery, it has yet to evaluate the software running on it. It makes inferences about the applications that the software constitutes. This means that the above scope rule causes dependencies to be added to the view when performed manually by the user - only at a point when those applications exist.

Note: It is safe to refer to a Host from a SoftwareInstance and to a Host or SoftwareInstance from a BusinessApplicationInstance from within key expressions or nodecount expressions in scope rules.

Deleting a View

A view can be deleted using the "Delete" link shown next to its entry on the "Manage views" page. After selecting the link, a confirmation dialog will be presented that requires you to confirm the deletion.

Deleting a view causes the view to be removed from the appliance. This has the following effects:

• The storage associated with the view is freed and it is no longer visible to any user on the "Manage views" page, or using the Foundation search UI, regardless of whether it was a favorite of theirs.
• Any dependency that was a member of that view but not of any other view is deleted and its storage is freed. All other dependencies are retained.

Note that deleting a dependency never deletes any of its dependency components, so the Foundation nodes that made up the dependency (for example a SoftwareInstance or Host node) are retained. However, the state of the dependency itself is lost. This means if a view with the same view type and scope rule is recreated, an equivalent dependency will be created but its alert status, authorization state, provenance, history will be as for a new dependency.

• As a result of deleting one or more dependencies, there may be notes that are no longer associated with any dependencies. These notes and all of their entries are deleted.

You cannot undelete a view once it has been deleted, nor can you recover any dependencies destroyed or notes deleted as a result.

Audit Logging for Lifecycle Management Views

Every time a view is created, updated or deleted in Lifecycle Management, a log entry is created in Tideway Foundation.
Lifecycle Management view audit log entries have the same event group (LifecycleManagement). The audit entries contain the following "Standard details":

• Event – e.g. Create LMView
• Event Group – LifecycleManagement
• User – e.g. system
• When – e.g Wed Oct 31 15:56:28 2007
• Summary – e.g. LifecycleManagement view, called MyAceView, created

Full Name and User Groups are not populated.
Additional information about the view is stored in the audit entry. Attributes included from the view are:

• Description - the view's current description.
• Name - the name of the view.
• Populated State - valid values are Not Populated, Populating, Populated or Unknown.
• Scope rule - the view's current scope rule.
• Modified date - only included if this value is set on the view.

Auditing for View Creation

On creating a view, an audit entry of event type Create LMView is created.

Auditing for View Editing

On editing a view, an audit entry of event type Alter LMView is created.

Auditing for View Deletion

On deleting a view, an audit entry of event type Delete LMView is created. The additional details for the deleted view will include:

• Name
• Populated state
• Scope rule
• Last modified date (if valid)

For further information about logging in Tideway Foundation, see Appliance Audit.