Hi Dojo,
I have a question regarding the System Name alarm property and the setting of foreign keys to the Topology Cell table.
A driver has an alarmed SNMP table, which contains a retrieved column to hold the foreign key to a Topology Cell table (Equipment Overview table, with Equipment Name being its primary key).
When a new row is added to this SNMP table via polling, a QAction will then afterwards be triggered to fill in the Equipment Name FK on the just created row.
What we see in the Alarm Console is that the Alarm Properties are filled in correctly except for the automatically set System Name.
I suppose this happens because the Alarm is created after the polling, BEFORE the QAction fills in the right Equipment Name FK, which contains at that point all the data except for the Equipment Name/System Name. After the Equipment Name FK is filled in, the System Name in the Alarm Console isn't updated accordingly, which leads me to believe this FK change didn't trigger a refresh/update event for the Alarm Properties, unlike if any of the other Alarm Property values had changed.
Does anyone know if this is intended behavior? If so, is there a workaround for it? For example, I was looking for a NotifyProtocol Type that I could trigger in the QAction, right after filling in the FK column, that could force a refresh on the Alarm Properties, making them re-evaluate and update their values like when an Alarm property value changes in the driver (the closest I could find is NT_REFRESH_GENERIC_PROPERTIES (206), although I can't find any information about it or how to use it).
Cheers!
Hi Francisco
A possible workaround is to add an extra column in the table that will be the one used for alarming (and where you define the alarm properties).
The original SNMP-retrieved column is not alarming anymore. When a new row is created via SNMP and the FK to the topology cell is filled by the QAction, that same QAction then copies the value from the original column into this 'alarm' column.
Because the alarm is only raised on this column after the FK has been set, the System Name can be resolved correctly at alarm creation time
Regards
Yes, that would be a possible workaround, considering it might be a potential bug according to Davy Degrande.
Another workaround I was thinking on would be to add another Alarm Property that is populated at the same time as when the FK is populated too, inside the QAction (something like "Last Time Updated", for example). Maybe that way, the Alarm Propreties will update as they will notice a change on their linked parameters. I will need to check if this might indeed be the case or not. Thanks!