How to create custom reports in BMC Capacity Optimization...PAGE 1 OF 54 CONFIDENTIAL BMC Capacity Optimization How to create custom reports in BCO Table of Contents Legal Notice _____6

BCO how-to guides

How to create custom reports

in BMC Capacity Optimization

April 2012

PAGE 1 OF 54 CONFIDENTIAL

BMC Capacity Optimization How to create custom reports in BCO

Table of Contents

Legal Notice ________________________________________________________________________________________ 6

Document Information ________________________________________________________________________________ 6

Document Scope ____________________________________________________________________________________ 6

Acknowledgements __________________________________________________________________________________ 6

Introduction ________________________________________________________________________________________ 8

Example 1: List top 20 systems by Memory utilization _____________________________________________________ 9

The problem ........................................................................................................................................................................ 9

The solution ......................................................................................................................................................................... 9

Step 1 – define the Data Source ......................................................................................................................... 10

Step 2 – define the Data Sets ............................................................................................................................. 11

Step 3 – define the layout ................................................................................................................................... 13

Step 4 – install the report template ...................................................................................................................... 14

Step 5 – executing the report .............................................................................................................................. 16

Example 2: Count systems by number of CPU ___________________________________________________________ 17

The problem ...................................................................................................................................................................... 17

The solution ....................................................................................................................................................................... 17



Step 3 – defining the layout ................................................................................................................................. 19



Example 3: Report systems that are expected to saturate _________________________________________________ 26

The problem ...................................................................................................................................................................... 26

The solution ....................................................................................................................................................................... 26






Example 4: Report on under-/over-utilization systems ____________________________________________________ 39

The problem ...................................................................................................................................................................... 39

The solution ....................................................................................................................................................................... 39

Step 1 – defining custom statistics ...................................................................................................................... 39

Step 2 – defining AR views ................................................................................................................................. 41








Appendix A: PV_SYS_DATA_ROLL ____________________________________________________________________ 50

Acronyms _________________________________________________________________________________________ 51

References ________________________________________________________________________________________ 52



Table of Figures

Figure 1 – Basic and Advanced Reports .................................................................................................................................. 8

Figure 1 – Setting the value of the Data Source URL and credentials ................................................................................... 10

Figure 2 – Setting the value of the jbdcurl parameter ............................................................................................................. 10

Figure 3 – Setting the value of the jbdcurl parameter ............................................................................................................. 11

Figure 4 – Defining the Query in the Data Set ........................................................................................................................ 12

Figure 5 – Data Set parameters used to test the SQL query.................................................................................................. 12

Figure 6 – Data Set parameters referring to report template parameters ............................................................................... 13

Figure 7 – Report layout from the BCO Integration Studio ..................................................................................................... 13

Figure 8 – Report layout from the BCO Integration Studio ..................................................................................................... 14

Figure 9 – Installing the report template: uploading report template (“rptdesign” file) ............................................................ 14

Figure 10 – Installing the report template: specifying data parameters .................................................................................. 15

Figure 11 – Installing the report template: specifying report (run-time) parameters ............................................................... 15

Figure 12 – Report parameter(s) as specified at run-time ...................................................................................................... 16

Figure 13 – Multiple instances of the report with its parameter values as specified at run-time ............................................. 16

Figure 14 – PV_SYS_CONF_LAST and PV_SYS_CONF_VARIATION Public Views (as seen from Oracle Developer) ...... 17

Figure 15 – Defining the Query in the Data Set ...................................................................................................................... 18

Figure 16 – Defining report template parameters ................................................................................................................... 18

Figure 17 – Defining the Display Name for Data Set output columns .................................................................................... 19

Figure 18 – Report layout from the BCO Integration Studio ................................................................................................... 19

Figure 19 – Outline of the report layout .................................................................................................................................. 20




Figure 23 – PDF format showing the defined Bookmarks ...................................................................................................... 22

Figure 24 – Select Data tab in the Chart definition ................................................................................................................. 22

Figure 25 – Specify Interactivity properties in the Chart definition .......................................................................................... 23



Figure 26 – Preview mode from the BCO Integration Studio showing the interactivity of the chart legend ............................ 23

Figure 27 – Installing the report template: specifying report (creation-time) parameters ........................................................ 24

Figure 28 – Installing the report template: specifying report (creation-time) parameters ........................................................ 24

Figure 29 – Multiple instances of the report with values specified at run-time ........................................................................ 25

Figure 30 – Data Sets defined for the report template ........................................................................................................... 26

Figure 31 – SQL query used in the first Data Sets of the report template .............................................................................. 27

Figure 32 – Data Set parameter linked to the corresponding report parameter ..................................................................... 27

Figure 33– SQL query used in the first Data Sets of the report template ............................................................................... 28

Figure 34 – SQL query used in the second Data Sets of the report template (as seen in the Oracle Developer client) ......... 29

Figure 35 – Data Set parameters as linked to report template ............................................................................................... 30

Figure 36 – time_interval parameter defined as hidden ......................................................................................................... 30

Figure 37 – Preview Results for the second Data Set ............................................................................................................ 31

Figure 38 –Report layout showing the report parameters and the Group Table structure ...................................................... 31

Figure 39 – Highlights defined on DAYS_LEFT_H ................................................................................................................. 32

