Hi everybody!
You are absolutly right, the creating of dynamic views templates are probably the most difficult aspect of using SDP!
When starting designing SDP we did not believe it would become such a popular feature (in fact we mainly believed this would be a feature used by Nimsoft staff).
I hope the following comments will help you understand how the templates work and what they can offer. We're in the process of redesigning the support for 'dynamic views' (and will of course also support the existing) and when this is completed the corresponding support in SDP/UMP will be documented in a much better way.
Anyway here are the answers to your questions.
Hidden variables
Yes, there is a list of ‘hidden’ variables, which variables depend on type of dynamic views dashboard template you are working on.
The list of variables for a template matches the columns in a table in the NIS database matching the type of dynamic views template as follows, just put a $ in front of the column name to make it a variable:
- Server templates have variables which match the columns in the table grp_server
- Connectivity templates variables which match the columns in the table grp_connectivity
- Interface templates variables which match the columns in the table grp_interface
Alarm filter
DD_Override is a value you will see for some fields in the alarm filters for dynamic views templates and is mainly there to indicate that the probe dashboard_engine will overwrite whatever is in this field when the template is instantiated to a dashboard. For example the field Robot in a server template will be overwritten with the content of the cell defined by column robotname and the corresponding row in grp_server.
Probe requests
<DataProbe robot="/SDP/van01/van/01" is actually rather misleading. When a probe request is defined in a dynamic views template, the address of the probe is just a placeholder. Typically when you design the template you will chose the probe offering the information you would like to display. As long as you can access the probe from DashboardDesigner you can chose any such probe, f.ex. the local cdm probe or another cdm probe running on a different robot/hub. As long as the probe can offer the set of callbacks you require you’re fine since the probe dashboard_engine will, when template is instantiated to dashboard, use the address defined by the server (/domain/hub/robot/) to address the correct probe. The address /SDP/van01/van01 only exists because this was the server the template was originally developed against at Engineering in Nimsoft.
The explanation above should also answers the question regarding addressing probes, all probe requests are modified to point to the probe related to the node/server the mapped against.
spn_dp_TemplateTabelExpander
No, there is sadly no other procedures like spn_dp__TemplateTableExpander_01. However the good news is that you can easily write your own. The purpose of these procedures is to allow the dashboard_engine to create the required sql for the related table widget the instantiated dashboard. The dashboard_engine will at that time edxecute the procedure (using any supplied arguments, and a few which is supplied by dashboard_engine by default). Before starting to create your own procedures you should make sure you understand how spn_dp__TemplateTableExpander_01 works. You can then create say spn_dp__TemplateTableExpander_02 and use this in the widget’s datasource.
Regards,
Guttorm