Method : Data sets & parameters management

In Centreon MBI, we use two different methods to manage the links between data sets, objects parameters and report parameters. These two parameters management methods are used with data sets based on JDBC data sources. The two methods that we use to inject parameters in SQL requests are described in the thow following sections.

The ‘classic’ parameter binding method 1

This method is based on the ‘?’ character in the SQL statement of a data set: in this case, request parameters are listed in the data set ‘Parameters’ tab. Each parameter can be directly linked to a report parameter or be filled with a default value (custom javascript statement or default string/number/...). When paremeters are filled only with a default value (string/number/...), it means that this parameter have to be overrided later.

Parameter created this way are visible in the ‘Parameters’ section of the object that uses the data set. Have a look to the exemple below:

DS_parameter_tab_png

In the picture above, we have the 3 different cases for the classic method:
  • the graph parameter ‘dateEnd’ is filled with a custom javascript which starts with ‘BirtDateTime.addDay(par...’ (‘BirtDateTime.addDay(params[“dateEnd”].value,-1)’)
  • the graph parameter ‘hg_id’ is filled with a default value ‘88’
  • the graph parameter ‘liveserviceID’ seems not to be filled but actually it corresponds to a direct link to a report parameter already bound in the data set. When report parameters are directly linked in the data set, they do not appear in the parameter section of table or graphs.

What you have to understand here is if you use this component, you will at least have to override the parameter ‘hg_id’ and import two report parameters called ‘dateEnd’ and ‘liveserviceID’. If you do not import these parameters, you will have to override the two object parameters ‘dateEnd’ and ‘liveserviceID’.

All the parameters using this method can be overrided with custom scripts, values or report parameters.

Now, have a look to the parameters needed for this object: 122003_Storage_Capacity_by_hostcategories_Pie

You probably noticed that, on the picture above, you do not see the 3 other report parameters needed for this object: hostcategoryID,servicecategoryID,metricNAME. The reason is simple: they are linked to this object using the second method ‘the scripting method’.

The scripting method 2

This method is based on javascript code on the data set : We use this method when the classic method cannot be applied to the type of parameter used. Indeed, injection of multiselect parameters in SQL requests cannot be done using the “classic” method. This is the reason why we use javascript code on data sets to modify the SQL requests at runtime and insert the right multiselect parameters at the right place.

To be able to use multiselect parameters in the SQL request, we use that kind of script in the “beforeOpen”:

var SQL = this.queryText;
this.queryText=SQL.replace(" mbs.hc_id IN (1,2,3,4)"," mbs.hc_id IN("+params["hostcategoryID"].value+")");

Of course, in the SQL request, you can find ‘hc_id IN (1,2,3,4)’

This method is applied to all data sets that use multiselect report parameters.

This method brings two limitations :
  • You cannot see multiselect parameters in the “Parameters” section of objects.
  • You cannot rename multiselect parameters.

Conclusion

Do not only import parameters that you can see in the objects’ ‘Parameters’ section and be sure to check the component documentation to know which parameters to import. Depending on the method used for parameters, you will find method 1 or method 2 next to the parameters’ table in the Report parameters documentation page. Do not forget that parameters using the classic method can be easily overrided by any value, scripts or other report parameters.