Figure 40 – Formatting values (e.g. PCTILE75_H) as percentile values ................................................................................ 32

Figure 41 – Mapping DAYS_LEFT_H in case of “null” value.................................................................................................. 32

Figure 42 – Mapping rule for DAYS_LEFT_H from “null” value to “saturated” ....................................................................... 33

Figure 43 – Mapping rules for SLOPE_H to readable trend values ........................................................................................ 33

Figure 44 – Highlights defined on DAYS_LEFT_H (the select rule is for “null” values) .......................................................... 34

Figure 45 – Highlights defined on DAYS_LEFT_H (see comparison to ) ............................................................................... 34

Figure 46 – Dynamic Text in the Table Footer ....................................................................................................................... 34

Figure 47 – definition of the Dynamic Text in the Table Footer .............................................................................................. 35

Figure 48 – visibility property for the dynamic label in the Table Footer ................................................................................. 35

Figure 49 – report page for sub-domain with no systems predicted to saturate ..................................................................... 35

Figure 50 – report page for sub-domain with systems predicted to saturate .......................................................................... 36

Figure 51 – report page for sub-domain with systems already saturated ............................................................................... 36

Figure 52 – Installing report template: creation-time parameters ........................................................................................... 37



Figure 53 – Installing report template: run-time parameters ................................................................................................... 37

Figure 54 – Generated report with specified run-time parameters ......................................................................................... 38

Figure 55 – MONTHLYCPU95PCT custom statistic created by selecting “Add stat” in the “Rule-based statistics” section ... 40

Figure 56 – Definition of the MONTHLYCPU95PCT custom statistic ..................................................................................... 40

Figure 57 – Where to activate the data recovery for the MONTHLYCPU95PCT custom statistic .......................................... 41

Figure 58 – Analysis used to define AR Views: Entity Filter and the time resolution parameters ........................................... 41

Figure 59 – Analysis used to define AR Views: Time Filter and resource filter ...................................................................... 42

Figure 60 – Analysis used to define AR Views: standard and custom statistics ..................................................................... 42

Figure 61 – AR View definition: associated analysis and materialized task (notice that the option to not limit the number of

rows and series needs to be selected when in Advanced Mode) ....................................................................... 43

Figure 62 - AR View definition: column mapping to required (standard and custom) statistics .............................................. 43

Figure 63 – Enterprise Reporting Materialized task as seen from the System Task list ......................................................... 44

Figure 64 - AR View definition: column mapping to required (standard and custom) statistics .............................................. 44

Figure 65 - AR View as listed in the Analysis/Model view list (with the associated name of the physical view) ..................... 44

Figure 66 – The query provided by the AR view used as a Data Set in the report definition .................................................. 45

Figure 67 – Data Set parameters and their correspondence to report parameters ................................................................ 46

Figure 68 – Report layout as seen from the BCO Integration Studio ..................................................................................... 47

Figure 69 – Expression used in the table footer (for the system with a normal range of CPU utilization) .............................. 47

Figure 70 – Report template with reference data is ignored (as it is provided as specific parameter) .................................... 48

Figure 71 – Report template with reference data is set to “Last month” ................................................................................. 48

Figure 72 – Report template with high_watermark and low_watermark as creation parameters (with their assigned default

values: 85% and 30% respectively) .................................................................................................................... 49



Legal Notice

The information contained in this document is the confidential information of BMC Software, Inc. and is being

provided to you with the express understanding that without the prior written consent of BMC, you may not

discuss or otherwise disclose this information to any third party or otherwise make use of this information for any

purpose other than for which BMC intended.

Document Information

Table 1. Document Information

Version Created/modified by Affiliation Date Description

1.0 Giuseppe Nardiello BCO Product Team January 2012 First Version

2.0 Giuseppe Nardiello BCO Product Team March 2012 Second Version

2.2 Giuseppe Nardiello BCO Product Team April 2012 Third Version (published)

Document Scope

This document intends to describe how to create custom reports in BMC Capacity Optimization (BCO) by

discussing some sample reports and real-life cases that have been implemented by the author while working

with some customers. Reports are presented in order of increasing complexity in terms of knowledge of the BCO

schema, SQL statements and of usage of the BCO Integration Studio.

Notice that this document is not intended as a replacement to BCO official manuals. Therefore users are strongly

encouraged to read these manuals beforehand and in case to consult them while reading this document. In

addition to BCO documentation, there are also several useful resources on the Internet on how to create BIRT

reports.

BCO reference version

All cases presented here have been implemented in BCO 4.5 and unless otherwise specified do not require

additional Service Packs or patches to be installed.

Notice that all report templates have been created using the BCO Capacity Optimization templates in order to

some of the functionalities discussed in this document.

Acknowledgements

The author would like to acknowledge the support from BCO Product Team during his work with the BCO

customers that provided the base for this document. In particular, he would like to thank Emanuele Marcora for

providing the initial intro to BCO Integration Studio and additional tips afterward and Alessandro Trolli for

providing help on how to code some more complex SQL statements.



“Why a four-year-old child could understand this report.

Run out and find me a four-year-old child. I can't make head nor tail out of it.”

Groucho Marx

http://thinkexist.com/quotation/why_a_four-year-old_child_could_understand_this/207995.html

