Dashboard Preference

QPID-7118 aims to add the support for a simple dashboards to the Web Management Console.  The dashboard is targeted at users in the operate role and aims to help such a user understand the health of the system that he monitors.

In the long term, the dashboard will support:

• Different sorts of widgets (perhaps queries, charts, traffic light style alerts etc).
• Flexible arrangements of widgets within the dashboard.
• Dashboards will have stable URLs - facilitating the easy incorporation into team radiators.

For the first version, the dashboard will be limited to showing one or more queries arranged in a single column.    The dashboard will be contained within an existing Web Management Console (WMC) tab.

When adding widget to a dashboard, the user will be selecting from widgets (queries) associated with the same object.

Dashboard Preference Serialisation

The Dashboard will need to be serialised as a Preference.  The serialisation format will be a concern of the WMC only; the Broker will handle it as an opaque preference type (X-Dashboard).

The serialisation format needs to encapsulate:

• id of each widget
• position of each widget
• configuration associated with each widget e.g. refresh interval, minimised status, query limit.  Some configuration items may be common to all widgets, others will be associated with only widgets of a particular type

Serialisation Format

This initial version of a serialisation format for a 2 x 2 dashboard:

id1 id3
id2 id4

would look like this:

{ "version": 1.0,
  layout:
  { "matrix": [["id1", "id2"], ["id3", "id4"]], 
    "layoutStyle": "COLUMNS_AND_ROWS"
  },
  configuration:
  {
     "id1" :
        {"refreshPeriod", 30000,
         "state" : "OPEN", /* State of the widget */
         "widgetConfiguration" : /* Arbitrary configuration items understood by the widget */
                {
                  "queryLimit" : 50
                }
     "id2" : {....}
  }
}
 

Matrix is a two dimensional array, with inner arrays corresponding to each column's contents.  Columns need not have the same number of entries.    The lists within the matrix may not contain nulls.

Each widget may have configuration associated with it.  It will be legal for configuration to be absent, in which case, defaults will apply.  Configuration will be divided into configuration that may be associated with any widget (for instance, refreshPeriod or state), and configuration that associates with widgets of particular types (for instance, limit).  The widget configuration's is opaque to the dashboard serialisation format. The widget configuration does not encapsulate the widget's type.  To discover the type, a further REST API call will be necessary.

To illustrate the the format further, if I wanted a dashboard like this:

    id2
id1 id3
    id4

it would be serialised as:

layout:
  { "matrix": [["id1"], ["id2", "id3", "id4"]], 
    "layoutStyle": "COLUMNS_AND_ROWS"
  },

Later we can add more sophisticated layout styles if required.

For instance, to allow for dashboard layouts like this:

  id1
    id3
id2 id4
    id5
  id6

we could serialise generically as:

{ "matrix": [ [["id1"]],
              [["id2"], ["id3", "id4", "id5"]],
              [["id6"]] ], 
    "layoutStyle": "ROWS_OF_COLUMNS_AND_ROWS"
  },