IT Operations Management (ITOM)

Building your HPE Business value dashboard using tags and dimensions

Building your HPE Business value dashboard using tags and dimensions


The following is a guest post by Klaus Baumecker, R&D OpsBridge Specialist


From the BVD (Business Value Dashboard) docs, you might know that the way to connect your data with the widgets is via so-called data channels. Data channels are a kind of pipeline where the data from a specific source is wired to the widget on your dashboard. But how are these pipelines created? Data channels are a concept; nevertheless, they can be seen like real pipelines that are created when they're needed. And that can happen all the time when you send data to BVD.


All data sent to BVD is made of JSON documents. And the good thing is, that there is no given structure you need to obey. But how does BVD know, where to route this data, i.e. in which pipeline/channel to put it? That's by giving hints to BVD. These hints are information pieces given as URL or path parameters when sending data to BVD via HTTP POST. The URL parameters are dimensions and tags. The simple way is using tags like

http://localhost:12224/api/submit/<api-key>/tags/mymetric or



Here BVD creates a channel with the name mymetric and all data that is coming from this requests will be stuffed in that channel. But what if you have a data sender that is sending not just a single metric, but multiple? Think of a service that consolidates the metrics from multiple sensors. In this case they have to go into separate channels in order to be mapped to different widgets.

In this case dimensions to the trick. But what to specify in the dimensions? Here the sender has to figure out, what identifies the different sensor data from each other? Let's look at an example of three sensor messages:


  sensor: 'Sensor A',

  value: 12.5,

  other: foo



  sensor: 'Sensor B',

  value: 42,

  any: blah



  sensor: 'Sensor C',

  value: 21,

  aux: bar



It seems like they all have a sensor name in the sensor property and carry a value. That means the sensor property can be used to identify the sources and is therefore a good candidate for a dimension. Similar to the above URL you can specify dimensions with the dims URL param



Now instead of a creating a static channel name, BVD looks up the message for all properties that are dimensions and creates a channel from that. Here the channels Sensor A, Sensor B and Sensor C. That all goes automatically when sending data to BVD. The only thing you need to do is giving BVD a few hints on what differentiates the messages from each other.

Note: It is necessary, that a consolidation of different metrics has to follow the same schema, at least they all should contain the same identifying (dims) and value properties


And in case the 3 sensors do not send a single metric but many of different type, then a message would look like this:


  sensor: 'Sensor C',

  value: 21,

  type: 'temp',

  aux: bar



Now sensor alone as dimension is not enough. We need to add another dimension: type:


And the resulting channel name(s) become

'Sensor C temp'


And in the rare case, where you might have sensors that are replicated onto multiple sites (like in a backup data center) they might send data which is using the same dims and the same values for sensor and type, but actually come from multiple sites. They would send data which ends up in the same channel, which would be bad. Now tags can help you again by adding another static name prefix per each data sender, like so





The result is a set of channel names with a difference in the string DC1 or DC2

'DC1 Sensor 1 temp'


With the upcoming release, dims and tags get even smarter and together with the hot Dashboard Template feature this opens even more possibilities.

More on this in the next BVD blog.
Search for BVD and OpsBridge for other blogs on this topic.

Try OMi now! OMi 10.10 comes pre-loaded with a number of Management Packs that you can try out without the hassle of getting management pack software or evaluation license.

Read more on our @HPE IT_Ops solutions:

HPE Operations Bridge
HPE Live Network: Operations Bridge Evolution

HPE Live Network: Operations Manager i

HPE Live Network: OMi Management Pack development kit

HPE Live Network: HPE  SPI to MP Evolution Tool

You can see demonstrations and find out more details of this and other features of our HPE Operations Bridge solution in our sessions and at our booths during #Discover Las Vegas.

Click on the image below or here to register.


  • operations bridge
About the Author