http://thinkexist.com/quotation/why_a_four-year-old_child_could_understand_this/207995.html



Introduction

Reports generated by BMC Capacity Optimization (BCO) can be classified as either Basic Reports or Advanced

Reports (see also the following figure):

Basic Reports can be generated from any set of analysis and model scenarios thanks to the “add to the

report cart” feature; the look & feel of Basic Reports allow a limited level of customization (e.g. the company

logo) and their content is displayed similarly to the corresponding charts from analysis and model scenarios.

Advanced Reports can be created using BCO Development Studio, an Integrated Development Environment

(IDE) based on Eclipse, that allows users to create Report Templates where both the report content and

their look & feel can be customized as required; BCO provides a number of out-of-the-box Report

Templates; custom Report Templates can be uploaded in a BCO environment to be made available to users

to create their Advanced Reports.

Both Basic and Advanced Reports can be generated manually or scheduled to be generated automatically and

possibly send by mail (as by-exception reports as either links or attachments). BCO reports can be generated in

different formats.

Figure 1 – Basic and Advanced Reports

Notice that since Advanced Reports are based on BIRT (Business Intelligence Reporting Tool) technology, they

are also referred as “BIRT Reports” in both the user interface and the manuals. Since BCO Development Studio

integrates BIRT Report Designer the documentation available (see references at the end of this document) on

how to design BIRT reports can be used also to design BCO Advanced Report templates.



Example 1: List top 20 systems by Memory utilization

This first example illustrates how to use BCO Public Views to get values for performance metrics and to list

systems belonging to a specific BCO domain. This example is also is useful to get acquainted with BCO

Integration Studio concepts, in particular Data Sources, Data Sets and report template parameters.

The problem

The problem can be stated as follows: “Create a report that displays the top 20 systems belonging to a domain

provided as parameter with respect to the average memory utilization (over daily samples) for a period of one

month”.

The solution

The solution to this problem consists in creating a custom report template created from BCO Integration Studio.

This report template can then be uploaded and executed (as on-demand or scheduled report) from the BCO

console.

Notice that in order to be able to leverage some of the functionalities described below (such as binding Data

Source parameters that are already defined), the standard BCO Capacity Optimization template (see the

following figure) needs to be used. This is assumed to be the case for all the examples described in this

document.

Figure 2 – Selection BCO Capacity Optimization Template when creating a new report template



Step 1 – define the Data Source

In the following we assume basic knowledge of BCO Integration Studio concept and interface. However, for this

first example we remind the reader that a Data Source has to be defined by setting the specific JDBC URL and

credentials to BCO database (see the following figure) to be used to preview the Data Sets defined in the report

template.

Figure 3 – Setting the value of the Data Source URL and credentials

Also the specific “jdbcurl” report parameter needs to be set to the BCO database (possibly a different database,

but usually the same) to be used to run the report template from the BCO Integration Studio (see the following

figure).

Figure 4 – Setting the value of the jbdcurl parameter



Notice that the value of the “jdbcurl” parameter is automatically replaced at execution time by the values set for

the connection to BCO database (General tab in the ADMINISTRATION>SYSTEM>Configuration page in the

BCO Console) once the report template is uploaded in the BCO environment.

Step 2 – define the Data Sets

The query that provides the data to be displayed in the report can be implemented in different ways. In this initial

example the SQL query will leverage the following BCO Public Views:

PV_SYSTEM: describes all BCO managed systems (and business drivers);

PV_SYS_METRIC: describes all BCO metrics for managed systems;

PV_APPL_SYS: describes all containment relationships (one level) between BCO managed systems

and domains;

PV_APPLICATION: describes all defined BCO domains;

PV_SYS_DATA_D: contains samples at daily resolution for all BCO managed entities and systems.

Even for defining simple SQL queries it is suggested to first use a SQL Client (as the Oracle Developer shown in

the following figure) that offer a more user-friendly editor run environment.

Figure 5 – Setting the value of the jbdcurl parameter



Otherwise, this SQL query can be directly coded into a Data Source with its associated parameters (see the

following figure).

Figure 6 – Defining the Query in the Data Set

In particular, for in this example there are three parameters: one “domain” referring to the domain of interest (to

be provided at either installation time or more likely at execution time – see the installation step below) and two

“now_1” and “now_2” both referring to the starting date of the month period. Notice that two parameters are

required as the same parameter cannot occur in two different places in the Data Set.

When testing Data Sets, parameters values can be specified directly in to the Parameter tab of the Data Set

definition.

Figure 7 – Data Set parameters used to test the SQL query

After the testing phase, Data Sets parameters can be set to refer (see the following figure) to report parameters

tab (notice that parameters in the Data Sets and in the report template can have different labels – for simplicity



sake it is however recommended to not use different labels for the same attribute). In any case, default values

can also be set for the report template parameters.

Figure 8 – Data Set parameters referring to report template parameters

Step 3 – define the layout

The detail description of how to define the layout is outside the scope of this document (please refer to manuals

and other documents mentioned at the end of this document), that is more focused on explaining how to define

the business logic of custom reports. However, in the followings we will provide some hits and illustrate some of

the (basic and advanced) features provided by Integration Studio.

In this specific case, a simple table to bind the Data Set outputs (see the following figure) could be adequate.

