AlarmScreenNg 0.9.9
JSON syntax

This sections describes the format of JSON, used for different settings of AS EWO

Basic configuration

The basic configuration is a string in JSON format, stored in dedicated DP. There is no WinCC OA panel for preparing the basic configuration, JSON string shall be prepared manually, using suitable text edidor. This section describes the syntax and semantics of basic configuration JSON.

The structure

The whole basic configuration is rather large and complicated. Here are the major components of basic configuration (== top level nodes of JSON), the content of every component will be described in more details in next sections.

{
"ProxyModelConfiguration": {...},
"FilterWidget": {...}.
"MouseProcessor": {...},
"EwoEventsProcessing": {...},
"wildcards": {...},
"SpecificOptions": {...},
"UserSettings": {...}
}

Only ProxyModelConfiguration is mandatory for basic configuration, all other parts are optional, though still useful.

ProxyModelConfiguration

Some basic knowledge of AS EWO code is needed in order to understand the configuration of models. The simplified structure of code in presented on the following picture:

Software structure
  • Alarm Source connects to live alarms in WinCC OA system or executes historical queries.
  • Alarms Model keeps the list of alarms, arriving from source.
  • Proxy Model performs filtering, sorting and grouping as specified by the user.
  • Finally, alarms data from Proxy Model are presented to user in Alarm Table.

Keeping this software structure in mind, the structure of model configuration looks more clear:

"ProxyModelConfiguration": {
"AlarmModelConfiguration": {...},
"columns": [...]
}

The ProxyModelConfiguration consists of the source for Proxy Model (AlarmModelConfiguration, the configuration for Alarm Model, according to software strcture), and list of columns which can be shown in table.

AlarmModelConfiguration

The configuration for Alarm Model, in turn, includes the configuration for Alarm Source,

"AlarmModelConfiguration": {
"AlarmSourceConfiguration": {
...
},
"blockingTime": 2000,
"liveValuesTriggerType": "none",
"liveDpeRefreshPeriod": 5000,
"maxDpesInDpGetRequest": 128,
"maxDpGetRequests": 16,
"embeddedFilters": {
}
}

The items for AlarmModelConfiguration are the following:

  • AlarmSourceConfiguration: see AlarmSourceConfiguration for more details
  • blockingTime: the time in milliseconds between successive updates of Alarm Model with new data from Alarm Source. The main purpose of this delay is to avoid continuous refresh of Alarm Table if new alarm data arrive to source continuously: the table content is not updated during this time interval, new alarms data are buffered, and then, after blocking time expires, all collected alarm data are processed in one batch.
  • liveValuesTriggerType: AS EWO can dsiplay live value of DPE that produced alarm; this configuration defines: for which alarms live DPE value shall be requested (using dpGet()). The following values are possible:
    • none: no live DPE values are requested, this is the default
    • filtered: live DPE values are requested for alarms which match current filter
    • all: live DPE values are requested for all alarms in model
  • liveDpeRefreshPeriod: the period in milliseconds for updating model with 'live' value from DPE of alarm. In principle, the live value for DPE can be obtained by two major methods:
    1. Periodic polling requests by model (using dpGet() and similar calls)
    2. Subscription for DPEs of interest (using dpConnect() and similar calls)
    After some thinking/discussions, it was decided to use 1st method for implementation, the main arguments were: it is more easy to implement and to control. This time is period for issuing dpGet() requests. Default value is 5000.
  • maxDpesInDpGetRequest: maximum number of DPEs in one dpGet() request for updating model with 'live' DPE value, see above. Default value is 128.
  • maxDpGetRequests: maximum number of dpGet() requests to send in row. Previous value was number of DPEs in one batch, this number is max number of batches. If there are more pending requests then they will be sent after short pause, allowing for model (and AS EWO) to perform other processing if necessary. Default value is 16.
  • embeddedFilters: sometimes the required filtering can't be expressed as FROM and/or WHERE clauses of dpQueryConnectSingle(), but the list of alarms for Alarm Model still needs to be filtered. In such case, a definition of structured filter (see Structured filters (entered using widgets)) can be added here, and only alarms matching this filter will reach the Alarm Model from Alarm Source.

columns

The columns entry of configuration for Alarm Model describes all columns which can be shown in table. The columns is an array of objects, where every object describes individual column.

