The Self Service Alerts functionality allows threshold, duration and enabled settings of alert definitions to be modified at run-time. Alert definitions are created in the Display Builder and are generally loaded at startup by the Display Server and Data Server. However, sometimes end-users of RTView prefer to modify alert settings at run-time rather than reload a modified alert definition. To enable run-time modification, current values of alert settings are maintained in a database. Optionally, this database can also store an audit trail tracking who has modified alert settings and when those changes were made.

To enable and configure Self Service Alerts and the database to persist alert settings, go to the Self Service Alerts tab in the Application Options dialog. To provide end-users with an interface to modify alert settings, a Self Service Alerts demo is included that can be used stand-alone or integrated into your RTView application.

Two database tables are used for Self Service Alerts: the Alert Settings Table is required and the Self Service Audit Table is optional. An hsqldb database that contains these tables is provided as part of the Self Service Alerts demo. NOTE: For other database types, the demos\selfservicealerts\dbconfig directory contains .sql files with the correct table schemas and a README.txt that explains how to use them.

Alert Settings Table
When Self Service Alerts are enabled, RTView will attempt to connect to the Alert Settings Table in the specified Self Service Alerts Database. NOTE: No alert configuration files will be processed until it receives the first update of this table.  To view your Alert Settings Table table, make a data attachment to the Alert Settings Table from the Attach to Alert Data dialog.

Column names, types and order must match exactly.

For all alert types, when the alert is loaded RTView will look for a row in the Alert Settings Table with that alert name. If it isn't found, a row will be added. Once the row has been added, the value in the database will be used instead of the value in the property sheet for the corresponding properties. Note that the specified database and table(s) will apply to all alerts; there is no flag to indicate that for a single alert you want to use the values in the property sheet instead of the database.

The initial values for the DURATION and ENABLED fields will be set from the alertDelayTime and enabledFlag properties respectively. For an Event alert, only the ENABLED field will be set. WARNINGLEVEL, ALARMLEVEL and DURATION are not supported for Event alerts. For all other alerts, values for ALARMLEVEL and WARNINGLEVEL will be set from different properties depending of the alert type:

• For a Limits alert, the valueHighAlert and valueHighWarning properties map to the ALARMLEVEL and WARNINGLEVEL fields. If these are both disabled, the valueLowAlert and valueLowWarning properties are used. If either valueHighAlert or valueHighWarning are enabled, then valueLowAlert and valueLowWarning are not mapped to the database even if they are enabled (they'll use the values in the property sheet). NOTE: If only one threshold is enabled only that value will be added to the table and the value for the other field will be inserted into the database as NaN which indicates that the value isn't used.
   
• For a Discrete alert the valueHighAlert property maps to the ALARMLEVEL field and the valueLowAlert property maps to the WARNINGLEVEL field. Again, only fields that are enabled are mapped and written to the database. The valueMediumAlert property is never mapped to a field in the database. NOTE: ALARMLEVEL and WARNINGLEVEL database columns are of type Double, so string thresholds cannot be entered in the database.
   
• For a Multi State alert, AlertState01Comparison is mapped to ALARMLEVEL and AlertState02Comparison is mapped to WARNINGLEVEL. Again, only fields that are enabled are mapped and written to the database. Also be aware that range comparison types are not mapped to the database, nor are any alert states beyond Alert State 02. NOTE: ALARMLEVEL and WARNINGLEVEL database columns are of type Double, so string thresholds cannot be entered in the database.
• For an Event alert, only the ENABLED field can be set. The WARNINGLEVEL, ALARMLEVEL, and DURATION are not supported.

Self Service Audit Table
If Self Service Alerts are enabled and a Self Service Audit Table is specified on the Self Service Alerts tab of the Application Options dialog, then RTView will insert an entry into the Self Service Audit Table each time it makes a change to the Alert Settings Table. To view your Self Service Audit table, make a data attachment to the Self Service Audit Table from the Attach to Alert Data dialog.

Column names, types and order must match exactly.

The Self Service Audit Table contains the TIME_STAMP of the change, the USER that made the change, the ACTION that was done, plus row information.

• If the USER listed is RTView.GmsRtViewAlertDs, this indicates that RTView made the change. This happens when a row is added for a new alert, when the threshold enabled flag for an alert that was already in the database changes and when a row is removed due to a selected Clean Settings Table On Startup option.
• If the USER value is No Login, this indicates that no value was specified for the user in the Update Self Service Alerts command. This could be because RTView login is disabled or because the command was not configured to include a user name.

Alert Construction Limitations
The following limitations apply when creating alerts to use with Self Service Alerts:

• Alerts can only use numeric threshold values
• Alerts can only use 1 or 2 thresholds:
  • Limits alerts can use valueHighAlert and valueHighWarning or valueLowAlert and valueLowWarning
  • Discrete alerts can use valueHIghAlert and valueLowAlert
  • Multi-state alerts can use AlertState01Comparison and AlertState02Comparison.
• Threshold values cannot be attached to data.