Figure 9 – Report layout from the BCO Integration Studio

The only detail that it is worth describing at this point is the ability (see the following figure) to specify the order of

the entries in the table (in this case descending with respect to the average memory utilization).




Step 4 – install the report template

The final step consists in installing the report template from the BCO console (section “ADMINISTRATION>

Report templates” by selecting the action “Add report template”: see the following figure).

Figure 11 – Installing the report template: uploading report template (“rptdesign” file)



Once the “rptdesign” file is uploaded, the report parameters needs to be specified: the report reference date in

this case being automatically specified (see the following figure),

Figure 12 – Installing the report template: specifying data parameters

while the domain being specified as either a creation parameter, that is set when creating a new report from this

template, or as an execution parameter, that is to be specified a run-time by the end user (see the following

figure describing this option).

Figure 13 – Installing the report template: specifying report (run-time) parameters



Step 5 – executing the report

Therefore, when executing a new report instance from this new report template this parameter will be visualized

to the user (see the following figure)

Figure 14 – Report parameter(s) as specified at run-time

and, of course, will also displayed for the different generated instances of the report (see the following figure).

Figure 15 – Multiple instances of the report with its parameter values as specified at run-time



Example 2: Count systems by number of CPU

This second example illustrates how to use BCO Public Views to get the full list of server that belong to

forecasted values for performance metrics. This example is also is useful to get acquainted with some more

advanced presentation features of BCO Integration Studio such as the ability to re-label column names, define

Groups and Aggregations, insert bookmarks and insert graphical (and interactive) charts.

The problem

The problem can be stated as follows: “Create a report that displays the number of systems by number of CPUs

in the last number of months (this number being provided as parameter) and includes a summary chart”.

The solution

Also in this case, the solution to this problem consists in creating a custom report template created from BCO

Integration Studio. This report template can then be uploaded and executed (as on-demand or scheduled report)

from the BCO console.


This step is the same described for the previous example.


Notice that configuration metrics are stored in a different way than performance metrics as their samples are not

supposed change frequently. More precisely, there are two Public Views for configuration metrics (see the

following figure): one (PV_SYS_CONF_LAST) that stores the last collected value for the configuration metric

and another (PV_SYS_CONF_VARIATION) that stores all the changes as assigned to as specific time ranges.

Since this specific example needs to display changes over time, this second Public View is the one to be used.

Figure 16 – PV_SYS_CONF_LAST and PV_SYS_CONF_VARIATION Public Views (as seen from Oracle Developer)

Therefore the following BCO Public Views will be used:

PV_SYS_CONF_LAST: describes all changes for all BCO configuration metrics of all managed systems;



PV_SYS_METRIC: (already used in the previous example) describes all BCO metrics for managed

systems.

Figure 17 – Defining the Query in the Data Set

Notice that this query uses nested tables to generate the list of month names starting from the current month

back to as many months specified by the report parameter “nmonths_back” (see the following figure).

Figure 18 – Defining report template parameters

Notice that an additional parameter could be added to allow the report to be run against a specific domain. Of

course, that would also require changing the Data Set accordingly.



Notice that this Data Set also redefines the displayed name of the output columns (see the following figure) to

make easier the layout definition.

Figure 19 – Defining the Display Name for Data Set output columns

Step 3 – defining the layout

The report layout for this example is structured as follows (see the following figure): a summary chart and one or

more tables, each one displaying the values for each of the specified months in a separate page.




The layout of this report is clarified by the following figure that displays its outline (on the left hand side). This

figure also shows the definition of a (Table) Group (“NewTableGroup1”) on the Table structure and its four rows:

the table header (#1), the group header (#2), table detail (#3) and footer table (#4). The Property Editor tab

shows that the Table Group is defined (“Key expression”) on the TS column (representing the month name).

Figure 21 – Outline of the report layout

The definition of the Table Group is also shown in the following figure.




In order to display the total number of CPUs per each month, an Aggregation (see the following figure) has been

defined as the SUM of all the CPUNUM values in that Table Group (as shown in the Bindings tab of the Property

Editor). The aggregated values are displayed in the table (group) footer.


Finally, Bookmarks are added to the Table Group header that is displaying the different month names.


Bookmarks allow an easy way to browse (long) reports (see the following figure showing the PDF format of this

report) and can also be used to make reports more interactive, as explained in the following.



Figure 25 – PDF format showing the defined Bookmarks

Finally, the report layout includes a graph that has been created by selecting the Chart Type (“line”), Data (see

the following figure where the Y-series grouping option is also set to the TS column to allow multiple series to be

displayed (one for each month) and the format of the chart.

Figure 26 – Select Data tab in the Chart definition



In particular the format of the chart allows to specify that the interactivity of the Chart Legend (see the following

figure), that is to specify that on mouse click the specific page and table for the corresponding month needs to

be displayed.

Figure 27 – Specify Interactivity properties in the Chart definition

The behavior is displayed in the following figure (in preview mode from BCO Integration Studio): the mouse over

one of the month names shows the tip describing the action performed by the mouse click on the legend.

Figure 28 – Preview mode from the BCO Integration Studio showing the interactivity of the chart legend




The installation step for this report template is similar to what described for the previous example. For example

the following figure shows this report template being installed by specifying the report parameter to be set at

creation time.

Figure 29 – Installing the report template: specifying report (creation-time) parameters

The following figure shows one of the steps from the report creation wizard

Figure 30 – Installing the report template: specifying report (creation-time) parameters




The following figure shows that report instances do not display the value of the report parameter as it is does not need to be provided at execution time.

Figure 31 – Multiple instances of the report with values specified at run-time



Example 3: Report systems that are expected to saturate

This third example illustrates how to use BCO Public Views and a specific BCO table that provides rolling robust

linear forecast values for different useful statistics. This example is also is useful to show how multiple Data Set

can interplay and to explore additional features that are available to make the output of summary tables more

readable.

The problem

The problem can be stated as follows: “Create a report that displays all systems belonging to all sub-domains of

a given domain (provided as parameter) that are predicted to saturate with respect to the 75th percentile of their

CPU utilization in the next following 200 days”.

The solution

Notice that for the previous problem, a possible solution is represented by a basic report created from a standard

Time Forecast Model. However, a solution based on a custom report template created from BCO Integration

Studio can provide more flexibility (without requiring custom statistics to be added to BCO Data Warehouse).


This step is the same described for the previous examples.


For this report template, two different Data Sets are required (see the following figure): i) one returning all the

sub-domains of the domain provided as parameter and ii) another returning all the systems in a specific sub-