"columns": [
{ "id": "Abbreviation", "source": "this", "title": "Short Sign", "backColor": { "id": "AlertColor" } },
{ "id": "AlarmTime", "title": "Local Time" },
{ "id": "timeUtc", "title": "UTC Time" },
...
]

Every column object may contain the following items:

  • id (mandatory): the internal name of alarm property to be shown in this column, see Alarm properties.
  • source (optional): the source for reading this property, possible values are:
    • this: the value of alarm property property for this column is taken from 'this' alarm, i.e. the alarm which is displayed in table row
    • partner: the value of alarm property for this column is taken from partner of the alarm which is displayed in table row
    • came: the value of alarm property for this column is taken from CAME alarm of alarms pair
    • went: the value of alarm property for this column is taken from WENT alarm of alarms pair
    If source is missing in column configuration, then this is assumed.
  • title (mandatory): the string with header of column as it shall appear in Alarm Table. Note that this title is not only for displayin in the table header, for example, user settings related to columns will operate the title given here.
  • hideable (optional): false if user shall not be allowed to hide this column in Alarm Table; default is true.
    Note
    even for columns which are not hideable, user can reduce visible column width to zero
  • backColor (optional): the decsription of other alarm property where background color for this column shall be taken.
  • foreColor (optional): the decsription of other alarm property where foreground (text) color for this column shall be taken.

The content of backColor and foreColor are, in principle, objects of the same structure, but only id and source values are used.

AlarmSourceConfiguration

The configuration for Alarm Source has the following structure:

"AlarmSourceConfiguration": {
"queryFilter": {
"onlineFrom": "",
"onlineWhere": "",
"oracleWhereElements": "",
"oracleWhereAlerts": ""
},
"maxThreadCount": 1,
"maxWaitForDpGet": 10,
"autoConnectIncludes": [
"system1",
"system2*"
],
"autoConnectExcludes": [
"system22",
"system24*"
],
"plugins": [
{
"name": "AlarmSourceJCOP",
"options": {
"descriptionWhenEmpty": "aliasOrName"
}
},
"AlarmSourceUNICOS"
]
}

