Alert Paging Description

The following sections detail the customer requirements and the work, which will be provided by Longview Software in meeting this functionality.

Remote Management of Paging Profiles

Requirements specify the need to remotely be able to make changes to personal paging profiles.  To meet this requirement Longview Software will be adding onto the NETeXPERT Web Alert architecture.  This will allow a user to access their own paging profiles anytime and anywhere within a browser. To allow for market and/or customer separation, paging definitions and personnel are associated with Operator Groups. This allows operators to only see and manage paging data within their own Operator Group as specified within the VSM Auth Editor. Another new feature, Operator Filters, can be used to help admins manage Operator Groups. The Operator Filters screen (discussed separately as a stand alone feature) allows an admin to quickly view operators and their Operator Groups among all registered VSM systems. It is important to have operators in the same Operator Group in every registered VSM system!

Summary of Paging Requirements

The following use cases have been provided:

Summary of Paging Requirements	In/Out of Scope?
The user should be able to remotely update personnel’s profile of paged alarmed events.	Yes in Scope
Add/remove a managed site to a tech’s profile	Yes
Add/remove a “Loss of Signal” alarm for a cell tech or a “EQUIPMENT FAIL” for a tech)	Yes
Update personnel’s profile schedule.	Yes
Redirecting the pages of a tech to another tech or adding a 2nd tech to the paging profile)	Yes
Make changes in paging profile to reflect a time shift change	Yes
Update personnel’s profile to reflect urgency/escalation pages.	Yes
Add/remove critical levels from profile.	Yes
Make changes to delays in event pages to be sent.	Yes

 

Paging Definitions

 

Paging is initiated based on a Paging Definition (PD).

 

Below is a mock-up of this new page.

Figure 1: Paging Definition

Each PD can match against more than one alert but special care should be taken so that a single alert does not trigger more than one PD unless this is specifically desired behavior.

 

PD Trigger

 

See Figure 1 (top left section)

A PD consists of a table of alert field/regular expression pairs and a type of  ‘All’ or ‘Any’, much like the Web Alert filter definitions. Additionally, a PD will have an option to ignore alert updates and only trigger when the alert is created.

 

PD Severity Delay

 

The second portion of a PD is the Severity Delay (See Figure 1 – bottom right section)

 

A Severity Delay can be defined for each alert severity since a PD may define more than one alert and alerts may change severity over time. The time delay is specified in minutes. No page will be sent if the alert severity is not set to be active. After the delay period has expired the page will be sent to specified recipients if the alert that triggered this paging event still exists.

 

PD Message Content

 

The last portion of the PD is the contents. (See Figure 1 – top right section)

 

The contents are defined in two sections.

 

• The first section is a free form text field for a user-defined message.
• The second is a list of alert fields for including alert data in the page. You may also enter alert fields manually using the syntax ${Field} but you should ensure the field you type is valid.

 

PD Subscriber List

Every PD must have a Subscriber List. (See Figure 1 – bottom left section)

A Subscriber List is a set of Personnel to be paged when the PD is triggered.  The following behavior is listed for the Subscriber List:

 

• The order of this list determines the order in which personnel will be paged.
• Each entry will be accompanied by a Resolution Time, which gives paged personnel a window of time to resolve the alert condition.
• Alert condition resolution is determined based on whether or not the alert still exists in the system.
• A cleared alert will result in the end of paging any more personnel.
• If no Resolution Time is specified for a personnel entry, then paging will end if there are no more personnel entries, or immediately the page will be sent to the next personnel listed.
• It is important to note that the subscriber list must take into account personnel availability in order to ensure that pages are actually sent. Pages will not be sent to personnel when the page occurs during a time when they are unavailable. In case of unavailability the next personnel entry in the list will be evaluated immediately.
• One way to ensure someone will be paged is to list personnel in order based on availability.
• For example, if Joe is on call during weekdays only and Marry is on call during weekends only, you should list Joe first and Mary second.

 

Personnel

Personnel must be defined for anyone who will receive pages.

Figure 2: Personnel Definition Mock Up

 

Each personnel entry must include:

• first name
• last name, and
• e-mail address. (E-mail address is required because the paging system will only implement e-mail paging at this time.)

Personnel may have a defined availability schedule. Pages will only be sent to personnel when the page occurs within their defined availability, as discussed above.

Management of personnel is done in a floating window on the same screen as the PDs. It can float above the other elements so it’s always available while trying to define a PDs subscriber list. The personnel window will show a list of all personnel with simple filtering ability to narrow the list. Each entry allows personnel to be enabled or disable. For example, if Joe goes on vacation for a week you can set him as disabled (represented by the red cross) and any PDs that reference Joe will skip over him. To edit personnel’s availability just click on the edit link under the enabled/disabled icon.

 

 

 

 

Paging Interfaces

 

Original requirements specified different paging interfaces.  The customer has narrowed the scope to email as the primary requirement.

 

Multiple paging devices are specified in the table below:

 

Paging Interface Type	In/Out of Scope
1) Email output via SMTP to the cell phone or pager.	In Scope
2) SNPP – Ability to send messages to  SMS gateways directly.	For future consideration.
3) SMS output via modem or network to cell phone or pager.	Via Email (see above #1)
4) TAP message output via modem or network to cell phone or pager.	For future consideration.

 

 

Please feel free to send us your feedback

This e-mail address is being protected from spam bots, you need JavaScript enabled to view it