domain whose CPU utilization is predicted to saturate according to the defined criteria. As expected, the sub-

domains (their identifiers) returned by the first Data Set are used to define the where condition of the second

Data Set.

Figure 32 – Data Sets defined for the report template

The first Data Set is quite simple (as shown in the following figure) as it uses the following two Public Views:



PV_APPLICATION: (already used in the first example) describes all defined BCO domains;

PV_ENT_PARENTSHIP_CURRENT: describes the current relationships between BCO domains.

Figure 33 – SQL query used in the first Data Sets of the report template

The only parameter used in this Data Set is defined as linked to a corresponding report paramter (see the

following figure). All report paraterms are described in the following.

Figure 34 – Data Set parameter linked to the corresponding report parameter

The second Data Set is more complex as it involves using in addition to the following Public Views:

PV_SYSTEM: (already used in the first example) describes all BCO managed systems;

PV_SYS_METRIC: (already used in both the first and the second examples) describes all BCO metrics

for managed systems;

PV_APPL_SYS: (already used in the first example) describes all containment relationships (one level)

between BCO managed systems and domains;



PV_APPLICATION: (already used in the first example and in the previous Data Set): describes all

defined BCO domains;

also the following BCO table SYS_DATA_ROLL, whose structure is described by the following figure. Notice that

in BCO 4.5 SP2 and subsequent versions a corresponding Public View (PV_SYS_DATA_ROLL) is also made

available. In general, it is highly recommended to use Public Views as they provide a consistent interface across

BCO versions, it is suggested to create to upgrade BCO or to manually create this Public View using the script

provided in the Appendix A (notice that some columns can have a different name from what described here).

Figure 35– SQL query used in the first Data Sets of the report template

For this example, the key columns of this table/view are:

PCTILE75 (and similarly the other PCTILENN columns) represents the values for the 75th percentile of

the metric specified by SYSOBJID (to be joined to PV_SYS_METRIC.SYSMETRICID); notice that only

some specific metrics are provided in the SYS_DATA_ROLL table (and corresponding

PV_SYS_DATA_ROLL Public View);

TS is the timestamp representing the beginning of the rolling period;

ROLLPERIOD represents the rolling period (in days) used for calculating all statistics; notice that in the

current version of BCO only a 30 days rolling period is available;

SLOPE represents the slope of the linear regression line; notice that if Oracle Java Options are activated

on the BCO Database Server then this linear regression is robust (that is it automatically filters outliers);

DURATION represents the time interval (in seconds) effectively used for the linear regression; this can

be used to evaluate the reliability of the prediction based on the number of samples;

UPDATETS represents the timestamp associated to last time values where refreshed; this can be used

to evaluate the reliability of the prediction, based on the availability of new data into BCO.



Moreover in the query, the function get_days_to_saturation/3 that provides the number of days left until reaching

the saturation, given the actual value (e.g. the 75th percentile), the slope of the regression line and the threshold.

Notice that when the number of days to saturation is returned as “null”, the corresponding system is already

saturated. In this example, the SQL query also returns systems that are already saturated as the problem

specified before does not clarify whether they need to be filtered out.

The resulting query is illustrated by the following figure taken from Oracle SQL Developer. As suggested in the

first example, an SQL graphical client can help debugging complex queries like this one, for example by running

it against a system that has been verified to saturate.

Figure 36 – SQL query used in the second Data Sets of the report template (as seen in the Oracle Developer client)

All Data Set parameters are linked to report parameters (as shown in the following figure) except for the

domain_id parameter which is only used in the Data Set (to debug the SQL query) but get replaced by values

returned by the first Data Set (this is explained later).



Figure 37 – Data Set parameters as linked to report template

The report parameters are:

threshold_H: represents the threshold (e.g. 85%)used for calculating the number of days to saturation

for the required statistic, that 75th percentile of the CPU utilization;

time_interval: represents the rolling time interval used for the regression; this can be defined as a hidden

parameter automatically valued to 30 days, while still allowing the report to have this parameter valued

