Business Value Dashboards present your data in a very flexible layout for visualizing on any browser capable device. Within Micro Focus Operations Bridge there are several out-of-the-box data sources, such as Operations Manager i (OMi) monitoring dashboards, KPI status, and Performance Dashboard metrics. There is also an open interface that accepts JSON data submitted in an HTTP(S) POST. OMi provides a Data Forwarding policy type that lets you forward data that was collected by certain other policies to BVD. The Data Forwarding policy also takes care of putting the data into JSON format.
This blog explains how to configure OMi policies to send metrics to BVD to display in a pie, bar or line chart. The example queries metrics from a Microsoft SQL Server database, but the same principle applies to other data sources such as: a structured log file, XML file, REST web service or Perl script.
The goal in this example is to create a pie chart showing the total number of OMi events which are currently open, in progress, and resolved, and a line chart of events closed over time.
There are five steps to creating this type of chart:
- Create a Generic output – Database policy
- Create (or modify) a data forwarding policy
- Activate the two policies
- Create your business value dashboard
- Connect the data channel to the widget in BVD
Step 1: Create a Generic output – Database policy
For database policies, you need an Operations Connector. For other policies (structured log file, REST web service, XML file or Perl script), you just need Operations Agent version 12 on Windows or Linux.
Note: You could create this policy on the OMi server and then deploy to the Operations Connector node, but it is much easier to create database policies using the Operations Connector UI because it allows you to test your connectivity and SQL statements. Once you know it works, you can import it to the OMi server to manage it centrally and apply version control.
Next, give the policy an appropriate name.
In the Source tab, enter the details for connecting to your database. For this, you need to get a compatible JDBC database driver provided by your database vendor or a third-party driver and put it on the Operations Connector server. Enter the JDBC driver class and connect string according to the driver documentation.
In this example, the policy will execute the database query every 5 minutes.
Click the Collection tab.
The SQL statement needs to output a column name for each lifecycle state. It may be tempting to create a statement like this:
SELECT state, COUNT(*) AS total
GROUP BY state;
But, it outputs multiple rows with the column names state and total, which is not what we want for BVD. Instead, we want a single row with a column name for each lifecycle state.
In addition, the closed event count needs to include only those events that were closed since the last time the policy executed. This requires the use of a session variable to keep track of where the policy read up to last time in the database. More on that capability in a moment.
The following statement produces the desired result:
SELECT (SELECT COUNT(*) FROM event.dbo.all_events WHERE state = 'OPEN') AS openstate,
(SELECT count(*) FROM event.dbo.all_events WHERE state = 'IN_PROGRESS') AS in_progress,
(SELECT count(*) FROM event.dbo.all_events WHERE state = 'RESOLVED') AS resolved,
(SELECT count(*) FROM event.dbo.all_events WHERE state = 'CLOSED' AND time_received > '<$DATA:timestamp>') AS closed,
'OMi Prod' AS OMi
The last line was added to be used as a dimension in BVD, since all the other columns are metrics. BVD creates a data channel for each dimension’s value. Thus, this would create a dimension called “OMi Prod”.
This “Initial value statement” is executed the first time the policy runs and returns the latest time_received, which gets stored in the timestamp variable:
SELECT MAX(time_received) as timestamp FROM event.dbo.all_events
When the “SQL statement” is executed, the WHERE clause restricts the count of closed events to those with a time_received since the last time the policy ran.
Note that there is also a hard-coded “Session variable”. This is used when testing the SQL statement in the GUI. It is also used during policy execution if the “Initial value statement” doesn’t return any records.
After entering the SQL statement, Session variable and Initial value statement, click the “Execute SQL statement” button. Click the Sample Data tab to see the column names as properties. Click on each property to see its value.
Note: If you get an error executing the SQL statement, check your connection settings and SQL statement.
Click the Mappings tab.
Ensure that “Keep All input Fields” is checked.
Add a field with a name and value of your choice. It will be used in a later step to identify this data for forwarding to BVD.
Save and close the policy.
Step 2: Create (or modify) a data forwarding policy
In this policy, you define what data to forward to BVD in JSON format.
In the Targets tab, specify the BVD URL and specify “OMi”, which was defined as a column in the SQL statement, as the dimension. The URL format depends on which version of BVD you are using:
BVD 10.1x: http(s)://<your_fqdn>:[12224|12225]/api/submit/<your_api_key>/dims/OMi
BVD 10.6x: https://<your_external_fqdn>/bvd-receiver/api/submit/<your_api_key>/dims/OMi
In the Structured input tab, create a “Forward on matched” rule with a condition that matches the data in the generic output policy created earlier. This is where the additional field called “DataType” comes in handy. You want to be sure to forward only the data from the above policy and not ALL data that might be monitored by the node from Perl, structured log file, REST web services, XML file, and other database data sources to this particular target.
In the target tab, select the BVD target.
Save and close the policy.
Step 3: Activate the two policies
If you created the policies on an Operations Connector, activate both policies. If you created the policies in OMi, assign and deploy them to a node that contains an Operations Connector.
Step 4: Create your business value dashboard
Define the dashboard layout with widgets (eg, pie chart, line chart) in Visio and import it to BVD. For detailed steps, refer to the End-to-end business value dashboard creation video.
Step 5: Connect the data channel to the widget in BVD
The above data is forwarded to BVD with a JSON body like this:
"bsmc_source":"Event Lifecycle Summarycom/hp/opr/bsmc/geni/jdbc/GENIExtModJDBC",
"DataType":"Event Lifecycle Statistics",
The following screenshot shows the “OMi Prod” data channel and the event lifecycle states selected to drive the pie chart.
Explore all the capabilities of the Operations Bridge and technology integrations by visiting these sites:
- Operations Bridge
- Operations Manager i
- Operations Bridge Technology Integrations eBook
- Operations Bridge Integrations page