The configuration for source may include the following parts (all are optionsl):

  • queryFilter: in many cases not all alerts in the system(s) shall be selected by Alarm Source, but only some subset. In general, it is better to apply filte as early as possible; this configuration entry allows specifying filter(s) to be applied at the very first stage: when query is executed.
    Because of very different syntax, used by different queries (dpQueryConnectSingle() for online data, SQL query for ORACLE archive...), the syntax of such filters is very different. It is responsability of expert, preparing configuration, to supply these config entries with correct syntax.
    Furthermore, it is responsability of the same person to write consistent filter conditions (for example, criteria for online query shall result in the same set of alarms as criteria for archive query).
    The following filters are supported so far:
    • onlineFrom: string to be used as FROM clause of query for online alarms. Example is configuration for UNICOS where input is restricted to only DPs with paricular structure:
      "onlineFrom": "FROM '*.ProcessInput.*'"
    • onlineWhere: string to be used as part of WHERE clause of query for online alarms. Example is configuration for UNICOS CPC where input is restricted to only DPs with paricular names:
      "onlineWhere": "((_DP LIKE \"un-*\") OR (_DP LIKE \"su-*\"))"
    • oracleWhereElements: string will be added to WHERE clause of query for archived alarms from ORACLE archive, namely - to WHERE clause of first query that selects DPE IDs, which will be used by second query to select alarms. Example is configuration for UNICOS CPC devices, which is ORACLE equivalent of examples for onlineFrom and onlineWhere above:
      "oracleWhereElements": "((el.element_name LIKE '%:%.ProcessInput.%') AND ((el.element_name LIKE '%:un-%') OR (el.element_name LIKE '%:su-%')))"
    • oracleWhereAlerts: string will be added to WHERE clause of query for archived alarms from ORACLE archive, namely - to WHERE clause of second query that selects alarm details for DPE IDs found by first query.
  • maxThreadCount: maximum number of threads which can be used for processing callback data in Online mode of alarm source. Default value is 1. Zero or negative value means that alarm source shall take the default number for Qt (calculated from number of processor cores).
  • maxWaitForDpGet: maximum number to wait for response of dpGet() call in Archive mode of alarm source. Default value is 10. Filtering on some of alarm properties can't be directly mapped to criteria in query for archive DB; examples can be found in UNICOS: alarmType and master properties of alarms: for some DP types these properties are calculated from content of special DPE *.statusInformation.configuration.deviceConfiguration, whose value is not available in archive (in general). Filtering on such properties is done in two steps:
    1. Query uses only part of the whole criteria, if possible (for example, criteria on DP type names)
    2. Then for alarms, returned by query, the 'final filtering' to be applied, requiring the value of DPE to be obtained by dpGet() call.
    If the response for dpGet() request doesn't arrive after waiting for number of seconds, given by this value, then the query of archived data is considered to be failed.
  • autoConnectIncludes: array of system names to which AS EWO shall connect automatically. The names can contain UNIX-style wildcards. Formerly this parameter was called autoConnectSystems, and old name is still recognoized by parser.
  • autoConnectExcludes: array of system names to which AS EWO shall NOT connect automatically. The names can contain UNIX-style wildcards. If some system name matches both filters in autoConnectIncludes and autoConnectExcludes then the latter wins: it is expected that autoConnectExcludes will contain more specific name patterns. Two set of patterns have been introduced for the cases where distributed system is organized (more or less) hierarcghically, and AS shall connect to (many) child systems, but not to (few) parent systems.
  • plugins: the array of plugins, used to extend set of properties for alarm, see Alarm properties. Alarm Source may use more than one plugin, they are processed in the order in which they appear in this array; the next plugin may override properties calculated by prevous plugin.
    The same plugins also provide functionality of building query for archived data, as well as processing query results. Again, the 'most important' plugin must be the last one in this list.

    Two types of format for elements of plugins array are supported:

    • object: plugin definition is object containing two items:
      • name: the name of plugin to be loaded (in fact - the name of DLL/so)
      • options: the set of options for this plugin. The options are interpreted by plugin itself, the AS EWO doesn't make any assumptions on syntax/semantics of options. The format for plugin options is the same as for SpecificOptions.
        For the time being the only plugin working with options is AlarmPropJCOP plugin; it can use option named descriptionWhenEmpty. This option determines what shall be the content of Description property when description itself is missing. Possible values are:
        • deviceName: device name shall be used if description is empty
        • aliasOrName: alias shall be used if description is empty; if alias is also empty then device name shall be used
    • string: plugin definition only contains plugin name to be loaded, without any options.

    Both varaints are shown in the example JSON above: object for AlarmPropJCOP and string for AlarmPropUNICOS.
    While building the query for historical data from ORACLE RDB, the main purpose of such plugins is preparing WHERE clause of query according to content of filter, supplied by user. There is a default processing, that can prepare query predicates for 'standard' alarm properties. But if some of these plugins, has introduced new (framework-specifc) alarm property, then basic implementation just doesn't know how to convert user filter on this property to ORACLE query. The plugins, listed in this section, are expected to know how to convert filter to ORACLE query for specific framework (if that is possible at all).

Both fromTemplate and whereTemplate may not only be fixed strings, they can be parametrized strings, with values of parameters applied at run time. For example, if we want AS EWO to display alarms of one DP only, then we can specify in configuration something like:

"whereTemplate" : "WHERE _DP = \"%1\""

Then at run time real DP name can be substituted to string template using corresponding EWO methods.

Parameters in string shall be called %1, %2 etc. Lists of strings, passed to EWO methods, shall contain enough items to substitute all parameters.

In either case, AS EWO doesn't make any check on syntax of resulting FROM and WHERE to be used in query: the query either works or not. Even if it works (i.e. there is no syntax error), it can happen that result of query is not what was planned. The right query syntax is responsability of user who prepared configuration, the right values for parameters substitution is a responsability of CTRL that passes strings for parameters substitution.

Furthermore, the format of FROM and WHERE parts of query are expected to be different for different modes of data source (online data, or archived data). The examples above assumed online source of alarms, where syntax must be suitable for passing resulting string to dpQueryConnectSingle() and similar functions.

For data from archive, syntax of FROM and WHERE shall be different. Even more, the syntax can also depend on what archiving is used. In order to allow source switching on the fly, the syntax allows one more form of configuration for fromTemplate and whereTemplate:

"whereTemplate": {
"online": "WHERE _DP = \"%1\"",
"oracleRDB": "(el.element_name LIKE '%2.%')"
}

In this example, two variants of WHERE condition for query are specified in configuration: one for online alarm source, and another one for alarm source, reading archived alarms from ORACLE RDB.