once BCO will also provide different rolling time periods;

time_to_saturation: the time threshold (as number of days) to reach saturation.

Figure 38 – time_interval parameter defined as hidden

Notice that an additional report parameter “back_in_time” has been introduced only for making easier to verify

the report template in test environment that do not have fresh data continuously imported into BCO. Basically, it

provides a simple way of the setting the clock back by a given a number of days. Also this report parameter can

be hidden.



The following figure shows an example of the preview for this second Data Set.

Figure 39 – Preview Results for the second Data Set


The report layout for this example is structured as described by the following figure: a Group Table on

DOMAIN_ID taken from the first DataSet that provides the value of the sub-domain used by the internal Table to

display the values of the second Data Set.

Figure 40 – Report layout showing the report parameters and the Group Table structure



Of course, the table can be sorted to present first the systems that are predicted to saturate sooner (see the

following figure).

Figure 41 – Highlights defined on DAYS_LEFT_H

For this sample report, it is also convenient to leverage a number of presentation features provided by BIRT

Reports, such as the ability to format, remap and highlight values.

For example, it is convenient to format all numbers representing percentages (see the following figure).

Figure 42 – Formatting values (e.g. PCTILE75_H) as percentile values

Moreover, since the number of days to saturation can also be valued as “null” in case a system is already

saturated, a mapping rule to displays the string “saturated” is defined (as illustrated in the following two figures).

Figure 43 – Mapping DAYS_LEFT_H in case of “null” value



Figure 44 – Mapping rule for DAYS_LEFT_H from “null” value to “saturated”

Moreover, since the value of slope are not immediately readable some additional mapping rules can be defined,

for example (see the following figure) to remap the original to string such as “slow”, “medium” and “fast” (trend).

Figure 45 – Mapping rules for SLOPE_H to readable trend values

Notice that in case of multiple conditions, these conditions are evaluated from top to bottom as listed. In general,

it is recommended to list all conditions explicitly.

Also it might be useful to highlight differently systems according to different conditions, for example systems that

have a fast growing trend or (see the following figures) to identify systems already saturated from those that are

predicted to saturate in the future.



Figure 46 – Highlights defined on DAYS_LEFT_H (the select rule is for “null” values)

Figure 47 – Highlights defined on DAYS_LEFT_H (notice comparison to report parameter value)

Notice that in the previous figure the condition could be simplified as simply being about not “null” values but it is

provided here as an example of how to compare to parameter values.

Finally, a dynamic text can be inserted Table Footer to describe how many systems are predicted to saturate for

a given sub-domain or to explicitly clarify that a no systems matching this condition (of course in this case the

corresponding table would be empty), as illustrate by the following figures (notice that different colors are

associated to the two different strings displayed).

Figure 48 – Dynamic Text in the Table Footer



Figure 49 – definition of the Dynamic Text in the Table Footer

As shown in the previous figure, the dynamic text is based on a JavaScript expression (notice that table rows are

indexed starting from 0 so the expression need to take that into account). The associated visibility properties

(see the following figure) specify that the dynamic text needs to be hidden when the table is empty (again notice

that table rows start from 0); in that case the other Table Footer will be displayed instead – see below).

Figure 50 – visibility property for the dynamic label in the Table Footer

The following figures show the preview that can be obtained from the BCO Integration Studio for different values

of the report parameters.

Figure 51 – report page for sub-domain with no systems predicted to saturate



Figure 52 – report page for sub-domain with systems predicted to saturate

Figure 53 – report page for sub-domain with systems already saturated


The installation step for this report template is similar to what described for the previous examples, with the

option of having some report parameters defined at creation time and others defined at run time.

The following two figures illustrate one of the potential options on how to specify the report parameters at

installation time.



Figure 54 – Installing report template: creation-time parameters

Figure 55 – Installing report template: run-time parameters


The following figure shows an instance of a generated report with specified run-time parameters indicated for

each run.



Figure 56 – Generated report with specified run-time parameters



Example 4: Report on under-/over-utilization systems

This fourth (and final) example illustrates how to extend the BCO data schema by defining Data Marts from

simple Performance Time Analysis (also known as PTA) defined on standard metrics and custom statistics. In

this example, several features of BCO Integration Studio that have already described in the previous examples

will be used.

The problem

The problem can be stated as follows: “Create a monthly report that lists both the under- and the over-utilized

AIX systems in terms of CPU utilization (by considering average, peak and 95th percentile values), with respect

to two thresholds (e.g. low and high watermarks)”.

The solution

Also in this case, the solution to this problem consists in creating a custom report template created from BCO

Integration Studio. This report template can then be uploaded and executed (as on-demand or scheduled report)

from the BCO console.

With respect to the examples illustrated in the previous chapter, a couple of additional initial steps are required

to define the custom statistic (95th percentile of CPU utilization) mentioned in the problem statement and to

create a Data Mart to then leveraged by the report template Data Sets.

Step 1 – defining custom statistics

The first step in creating a custom report consists of identifying the metrics/statistics required for the custom

reports. In this specific case, in addition to standard statistics, such as average and max, also the 95th percentile

statistic is requested. Therefore, a new custom statistic needs to be defined to provide the required values for

