Méthodes: Gestion des paramètres et des Data sets

Dans Centreon MBI, nous utilisons deux méthodes différentes pour gérer les lien entre les datasets, les objets de type “paramètre” et les paramètres de rapports. Ces deux méthodes utilisées pour injecter les paramètres dans les requêtes SQL sont décrites ci-dessous

These two parameters management methods are used with data sets based on JDBC data sources.

La méthode de biding classique 1

Cette méthode est basée sur le caractère ‘?’ de la requête SQL du data set: Dans ce cas de figure, les paramètres demandés sont listés dans l’onglet ‘Parameters’ du data set. Chaque paramètre peut être directement lié à un objet ‘paramètre de rapport’ ou alors rempli avec une valeur par défaut (nombre, chaîne de caractères ou code javascript...). Quand des paramètres sont renseignés avec des caleurs par défaut, celà veut dire qu’ils seront surchargés plus tard.

Les paramètres créés en utilisant cette méthode sont visibles dans la section ‘Parameters’ de l’objet qui utilise le data set. Jetez un oeil à l’exemple ci-dessous:

../_images/DS_parameter_tab.png

Sur la capture ci-dessus, nous avons 3 cas différents de la méthode classique:

  • Le paramètre ‘dateEnd’ est rempli avec la fonction javascript (‘BirtDateTime.addDay(params[“dateEnd”].value,-1)’)
  • Le paramètre ‘hg_id’ est rempli avec la valeur par défaut ‘88’
  • Le paramètre ‘liveserviceID’ semble ne pas être rempli, mais en réalité, le binding est fait au niveau du data set. Quand les paramètres sont liés au niveau du data set, ils n’appraissent pas dans les paramètres du graphique ou du tableau.

Ce qu’il faut que vous sachiez ici, c’est que vous avez au moins à surcharger le paramètre ‘hg_id’ et importer 2 paramètres nommés ‘dateEnd’ et ‘liveserviceID’. Si vous n’importez pas ces 2 paramètres, ils faut surcharger les paramètres d’objet ‘dateEnd’ et ‘liveserviceID’.

Tous les paramètres utilisants cette méthode peuvent être surchargés avec valeurs fixes, du scripting ou alors des paramètres de rapports.

Maintenant, jetez un coup d’oeil sur les paramètres dont l’objet 122003_Storage_Capacity_by_hostcategories_Pie a besoin.

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 Composants de la bibliothèque des paramètres de rapports documentation page. Do not forget that parameters using the classic method can be easily overrided by any value, scripts or other report parameters.