Note
The same syntax of configuration can be used for fromTemplate, but for the time being FROM is not used for data from ORACLE RDB.

FilterWidget

The basic AS EWO does not include any particular configuration for structured filter (see Structured filters (entered using widgets)). Instead, AS EWO can load at run time dedicted plugin, which is responsible for bulding the structured filter area, using standard filter widgets implemented in AS EWO.

The FilterWidget part of basic configuration has the following structure (example of configuration for JCOP):

"FilterWidget": {
"widgetBuilder": "FilterWidgetJCOP",
"builderOptions": {
"option1": "value1",
"option2": "value2"
},
"completerLib": "fwAlarmScreenNg/AlarmScreenJCOP.ctl",
"masterCompleterFunc": "AlarmScreenJCOP_getFilterCompletions",
"slaveCompleterFunc": "AlarmScreenJCOP_getSlaveFilterCompletions",
"completions": {
"alarmType": [
"Position Alarm",
"Position Status"
]
}
}

All parts of this configuration are optional: AS EWO may operate without editable structured filter.

  • widgetBuilder: the name of plugin which shall build all necessary widgets for editing structured filter.
  • builderOptions: set of options for widgetBuilder plugin. The options are just key + value pairs. Exact set of supported options depends on particular plugin implementation, the basic AS EWO doesn't make any assumption about content of these options.
  • completerLib: the name of CTRL library, containing functions for calculating list of possible completions for every filter widget. See Filter completers
  • masterCompleterFunc: the name of CTRL function to ba called for calculating list of possible completions for filter widgets where list of completions does not depend on current value in another filter widget. See Filter completers
  • slaveCompleterFunc: the name of CTRL function to ba called for calculating list of possible completions for filter widgets where list of completions depends on current value in another filter widget, i.e. this filter is a slave for another filter. See Filter completers
  • completions: in some cases list of completions is fixed, i.e. the list is known in advance and no need to call any CTRL function in order to get it. In such case the list of completions can be specified directly in configuration. The value of this config entry is object with:
    • Name corresponds to ID of alarm property for whose filter shall use fixed list of completions for configuration.
    • The value for every name is array containing all allowed completions.

MouseProcessor

This part of basic configuration is almost useless, though still needed if mouse events from Alarm Table need to be processed.

"MouseProcessor": {
"processByEwo": true,
"ctrlLib": "fwAlarmScreenNg/AlarmScreenJCOP.ctl",
"ctrlFunc": "AlarmScreenJCOP_mouseTableEvent"
}
  • processByEwo: the value must be true, in this case mouse events is fired as event of AS EWO and processed by CTRL code. Other option (false) doesn't work as expected, so it shall not be used.
  • ctrlLib: not ised if processByEwo is true
  • ctrlLib: not ised if processByEwo is true

EwoEventsProcessing

Description of AS EWO events mentioned that names of CTRL function for processing this event and CTRL library where that function is dfined are passed in arguments to EWO events. But how EWO can know these names? No magic, the names are just part of basic configuration, as shown in the next example for JCOP configuration:

"EwoEventsProcessing": {
"mouseEvent": {
"ctrlLib": "fwAlarmScreenNg/AlarmScreenJCOP.ctl",
"ctrlFunc": "AlarmScreenJCOP_mouseTableEvent"
},
"ctrlActionRequested": {
"ctrlLib": "fwAlarmScreenNg/AlarmScreenJCOP.ctl",
"ctrlFunc": "AlarmScreenJCOP_ctrlActionRequested"
}
}

When AS EWO is about to fire event, it just takes these names from basic configuration and adds them to the arguments of event. The names are not interpreted in any way by EWO itself.

wildcards

In some cases 'unusual' wildcards are used, and basic configuration allows to modify some settings for interpretaion of wildcards in AS EWO.

"wildcards": {
"matchZeroOrMoreChars": "%",
"matchSingleChar": "_",
"alwaysShowNonEmpty": true
}
  • matchZeroOrMoreChars: specifieis the character that matches zero or more characters. The default value is '*' (asterisk).
  • matchSingleChar: specifies the character that matches any single character. The default value is '?' (question mark).
  • alwaysShowNonEmpty: normally 'no filter' is indicated by empty string in individual filters. When this value is set to true, 'no filter' is indicated by matchZeroOrMoreChars character.