the 95th percentile at the monthly level for the intended time interval (e.g. since the last 2 months to allow the

report to be generated also for the previous and the current month – of course it is assumed that proper aging

policies are set for that summarization level).

Defining custom statistics can be easily accomplished from the BCO Console (page “ADMINISTRATION>Data

Warehouse>Custom stats”) by a BCO Administrator.

The following figure shows the list of custom statistics where a custom statistic MONTHLY_CPU_95PCT has

been already defined. Notice that this specific statistic is a “rule-based statistic”, that is it defined by a (user) rule

not a “producer” (such as a performance analysis or a time forecast model). Please refer to BCO manuals for

more clarifications on this topic.



Figure 57 – MONTHLYCPU95PCT custom statistic created by selecting “Add stat” in the “Rule-based statistics” section

The key parameters to be specified for this custom statistic are the Time Aggregation (“Hourly” since we need to

produce a monthly value) and the Value (“.95” to represent 95%), as shown in the following figure.

Figure 58 – Definition of the MONTHLYCPU95PCT custom statistic



After creating this custom statistic, an “historical recovery” starting from a specific date (e.g. the beginning of the

previous month) needs to be executed to ensure that values for this custom statistic are available also for

previous time periods.

Figure 59 – Where to activate the data recovery for the MONTHLYCPU95PCT custom statistic

Notice that historical recovery can be performed on specific systems or on the whole environment.

Step 2 – defining AR views

The second step involves creating an Advanced Reporting view (AR View) that can be used to extract the

required data to be presented in the reports with a single query. An AR View can be easily done from BCO

Console leveraging any defined Performance Analysis over Time (PTA).

The following figures show how this analysis has been defined.

Figure 60 – Analysis used to define AR Views: Entity Filter and the time resolution parameters



Figure 61 – Analysis used to define AR Views: Time Filter and resource filter

Notice that all the metrics and statistics (including their granularity) that are defined in the analysis map to

columns in the physical view stored and populated in the BCO database that corresponds to an AR View. Also

both Time Filters and Entity Filters defined in the original analysis are inherited by the corresponding AR View

(as shown in the previous figures, where an “AIX_interval” Time Filters and “ALL_AIX” Entity Filters are used).

In particular, the Analysis should define the standard and custom statistics of interest (see the following figure).

Figure 62 – Analysis used to define AR Views: standard and custom statistics



In order to have a quick preview of the output of the Analysis it is suggested to select a simple chart type, such

as “Summary – table” in the chart options.

AR Views can be defined from the BCO Console (page “ADMINISTRATION>Advanced Reporting>AR

Views>Analysis/Model Views”) by a BCO Administrator, as illustrated by the following two figures. This requires

linking the AR View to the PTA created before and mapping the PTA metrics to the AR View column names.

Figure 63 – AR View definition: associated analysis and materialized task (notice that the option to not limit the number of

rows and series needs to be selected when in Advanced Mode)

Figure 64 - AR View definition: column mapping to required (standard and custom) statistics

Notice that AR views are automatically populated (“materialized” in BCO terminology) by the specified task

configured when defining the AR views (see the following figure).



Figure 65 – Enterprise Reporting Materialized task as seen from the System Task list

Moreover, the materialization can also be executed on-demand (see the following figure). Also notice that if the

analysis is modified (e.g. the Entity Filter or the Time Filter or the resource metrics are changed) then the AR

View needs to be rebuilt (and then re-materialized) to see those changes applied. Notice that AR View needs to

be rebuilt also when other AR View parameters (e.g. the option to extract “all rows”, that is displayed only in the

advanced option) are changed.

Figure 66 - AR View definition: column mapping to required (standard and custom) statistics

The materialized view is named “ER_V_” as a prefix and a numerical identifier as suffix to the original AR View.

Figure 67 - AR View as listed in the Analysis/Model view list (with the associated name of the physical view)



The correct definition and content of the “physical" (that is database) view corresponding to the defined AR

Views can be inspected directly from an Oracle client.

Notice that the AR View has been defined as referring to an Entity Filter defined so as to return only AIX systems

(the different options this could be done not being in the scope of this document) as requested by the problem

discussed for this example. Therefore, in case similar reports are required for other operating systems (e.g.

Windows, Solaris, Linux, etc), additional OS-specific AR Views can be created (from Analysis with corresponding

Entity Filters). As an alternative approach, the selection a single AR View could be created to then have the

report Data Sets select the appropriate rows.


Once AR Views have been created, the next step is to create custom Report Templates from the BCO

Integration Studio client. The third step now consists in defining the Report Template. As usual, this implies

defining the Data Source as illustrated in the previous chapters for the other examples.

At this point it is worth mentioning an additional best practice to be adopted when releasing a report template

from a test to a production development. That is to replace both the JDBC Driver URL and username/password

credentials with anonymous values (e.g. “jdbc:oracle:thin:database_server:database_port:SID” and

“empty/empty” respectively).


The following figure illustrates the Data Sets that refer to the defined AR View needs to be defined (see the

following figure).

Figure 68 – The query provided by the AR view used as a Data Set in the report definition

Notice that where condition uses two Data Set parameters “month_year_1” and “month_year_2” (in Data Sets

multiple occurrences required to have different names) are associated to the report parameter (as shown in the

following figure).



Figure 69 – Data Set parameters and their correspondence to report parameters

