Building a Business View

The views you create should provide the business users with logical representations of your company's structure, processes, and goals. To meet these requirements, you generally build multiple views representing different aspects of your business; for example, you could build business views that revolve around any of the following:

• Company structure, so that data is organized by the geographical location of branches, or by data centers.

• Business processes, so that data is organized by line of business, or by applications.

• Business goals, so that data is organized by sales, or by key customers.

The views depend on the particular demands of your organization and the actual hierarchical structure of the views should reflect those demands.

The usual hierarchical format of a view is as follows:

• Top level. The highest levels of the view, consisting of the root CI and the branches below it, are normally built from logical Business CI types such as Location, Line of Business, Customer, Application, and so on.

• Intermediate level. The intermediate branches of the view normally consist of System CI types, representing actual hardware and software and/or monitoring group CI types, representing groups containing monitors.

• Bottom level. The lowest level of the view, consisting of leaf CIs at the ends of the subtrees, is built from the Monitor CI types.

Note The bottom level is only relevant when a monitoring solution such as Business Service Management is connected and modeled in the CMDB.

The Pattern View Editor enables you to set the view hierarchy using the Hierarchy pane on the right side of the screen. There are two methods available for setting the hierarchy: Manual and Rule-based. The manual method is selected by default.

• Manual Hierarchy Method

  In the manual hierarchy method, the query nodes of the view are displayed in a tree format. You can create the hierarchy by manually dragging a selected query node under another query node or by using the toolbar buttons. The system only allows you to move a query node under another query node when the resulting hierarchy is valid. For details, see Hierarchy Pane.

  It is possible to place a single query node from the view into the hierarchy multiple times. You can then adjust the hierarchy so that the query node appears in different layers, according to the required layout. The view results in such an instance would be the same as if you added another query node to the TQL query. Using the same query node twice in the hierarchy enables you to achieve the desired view results using a simpler TQL query.

  Query Node Grouping

  When setting the view hierarchy manually, you can create subgroups to group CIs by different criteria for the convenience of viewing the display. Click the Add Group By button and select one of the options. You can create a subgroup for CIs of the same type in the Topology Map using the Add Group by CI Type option. You can create a subgroup for a specific query node by selecting the Add Group by View Node option. You can group CIs by a common attribute using the Add Group by Attribute button and entering a regular expression as described in Query Node Grouping Dialog Box. For details about regular expressions, see Regular Expression Examples.

  You can also create nested groups (a query node group inside another query node group) to help fine-tune the TQL query results that are displayed in the Topology Map.

  For example, after grouping query nodes of type node by their CIT, you can use their operation state attribute to create more focused groups.

• Rule-Based Hierarchy Method

  In the rule-based hierarchy method, you define hierarchy rules, using the Hierarchy Rules dialog box. You select a source CIT, target CIT, relationship type, and relationship direction, which define the conditions for a hierarchy rule. Any CIs in the view which satisfy the defined conditions are subject to the rule, that is, the target CI is placed on the layer below the source CI. For details on defining hierarchy rules, see Hierarchy Rules Dialog Box.

You can select to hide certain query nodes so they do not appear in the view results. The following options are available:

• Hide/Show Element in Query Results. These options are available by right-clicking a query node in the Query Definition pane. CIs matching a query node that is set as hidden are excluded from the query results. You cannot set all of the query nodes as hidden; at least one query node must be shown for the query definition to be valid.

• Set View Node Invisible/Visible. These options are available by right-clicking a query node in the Hierarchy pane. CIs matching a query node that is set as invisible are excluded from the view results. However, if a function is defined in the Report Layout pane, it takes invisible query nodes into account. For example, a Count function will include CIs corresponding to invisible query nodes in the total count.

  When a query node is set as invisible in the hierarchy, all of its descendants are automatically set as invisible. This enables you to hide an entire branch of the view results. The query definition cannot have visible query nodes under an invisible query node. When an invisible query node is set as visible, its descendants are not changed automatically.

  A valid hierarchy definition must have at least one visible query node, other than the root query node. The root query node can never be set as invisible.

When the TQL query is calculated, UCMDB first filters the query results by the Hide/Show Element in Query Results settings. The query results are then filtered again by the Set Query Node Invisible/Visible settings. The final view results reflect the combination of both filters and are displayed in IT Universe Manager, the Result Preview in Modeling Studio, and the topology report for the view in Reports.

You can view the data of any view in report format in the Reports module. Such a report is called the topology report of the view. You define the topology report settings in the Report tab of the Pattern View Editor in the Modeling Studio. For details on Topology Reports, see Topology Reports Overview.