SpecificOptions

This is rather special section in basic settings, it may contain arbitrary settings which are not even interpreted/used by basic implementation of AS EWO. For the moment JCOP-specific extension uses one setting of this category:

"SpecificOptions": {
"maskWithForceFiltered": {
"enabled": true
}
}

This is used to control appearance of mask Alarm item in popup menu: when this option is missing in basic config, or when the value of enabled is false, then the item just does not appear in popup menu.

But configuraion allows specifying any option, required to configure any feature (extenstion) of AS EWO. For example, this section could like like the following when two more specific options have been added:

"SpecificOptions": {
"maskWithForceFiltered": {
"enabled": true
},
"someOption1": {
"userlabel": "The label for option #1",
"threshold": 234,
"enabled": true,
"values": [
123,
234,
345
]
},
"someOption2": {
"alwaysVisible": false,
"choices": [
{ "label": "one", "value": 1 },
{ "label": "two", "value": 2 }
]
}
}

Every single option must have a unique name, the value for option must be object with arbitrary structure. CTRL code may retrive the value of option with given ID (name) using dedicated method of AS EWO.

Default UserSettings

In addition to configuration items, described in previous sections, basic configuration also contain default user settings for AS EWO. At run time these settings can be changed by user, the settings in basic configuration is just a default.

The format is for user settings is described in User settings.

Other

Unlike basic configuration, which must be prepared manually, other settings can be edited using dedicated panels. Normally, the user (or admin) shall not care about the JSON format for these settings. In addition, it is simple enough to make minor reverse engineering: just save required subset of settings, then look at resulting JSON, written to correspodning DP. This part of document provides just very short format description for these settings.

Admin Settings

There are 3 subsets of admin settings, described in Admin Settings, they are stored in 3 DPEs of dedicated DP . Every subset of admin settings uses its own format.

Access control

The settings of access control are normally edited using dedicated panel and finally saved in DPE of dedicated DP. The format of access control settings is the following:

{
"ackAll": [
{
"domain": "DCS",
"privilege": "expert"
},
{
"other": 2
}
],
"ackGone": [
{
"domain": "RICH",
"privilege": "expert"
},
{
"domain": "CHOD",
"privilege": "expert"
},
{
"other": 1
}
]
}

The syntax of JSON seems to be evident when comparing with the functionality of panel used for editing access control rules: the names of actions having some restrictions, plus the details of restrictions for every action.

Popup menu configuratin

The content of popup menu for alarm table is edited using dedicated panel and finally saved in DPE of dedicated DP. The format of popup menu descriiption is the following (part of configuration for JCOP):

[
{
"action": "viewAlarmTrend",
"appearanceFunc": "AlarmScreenMenuJCOP_itemAppearance",
"appearanceLib": "AlarmScreenNg/AlarmScreenMenuJCOP.ctl",
"ctrlFunc": "AlarmScreenMenuJCOP_showTrend",
"ctrlLib": "AlarmScreenNg/AlarmScreenMenuJCOP.ctl",
"label": "Trend"
},
...
]

The syntax of JSON seems to be evident when comparing with the functionality of panel used for editing popup menu: array of objects, where every object contains details for every menu item.

Help file types

Supported help file types are edited using dedicated panel and finally saved in DPE of dedicated DP. The format of help file types description is the following (part of default configuration):

{
".htm": {
"cmdLinux": "",
"cmdWin": ""
},
".html": {
"cmdLinux": "",
"cmdWin": ""
},
...
}

JSON contains all supported types of help files, plus two commands for opening files of this type on different operating systems.

User settings

User settings are edited using dedicated panel and finally saved in DPE of dedicated DP. The format of user settings is the following:

{
"GroupingConfiguration": {
"columnWidth": 150,
"groupHeader": "System / Priority",
"groupingRules": [
{
"alarmPropId": "SystemName",
"groupingRole": "display",
"sortAscending": true,
"textFormat": ""
},
{
"alarmPropId": "Priority",
"groupingRole": "display",
"sortAscending": false,
"textFormat": ""
}
]
},
"allowSwitchPairMode": true,
"filterSetDp": "na62dcs01:_NgAsFilterSet_1",
"showFilterView": "top",
"showFilterWidget": "Collapsed",
"showFooterWidget": "Expanded",
"singleRowPerPair": true,
"showConnectMap": false,
"useSystemConnectDialog": false,
"tableFont": "Arial,-1,12,5,50,0,0,0,0,0",
"sortingOrder": [
{
"columnTitle": "Time",
"sortAscending": false
},
{
"columnTitle": "Ack.",
"sortAscending": true
}
],
"visibleColumns": [
{
"columnTitle": "Short Sign",
"visible": "always",
"width": 40
},
{
"columnTitle": "Device DP Element",
"visible": "never",
"width": 350
},
...
],
"overrideDefaultAutoConnectRules": true,
"autoConnectIncludes": [
"system1",
"system2*"
],
"autoConnectExcludes": [
"system22",
"system24*"
],
"defaultFilter": {...}
}