Since the reports are supposed to by generated monthly, it can be assumed that there would be a parameter

that users can use to specify the month of interest (in a specific format, such as “YYYY-MM”) when executing the

report manually. The pre-defined parameter “ref_date” can be directly used as it will be configure to provide the

last month with respect to the time of execution. In this case, since the “ref_date” values are in “DD/MM/YYYY”

format (that cannot be changed), the SQL query in the Data Set will need to be changed accordingly. Also a

different configuration will then be required at installation time, that is by having the reference date passed by the

report ignored and a “ref_date” parameter specified the report parameter as creation or run-time parameter.

Moreover, to specify the threshold for systems to be consider under- and over-utilized with respect to monthly

values of the 95th percentile values of the CPU utilization, two additional parameters are defined, that is

“low_watermark” and “high_watermark” respectively (both as numbers ranging from 0 to 100). Default values for

these parameters need to be necessarily set at installation time if these reports need to be automatically

executed. Notice that in this example the SQL query in the Data Set does not use these parameters, as the

decision here has been to have a simple query and to work at presentation level to make visible only specific

values in separate tables (see below).


The layout of this report is illustrated by the following figure. It basically contains three tables (similar to what

created for the report presented in the previous chapter) that display respectively the list of all (AIX) systems

whose (95th percentile) CPU utilization is: i) above the high watermark threshold (that is that are over-utilized); ii)

between the high and the low watermark threshold and iii) below the low watermark threshold (that is that are

under-utilized). Of course, the second table could be simply dropped as not providing useful content for a by-

exception report.

The report layout can involve additional customizations such as: sorting these tables in descending order with

respect to the CPU_UTIL_95 statistic, showing the overall number of rows in each table (with different messages

and colors when the table is or is not empty), show “out-of-range” in place of higher than 100% values (e.g. in

case the original data source is not fully reliable), including a summary (e.g. an histogram), etc, similarly to what

done for the report presented in the previous chapter, to make this report to be more easily readable.



Figure 70 – Report layout as seen from the BCO Integration Studio

Notice that in the table footers expressions referring to Aggregations (see the following figure) are used to

provide the total number of system listed in each table.

Figure 71 – Expression used in the table footer (for the system with a normal range of CPU utilization)




As a final step before being able to use them, this report template can be installed and configured in terms of

report parameters specified at configuration or at run-time time, as illustrated by the following figures.

Figure 72 – Report template with reference data is ignored (as it is provided as specific parameter)

Figure 73 – Report template with reference data is set to “Last month”



Figure 74 – Report template with high_watermark and low_watermark as creation parameters (with their assigned default

values: 85% and 30% respectively)


At this point, custom reports can be generated on-demand or scheduled by selecting the appropriate custom

Report Templates (from the WORKSPACE section of the BCO Console). As for all reports generated with BCO,

they can also be published in the Reports section of the BCO Console or published to BCO dashboard views or

automatically sent by mail (as either an attachment or a link).



Appendix A: PV_SYS_DATA_ROLL

As mentioned in the previous chapters, the Public View PV_SYS_DATA_ROLL will be provided for of BCO 4.5

by Service Pack 2 (yet to be release at the time this document is being written). However, this Public View can

be created also in a general BCO 4.5 environment using a SQL script (see the following figure)

Figure 75 – Fragments of the SQL script used to create PV_SYS_DATA_ROLL



Acronyms

The following acronyms are used in this document to refer to BMC products and components:

BPA: BMC Performance Assurance (now part of BCO Extended Edition)

BCO: BMC Capacity Optimization

BCO/EE: BMC Capacity Optimization Extended Edition



References

BCO User Guide:

https://support.neptuny.com/display/CAPUG

Public Views: https://support.neptuny.com/display/CAPDG/Public+Views

How to create custom stat: https://support.neptuny.com/display/CAPAG/Custom+stats

How to create ER views: https://support.neptuny.com/display/CAPAG/Analysis+and+Model+Views

BCO Administration Guide:

https://support.neptuny.com/display/CAPAG

BCO Development Guide:

https://support.neptuny.com/display/CAPDG

BCO Knowledge Base pages:

https://support.neptuny.com/display/CKB

https://support.neptuny.com/display/CAPUG

https://support.neptuny.com/display/CAPDG/Public+Views

https://support.neptuny.com/display/CAPAG/Custom+stats

https://support.neptuny.com/display/CAPAG/Analysis+and+Model+Views

https://support.neptuny.com/display/CAPAG

https://support.neptuny.com/display/CAPDG

https://support.neptuny.com/display/CKB

Business runs on IT. IT runs on BMC Software.

Business thrives when IT runs smarter, faster, and stronger. That’s why the most demanding IT organizations in the world rely on BMC Software across both distributed and mainframe environments. Recognized as the leader in Business Service Management, BMC offers a comprehensive approach and unified platform that helps IT organizations cut cost, reduce risk and drive business profit. For the four fiscal quarters ended September 30, 2008, BMC revenue was approximately $1.83 billion. Visit www.bmc.com for more information.

Documents

How to create custom reports in BMC Capacity Optimization...PAGE 1 OF 54 CONFIDENTIAL BMC Capacity Optimization How to create custom reports in BCO Table of Contents Legal Notice _____6