What is the best way to combine data retrieved from a remote source and calculated info in the same table?
For example, in the protocol definition I have 3 columns are retrieved from an external source (via WMI or via SNMP) : this data is filled in immediately in the table.
Due to this, the existing calculated values are cleared.
Logic in a QAction will calculate and set data in 2 other columns of that table.
When an alarm in configured on these calculated values the root time will be reset every time the data is filled in.
1. How can I avoid the clearing of the calculated data and thus have a root time that is really the root time and not the last updated time?
2. Or do I always need to make a hidden buffer table and copy all the retrieved data into a fully customized table (will extra logic and system load needed to keep the 2 tables in sync)?
3. Do you have any practical coding example how to best integrate this need?
When you have a table that contains data retrieved via polling (snmp for example) and you need additional columns that are filled in from a QAction (for example calculated values like bitrates), these additional columns can be added in the same table and will have the type set to "retrieved" or "custom". More information when to use which type can be found in the help.
The parameter id of the table should be set as trigger of your QAction and will execute the QAction each time there is a change after polling. Polling the snmp data should not clear your retrieved/custom columns in your table (if that is the case please share the actual example where you encounter this). The QAction will trigger and is used to update the values in your columns based on the newly retrieved snmp data.
Off course, there could be specific situations where you will want to create a dedicated custom table for calculated values or to combine data from multiple (snmp) tables. This depends on the situation though and needs to be evaluated case by case.
[Update (see comment)]In case of wmi tables (updated via wmi actions), by default the data in the "retrieved" columns is cleared when the table is updated after receiving the wmi data. However, you can make sure this doesn't happen by adding an additional state column which will make sure the retrieved column data (not retrieved via wmi polling) is not cleared on every wmi polling update. Your table definition would then look like this:
In this example, column with pid 63 is a retrieved column (filled in manually or via a QAction) and column with pid 64 is a state column which makes sure the data in column 63 is not cleared on every wmi update. The delete option added to the state column definition is to make sure that rows that are no longer received via wmi are automatically deleted (which is not the case if this option is not configured). All other columns in this example are filled in via wmi.
Hi Mieke,
I’m no wmi expert myself, but I did a quick test and updated the answer above (with a screenshot) of an example how to make sure wmi polling does not automatically clear your retrieved columns.
This is not very clear from our current documentation and I’ll check to make sure this can be added.
Also note that my comment still stands that choosing for a separate table to combine the wmi data with additional (calculated) data is still an option and can be decided case by case.
Hi Joey,
Thank you for your reply. You mention that the calculated data (filled in via QAction in a retrieved column) will not get cleared when polling the SNMP data.
Can you also confirm if this is the case for WMI queries?
My case uses WMI queries (action) to fill in the 3 columns.