Again, the syntax of JSON seems to be evident when comparing with content of panel used for editing user settings.

Sitting a bit aside is a defaultFilter. The content of this section contains the definition of structured filter at moment when user settings were saved. However, the definition of how this defaultFilter shall be used when loading this settings - is not part of user settings themselves, the usage is defined by content of DefaultFilter DPE, see User settings.

Items showFilterWidget and showFooterWidget allow also boolean value, where true is equivalent for Expanded, and false is equivalent for Hidden. This allows backward compatibility with user settings in 'old' format.

Filter

The structured filter, edited in filter editor area of EWO (see Structured filters (entered using widgets)) can be saved in DPE of dedicated DP. Exact content of JSON with filter settings depends on content of individual filters in filter editor. JSON below illustrates common structure of filter syntax in JSON:

{
"matchCase": false,
"filterRulesSets": [
{
"include": true,
"filters": [
{
"filter": {
"pattern": "na62dcs01*",
"source": "this",
"valueId": "dpElement"
}
},
{
"fixedMultiFilter": [
{
"fixedFilter": {
"filter": {
"numbers": "1,40-59",
"source": "this",
"valueId": "Priority"
},
"include": true,
"kind": "severityWarning"
}
},
...
]
}
],
}
]
}

The definition of structured filter consista of two elements:

  • matchCase: flag indicating if filter shall use case-sensitive string comparison
  • filterRulesSets: array of objects, every such object corresponds to one tab on structured filter editor. Every 'filter set' (or 'filter tab') object again consists of two elements:
    • include: flag indicating if alarms matching this set of filters shall be included to or excluded from visible table
    • filters: array of objects, every object corresponds to individual filter on this tab of filter editor. The structure of every individual filter depends on type of widget, used for editing this filter. Independently on widget type, all individual filters have two common fields:
      • valueId: the name of alarm property, whose value is taken for comparing with filter condition.
      • source: from which alarm given alarm property shall be taken (this, partner, came, went).
      Other field(s) for individual filter are filter type dependent. If there is a need for creating manually the filter in JSON, then the easy way is to specify required filter in filter editor area of EWO, save that filter and look at resulting JSON, written to DPE.
      There is also a method in AS EWO, allowing to read JSON presentation of current filter in EWO, see the methods of AS EWO.

Filter View

The content and appearance of filter view, edited in dedicated panel, is saved in DPE of dedicated DP. The structure of JSON with filter view definition is the following:

{
"grid": {
"filters": [
{
"column": 0,
"filterDp": "_NgAsFilter_operator_1",
"row": 0
},
{
"column": 1,
"filterDp": "_NgAsFilter_operator_2",
"row": 0
},
{
"column": 2,
"filterDp": "_NgAsFilter_operator_3",
"row": 0
},
{
"column": 3,
"filterDp": "_NgAsFilter_operator_4",
"row": 0
}
],
"frameBackColor": "none",
"frameLineWidth": 2,
"frameMidLineWidth": 1,
"frameShadow": "Raised",
"frameShape": "Box",
"frameSpacing": 4,
"itemBackColorSource": "totalBg",
"itemForeColorSource": "none",
"itemLineWidth": 2,
"itemMidLineWidth": 1,
"itemShadow": "Raised",
"itemShape": "Panel",
"itemTextFormat": "%{name}: %{total} (%{notAck})",
"itemToolTipTextFormat": "%{name}: total %{total}, not acked %{notAck}"
}
}

Every element in filter view description in JSON directlt corresponds to one of elements in corresponding editor panel, so the meaning must be clear.

Few words about the root element grid. Two types of Filter View were foreseen: grid and tree. However, Filter View oarganised in tree is not implemented yet.