SRS Clues and Priorities

Understanding Clues

Clues are a subset of all trouble calls (incidents). Clues for a particular customer are whatever that customer has defined to be clues. There are two ways to define which trouble calls are clues:

• CLUE format item in a trouble call itself with a corresponding value of 1 will make the trouble call a clue.

• If any of the trouble codes of a call has been defined in the srs_trouble_codes table to be a clue, then the trouble call will be a clue.

The reason why clues are beneficial is that they have their own SRS broadcast rule broadcastClues. All trouble calls, clues and non-clues alike, will be broadcast by JMService to the outside world (Viewer, interfaces, etc.) if the broadcastIncidents SRS rule is set. This can generate a lot of traffic and can clutter the viewer badly.

By defining as clues a subset of calls that add value to the system and that should be displayed, and by setting the broadcastIncidents SRS rule to 0 and broadcastClues to 1, only what the customer has defined as clues will be broadcast and thus displayed by the Viewer.

The priority and condition status attributes of clues are also computed differently from those of normal trouble calls, as can be seen in the description below:

The Total Priority of a Trouble Call

The total priority of a trouble call is the sum of the priorities of the individual trouble codes of the trouble call. The total priority of a trouble call can be specified in three ways:

1. COMBINE_PRI format item in a trouble call itself with a corresponding value will use that value as the total priority.

2. If the COMBINE_PRI format item is not sent, the total priority will be computed by JMService as the sum of the priorities of the individual trouble codes of the trouble call.

3. A default total priority of 2 is used for "trouble calls" created by CreateEventCommand.

The Priority of a Trouble Call

The lower the value for priority, the higher the priority of the call. There are 4 ways to set the priority of a trouble call:

1. CUST_PRIORITY format item in a trouble call specifies the priority of the customer calling. If cusPriority SRS rule is used to specify the mappings from customer priorities to SRS priorities, then the value corresponding to this format item will be used to set the priority of the trouble call UNLESS rule 2 described below provides a smaller priority value (higher priority).

2. CUST_TROUBLE_CODE format item in a trouble call specifies the trouble codes of the call. priority column in srs_trouble_codes specifies the priority value of each trouble code. The lowest priority value of the trouble codes of the call will be used UNLESS rule 1 described above provides a smaller priority value (higher priority).

3. If the trouble call is a clue or if the useTotalPriority SRS rule is set, the priority of the trouble call is set to the total priority of the trouble call. This rule will override rules 1 - 2.

4. A default priority of 2 is used for "trouble calls" created by CreateEventCommand.

The Total Priority of an Event

The total priority of an event is the sum of the priorities of the unique trouble codes for all of the trouble calls that comprise an event.

Example:

The priority of the 'LTS OUT' trouble call has been previously determined to have a value of 3500. The priority of a 'LTS OUT-BROKEN POLE' trouble call has been previously determined to have a value of 6300.

By default, and event comprised of 5 'LTS OUT' and 1 'LTS OUT-BROKEN POLE' calls would have a total priority value of 9800 (3500 + 6300).

This default behavior can be overridden to calculate the total priority of the event to be the sum of ALL trouble call priorities by setting the sumOfAllTcodePri SRS rule. With that rule set, the example above would then be calculated to have a total priority value of 23800 (3500 x 5 + 6300).

The Condition Status of a Trouble Call

The condition status of a trouble call is used to determine what symbol to display for an outage. A symbol must be defined for every possible condition status. The condition status of a trouble call (incident) can be computed in the following four ways:

1. CUST_STATUS format item in a trouble call itself with a corresponding value will use that value as the condition status.

2. If the CUST_STATUS format item is not sent and the trouble call IS a clue, the condition status will be the highest combined priority value of the trouble codes of the trouble call. The combined priority values of trouble codes are specified in the combine_pri column of the srs_trouble_codes table.

3. If the CUST_STATUS format item is not sent and the trouble call is NOT a clue, the condition status will be the priority of the trouble call.

4. A default condition status of 2 is used for "trouble calls" created by CreateEventCommand.

Understanding Priority Calls

Priority calls are calls that have a priority value (computed as detailed above) within the interval defined by priorityCallMin and priorityCallMax SRS rules.

Many customers display on their Work Agenda the total number of priority calls. Others may want to display their priority calls in different groups. This is achieved by specifying entries of trouble code matching criteria in the call_quality table for up to 4 different groups (pri_w, pri_sw, pri_p, pri_e).

Furthermore, some customers want an extra alarm row for each priority call on the Work Agenda. This is achieved by setting the priorityIncAlarm SRS rule.