When we upgraded to the new Orion schema last year we thought we were extra careful about checking through the schema changes to make sure we didn't break anything, especially since we relied heavily on custom SQL queries for things like reporting and alerting. Then today happened.
One of our teams reached out and asked why an alert for F5 Pool Members wasn't triggering anymore. (And, yes, I know that the next release of NPM will have some more F5 magic! What We're Working on for NPM (Updated January 7th, 2016) So I started to dig into the alert logic. That's odd -- the logic didn't change but because we're using some custom SQL queries in the trigger actions to return things like the pool member name (thanks adatole!) I thought I should start to pull them apart to see how the worked.
Orion 2014.x.x schema has a table called CustomPollerStatusTable that contains the, wait for it, the polled status of values collected by the custom pollers (aka UnDPs)
Orion 2015.x.x schema has a similarly named table called CustomPollerStatus.
The developers conveniently created a SQL view with the old table name. (Nodes vs NodesData is another good example). In this case, there is no such view. There *is* a view called CustomPollerStatusTable but referencing it didn't seem to work in our queries. We updated the table names to reference CustomPollerStatus and we're doing some testing now.
As a heads up, I also found that custom SQL trigger actions converted to schema 2015 have some variables converted from pure SQL to SWQL. When you try and save an alert with trigger actions using both custom SQL and SWQL you get a SWIS reference error. SQL must live with SQL only it seems.
I'll update if this doesn't work as expected.
