Escolar Documentos
Profissional Documentos
Cultura Documentos
Administrator Guide
Version 6.2.0
Copyrights Copyright 2005 - 2009, 2010 MIR3, Inc. TelAlert 6e Administrator Guide This document is copyrighted and all rights are reserved. The distribution and sale of this product are intended for the use of the original purchaser only per the terms of the Agreement. This document may not, in whole or part, be copied, photocopied, reproduced, translated, reduced, or transferred to any electronic medium or machine-readable form without prior written consent in writing from MIR3, Inc. MIR3, TelAlert, IN, inEnterprise, inEnterprisePRO, inAlertCenter, inAlertCenterPRO, inCampusAlert inGovAlert, inGovAlertPRO, inSalesTalk, inTechCenter, inTechCenterPRO, inWebServices, inConnect, inConsole and Enterprise Access Control are trademarks of MIR3, Inc. All other product and company names are marks of their respective holders. This document is the property of MIR3, Inc. and may not be distributed in any manner except with the express written permission of MIR3, Inc.
MIR3, Inc. 3398 Carmel Mountain Road San Diego, CA 92121 Phone: 858.724.1200 Fax: 858.724.1201
Preface
The TelAlert 6e Version 6.2 Administrator Guide describes how to use the TelAlert 6e software. It can run on all major platforms (Sun Solaris, Windows, HP-UX and Linux), and use all major relational databases (Oracle, Microsoft SQL Server, and MySQL). The information in this document is accurate regardless of the platform or database used to support the TelAlert 6e system. This Guide does not include instructions about how to install, configure or integrate the TelAlert 6e system with third-party data sources.
Table of Contents
Introduction ................................................................................... 1
1.1 1.2 Overview .......................................................................................... 1 Guide Introduction .............................................................................. 1 1.2.1 Contents ....................................................................................... 1 1.2.2 Audience....................................................................................... 1 1.2.3 Related Technical Documentation ...................................................... 2 1.3 Product Support Contact Information...................................................... 2 1.4 TelAlert Solutions from MIR3 ............................................................... 2 1.5 Guide Conventions .............................................................................. 3 1.5.1 Screen Captures ............................................................................. 5 1.5.2 File Locations ................................................................................. 5 1.6 Structure of the Administrator Guide ...................................................... 5 1.6.1 Chapter 1: Introduction ................................................................... 5 1.6.2 Chapter 2: What is TelAlert 6e .......................................................... 5 1.6.3 Chapter 3: Technical Overview .......................................................... 5 1.6.4 Chapter 4: Implementation Planning .................................................. 5 1.6.5 Chapter 5: Configuration Basics ........................................................ 5 1.6.6 Chapter 6: The Role of Ports in TelAlert .............................................. 6 1.6.7 Chapter 7: Dialing the Telephone....................................................... 6 1.6.8 Chapter 8: Configuring for Paging Notification ...................................... 6 1.6.9 Chapter 9: Configuring for Text to Speech (TTS) Notification .................. 6 1.6.10 Chapter 10: Configuring for Other Notification Media ........................... 7 1.6.11 Chapter 11: Applying Filtering Techniques ......................................... 7 1.6.12 Chapter 12: Setting Up and Applying Schedules.................................. 7 1.6.13 Chapter 13: Representing Users ...................................................... 7 1.6.14 Chapter 14: Enabling Responses ...................................................... 7 1.6.15 Chapter 15: Broadcasting to Groups and Creating Escalations ............... 8 1.6.16 Chapter 16: Processing Events ........................................................ 8 1.6.17 Chapter 17: Miscellaneous Administrative Tasks ................................. 8 1.6.18 Chapter 18: TelAlert Monitor ........................................................... 8 1.6.19 Chapter 19: Security Features ......................................................... 8 1.6.20 Chapter 20: Integrating XML Output ................................................. 8 2.1 2.2 Overview .......................................................................................... 9 What is TelAlert 6e? ............................................................................ 9 2.2.1 Messaging Component ..................................................................... 9 2.2.2 Configuration Tools ......................................................................... 9 2.2.3 Add-On Product Modules ................................................................ 10 2.2.4 Two-Way Pagers .......................................................................... 11 2.2.5 WAP- and SMS-Enabled Cell Phones ................................................. 11
2.3
2.2.6 Applet-Based Remote Interactions ................................................... 11 TelAlert Text to Speech (TTS) ............................................................. 11 2.3.1 Full Range of Voice Destinations ...................................................... 11 2.3.2 Customizable Vocabulary in Four Languages ...................................... 11 2.3.3 Interactive Voice Response (IVR)..................................................... 11 2.3.4 Dialogic Telephony Card................................................................. 11 2.4 TelAlert 6e Integrations ..................................................................... 12 2.4.1 TelAlert 6e Integration Templates for Third-Party Applications ............... 12 2.4.2 Do-it-Yourself Integrations for In-House Applications........................... 12 2.5 Supported Platforms.......................................................................... 13 2.5.1 Web Server ................................................................................. 13 2.5.2 Database Server........................................................................... 13 2.5.3 Messaging Server and Client Platforms ............................................. 14 2.5.4 Client Platforms............................................................................ 15 2.5.5 Operating Systems Not Supported for Version 5.7 .............................. 17 2.6 TelAlert 6e Documentation ................................................................. 17 2.6.1 TelAlert 6e Administrator Guide ....................................................... 17 2.6.2 TelAlert 6e Installation Guide .......................................................... 17 2.6.3 TelAlert 6e Online Help .................................................................. 17 2.6.4 TelAlert 6e Keyword and Command Reference ................................... 17 2.6.5 Integration Instructions ................................................................. 18 2.6.6 TelAlert 6e Failover Module Guide .................................................... 18 2.7 TelAlert Messaging Server File Locations ............................................... 18 3.1 3.2 Overview ........................................................................................ 19 How TelAlert Messaging Server Works .................................................. 19 3.2.1 A Typical Alert ............................................................................. 20 3.3 Server Processes and Command Line Clients.......................................... 21 3.4 Server Processes .............................................................................. 21 3.4.1 telalerte (TelAlertE.exe) ................................................................. 21 3.4.2 telaconfe (TelaConfE.exe) .............................................................. 21 3.4.3 telalertd (TelAlertD.exe) ................................................................ 22 3.4.4 telalertf (TelAlertF.exe).................................................................. 22 3.4.5 telalertm (TelAlertM.exe) ............................................................... 22 3.4.6 telalertr (TelAlertR.exe) ................................................................. 22 3.4.7 telalerts (TelAlertS.exe) ................................................................. 22 3.4.8 telalertv (TelAlertV.exe) ................................................................. 22 3.4.9 readmail (ReadMail.exe) ................................................................ 22 3.4.10 ntfysrvr (NtfySrvr.exe) ................................................................ 22 3.4.11 hostaddr (HostAddr.exe) .............................................................. 22 3.4.12 killtela (KillTela.exe) .................................................................... 23 3.4.13 mailaddr (MailAddr.exe) ............................................................... 23 3.5 Command Line Clients ....................................................................... 23 3.5.1 telalert (TelAlert.exe) .................................................................... 23
3.5.2 telalconf (TelaConf.exe) ................................................................. 23 3.5.3 telalertc (TelAlertC.exe) ................................................................. 23 3.5.4 telalerth (TelAlertH.exe) ................................................................ 23 3.5.5 telalerths (TelAlertHS.exe) ............................................................. 24 3.6 Key TelAlert Files .............................................................................. 24 3.6.1 telalert.trail ................................................................................. 24 3.6.2 telalert.alert ................................................................................ 24 3.6.3 telalert[e/f/r/s/d/m/h/v].log ........................................................... 24 3.6.4 telalert.sects................................................................................ 24 3.6.5 telalert.ini ................................................................................... 24 3.7 Key Configuration Concepts ................................................................ 25
5.7
Using TelAdmin to Configure TelAlert Messaging Server ........................... 49 5.7.1 About TelAdmin............................................................................ 50 5.7.2 The TelAdmin Window ................................................................... 50 5.7.3 Configuring TelAlert Messaging Server .............................................. 51 5.7.4 Making Configuration Changes ........................................................ 51 5.7.5 TelAdmin Menu Items.................................................................... 52 5.7.6 Importing Data from Windows Clipboard ........................................... 54 5.7.7 Desktop Locking ........................................................................... 56 5.8 Understanding Configuration Examples ................................................. 57 5.9 What is TheTelAlert 6e Web Interface?.................................................. 58 5.10 Logging In ....................................................................................... 59 5.11 Navigating....................................................................................... 60 5.11.1 Home ....................................................................................... 61 5.11.2 Alerts ....................................................................................... 62 5.11.3 Users........................................................................................ 64 5.11.4 Devices ..................................................................................... 64 5.11.5 Groups...................................................................................... 65 5.11.6 Schedules.................................................................................. 65 6.1 6.2 6.3 6.4 Overview ........................................................................................ 67 What is a Port? ................................................................................. 67 Basic Port Considerations ................................................................... 68 If You Are Using a Terminal Server....................................................... 71 6.4.1 Testing Connectivity on a Terminal Server ......................................... 72 6.5 More Advanced Port Considerations ...................................................... 72 6.5.1 Directing Specific Notifications to Specific Ports .................................. 72 6.5.2 Providing Port Backup.................................................................... 74 6.5.3 Controlling Port Deactivation Due To Errors ....................................... 75 6.5.4 What Remote Ports Are Used For ..................................................... 76 7.1 7.2 Overview ........................................................................................ 79 Whats So Hard About Dialing the Phone? .............................................. 79 7.2.1 Local Dialing ................................................................................ 80 7.2.2 Alternate Numbers........................................................................ 80 7.2.3 Inside and Outside Lines ................................................................ 80 7.2.4 Special Dialing Scenarios ............................................................... 80 7.2.5 Dialing After the Main Number is Answered ....................................... 80 7.2.6 Inserting Pauses During Dialing ....................................................... 80 7.3 Dialing Logic .................................................................................... 81 7.3.1 Dialing Components ...................................................................... 81 7.3.2 Dialing Process............................................................................. 82 7.4 Local Dialing .................................................................................... 82 7.4.1 Normal Local Dialing ..................................................................... 82 7.4.2 Ten-Digit Local Dialing ................................................................... 83
7.5
7.4.3 Eleven-Digit Local Dialing ............................................................... 83 Long Distance Dialing ........................................................................ 83 7.5.1 Normal Long Distance Dialing ......................................................... 83 7.5.2 Other Long Distance Dialing............................................................ 84 7.5.3 Alternate Numbers........................................................................ 84 7.6 Inside and Outside Lines .................................................................... 85 7.6.1 Getting an Outside Line ................................................................. 85 7.6.2 Getting an Inside Line ................................................................... 85 7.7 Special Dialing Scenarios.................................................................... 86 7.8 Dialing After the Main Number is Answered............................................ 86 7.8.1 Dialing a Number, Then an Extension ............................................... 86 7.8.2 Dialing a Number, Then Accessing a Mailbox ...................................... 87 7.9 Inserting Pauses During Dialing ........................................................... 87 7.10 Specifying Telephone Dialing Components at the Command Line................ 88 7.11 Overriding the Need for Dialtone.......................................................... 88 8.1 8.2 Overview ........................................................................................ 89 Getting Started ................................................................................ 89 8.2.1 Needed Information ...................................................................... 89 8.2.2 General Considerations .................................................................. 90 8.3 Setting Up Text Paging ...................................................................... 91 8.3.1 Creating a Text Pager [Configurations] Definition................................ 91 8.3.2 Pointing to a Modem ..................................................................... 91 8.3.3 Creating a Text Pager Destination .................................................... 92 8.3.4 Sending a Page by Invoking a Destination ......................................... 93 8.3.5 Sending a Page Without Invoking a Destination .................................. 93 8.3.6 Sending to Text Pagers via [Configurations] Definitions of Type=InteractiveTextPager .................................................................... 93 8.3.7 Sending Text Pages via Modem without TAP (Protocol=Chat) ................ 94 8.4 Setting Up Numeric Paging ................................................................. 98 8.4.1 Sending Numeric Pages Using the TAP Protocol .................................. 98 8.4.2 Sending Numeric Pages Without TAP ................................................ 99 8.5 Setting Up Two-Way Paging .............................................................. 102 8.5.1 Creating a Two-Way Pager [Configurations] Definition ....................... 102 8.5.2 Pointing to a Modem ................................................................... 103 8.5.3 Creating Two-Way Pager Destinations ............................................ 104 8.5.4 Enabling Responses .................................................................... 104 8.5.5 Enabling Polling .......................................................................... 107 8.5.6 Enabling Notifications .................................................................. 107 8.6 Setting Up Requests: Unsolicited Messages From Two-Way Pagers ........... 108 8.6.1 Receiving Requests ..................................................................... 108 8.6.2 Having Requests Trigger [Notifications] Actions ................................ 108 8.6.3 Simulating Requests for Testing Purposes ....................................... 108 8.7 Setting Up Internet-Based Paging ...................................................... 109 8.7.1 One-Way Internet-Based Paging.................................................... 109
8.8
8.7.2 Two-Way Internet-Based Paging.................................................... Initiating Pages via Email ................................................................. 8.8.1 Responses to Two-Way Email-Based Text Pages ............................... 8.9 Adding ID Numbers to Pages ............................................................ 9.1 9.2
10.10.2 TelaConsole ........................................................................... 144 10.10.3 AS/400s ................................................................................ 144 10.11 Sending Text Messages to Web-Enabled Phones ................................... 145 10.12 Sending Text Messages to Nextel Cellular Phones ................................. 146 10.13 Sending One-Way Text Messages to GSM Cellular Telephones Modem....... 147 10.14 Sending Two-Way Text Messages to SMS Mobile Telephones Via a GSM Wireless Modem .................................................................................................. 148 10.14.1 Set-Up During Installation......................................................... 148 10.14.2 New Technique in TelAlert 5.4 ................................................... 148 10.14.3 Differences Between the Two Techniques ..................................... 149 10.14.4 Samples for Both Techniques..................................................... 150 10.15 Sending Text Messages to a DN400E Fax Modem .................................. 154 10.16 Sending a File or a Line from stdin as a Message .................................. 155 10.16.1 Sending a File as a Message ...................................................... 155 10.16.2 Sending a Line from stdin as a Message ...................................... 156 10.17 SMPP............................................................................................ 157 10.17.1 SMPP Confirmed Delivery Option ................................................ 157 10.17.2 SMPP Sample Configuration....................................................... 157 10.18 WCTP Proxy Configuration ................................................................ 158
11.9 Filtering Messages by Source ............................................................ 11.10 Pattern Matching ............................................................................ 11.10.1 Other Uses............................................................................. 11.10.2 Pre-Defining Regular Expressions ............................................... 12.1 Overview ...................................................................................... 12.2 Getting Started .............................................................................. 12.2.1 What are Schedules? ................................................................. 12.2.2 Needed Information .................................................................. Managing Schedules ................................................................................ Schedule Types .................................................................................. Viewing Schedules .............................................................................. 12.3 Scheduling Approaches .................................................................... 12.3.1 Schedules and Default Logic........................................................ 12.4 Assigning Device Schedules .............................................................. 12.4.1 Adding a New Device Schedule .................................................... 12.5 Creating Group Member Schedules..................................................... 12.5.1 Assigning Group Member Schedules ............................................. 12.5.2 Effect of Time Zones.................................................................. Creating Extra Duty Schedules .............................................................. 12.5.3 Schedules and [Filter] Definitions ................................................. 12.5.4 Schedules and [User] Definitions ................................................. 12.5.5 Schedules and Message Priority ................................................... 13.1 Overview ...................................................................................... 13.2 Getting Started .............................................................................. 13.2.1 What Are Users? What Are They For? ............................................ 13.2.2 Needed Information .................................................................. 13.3 User Roles ..................................................................................... 13.3.1 Key Principles........................................................................... 13.3.2 Definitions ............................................................................... 13.3.3 Viewing Tabs............................................................................ 13.3.4 Role Editor Screen .................................................................... 13.4 Managing Users.............................................................................. 13.4.1 Adding Users............................................................................ 13.5 Creating a [User] definition: Essentials ............................................... 13.6 Values for Inheritance by Associated Destinations ................................. 13.6.1 Direct Inheritance ..................................................................... 13.6.2 Minimum of the [User] Value and the [Destinations] Default ............. 13.6.3 Maximum of the [User] Value and the [Destinations] Default............. 13.6.4 Maximum of the [User] Value, the [Destinations] Default, and the [Configurations] Value......................................................................... 13.7 Values for Dial-in and Dial-out Access ................................................. 13.8 User-Based Administrative Techniques ................................................
178 178 179 180 183 183 183 184 184 184 185 186 186 187 190 191 192 193 194 194 194 195 197 197 197 198 198 198 198 199 200 207 207 213 213 213 214 214 214 214 215
13.8.1 Viewing Messages: -show ........................................................... 215 13.8.2 Getting Rid of Messages: -clear and -release .................................. 216 13.8.3 Listing Users ............................................................................ 216
16.6.3 Escalations Involving Subgroups .................................................. 253 16.6.4 Balancing Workloads by Rotating the First Destination ..................... 255 16.6.5 Schedules and Escalation ........................................................... 256
18.5.3 Using the Web Clients with Web-Enabled Cell Phones....................... 18.5.4 Installing Online Help for the Web Clients ...................................... 18.5.5 Configuring telalerth with telalerth.ini ........................................... 18.5.6 Other Keywords........................................................................ 18.6 Setting up Logging .......................................................................... 18.6.1 Default Log Files ....................................................................... 18.6.2 Setting Maximum Sizes .............................................................. 18.6.3 WriteExecsToTrail ..................................................................... 18.6.4 Configuring Additional Logging Behavior ........................................ 18.7 Miscellaneous Administrative Tasks .................................................... 18.7.1 Specifying Maximum ID Assignments............................................ 18.7.2 Viewing Listen Sockets............................................................... 18.8 TelAlert Web UI Administrative Tasks ................................................. 18.8.1 Importing Data......................................................................... 18.8.2 Changing the Color Theme.......................................................... 18.8.3 Managing Configurations ............................................................ 18.8.4 Managing Departments .............................................................. 18.8.5 Managing Holidays .................................................................... 18.8.6 LDAP Configuration ................................................................... 18.8.7 User Role Configuration.............................................................. 18.8.8 Single Sign On Configuration ....................................................... 18.8.9 Log Viewer .............................................................................. 18.8.10 Setting System Preferences....................................................... 18.8.11 System Status Verification ........................................................ 18.9 Additional Admin Tasks ..................................................................... 18.9.1 Changing a Users Role ............................................................... 18.10 System Reports .............................................................................. 19.1 Overview ...................................................................................... 19.2 About the TelAlert Monitor Window .................................................... 19.3 Setting Up TelAlert Monitor ............................................................... 19.3.1 Configuring TelAlert Notification Paragraphs for TelAlert Monitor ......... 19.3.2 Configuring TelAlert Desktops Host Properties................................ 19.4 Launching the TelAlert Monitor Window ............................................... 19.4.1 TelAlert Monitor Window Button ................................................... 19.4.2 TelAlert Desktop Tools Menu ....................................................... 19.4.3 TelAlert Monitor Data Dialog........................................................ 19.5 Using TelAlert Monitor ..................................................................... 19.5.1 TelAlert Monitor AlertTree ........................................................... 19.5.2 Icons ...................................................................................... 19.5.3 TelAlert Monitor Toolbar ............................................................. TelAlert Monitor Tabs .......................................................................... Alert Monitor Send Message Interface Dialog ...........................................
283 283 283 288 291 291 292 292 292 292 292 293 293 294 301 301 302 307 308 309 310 311 312 313 314 314 314 317 318 318 319 319 319 319 320 320 321 322 323 326 328 330
1
Introduction
1.1 Overview
This chapter includes the following sections: An overview of the TelAlert Administrator Guide and other TelAlert documentation.
1.2.1 Contents
To help you learn how to use the TelAlert system effectively, the first page of each chapter includes a bulleted table of contents summarizing the information in the chapter. Each chapter also contains step-by-step instructions and procedures for using each function with the TelAlert system. The Guide provides administrator-directed information, including adding Users, Setting up connections to service providers, and the optiona available for the TelAlert components.
1.2.2 Audience
The TelAlert Administrator Guide is designed for use by individuals who configure the TelAlert system.
Command line text Text representing information entered by the user at the command line or presented by TelAlert as output is shown in a monospaced font.
1.
Message Formatting In this guide, message text passed on the command line is enclosed in quotation marks. This is not required in all cases, but putting your message text in quotation marks is an excellent habit, as it ensures that neither TelAlert nor any shell you might be using will read the message as anything other than a string of text to be delivered.
Chapter 1: Introduction | 3
Example "Open
Purpose File names and extensions The same monospaced font is used to represent file names and extensions. telalert.iniexamples Entries drawn from the TelAlert configuration file are also represented in a monospaced font.
" ... gives the file a .bak extension and then ..." {LauraTextPager} ... Configuration=SkyTelNationalTe xtPager PIN=4850879
The ellipses (...) indicate information that may be present in the actual telalert.ini entry but which is omitted in the example because it is not relevant here.
Click OK.
Within procedural (how-to) text, boldface words are characters you type or elements you can click. Within overview or conceptual text, bolded words may simply represent concepts that have been highlighted to emphasize their relative importance. Within procedural text, numbered steps denote actions that should be followed in sequence. Within procedural text, bulleted text denotes available options. Within overview or conceptual text, bulleted text also denotes supporting information that is subordinate to the major topic being discussed in the Guide. The light bulb icon denotes a helpful tip.
2.
Click Save to save your work. Click Cancel to exit without saving.
The note icon indicates definitions or considerations that help you understand the related task.
Broken Lines in
telalert.ini
In TelAlert configuration examples presented here, some lines are too long to be presented as single lines. In such cases, the line is broken and continued below. The continuation is indented. It is assumed that, in the TelAlert entry itself, the line will not actually be broken. Note that telalert(c) does not support breaking command lines.
Chapter 1: Introduction | 5
Text to Speech (TTS) is the second most commonly used notification medium supported by TelAlert. If you plan to use TelAlerts voice capability, you should have purchased a TelAlert Dialogic telephony card and installed and tested it following the directions in the TelAlert Voice and Hardware Guide. Once TTS is in place, most of your work will consist of setting up specific [Configurations] and [Destinations] definitions appropriate for voice notifications. One important aspect of this process is determining how TelAlert should behave when a number it calls is answeredfor instance, whether it should expect to reach a voice mail system or a human user whom it must ask for identification before reading its message. All the information regarding the TelAlert Dialogic telephony card and software configuration for voice functionality is now covered in chapters 2 through 4 of the TelAlert Voice and Hardware Guide.
Chapter 1: Introduction | 7
2
What is TelAlert 6e?
2.1 Overview
This chapter contains high-level look at TelAlert 6e, integrations, and documentation.
TelAlert Web UI. This is a tool primarily dedicated to end-user (supervisors and staff) features. These include creating users, adding users communication devices, creating groups of users, devices, and other groups, and creating schedules (on-duty, off-duty, and so on). However, administrators also use the TelAlert Web UI to import user data, manage departments, create holiday schedules, enable LDAP authentication at log, and other complete other tasks (see the Getting Started section in the TelAlert Web UI online help for details). In some cases, administrators may need to use the end-user features as well.
*If using SQL Server express all TCP ports must be set to 1433 as shown in the figure below.
Operating System
AIX AIX 3.2.5 AIX 4.1.3 (and higher) AIX 5.2 (and higher) HP-UX HP-UX PA-RISC 1.0 (9.04 and higher) HP-UX PA-RISC 1.1 (9.04 and higher) HP-UX PA-RISC 1.1 (10.20 and higher) HP-UX PA-RISC 2.0 (10.20 and higher) HP-UX PA-RISC 1.1 (11.31 and higher) HP-UX PA-RISC 2.0 (11.31 and higher) HP-UX Itanium2 (11.31 and higher) Java Java 1.50 (TelAlert Admin "telalert") Java 1.50 (TelAlert EndUser "telalertc") Java 1.60 (TelAlert Admin "telalert") Java 1.60 (TelAlert EndUser "telalertc") Linux Linux (glibc 2.0) (Intel x86 32bit) Linux (glibc 2.1) (Intel x86 32bit) Linux (glibc 2.5) (Intel x86 32bit) (Red Hat 5.4) Microsoft Windows (32 bit Server) (4.0/2000/XP Professional) Windows (32 bit Server) (2003) Windows (32 bit Server) (2008)
Status
Supported with TA 5.50 Supported with TA 5.50 Supported with TA 5.70 Supported with TA 5.70 EXISTING EXISTING EXISTING
NEW
SGI SGI Irix SGI MIPS ABI SCO SCO Release 3 SCO Release 5 Sun SunOS 4.1.3 (SPARC 32bit) Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit) Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (Intel X86 32/64 bit) Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (SPARC 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (Intel X86 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (SPARC 32/64 bit) Other AT&T GIS (System 3000) BSDI 4.1 Digital Unix (Tru64 UNIX 5.1A BL4) Tandem Guardian & Tandem OSS IBM OS/2 HP MPE/iX (WRQ format) Supported with TA 5.50 Supported with TA 5.50 Supported with TA 5.70 Supported with TA 4.03 Supported with TA 5.10 Supported with TA 5.20 Supported with TA 5.50 Supported with TA 5.70 NEW NEW NEW NEW Supported with TA 5.50 Supported with TA 5.50 Supported with TA 5.50 Supported with TA 5.50
Server/Client platforms:
HP-UX PA-RISC 1.1 (10.20 and higher) HP-UX PA-RISC 2.0 (10.20 and higher) AIX 5.2 (No AIX version is supported in this release) Linux (glibc 2.0) (Intel x86 32bit) Linux (glibc 2.1) (Intel x86 32bit) Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit) Digital Unix (Tru64 UNIX 5.1A BL4)
On Windows, TelAlert Messaging Server files are placed in c:\ProgramFiles\telalert. Other TelAlert files are placed in directories relative to this location. You are not required to accept these defaults during installation, but all references to file locations in TelAlert documentation assume (for simplicity of representation) that these default settings have been used.
3
Technical Overview
3.1 Overview
This chapter contains a high-level look at TelAlert Messaging Server from a technical perspective: how it works, the programs and processes comprising it, key TelAlert Messaging Server files, the concepts underlying TelAlert Messaging Server configuration, some frequently asked questions and their answers.
Notification Instructions
Notification instructions specify a message that TelAlert Messaging Server is to send to one or more recipients. Notification instructions can originate directly from an application, such as a network monitoring application, or from TelAlert 6e users. Notification instructions from applications generally utilize a TelAlert API or one of several command-line client programs. Notification instructions from TelAlert 6e users generally use the TelAlert 6e Web UI.
Administrative Instructions
Administrative instructions relate to configuring the TelAlert environment (for example, modem and Internet connections, information about the wireless providers that are used, and so on), starting and stopping TelAlert Messaging Server, and checking the TelAlert Messaging Servers processing of notification instructions. Administrative functions dealing with starting and stopping TelAlert Messaging Server are generally done via the command-line clients. They are also automated as part of the startup and shutdown of the underlying operating system. Administrative functions
dealing with checking the status of TelAlert Messaging Servers processing of notification instructions are done via a combination of command-line clients, TelAdmin, and the TelAlert 6e Web UI.
Responsive Instructions
Responsive instructions come from message recipients and acknowledge receipt of the message, update the status of a problem, ask for more information, and so on. The main TelAlert Messaging Server process is telalerte. telalerte validates these instructions against TelAlert Messaging Server configuration information and queues tasks to be performed by other server processes, which in turn are responsible for interactions with specific devices or connections, such as modems, Dialogic telephony cards, and sockets-based Internet connections.
telalerte then looks in telalert.sects, the configuration file, to find the definition for the recipient, the configuration information for the modem to be used, etc. Next telalerte tells telalertm (TelAlerts modem daemon, the process that actually controls the modem) precisely
what to do, providing it with instructions for dialing the specified service provider, the PIN for this particular recipient, and finally the message itself. All the while,
telalerte tracks all TelAlert Messaging Server activity, recording it in a comprehensive events telalert.trail. It maintains a record of all active alerts in telalert.alert. telalerte is also the part of TelAlert Messaging Server that processes responses and requests. If
a message recipient dials in and acknowledges receipt of a message using TelAlerts voice menus, this response is passed by telalertd (the daemon handling interactions with the TelAlert Voice Engine or Dialogic telephony card) to telalerte, which updates the status of the alert (internally and, where applicable, with the monitoring application that originally issued the command) to reflect the acknowledgment. Similarly, if someone uses telalert to request a list of all active alerts, it is telalerte that retrieves this information and passes it to telalert for display.
telaconf -status
On UNIX, you can also configure telaconfe to start automatically when the system boots up. For details, see the telaconf.init.d file, which contains comments about how to customize it and copy it to the startup directory. It can also be manually started with the command telaconf -start. If an error message such as Error*Can't connect to host... appears in either a popup box inside TelAdmin, or on the command line, there's a good chance that telaconf has not been started.
telalertc.
Most administrative commands can be issued on any machine on which telalert is installed, regardless of whether it is the same machine on which telalerte is running. Certain key administrative commands, including -start, -stop, -compile, and
-init, must originate on the telalerte machine; they cannot be given remotely.
3.6.1 telalert.trail
telalerte records all TelAlert activity in this file. When it reaches a specified size (100 K is the default), the file name is changed to telalert.trbak and telalerte begins a new trail file.
This backup file will be overwritten each time the current trail file reaches 100K. (The
TrailSwitchCmd= line in the [Files] section lets you define an external process for archiving the data in these backup .trail files.)
3.6.2 telalert.alert
Maintained by telalerte, telalert.alert is a continuously updated file containing all the information TelAlert needs to process all active alerts.
3.6.3 telalert[e/f/r/s/d/m/h/v].log
By default, TelAlert maintains a separate log file for each of the daemon processes. telalerte.log is unnumbered, but each of the others (telalertd2.log, for instance) is marked with a number indicating the place (sequentially) of the definition under [Port] with which it is associated. The numbering is necessary because a TelAlert installation may feature more than one instance of the d, s, h, r, and m processes.
3.6.4 telalert.sects
This is TelAlerts configuration file. It contains a variety of information that TelAlert uses to carry out commands. This includes licensing details; information about ports, devices, groups, schedules, and users; and instructions about sending messages to specific destinations and general destination types.
telalerte reads this file in order to process commands. You can control the way TelAlert works by using TelAdmin and the TelAlert 6e Web UI to modify this file. telalert.sects is in a binary format. To generate a human readable format, see the telalert.ini section below.
3.6.5 telalert.ini
telalert.ini is divided into sections headed by words enclosed in straight [brackets]. Many
of these sections are further subdivided into definitions headed by words enclosed in curly {braces}. Lines in the telalert.ini file that are neither section nor definition headings take the form keyword=value, where keyword is any of the many words TelAlert is programmed to recognize (including but not limited to section names), and value is the value you assign (including but not limited to definition names). When TelAlert is installed, the first version of the binary telalert.sects file is "compiled" from a human-readable text file named telalert.ini. (telalert.ini may actually be a set of files, where the primary telalert.ini file contains $include commands that reference other .ini files during the compilation process.) When using stand alone TelAlert vs. TelAlert 6e, users have the option of using either the telalert.ini file or Desktop Admin for configuring TelAlert. In TelAlert 6e all subsequent configuration changes must be made by directly changing
telalert.sects. This is done by Desktop Admin for certain sections and the Web UI for others and never the telalert.ini file. For details on which configuration method to use when see Chapter 5 Configuration Basics. The telalert.ini file can still be used to illustrate all the
different configuration settings in one flat file. It may also be used as a back up file for the current configurations. To make a backup file and save it to telalert.ini enter in the following command:
-c tells TelAlert to understand SkyTelNationalTextPager as a reference to the [Configurations] definition of the same name. This definition contains information on how to
Here, use the SkyTel service, but the PIN for the intended individual recipient is passed here on the command line, as is the message itself (the text following -m, which is best enclosed in quotation marks). Alternatively, you could issue a command referring to a specific destination (see below) defined in the configuration file. For instance:
4
Implementation Planning
4.1 Overview
An introduction to the work of setting up TelAlert to meet your organizations unique notification needs.
This continues to be true as you add other [Configurations] and [Destinations] definitions to the mix, thus making other notification media available, and even as you begin sending messages to more than one destination and filtering these destinations according to the ones considered on-duty. Whether you are sending a message to one or many destinations, TelAlerts basic procedure is the same: it sends the message to the specified destination or destinations and then lets go of the alert. Note that TelAlert knows nothing about nodes, node numbers, or downtime. It simply takes the text of the message received from the controlling application, and sends it to the destination indicated by the command.
-ackwait
What does this extension of the timeline accomplish? Since the message is being sent to a single destination, there is no question of any TelAlert-directed escalation taking place as the result of a response or non-response. But, for as long as the message and (as a consequence) the alert remain alive after message delivery (here, ten minutes), TelAlert can accept a response and pass it to a controlling application. Thus, your help desk application (for instance) will know whether the problem is being handledsomething it could not learn unless the alert were held after the point of delivery.
-ackhold
The limit to this held state is set by the value assigned to ReleaseWait. This specifies how long TelAlert will wait after beginning to hold the message before it releases it automatically. Using the -holdrefresh parameter with a command has a special effect on the ReleaseWait value: -holdrefresh causes TelAlert to reset the ReleaseWaittimer each time TelAlert receives a response other than one instructing it to release the message (these might be status reports that are written to a file in the controlling application, for instance). Thus, it is possible to extend the held state of the message indefinitely.
Complete keyword, which is included in the [Strategy] definition. As long as this criterion has
not been met, TelAlert keeps the alert alive. An individual message recipient may positively acknowledge having received it and thus cause TelAlert to let go of that particular send (one of the multiple notifications that may result when an alert is sent to multiple destinations). However, if this individual acknowledgment does not meet the completion criterion for the alert, the alert itself remains alive. Likewise, an individual message recipient may acknowledge and hold a message. This affects the state of the alert itself only if the acknowledgment meets the completion criterion; otherwise it affects only the state of the individual send. In this case, TelAlert holds the message but continues to process other sends and responses associated with the alert until the completion criterion is met. When this happens, TelAlert stops processing sends and clears all messages in an ackwait state. It continues to hold the held message, however, and as a result the alert remains alive until the message is released, the ReleaseWait timer expires, or the alert is cleared by the sender or a TelAlert administrator.
4.3.5 Summary
The timeline of a TelAlert alert is, by default, very short and simple. Unless it is configured to do otherwise, TelAlert sends all the messages and immediately releases the alert to which they are related. Extending the life of the alert beyond that point is essential if you want to track acknowledgement of messages, perform escalations, or let users interact with TelAlert. Most of the basic configuration issues involved in a TelAlert implementation do not affect this basic timeline model: it remains in effect regardless of the notification medium, the number of destinations invoked, the schedules associated with them, and the strategy at work. The key to extending the timeline is the enabling of responses. For instance, if the -ackwait parameter is used on the command line, TelAlert will hold on to the alert and wait for a response. If a message recipient acknowledges and holds the message, TelAlert holds the message pending a command to release it. As you proceed with your implementation, keep the timeline model in mind. It will help you understand what you can accomplish when tackling a configuration issue.
A Word About These Scenarios Here you will find some issues covered in enough detail so that you may be able to accomplish certain basic goals without looking elsewhere in this guide. But these scenarios are not intended as a substitute for the more complete coverage provided in subsequent chapters of this guide. In addition to giving you a sense of what lies ahead, these scenarios should help you navigate the rest of the TelAlert documentation and determine what coverage is pertinent for you and what you may safely ignore.
All of these process summaries assume that TelAlert (and, where applicable, the Dialogic telephony card) is installed and configured to the point that it can send a test page. You should read all three, as the later ones build on (rather than repeat) the information contained in the first two.
2. Set up Destinations
Next, you then would set up four [Destinations] definitions, one for each pager to which TelAlert will be sending notifications. The following are for the three support employees. Notice that they all refer to the same [Configurations] definition. These are examples of the data in the telalert.sects file and are shown in telalert.ini format. The {JohnTextPager} [Destinations] entry in the telalert.ini format is the same as the JohnTextPager Device shown in the TelAlert 6e Web UI.
[Destinations] ... {JohnTextPager} Configuration=ATTWichitaTextPager PIN=1234567 {CynthiaTextPager} Configuration=ATTWichitaTextPager PIN=2345678 {DavidTextPager} Configuration=ATTWichitaTextPager PIN=3456789
You can name these definitions anything you like, but including the persons name, along with text and pager, in the name you assign may be helpful later, even if there currently are no other entries with which these might be confused. Next, create the destination for their manager:
3. Create Groups
At this point, there are just a few [Group] definitions to create. Later, when you begin setting up escalation strategies, you may find that you want to add others or make changes to these (for instance, since strategies are associated with groups, you may want to create several versions of the same group and assign each a different strategy). First, under [Group], create an entry that points to the destinations for all three support employees. This might be used for standard notifications.
4. Set up Schedules
Recognizing that not all support personnel are on duty around the clock, you may want to associate a [Schedule] definition (or two) with each destination so that messages are sent to on-duty destinations only. Under [Schedule], create an entry for each destination. For instance:
Next, under each of the four destinations you created, set the following values:
Schedule=name_of_schedule
Here, name_of_schedule matches the name of the regular schedule you created for this destination under [Schedule]. For the destination {CynthiaTextPager}, name_of_schedule would be {CynthiaPageSched}. You can name a schedule anything you like, but, if it is unique to the person and/or destination in question, you should choose a name that makes the relationship clear. Note that, if some employees have the same schedule, their [Destinations] definitions can invoke the same regular schedules; you need not create unique entries for each. For instance, a [Schedule] definition called {OfficeHours} might suffice as the regular schedule for almost all users. For a detailed discussion of these settings, refer to Chapter 12: Setting Up and Applying Schedules.
5. Enable Responses
In the present scenario, none of the destinations are of a type that permits a response; while you may invoke a set of possible responses when you send a message, there is no way for these options to be displayed to recipients. The set of invoked response options will be available to them should they decide to reply via the command line, however, and thus you might want to set up a basic menu of replies that users would understand to be available. Under [Response], create the following entry:
[Response] ... {Basic} NumReplies=4 Acked=1 NotAcked=2 AckedHold=3 Released=4 Reply1=Yes Reply2=No Reply3=Hold Reply4=Release
Once this is in place, you (or the application controlling TelAlert) can invoke this set of responses on the command line when sending a message:
telalertc -reply sendID yes sendID is the integer uniquely identifying the message sent to this recipient. (The command telalertc -showalert will display the IDs of active sends.) Even if you do not want to use
Here, this set of responses when you send to regular text pager destinations, setting it up now prepares you for the addition of two-way pagers in the future.
Response Menus vs. Response Commands You do not have to set up a [Response] definition for message recipients to be able to acknowledge the message on the command line. -ack, -nak, -ackhold, and -release are TelAlert commands all users can use with regard to any message in an ackwait state (or, in the case of -release, a held state)even if no responses were associated with the send.
For a detailed discussion of these settings, refer to Chapter 14: Enabling Responses.
6. Create Strategies
The final step in implementing TelAlert in this scenario is setting up [Strategy] definitions that enable alert escalationso that a message is sent first to one destination, then another, then another, until certain conditions are met. In an organization this size, you might need only one. Under [Strategy], create the following entry:
{SupportAll}. Simply set a Strategy value here, like so: [Group] ... {SupportAll} Destinations="Support","RachelNationalTextPager" Strategy=FirstAcknowledge
Now, any message sent to this group with -response Basic and -ackwait time appended at the command line will invoke this strategy. First the message will be sent to all valid destinations comprising {Support} simultaneously. If, after the specified amount of time has passed, no positive acknowledgment has been received, the message will be sent to {RachelNationalTextPager}. Note that, since the only way to respond in this scenario is via the command line, a relatively long -ackwait parameter is most suitable. Response-dependent escalations are more useful in situations supporting response via two-way pager or inbound voice (refer to Scenario Two below). In any event, however, this is an effective means of ensuring that a critical message reaches someone, up to and including the person holding ultimate responsibility. For a detailed discussion of these settings, refer to Chapter 15: Broadcasting to Groups and Creating Escalations.
2.
3.
For a detailed discussion of these settings, refer to Chapter 15: Broadcasting to Groups and Creating Escalations and Chapter 12: Setting Up and Applying Schedules. Set [Configurations] Definitions for Email With email, the same model applies. First create the used to send email notifications:
[Configurations] ... {Email} Type=Email Model=Internet Host=server.domain.com Service=smtp From=telalert@domain.com Type=Email and Model=Internet point to the {Internet} definition under [Port], which you should set up now, if you have not done so already.
Together, Add Email Destinations Next, create a destination for each person to whom you want to be able to send email notifications. For example:
Higher Volume
There are a number of reasons for the increased volume of work: You will very likely be creating more [Configurations] definitions, and you will certainly be creating many more destinations. For each destination, you may be creating one or two unique schedules, and for every human user you may decide to create a separate [User] definition and then associate each with the appropriate destinations. There will be more groups to create, and some of these may be comprised of a large number of destinations. Even if you opt to use only one [Response] and one [Strategy] definition, tending to the other parts of this implementation will demand considerably more effort than in a small organization.
Greater Complexity
The greater complexity is partly the consequence of the greater volume. For instance: More destinations means more choices as to how to set up your groups. Likewise, the fact that significant numbers of destinations will be on duty at precisely the same times may lead you to set up a system of shared schedulessomething that, though rather complicated, will save on maintenance in the long run. At the same time, a larger organization is more likely to have needs that can be met only through more complex techniques: In order to achieve certain escalation effects, you may have to develop your [Group] and [Strategy] definitions at the same time, or you may need to return to your originally created groups and add to or modify them based on what you want to accomplish. As mentioned earlier, you might create several otherwise identical versions of a group, associating each with a different [Strategy] definition. You may find that there are times when you want a message to go to a particular person, via a destination that TelAlert chooses based on scheduling. This requires creating a set of groups, each referring to all of the destinations linked to each person. Once you have done this, you will have to decide if and when these groups should comprise larger ones and what escalation strategies, if any, should be applied.
Note that all Users must belong to one or more Departments. To start, Users can be all assigned to a few Departments or even the Default Department. Changes to Department assignment can be made later with little impact. For more on Departments, see Managing Departments in Chapter 18. Users must also be assigned a Role. Roles are discussed in User Roles in Chapter 13.
Finally, create [Schedule] definitions and associate these with the destinations in as hierarchical a way as possible (i.e., by sharing identical schedules whenever possible).
What response options will be provided? What responses can affect the processing of the alert? How would you like an urgent alert handled in a worst-case scenariofor instance, if no support personnel could be contacted? Will a response from a message recipient be used to control an external application?
5
Configuration Basics
5.1 Overview
An overview of the concepts you will use to configure TelAlert 6e, including a comparison of the tools for performing configuration tasks. TADesktop TelAlert 6e Web Interface
Important Note: In the TelAlert Web UI, communication devices are called "Devices," but in the TelAdmin tool and related documentation, the term for communication devices is "Destinations." Regardless of the term used, in TelAlert 6e, devices/destinations are always created and modified using the TelAlert Web UI.
Note that administrators will also use the TelAlert Web UI for certain other administrator tasks. However, as a self-service configuration tool, the TelAlert Web UI is used primarily by end-users--supervisors and staff users--to modify keywords relating to users, groups, devices, and scheduling.
Note: When TelAlert is installed, the first version of the binary telalert.sects file is "compiled" from a human-readable text file named telalert.ini. (telalert.ini may actually be a set of files, where the primary telalert.ini file contains $include commands that reference other .ini files during the compilation process.) All subsequent configuration changes must be made by changing telalert.sects via TelAdmin or the Web UI. (Never modify the telalert.sects file directly.) Therefore, we recommend removing all telalert.ini files to reduce the risk of inconsistent
configuration specifications.
5.3.2 TelAdmin
The Desktop is the home of TelAdmin, the graphical application used to configure and manage TelAlert. Although TelAdmin runs on Windows, it may be used to configure TelAlert installations running on Windows and UNIX platforms. TelAdmin allows you to configure TelAlert with an easy to use graphical interface. Multiple TelAdmin windows may be opened within the TelAlert Desktop to simultaneously manage multiple TelAlert hosts.
If you are running TelAlert Desktop for the first time, you will need to configure connection parameters for a TelAlert host before using any of the tools. New TelAlert hosts may be and properties for existing hosts may be edited using the Hosts menu. A drop-down list box in TelAlert Desktops toolbar (Figure 7) displays a list of TelAlert hosts that have been configured. The menu options and toolbar buttons will launch tools and perform operations for the TelAlert host that is selected in this list box.
When a host that is managed by TelAlert 6e is selected the toolbar buttons and menu options are different than those that are displayed for a host that is not managed by TelAlert 6e.
While communicating with a server this icon found on the top right hand corner will be animated to inform you that the desktop is sending data to a TelAlert server or waiting for a response. The host monitoring area will display all the hosts (with an abbreviated host name) you are connected to and their status. If the color is green, the connection to the host is up. If it is red, the connection to the host is down. The status bar on the bottom will display details of the connection.
In the TelAlert 6e mode the TelAdmin, TelAlert Monitor tools and TelAlert 6e web interface may be launched from the tools menu, toolbar buttons. Advanced administration of TelAlert 6e managed servers (configurations, ports, etc.) can only be accomplished using the TelAdmin interface. The administration of most of the common functions (devices, users, groups and schedules) is done using the TelAlert 6e browser interface.
To create additional connections to other hosts by choosing Hosts > Add New Hosts
Note that telaconf.hosts should contain the following entries: 00.y All nodes where TelAdmin will connect from The TelAlert 6e Web Server The telalert.hosts file should contain the following entries: All nodes where TelAdmin will connect from The TelAlert 6e Web Server All nodes where telalertc will connect from
See the discussion of telalert.hosts in the section Command Line Options for Modifying Filter Files, in Chapter 3 of the TelAlert Keyword and Command Reference for more information.
telaconf -reload
3. Or, you could use the telaconf utility to add this information as follows. In this example, IP_Address is the IP address the server where TelAdmin runs.
Setting WriteSectsFileAfterChanges to True causes TelAdmin to save changes automatically, at the interval specified by WriteSectsFileInterval. Users have only to click the Update or Save button, and their changes will be written the next time the interval expires. Setting WriteSectsFileInterval at a value of 0m means that TelAdmin will save any changes (that is, write TelAlert.sects to disk) immediately. Changes are written every time a user clicks Update or Save. Setting ReloadAfterSectsFileWritten to True causes TelAdmin to activate changes automatically after it saves them by having TelAlert reload the newly written .sects file, the binary file from which TelAlert actually draws the information it needs to process alerts. This eliminates the need to use the File/Reload Data command to activate changes manually. Typically, if you are using TelAdmins auto-save features, you will want to set this to True. You might set it to False if you wanted to make extensive changes over a period of time without having them affect TelAlerts operational data.
Desktop locking
Chapter 8, Configuring for Paging Notification Chapter 9, Configuring for Voice Notification Chapter 10, Configuring for Other Notification Media
Here, you can set values for any of the keywords allowed in the definition. Depending on the type of keyword value, you may use a pull-down list, type a string or number in a field, or set a time, date, or some other type of formatted data. You can access additional values by clicking the tabs. Default values in Definition windows are displayed in normal typeface; values that have been modified are displayed in bold. It is also possible to restore the default values by simply right-clicking on a non-default value, and choosing Restore Defaults . Clicking a View button displays the referenced definition. This display is read-only; to change the referenced definition, you must access it directly, through the TelAdmin tree. For detailed explanations of all the keywords contained in TelAdmins sections and definitions, see Chapter 2 of the TelAlert Keyword and Command Reference. When you are finished making changes, click the Save button to commit the changes. Click Import to import definitions from a file or the clipboard. Click Cancel to dismiss the dialog without saving changes.
Edit Menu
When you click on a section, paragraph, and definition icon in TelAdmin, the Edit menu items update automatically to include some or all of the following commands,
depending upon which icon is selected and the current state of telalert.sects. The right-click menu and the TelAdmin window toolbar also update automatically. Please note that only Display and References will be available for sections under the control of the TelAlert 6e Web UI. Add New - Creates a new definition with default values. Display - Displays a read-only version of the dialog box. Copy - Creates a new definition with the same values as the selected definition. TelAdmin will prompt for the name of the new definition. Rename - Lets you change the selected definitions name. Update - Brings up the dialog box in which you can change the selected definitions keyword values. Delete - Deletes the selected definition. References . Displays a list of definitions that refer to the select definition. You can use this, for example, to see which [Destination] definitions are associated with a particular [Configuration] definition.
2.
3.
2.
2.
3.
3.
4.
5.
6.
Any Password= keyword-value data on the clipboard will be ignored. This is because TelAdmin always displays passwords as ******, and thus you would not be able to view the password value that was being imported. If the definition being updated supports Password=, then the Set Password button will be enabled, and you can click it to bring up the standard TelAdmin password setting dialog box. Note that it is not necessary to set the password here; you can set it back on the main panel. If errors occur, you can either hit the Cancel button, or you can correct the data on the clipboard (perhaps by copying a different selection of lines), and hit the Get Clipboard button again. Click the Apply button. The Import dialog appears. The imported values are displayed in the appropriate fields, and if the Use defaults radio button was selected during import, all other fields will be reset to defaults. Change any other field values as needed, and click Save. The imported values are not permanently saved until you click the Save button.
7.
8.
9.
In addition to the above features, administrators and supervisors can use the TelAlert Web UI to: Manage Groups and Group Schedules. This facilitates automated broadcasts or escalations of mission-critical alerts at a group level. Configure Security Authentication to the TelAlert Web UI can be performed locally or using an existing LDAP (Lightweight Directory Access Protocol) or LDAPS (Secure) system. Single Sign On can also be enabled. View Alert Status Boards On the Mange Alerts page, administrators and supervisors have three views into alert activity. Like staff users they will see the Alerts Received and the Alerts Sent by the logged in user. An additional Department Alerts view displays alerts sent by and received by all users, devices and groups sharing the same department as the logged in user. For most administrators the Department Alerts view is a system-wide alert status board displaying all alerts routed through TelAlert. Manage Users - Users can be added to the system and assigned to departments and groups. Administrators can create Departments for the system. Create and Assign Schedules TelAlert 6e allows you to send alerts based on availability schedules (such as during scheduled work hours, but excluding company holidays). Supervisors and administrators are able to create group member schedules and assign them to group members. They can add vacation schedules for all users in their department. Administrators can add holiday schedules for the entire system. Reports The reports that are shipped with TelAlert 6e provide insight into the day-today activity of TelAlert. As stated previously TelAdmin will remain the primary tool for most administrative configurations, however Administrators may have the need to modify users, groups, devices, and scheduling which is done using the TelAlert Web UI.
5.10
Logging In
All users must log in before they can access the features found in the Web User Interface (Web UI). User authentication can involve manually entering a username and password stored in the TelAlert database or client LDAP/LDAPS database or automatically using SSO. A username and password should be provided to you by your system administrator, administrator or supervisor. You will also need a link or URL to the TelAlert 6e Log In screen. During the installation of TelAlert 6e a single system wide, master account is created. Using this log in username and password, the system administrator can log in and create additional users. Users added to the system with the role of administrator or supervisor can create other users, selecting a username and temporary password that can be changed by the user once they have initially logged in. If the batch import process is used to populate the database and to create user accounts, users will be able to log in to the system once the import is complete and they have been provided with their log in username and password. To log in to the TelAlert 6e system, do the following: 1. 2. 3. Enter the appropriate URL into your Internet browser. On the TelAlert 6e Log In screen, enter your assigned username and password. Select the Log In button. After successfully logging in, the TelAlert 6e Home page appears.
5.11
Navigating
Use the main menu, comprised of navigation tabs at the top of each page to access the main sections in the TelAlert web UI. The navigation tabs are customized according to the logged in users role. Users with the role of Administrator have access to all 6e features and will therefore see all navigation tabs. Please note that version 6.2.0 of TelAlert 6e added the ability to add custom roles and modify the out-of-the-box roles. The examples below are based on the default permissions assigned to the out-of-the-box roles.
Users with the role of Supervisor have access to most 6e features and will see all of the navigation tabs except for the Admin Tools tab.
Users with the staff user role can access their own information but do not have access to the site management tabs.
To navigate the TelAlert web UI, use the following tabs: Home Alerts Users Devices Groups Schedules Subscriptions Reports Admin Tools
5.11.1 Home
On the Home page, you can: View the five most recent active alerts that you have sent or received. If more than five active alerts exist, you can view the remainder of active alerts by selecting the View All Active Alerts Received/Sent button. View the details of your five most recent active alerts. View a list of devices you own. View a list of groups you are a member of. View your schedules for the current week.
In TelAlert 6e, a device is anything you can use to receive an alert. For example, e-mail is considered a device. Therefore, if your email account is set up in the TelAlert 6e system, it will appear as a device.
5.11.2 Alerts
In the Alerts area, you can: View a list of alerts that have been sent to or received by you and your devices. If you are a supervisor or administrator, you will see all alerts sent and received by the users, devices and groups that belong to your department. The system administrator can see all alerts that have been sent and received. View a list of alerts that have been sent or received by you and reply to those alerts. Send a new alert Search for specific alerts Export alert information for reporting purposes Manage Alert Templates
5.11.3 Users
The Users tab is only available to administrators and supervisors. In the Users section you can manage users that belong to your department. You can create users, edit their information and delete user records. The system administrator can create, edit and delete users within all departments.
5.11.4 Devices
In the Devices area, you can view, add, edit and delete devices that you own. You can also create schedules that can be assigned to your devices. Advanced parameters can be specified for devices. Supervisors and administrators can manage their own devices as well as those owned by other users in their department. System administrators can manage all devices.
5.11.5 Groups
In the Groups section, you can view a list of groups that contain you or one of your devices as a member. Supervisors and administrators can manage groups that they or a device they own is a member of as well as all groups assigned to their department. System administrators can manage all groups. Groups can be created, edited and deleted from the Manage Groups page. When editing group details you can add yourself or other users, devices and groups in your department to groups, define escalation settings for the group and assign schedules to group members.
5.11.6 Schedules
The Schedule page provides supervisors and administrators with the ability to create, edit and delete global and group schedules and edit and delete Device schedules. Device schedules can only be created from within the Devices section. All global, group and device schedule templates assigned to specific groups or devices within their department are available to supervisors and administrators. Global and group schedules can be assigned to group members on the Edit Group Member Schedule page under the Groups tab. These schedules are applied to group members only when an alert is sent to the group. They do not influence alerts sent directly to the user, device or subgroup itself. Device schedules determine availability for the device and owner of the device for all alerts unless overridden by a group or global schedule.
Under the Schedules tab, staff users can view their device schedules and see a calendar display of their group member schedules. The Schedule display is based on group membership and reflects their On Duty hours within a particular group. To schedule availability for individual devices see Editing Your Devices.
6
The Role of Ports in TelAlert
6.1 Overview
An introduction to the "port" concept in TelAlert and instructions for configuring [Port]definitions to achieve the desired notification behavior.
The first two issues are covered in the Quick Start Guide. This chapter covers the third: the issues you must take into account when setting up, within TelAlert, the ports you need for the kinds of notifications you want to carry out.
Ports Defined During Installation, But The TelAlert installation application asks you questions about the connections and devices that TelAlert will use to deliver notifications. Using this information, it automatically creates the corresponding [Port] definitions. You may never need to make any portrelated changes to your TelAlert configuration. However, this chapter tells you what you need to know if you want to add a port, change a ports definition, or understand how a port figures in TelAlert notifications. Note that port changes may require a new Key value (under [License]). Additional charges may apply.
Modemfor a port to which a modem is connected. DirectModemfor a port to which a modem hooked to a leased line is connected. FaxModemfor a port to which a DN400E fax modem is connected to send text messages to fax machines. TTSfor a port to which a Dialogic telephony card is connected using Text to Speech
(TTS).
Internetfor the computers Internet connection. Devicefor a port to which a device of any kind not explicitly supported by the other
models is connected (electronic signboards, most commonly).
Remotefor another installation of TelAlert with which the installation on the local machine is to communicate. Gatewayfor another installation of a TelAlert server that is behind a firewall.
Obsolete Model values:
Voicefor a port to which a Dialogic telephony card is connected using prerecorded words. (Obsolete) EngineMinifor a port to which a TelAlert Voice Engine is connected. (Obsolete) Enginefor a port to which a TelAlert Classic Engine is connected. (Obsolete) EngineSensorfor a port to which a TelAlert Sensor Interface Unit is connected.
(Obsolete)
[Port] components vary according to the Model value set. These are
Modem
A [Port] definition of values.
DevThe name of the file associated with the physical port to which the modem is connected (e.g., COM2,tty00). SpeedThe speed at which you want to communicate with the modem. ModemThe name of the [Modem] section corresponding to the model of the modem. PhonePrefixesThe name of the [PhonePrefixes] section describing the attributes of the telephone line to which the modem is attached. For information on these settings, refer to Chapter 6: Dialing the Telephone, and the TelAlert Keyword and Command Reference.
DirectModem
A [Port] definition of Model=DirectModem requires Dev and Speed values. No Modem value is needed: because the modem will not be used to dial, TelAlert does not need to know the special command set associated with the modems model.
DevThe name of the file associated with the physical port to which the modem is connected (e.g., COM2, tty00). SpeedThe speed at which you want to communicate with the modem.
FaxModem
[Port] definition of Model=FaxModem requires Dev, Speed, Modem, and PhonePrefixes values.
A
DevThe name of the file associated with the physical port to which the modem is connected (e.g., COM2,tty00). SpeedThe speed at which you want to communicate with the modem. ModemThe name of the [Modem]section corresponding to the model of the modem. PhonePrefixesThe name of the [PhonePrefixes] section describing the attributes of the telephone line to which the modem is attached. For information on these settings, refer to Chapter 6: Dialing the Telephone, and the TelAlert Keyword and Command Reference.
TTS
A
VoiceLineA single Dialogic telephony card can support a number of telephone lines. A separate [Port] definition is required for each. The telephone line to which a given [Port] definition pertains is indicated by the value it assigns VoiceLine: e.g., 1, 2, 3, etc. The proper value is
determined by the number of the jack on the card into which the line is plugged.
PhonePrefixesThe name of the [PhonePrefixes] section describing the attributes of the telephone line to which the card is attached. For information on these settings, refer to Chapter 6: Dialing the Telephone, and the TelAlert Keyword and Command Reference.
Internet
A
Device
A [Port] definition of Model=Device requires Dev and Speed values. If the device is a signboard, the definition also requires a value for DeviceSubType and (if DeviceSubtype is set to 2) AlphaAddresses.
DevThe name of the file associated with the physical port to which the device is connected (e.g., COM2, tty00).
Referring to Physical Ports on Windows On Windows, TelAlert now allows the Dev value under two formats
Dev=COMn Dev=COMn:
where
SpeedThe speed at which you want to communicate with the device. DeviceSubtypeThe type of device. 0 is generic; 1 is a signboard to be managed outside of TelAlert; 2 is a signboard to be managed by TelAlert; 3 is a SpectraLink telephone system. AlphaAddressesA range list that provides the addresses of each of a series of daisy-chained signboards (used only when DeviceSubtype=2).
Remote
A
HostThe host name (or IP address) of the remote machine on which TelAlert is installed. ServiceThe name or number of the port on which the remote installation of TelAlert runs.
Gateway
A
HostThe host name (or IP address) of the gateway machine on which TelAlert is installed. ServiceThe name or number of the port on which the gateway installation of TelAlert runs.
DeviceHostThe host name (or IP address) of the terminal server. DeviceServiceThe name or number of the port on the terminal server to which the device is
connected.
NetDeviceSet to True. SoftwareParitySet to True if the device to which you are connecting is a modem; False
otherwise. You also must modify the configuration of the terminal server itself: Its speed setting must match the speed of the device. Its parity setting must be 8/none except where Model=Device. In this case, the terminal servers parity setting is determined by the DeviceSubtype value:
0whatever value is needed to match the devices parity setting 17/even 27/even 37/even
The termserv program cannot be used to test connectivity to a real terminal server. The purpose of termserv is to make a PC with an attached modem act like a terminal server if you do not have a real terminal server. MIR3 recommends using testcomm to test your real terminal server. Please note that using testcomm with a terminal server is different from using testcomm with a standard modem. Use the following syntax with testcomm for testing your real terminal server:
[Port] ... {Engine1} Active=True Model=Engine Types=Speaker,Display,NumericPager,TextPager,InteractiveTextPager,Mode m,InteractiveModem,Voice,InteractiveVoice,Relay Dev=/dev/com/2 Speed=19200 Modem=[Modem.EngineCermetek] [Configurations] ... {TelamonTestPage} Type=TextPager Speed=19200 AreaCode=800 Number=679-2778
72 | TelAlert 6e Administrator Guide - Version 6.1.29
Here, TelAlert recognizes {Engine1} as an appropriate port for processing notifications based on {TelamonTestPage} because TextPager is one of the types listed in the ports definition. If you also had a [Port] definition of Model=Modem, it would (by virtue of its default settings) also have a Types value containing TextPager. Thus, TelAlert could use either port to deliver notifications based on this [Configurations] definition. Which one it would actually use in any given case is determined by (1) the order in which they were created in TelAdmin and (2) whether the first one is available at the time TelAlert goes to process the notification. (If this behavior is not acceptable, you may alter it using the Class keyword discussed immediately below.) Note that there is a default Types value for all [Port] definitions of a given model. For instance, the Types value shown above is the default for [Port] definitions of Model=Engine and would hold even if this value were not explicitly assigned in the configuration file. This default value cannot be expanded; it consists of all the types that a given model is capable of supporting. But it can be pared down so that a given [Port] definition will not be used to process notifications of an excluded type. Why would you want to do this? If you use TelAlert to send both text and numeric pages and have both a Voice Engine and a modem at your disposal, you might want to make sure that numeric pages go out through the Engine only (since an Engines listening abilities make it easier to send numeric pages), while allowing text pages to be sent using whichever was available. By modifying the [Port] definition associated with the modem so that the Types value no longer included NumericPager, you could ensure that TelAlert never used the modem to send numeric pages. Assuming the Voice Engine was the only other appropriate mechanism, TelAlert would always use it instead.
Class
The Class keyword gives you an additional degree of control over which ports are used for which notifications. By assigning a Class value (an arbitrary integer) to a [Configurations] definition, you can tie that definition to any [Port] definition(s) to which you assign a matching Class value. Almost exclusively, Class is used to ensure that pages sent over a leased line (Model=DirectModem) use the appropriate [Port] definition. For instance, perhaps you send pages using two paging service providers. One you connect to via dial-up, the other via a leased line. To achieve this, you would assign a Class value of 1 to the [Configuration] definition that should use the leased line and the same Class value to the corresponding [Port] definition. In both the dial-up [Configuration] definition and the corresponding [Port] definition, you would allow the Class value to default to 0 (i.e., by not setting a Class value).
Sometimes Class is Required There are scenarios in which you might use Class to achieve a desired but optional behavior. A scenario in which you use a leased line and a regular line to send pages via different service providers, however, would require some form of Class-based exclusion. Otherwise, TelAlert would try to use the leased-line port to send other notifications, and these pages would not go through.
If in addition to the leased line you had several regular telephone lines, all with modems attached, they would all be available to the [Configurations] definition that did not specify a Class value as long as they, too, did not specify a Class value (in which case it would default to 0). Conversely, [Port] definitions can have more than one Class value (for instance: Class=1,3). This allows you to point several [Configuration] definitions to a single port. By setting up several [Port] definitions with multiple, overlapping Class values, you can give certain [Configuration] definitions access to several ports while making others completely off-limits. In this abbreviated example, assume that all [Port] definitions match all [Configuration] definitions in terms of Type:
[Port] ... {Port1} Class=1,2 {Port2} Class=2,3 {Port3} Class=1,3 [Configurations] ... {ConfigurationA} Class=1 {ConfigurationB} Class=2 {ConfigurationC} Class=3
Here, notifications based on {ConfigurationA} will be processed using {Port1} or {Port3} but never {Port2}. Notifications based on {ConfigurationB} will be processed using {Port1} or {Port2} but never {Port3}. And notifications based on {ConfigurationC} will be processed using {Port2} or {Port3} but never {Port1}.
This is useful if you have leased lines and a regular line, each dedicated to sends that use different service providers, but want to use the regular line as a backup for notifications that would normally be sent over the leased lines. Consider this abbreviated example:
[Port] ... {LeasedLinePortProviderA} Class=1 {LeasedLinePortProviderB} Class=2 {DialOutPort} #defaults to Class=0 BackupClass=1,2 [Configurations] ... {LeasedLineConfigurationProviderA} Class=1 {LeasedLineConfigurationProviderB} Class=2 {DialOutConfiguration} #defaults to Class=0
Here, TelAlert understands {DialOutPort} as the port to use to back up the two leased line ports, as well as any other ports of Class=1 and Class=2, if unavailable.
When a port is deactivated for either Dialing or Connect errors, TelAlert will execute [Heartbeat] Error and [Notification] Activation events, if any are defined. TelAlert will then attempt to reactivate the port, if its MaxAutoActivates keyword has a value > 0. It will wait for the time specified by the AutoActivateWait keyword before attempting the reactivation. Once the number of reactivation attempts has reached the value specified by MaxAutoActivates, TelAlert will wait for 60 minutes (regardless of the AutoActivateWait setting), reset its activation attempt counter to zero, and start another cycle of activation attempts up to the MaxAutoActivates limit.
DialingErrorLimit, DialingErrorWindow, and DialingErrorLimitDeactivation are used. If both DialingErrorLimit and DialingErrorWindow are zero, errors will not be tracked for port deactivation purposes. Otherwise, DialingErrorWindow is a sliding window of the immediately preceding dialing
For Dialing errors, the keywords attempts, and if the number of dialing errors in that sliding window reaches the DialingErrorLimit value, then the port deactivation process will be initiated. Whether or not the port is ACTUALLY deactivated depends on the setting of DialingErrorLimitDeactivation; if False, the [Heartbeat]Error and [Notification] Activation events, if any, will be executed for warning and tracking purposes, but the dialing error counter will be reset to zero rather than deactivating the port (MaxAutoActivatesand AutoActivateWait will not come into consideration.) For example, if DialingErrorLimit=2 and DialingErrorWindow=100, port deactivation will be initiated if just a couple of errors occur; while if DialingErrorLimit=30and DialingErrorWindow=30, then port deactivation will only be initiated if its become clear that no messages are getting through at all. For Connect errors, theres a similar set of keywords ConnectErrorLimit, ConnectErrorWindow, and ConnectErrorLimitDeactivation.
However, using a remote port, you can have the New York installation pass the notification along to the San Francisco installation, which can in turn page the employee by making a local call. To do this, you must first configure both machines so they agree as to the socket number over which they will communicate. You do this by adding the following line to the operating systems services file:
[Port] ... {SanFranciscoRemote} Active=True Model=Remote Service=telaremt Host=Name/IP Address of SF Machine [Configurations] ... {SanFranciscoServiceProvider} Type=TextPager Speed=2400 AreaCode=415 Number=5551212 Remote=SanFranciscoRemote LocalIfRemoteDown=True
Here, the Remote value in {SanFranciscoServiceProvider} causes notifications originating in New York and based on this [Configurations] definition to be processed using the {SanFranciscoRemote} port definition, which gives the New York TelAlert installation the information it needs to contact the San Francisco installation and have it process the notification. Further, by setting LocalIfRemoteDown to True in {SanFranciscoServiceProvider}, you can ensure that the New York installation will use a local port to send the notification if it cannot make contact with the San Francisco installation.
7
Dialing the Telephone
7.1 Overview
Coverage of techniques relating to TelAlert ability to dial a telephone number needed for most notifications that will be delivered via text to speech or pager.
TelAlert Does Not Use Windowss Modem Settings In Windows, TelAlert controls the modem directly. It ignores any settings in the Modem and Telephony control panel applets.
Number AreaCode
Two other parts may be found here as well. Note that these are not dialed as part of the main number.
Extension Mailbox
Other parts are typically found in the set of [PhonePrefixes] settings associated with the telephone line (via the relevant [Port] definition) that will be used to send the notification. (There can be more than one [PhonePrefixes] section. A given [Port] definition is linked to a given [PhonePrefixes] section through the formers use of the PhonePrefixes keyword.) When used, the following are dialed before the beginning of the main number (or before the area code, if one is used):
If the Number value is comprised of a number of digits equal to or less than InsideDigitCount, then
TelAlert dials the
If the Number value is comprised of a number of digits equal to or greater than SpecialDigitCount, then
SpecialAccess value (if any), then the Numbervalue, and then the SpecialBillingCode value (if any). In these instances, AreaCode is ignored and not
TelAlert dials the dialed.
If the Number value is comprised of a number of digits neither less than or equal to InsideDigitCount nor greater than or equal to SpecialDigitCount, then
If AreaCode is blank or matches LocalAreaCode, TelAlert dials the value (if any), then the Number value.
LocalAccess
If AreaCode matches AlternateLocalAreaCode, TelAlert dials the LocalAccess value (if any), then the AreaCode value, and then the Number value. If AreaCode is not blank, does not match LocalAreaCode, and does not match any value listed for AlternateLongDistAreaCodes, TelAlert dials the LongDistAccess value (if any), then AreaCode, then the Number value, then the LongDistBillingCodevalue (if any). If AreaCode matches any value listed for AlternateLongDistAreaCodes, TelAlert dials the AlternateLongDistAccess value (if any), then AreaCode, then the Numbervalue, and then the AlternateLongDistBillingCode value (if any).
[Configurations] or [Destinations]
2.
3.
If you have not already done so, set LocalAccess under [PhonePrefixes]. This is the value TelAlert must dial (if any) to get an outside line on which to make a local call.
Because the area code matches (if any) and the number.
[Configurations] or [Destinations]
If you use seven-digit dialing for numbers in your own area code, but ten-digit dialing for local numbers in other area codes, enter your area code in LocalAreaCode, and the other local area codes in AlternateLocalAreaCodes. If you use ten-digit dialing for all local calls, leave LocalAreaCode blank, and enter all local area codes, including your own, in AlternateLocalAreaCodes. 3. If you have not already done so, set LocalAccess under [PhonePrefixes]. This is the value TelAlert must dial (if any) to get an outside line on which to make a local call.
Here, if the area code matches one of those listed in AlternateLocalAreaCodes, TelAlert dials the LocalAccess value, the AreaCode value, and the Number value.
Number and AreaCodevalues in either the [Configurations] or the [Destinations] definition. As a general rule, if you dial the same number to reach different
Set the people (as in the case of a number that gives you access to a voice mail system, or the number for a paging service providers system), it makes sense to put these values in the [Configurations] definition. If they are unique to a given person, they belong in the [Destinations] definition. (It is a good idea always to provide an AreaCode, even for local numbers.) You must also make sure that your local area code (LocalAreaCode) is set in the [PhonePrefixes] section associated with the telephone line to be used. Before dialing, TelAlert compares the AreaCode involved in the notification against this value. If they do not match, it knows to dial the area code.
Finally, set LongDistAccess and LongDistBillingCode. LongDistAccess is the value TelAlert must enter to access a line on which a long distance call can be placed; it may be the same value required to access an outside line for local calls, followed by 1 (e.g., 91). LongDistBillingCode is a value your organization may use to ensure proper billing or tracking of long distance calls. For instance, each person or each department may have a special billing code.
2.
3.
AlternateLongDistAccess and AlternateLongDistBillingCode. AlternateLongDistAccess is the value TelAlert must enter to access a line on which
this type of call can be placed; it may be the same value required to access an outside line for local calls, followed by 1(e.g., 91). AlternateLongDistBillingCode is a value your organization may use to ensure proper billing or tracking of long distance calls. For instance, each person or each department may have a special billing code. It may be that no such code is required for calls of this type. When TelAlert sees that the area code provided does not match the LocalAreaCode value, it checks the value against those listed for AlternateLongDistAreaCodes. When it finds it listed there, it uses the AlternateLongDistAccess and AlternateLongDistBillingCode values, instead of LongDistAccess and LongDistBillingCode.
Number
Often a Part of Local and Long Distance Calling Because getting an outside line is commonly a part of making a local or long distance call, it is covered in greater detail in the preceding sections addressing local and long distance dialing.
SpecialDigitCount works much like InsideDigitCount. You use it to indicate what kinds of numbers TelAlert should treat speciallyi.e., by ignoring area code considerations and dialing the SpecialAccess value, the SpecialBillingCode value (if any), and then the Number value. A number is treated in this way if it is comprised of a number of digits equal to or greater than SpecialDigitCount (whereas a number is treated according to the rules of inside access if it is comprised of a number of digits equal to or less than InsideDigitCount).
If you are in the United States and want TelAlert to dial an international number, typically you would assign SpecialAccess a value of 011 and SpecialDigitCount a value of 9. SpecialBillingCode is optional; whether you assign a value here depends on whether your phone system requires such a billing code to be entered. If you are using a PBX and must dial a number to get an outside line, you would include this number as part of the SpecialAccess valuemaking it 9011, for instance.
ats8?
To change the registers setting, use the following command, where n is the length of the pause in seconds:
ats8=n
Various keywords associated with Extension and Mailbox (ExtensionWait, ExtensionListenDelay, MailboxWait) also provide means of inserting pauses into certain types of voice-based notifications. For more information, refer to Chapter 3 of the TelAlert Voice and Hardware Guide.
command-line option
equivalent to keyword(s)
Note that you can use these options only to supply missing values. Any values set with keywords will override those specified at the command line. See the TelAlert Keyword and Command Reference for detailed instructions.
7.11
Some PBXs either do not provide a dialtone at all, or provide an unusual dialtone the modem/Dialogic telephony card does not recognize. In such cases it is necessary to customize the appropriate modem.setups file so that the modem or Dialogic telephony card will skip the dialtone check and "blind dial" instead. In this situation, change the modem AT setup commands to skip dial tone detection. While you should check the particular modems documentation, this is usually done by changing X4 to X3. Normally TelAlert has X4 in the Setup0 string of the modem.setups file. If you use X3, you may also need to change the length of time that the modem pauses between when it goes "off-hook" and when it starts to blind dial. Again, check the particular modems documentation, but usually this is done by adding a S6=4 to one of the Setup strings (in this case, were setting a pause of 4 seconds).
8
Configuring for Paging Notification
8.1 Overview
Instructions for setting up TelAlert to send notifications to numeric, text, and two-way pagers. This chapter covers creating paging-related [Port], [Configurations], [Destinations] (including settings for sending pages via the Internet using SNPP and TMEX), and [Response] definitions and shows you how to use these definitions and the TelAlert command line to send pages.
Next, gather information relating to each of the pagers used by your organization. This will be used in setting up [Destinations] definitions for paging. PIN name of user(s) telephone number (needed only for services that assign a different phone number to each pager)
[Port] ... {Engine} Active=True Model=Engine Types=Speaker,Display,NumericPager,TextPager, InteractiveTextPager,Modem,InteractiveModem,Voice,& InteractiveVoice,Relay Dev=/dev/tty00 Speed=19200 Modem=Engine {Modem} Active=True Model=Modem Types=NumericPager,TextPager,InteractiveTextPager,Modem,& InteractiveModem Dev=/dev/tty00 Speed=19200 Modem=Hayes1200
Given these settings, a [Configurations] definition that contained a Type=TextPager setting could use either port. By contrast, a [Configurations] definition containing Type=TextPager and Model=Modem settings would be able to use only the external modem. The third keyword option, Class, extends your ability to include and exclude port choices for each [Configurations] definition. A large organization might use a half-dozen service providers, and a bank of external modems, some of which may be connected to lines dedicated to a single service provider. Being able to use two or even three keywords to link [ Configurations] definitions to ports makes it possible to give each some port flexibility while removing some ports completely from its list of options.
Note that a text pager destination is typically comprised of: 1. 2. 3. A name that uniquely identifies it within the context of TelAlert. A reference to an existing [Configurations] definition. A PIN that uniquely identifies the pager within the context of the paging service.
For a complete list, refer to Chapter 2: Keyword Reference, in the TelAlert Keyword and Command Reference.
Note that the same [Configurations] definition cannot be used for both one-way and two-way paging. If you want to send pages of both types, you must create a separate [Configurations] definition for each and have each destination refer to the appropriate one. If you ask TelAlert to send a message to a group of destinations, some of which point to one [ Configurations] definition and some of which point to the other, TelAlert will deliver all messages to SkyTel in the same telephone call. TelAlert will still understand a one-way text pager destination used in conjunction with such a [Configurations] definition as one-way. Thus, if you wanted to provide a message formatted specifically for a one-way pager used in this way, you would use the -mP command line option.
set timeout to ## seconds - (hyphen) bell line feed carriage return space tab backslash hex character number ## octal character number ###
\E \e \c \d \p \P \A \M
echo check on echo check off suppress carriage return at end of send pause 1 second pause .25 seconds the pager number (from PIN keyword or pin option) the password (from Access keyword) the message text
If you do not set a timeout with \W##, TelAlert uses the one set by the TextPagerWait keyword, which has a default value of 10 seconds. Turning on echo check in a send parameter will cause the chat script to fail if the paging service does not echo back all of the sent text.
Please Enter Required Pager Number After the user enters the pager number, VodaPage prompts for the message:
Please Enter Alpha-numeric Message (up to 80 characters) After the user enters the message, VodaPage returns to the first prompt, where the user may either enter another pager number or simply hang up to complete the session. An appropriate set of [Configurations] keywords for this service would include:
[Configurations] ... {VodaPagePremierTextPager} Type=TextPager Parity=None Protocol=Chat ChatLogon=Number\s\-\s ChatScript="" \P characters)\s\-\r\n \M Number\s\-\s ChatLogoff= MaxMessagesPerCall=10 MaxMessageLength=80
After the call is connected, TelAlert executes the chat script defined by ChatLogon. First it waits to see the string Number - (Number\ s\-\s). If the paging service sends that string within the timeout, since there is no send parameter, TelAlert simply moves on to the script defined by ChatScript; otherwise, it fails and goes on to ChatLogoff. If TelAlert gets to the ChatScript string at all, the first thing it needs to do is send the pager number. This script contains three expect/send pairs: 1. The script starts with an empty expect parameter ("") followed by \P, which tells TelAlert to send the value of the ${PIN} variable (that is, the pager number associated with this destination by the PIN keyword or passed at the command line by the -pin option) immediately. After sending the pager number, TelAlert waits for the string characters) - followed by a carriage return (\r) and line feed (\n). If it receives the string before the timeout, it sends the value of the ${Message} variable (that is, the message text); otherwise, it fails and goes on to ChatLogoff. If TelAlert sends the message successfully, it waits for the string Number - (just as it did in the ChatLogon script). If TelAlert (1) receives that string before the timeout, (2) has another message to send to this service, and (3) has not yet sent the maximum number of messages indicated by the MaxMessagesPerCall keyword, TelAlert starts ChatScript over at step 1. Otherwisethat is, if If TelAlert has no more messages to send, or it does not receive the string within the timeoutit goes on to ChatLogoff.
2.
3.
One way or another, TelAlert will eventually get to the ChatLogoff script. Since in this case it is empty (""), TelAlert continues processing the event, normally by hanging up and putting the message(s) in the sent state.
Please choose an option (do not press return) : S :- Send a message H :- Help E :- Exit
If the user presses s, this prompt appears:
Type your message (160 characters max) and press return to send:
After the user enters the message after the colon, the system again displays the send/help/exit menu. An appropriate set of [Configurations] keywords for this service would be:
Type=TextPager Parity=None Protocol=Chat ChatLogon=Exit\r\n ChatScript="" S\c return\r\n\r\n: \E\P send\r\n\r\n: \M Exit\r\n ChatLogoff="" E\c MaxMessagesPerCall=10 MaxMessageLength=160
ChatLogon waits for the last part of the menu (the string Exit followed by a carriage return and line feed). Since the send parameter is missing, TelAlert goes directly to ChatScript when it detects the string, or directly to ChatLogoff if the timeout expires first.
96 | TelAlert 6e Administrator Guide - Version 6.1.29
Waits for the colon after the pager-number prompt, then sends the ${PIN} value. The means that TelAlert will check to make sure the paging service echoes back the PIN correctly. Waits for the colon after the message prompt, then sends the
3. 4.
${Message} value.
Waits for the menu to appear again, then starts ChatScript over or moves on to ChatLogoff, as discussed in the previous example.
ChatLogoff.
Since ChatLogoff has a blank expect parameter, TelAlert immediately sends an E followed by a carriage return, telling the paging system that it is exiting. TelAlert then continues processing the event, normally by hanging up and putting the message(s) in the sent state.
Runs ChatScript repeatedly, once for each message. If the script fails or TelAlert hits the limit set by MaxMessagesPerCall, it goes to step 4. If TelAlert receives the ChatRejected string, it hangs up, puts the current message into the message rejected state, and goes to step 5. Runs
4. 5.
ChatLogoff.
If TelAlert has additional messages for the service, it starts over with step 1.
TelAlerts chat scripts take the form of pairs of expect and send parameters, separated by spaces. For example, here are four pairs:
If an expect parameter is not followed by a send parameter, as in the last of the sections outlined above, when TelAlert detects the expect string it goes on to the next expect parameter or, if as in this case it is at the end of the script, considers the script complete.
This setting may come into play in a send to a group of destinations that specifies both a text and a numeric message in order to let TelAlert decide which version to send to each destination. Normally, the Type setting determines which version of the message is sent to a given destination, but setting NumericMessageOnly to True overrides this, ensuring that TelAlert sends only the numeric message to pagers using this [Configurations] definition. For more information, refer to the discussion of message-specific command line options (-m, -mi, -mp, etc.) in Chapter 3: Command Line Reference in the TelAlert Keyword and Command Reference. 3. Next, under [Destinations], create entries for all the numeric pagers to which you will be sending pages using the special [Configurations] definition you created. For instance:
BlindAnswerWait10s specifies how long after the completion of dialing TelAlert will
wait before blindly delivering its message. If this is set too low, TelAlert may deliver the message when the phone is still ringing. If it is set too high, the service may hang up on TelAlert before it delivers the message. To determine what value to assign here, call the numeric paging service and count the seconds that elapse from the time you finish dialing until you hear the tones. Repeat this procedure until you are confident of the consistency of this timing. To accommodate each additional ring, you will need to add a full six seconds to the BlindAnswerWait value, since a standard ring cycle is six seconds. You must make sure that this additional time does not cause the service to time out on occasions when the line is answered more quickly.
TerminatorThis is the tone that TelAlert issues to signal the end of message transmission. Most services ask callers to press the pound (#) key after entering the
numeric message. After issuing this tone, TelAlert waits the amount of time specified by PostMsgWait and hangs up.
PostMsgWait2s specifies how long after message transmission (which includes the issuing of the terminator tone) TelAlert should wait before hanging up. This is needed in cases where the service provider issues a fake busy signal after it hears the terminator tone; if you permit the modem to detect this, it will report that it received a busy signal and you will not know whether the message was actually delivered.
Tone Recognition Settings Not Needed Some of the configuration settings used for sending numeric pages via the Engines modem are not needed here (e.g., ToneWait, AnswerToneOnly, ToneRepeats, MinToneOn, MaxToneOn, MinToneOff, MaxToneOff, and PreMsgWait). If you model your standard numeric paging [Configurations] definition on a definition that contains these settings, you can either delete them or leave them intact. Assigning a value to BlindAnswerWait causes TelAlert to ignore all settings related to tone recognition.
3.
Under [Destinations], create an entry for each numeric pager. For example:
tail -f $TELALERTDIR/telalert.trail
On Windows:
tail -f telalert.trail
[Configurations] ... {SkyTelITwoWayTextPager} Type=InteractiveTextPager Protocol=TMEX Parity=None MaxMessagesPerCall=100 Speed=19200 AreaCode=800 Number=679-2778 InteractiveTextPager, and the I (for interactive) in the name: SkyTelITwoWayTextPager. Other [Configurations] definition names may refer to two-way paging, but only if Typeequals InteractiveTextPager will the definition support two-way paging (some other two-way [Configurations] definitions, of Type=TextPager, are
Note the type, for sending regular text pages to two-way pagers). The Protocol keyword refers to the protocol used to send information back and forth from the pager. The pagers that TelAlert supports use many different protocols: refer to Chapter 2 of the TelAlert Keyword and Command Reference for details on the Protocol keyword. Above, Parity=None is a setting required by the protocol used for two-way paging, TMEX (Telocator Message Entry). MaxMessagesPerCall is a limit specified by your service provider; the number entered here must not exceed this limit. The Speed setting should be correct for the service provider, assuming you are using configuration information from the Pagers directory.
[Port] ... {EngineMini} Active=True Model=EngineMini Types=Speaker,Display,NumericPager,TextPager,InteractiveTextPage r,& Modem,InteractiveModem,Voice,InteractiveVoice,Relay Dev=/dev/tty00 Speed=19200 Modem=EngineMini {Modem} Active=True Model=Modem Types=NumericPager,TextPager,InteractiveTextPager,Modem,Interact iveModem Dev=/dev/tty00 Speed=19200 Modem=Hayes1200
Given these settings, a [Configurations] definition that contained a Type=InteractiveTextPager setting could use either port. By contrast, a [Configurations] definition containing Type=InteractiveTextPagerand settings would be able to use only the external modem.
Model=Modem
The third keyword option, Class, extends your ability to include and exclude port choices for each [Configurations] definition. A large organization might use a half-dozen service providers, two or more Engines, and a bank of external modems, some of which may be connected to lines dedicated to a single service provider. Being able to use two or even three keywords to link [Configurations] definitions to ports makes it possible to give each [Configurations] definition some port flexibility while removing some ports completely from its list of choices.
A [Destinations] definition may contain other settings as well, including User and Schedule. For a complete list, refer to Chapter 2: Keyword Reference, in the TelAlert Keyword and Command Reference. Though recommended, setting up destinations is optional. As explained below, at the beginning of Enabling Responses, you can invoke a [Configurations] definition and provide destinationrelated information on the command line.
Unless you attach a menu of responses to the messages you send, you cannot take advantage of the mediums two-way functionality. To do this, follow these steps. 1. Examine the response entries found under [Response]. These are ready for you to refer to on the command line. For example:
[Response] ... {Basic} NumReplies=6 Acked=1 AckedHold=3,4,6 NotAcked=2 Released=5 Reply1=Yes Reply2=No Reply3=Hold Reply4=Info #Reply4 means the user will be sending additional info #(requires use of a special notification script) Reply5=Release Reply6=Ping #Reply6 runs a script that pings a node and reports the result #to the user (requires use of a special notification script)
You can invoke any existing [Response] definition when sending a message to a two-way pager using an interactive [Configurations] definition:
2.
Modify the existing [Response] definitions, or create new ones, as necessary. For instance, you might want to make the above set of responses even more basic by removing Info and Ping, so that there is a one-to-one correspondence between menu items and TelAlert commands. Or you might want to add more responses that map to Acked, AckedHold, NotAcked, or Released, so that these responses carry out the corresponding action within TelAlert while providing more detailed information. For example:
[Response] ... {DetailedReplies} NumReplies=8 Acked=1,2 AckedHold=5,6 NotAcked=3,4 Released=7,8 Reply1=Yes<1Hour #Reply1 means yes, in less than one hour Reply2=Yes>1Hour #Reply2 means yes, in more than one hour Reply3=NoBusy #Reply3 means no, I am busy Reply4=NoOffDuty #Reply4 means no, I am off duty Reply5=HoldWillHandle #Reply5 means hold, I will handle it Reply6=HoldWillDelegate #Reply6 means hold, I will assign this to someone else Reply7=ReleaseFixed #Reply7 means release, this is fixed Reply8=ReleaseNotFixed #Reply8 means release, but this is not fixed
Here, two responses map to each command, allowing the respondent to positively acknowledge the message in two ways, negatively acknowledge the message two ways, and so on. (The intended meaning of each response is explained in a comment line.) The text of the response will be available in the telalert.trail file. You can make much better use of this sort of response-related information when using TelAlerts notification feature. For more information, refer to Enabling Notifications below.
-ackwait value.
The command generating the alert must specify a set of responses. In addition, the message must still be active: it must be in either an ackwaitor ackheld state. Otherwise, from TelAlerts point of view, the message no longer exists and there is no reason for TelAlert to poll for a response. The only aspect of polling that it is possible to control is the frequency with which TelAlert dials in to check for responses. You can do this by changing the CheckITPRepliesInterval setting under [Limits]. The default is 5m. Note that this single setting is used by all [Configurations] definitions of Type=InteractiveTextPager. You may find that a value of less than 5m interferes with TelAlerts attempts to deliver messages, since it will cause TelAlert to spend more time polling for responses. At the same time, this value must be less than any -ackwait value you assign; otherwise, messages will always expire before TelAlert has a chance to dial in and check for a response.
[Port] ... {Internet} Active=True Model=Internet Types=Email,TextPager,InteractiveTextPager Active means that the port is active and available to be used by TelAlert. Model and Types are keywords that form the association between this [Port] definition and the [Configurations] definition(s) in which these values match.
2. Next, set up a [Configurations] definition that uses the [Port] definition of Model=Internet. Use the information you find for your service provider in the appropriate pagers file. On Windows systems, these files will be in %TELALERTCFG%\Pagers; on UNIX systems they will be in ${TELALERTCFG:-/usr/telalert}/Pagers. If you cannot find the pager configuration you need in this directory and are having trouble creating one, please contact our Technical Support staff. We may have already written the configuration you want. The [Configurations] definition will look something like this:
[Configurations] ... {PagemartSNPPTextPager} Type=TextPager Protocol=SNPP Model=Internet MaxMessagesPerCall=100 Host=pagemart.net #Host=198.78.254.130 Service=444 TextPagerWait=30s Type and Model determine which port this [Configurations] definition uses; both the values assigned here must match the values set in the [ Port] definition for that port to be used. Since this is an Internet transmission for one-way paging, it will use Protocol=SNPP. MaxMessagesPerCall is a limit determined by the service provider; the number you enter here must not exceed the providers limit. Host is the Internet name or IP address of the machine running the paging application (you may need to contact your service provider to learn the correct value). Service is the Internet port or service name used by SNPP; the default, as defined by this standard, is 444.
Chapter 8: Configuring for Paging Notification | 109
TextPagerWait is the amount of time TelAlert should wait for a response from the
paging provider before it considers the connection to be non-functioning and the send to have failed. 3. Finally, set up a destination that uses this [Configurations] definition. You will need to include some information on the particular pager you are defining.
[Port] Definition
The [Configurations] definition you are going to select or create will use the Internet port represented by the following definition. If this definition is not already in place, it may mean that your license does not support an Internet port. In this case, you should contact your MIR3 sales representative.
[Configurations] Definition Next, choose and set up a [Configurations] definition. Use the information you find for your service provider in the appropriate pagers file. On Windows systems, these files are located in %TELALERTCFG%\Pagers; on UNIX systems they are located in ${TELALERTCFG:-/usr/ telalert}/Pagers. Your configuration will look something like this:
[Configurations] ... {SkyTelInetTwoWayTextPager} Type=InteractiveTextPager Protocol=TMEX Model=Internet MaxMessagesPerCall=100 ServerPIN=serverpin Access=password PollRequests=False Host=skysock.skytel.com Service=2502 DialBackup=5 Parity=None Speed=19200 AreaCode=800 Number=679-2778
The values assigned to Type and Model tie this [Configurations] definition to one of your [Port] definitions (in this case, {Internet}). The communication protocol is TMEX. MaxMessagesPerCall is a limit determined by your service provider; the number you enter here must not exceed this limit. ServerPIN and Access will usually be needed,; contact your service provider if you do not have the correct values for these. Host is the Internet name or IP address of the machine running the paging application (you may need to contact your service provider to learn the correct value). Service is the Internet port or service name used by TMEX; the default, as defined by this standard, is 2502. The last five settings in this entry, beginning with DialBackup, are optional. Taken together, they permit pages to be sent via dial-up if TelAlert encounters (in this case) five connect failures in the course of attempting to send a page using this [Configurations] definition. In the current example, as soon as TelAlert encounters the fifth connection error in attempting to send a page, it dials the number you provide here and, still using the TMEX protocol, transmits the message to the service provider. Parity=None is the correct value relating to all dial-up TMEX paging, as is the Speed setting presented here.
Connecting to BSWD via the Internet Bell Souths two-way paging service allows you to initiate pages via the Internet. To take advantage of this capability, TelAlert has been modified to support the associated protocol. Thus, in the relevant [Configurations] definition, Protocol should be set to XSOCKET. This [Configurations] definition also requires ServerPIN (DAS account Administrator) and Access(password) values.
[Destinations] Definition
Under [Destinations], create an entry for the two-way pager to which you want to send pages:
Polling
Polling is the means by which TelAlert checks for responses to two-way pages it has sent. When it polls, TelAlert uses the same [Configurations] definition that it used to send the original page. If you send a two-way page via the Internet, TelAlert attempts to retrieve a response by the same medium. If DialBackup is specified and TelAlert encounters the specified number of connect errors in attempting to poll, it will use the DialBackup information to poll by dial-up. For more detailed information, refer to the discussion of polling in the preceding section on regular (i.e., nonInternet-based) two-way polling. [Notifications] Definition As discussed under Setting Up Two-Way Paging, response functionality can be significantly expanded using TelAlerts notification feature, which allows you to pass customized responses to a log file or another application. Thus, you can enable a response that will update a trouble ticket in the controlling application with which you have integrated TelAlert; likewise, you can enable a response that, by triggering a script, will carry out a diagnostic or administrative operation. Because the notification feature has many uses that are not specifically related to paging, it is covered elsewhere. For detailed instructions, refer to Chapter 16: Processing Events.
[Configurations] ... {EmailPage} Type=TextPager Model=Internet Host=mailserver.com Service=smtp From=alert@mailserver.com To=${PIN}@pagingprovider.com [Destinations] ... {BobEmailPager} ... PIN=1234567
When processing a notification to {BobEmailPager}, TelAlert will the take PIN value from the invoked destination, substitute it for the ${PIN} in the configurations To value, and use that as the address for the email message. The more important application of this feature, however, is for users who store PINs outside of TelAlert and pass them on the command line, bypassing any references to destinations in the configuration file. Here, as long as the invoked [Configurations] definition contains the correct To value (see above), the command line need not contain any email-related information. For instance:
AddSendIDtoMessage=True
With this setting, messages sent using this configuration or destination will be preceded by the send ID number and a colon. For example:
${SendID}
MaxTrackID=999 AddTrackIDtoMessage=True
No Track IDs Assigned When Using -c Track IDs are assigned only to messages sent to defined destinations. Hence, regardless of the [Configurations] settings, when you send a message using -c no track ID will be assigned.
Setting MaxTrackID to a value higher than 0 (its default) causes TelAlert to assign track ID numbers to messages sent using this configuration or destination. The value is the number after which TelAlert restarts track ID numbering at 1. Setting AddTrackIDtoMessage to True causes the track IDs to be added to the beginning of the message text, as shown in the examples above. If you have AddSendIDtoMessage also set to True, in the message text the send ID precedes the track ID, and the two are separated by a colon. Alternatively, you can leave AddTrackIDtoMessage set to its default value of False, and add track IDs to selected messages using the ${TrackID} substitution parameter. For example:
telalertc -i BobNumericPager -m "\${TrackID}:node 1250 down" -ackwait 1h AddTrackIDtoMessage to True, you may also wish to set an AcknowledgeWait value in the same definition to ensure that messages sent without an ackwait will be active long enough to be recovered in the event they are not delivered to the
When you set pager. Escalation May Cause Gaps in Track ID Sequence Track IDs are assigned to messages at the time they are created. When an alert is directed to a group with an associated [Strategy] definition, all messages are created at once. When a member of the group acknowledges one of those messages, any stillunsent messages are normally cleared, producing a gap in track ID sequence at the destinations to which they would have been sent.
telalertc -i BobNumericPager -m "\${AlertID}:node 1250 down" -ackwait 1h telalertc -i BobNumericPager -m "\${GroupID}:node 1250 down" -ackwait 1h
9
Configuring for Voice Notification
9.1 Overview
Information on software configuration for voice functionality has been moved to the TelAlert Voice and Hardware Guide.
Voice is the second most commonly used notification medium supported by TelAlert. If you plan to use TelAlerts voice capability, you should have purchased a Dialogic telephony card and installed and tested it following the directions in the TelAlert Voice and Hardware Guide. Once the Dialogic telephony card is in place, most of your work will consist of setting up specific [Configurations] and [ Destinations] definitions appropriate for voice notifications. All the information regarding the Dialogic telephony card and software configuration for voice functionality is now covered in the TelAlert Voice and Hardware Guide.
10
Configuring for Other Notification Media
10.1 Overview
Instructions for setting up TelAlert to send notifications to non-voice, non-pager destinations such as email, electronic signboards, the LCD text displays of SpectraLink wireless telephones, and the command line. This chapter covers creating [Configurations] and [ Destinations] definitions for these media and using these definitions and the TelAlert command line to send messages.
10.2
Getting Started
For command line notification setup, you need to know: the full path to the application you want to trigger the command you want to give the shell you want to use (if any)
To set up TelAlert to send messages to other systems (UNIX syslog processes, TelaConsole running on an Windows machine, and AS/400s), you need to know: the appropriate Serviceand Host value for the system in question (when sending messages to UNIX syslog processes, TelaConsole, or an AS/400) the Facility Code and Priority values required by the system in question (when sending messages to UNIX syslog processes or TelaConsole) a valid login value and the queue in which you want the message to be placed (when sending messages to an AS/400) a special AS/400 program, QSYSOPR, available from Patrick Townsend Associates (when sending messages to an AS/400)
To set up TelAlert to send messages to Web-enabled cellular telephones, you need to know: the host name and service value for the Nextel server the exact TelAlert Web client URL to which recipients should go to retrieve their messages
To set up TelAlert to send two-way messages to Nextel cellular phones equipped with text screens, you need to know: the host name of the Nextel server the PIN for any phones to which you will be sending messages an email address within your organizations domain to which responses can be sent
Key Values in License may need updating when creating new Ports Note that adding new [Port] definitions may require a new Key value (under [License]), depending on the number of licenses you purchased. Additional charges may apply. Contact your MIR3 Sales Representative for more information on adding new [Ports].
10.3
telalertc -c signboard -mailbox ?1 -m "hello help desk office" -ackwait 10m telalertc -c signboard -mailbox ?2 -m "hello network managers" -ackwait 10m
10.4
The following discussion covers the configuration changes required for TelAlert to control how messages are displayed on your signboard. See Alternative Signboard Setup (DeviceSubtype=1) below for instructions on configuring TelAlert to let another application control message display.
[Port] ... {SignboardPort} Active=True Model=Device Types=Device DeviceSubType=2 SoftwareParity=False Dev=/dev/com/a Speed=9600 AlphaAddresses=1
The configuration for Windows is the same, except for the
dev= value:
DeviceSubtypeSet to 2 if you want TelAlert to control message display; set to TelAlert to let another application control message display.
SoftwareParity Not relevant to signboards. Leave blank or set at default value of DevThe name of the physical port to which the signboard is connected. SpeedFor signboards, must be set to
9600.
AlphaAddressesA list of the serial addresses (discussed under Initial Signboard Firmware Setup above) of daisy-chained signboards sharing this port, expressed as two-digit decimal numbers separated by commas: for example, 1-3,11-13,21-23. For a single signboard, normally left blank or set at default value of 1. (This keyword is ignored when DeviceSubtype=1.) NetDeviceSet to its default value of computer running telalerte. Set to
False if the signboard is connected to serial port of the True if the signboard is connected to a terminal server.
DeviceHostThe IP address or network name of the terminal server to which the signboard is connected. DeviceServiceThe number of the TCP port TelAlert is to use to communicate with the terminal server to which the signboard is connected.
[Configurations] ... {SignConfigST2} Type=Device DeviceSubtype=2 Parity=Even Mailbox=Z Terminator= ServiceMaxMessageLength=960 MaxTextFiles=10 TextFilesFIFO=True TextFilesFIFOMinDisplayTime=2m FailWait=2
Chapter 10: Configuring for Other Notification Media | 123
TextFilesEmptyMessage=\x1B b \x1C1\x13
TypeWith signboards, always set
DeviceSubtypeMust be set to match the setting in the [Port] definition. ParityFor signboards, must be set to
Even.
MailboxThis keyword uniquely identifies the signboard with which this [ Configurations] definition is associated. Mailbox values are comprised of (1) a letter indicating type (one-line vs. two-line, for instance) and (2) a two-digit hexadecimal number (01 to FF) corresponding to the signboards serial address (discussed under Initial Signboard Firmware Setup above). Mailbox should normally be set to Z in the [Configurations] definition. (The Z type will work with all models.) Set the serial address in the [Destinations] definitions, and TelAlert will combine the type and serial address values when sending messages to the destinations. With this setup, you can also specify the serial address on the command line, for example:
telalertc -i Sign -m "this is a test" -ackwait 10m telalertc -c SignConfigST2 -mailbox 01 -m "this is a test" -ackwait 10m
The -ackwait option is required, as it determines how long the message stays on the signboard. If you send a message with no ackwait value, it will not appear on the board, or will flash for just an instant.
To create a usable signboard control string, replace [mode] and [color] with codes from the following table: mode code a b c e f g h i j k l m p q r s effect slow continuous scroll right to left no motion flash scroll up scroll down scroll right to center scroll left to center wipe up wipe down wipe left wipe right scroll up with pauses split message and scroll in from sides split message and scroll out from center split message and wipe in from sides split message and wipe out from center color code 1 2 3 color red gree n ambe r
[Destinations] ... {SignRed} MessagePrefix=\x1B0a\x1C1 ... {SignGreen} MessagePrefix=\x1B0a\x1C2 ... {SignAmber} MessagePrefix=\x1B0a\x1C3 ...
Assuming the three definitions other settings were identical, with this setup you could make a message appear in the desired color by sending it to the matching destination.
telalertc -i Sign -mi Subtype2Msg a 1 "node 2042 down" telalertc -i Sign -mi Subtype2Msg a 2 "node 2042 down" telalertc -i Sign -mi Subtype2Msg a 3 "node 2042 down"
telalertc -i signboard1 -m "message for signboard 1" -ackwait 10m telalertc -i signboard2 -m "message for signboard 2" -ackwait 10m
Alternatively, you can have the controlling application send messages to the appropriate signboard by using the -mailbox command-line option. For example:
10.5
The previous section focused on installations in which TelAlert controls signboard message display. In this section, well discuss configuring TelAlert to let another application control the signboard. With this alternative setup, the signboard will display a fixed number of continuously updated messages from the controlling application. Typically this approach is used in call centers to display status messages, such as current hold time, number of calls waiting, and number of calls in progress. As with the standard signboard setup, you must define [ Port] and [Configurations] definitions. Then you will use TelAlert to perform some additional firmware initialization. Finally, you can either create a separate [Destinations] definition for each message, or configure the controlling application to include the necessary signboard control codes in the message.
DeviceSubtype=1signboard, you need only the following keywords: Configuration ... {SignConfigST1} Type=Device DeviceSubtype=1 Mailbox=...
Device and DeviceSubtype should be set as shown. See the Signboard [Configurations] Definition section of Standard Signboard Setup (DeviceSubtype=2) above for instructions on setting the Mailbox value. (The keywords MaxTextFiles, TextFilesFIFO, TextFilesFIFOMinDisplayTime, and TextFilesEmptyMessagerelate only to TelAlerts control of signboard message display and are ignored when DeviceSubtype=1.) Note that when
DeviceSubtype=2, TelAlert will not give you an error message if you provide the wrong Mailbox value.
After youve saved this new definition, activate it by making TelAlert re-read its configuration file. You must activate the new definition before you can perform the following instructions.
FFFE (tells signboard not to control display with its internal clock)
Create a separate 11-character control string for each virtual file you want to create, run them all together without spaces, and use the command above to send the whole mess to your signboard. (Using that syntax to interpret the sample command, the signboard reads AA (create file A), L (disable remote control while displaying file). 00FF (allocate 255 characters to file), FFEE (display regardless of current time), BA (create file B), and so on until it has created all six virtual files.) By default, the signboard displays each file for an equal length of time. If you do not use all six files, you can use the AlphaTextFileSequence [Message] definition to change the display. First, make sure that the AlphaAllocateTextFilesdefinition exists and is set active in TelAlerts [Message] section. If not, create it, as follows:
A[file_name] file_name is the single-letter name of the virtual file you want to hold the message. Thus, to put a message into virtual file A, and have the signboard scroll it in red, you would use the following string: AA
To put a message into virtual file B, you would use:
AB
This string must immediately precede the one discussed above in Controlling Signboard Text Color and Effects. You can specify both strings in the MessagePrefix value of your signboard [Destinations] definitions, put only the virtual-file string in MessagePrefix and have the controlling application add the mode and color string at the command line, or have the application that controls TelAlert specify both at the command line.
[Destinations] ... {SignFileARed} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AA\x1B0a\x1C1 {SignFileAGreen} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AA\x1B0a\x1C2 {SignFileBRed} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AB\x1B0a\x1C1 {SignFileBGreen} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AB\x1B0a\x1C2
With those definitions, the following commands will send messages to two different virtual files:
telalertc -i signfileared -m "this goes to file A, in red" telalertc -i signfilebgreen -m "this goes to file B, in green"
-ackwait Not Required When
DeviceSubtype=1
As reflected in the command examples above, there is no need to use -ackwait when sending messages to a DeviceSubtype=1 signboard. Messages continue to display until updated by another send to the same virtual file.
Specifying Virtual Files in [Destinations] Definitions and Text Color and Effects at the Command Line
Alternatively, you can set only the virtual file name in the MessagePrefix value, and pass the control codes for text mode and color at the command line. This approach is useful if you want to manage signboard virtual files within TelAlert, and have the controlling application control text color, for example to switch status messages from green to red when conditions are abnormal. First, create one [Destinations] definition for each virtual file you want to use. For example:
[Destinations] ... {SignFileA} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AA {SignFileB} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AB {SignFileC} Configuration=SignConfigST1 Mailbox=01 Terminator= MessagePrefix=AC
Then create a [Message] definition that will insert the parts of the mode/color control string that are always the same. For example:
telalertc -i SignFileA -mi ModeColorMsg a 2 "average hold 2 minutes" telalertc -i SignFileB -mi ModeColorMsg c 1 "15 calls waiting" telalertc -i SignFileC -mi ModeColorMsg a 2 "14 calls in progress"
Specifying Virtual Files, Text Color, and Effects at the Command Line
A third alternative is to specify the virtual file you want to receive a message at the command line. When you use this method, you must also include the mode and color control codes at the command line. (See Controlling Signboard Text Color and Effects earlier in this chapter for instructions on setting the display mode and color.) Also, note that with this approach you must use only destinations in which MessagePrefix is blank. For example:
telalertc -i sign -mi Subtype1Msg A a 1 "this goes to file A" telalertc -i Sign -mi Subtype1Msg B a 1 "this goes to file B"
10.6
Because the Internet is sometimes subject to delays, and because not everyone checks for new email messages with the same frequency, email is not the most efficient or reliable notification medium. It can be very useful, however, for low-priority messages. Also, some organizations set up TelAlert so that every message sent via pager also is sent to the persons email address. Used in this way, email can serve as an effective means for backing up other media or for creating records of messages that individual users may find valuable. Setting up email notification involves creating a [Configurations] definition and one or more destinations. The [Port] definition that will be referred to by the [Configurations] definition probably already exists in your TelAlert configuration file. You can have TelAlert use a provided helper application, called Readmail, to process responses to email notifications. This is also useful in the case of two-way text paging services that are emailbased. For instructions on using Readmail, refer to the end of this section.
[Port] ... {Internet} Active=True Model=Internet Types=Email,TextPager,InteractiveTextPager Model=Internet provides an additional link matching the [Configurations] definition, below, to this [Port] definition. It also tells TelAlert which process to use in processing notifications that invoke this [Port] definition.
The From Setting in an Email [Configurations] Definition Setting the From value does not in itself make it possible to reply to messages sent by TelAlert; to do this, the address entered here must be a valid one. Further, even if you set up telalert@domain.com on your mail server as a valid email address, sending mail to this address is not a means of getting information into TelAlert. Even if you do not mean to allow users to respond to TelAlert messages via email, you should assign a valid email address to the From keyword, since many mail servers will not send email without a valid From address. If you are interested in making it possible for users to respond to notifications via email (i.e., to use email as a means of getting information into TelAlert), you will need to use the provided Readmail program, which is governed by the [Process] section. For more information information, see Handling Responses to Email With Readmail later in this section.
{POPClient} Settings
Following is an example {POPClient} definition.
[Process] ... {POPClient} Active=False Shell="" Command=${TelAlertBin}/readmail ${EventData} -name ${Definition} -file POPClient.log -back POPClient.%Y%m%d%H%M -sleep 30 -host 127.0.0.1-service 110 -user <User> -password <Password> -send -ack -reply -request Start=${TimeStamp} Start Reset=${TimeStamp} Reset Status=${TimeStamp} Status Control=${TimeStamp} Control ${Message} Switch=${TimeStamp} Switch Stop=${TimeStamp} Stop
ActiveDetermines whether the definition is active. You must set this to
ShellThe shell to which TelAlert should pass the specified Command value. The value should be a fully qualified reference, as the users PATH will not be used. When the Command value is not a shell command (as is normally the case in Windows), the Shell value should be blank. CommandThe command TelAlert should issue whenever it (TelAlert) is started. This command launches Readmail and sets the parameters that govern its behavior. TelAlert issues this command only if Active=True. The value assigned to this keyword in the template is comprised of a number of command line options. -name ${Definition} invokes the name of the current [Process] definition. file is used to specify a log file. back is used to specify a naming convention for backup copies of this file. -sleep determines how often Readmail checks for new mail. -host, -service, -user, and -password provide the information Readmail needs to connect to the POP host. Finally, the presence of -send, -ack, -reply, and -request determine what email messages it processes (specifically, messages that, based on their subject line, are intended to ack or nak a notification (-ack, -nak), reply to a notification (-reply), send a new message via TelAlert (-send), or submit a request (-request).
Readmail 1.13, build 20021014 or later, includes an used in conjunction with -response. Without
-ignore:
-response expects the Subject line to be in the format: Re: <SendId> <Reply>
where <Reply> will be string-matched against the list of replies contained in the -response definition specified in the original command (the command that initiated SendID). If <Reply> is null on the Subject line, then the first line of the message body will be taken as <Reply> and string-matched instead. With
-ignore:
-response expects the Subject line to be in the format Re: <SendId> <whatever>
and the first line of the message body to be:
<Reply>
The <Reply> will be string-matched against the list of replies contained in the -response definition and will always be taken from the first line of the message body. Any text that follows <SendId> on the Subject line will be ignored.
Start, Reset, Status, Control, Switch, StopThese keywords allow you to specify the commands to be passed to Readmail whenever the associated keyword is used on the command line. Readmail understands a set of commands identical to this set of keywords (i.e., start, reset, status, control, switch, and stop), but they still must be set explicitly. Note that only one of these, Control, is designed to allow you to pass more than just a command: to the value of Control you can append data, either explicitly or using a substitution parameter. (In the case of other helper applications, these keywords may be assigned other values, depending on the commands these applications have been designed to accept.)
Readmail Logfile and Rollover Logfile
The names of the readmail logfile and rollover logfile are controlled by the parameters on the readmail command line:
[Process] ... {POPClient} ... Command=${TelAlertBin}/readmail ${EventData} -name ${Paragraph} -file POPClient.log & -back POPClient.%Y%m%d%H%M -size 50000 -time 01:00 -dayofweek 0 ...
If file or -back are not specified, the built-in defaults are those shown above. In the example for the -back filename, the % parameters are replaced at file creation time as follows:
POPClient.200211260915
This allows keeping each rollover file separate, instead of having the rollover files overwrite each other. However, there is a need to adopt some plan to archive off old rollover files. If you use -back POPClient.bak, then the rollover files will overwrite each other. You may include a file path in file or -back, but the file path is relative to the path given by telalertdir. (Also note that its telalertdir, not telalertbin/cfg/tmp). For example, if you have -file /logfiles/POPClient.log, and telalertdir is /var/opt/telalert, then the fully-qualified file location will be /var/opt/telalert/logfiles/POPClient.log. Regarding the other logfile-related parameters: -size - 50000 means that when the logfile reaches 50,000 bytes, it will be renamed to the -back filename and a new logfile created with -name. To disable switching on logfile size, omit the size keyword (do not use -size 0). -time -01:00 means that the logfile will roll over to -back at 1AM. Whether it rolls over daily or weekly depends on the value of -dayofweek. If the -time keyword is omitted, the logfile will not roll over based on time of day. -dayofweek -if this keyword is specified, the logfile will roll over weekly at -time; if it is not specified, the logfile will roll over daily at -time. The value following -dayofweek indicates which day the weekly rollover will occur; 0=Sunday, 1=Monday, ... 6=Saturday.
MIR3 does not recommend omitting both size and -time. If you do, then the logfile continues to grow until the disk runs out of space. If you decide to specify both size and -time, MIR3 recommends setting -size to a fairly high value, so that most rollovers will occur due to -time, but if you get a sudden influx of log entries, the -size will prevent the logfile from growing to excess size.
Readmail in Action
If the [Process] definition governing it is set to Active=True, Readmail runs when TelAlert is started. Based on the settings found in the above example, Readmail will check mail at the designated email address every thirty seconds. It will process emails that have been formatted to ack, nak, or reply to TelAlert notifications. It will also process emails that have been formatted to send notifications through TelAlert or to submit requests (refer to the discussion of requests in Chapter 8: Configuring for Paging Notification).
Readmail recognizes emails that it should process by parsing the subject line. Based on what it finds there, it generates and executes an appropriate TelAlert command. Details regarding the recognition and processing of particular kinds of emails are presented below. In most cases, users must understand what kind of subject line Readmail looks for, in order to send an email that is formatted appropriately. Sending Messages Readmail recognizes an email intended to generate a TelAlert send by the presence (in the first line of the messages subject line) the name of a TelAlert [Destinations] or [Group] definition. The subject line should take the form:
destination_name
or, in the case of sends to a group:
group: group_name
The body of the email message (up to TelAlerts configured maximum message length) will be used as the message text. After processing such a message, Readmail deletes it. Acting on Outstanding SendsReadmail recognizes an email intended to act on a TelAlert notification by the presence of certain magic words in the subject line:
10.7
SpectraLinks Link system is a wireless equivalent of a PBX telephone system, and is often integrated with conventional PBXes. You make calls within the system by dialing an extension number, and such calls incur no telephone-company or cell-phone charges. In addition to their standard telephone capabilities, the Link handsets include an LCD, which may be used to display text messages. If you connect a SpectraLink Open Applications Interface (OAI) Gatewaya modem-like boxto a TelAlert server, you can send messages to those displays, exactly as you would to one-way text pagers. To set up SpectraLink LCD notification, you must define a [Port] definition, a [Configurations] definition, and [Destinations] definition for each handset to which you wish to send text messages. To set up voice notification for the handsets, refer to Chapter 3 of the TelAlert Voice and Hardware Guide. (The definitions used for LCD and voice notification are completely independent.) Contact SpectraLink for information about the OAI Gateway. See your SpectraLink documentation for instructions on configuring handsets to use a distinctive ring pattern to indicate reception of a text message.
[Port] ... {SpectraLink} Active=True Model=Device Types=Device DeviceSubtype=3 SoftwareParity=False Dev=COM5: Speed=9600
The Dev setting must indicate the Windows COM port or UNIX device file for the serial port to which the OAI Gateway is connected. The other settings must be as shown. (DeviceSubtype=3 is the setting that lets TelAlert know that the device is an OAI Gateway.)
10.8
You can set up TelAlert so that it carries out certain notifications by issuing a command that will trigger a script or other application. Such a setup requires creating a [Configurations] definition and a destination only; no [Port] definition is required.
Here,
Command specifies:
the path to the Windows Media Player additional instructions for this applicationso that it closes after executing the command the path to the .wav file that the application is to play
Note that the actual .wav file is not specified. This command destination is set up so that the file can be supplied on the command line as the notifications message, like so:
telalertc -i sound -m ,
10.9
Windows includes net send functionality that allows popping up a message box on a networked PC. Although it is possible to create a TelAlert Command Configuration to invoke the net send command, it is simpler to use TelAlert's built-in Protocol=WINPOP access to the functionality. The following illustrates a Winpop example:
[Configuration] {Winpop} Type=TextPager Model=Internet Protocol=WINPOP From="TelAlert" [Destination] {GeorgeWinpop} Configuration=Winpop To=GeorgeDesktop telalertc -c Winpop -To GeorgeDesktop -m "Heres a popup" telalertc -i GeorgeWinpop -m "Heres another popup"
Note that when using -c Winpop, you use -to, not -PIN. Also notice that the To/-to value must be a DNS name; it cannot be an IP address. Also notice that From= is supported and is included in the text displayed in the popup. TelAlert does not support an equivalent to this popup functionality on UNIX, because of the variety of window managers and networking protocols. If you know that a particular utility providing this functionality is installed at your site, a Command Configuration can be used. The following is an example if the smbclient utility is installed:
[Configuration] {smbclientpop} Type=Command Shell="bin/sh -c" Command="smbclient -M ${PIN} -U TelAlert" Acked=252 PINRequired=True WriteExecsToTrail=False telalertc -c smbclientpop -PIN GeorgeDesktop -m "UNIX popup"
This UNIX Command Configuration example should be crossreferenced from the topic on command configurations, since otherwise all of the command configuration examples are for Windows. In TelAlert release 5.0 and earlier, Type=Email was required with and later, Type=TextPager is required instead.
Protocol=WINPOP; in 5.1
10.10.2 TelaConsole
To send messages to TelaConsole, you also use a [Configurations] definition of Type=TextPager. Here, Protocol should be set to TelaConsole. Service and Host should also be set appropriately. If you choose, you can provide "Facility code" and "priority" information just as with the Syslog protocoli.e., passed as the PIN value, typically either on the command line (using -pin) orin a [Destinations] definition (using the PIN keyword). The format for this information is facilitycode.priority, where facilitycode is a number between 0 and 127, inclusive, and priority is a number between 0 and 7, inclusive.
10.10.3 AS/400s
To send messages to an AS/400, the AS/400 must have the appropriate software installed on the AS/400. This is called QSYSOPR, available from Patrick Townsend Associates. Sending messages to an AS/400 also involves a [Configurations] definition of Type=TextPager in which Protocol should be set to QSYSOPR. Service and Host should also be set appropriately. The Access keyword, set in the same [Configurations] definition, is used to pass login information to the AS/400. The To keyword, typically set in a [Destinations] definition, allows you to specify the queue in which the message should be placed. Alternatively, you can use the to tag on the command line.
{NextelUPNotify} Type=TextPager Protocol=UPNOTIFY Host=atlsnup2.adc.nexteldata.net Service=4445 Subject=ALERT-${SendID} ReplyTo=http://www.company.com/cgibin/telalerths?sendid=${SendID} Type must be set to TextPager, and Protocol must be set to UPNOTIFY. The Subject value is the message that will first show up in the recipients browser. The ReplyTo value is the URL to which the recipients browser will be directed when the recipient reads the message from TelAlert.
A [Destinations] definition simply points to the [Configurations] definition and provides a PIN, which is the telephones subscriber ID, not the telephone number:
{NextelSMTPTwoWay} Type=InteractiveTextPager Protocol=SMTP Host=messaging.nextel.com Service=smtp ProtocolMask=4 To=${PIN}@messaging.nextel.com From=telalert@yourcompany.com AddSendIDToMessage=True PINRequired=True
A [Destinations] definition typically contains only a reference to the [Configurations] definition and a PIN value (the telephone number):
{Europolitan} Type=InteractiveTextPager Model=Internet Protocol=CIMD2 ProtocolMask=0 ServerPIN=1234567890 Access=ID:password Host=123.45.67.8 Service=9972 TextPagerWait=30s ConfirmDelivery=True PollRequests=True ProcessCharacterEscapeCodes=True QuoteControlCharacters=False StripControlCharacters=False $include CharMap.gsm
The [Destinations] definition typically does nothing more than point to the [Configurations] definition and provide a PIN value:
10.14 Sending Two-Way Text Messages to SMS Mobile Telephones Via a GSM Wireless Modem
Used with a GSM wireless modem, TelAlert can send text messages directly to SMS mobile phones.
One-way pages, and the outgoing part of two-way pages, are sent out via the [Port] and [Configuration]. Responses to two-way pages come back via the [Process]; if only one-way paging is used, the [Process] is not required. For simplicity, in the sample definitions, the name {GSMModem} is used for the [Port] and [Configuration], and the name {GSMPoll} was used for the [Process]. These specific names are not required; any names can be used, as long as all references to the names are properly updated.
Protocol=GSM
These definitions are used for both one-way and two-way paging; no [Process] is used. Again for simplicity, the samples use the name {GSMModem} for both the [Port] and the [Configuration], but any names can be used. TelAlert 5.6 supports both techniques; existing GSM wireless modem users that upgrade from 5.2 to 5.4 will continue to use the older technique. If a GSM modem [Port] is defined during a new installation of 5.4, the installer will set up a [Port] and [Configuration] using the newer technique.
Option SendID
or
SendID Option
where Option is one of
The newer technique requires that a custom [Response] list be specified on the command line. The newer technique's SMS replies must be in the form
SendID response
where response must be one of the responses specified on the original command (for instance, if the original command contained the specification
-response basic
then response must be one of Yes, No, Hold, Info, Release, or Ping). Note that these basic responses are not the same as the options for the older technique. To facilitate upgrading, a new set of responses has been created -- refer to {GSMResponse} below. However, even with these responses, the newer technique requires SendID before the response; the older technique would accept SendID either before or after the option. Also, there isn't any newer response equivalent for the older clear option; this shouldnt be a problem because clear is normally used when nobody has responded, rather than as a response option in itself. These new responses would be invoked by including
-response GSMResponse
on the
Note on Using these Samples with the TelAdmin Import Function If the following sample definitions are used with the TelAdmin Import function, be aware that lines that require customization to a particular customers values, such as
Dev=<<dev>>
will not import as-is. There are two choices: 1. 2. Edit these lines before copying to the clipboard. The import function will give errors for lines that cant be imported; make a note of these lines and set the appropriate keyword values via the main TelAdmin panel.
Example definitions for the older technique: [Port] {GSMModem} #A. Model=DirectModem because no dialing is needed to connect to # the service provider #B. Types=TextPager since only outgoing is handled by [Port] {GSMModem}; # incoming responses are handled by [Process] {GSMPoll} #C. Share=True to allow [Process] {GSMPoll} access to the modem #D. Class=1 to link with [Configuration] {GSMModem} #E. No Modem= value needed since no brand/model-specific commands are used Active=True Model=DirectModem Types=TextPager Dev=<<dev>> Speed=<<speed; some modems are 9600-only, others are 19200-only>> Share=True Class=1 [Configuration] {GSMModem} #A. Type=TextPager to link with [Port] {GSMModem} #B. Model=DirectModem to link with [Port] {GSMModem} #C. Protocol=Chat to allow imbedding AT commands specific to GSM # wireless modems in this configuration, since the core telalertm # executable is not aware of them #D. ChatLogon,ChatScript,ChatLogoff -- see Protocol=Chat above #E. Class=1 to link with [Port] {GSMModem} Active=True Type=TextPager Model=DirectModem Speed=<<speed; some modems are 9600-only, others are 19200-only>> Protocol=Chat PINRequired=True Parity=None MaxMessageLength=160 MaxMessagesPerCall=1 150 | TelAlert 6e Administrator Guide - Version 6.1.29
#ChatLogon="" \EAT+CMGF=1 OK #ChatScript="" \EAT+CMGS="\P" > \M\x1A\c OK #ChatLogon="" \EAT+CMGF=0 OK ChatLogon="" ChatScript="" \EAT+CMGF=1 OK \EAT+CMGS="\P" > \M\x1A\c OK ChatLogoff="" Class=1 [Process] {GSMPoll} # See notes for details on the Command= line Active=True Shell="" Command=${TelAlertBin}/gsmpoll "${EventData}" -name ${Paragraph} & -file gsmpoll.log -back gsmpoll.%Y%m%d%H%M -size 50000 & -dev COM6 -speed 9600 -parity none & -sleep 30 -debug 0 Start=${TimeStamp} Start Reset=${TimeStamp} Reset Status=${TimeStamp} Status Stop=${TimeStamp} Stop
Set Speed= to the modems correct speed setting (9600 for most GSM modems; because the trailing 0 is optional, 960 is equivalent to 9600). To determine the speed of the modem (and check the availability of the port), use testcomm, a utility included with TelAlert. Use this command line:
-file Name The log file will be named Name. Default value is readmail.log -back Name
The backup log file will be named Name. Default value is readmail.%Y%m%d%H%M. Both Names are passed through strftime (). Common substitutions are: %Y: 4-digit year %m: 2-digit month (1-12) %d: 2-digit day of month %H: 2-dight hour, 24 hour clock %M: 2-digit minute
-size n
When the log file reaches n bytes, the backup log file is removed, the log file is renamed to the backup log file and a new log file is created. By default, the log file is not switched based on size.
-time hh:mm
When the time passes hh:mm (24 hour clock), the backup log file is removed, the log file is renamed to the backup log file and a new log file is created. By default, the log file is not switched based on time.
-dev <device>
This is the Device where your GSM modem has been connected. This should match the Dev= value in one of your [Port] section definitions. The [Port] definition with this device specification must have Share=True set.
-speed <speed>
The speed of the GSM modem. This should match the definitions.
-sleep N
The number of seconds between poll checks. The default value is 30.
-debug N
Debug level. Set to 1024 to have modem interaction written to log file (-file)
Example definitions for the new technique: [Port] {GSMModem} #A. Model=Modem and ModemSubtype=2 to invoke new core code that # is specific to GSM wireless modems; ModemSubtype=2 also links # to [Configuration] {GSMModem} #B. Modem=xxx_GSM required when Model=Modem #C. Share=True not required since GSMPoll no longer used #D. Class=1 no longer needed; [Configuration] {GSMModem} linked # by ModemSubtype=2 Active=True Model=Modem ModemSubtype=2 Types=TextPager,InteractiveTextPager Modem=<<[Modem.xxx_GSM]>> Dev=<<dev>> Speed=<<speed; some modems are 9600-only, others are 19200-only>> [Configuration] {GSMModem} 152 | TelAlert 6e Administrator Guide - Version 6.1.29
#A. Set Type=TextPager for one-way, InteractiveTextPager for two-way #B. Protocol=GSM enables hard-coded GSM AT modem commands in telalertm #C. ModemSubtype=2 links to [Port] {GSMModem} #D. ProtocolMask setting depends on service provider; try 0 first, then 1, then 2 #E. Set AddSendIDToMessage True for two-way, either True or False for one-way {GSMModem} Active=True Type=InteractiveTextPager Protocol=GSM Speed=<<speed; some modems are 9600-only, others are 19200-only>> ModemSubtype=2 MaxMessagesPerCall=1 PINRequired=True PollRequests=False # ProtocolMask::= 1 -> Send in Text Mode; 0 -> PDU mode # ProtocolMask::= 2 -> Send as Flash Message; 0 -> Normal Message # Note: Flash messages must be sent in PDU mode - e.g. a value of 3 # wont work. ProtocolMask=0 AddSendIDToMessage=True [Response] {GSMResponse} # Used to have the newer 5.4 GSM two-way responses look similar to the # older 5.2 GSM two-way responses. The older clear response is # not supported in the newer method. # TelAlert matches on case-INsensitive leading substring. For instance, since # Reply2=Nak, then the following will match: N, NA, nak, and NAK. But # NO will NOT match because there isnt any O in Reply2=Nak NumReplies=4 Acked=1 AckedHold=3 NotAcked=2 Released=4 Reply1=Ack Reply2=Nak Reply3=Hold Reply4=Release
Model=FaxModem and
FaxFSI keyword has been added to the [Configuration] section. FaxCSI keyword has been added to the [Destination] section.
[Port] {FaxModem1} Model=FaxModem Types=Fax Dev=COM3 Speed=19200 Modem=DN400E [Configuration] {Fax} Type=Fax Model=FaxModem FaxFSI=AAA-BBB-CCCC [Destination] {FaxZZZZ} Configuration=Fax AreaCode=AAA Number=XXX-YYYY FaxCSI=ZZZZ FaxFSI (the Fax Subscriber Identifier) is the string sent by TelAlert to the remote fax machine to indicate the source of the fax. FaxFSI can be up to 20 characters. FaxCSI (Called Subscriber Identifier), is the string returned by the fax machine at (AAA)XXX-YYYY to identify itself to TelAlert. If FaxCSI is specified, the value returned by the fax machine must match FaxCSI exactly, otherwise the fax is not sent. If FaxCSI is not specified or blank, no checking is performed. FaxCSI can be up to 20 characters.
In addition, the command line option: -faxcsi string can be used to specify, but not replace, the FaxCSI string from a [Configuration] or [Destination]. The first 32 characters of Subject= or Identifier) to the remote fax machine.
If the destination (BostonModem) is of type Email or Modem or InteractiveModem, the message will be sent with variable substitution only if the message is shorter than MaxMessageLength. If the destination type is Modem or InteractiveModem and the message is longer than MaxMessageLength, the message will be sent without variable substitution. If the destination is type Email, then the message file is not processed until telalerte's telalerts child process actually connects to the smtp mail server. This may be a concern if the message file is dynamically produced, and a new event may overwrite the existing message file before it has been read and sent. Note: the message file is read by the server telalerte process, not the client telalert(c). Thus, if you are running telalertcon a client machine, you must specify ~file with a path that the TelAlert server can follow, not a path that the telalertc client can follow. So, you either need to move the file (using FTP or another such protocol) from the client machine to the server machine before issuing the telalertc command; or move the file to a file server that both machines have access to before issuing the telalertc command; or have set up a share for a disk on either the client or server machine, such that the client can place the file on the shared disk and the server can read the file from the shared disk, before issuing the telalertc command.
If the client and server machines do not have shared access to a common directory, then the telalertc client will be restricted to specifying canned message files that reside on the server. OR: The fact that the server, not the client, reads the message file is what allows the contents of the message file to be larger than what the internal buffers in telalertc can hold. Thus, the restriction that the server reads the file cannot be changed. However, if the contents of the message file are short enough to fit into telalertc's buffers, there are a couple of workarounds.The first workaround has the O/S read the file and pass it as text to the telalertc command; it works on a UNIX system, or on a Windows system with a
Bourne/Korn shell such as the MKS toolkit that can provide both command substitution (command) and the "cat" command:
10.17 SMPP
TelAlert supports the SMPP (Short Message Peer to Peer) TCP/IP protocol. Although SMPP is an international standard, there are slight differences in implementation between different service providers, and thus TelAlert must test and fine tune its configurations for each new provider supporting SMPP. Currently Vytek has tested configuration for AT&T. AT&T is providing SMPP as part of a set of advanced messaging services; customers must sign up with AT&T for these services before the AT&T servers will accept SMPP messages from TelAlert.
Note: AT&T calls partner products like TelAlert Adapters, because they allow customers to quickly and easily connect mission-critical software (OpenView, Tivoli, Remedy, etc.) to AT&T's secure and reliable communication solutions, without any need to do custom programming.
SMPP is basically a one-way protocol; optionally, it can provide a confirmation of delivery to the handheld device, although not all service providers may implement delivery confirmation, and delivery confirmation does not show that the message has actually been read. If delivery confirmation is supported by the service provider, TelAlert can pass the confirmation to an external script, which users can customize to update applications such as OpenView, Remedy, etc. Although a service provider may optionally allow the handheld device to send a SMPP message back to TelAlert, this is not precisely two-way messaging in the TelAlert sense. The SMPP protocol, unlike some other protocols, does not provide an internal unique ID field that unambiguously links the original message with the return message. Instead, the user must manually enter sufficient information in the return message to allow TelAlert to match the return message with the original message. It is important that the user does not omit or mistypes that information as TelAlert may not mark the alert as acknowledged, or may mark the wrong alert as acknowledged. MIR3 recommends that where two-way response capability is critical, users investigate the use of protocols such as SNPP or WCTP that are designed for two-way messaging and contain internal unique ID values to match original and return messages.
HTTPProxyRequired
A True/False variable indicating whether the Proxy mechanism is to be used (True) or not (False.)
HTTPProxyHost
The IP address of the HTTP Proxy server. This is typically an address within the customers network domain.
HTTPProxyService
The TCP/IP port value for the HTTP Proxy server. The default text value is "webcache"; the default numeric value is 8080. As an example, the Arch Wireless WCTP [ Configuration] looks like:
{ArchWCTP} Comment=Arch WCTP service for Two-Way messaging. Type=InteractiveTextPager Protocol=WCTP Host=wctp.arch.com Service=http # For one-way paging, set ServerPIN to yourname.yourdomain and # Access="", and un-comment both lines. # For two-way paging, you'll need to get an account set up with # Arch. Use the senderID/securityCode provided by Arch, and # un-comment both lines. # ServerPIN=<your senderID> # Access=<your securityCode> PollRequests=False TextPagerWait=30s ProtocolMask=32
{ArchWCTP} Comment=Arch WCTP service for Two-Way messaging. Type=InteractiveTextPager Protocol=WCTP Host=wctp.arch.com Service=http # For one-way paging, set ServerPIN to yourname.yourdomain and # Access="", and un-comment both lines. # For two-way paging, you'll need to get an account set up with # Arch. Use the senderID/securityCode provided by Arch, and # un-comment both lines. # ServerPIN=<your senderID> # Access=<your securityCode> PollRequests=False TextPagerWait=30s ProtocolMask=32 HTTPProxyHost=10.11.10.99 HTTPProxyService=8085 HTTPProxyRequired=True
Note: For Service=http, TelAlert looks up http in the servers etc/hosts file, and uses the numeric value found there (normally 80). It is legal to use Service=80, which allows TelAlert to skip the etc/hosts lookup step. The following describes the differences in TelAlerts processing when using one or the other of the above configurations: Non-Proxy access: 1. 2. Connect to wctp.arch.com:http Send "POST /wctp HTTP/1.1"
Proxy access: 1. 2. Connect to 10.11.10.99:8085 Send "POST http://wctp.arch.com:80/wctp HTTP/1.1" Note that the numeric Service value is substituted in the POST directive, rather than "wctp".
Simply changing HTTPProxyRequired to False will cause the Configuration to revert back to non-Proxy mode - its not necessary to blank out the HTTPProxyHost/Service values, or remove those keywords.
11
Applying Filtering Techniques
11.1 Overview
Instructions for using each of TelAlert filtering mechanisms to prevent certain messages from being sent under certain conditions. These mechanisms rely on (1) [Filter]definitions; (2) message priority; (3) -check string value; (4) IP address or host name, and (5) -source string.
11.2
Getting Started
11.3
A Simple Filter
11.3.2 Procedure
To set up this simple filter, David first creates the following [Filter] definition and refers to it in his destination. In TelAlert 6e, Filters are referenced under the Advanced tab as shown below.
[Filter] ... {DavidFilter} Active=True RequiresFullMatch=False Exclusive=False Tags=Router,Server [Destinations] ... {DavidTextPager} Configuration=ATTWichitaTextPager PIN=3456789 Filter=DavidFilter
The relevant line in the [Destinations] definition is the values in the [Filter] definition is as follows: ActiveSet to
True, this makes the [Filter] definition available for use by TelAlert.
RequiresFullMatchSet to False, this means that a minimum of one tag specified in the [Filter] definition must be matched by a tag specified on the command line for the destination to be deemed a match. Set to True, this means that all tags specified in the [Filter] definition must be matched by those on the command line. How a match is treated is determined by the Exclusive setting. ExclusiveThis determines how TelAlert treats a destination that it, on the basis of the tags specified and the RequiresFullMatch value, views as a match. When this is set to False, TelAlert will includei.e., will deem valida matching destination while excluding all non-matching destinations. When this is set to True, TelAlert will excludei.e., will not send toa matching destination while sending to all non-matching destinations. TagsThe values entered here serve solely as a means for determining a match or non-match between a command and a destination. Even though TelAlert understands a tag only as a string of characters to compare against another string of characters, you should name your tags so that you can understand what they refer to. Having created this [Filter] definition and added this line to {DavidTextPager}, David then modifies the network monitoring application so that, in passing news of an event to TelAlert, it specifies a tag on the command lineserver, router, modem, printer, etc.so that the complete command looks like this:
Here, the message is not sent because (1) the destination is a non-match (since the tag specified here does not match any specified in the [Filter] definition); and (2) Exclusive is set to False (meaning that matching destinations, and only matching destinations, are included). Note that: If he changed the Exclusive setting to True, the [Filter] definition would operate exclusively, but here the message would be sent because TelAlert excludes only matching destinations and includes all non-matches. If he changed RequiresFullMatch to True and left Exclusive set to False, the message would not be sent. The destination is not a match because none of the [Filter] definitions tags appear on the command line. As a non-match, the destination is excluded, since the Exclusive setting specifies that only matching destinations are to be sent to. If he changed RequiresFullMatch to True and Exclusive to True, the message would be sent. The destination is not a match because none of the [Filter] definitions tags appear on the command line. As a non-match, the destination is included, since the Exclusive setting specifies that only matching destinations will be excluded. In the case of events that David wanted to be informed of no matter what, he would set up the network monitoring application to issue appropriate commands without a -tags value:
11.4
Filtering Strategies
[Destinations] ... Filter=DefaultFilter ... {DavidTextPager} ... {JohnTextPager} ... {RachelTextPager} ... Filter=RachelFilter
{DavidTextPager}and {JohnTextPager} are both associated with {DefaultFilter} while {RachelTextPager} is associated with its own [Filter] definition, {RachelFilter}.
A [Filter] definition specified directly on the command line overrides all others. Thus, in the case of the following command
Exclusive provides a
RequiresFullMatch=False, Exclusive=False
Generally speaking, this combination is useful when you want all of the messages directed to a destination to be filtered (and thus not sent) unless they meet specified criteria. It differs from the True-False combination, however, in that it allows you to specify a set of criteria and have the destination be considered valid if it matches in a single respect. In the example provided, this combination is appropriate because David wants to filter all messages other than those specified. At the same time, he wants to be able to provide a fairly loose specification: either messages tagged with Router or messages tagged with Server.
RequiresFullMatch=False, Exclusive=True
Generally speaking, this combination is useful when you want all of the messages directed to a destination to be sent unless they meet specified criteria (in which case you want TelAlert to discard them). It differs from the True-True combination, however, in that it allows you to specify a set of criteria and have the destination be excluded if it matches in any respect. Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive any message directed to it unless the message falls into one of three classes: those relating to Web servers, those relating to mail servers, and those relating to Internet gateways. To accomplish this, you would: use the
configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)
RequiresFullMatch=True, Exclusive=False
Generally speaking, this combination is useful when you want all of the messages directed to a destination to be filtered (and thus not sent) unless they meet specified criteria. It differs from the False-False combination, however, in that it allows you to specify a set of criteria and have the destination be considered valid only if it matches in every respect. Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive only a very narrow set of messages. For instance, your network monitoring application may be able to generate notifications about a number of different status changes and node types, but in this case you want to receive node down messages only, and only those pertaining to downed UNIX serversnot routers, and not Windows servers. To accomplish this, you would: use the
configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)
RequiresFullMatch=True, Exclusive=True
Generally speaking, this combination is useful when you want all of the messages directed to a destination to be sent unless they meet specified criteria (in which case you want TelAlert to discard them). It differs from the False-True combination, however, in that it allows you to specify a set of criteria and have the destination be excluded only if it matches in every respect. Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive any message directed to it unless the message has all of three special characteristics: it pertains to a (1) workstation (2) manufactured by Hewlett-Packard and (3) running UNIX. To accomplish this, you would: use the
configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)
Interaction Between
RequiresFullMatch works in conjunction with the tags specified in the filter and on the command line to determine whether a destination is a match. Exclusive tells TelAlert what to do with matches and, implicitly, with non-matches.
With Exclusive set to False, matching destinations are used and non-matching destinations are discarded. With Exclusive set to destinations are used.
11.4.3 RequiresClientMatch
The RequiresClientMatch keyword has roughly the opposite effect of RequiresFullMatch: When this keyword is set to True, the filtering condition is met only if all the tags passed on the command line are also listed in the [Filter] definition. (Additional, non-matching tags present in the definition do not prevent a match.) Use this keyword when you want to filter out messages with tags that do not match a specific list.
Consider the following [Filter] definitions, each associated with {JohnTextPager}, {DavidTextPager}, {RachelTextPager}, and {CynthiaTextPager}, respectively:
[Filter] ... {John} Active=True RequiresFullMatch=False Exclusive=False Tags=Server {David} Active=True RequiresFullMatch=False Exclusive=False Tags=Workstation {Rachel} Active=True RequiresFullMatch=False Exclusive=False Tags=Router {Cynthia} Active=True RequiresFullMatch=False Exclusive=False Tags=Modem
Now, recalling that {Support} is a group of destinations comprised of {JohnTextPager}, {DavidTextPager}, {RachelTextPager}, and {CynthiaTextPager}, consider this command:
A group can be associated with one [Filter] definition, a subgroup within that group with another, and each of the individual destinations with still others. If, after evaluating the groups [Filter] definition, TelAlert finds that the group is valid, it evaluates the subgroups [Filter] definition. If this too is valid, it looks at the [Filter] definitions invoked at the destination level. In such a case, the message will be sent to a destination only if all three [ Filter] definitions permit it.
[Filter] ... {JohnFilter} ... [User] ... {John} ... Filter=JohnFilter ... [Destinations] ... {JohnTextPager} ... User=John ... {JohnCellPhone}
170 | TelAlert 6e Administrator Guide - Version 6.1.29
11.5
There is another filtering technique that lets you determine whether a message directed to a given destination is actually sent to that destination. This involves assigning the message a priority on the command line and including MinFilterPriority and MaxFilterPriority values in the [Destinations] definition. If the messages priority is less than MinFilterPriority or greater than MaxFilterPriority, it is not sent. Consider this destination:
telalertc -i CynthiaTextPager -m "this is a test" -priority 40 telalertc -i CynthiaTextPager -m "this is a test" -priority 80 telalertc -i CynthiaTextPager -m "this is a test" -priority 90
Here, the first message would not be sent, because its priority is less than the MinFilterPriority assigned in the destination. The second message would be sent, because its priority is neither less than the MinFilterPriority nor greater than the MaxFilterPriority. The third message would not be sent, because its priority is greater than MaxFilterPriority.
Schedule-Based Filtering Schedule-based filtering (including schedule-based filtering using covered in Chapter 12: Setting Up and Applying Schedules.
priority) is
[Destinations] ... {DavidEmail} ... MinFilterPriority=1 MaxFilterPriority=40 {DavidVoiceMail} ... MinFilterPriority=40 MaxFilterPriority=80 {DavidTextPager} ... MinFilterPriority=80 MaxFilterPriority=100
With these values in place, he could then create a group pointing to these destinations:
MinFilterPriority and MaxFilterPriority do not have to be used so that they create a middle rangee.g., from 50 to 80. You can set MinFilterPriority to 60, for example, and MaxFilterPriority to 100; this means that all messages of priority 60 or higher will be sent to the destination. Likewise, you can set MinFilterPriority to 0 and MaxFilterPriority to 60; this means that all messages of priority 60 and lower will be sent to the destination.
11.6
The telalert.ipchk file can be used to determine whether an alert is processed or discarded by TelAlert based on the identity of the machine with which the alert is concerned. Typically, you would edit this file so that it contains the IP addresses of all machines that you do not want to be the basis for alerts. To exclude the machines with IP addresses in telalert.ipchk, you must also set the value of the NegativeIPCheck command to True (its default is False). When you start TelAlert, the contents of the file are loaded into an in-memory filter. To invoke this filter, you would set up your TelAlert integration so that, each time a command to generate an alert is issued, the IP address of the pertinent machine is included on the command line, preceded by the -ipcheck option:
telalert.ipchk
You can reverse the function of telalert.ipchk by changing the value of the NegativeIPCheck command: Setting the command to True causes commands containing -ipcheck, with IP addresses that match those in telalert.ipchk, not to be processed (as described above). Setting NegativeIPCheck to False (its default value), causes those commands with matching values to be included and processed.
You can edit the contents of this filter on the fly. To add an address:
11.7
Users who control TelAlert with network management applications frequently have problems with duplicate messages. Another common problem is transient messages produced by devices that occasionally go offline and come back on by themselves.
telalertc -i RachelPager -m "node 123 down" -check "node 123 down" -holdifsent -holdrefresh -releasewait 6m
When a node first goes down and TelAlert receives this command, it sends the node down message. Since the command contains the -holdifsent option, TelAlert then puts the message in a held state. If five minutes later TelAlert receives the command again, it finds that its -check string matches the held message, so it does not send the duplicate message. Since the command contains the -holdrefresh option, TelAlert resets the -releasewait timer, holding the message for another six minutes. If five minutes later TelAlert receives the command yet another time, it resets the -releasewait timer again, and keeps doing so until the node comes back up and the network management application stops sending the repetitive commands. Thus TelAlert sends only one message each time the node goes down.
telalertc -i RachelPager -m "node 123 down" -check "node 123 down" -holdifsent -holdrefresh -releasewait 6m -delay 7m -affirm 1
When a node first goes down and TelAlert receives this command, it does nothing immediately. Instead, it waits for seven minutes (-delay 7) to see if it receives one (-affirm 1) additional command with a message that matches its -check string. (Note that the affirm value represents the number of duplicates required within the time frame represented by the delay value before TelAlert will send the original message. The original command does not count against the -affirm count.) If five minutes later TelAlert receives the command again, it finds that its -check string matches the held message, sends the delayed message, and does not send the duplicate message. Since the delayed message contains the -holdifsent option, TelAlert then puts the message in a held state. From that point, TelAlert proceeds as in the previous example, discarding duplicate messages until the network management goes at least six minutes without sending a node down command.
telalertc -i RachelPager -m "node 123 down" -check "node 123 down" -delay 6m
Use a command similar to this one for node up messages:
telalertc -g support -m "node 2302 is down" -filterschedule SystemUp -check "node 2302 is down" -delay 5m telalertc -g support -m "node 2302 is up" -filterschedule SystemUp -cancelnc "node 2302 is down"
With those commands, TelAlert will send the up message only if its -cancelnc string matches the -check string of a message that is not in a delayed state, for example, one that has been responded to with an ackhold. If TelAlert does not find such a match, it does not send the up message, and also deletes any delayed messages that match the cancelnc string. In other words, TelAlert sends an up message only when a down message has been sent and has not yet been cleared.
telalert -g support -m "node 2302 is down" -delay 5m -filterschedule SystemUp -check "node 2302 is down"
When you use -delay in combination with -filterschedule, TelAlert does not discard messages during downtime. Instead, it delays them until the scheduled uptime, plus the number of minutes specified in -delay. Send your up messages with the following command, and the down messages will be sent only if the machine does not come back online within five minutes of the scheduled time:
telalert -g support -m "node 2302 is up" -filterschedule SystemUp -cancel "node 2302 is down"
11.9
The telalert.alert file can contain, among other things, certain filtering information referred to by TelAlert in determining whether or not it should process each notification it receives. For instance, as discussed above, there are ways (both automatic and manual) to load a -check value into this file, so that any messages to which a matching -check string is affixed are discarded. It is also possible to load a -source value into telalert.alert, so that TelAlert discards all subsequent messages with matching source strings. This lets you ensure that no messages from a specified source are processed. All operations related to -source filtering must be carried out manually; they cannot be performed as part of a send. For example:
Pattern-matching provides support for a wide range of Boolean and wildcard expressions. For example, you can combine the two commands presented above into a single command:
telalert -show -selectpe source "remedy|openview" -selectpe means select pattern expression. You can specify alerts according to message
content:
-checkpe
The checkpe operator is used to compare a new message against messages already in the TelAlert queue. Where previously, you might have used:
-checkpe
-filterpe
A -filterpattern is used in conjunction with -i/-g/-l/-c/-cpl and -mto filter messages. The pattern expressions are applied to the command line parameters specified with I and -m. If the match expression is true, the message is filtered. For example, to filter out automatically generated "Node Down" messages that contain references to Printers:
-cancelpe
A cancelpattern is used in conjunction with -i/-g/-l/-c/-cpland -m to cancel the new message if a matching message is found. The pattern expressions are applied to existing Alerts; if the match expression is true for an Alert, the Alert is cleared. The new message is dropped if any Alert that was cleared had status SS_Delayed. The new message is also dropped if no Alert matched and the -cancelnc option as specified.
To use this to show active sends to SkyTel (assuming that all SkyTel Configurations names contain "Sky"), use:
The following pattern additionally filters out entries with a user value other than
".*Ross.*"
telalert -show -selectpe configuration "sky" \-selectpe user "ross" \-selectpm "configuration & !user"
12
Setting Up and Applying Schedules
12.1 Overview
Instructions for using [Schedule] definitions to specify the times when destinations are valid for sending notifications.
12.2
Getting Started
Schedules Specify On-Duty Hours The main component of a schedule is a list of on-duty hours. Unless you create an exception to these hours, they represent the only times during which a destination associated with the schedule is on-duty.
Managing Schedules
This section covers the following topics: Schedule Types Viewing Schedules Creating Group Member Schedules Assigning Group Member Schedules
Schedule Types
The following schedule options allow users to determine exactly when they and each of their devices are on duty and available to receive alerts. Some of the schedules are user specific like vacation and device schedules. Others are specific to a particular group like group member and extra duty schedules, only affecting alerts that are sent to a particular group. Although all schedule types are listed below, this section focuses on schedules assigned at the group member level. Holiday Schedules are system wide and affect all users in the system. Holidays are shown in the group member schedule calendar display. Vacation Schedules are user specific. Users will not receive alerts during their designated vacation time. Vacation times appear in the group member schedule calendar display. Device Schedules are user specific and determine when an individual device is on duty and available to receive alerts. Device schedules affect alerts sent directly to the device, the owner of the device and when alerts are sent to groups containing the device or owner. Device schedules are created for individual devices and are associated with the owner of the device. The device schedule can only be assigned to this particular owners devices. Other users will not see the device schedule in the Default Schedule drop-down list on the Edit Device Schedule page. Group Member Schedules are group specific and only influence alerts that are sent to the group. Each member of a group is assigned a schedule which determines whether or not that member will be notified when alerts are sent to the group. Users, devices and groups may be members of multiple groups therefore having multiple schedules or may not be a member of any groups and have no schedules.
Extra Duty Schedules, like group member schedules are group member specific. They are assigned when it is necessary for a group member to be on duty outside of their Regular Schedule hours. Note: All of the schedule types above can be viewed in the group member schedule calendar display.
Viewing Schedules
Schedules can be viewed on the Home page of the application and for staff users under the Schedules tab. Users will only see schedules if they belong to a group since the schedule display is based on group membership. As a supervisor or administrator, you will also see the schedules for all groups belonging to your department. The system administrator can see the schedules for all groups in the system. The schedule display on the Home page is a view of the users current week schedules. The display on the Edit Group Schedules page for administrators and supervisors and the Schedules page for staff users can be set to either day, week or month view. In all views your scheduling status is represented using the following color codes:
On Duty - You (or the devices you own) are scheduled to receive alerts during these hours. Extra Duty - You (or the devices you own) are scheduled to receive alerts during these hours, regardless of whether it is a vacation or holiday period. Vacation - The system will not alert you unless Extra Duty is configured during your vacation hours. Holiday - The system will not alert you on days specified as a holiday by the system administrator, unless Extra Duty is configured during the holiday. Off Duty - You (or the devices you own) are not scheduled to receive alerts during these hours. Current Time - The current time of day is highlighted in the schedule display as a vertical orange bar. This is referred to as the Current Time Indicator and allows the user to reference the current time in the Time Zone selected in the Time Zone drop-down menu. To display schedules in the future or past, use the Jump To date field or calendar icon to show other duty cycles.
Note: By default, the schedule pages will display the time of day relative to the time zone of the logged in user, but you can see how schedules appear to users in other time zones. So, even if you were a user from New York (EST), you could view your schedule as it would appear to a user in San Francisco (PST) by selecting Pacific Time in the Time Zone drop-down menu.
12.3
Scheduling Approaches
Supervisor overrides the Default Schedule The message will be delivered according to the Schedule attached to the Device by the Supervisor. This approach is useful where a Users on-duty hours need to be different in different Groups. The Schedule associated with the User or Device is controlled by the Supervisor and cannot be changed by the User. In any case, the Schedule displayed in the Web UI is the Schedule that will apply to the User. This means that if a user has multiple devices and at least one device shows the recipient as on duty the alert will successfully go through.
12.4
Devices can be assigned schedules so that they are only available to receive alerts during specified periods when they are considered on duty. Users can create and assign schedules for their own devices. Supervisors and Administrators can create and assign device schedules for all devices owned by users in their department. Defining device suchedules is optional. If you do not assign a device schedule, the systems default setting of 24x7, always on duty is explicitly applied.
Figure 26. Edit Device Schedule page allows user to assign a default device schedule.
Device schedules tell TelAlert whether a device is on duty at the time an alert is sent. Setting up schedules for devices rather than for people might seem counterintuitive. However, setting up schedules for devices makes it possible to send alerts to a particular device--Johns phone-during certain hours and to a different device--Johns pager--during other hours. To assign a device schedule, do the following: 1. Click the Devices tab. The Manage Devices page displays.
2.
Choose the device from the list by clicking the to the left of the devices name.
3.
The default schedule for new devices is 24x7, indicating that the device is available to receive alerts at any time. 4. To assign a device schedule, select the desired schedule from the Default Schedule drop-down menu. Select the date the schedule should go into affect in the Start Date field followed by the Save button.
Note: Device schedules are listed below global schedules in the Default Schedule drop-down menu under the User Defined Schedules heading. Device schedules are considered User Defined because they are linked to the owner of a device and are available to that user only for assignment to their devices. Other users in the system will not have the ability to assign another users device schedule to their own devices. If you would like a schedule to be available to more than one user, create a global schedule instead of a device schedule. The global schedule will appear in the Default Schedule drop-down menu under the Global Schedule heading and will be available for use by all users in your department. 5. When the device schedule has been assigned you will see a confirmation page indicating the device details (in this case the schedule) have been updated successfully.
8.
In the Description field, enter a brief description of the device schedule. This is optional, but very useful when managing many schedules. Indicate the Repeat Pattern and On Duty Hours Pattern and select the Next button.
9.
10. Enter the times and days of the week that the device will be on duty and available to receive alerts. Note: A device with the 9 to 5 device schedule will NOT receive alerts sent on Monday at 8:59. The device will receive alerts sent on Monday at 9:00. Additionally, they will NOT receive alerts sent on Monday at 17:01. 1. Select the Save button.
The device schedule is now available to assign to the selected device and any additional devices owned by the same user on the Edit Device Details page. 2. To assign this or other device schedules to a device see Assigning Device Schedules at the top of this section.
12.5
Global and group member schedules can be created by supervisors and administrators. They can be made available to All Groups or limited to a particular group within the users department. There are two types of regular schedules: a weekly schedule and a rotating schedule. The standard weekly schedule starts on Sunday and ends on Saturday. Rotation Schedules The rotating schedule can start on any day of the week and can consist of anywhere from 1 to 98 days. Once this members schedule is established the next member with the same schedule will be on duty for the specified period of time. In the case of vacation or unexpected leave the on duty members date should be switched to reflect as on duty and the start dates can be readjusted upon the missing members return.
Figure 27. The Manage Schedule page allows supervisors and administrators to view existing schedules.
Note: When a Schedule is created, it is not tied to a Time Zone. When a Schedule is assigned to a User or Device, the Schedule will use the Time Zone associated with the profile of the User or the Users Device(s). See example in Effect of Time Zones section below.
Figure 29. Schedules are assigned to individual group members on the Edit Group Member Schedule page.
All members of a group must be assigned a Regular Schedule. When group members are originally added their device schedule determines their availability. To change the default device schedule, select one of the schedules in the Schedule drop-down menu and a Start Date. This will override any Device Schedule set by the User.
In the Extra Duty Schedule section enter the date and time the group member will be on duty and the End date and time defining when the group member is no longer on duty based on the extra duty schedule.
OverrideSchedulePriority
You can take special treatment of high-priority messages a step further using OverrideSchedulePriority in a destination, a group, or a [User] definition. When a messages priority meets or exceeds this threshold, TelAlert will send it, completely disregarding all questions of schedule. Simply add the OverrideSchedulePriority setting, where appropriate in the Advanced tab of the TelAlert 6e Web UI. For example:
To use this feature, send a message with a Priority that is equal to or greater than the OverrideSchedulePriority setting. For example:
13
Representing Users
13.1 Overview
Instructions for creating [User] definitions and using them to link values to destinations, determine TelAlert dial-in/dial-out access behavior, and perform administrative tasks.
13.2
Getting Started
13.3
User Roles
TelAlert 6e customers have requested the ability to modify existing roles and create new ones. Role Management will associate roles and permissions and provide better management of Users' permissions.
13.3.2 Definitions
Roles A role is a label applied to a set of permissions that may be given to a user. Permissions Each permission has 4 elements: Create, Read/Run, Update and Delete.
Predefined roles These are roles that are predetermined and included with the original setup. TelAlert 6e will have 4 predefined roles: System Administrator, Administrator, Supervisor and Staff. System Administrator A predefined role, a System Administrator can view, create, update and delete all users, devices, groups, departments and schedules in the system. They may run all reports. There is only one System Administrator per installation. The System Administrator may not be deleted or edited. The System Administrator is automatically assigned to all Departments. Administrator A predefined role, an Administrator can view, create, update and delete departments, all devices, groups, and schedules within their department and all users except the System Administrator. They may run all reports within their departments. Supervisor A predefined role, a Supervisor can view, create, update and delete all devices, groups and schedules within their department and all users except Administrators and the System Administrator. They may run all department reports. Staff A predefined role, Staff level users have access to basic profile, device and messaging features. They also possess the ability to subscribe to groups, view groups they are a member of and view their own schedules. They can create and maintain their own devices and assign device schedules.
Navigation Edit Role Page The Edit Role page allows administrators to define custom user roles for TelAlert 6e. It contains a set of tabs with checkboxes for the various permissions to match the tabs users see in the Web UI. All permissions that the user does not have are unchecked and unavailable (grayed out). To get an idea how the roles are set up, it may be a good idea to look at some of the Roles already defined in TelAlert6e. This will help you define your own roles and permissions. Lets take a look at the default Supervisor role. Click on the notepad icon located to the left of the Supervisor role, you should see this screen:
On the Alerts Tab you see the permissions given to Send Alerts, View ALL Users Sent or Received Alerts, Respond To Alerts and create Alert Templates, Edit Alert Templates or Delete Alert Templates. If you remove any of the permissions on this default role, you affect all of the Users that have been given this role of Supervisor. In this case, it would be better to create another Supervisor role, give it a different name, and assign that role to the Users you want to limit some Supervisor capabilitities.
Next, click on the Edit Role Details Users Tab, you should see this screen:
This screen shows the capabilities this role has pertaining to User records. They can edit their own User record and change their own Devices. They also have permissions to Create, Edit, and Delete User records as well as Create, Edit, and Delete ALL User Devices. Next click on the Edit Role Details Groups Tab, you should see this screen:
This screen shows the capabilities this role has pertaining to Group records. They can Create, Edit , and Delete Groups as well as Group Subscriptions. They can also Edit Group Advanced Parameters.
Next click on the Edit Role Details Schedules Tab, you should see this screen:
This screen shows the capabilities this role has pertaining to Schedules. They can Create, Edit, and Delete all of their schedules as well as schedules for ALL Users, Group Schedules, and Global Schedules. Next click on the Edit Role Details Reports Tab, you should see this screen:
This screen shows the capabilities this role has pertaining to Reports. They can run the Department Metrics report as well as the Department Group Traffic report.
Next click on the Edit Role Details Admin Tools Tab, you should see this screen:
This screen shows that the Supervisor Role does not have permissions t o access anything on the Admin Tab except the System Configuration permission. Remember, this is the Default permissions for the Supervisor Role. Changing anything here will affect anyone who currently has the Supervisor role. Now that you have seen how the Default permissions are configured, you should have a good idea how to set up your own custom Roles and Permissions.
Adding your own Custom role: When you entered the Role Management page from the Admin Tab you are given the option to Create a new role. Click on the Add A New Role button. You should see this screen:
Just enter the name you want to call this new role in the Role Name field, then select the permissions you want to give this new role. You can move through all of the Tabs to select your options, then click Save to create your new Role. Keep in mind that if you Select Create it will also give them Edit capability.
TIP: You can take an existing Role and Save As New to help you copy a role and modify as necessary. For Example,if you click on one of the roles already created and modify it , then type in a different name, the Save As New button appears. You can then save it as your new role and modify accordingly. See screenshot below:
After you have Saved your new role, you will want to assign it the User or Users you created it for. Keep in mind that they will have to log off and back on for the new permissions to take effect.
13.4
Managing Users
Both supervisors and administrators can manage users. They can add users to the system and view, edit and delete users within their departments. They can also manage user information to control how alerts are delivered and escalated. Examples of this user information are as follows: What department or departments does the user belong to? What is the users role--staff, supervisor, or administrator? What is the users schedule and time zone? Can alerts be sent to the user, or can alerts only be sent to a single device that is shared among several users? Is an access key needed to send an alert to the user? What optional information about the user is inherited by devices associated with the user and what information is not inherited? Before adding users in TelAlert 6e, you should consider these and other questions. Note: When the system contains large numbers of users, the users can be filtered by department using the By Department: drop-down menu and Search field in the Filter Results section at the top of the Manage Users page. Administrators can add new users to the system by importing user data through the batch import process or by adding them manually (one at a time). Supervisors can only add users manually. This section describes how to add new users manually. To add new users by importing data using batch import, see Importing Data.
2.
On the Manage Users page, click the Add a New User button.
3.
Complete the required fields, and then click Save . For help completing the fields, see Table E, Click on the Return to the users List link to return to the Manage Users page.
4.
After adding the user you will see a confirmation page. From this page you can: Verify the user information is correct in the User Details section at the top of the page. Click the Edit this user link to edit the user details or add advanced parameters for the user. Click the Add another user link when adding multiple users. Click the Add a device to this user link to add information about how the user would like to receive notifications. Click on the Return to the users List link to return to the Manage Users page.
Field Active
Description If a user is active, there are no restrictions to their ability to receive alerts. If the user is inactive, the following restrictions apply: The user cannot receive alerts. The user can be added to a group, but the user will not receive alerts sent to that group. The users devices can be added to a group, but the users devices will not receive alerts sent to that group. Any user can change their Active status at anytime using the My Account link on the Home page.
Advanced Parameters
These parameters, such as AcknowledgeWait, are TelAlert keywords. For descriptions of these keywords, see the TelAlert TelAlert 6e Keyword and Command Reference. Note: The advanced parameters can be accessed by clicking on the Advanced tab when editing a user. Advanced fields are not accessible until after a user has been saved.
Access Key
If an access key is entered, the access key will be needed to send an alert to this user or any device owned by this user. Note: This field is found on the Advanced Settings page.
If you set this to No, this user will not appear in the available recipients list on the Send a New Alert page. Note: Inactivating the user will override the Display User on Recipients Page selection and the user will not display on the recipients page.
When a user is active, the user and their devices can receive alerts. For details, see Table E, Click on the Return to the users List link to return to the Manage Users page. To make a user active or inactive, do the following: 1. Click the User tab. The Manage Users page appears.
2.
Click the icon next to the user record in the Manage Users list.
3. 4.
On the Edit User page, modify the Active field. Click the Save button.
To modify an existing users information, do the following: 1. 2. Click the User tab. The Manage Users page appears. Click the Edit User icon next to the user record in the Manage Users list. The Edit User Details page appears. Edit the necessary fields, and then click. For help completing the fields, see Table 18: User Fields. Note: Changing a users departments will affect which users, devices and groups the user can view. It may also affect the ability of other users to access or view the edited users information.
3.
User 1 Details
User 1 belongs to Department A. User 1 can see all users, devices and groups that belong to Department A. User 1 is a member of Group Y. User 1 can see Group Y as well as all users, devices and groups that are members of Group Y. Since User 2 belongs to Department A, User 1 can see User 2, and all devices owned by User 2. User 1 is not able to see User 3 and Group Z since they do not belong to Department A. Department Field Edited User 1 is removed from Department A and added to Department B.
13.5
It common to set all passwords to be encrypted before being written to the by setting EncryptPasswords=True.
Password is Required An active [User] definition must contain a password setting. TelAdmin will not allow you to save a [User] definition without a password. If you create a [User] definition in which both the name and password would be indistinguishable from those in another [User] definition when entered using a touchtone telephone keypad, TelAlert will issue a warning.
13.6.4 Maximum of the [User] Value, the [Destinations] Default, and the [Configurations] Value
For these keywords, the value set in the [User] definition applies to the destination only if it is more than both the default value assigned to all destinations and the value assigned (directly or by default) to the [Configurations] definition to which the destination points: Priority AcknowledgeWait ReleaseWait
13.7
Many settings that can appear in a [User] definition govern how TelAlert behaves when a person identifies himself or herself as that user after either dialing in to TelAlert or being telephoned by TelAlert.
DialInMenuAccess and, for instance, determine whether TelAlert offers the user a designated voice menu of choices when the user dials in or is called. If either is set to True, you use the Menu setting to designate the (script-based) voice menu for TelAlert to play; you could set up a unique menu for every user, or a certain set of users could all be played the same menu. Consider this example: [User] ... {Rachel} Password=12345 DialInMenuAccess=True DialOutMenuAccess=True
214 | TelAlert 6e Administrator Guide - Version 6.1.29
Menu=StandardVoice
These settings have very little to do with the destinations associated with {Rachel}. The one connection is a general one: Rachel will be able to use TelAlerts dial-in and dial-out capabilities to access only those messages sent to destinations with which she is associated as user. However, neither the fact that she has dial-in/dial-out access nor the Menu setting affects TelAlerts processing of the messages sent to these destinations. In this sense, these settings are distinct from those discussed under Values for Inheritance by Associated Destinations, located earlier in this chapter. Below is a list of the keywords that can be assigned values in a control TelAlerts dial-in/dial-out behavior for that user: Active DialInMaxMessages DialInMenuAccess DialOutMaxMessages DialOutMenuAccess Menu ModemDialbackAreaCode ModemDialbackConfiguration ModemDialbackNumber Password VoiceDialbackAreaCode VoiceDialbackConfiguration VoiceDialbackNumber
13.8
If your destinations are associated with [User] definitions, you can administer messages sent to those destinations in terms of the [User] definitions with which they are associated. This may be helpful because a [User] definition may be associated with more than one destination; it may be convenient for you to work with all the messages relating to a person instead of having to proceed destination by destination.
2.
3.
For instance, you could set up a [Filter] definition such that specifying a certain tag with the command causes all [User] definitions pointing to that [Filter] definition to be displayed. Having done this, you would issue a command like this to see a list of those [User] definitions:
14
Representing Devices
14.1 Overview
The [Destination] section in TelAdmin translates to the Device tab in the TelAlert Web UI.
14.2
Before you can receive an alert, you must be the owner of a device. The types of devices you can use might include an e-mail account, a pager, a cell phone, and others. Your administrator can tell you which types of devices he or she has created and activated for your organization. These types will display in the Type/Configuration drop-down menu on the Add a New Device page. You do not need to add a device if it has already been added for you by your supervisor or administrator. However, if a device has been added for you, you might want to confirm that the device is configured correctly. You may also want to assign a device schedule so that alerts are only sent to the device during certain time periods. To find out if you have any devices, click the tab to view the My Devices portlet. If a device has been added for you, it will be listed on the Home page. Devices that you own are also listed on the Devices Page found by clicking the Devices tab. Supervisors and Administrators see all devices owned by users in their department. Staff users see only their own devices. To confirm that a device is configured correctly for you, click the icon next to the device name. You can also edit and delete your devices from the My Devices portlet on the Home page.
2.
Click the Add a New Device button. The Add a New Device page displays.
3.
In the device Name field, enter a name for the device. The name should be unique so that when it is displayed along with other devices in a group, it is self-documenting. The device name can be up to 20 characters long. Assign the device an owner by selecting one of the users listed in the Owner drop-down menu. The owner should be you if you would like the device to be associated to your user record. Meaning that when you are listed as an alert recipient (Your name added verses your device) the alert will automatically be sent to this device without the device being added to the alert recipient list. Users can own many devices, but each device can have only one owner. If a device is to be shared between multiple people, choose one of the users as the owner of the device. When sending alerts to this device add the device as an alert recipient instead of a particular user. Select a Type/Configuration. If the desired device type does not display in the Type/Configuration drop-down menu, an administrator needs to create it or activate it if it already exists in the system.
4.
5.
6.
Administrators can create new configurations and activate existing configurations using the TelAdmin tool in TelAlert Desktop. Use the Manage Configurations page under the Admin Tools tab to view and reload all active configurations. Configurations must be reloaded any time a new configuration is added or an exiting configurations Active/Inactive status has changed. To reload active configurations select the Reload button on the Manage Configurations page under Admin Tools.
It is recommended to select the Reload button on the Manage Configuration page every time a change is made to configurations in TelAlert Desktop. After you select a Device/Type Configuration, additional fields customized for the device type appear. 7. Complete the configuration specific fields that appear as soon as a selection is made in the Type/Configuration drop-down menu (i.e. An email device has a To field and a text pager has a PIN field). Click the Save button After adding a device you will see a confirmation page. Verify the device details. From this page you can click on one of the links in the Next Step section to proceed forward.
8. 9.
10. To define additional device parameters, select the Edit this device link and click on the tab.
11. Note: If you are a staff user and do not see the Advanced tab, your administrator has turned off this feature. See Table 14. Advanced options in the devices form for additional information. 12. Make the necessary changes in the Edit Device Advanced Settings form, and then click the Save button. Field Input/Select
Name
In the Name field, enter a name for the device. The name should be unique so that when it is displayed along with other devices in a group, it is selfdocumenting. The device name can be up to 20 characters long. Select the owner of this device. This drop-down menu will only allow you to assign an owner that is a member of your department. This drop-down menu displays all the device types that your administrator has made available to you. If you do not see the type of device you are trying to add, ask your administrator to have your device type enabled. To see a list of active configurations see the Manage Configurations page under the Admin Tools tab. Enter a brief description of the device. Make sure the comments document the device. The comment character count displays the number of characters you have typed in. You cannot exceed 100 characters.
Owner
Comments/Description
Field
Input/Select
To
Enter the SMTP e-mail address of the device (mailbox). The email address must be valid or an error message will be This is the e-mail address to which replies will be sent. This may be left blank. This is used only when the reply address is different from the sending address. This is the default subject when sending messages to this device. This may be left blank. Note: This text will be overwritten if text is entered in the subject field in the Advanced section on the Send a New Alert page.
ReplyTo
Subject
Field
Input/Select
PIN
Enter the 10-digit phone number of the device. You may enter hyphens and dashes.
Table 11. Text pager, interactive text pager, and GSM modem options in the Devices form
Field
Input/Select
PIN
Enter the pin number for the pager. The pin number can be up to 50 characters.
Field
Input/Select
Enter the area code up to 6 digits. Enter the phone number of the device. You may enter hyphens and dashes.
Field
Input/Select
Display Device on This is used to hide the device when manually sending alerts. The device will still be visible to external systems. Recipients Page
Access Key
When an access key is defined for a device, that access key must be input to send an alert to that device. However, if the alert is sent to the device because the owner is selected as a recipient or the device is contained in a group, the user access key or group access key, respectively, is required instead.
2.
In the list of devices, click the Edit Device icon to the left of the device name.
3.
Modify the fields you wish to edit, and use the Advanced tab to access additional fields if necessary. On the Edit Device page the Name field is not editable. The Device Type/Configuration field will only contain active configurations that are of the same Device Type as the device being edited. Note: If you do not see the Advanced tab and you are a staff member, your administrator has turned off this feature. See Tables 9 - 13 for more information about the most common fields used for various devices. For details on any fields not listed in Tables 9 - 13, see the TelAlert 6e Keyword and Command Reference.
4.
Click Save.
14.3
Devices can be assigned schedules so that they are only available to receive alerts during specified periods when they are considered on duty. Users can create and assign schedules for their own devices. Supervisors and Administrators can create and assign device schedules for all devices owned by users in their department. Defining device suchedules is optional. If you do not assign a device schedule, the systems default setting of 24x7, always on duty applies.
Figure 30. Edit Device Schedule page allows user to assign a default device schedule.
Device schedules tell TelAlert whether a device is on duty at the time an alert is sent. Setting up schedules for devices rather than for people might seem counterintuitive. However, setting up schedules for devices makes it possible to send alerts to a particular device--Johns phone-during certain hours and to a different device--Johns pager--during other hours. To assign a device schedule, do the following: 4. Click the Devices tab. The Manage Devices page displays.
5.
Choose the device from the list by clicking the to the left of the devices name.
6.
The default schedule for new devices is 24x7, indicating that the device is available to receive alerts at any time.
7.
To assign a device schedule, select the desired schedule from the Default Schedule drop-down menu. Select the date the schedule should go into affect in the Start Date field followed by the Save button.
Note: Device schedules are listed below global schedules in the Default Schedule drop-down menu under the User Defined Schedules heading. Device schedules are considered User Defined because they are linked to the owner of a device and are available to that user only for assignment to their devices. Other users in the system will not have the ability to assign another users device schedule to their own devices. If you would like a schedule to be available to more than one user, create a global schedule instead of a device schedule. The global schedule will appear in the Default Schedule drop-down menu under the Global Schedule heading and will be available for use by all users in your department. 8. When the device schedule has been assigned you will see a confirmation page indicating the device details (in this case the schedule) have been updated successfully.
3.
In the Description field, enter a brief description of the device schedule. This is optional, but very useful when managing many schedules. Indicate the Repeat Pattern and On Duty Hours Pattern and select the Next button. Enter the times and days of the week that the device will be on duty and available to receive alerts.
4. 5.
Note: A device with the 9 to 5 device schedule will NOT receive alerts sent on Monday at 8:59. The device will receive alerts sent on Monday at 9:00. Additionally, they will NOT receive alerts sent on Monday at 17:01. 6. Select the Save button.
The device schedule is now available to assign to the selected device and any additional devices owned by the same user on the Edit Device Details page. 7. To assign this or other device schedules to a device see Assigning Device Schedules at the top of this section.
Removing a users last device removes them from all groups since users must have an active device to belong to a group. This feature is intended to prevent alerts being sent to empty groups. 3. In the confirmation window, c l ic k O K to delete the device, or click Cancel if you do not want to delete the device.
15
Enabling Responses
15.1 Overview
Yhis chapter contains instructions for making it possible for message recipients to respond to notifications sent by TelAlert. This chapter focuses on two-way pager destinations but explains how responses can be appended to messages sent to other types of destinations as well.
15.2
Getting Started
15.3
TelAlert ships with two sets of pre-defined responses under you to refer to on the command line. For example:
[Response] ... {Basic} NumReplies=6 Acked=1 AckedHold=3,4,6 NotAcked=2 Released=5 Reply1=Yes Reply2=No Reply3=Hold Reply4=Info Reply5=Release Reply6=Ping
Here, Reply4 is intended to offer a means by which the user can send additional info (this requires the use of a script invoked using a [Notifications] definition). Reply6 is intended to allow the user to run a script that pings a node and reports the result to the user (this, too, requires the use of a script invoked using a [Notifications] definition). You can invoke this set of responses when sending a message to a two-way text pager:
15.4
It is a simple matter to modify the pre-defined [Response] definitions or create new ones of your own. For instance, you might want to make the previously cited set of responses even more basic by removing Infoand Ping, so that there is a simple, one-to-one correspondence between menu items and TelAlert commands. Or you might want to include additional response options that map to Acked, AckedHold, NotAcked, or Released, so that these responses carry out the corresponding action within TelAlert while providing more detailed information. For example:
[Response] ... {Detailed} NumReplies=8 Acked=1,2 AckedHold=5,6 NotAcked=3,4 Released=7,8 Reply1=Yes<1Hour #Reply1 means yes, in less than one hour Reply2=Yes>1Hour #Reply2 means yes, in more than one hour Reply3=NoBusy #Reply3 means "no, I am busy"
Chapter 15: Enabling Responses | 229
Reply4=NoOffDuty #Reply4 means "no, I am off duty" Reply5=HoldWillHandle #Reply5 means "hold, I will handle it" Reply6=HoldWillDelegate #Reply6 means "hold, I will assign this to someone else" Reply7=ReleaseFixed #Reply7 means "release, this is fixed" Reply8=ReleaseNotFixed #Reply8 means "release, but this is not fixed"
Here, two responses map to each command, allowing the respondent to positively acknowledge the message in two ways, negatively acknowledge the message in two ways, and so on. (The intended meaning of each response is explained in a comment line.) The text of the response will be available in the telalert.trail file. You can take greater advantage of this sort of response-related information using TelAlerts [Notifications] feature. For more information, refer to Responses and the [Notifications] Feature below. Once you have the desired set of responses in place, you can send pages by invoking the destination in a command such as this:
15.5
Because invocation of a set of responses is handled more or less seamlessly in sends to two-way pager destinations (i.e., the responses are presented straightforwardly as a menu of choices, without additional effort on your part), the only detail unique to two-way pagers with which you need to concern yourself is polling. Polling is the means by which TelAlert checks for responses to two-way pages it has sent. TelAlert knows to poll for responses whenever it sends a page that meets three conditions:
The page must use a [Configurations] definition (or a destination) in which defined as InteractiveTextPager.
Type is
The command generating the alert must specify an ackwait value (or an AcknowledgeWait value must be in effect via some other mechanism). The command generating the alert must specify a set of responses.
In addition, the message must still be active: it must be in either an ackwait or ackheld state. Otherwise, from TelAlerts point of view, the message no longer exists and there is no reason for TelAlert to poll for a response. When it polls, TelAlert uses the same [Configurations] definition that it used to send the original page. If you send a two-way page via the Internet, TelAlert attempts to retrieve a response by the same medium. If DialBackup is specified and TelAlert encounters the specified number of connect errors in attempting to poll, it will use the DialBackup information to poll by dial-up.
The only aspect of polling that it is possible to control is the frequency with which TelAlert dials in to check for responses. You can do this by changing the CheckITPRepliesInterval setting under [Limits]. The default is 5m. This must be set to a value lower than your -ackwait value if TelAlert is to have a chance to check for a response before the message expires. In the case of Internet-based two-way paging, a frequent polling interval is less likely to interfere with sending pages than in the case of dial-up, since Internet-based polling ties up the port for only a few seconds each time.
15.6
Response functionality can be significantly expanded using [Notifications] definitions, which allow you to pass designated responses to a log file or another application. Thus, you can enable a response that will update a trouble ticket in a controlling application with which you have integrated TelAlert; likewise, you can enable a response that, by triggering a script, will carry out a diagnostic or administrative operation. As mentioned above, one of the pre-defined sets of responses provided in the TelAlert configuration file includes two responses designed to work in conjunction with a script,Reply4
and Reply6: [Response] ... {Basic} NumReplies=6 Acked=1 AckedHold=3,4,6 NotAcked=2 Released=5 Reply1=Yes Reply2=No Reply3=Hold Reply4=Info Reply5=Release Reply6=Ping
You invoke such a script by referring to it in a [Notifications] definition associated with the [Destinations] definition to which the original message was sent. For example, this command
telalertc -i DavidTwoWayInternetPager -m "this is a test" -response Basic -ackwait 15m -remark 192.168.168.1
refers to a
[Destinations] definition
[Destinations]
...
[Notifications]
...
Passing a NotificationReply Value on the Command Line You can invoke the [Configurations] definition and specify destination-related information on the command line, like so:
telalertc -c SkyTelInetTwoWayTextPagerSP -pin 3456789 -m "test" -response Detailed -ackwait 15m -notificationreply BasicReply.
16
Broadcasting to Groups and Creating Escalations
16.1 Overview
Instructions for sending notifications to more than one destination using your own [Group] definitions. This chapter covers both broadcast group notifications, in which the message goes simultaneously to all members of the group, and escalations, in which TelAlert directs the message to one or more destinations in sequence, according to specified rules.
16.2
Getting Started
2.
Click the Edit Device button. The Add a New Group page appears.
3.
If you want to allow alerts to be sent to the group, in the Active field select Yes. Otherwise, select No. Selecting No removes the group from the Recipients list on the Add Recipients page. In the Name field, enter a name for the group. The group name cannot exceed 20 characters and cannot include special characters. In the Comments/Description text box, enter a brief description of the group (by function, department, or other logical component of your organization). In the Public section, select Yes if you want to allow users to be able to add and remove themselves from the group. Select the department or departments that you would like your group to belong to. To select more than one department click on one of the departments, hold down the ctr key while clicking on additional departments.
4.
5.
6.
7.
Note: The departments selected will determine which users, devices and groups will be available later to add as members of the group. The Add Group Members list will only contain users and the devices that belong to those users and groups that belong to same department as the new group. 8. Click the Save button.
The new group is added to the system. However, the group will not become available to receive alerts until at least one member has been added. See Adding Group Members.
2.
Click the Edit Group icon next to the device record in the Manage Groups list. The Edit Group page appears
3. 4.
3.
2.
Choose the group you want to manage by clicking the Edit Group icon next to its name in the list.
3.
Select the Members tab. This shows the current group member list.
4.
Select the Add to Group button. This brings up the Add User Members window.
5.
You can add users, devices or groups by selecting between these terms in the View By: dropdown menu. The Add Members window displays the first ten of all eligible devices, users or groups. Select the entries you want to add to the group by selecting the checkbox next to each recipient.
6. 7.
Note: You can add a member to a group more than once. If you do, the system will send the alert to that target as many times as it appears in the group (or until someone acknowledges the message). 7. Select the Add Selected button to save the selected recipients on the current page. When you have selected all desired recipients click on the Finished button to close the window and return you to the Edit Group Members page.
8.
16.3
The purpose of group member schedules is to override the default device schedule of a group member. The group member schedule will only be applied when alerts are sent to the group. They do not influence alerts sent to other groups or to the device or user directly. Group member schedules indicate when members are on duty or off duty when alerts are sent to the group. When the member is on duty they will be sent an alert when alerts are sent to the group. Group members can be users, devices or groups (subgroups). If the group member is a user, alerts will be sent to all of their on duty devices when alerts are sent to the group. (See Assigning Device Schedules for information about device schedules.) If the group member is a device, alerts will be sent to that device if it is on duty when the alert is sent to the group. If the group member is a Group (subgroup), all of the on duty members of the subgroup will be sent alerts when an alert is sent to the group. Note: Device schedules and escalation schedules can affect whether or not or in which order members of a group will be sent alerts.
3.
4.
In the calendar, click the name of the group member that you would like to assign a schedule.
5.
In the Regular Schedule section, the radio button will default to Use the Default Schedule. For device group members, the default schedule is referring to the schedule that has been assigned to the device in the device section. If no schedule has been assigned to the device a 24x7 schedule applies. When the group member is a user, the default schedule is the compilation of all of the users device schedules. To see the group members default schedule, select the Override the Default Schedule radio button. The name of the default schedule will appear in the Schedule drop-down menu.
6.
The Schedule drop-down list contains all global schedules, group schedules created for this group and device schedules associated with the particular group member. The device schedules are listed as User Specific Schedules since they are associated with a user for assignment to any of their devices. Use the Schedule drop-down menu to select the desired schedule. You can select a global, group or user specific (device) schedule. Global schedules are schedules that are available to all groups. Group schedules are schedules that are available to the group selected in the Group drop-down menu when the schedule was created.
7.
8.
In the Regular Schedule section, enter a schedule Start Date. This date should be todays date or a prior date. If a future date is entered, the system will retroactively adjust the start date to a date in the current week. The schedule will adhere to the date, in that the schedule cycle will begin at the specified start date and you will see a message informing you that the schedule date has been adjusted on the confirmation page. The group member will also be on duty for the number of schedule cycles required to backtrack to todays date. If you want to create a schedule that will not go into effect until a future date, the best method is to change the groups status or the group members status to inactive (dont forget to change it back to active later). If you change the groups status to inactive, group members who are active can still receive alerts that are sent to them or their device directly or using other users or groups.
Note: Since Weekly schedules start on a Sunday, the date you enter will be changed to the prior Sunday if necessary. If the schedules repeat pattern is "every X days", the date you enter as the schedule start date will not be changed. 9. Click the Save Regular Schedule button.
10. To override all or a portion of a vacation or holiday schedule, use the Extra Duty Schedule section to define additional on duty hours. A group member schedule must be applied before adding Extra Duty.
11. The Extra Duty Schedule section does not appear the first time a group member schedule is viewed or before a group member schedule has been applied. If you do not see the Extra Duty Schedule section, an override schedule must be applied. Select the Override the default schedule radio button followed by the Save Regular Schedule button. The Extra Duty Section is now visible. The Extra Duty Schedule section does not appear the first time a group member schedule is viewed or before a group member schedule has been applied. If you do not see the Extra Duty Schedule section, an override schedule must be applied.
12. Enter a Start and End date. If the extra duty schedule is a single day enter that date in the Start and End fields and select the All Day checkbox. 13. Click the Save Extra Duty Schedule button. 14. To define an Acknowledge Wait time for the group member, enter a time (in minutes) in the Acknowledge Wait section. This setting will determine how long the alert will remain active when sent to this group member. 15. Acknowledge Wait is specified on the Group Advanced page or if an Acknowledge Wait is defined on the Send Alert page when the alert is sent, this value will not apply.
3. 4.
7. 8.
16.4
Group Basics
16.5
Broadcast Notification
The simplest use of groups is to send a message to multiple destinations all at the same time. For example:
-g "group_name"
If you use the -l syntax, you are essentially creating, on-the-fly, a one-time-use "supergroup". (If you are logging, you can assign a name to this one-time-use group with the -name parameter.) Regardless of whether you use -name, if you want this one-time-use group to use a strategy, you must specify the -strategy parameter on the command line; if escalation is involved, you will need to specify -ackwait; if you are doing two-way paging, you may want to specify the -response parameter; etc. In other words, when you use -l, you must use additional parameters on the command line to fully define the one-time-use group you are creating on-the-fly.
16.6
Escalation
Escalation is useful when you must be sure that at least one member of a group receives and acknowledges a message, but you want to avoid, if possible, sending it to all members of the group. Escalation Strategy Sequential
Description In this strategy, the alert is escalated sequentially until at least one member acknowledges. The Ack Wait period defined for each group member (see Adding Users) determines how long TelAlert waits before sending the alert to the next group member. In this strategy, the alert is always sent to the group members sequentially, however it will be sent initially to the next member in the list each time a new alert is sent. When each group member has been the first to receive an alert, the process starts again--the next alert is sent to the first group member, the one after that is sent to the second member first, and the third alert is sent to the third group member first. Here is an example for a group with three members: The first alert is sent to member 1, then escalates sequentially to member 2 and then to member 3. The next alert is sent to member 2 first, then to member 3, and then member 1. In this strategy, the alert is sent to every member of the group simultaneously.
Broadcast
[Group] ... {Support} Destinations=DavidTextPager,RachelTextPager,CynthiaTextPager, JohnTextPager Strategy=FirstAcknowledge [Strategy] ... {FirstAcknowledge} Complete=Acked>0 Escalate=Incomplete=0
The send is treated as an escalation because the group contains an Escalate value.
Complete specifies the conditions under which TelAlert will consider the alert complete. Here, Complete=Acked>0 means that a send in which this strategy is invoked will be considered complete when at least one person has positively acknowledged it (i.e., when the number of messages acked is greater then zero).
If the Complete criterion is met, TelAlert ends the escalation.
Escalate specifies the conditions under which TelAlert will escalate the alert, assuming the Complete criterion has not yet been met. In this example, Escalate=Incomplete=0 means that TelAlert will send the message to the next destination when the current send ceases to be in an incomplete state (i.e., when the number of sends in an incomplete state equals zero). TelAlert treats escalation differently when the group is comprised of subgroups. For more information, refer to Escalations Involving Subgroups later in this chapter.
ackwait The key to escalation is the -ackwait numberm/h parameter used at the command lineor, alternatively, the AcknowledgeWait=numberm/h line that can be used in defining a group or destination. These entries tell TelAlert how long to wait but before doing what? If there is a [Strategy] definition for TelAlert to refer to, it sends to the first destination and waits this amount of time before following its escalation procedure. If there is no [Strategy] definition, it sends to all destinations and waits this amount of time before releasing the alert. Without the -ackwait parameter or AcknowledgeWait= line, any escalation procedure specified in a [Strategy] definition becomes meaningless, since TelAlert will not know how long to wait before escalating the alert. In such cases, TelAlert sends to all destinations at once. -ackwait at the command line overrides an AcknowledgeWait value in telalert.ini. TelAlert ignores any AcknowledgeWait value given as part of a [Destinations] definition when that definition is invoked as part of a group.
Completeand Escalate values can be set using relational operators, logical operators, keywords
representing TelAlert send states, and numerical values representing percentages of the total number of sends. (An additional keyword is used to refer to how much time has elapsed since the alert began.) For instance
Complete=(Sent=100)|(Acked>=50)
means that the alert will be considered complete when the message has been sent to 100% of the valid destinations, or when 50% of these destinations have acknowledged the message. The supported logical operators are: & AND | OR ^ exclusive OR ! NOT
The supported relational operators are: = equal to > greater than >= greater than or equal to < less than <= less than or equal to <> not equal to
Send states that can be referred to in [Strategy] definitions are as follows. (The numerical values assigned to these keywords always represent the percentage of the total number of sends that are in this state.)
Ackedsends that have been successfully sent and acknowledged by the receiver NotAckedsends that have been negatively acknowledged Sentsends that have been successfully sent to their destination Failedsends that could not be successfully sent to their destination and for which the
maximum number of attempts have been made (as determined by the MaxFailCalls value for that configuration)
Clearedsends that have been cleared using the -clear option on the command line Incompletesends that are still in progress. A send is incomplete if TelAlert has not yet
made an attempt to send to a destination, or if TelAlert is trying to send the message but has not yet succeeded
OffDutysends that will never be sent because the destination is not currently on-duty
There is one other keyword that can be used in setting a Complete or numerical value assigned to it represents a number of minutes.)
Timethe number of minutes since TelAlert began issuing sends to the current
destination or subgroup.
Typical
Escalate Value
[Group] ... {Support} Destinations=Subgroup1,Subgroup2,Subgroup3 Strategy=FirstAcknowledge {Subgroup1} Destinations=Pager1,Pager2,Pager3 {Subgroup2} Destinations=Pager4,Pager5,Pager6 {Subgroup3} Destinations=Pager7,Pager8,Pager9
Here, a message directed to
{Support}, like so
SubgroupEscalation
The way TelAlert processes an escalated send to a group comprised of subgroups is changed significantly by the use of the SubgroupEscalation keyword. TelAlert treats any group containing a subgroup in which SubgroupEscalation is set to True as if the subgroups destinations were included directly in the supergroup. For instance, a group containing this
Destinations setting
Destinations=SG1,SG2,SG3
Destinations setting
Destinations=Dest1,Dest2,Dest3,SG2,SG3
as long as the first of the subgroups ({SG1}) had
SubgroupEscalation=True are carried out one by one, as a part of the escalation process, not
as a broadcast. Consider this example:
[Group] ... {SupportGroup} Destinations=Group1,Group2,Group3 Strategy=FirstAcknowledge {Group1} Destinations=Pager1,Pager2,Pager3 SubgroupEscalation=True {Group2} Destinations=Pager4,Pager5,Pager6 {Group3} Destinations=Pager7,Pager8,Pager9 SubgroupEscalation is set to Truein {Group1}, a message directed to {SupportGroup} would be handled as follows:
Because TelAlert sends the message to
Pager1.
If this recipient does not acknowledge the message within ten minutes, TelAlert sends the message to Pager2. If this recipient does not acknowledge the message within ten minutes, TelAlert sends the message to Pager3. If this recipient does not acknowledge the message within ten minutes, TelAlert sends the message to Pager4, Pager5, and Pager6, all at once. If none of these recipients acknowledges the message within ten minutes, TelAlert sends the message to Pager7, Pager8, and Pager9, all at once. If none of these recipients acknowledges the message within ten minutes, the alert is marked as "finished" but not as "complete," since the Complete criterion was not met.
Under what circumstances would you want to use SubgroupEscalation? Assume that you have three groups of support technicians. Any member of any of the groups is qualified to handle a node down message, but it is most appropriate to assign a member of one particular group whenever possible. This much is achieved simply by listing this most appropriate group first, since TelAlert sends to the destinations in the order in which they are listed. But perhaps you also want to avoid paging all the members of this first group each time a node down message is generated. By setting SubgroupEscalation to True in the definition of this group, you cause TelAlert to send the
message to these destinations one at a time. If none of these technicians responds during the allotted time, the message will be sent out to all members of the second subgroup (and, after that, to all members of the third subgroup). At this point, this may be precisely the behavior you want, since, thirty minutes into the alert, you may be more willing to page multiple destinations simultaneously to ensure a prompt response.
Subgroup
SubgroupEscalation=Truehas an effect only when the group functions as a subgroup that is, only when TelAlert computes the membership and escalation procedure for a group that lists this group as one of its Destinations values.
17
Processing Events
17.1 Overview
Instructions for setting up TelAlert to respond automatically to specified events by issuing commands to itself or other applications, sending SNMP traps, or writing to the operating systems log.
17.2
Getting Started
If you want to be notified when log file size limits are reached, you will need to know what log file(s) you are concerned about, the information you want to be passed, and the notification mechanism you want TelAlert to use.
17.3
A Word About Scripts You can configure TelAlert to execute a script (or a program) whenever any of the events described in this chapter occur. This means that TelAlerts event-handling capabilities are limited by only the work you are willing to invest to devise a script that does what you want.
([File] section):
Most logging-related functionality is covered in Chapter 17: Miscellaneous Administrative Tasks, but logging-related event handling (i.e., specifying what TelAlert does when size limits are reached) is covered here, in the present chapter, because of its close similarity to other eventhandling techniques.
17.4
Configuring TelAlert to process a particular event takes at least three steps, and usually four. Here is a brief overview of the process: 1. Select the type of event you want TelAlert to process by choosing one of the event keywords (AlertStarted, Acknowledged, Start, Error, and so on) and adding it to either the [Heartbeat] section (for process-related events), the [File] section (for logging-related events), or a [Notification] definition (for alert-related and miscellaneous events). Define what information you want TelAlert to pass with the command or SNMP trap, or to write to the log, in the event keyword value. Normally this string will include a number of substitution parameters (variables) that TelAlert will replace with information about the specific event. Event keywords and related substitution parameters are described in detail later in this chapter. 3. Define the action you want TelAlert to take by adding one of the following keywords to the same definition or section: Command: TelAlert will issue the specified command. Typically the command will include the ${EventData} replaceable parameter, for which TelAlert will substitute the event keyword value, with any replaceable parameters it contains expanded. See Issuing a Command, below, for detailed instructions on setting this and related keyword values. SNMPHosts: TelAlert will send an SNMP trap, which will include the expanded event keyword value and various other information, to the specified host. See Sending an SNMP Trap, below, for instructions on setting this keyword value and a discussion of what other information is passed to the host. WriteSysEventLog: When this keyword is set to True, TelAlert will write the event keyword value (with any replaceable parameters it contains expanded) to syslog(in UNIX) or the Application Event Log (in Windows). See Writing to the System Log, below, for instructions on setting this keyword value. The inclusion of the event keyword value in the command, SNMP trap, or log entry allows you to add multiple event keywords in a single definition or section (that is, to perform steps 1 and 2 above repeatedly, with different event keywords), and have each generate a different command, SNMP trap, or log entry. A fourth step is necessary for notification-related events only: 4.
2.
[Analog], [Battery], [Configuration], [Destinations], [Group], [Limits], [Port], [Power], [Relay], [Sensor], or [User] definition(s) you want to trigger the
Associate the [Notification] definition with the action by including a keyword value for Notification or one of the related keywords. Alternatively, you can invoke a [Notification] definition using the notification (or notificationreply or -notificationrequest) command line option.
NotificationReplyand NotificationRequest can be used only with [Configuration], [Destinations], [Group], and [User] definitions, and are issued only on reply and request events respectively. A [Notification] definition pointed to by one or both of these keywords should contain no event keywords other than Reply and Request.
17.5
Triggering Actions
As discussed above, in response to an event TelAlert can send an SNMP trap, write to the system log, or issue a command. This section provides detailed instructions on configuring each of the three types of actions, and on configuring TelAlert to perform multiple actions in response to a single event.
[Heartbeat]
...
Repeating Execution Attempts By default, the failure of a command specified using Command and/or Shell is considered a failure, and the intended action will not be carried out. You can change this behavior with the MaxAttempts and AttemptWait keywords.
MaxAttempts specifies the maximum number of times you want TelAlert to try to
execute the command. The default is 1; the maximum permitted value is 20.
AttemptWait specifies how many seconds you want TelAlert to wait following a failure
before trying again. The minimum value is 1; the maximum is 60. The default value is 5.
FIFOFileName: Assuming the program you are invoking in Shell and/or Command supports such behavior, FIFOFileName allows you to run this program once (at the events first occurrence) and write both initial and subsequent event data to a specified file that the program can then continuously read. The value you assign FIFOFileName is the name of the file from which you want your program to read. If you do assign it a value, you should make sure that ${FIFOFileName} appears at the point in your Command or Shell value where you want the name of the file to be passed to the program. WriteExecsToTrail: If you set this keyword to True, TelAlert will write the results of each attempted execution of the command to the telalert.trail file. This can be useful when debugging a command that does not work as expected.
Event Substitution Parameters Supported in Command and Shell Keyword Values
Shell and Command support a limited number of TelAlert substitution parameters. Most of these are used to point to various directories in which components of TelAlert are installed. Another is ${EventData}, which is especially important. Include this substitution parameter as part of either Shell or Command if TelAlert is to pass information from the event (as defined by the value assigned to the event keyword) to the specified program or script. Following is a complete list of substitutions supported in Shell and Command: ${Definition} The name of the telalert.ini definition in which the Command keyword appears. When Command appears at the section level, the section name is passed instead. ${EventData} The string formed based on the value assigned to the event keyword.
when the
${FIFOFileName} The name of the pipe that the program should read from (used only FIFOFileName keyword specifies the name of this pipe). c:\WINNT), or,
${SystemRoot} The directory in which Windows is installed (typically on UNIX, the root directory (/).
translated into forward slashes.
${SystemRootFS} The same as ${SystemRoot}, but with any backslash characters ${TelAlertBin} The value of the TelAlertBin environment variable. ${TelAlertBinFS}The same as ${TelAlertBin}, but with any backslash characters
translated into forward slashes.
${TelAlertCfg} The value of the TelAlertCfg environment variable. ${TelAlertCfgFS}The same as ${TelAlertCfg}, but with any backslash characters
translated into forward slashes.
${TelAlertDir} The value of the TelAlertDir environment variable. ${TelAlertDirFS} The same as ${TelAlertDir}, but with any backslash characters
translated into forward slashes.
${TelAlertTmp} The value of the TelAlertTmp environment variable. ${TelAlertTmpFS} The same as translated into forward slashes. ${TelAlertTmp}, but with any backslash characters
The SNMPHosts keyword value may contain multiple host names or IP addresses, separated by commas.
These methods are not mutually exclusive. You may use all of them to process the same event.
17.6
The event processing supported by the [Notification] section is by far TelAlerts most flexible and wide-ranging. You can use it to process replies received in response to TelAlert notifications, requests sent by two-way pagers capable of initiating sends, and environmental changes detected by a TelAlert Sensor Engine. You can also use it to process a broad spectrum of other events. To do this, you must first understand the general principles at work in TelAlerts event-processing capabilities, as explained in the previous sections. The following discusses the techniques specific to the [Notification] section and lists the events and substitution parameters it supports.
this data to a program capable of parsing it and reporting in real time on any failures exceeding the threshold permitted by the SLA.
Replies
Any TelAlert notification that invokes a [Response] definition can be replied to by the message recipient. Depending on the medium used to send the message, this reply can come via two-way pager, touch-tone telephone, email or the command line. If TelAlert receives a reply and the [Configuration] definition originally used to send the message points to a [Notification] entry containing the Reply event keyword, TelAlert processes the reply according to the terms of this [Notification] entry. Thus, a reply can be made to trigger a script or program, and the information contained in the reply can be passed to this script or program in order to have TelAlert execute an action desired by the person replying. It is best to configure reply events using the NotificationReply keyword (discussed in About Notification and Related Keywords, above). This approach leaves the Notification keyword free for other purposes. Note that some basic replies that can be specified in a [Response] definition (including ack, nak, etc.) can be processed directly by TelAlert, without any action being defined under [Notification]. Conversely, you can create other reply options that have nothing to do with TelAlertreplies designed only to trigger and be processed by the appropriate [Notification] definition.
Requests
Certain two-way paging services permit users to use their two-way paging devices to initiate a requesta message that is not a response to any received page. TelAlert polls for requests if PollRequests is set to True in a [Configuration] definition representing a paging service that supports requests. (Any [Configuration] definition in which PollRequests is set to True also requires ServerPIN and Access values. ServerPIN is the identifier that tells the service who is asking for the messages. Access is the security code or password associated with the account. For BSWD, ServerPIN is the DAS account Administrator. Note that BSWD requires ServerPIN and Access values for both regular two-way polling and unsolicited polling. SkyTel does not require them for regular two-way polling, but they will be used if you provide them.) To have TelAlert treat the retrieval of a request as an event, use the keyword NotificationRequest (discussed in About Notification and Related Keywords, above) to invoke a [Notification] definition. Thus, a request can trigger a script or program, and the information contained in the request can be passed to this script or program so that TelAlert executes an action desired by the person initiating the request. Consider this example of request processing:
MaxMessagesPerCall=100 Speed=19200 AreaCode=800 Number=679-2778 NotificationReply=ReplyAction NotificationRequest=RequestAction [Notification] ... {RequestAction} Active=True Shell="" Command=${TelAlertCfg}/Scripts/request.sh ${EventData} Request=${TimeStamp},Request,${RequestName},${Configuration}, ${PIN},${RequestID},"${Request}"
When TelAlert retrieves a request using this [Configuration] definition, the presence of the NotificationRequestvalue tells it to look to the invoked [Notification] definition (i.e., {RequestAction}) and process the retrieved message according to the terms laid out in there terms specified in the combination of Request, Command, and Shell. (Note that the [Configuration] definition points to another [Notification] definition using NotificationReply.) It may be that your two-way paging devices are capable of initiating requests using more than one application. If you want requests from different pager applications to result in different actions, you can set NotificationRequest to <RequestName> (literally, RequestName enclosed by angle brackets) and create [Notification] definitions with names matching the ${RequestName} value associated with each application. To use this feature, your pager applications must be set up so that each delivers a unique ${RequestName} value. Pager applications from Vytek Messaging Services, Inc. follow this convention. If, when using a [Configuration] definition in which NotificationRequest=<RequestName>, TelAlert retrieves a request with a ${RequestName} value that does not match any [Notification] definition, it generates an error. If the ${RequestName} value reduces to Requestbecause no vertical bar is present, TelAlert looks for a [Notification] definition called {Request}. You may want to set up a definition with this name for use in these situations.
[Notification] Section
When TelAlert detects one of these events, it takes the action you have prescribed according to the values assigned to Command, Shell, and the corresponding event keyword. Note that not all event keywords are meaningful for inclusion in every [Notification] definition. For example, Sensor makes no sense in a [Notification] definition that will be invoked by a [Configuration] definition, and AlertCompleted makes no sense in one that will be invoked by a [Sensor] definition. Providing a keyword that is not appropriate for a given entry does not generate an error; this keyword will simply not be used.
Alerts Versus Sends Some of the events and substitution parameters described below are related to alerts the comprehensive entities created within TelAlert when messages are directed to destinations, configurations, or groups. Others have to do with sends the smaller entities associated with the sending of a message to a single destination. When a message is directed to a single destination, both an alert and a send are created, and these are more or less identical. When a message is directed to a group comprised of three destinations, however, an alert and three sends are created. Here, the nature of a send as a subset of an alert is most clearly illustrated. There are also group send entities: subsets of alerts in which a message is directed to a group of destinations.
AlertDelayedThe event TelAlert recognizes when an alert is delayed by virtue of a -delay value on the command line. AlertStartedThe event TelAlert recognizes when an alert is started (i.e., when TelAlert receives the command to create the alert and begins processing it). AlertErrorThe event TelAlert recognizes when an error occurs in the processing of an alert owing to erroneous information being passed on the command line (typically, one or more invalid definition names). AlertNotSupportedThe event TelAlert recognizes when no destination involved in an
alert is supported by TelAlert (owing typically to the absence of appropriate resources for processing the sends).
AlertFilterThe event TelAlert recognizes when an alert cannot be processed because every specified destination is filtered according to the terms of a [Filter] definition. AlertClearedThe event TelAlert recognizes when an alert is cleared (i.e., when all remaining processing is stopped by a -clearalert, -cleargroup, -clearall, or -clear command). AlertCompletedThe event TelAlert recognizes when an alert completes by virtue of all
processing having been finished without being cleared.
AlertReleasedThe event TelAlert recognizes when an alert is released from a held state thanks to the release of all held sends using release or releaseall or the alert itself using -releasealert. AlertCheckThe event TelAlert recognizes when an -insert -check is performed. StartedThe event TelAlert recognizes when a send is started. ErrorThe event TelAlert recognizes when an error occurs in the processing of a send. ErrorLimitThe event TelAlert recognizes when a send reaches a limit defined by DialErrorLimit and DialErrorWindow, or by ConnectErrorLimit and ConnectErrorWindow. NotSupportedThe event TelAlert recognizes when the destination involved in a send is not supported by TelAlert (owing typically to the absence of appropriate resources for processing the send). OffDutyThe event TelAlert recognizes when a send cannot be processed because the
intended destination is not on duty.
FilterThe event TelAlert recognizes when a send cannot be processed because the specified destination is filtered according to the terms of a [Filter] definition. ChangeThe event TelAlert recognizes when a send is comprised of multiple processing
steps and one of these steps has been completed (this can occur because the send is set up to take multiple steps, or because of a dialing or other error).
ReplyChangeThe event TelAlert recognizes when an error occurs in the retrieval of a reply or request. ReplyThe event TelAlert recognizes when a reply is received. BadPasswordThe event TelAlert recognizes when a recipient is prompted for a
password and provides an incorrect one.
or
AcknowledgedThe event TelAlert recognizes when a send is acknowledged using ack -ackall. AcknowledgedHeldThe event TelAlert recognizes when a send is acknowledged and -hold. NotAcknowledgedThe event TelAlert recognizes when a send is negatively acknowledged using nak or -nakall. ClearedThe event TelAlert recognizes when a send is cleared using -clear, -clearall, -clearalert, or -cleargroup. CompletedThe event TelAlert recognizes when a send completes by virtue of all
processing having been finished without being cleared.
held using
ReleasedThe event TelAlert recognizes when a send is released from a held state using -release, -releaseall, or -releasealert.
Chapter 19: Getting Familiar with the TelAlert Monitor | 267
ConnectThe event TelAlert recognizes when a step associated with answering or ending
an inbound call occurs.
SecurityAll remote connects and disconnects are sent to this keyword. The [Notification] paragraphs referenced by [Limits] Notification, NotificationLog, NotificationTrap and NotificationITV are invoked for
each event.
WarningThe event TelAlert recognizes when it sends a message that would have failed had AllowUnsupportedTypeSends been set to False.
Non-Alert Events in the
[Notification] Section
[Notification] section are typically triggered by [Configuration], [Destination], [Group], or [User] definitions that is,
by alertsas discussed below they may also be triggered by the following events relating to [Analog], [Battery], [Port], [Power], [Relay], or [Sensor] definitions. The [Limits] section can also trigger [Notification] definitions, but only for error or activation events only, and only when no other relevant section contains the same notification keyword.
ActivationThe event TelAlert recognizes when a definition is activated or deactivated. EngineThe event TelAlert recognizes when a TelAlert Engine reports a change in its
status.
AnalogThe event TelAlert recognizes when a change in the status of an analog device is
reported.
SensorThe event TelAlert recognizes when a change in the status of a sensor device is
reported.
RelayThe event TelAlert recognizes when a change in the status of a relay device is reported. PowerThe event TelAlert recognizes when a change in the power level of the TelAlert
Engine is reported.
BatteryThe event TelAlert recognizes when a change in the status of the TelAlert
Engine battery is reported.
TalkThe event TelAlert recognizes when a talkload is performed. RequestThe event TelAlert recognizes when a request is received.
${AlertID}The alert ID. ${Calls}The maximum number of call attempts that can be made, the number that
have been completed, and the number that have failed.
${Check}The -checkstring. ${ClientHost}The name of the host from which the command generating the alert
was received.
${ClientUser}The user name on the host machine from which the command
generating the alert was received.
${Configuration}The [Configuration] definition used in processing the send. ${ConnectID}The ID identifying this unique telephone call. ${Destination}The destination to which the send was directed. ${EventNum}The event number. ${Group}The name of the group specified by -g or, when using -l, by name (if addressed to nested groups, the top-level group; with i and -c, the value is <none>) ${GroupID}The group send ID. ${IPCheck}The -ipcheck string. ${MaskedTicket}The Ticket value following its alteration according to the terms of the TicketMask value. ${Message}The message provided at the origination of the send. ${Number}The telephone number used in processing the send. ${PIN}The PIN used in processing the send. ${Port}The [Port] definition used in processing the send. ${Priority}The Priority value provided at the origination of the send. ${Remark}The -remark value associated with the send. ${Reply}The actual text of the reply. ${ReplyID}A pair of values: the ID assigned to the reply by TelAlert and the ID
assigned to it by the service provider.
${ReplyTo}The ReplyTo value associated with the send. ${Request}The full text of the request. ${RequestID}The ID assigned to the request by the service provider. ${RequestName}The text preceding the first vertical bar (|) in the request, up to
sixteen characters (if no vertical bar is present, this parameter is assigned the same value as ${Request}).
${RequestPIN}The PIN or email address of the device that originated the request. ${SendID}The ID associated with the send. ${ServerHost}The name of the host on which TelAlert is running. ${Source}The -source value provided at the origination of the send. ${StartTime}The time that the processing of the send or alert was begun. ${State}The current send state: ${StatusData} plus additional state information. ${StatusData}The state number and associated description of this event. ${StateNum}The state number of this event. ${Subgroup}The name of the lowest-level subgroup to which the message was addressed (if the message was not addressed to a group, the value is <none>) ${Subject}The -subject value provided at the origination of the send. ${Ticket}The -ticket value provided at the origination of the send. ${TimeStamp}The time that the event occurred. ${To}The To value used in processing the send. ${TrackID}The tracking ID assigned to the send by TelAlert (part of a sequence
specific to each destination).
${User}The User value used in processing the send. ${Value}The value reported from an analog, sensor, relay, battery, or power event.
[Heartbeat] Active=True WriteExecsToTrail=False Interval=0 Shell="" Command=${TelAlertCfg}/Scripts/notify.sh ${EventData} Start=${TimeStamp} ${ServerHost} Start ${Name} ${PID}, ${StatusData} Exit=${TimeStamp} ${ServerHost} Exit ${Name} ${PID}, ${StatusData} Error=${TimeStamp} ${ServerHost} Error ${Name} ${PID}, ${StatusData} Update=${TimeStamp} ${ServerHost} Update ${Name} ${PID}, ${StatusData}
In this example, a script called notify.sh (or, in Windows, notify.pl) is invoked as part of the Command value whenever one of the four specified events occurs. The data specified in the events definition is passed to and processed by this script. Interval refers to the interval at which TelAlert should issue a status update (assuming Update has been assigned a value). Other keywords are covered below.
notify.sh is provided with TelAlert. You can customize it or invoke instead a script or program of your choice.
[Heartbeat] Section
[Heartbeat]
In the above example, you see all four of the event keywords permitted in the section:
StartThe event TelAlert recognizes upon the starting of any of the TelAlert processes. ExitThe event TelAlert recognizes upon the termination of any of the TelAlert
processes.
ErrorThe event TelAlert recognizes upon the occurrence of an error relating to any of
the TelAlert processes.
When TelAlert detects one of these events, it takes the action you have prescribed according to the values assigned to Command, Shell, and the corresponding event keyword.
[Heartbeat]
Comprising the value assigned to each event keyword, you see all five of the substitution parameters supported for event definitions in the [Heartbeat] section:
${Name}The name of the process associated with the event. ${PID}The daemon process ID associated with the event. ${ServerHost}The name of the host on which TelAlert is running. ${StatusData}The state number and associated description of this event. ${TimeStamp}The time of the event.
17.8
One feature of the [File] section is that it allows you to tell TelAlert whether you would like to be informed when TelAlerts default log files reach their maximum size and, if so, the means by which it should do so. Here, Command, Shell, and one or more event-related keywords combine to form the string that will be passed on the command line when an event matching one of those event keywords takes place. Consider the following example:
[File] # Note that [File] is only invoked for BUILT-IN TelAlert files. # Events associated with log files used with helper programs # (such as readmail and gsmpoll # in [Process], or notify in # [Notification], [Heartbeat], etc.) do NOT invoke this section. Comment=TelAlert sample [File] Section Active=True AttemptWait=5m MaxAttempts=1 SNMPHosts="" WriteExecsToTrail=False WriteSysEventLog=False WriteTrapsToTrail=False Shell=""
# # # # # Use only ONE of the following three Command= examples. Note first example, (that calls the notify.exe program) requires the FIFOFileName and EndOfData keywords. The two subsequent (for script invocation in UNIX and Windows) must have blank FIFOFileName and EndOfData that the values for examples values for
#Example for high-volume logging to a flat file #Command=${TelAlertBin}/notify ${Message} -file ${TelAlertDir) # notify.log -size 50000 -time 01:00 -dayofweek 0 #FIFOFileName=${TelAlertTmp}/notify.fifo #EndOfData=${TimeStamp} EOD #Example for UNIX custom script invocation # Command=${TelAlertCfg}/Scripts/notify.sh ${Message} # FIFOFileName="" must be blank # EndOfData="" #Example for Windows custom script invocation #Requires MKS Toolkit; modify location of MKS as needed # Command="C:\Program Files\MKS Toolkit\mksnt\sh.exe # ${TelAlertCfgFS}/Scripts/notify.ksh ${Message} # FIFOFileName="" # EndOfData="" # For telalert.trail TrailMaxFileSize=50000 TrailSwitchTime=-1 TrailSwitchDayOfWeek=-1 TrailSwitchCmd=${TimeStamp} ${Name}(${PID}) ${BaseFS} Switched to ${FileFS} TrailErrorExit=True TrailErrorCmd="" # For telalerte.log EventMaxFileSize=50000 EventSwitchTime=-1 EventSwitchDayOfWeek=-1 EventSwitchCmd=${TimeStamp} ${Name}(${PID}) ${BaseFS} Switched to ${FileFS} EventErrorExit=True EventErrorCmd="" # For telalertd#.log, telalertf#.log, telalertm#.log, telalertr#.log, # telalerts#.log, telalertv#.log LogMaxFileSize=50000 LogSwitchTime=-1 LogSwitchDayOfWeek=-1 LogSwitchCmd=${TimeStamp} ${Name}(${PID}) ${BaseFS} Switched to ${FileFS} LogErrorExit=True LogErrorCmd=""
# The
With some of these configurations, a program called notify.exe is invoked as part of the Command value whenever one of the three specified events occurs. The data specified in the event keywords value is passed to and processed by this program. notify.exe is provided with TelAlert. You can invoke instead a program or script of your choice. The notify executable is best for high-volume logging to a flat file. The notify scripts are best for low-volume transfer of selected events to a custom script that takes special action on the events. The example scripts simply log the events to a flat file; unless you customize the scripts, they have little advantage over the executable, and have the disadvantage of additional operating-system overhead compared to the executable. Note that you should not have multiple invocations of the notifyexecutable with the same FIFOFilename=value and/or the same -file filename in the Command=line.
The [File] section also handles rollover of the telaconfe.log and The following is a sample [File] section for handling of these files:
# # # # # #
TelaConf and TelaInetD do not have their own .ini or .sects files, so the parameters relating to their log file rollover are kept in telalert.inis [File] section. Unlike telalerte, telaconfe and telainetde do not have functionality to execute operating system commands, so these keywords do NOT exist: ConfSwitchCmd, ConfErrorCmd, InetdSwitchCmd, InetdErrorCmd
# For telaconfe.log ConfMaxFileSize=50000 ConfSwitchTime=-1 ConfSwitchDayOfWeek=-1 ConfErrorExit=False # For telainetde.log InetdMaxFileSize=100000 InetdSwitchTime=-1 InetdSwitchDayOfWeek=-1 InetdErrorExit=False
BackupIniFile="" NumIniSectsFileBackups=2 ReloadAfterSectsFileWritten=True WriteSectsFileAfterChanges=True WriteSectsFileInterval=0s NumIniSectsFileBackups is the maximum number of backup copies of telalert.ini and telalert.sects TelAlert will maintain. The backup files are named telalert.sects.
274 | TelAlert 6e Administrator Guide - Version 6.1.29
followed by a date-time stamp in the format YYYYMMDDHHMMSS (Year/Month/Day/Hour/Minute/Seconds). If a file with that name already exists, TelAlert will append a three-digit number to the end of the new files name. To disable backup, set NumIniSectsFileBackups to 0.
ReloadAfterSectsFileWritten, when set to True, causes TelAlert to automatically activate changes to telalert.sects whenever:
1. 2. 3. TelAdmin user executes a File / Save Data command;
WriteSectsFileAfterChanges, when set to False, causes configuration changes made with TelAdmin to be saved only when a user executes the File / Save Data command. If set to True,
TelAlert saves configuration changes automatically at the interval specified by WriteSectsFileInterval.
WriteSectsFileInterval is the minimum amount of time TelAlert will wait after saving telalert.sects to disk before saving it again.
17.8.3 Miscellaneous
The
[File] Functions
NumVoiceFiles=8
[File]
These are the substitution parameters that are allowed as part of the event keyword value in your [File] section:
${Base}The name of the original log file. ${BaseFS}The same as ${Base}, but with any backslash characters translated into
forward slashes.
${Error}The error code from the failure of a system function (if any). ${File}The name of the file to which the log was switched. ${FileFS}The same as ${File}, but with any backslash characters translated into
forward slashes.
${Function}The function that failed (if any). ${Name}The name of the process associated with the event. ${PID}The daemon process ID associated with the event. ${ServerHost}The name of the host on which TelAlert is running. ${TimeStamp}The time of the event.
Chapter 19: Getting Familiar with the TelAlert Monitor | 275
18
Miscellaneous Administrative Tasks
18.1 Overview
Information on many of the administrative tasks associated with running TelAlert, including starting, stopping, and initializing TelAlert, installing clients, configuring TelAlert to run automatically, and setting up the TelAlert Web client.
18.2
telalert -start
The
The -terse command line option will cause TelAlert to suppress all startup output, except for errors and warnings. For example: telalert -start -terse.
Do Not Perform an
If you are using TelAdmin, doing an -init can wipe out your TelAlert configuration. Refer to Switching Between Configuration Methods in the TelAdmin User Guide for further discussion.
telalert stop
18.3
18.3.1 On Windows
When you install TelAlert on Windows, the installation application automatically configures several TelAlert services to run automatically. No change to the server configuration for all services to be started each time the machine is re-started.
18.3.2 On UNIX
System V-Compliant Systems
On the machine on which the TelAlert server is installed, find the file called It will be in the same directory as the telelartc file.
telalert.init.d.
Copy this file to the directory on the same machine that holds the start-up scripts. Change the name of the file to telalert. In the appropriate run-level status directory
18.4
Alternatively, you can temporarily or permanently modify this list of permitted hosts using various commands. For more information, refer to Command Line Options for Modifying Filter Files in Chapter 3 of the TelAlert Keyword and Command Reference. 2. You must have purchased licenses sufficient to handle as many clients as you wish to be able to connect simultaneously. Contact the MIR3 Sales Department if you need additional licenses, or licenses for different operating systems.
If either of these conditions is not met, the client will fail with an error message, usually this one:
/etc/services
Windows servers
%SystemRoot%\system32\drivers\etc\services
http://www.telalert.com/eval/telalert
When you install TelAlert on a Windows system, the setup utility will automatically install a copy of TelAdmin. To install TelAdmin on other systems running Windows, unzip the downloaded file to any directory. To run TelAdmin, double-click TelAlert.exe, or create a shortcut and add it to your Start menu. The first time you run TelAdmin, you must enter the TelAlert servers IP address. Right-click the TelAlert Hosts icon, choose Add New, enter the IP address in the TelAlert Host field, and click OK.
Three: Make Sure the Client Knows Where to Find the Server(s)
You can do this in either of two ways.
One, you can set the TELALERTHOST environment variable on the machine on which the client is installed. 1. From the Start menu, choose Settings / Control Panel. Double-click the System icon. Click the Environment tab. In the Variable field, type TELALERTHOST. In the Value field, type the hosts IP address. If you have one or more backup hosts and wish the client to roll over automatically when the primary host is down, add their IP addresses or host names, separated by spaces. Click Set, then click OK.
2. 3. 4.
5.
6.
Two, you can use the -host option each time you use this client to access the server:
telalertc -i speaker -m "this is a test" -host primary_host_IP_address 1st_backup_host_IP_address 2nd_backup_host_IP_address ... telalertc -i speaker -m "this is a test" -host primary_host_name 1st_backup_host_name 2nd_backup_host_name ...
Three: Make Sure the Client Knows Where to Find the Server(s)
You can do this in either of two ways. One, you can set the TELALERTHOST environment variable on the machine on which the client is installed. Edit the shell initialization script and add the line:
TELALERTHOST=host_IP_address
If you have one or more backup hosts and wish the client to roll over automatically when the primary host is down, add their IP addresses, separated by spaces.
-host option each time you use this client to access the server:
telalertc -i speaker -m "this is a test" host primary_host_IP_address first_backup_host_IP_address second_backup_host_IP_address ... telalertc -i speaker -m "this is a test" -host primary_host_name first_backup_host_name second_backup_host_name ...
18.5
TelAlert includes two client applications that run on Web servers and can be accessed from any Web browser. TelAlertH.exe (for Windows) and telalerth (for UNIX) are functionally equivalent to the command-line client telalertc, and TelAlertHS.exe (for Windows) and telalerths (for UNIX) are functionally equivalent to telalert. (In fact, both can also be used as command-line applications.) In general, each Web client serves as a messaging interface for cell phone microbrowsers, and it can also serve as an alternative (more lightweight) messaging interface for a standard browser. Thus, the Web clients extend your messaging interface options. Each Web client can be used as the sole means of sending and receiving messages, or it can be used in addition to other means of sending and receiving messages. You can also install the TelAlertH Web client so that your support staff can send, receive and respond to messages via a cell phone microbrowser.
http://www.myserver.com/scripts/telalerth.exe
http://www.myserver.com/cgi-bin/telalerth
You can also point to the servers IP address. For example, when working at the server itself, you could use one of these URLs:
http://127.0.0.1/scripts/telalerths.exe http://127.0.0.1/cgi-bin/telalerths
HelpURL=http://www.myserver.com/telalert/tawchelp.html
Clicking one of the Help links in the Web client will then bring up the online help. You may need to close your browser and reload the Web client before the link will work.
telalerth.ini Sections telalerth.ini can contain "sections" that allow it to present different options under different
circumstances. Three such sections are automatically created using these markers:
ShowTable, ShowVTable, ShowDetailHTable, and ShowDetailVTable relate to the screen shown when uses click the Show button and the Detail screen presented when users click the SendID link or Action button with "Details" selected in the drop-down list. These affect the screens shown to HTML browsers only. ShowAlertTable, ShowAlertVTable, ShowAlertDetailHTable, and ShowAlertDetailVTable all relate to the screen presented when users click the Show Alert
button and the Detail screen presented when users click the AlertID link or press the Action button with "Details" selected in the drop-down list. These affect the screens shown to HTML browsers only.
ShowWAPTable and ShowWAPDetail affect the options presented to microbrowsers. ShowWhat determines what buttons are shown on the main page: Show, Show Alert, both, or
neither.
telalerth.ini Keywords
Here is a brief guide to the telalerth.ini keywords, their meanings, and default values.
AckWait
Command-line -ackwait value. Default: 0m
AutoResetMessage
Y/N - Clear message text boxes after a send?
Default:
AutoResetOptions
Y/N - Clear Options screen values after a send?
Default:
AutoResetTargets
Y/N - Clear Destination/Group/Config values after a send?
Default:
BodyBackground
Sets HTML attribute.
Default:
none
BodyColorALINK
Sets HTML attribute.
Default:
none
BodyColorBGCOLOR
Sets HTML attribute.
Default:
none
BodyColorLINK
Sets HTML attribute.
Default:
none
BodyColorTEXT
Sets HTML attribute.
Default:
none
BodyColorVLINK
Sets HTML attribute.
Default:
none
ConnectPause Overrides ConnectPause configuration keyword value. Default: 2 ConnectTimer Overrides ConnectTimer configuration keyword value. Default: 10 ConnectTries Overrides ConnectTries configuration keyword value. Default: 5 ConnectWait Overrides ConnectWait configuration keyword value. Default: 30 Delay
Command-line -delay value. Default: 0m Chapter 19: Getting Familiar with the TelAlert Monitor | 285
DestGroupOnly
Y/N - Prevent access to Configuration/User screen?
Default:
DNS
Y/N - Convert numeric IP address to name form?
Default: Y
HelpURL
URL for Web client online help
Default:
none
Host
Same as -host command-line option
Default:
127.0.0.1
IPSecurity
Y/N - Add clients IP-address as -security option?
Default:
JavaScript
Script file name.
Default:
none
JavaSupport
Y/N - Support JavaScript functions?
Default:
ListSize
Vertical height of Dest/Group lists.
Default:
10
ListTags
Same as -tags command-line option.
Default:
none
LockConfig
Y|N - prevent changes/access to Config screen?
Default:
LockOptions
Y/N - prevent changes/access to Options screen?
Default:
LockPreferences
Y/N - prevent changes/access to Preferences screen?
Default:
LogFile
UNIX log file; Windows log file
Default:
/tmp/telalerth.log; C:\TEMP\TELALERTH.LOG
Logfile
Logo file name.
Default:
none
LogoHeight
Logo height.
Default:
80
MetaRefresh
Set to a value n to cause the message sent screen to automatically go back to the main screen n seconds after the send has been issued. If the value is set to 0 (the default), the client will stay on the message sent screen until you click one of the buttons.
Default:
MsgSize
Number of rows in message box.
Default:
Priority
Command-line -priority value.
Default:
50
SecurityRequired
Require use of Preferences->Security field?
Default:
Service
Same as -service command-line option.
Default:
25378
StatusWithDate
Y/N - Include Start time in Status displays?
Default:
Verbose
Y/N - Display telalertc equivalent when commands executed?
Default:
AltDial AltHost Calls Conf Dest Dial Group Host PIN Reply Send To Track Update User
Values supported by
Alternate phone number (-an) Alternate host/service (-ahs) e.g., "Connected 1/1, Failed 0/10, Rejected 0/1"
[Configurations] [Destinations]
Primary phone number (-n) Group ID Primary host/service (-hs)
-pin value
Last reply text Send ID -to value Track ID Update time -user value
ShowAlertTable, ShowAlertVTable, ShowAlertDetailHTable, ShowAlertDetailVTable, ShowWAPTable, and ShowWAPDetail are as follows: Recipient Release
To whom was the alert sent? Alert-level release info
Alert Check Client Delay Hold IPCheck Masked Message NodeAddr Priority Remark ReplyTo Response Source Start State Subject ShowTable
Alert ID -check
value
value
-ipcheck value
Masked ticket Message text -nodeaddr -priority -remark
value value
-replyto
value
value
Governs Show Send page appearance. Determines what information is displayed for each send, horizontally from left to right.
Default:
Send,Start,User,Dest,State?128,Message
ShowVTable
Governs Show Send page appearance. Determines what information is shown for each send in one or more rows beneath the initial row of horizontally-arranged send information. Default: Message
ShowDetailHTable
Governs Send Detail page appearance. Determines what information is displayed for each send, horizontally from left to right. Default: Send,Alert,User,Dest,Conf,Source,Priority,Ticket,Masked
ShowDetailVTable
Governs Send Detail page appearance. Determines what information is shown for each send in one or more rows, from top to bottom, beneath the initial row of horizontally-arranged send information. Default: Start,Update,Client,State?128,Calls,Remark,Message,Reply
ShowAlertTable
Governs Show Alert page appearance. Determines what information is displayed for each alert, horizontally from left to right. Default: Alert,Recipient,State?128,Message
ShowAlertVTable
Governs Show Alert page appearance. Determines what information is shown for each alert in one or more rows, from top to bottom, beneath the initial row of horizontally-arranged alert information. Default: Message
ShowAlertDetailHTable
Governs Alert Detail page appearance. Determines what information is displayed for each alert, horizontally from left to right. Default: Alert,Recipient,Source,Priority,Ticket,Masked
ShowAlertDetailVTable
Governs Alert Detail page appearance. Determines what information is shown for each alert in one or more rows, from top to bottom, beneath the initial row of horizontally-arranged alert information. Default: Start,Update,Client,State?128,Remark,Message,Reply
ShowContactInfo
Determines whether TelAlert sales and technical support contact info is displayed. Default: Y
ShowWAPTable
Determines what information is shown when a microbrowser-enabled phone initially accesses the TelAlert Web client. Message=Nlimits the number of characters shown in the message field to N. Default: Send,Message=10
ShowWAPDetail
Determines what information is shown when a microbrowser-enabled phone selects and "reads" a particular message. Default: Send?128,Message
Special Display Options for Microbrowsers Values assigned to ShowWAPTableand ShowWAPDetail can be further specified using these flags, each preceded by a question mark. For example, Send?128, Message shows the send ID in bold text, followed by the message in plain text. 1Splits text, causing each word to begin on a separate line. 2Center-aligns text. 4Left-aligns text. 8Right-aligns text. 128Bolds text. 256Italicizes text. 1024Prefixes each value with its name (i.e., Message=Hi there).
ShowWhat
Determines what buttons are shown on the main page; can be set to Show, Show Alert, Both, or None.
Default:
Both
18.6
The
Setting up Logging
telalert.trailThis is a general record of TelAlert activity. telalerte.logThis is the log file for telalerte, the TelAlert server. It contains all the information TelAlert needs to process all active alerts.
Media Controller log files -- To allow parallel processing, the telalerte server daemon creates a separate child Media Controller process for each Active [Port] definition. Each child process maintains its own log file; the names reflect the Media type: telalerts#.log for Internet Socket ports, telalertm#.log forModem ports, etc. The # is replaced by a digit (telalertv3.log, for instance) since there can be multiple child processes for a particular Media type.
TrailMaxFileSizedetermines the maximum size of telalert.trail EventMaxFileSizedetermines the maximum size of telalerte.log ConfMaxFileSizedetermines the maximum size of telaconfe.log LogMaxFileSizedetermines the maximum size of each of the process-specific log files
(this value applies to all of these files) When these limits are reached, TelAlert (1) deletes the existing backup file; (2) renames the existing log file, giving it a .bak extension; and (3) starts a new log file. You can set any of these keywords to 0 to prevent this procedure from being carried out. Note that doing so will cause the file to continue to grow indefinitely, unless you manually initiate the procedure using the -switch command (discussed in the "Administrative Command Line Options" section of Chapter 3 of the TelAlert Keyword and Command Reference).
18.6.3 WriteExecsToTrail
WriteExecsToTrail is a supported keyword in section or definition where a Commandvalue is
specified. When this is set to True, TelAlert writes the results of executions of the specified command to telalert.trail.
18.7
-deactivate -files -activate -files -deactivate -heartbeat -activate -heartbeat Active keyword can be activated or deactivated on the
18.8
As a user assigned the role of administrator, you can access admin tools to aid in configuring and managing TelAlert 6e. This section describes how to perform tasks using these tools that can be found under the Admin tab.
The remainder of this section is only visible to administrators. The tasks available to administrators are as follows: Importing Data Changing the Color Theme Managing Configurations Managing Departments Managing Holidays LDAP Configuration Single Sign On Configuration Log Viewer Setting System Preferences System Status Verification Changing a Users Role System Reports
To import users, devices, groups, schedules and departments do the following: 1. Contact TelAlert Technical Support for assistance in preparing a TelAlertXchange formatted XML file using an LDAP directory, spreadsheet, or other data source. In TelAlert 6e, this XML file is referred to as a batch import file. Once you have the XML file, log in again to the TelAlert Web UI. Go to Admin > Batch Tool .
2. 3.
4. 5. 6.
Click the Add New Import File button. Click the Browse button to locate your batch import file. Click the Upload File button to upload the batch import file. The records appear in the Batch Import Summary Report with a status of Pending. Select the checkbox next to the Batch Import ID for the record you would like to process. Select the checkbox at the top of the checkbox column if you would like to select all records. Click the Process Records button to process the selected records. The status of the records changes to Processed. Check the status of the individual records that were created by the batch import. To do so, click the in the Batch Import Summary Report. Records that did not get processed successfully are indicated by the word ERROR in the Status column.
7.
8.
9.
10. Correct any errors by manually adding, editing, or deleting the record. For details on how to manually change user, device, and group records, see Supervisor Tasks. 11. Records in your XML file that do not include an <active> tag are set to Active by default. You can change these records to Inactive, so that the user, device, or group cannot receive alerts. To do so, see Activating and De-Activating Users and Activating and De-Activating Groups. After you import users, devices, and groups, proceed to the next step in Common Configuration Tasks.
- <TelAlertXchange version="1.0"> - <summary> <tool version="1.0">6e TelAlert Enterprise Migration Tool</tool> <source>jdbc:microsoft:sqlserver://192.168.3.234:1433</source> <comments /> <timestamp /> <record_count /> </summary> - <records type="department" operation="insert"> - <record> <name>TelAlert_C</name> </record> </records> - <records type="user" operation="insert"> - <record> <username>YvonneG_Admin</username> <firstname>Yvonne</firstname> <lastname>Fickentsher</lastname> <password>password</password> <role>Administrator</role> - <departments> <department>TelAlert_C</department> </departments> </record> - <record> <username>LisaL_Super</username> <firstname>Lisa</firstname> <lastname>Linden</lastname> <password>password</password> <role>Supervisor</role> - <departments> <department>TelAlert_C</department> </departments> </record> - <record> <username>TonyB_Staff</username> <firstname>Tony</firstname> <lastname>Nguyen</lastname> <password>password</password> <role>Staff</role> - <departments> <department>TelAlert_C</department> </departments> </record> </records> - <!--Begin Export of Destination Records--> - <records type="destination" operation="insert"> - <record> <name>YvonneG_Device</name> <owner>YvonneG_Admin</owner> <typename>Email</typename> 4-108 TelAlert 6e User Guide - <ta_properties> <Configuration>Email</Configuration> <To>llinden@calamp.com</To> </ta_properties> </record> 296 | TelAlert 6e Administrator Guide - Version 6.1.29
- <record> <name>LisaL_Device</name> <owner>LisaL_Super</owner> <typename>Email</typename> - <ta_properties> <Configuration>Email</Configuration> <To>llinden@calamp.com</To> </ta_properties> </record> - <record> <name>TonyB_Device</name> <owner>TonyB_Staff</owner> <typename>Email</typename> - <ta_properties> <Configuration>Email</Configuration> <To>llinden@calamp.com</To> </ta_properties> </record> - <record> <name>System2_Device</name> <owner>system</owner> <typename>Email</typename> - <ta_properties> <Configuration>Email</Configuration> <To>llinden@calamp.com</To> </ta_properties> </record> </records> - <!--Export of Global Schedule (referenced in Groups)--> - <records type="rotation_schedule" operation="insert"> - <record> <name>Normal_Day_Shift</name> </record> </records> -<!--Begin Group Records--> - <records type="group" operation="insert"> - <record> <name>Dev1_Group</name> - <members> <destination>TonyB_Device</destination> <destination schedule="rotation_schedule">YvonneG_Device</destination> <user>LisaL_Super</user> </members> - <departments> TelAlert 6e User Guide 4-109 <department>TelAlert_C</department> </departments> </record> </records> </TelAlertXchange>
Record typeElement nameDescription Examples destination<schedulename> - Assign schedule template to a destination rotation_schedule<daysofweek> - Used to define on-duty time for weekly schedule using
the elements:
<MON> <TUE>
<MONDAY>
also supported
<WEEKDAYS> Cannot be combined with <MON> through <FRI> elements <WEEKENDS> Cannot be combined with <SAT> and <SUN> elements
The element values define a maximum of two time ranges using the syntax: hh:mm hh:mm,hh:mm hh:mm If <daysofweek> is omitted, a 24x7 schedule will be created (using a 1 day rotation 00:0023:59). If <daysofweek> is defined, any day that is not specified is considered off-duty. Day elements that do not contain values (example: <FRI></FRI>) are also considered off-duty.
rotation_schedule<owner> - Associates the schedule template with a specific User. When <owner> is defined, the schedule can only be assigned to Devices that are owned by the specified owner. If neither an <owner> or <groupname> is defined, the resulting schedule has
Global scope.
rotation_schedule<groupname> - Associates the schedule template with a specific Group. When <groupname> is defined, the schedule can only be assigned to Members of the specified
Group. The group must exist prior to importing the schedule. Group
Groups by setting <public>false</public>. Groups are imported as public by default (when this option is not specified).
<records type="destination" operation="insert"> <record> <name>JSmith_Pager</name> <owner>JohnSmith</owner> <schedulename>johnsmith_dayshift</schedulename> <typename>Email</typename> <ta_properties> <Configuration>Email</Configuration> <To>johnsmith@somedomain.com</To> </ta_properties> </record> </records>
Example 2: Define Weekday Schedule template for a specific User.
<records type="rotation_schedule" operation="insert"> <record> <name> JohnSmith Dayshift </name> <owner>JohnSmith</owner> <daysofweek> <WEEKDAYS>08:00-11:59,13:00-17:59</WEEKDAYS> </daysofweek> </record> </records> <records type="rotation_schedule" operation="insert"> <record> <name> JohnSmith Dayshift </name> <owner>JohnSmith</owner> <daysofweek> <SUN></SUN> <!--empty or missing Day element == not on-duty--> <MON>08:00-11:59,13:00-17:59</MON> <TUE>08:00-11:59,13:00-17:59</TUE> <WED>08:00-11:59,13:00-17:59</WED> <THU>08:00-11:59,13:00-17:59</THU> <FRI>08:00-11:59,13:00-17:59</FRI> <SAT></SAT> </daysofweek> </record> </records>
The example above shows two equivalent definitions for the same schedule.
<records type="rotation_schedule" operation="insert"> <record> <name>Global Weekend Shift</name> <daysofweek> <WEEKEND>08:00-20:59</WEEKEND> </daysofweek> </record> </records> <records type="rotation_schedule" operation="insert"> <record> <name>Global Weekend Shift</name> <daysofweek> <SAT>08:00-20:59</SUN> <SAT>08:00-20:59</SUN> </daysofweek> </record> </records>
The example above shows two equivalent definitions for the same schedule. Example 4: Define schedule for specific Group. <records type="rotation_schedule" operation="insert"> <record> <name>Helpdesk Weekend Coverage</name> <groupname>Helpdesk Group</groupname> <daysofweek> <WEEKEND>08:00-10:59,12:00-15:59</WEEKEND> </daysofweek> </record> These schedules must be imported after importing the referenced Group. Batch import can not be used to assign these schedules to Group Members (because the Group must be imported before importing the schedule).
If you select a custom color theme, it opens up a wider set of customization options. To create a custom color theme, do the following: 17. Navigate to the following folder in the TelAlert 6e application folder:
Figure 32. Administrators see Departments they are a member of on the Manage Departments page.
As an administrator you can create departments and view, edit and delete departments that you are a member of. You can also view all users and groups that belong to a given department by clicking on the Users and Groups tabs on the Edit Department Details page. Note: The system administrator is the only user that is permanently a member of all departments. Once an administrator is removed from a department, they will not be able to add themselves back to that department. The system administrator is the only user that will able to do this. To add departments to the system, do the following: 1. 2. Go to Admin > Manage Departments . The Manage Departments page appears. Click the Add a New Department button.
3. 4.
Enter a department name, and then click Sav e . After adding the department you will see a confirmation page. Verify the department information. From this page you can: Click on the Edit this department link to if you wish to edit the department details. Click on the Add users to this department link to assign users to this department. Click on the Add another department link if you would like to add another department. Click on the Return to department list link to return to the Manage Departments page.
To view the users and groups associated with a given department, do the following: 5. 6. Navigate to Admin > Manage Departments. The Manage Departments page appears. Click the Edit Department icon next to the name of the department that you would like to view. Click on the Users tab to view all users that belong to the department.
7.
Figure 32. Users can be added to or removed from departments on the Department Users page.
3.
4.
4.
5.
Figure 33. Groups can be added to and removed from departments on the Department Groups page.
4.
To add a group to the department click on the name of the group in the Available Groups list and select the Move Right button. Note: To add more than one group at a time hold down the ctrl key while you click on each of the names in the Available Groups list and then select the Move Right button. To select all of the groups in the current view of the Available Groups list, click on the Move All Right button.
5.
When the desired department members are listed in the Groups in Department list select the Save button.
8.
9.
Editing Departments
To edit a department, do the following: 11. Navigate to Admin > Manage Departments . The Manage Departments page appears. 12. Click the Edit Department icon next to the name of the department that you would like to edit.
Figure 34. Edit Department Details page is the default view when Manage Departments is selected under Admin Tools.
Deleting Departments
To delete a department, do the following: 14. Navigate to Admin > Manage Departments . The Manage Departments page appears. 15. In the list of departments, click the Remove button for the department you want to delete. Note: A Department cannot be deleted if users or groups belong to the department. Remove all users and groups before deleting a department. To view existing department members select the Users and Groups tabs. Members can be removed from departments on these pages.
Adding Holidays
For more information on scheduling, see Managing Schedules. To add holidays to the system, do the following: 1. 2. 3. 4. Navigate to Admin > Manage Departments . The Manage Departments page appears. Click the Add a New Holiday button. Complete the required fields, and then click Save . The holiday is created for the date specified. If the holiday is a recurring holiday (for example, an annual holiday), add a new holiday entry for each future occurrence.
Editing Holidays
To edit a holiday, do the following: 5. 6. 7. Navigate to Admin > Manage Departments . The Manage Departments page appears. Click the Edit Holiday icon next to the name of the holiday that you would like to edit. Edit the fields and click S ave .
Deleting Holidays
To delete a holiday, do the following:
8. 9.
Navigate to Admin > Manage Departments . The Manage Departments page appears. In the list of holidays, click the Remove button for the holiday you want to delete.
Figure 35. LDAP and LDAPS options are available on the Edit LDAP Configuration page.
To do so, modify the following settings: Enabled - If this is set, then users are authenticated by the configured LDAP server, using the parameters set below. Secured - If this is set, then users are authenticated by the configured Secure LDAP server, using the parameters set below. Protocol Version - If Select 2 or 3 depending on the desired protocol. Host - If This is the name or IP address of the LDAP server. Port - If This is the TCP/IP port number to use. The default is 389 for non-SSL and 636 for SSL but it could be different in your company. Root Context - If This is the path description used by the LDAP server. This is where the user records are kept. User Identifier - If This is the LDAP name that is given to designate a user. Most common use SAMAccountName. Access ID - If This is the user ID to be sent by the 6e LDAP client to perform the authentication. Access Password - This is the password string that is associated with the Access ID. Your LDAP server may not need an Access ID and Access Password, so they are not required parameters. After clicking the Save button, the system will attempt to access the LDAP server using these credentials. An error dialog will display if there is a problem. In the case where the LDAP service, though correctly configured, becomes unavailable, staff users and supervisors will not be able to
log in to the application. Administrators will be permitted to log in, using their local 6e password (which might be different from their LDAP password).
3.
C:\Program Files\TelAlert6e\web\jre\lib\security>keytool -import -file<CERTIFICATE FILENAME> -alias <NAME FOR KEY> keystore cacerts
4. Once the certificate is successfully imported into the key store, it is no longer required, so it can be removed from the Java Security directory. Restart the TelAlert 6e Tomcat server.
5.
If this is set, then users are authenticated by the corporate network server, using the Type and User Identifier. Type: Corporate network name/type. This is the corporate network name that is given to designate a user. Single Sign On Details: Clear Trust and Nortel are supported. When SSO is enabled, 6e looks for the username header variable to establish the user identity. If it is not set, a normal login dialog is offered with a warning that SSO is configured but not working currently. If the username is not recognized a normal login dialog is offered with a warning that user (username) is not a recognized 6e user. All SSO actions are audit logged (enable, disable, login, login fail). Users will not be able to reset their passwords when SSO is enabled. o Note In Text to speech environments, users will need to set and modify internal TelAlert passwords even when LDAP is enabled. Contact TelAlert support for a modification to allow this feature.
The Log Out link will not display when SSO is enabled.
To access the logs: 1. 2. 3. 4. Navigate to Admin > Log Viewer. Select the type of log you would like to view in the View Log drop-down menu. Select a value for the Number of Lines to Display Per Page field. Click on the Previous and Next buttons to navigate through the log file.
The settings you can change are as follows: Global Settings - These setting affect the entire web site. Default Number of Items to Display Per Page - This value determines list size, the number of items a user will see in a list of alerts, users, groups or devices. Individual users can then set their own values to whatever is comfortable. This setting establishes a starting value. The acceptable range is from 1-1,000. Default Time Zone - This setting determines which time zone displays by default in the Time Zone field on the Add a New User page. This does not determine the time zone for the schedule displays. Default Header and Display Footer - In some environments you may need to suppress header and footer banners (for example, because your Web portal already has them). Display Advanced Features for Staff Members - For users whose role is supervisor or administrator, TelAlert provides basic and advanced settings for configuring users, devices, groups, schedules, and alerts. For users whose role is staff, TelAlert provides basic and advanced settings for configuring devices and alerts. These advanced settings are provided in separate sections of the Edit My Device page and the Send a New Alert page. You can choose not to display these Advanced sections for staff users by selecting the No radio button.
Home Page Settings - These setting affect the home page only. Default Refresh Rate for My Alerts Snapshot - Defines how often the alert data is refreshed. There is a minimum limit of 60 seconds. Display My Snapshots - Administrators can select whether or not a selection of snapshots display on the home page. In some environments you may want to choose which portlet items should appear on the users home page. Selection is performed with simple radio buttons. Advanced Settings - These setting affect the entire web site. Default View. This value determines whether all alerts or only the active alerts display by default on the alert pages. Default Date Range. This value determines whether alerts sent on the current day, week, month or year will display by default on the alert pages. Changes to these settings take effect immediately when you click the button.
A Data Integrity Check and 6.1 Data Upgrade are available at the bottom of the page. The system administrator can perform a data integrity check to verify that the 6e database properties and TelAlert sections file are in synch and that all users are correctly mapped to their devices and groups. Selecting the Perform Check button writes all of the system status details and results of the user integrity check to the application log. If errors are discovered during the check see the application log for details. Running the data integrity check may degrade performance of the server significantly. It is recommended that the process is not run if there is any load on the system. The Upgrade Data button should only be used when performing an upgrade to 6.1 from an earlier version. The button should be selected before data is loaded into the system. Instructions for using the Upgrade Data button are in the TelAlert 6e 6.1 release notes in the Upgrade section and in the TelAlert 6e Installation and Upgrade guide.
18.9
System Metrics
This report provides the following metrics: Alerts - The total number of alerts initiated using TelAlert 6e during the period. Sends - The total number of sends initiated using TelAlert 6e during the period. Acknowledged - The number of sends to which a reply was returned. Escalated - The number of sends that were escalated. No Response - The number of sends to which there was no reply.
System Traffic
This report provides the following metrics: The total number of alerts initiated using TelAlert 6e during the period. The total number of sends initiated using TelAlert 6e during the period. The number of sends to which a reply was returned. The number of alert errors.
In each case, the administrator selects a start and end date for each report.
19
Getting Familiar with the TelAlert Monitor
19.1 Overview
TelAlert Desktop includes TelAlert Monitor, a tool for monitoring the current state of alerts and their associated messages. TelAlert Monitor is also useful for observing real-time state changes while testing (for example testing escalation). TelAlert Monitor provides the following features: Graphical representation of alert and message status in real-time The ability to manually change the state of active alerts and messages An interface for sending messages An interface for replying to messages An interface that can be customized to meet the needs of admin and non-admin users TelAlert Monitor Window views that can be customized
19.2
TelAlert Monitor is a tool for viewing TelAlert notification events. The primary feature of TelAlert Monitor is the AlertTree in the upper window pane. The AlertTree provides a graphical, real-time representation of TelAlert Alert/Send states and associated attribute values. The lower window pane of the TelAlert Monitor Window displays additional information about the Alert or Send item that is currently selected in the AlertTree.
The display characteristics may be customized to display a tree structure that is appropriate for particular applications. The columns may be customized to display the most pertinent attribute values for a particular application. Buttons at the top of the TelAlert Monitor Window allow you to invoke actions to modify the state of the selected Alert node or Send node. A right-click menu mirrors the button functionality. The New Alert button launches a dialog for sending new messages. You can customize the default buttons and other aspects of the TelAlert Monitor Window. For more information, see Customizing TelAlert Monitor Views. Several TelAlert Monitor windows can be active simultaneously for a particular host. This is useful for viewing alert activity from several perspectives.
19.3
TelAlert Monitor is dependent upon the TelaConf server (TelaConfE.exe) and the Notify Server (NtfySrvr.exe). These servers run on the machine that is hosting the TelAlert server (TelAlertE.exe). TelAlertE starts the NtfySrvr.exe process automatically by executing a command line that is specified in a Notification paragraph. An appropriate Notification paragraph must exist and must be referenced in the Limits section to successfully open a TelAlert Monitor Window. The [Notification] paragraph {Command} keyword value references a TCP/IP port that must match the port number that is specified in TelAlert Desktops Host Properties (associated with the particular server).
2. 3. 4.
19.4
TelAdmin tool and TelAlert Desktop wizards - these tools may be launched from either a toolbar button or from the Tools menu. The toolbar contains a Host selection (dropdown list) control that determines which TelAlert Host (server) is associated with any newly launched tool (TelAdmin, TelAlert Monitor or wizard). The significant difference in how these tools are integrated is that multiple TelAlert Monitor Windows may be simultaneously active for a particular host (only one TelAdmin view may be launched per host). This allows notification event data to be simultaneously viewed from a variety of perspectives (for examples, alert-centric views, destination-centric views, and group-centric views).
A specific TelAlert Monitor view may be selected by clicking the down arrow next to the right of the TelAlert Monitor Window button. This displays a dropdown list of all available views. The list contains the names of all files with an .amv file extension that are located in the same directory that TelAlert Desktop is executed from. Selecting a view from this list will opens a TelAlert Monitor Window using the display settings associated with the selected view.
The statistics in the TelAlert Monitor Data dialog show the actual number of captured notification events in memory. The counters also itemize the number of Alerts and Sends held in memory. Multiple events may be associated with each Alert and each Send. These counters increment as notification events are received and decrement as events are automatically purged from memory. When multiple TelAlert Monitor Windows are open for a particular host, they each provide a presentation of the same underlying data model. TelAlert Monitor builds a data model that contains all captured notification events irrespective of filtering that may be imposed by specific views. For this reason, the statistics may count data items that are not visible in the AlertTree. The TelAlert Monitor Data dialog remains open when all other views are closed. This allows collected event records to persist and allows collection of new records to continue. When a TelAlert Monitor Window is opened while the TelAlert Monitor Data dialog is open, the AlertTree presents data from recently collected notification events that are stored in memory. When a TelAlert Monitor Window is opened prior to collecting notification events, the TelAlert Monitor Data dialog launches and a TelAlert -show command is issued to capture the state of active Alerts and Sends. The in-memory data model is initialized for the resulting -show command output. The State attribute value for these initialized Alerts is: Initialized from Show Cmd (the StateNum attribute value is 1). When a TelAlert Monitor Window is opened that is associated with a snapshot file, the view is not associated with a particular TelAlert host. Consequently, a TelAlert Monitor Data dialog is not launched.
19.5
This section provides a detailed description of the following TelAlert Monitor features: TelAlert Monitor AlertTree TelAlert Monitor toolbar TelAlert Monitor tabs TelAlert Monitor Send Message dialog
19.5.2 Icons
This section describes the icons that appear in the AlertTree.
level) node when active level) node when not active level) node when information expired, pending deletion from memory and view
rd
nd
nd
Destination (3 level Send) node Email (3 level Send) node Speech/TTS (3 level Send) node
rd rd
If one or more Sends are Held, then the Alert is in the Held state and a red (Open) box will be overlaid on the Alert state image to indicate the Held state.
Figure 42 illustrates the basic tree structure. Alert nodes have child nodes that represent their associated Sends. Optional state icons are shown on the right side of the Alert icons and Send icons. The structure of the tree and the visibility of state icons are configured using the TelAlert Monitor - Preferences dialog. Completed events are automatically removed from the tree (and from memory) after a pre-determined delay interval (defined in the Host Properties dialog). The tree image on the right side of Figure 42 illustrates the appearance of the tree when a completed Alert is pending removal. TelAlert Monitor provides many options for modifying the tree appearance and structure. For more information, see Customizing TelAlert Monitor Views. The tree structure that is shown above is expected to be the most widely used option. This particular structure provides an alert-centric overview of system alert processing activity. The particular tree structure in Figure 42 is referred to as Host/Alert/Send because this name represents the hierarchy of the tree nodes.
Figure 43 shows the Alert Tree with labels that identify the states indicated by various icons. New nodes (icons) appear in the tree as notification events are received. If a tree node already exists for a particular Alert Id or Send Id, the node is updated to reflect the current state and attribute values. Various options are provided for controlling if nodes are automatically expanded and controlling if nodes are automatically selected (for more information, see Customizing TelAlert Monitor Views). Nodes may be manually selected by clicking on either a node icon or the associated text. Clicking the right mouse button displays a context menu with options to perform operations using the Alert Id, Send Id or other attributes associated with the selected node. Display updates will be suspended (paused) until the context menu option is selected, a red selection bar is displayed to indicate the display is in pause mode. Display updates may also be paused by double-clicking (left mouse button) on a node icon or associated text, and a single click will resume updates. A tabbed window interface located in the lower pane of the TelAlert Monitor displays detailed information about the selected node (see Figure 43). This information is updated when the selected node is automatically or manually changed. See section 2.1.3 for specific details about TelAlert Monitor Tabs.
Updates Enabled
Updates Paused
Snapshot Button
The Snapshot button is used to save the current in-memory state of Notification data to a file. The in- memory notification event will be instantly serialized to a temporary file when this button is clicked. A common File Open dialog (titled Save TelAlert Monitor Snapshot File) will then prompt the user to name the snapshot file. This dialog will provide a default name using the following convention: MMMDD- YY_hhmmss (where MM=month name, DD=day, YY=year and hhmmss hours/minutes/seconds using 24 hour local time). Example: Oct22-04_142416. The temporary file is renamed when the user clicks the Save button using the specified name. The file extension for Snapshot files is .ams (Alert Monitor Snapshot). Snapshot (.ams) files are stored in the directory that contains the TelAlert Desktop executable. The temporary file is named snapshot.tmp and is stored in the same directory. Snapshot files may be opened for viewing using the TelAlert Desktops Tools menu. Snapshot files contain an image of the view configuration data and notification event data that is serialized from memory into XML text. When a snapshot is opened, the TelAlert Monitor Window options that were in effect at the time the Snapshot is saved will determine the initial view options. Pre-defined and User-defined toolbar buttons are not displayed when viewing a Snapshot file. Only the Status Details and Event Info tabs may be displayed when viewing a Snapshot. The Group/Destination Info tab, Console tab, context menu and buttons are not displayed because a Snapshot view is not associated with a TelAlert Host, consequently no operations or host data information are accessible. Any Alert Monitor View (.amv) file that is locally available may be selected while viewing a Snapshot file.
Context Menu The context menu appears when the right mouse button is clicked in the top pane. If the right button is clicked while the cursor is positioned over a tree node icon or the associated text, a context menu will popup with menu items that correspond to visible buttons (as seen in Figure 43). A separator will divide the per- defined button operations on top from the user-defined operations on the bottom of the menu. User-defined button that are configured to always be in enabled state will not appear on this menu. Figure 43 shows an example context menu when a user-defined button named Forward Copy is configured to be enabled only when a Send node is selected. If the right button is clicked while the cursor is positioned over empty space in the top pane, a context menu will popup containing a menu item for New Alert and also containing menu items that correspond to user- defined buttons that are configured to always be enabled (as seen in Figure 44). Figure 44 shows a context menu, in this example buttons named Remove All and Test Page are configured to always be enabled. When an item is selected using the right mouse button, user-defined operations that are conditionally enabled are shown on the context menu (Figure 44). When the context menu is shown with no item selected (right-click on empty space), user-defined operations for buttons that are always enabled are displayed (Figure 44). The enabled state of context menu options mirrors the enabled state of the corresponding toolbar buttons.
This tab can be configured (using the TelAlert Monitor - Preferences dialog) to display a subset of the available attribute values. When the Show all status attributes checkbox is checked, the value of all available notification event attributes will be displayed, otherwise only available values for attributes that are selected via the TelAlert Monitor - Preferences dialog will be displayed. On option is provided to disable the Show all status attributes checkbox for the purpose of simplifying the presentation or to prevent users from viewing particular attributes (example usage: hide Message contents to preserve confidentially).
This tab can also be configured (using the TelAlert Monitor - Preferences dialog) to display a subset of the available attribute values. When the Show all event attributes checkbox provides the same functionality as the Show all status attributes checkbox that is described in the previous section.
Figure 47. Group/Destination Info Tab (when a Destination is selected in the top pane)
The Group/Destination Info tab requires a TelaConf host connection and Owner read permission (if Owners are used) to display paragraph data. The TelAlert Monitor caches paragraph data to minimize TelaConf host access. Console Tab The Console tab provides a command line console window for typing TelAlert commands and viewing the resulting server output. TelAlert commands resulting from toolbar buttons and context menu operations are also displayed in the console window.
The TelAlert Monitor - Preferences dialog provides an option to disable console command line entry. When console command line entry is enabled, the console window automatically outputs a telalert prompt at the beginning of each line (in blue text). The host command line option is not needed to address a specific TelAlert server because the TelAlert Monitor Window is implicitly associated with a particular server. The console window is equivalent to using the Admin version of the TelAlert client. Login and passwords are not needed from the console because that TelAlert Desktop will prompt for the login/password if needed and automatically supply these to the TelAlert server.
Figure 49 contains an image of the Send Message dialog in its collapsed form and the associated child dialogs (Select Recipients dialog and Delivery Options dialog). The Add Recipients button launches Select Recipients dialog, a mixture of Destinations and Groups may be selected using this dialog. When multiple Recipients are selected the Alert is issued using the TelAlert -l command, this results in creating a Group on the fly named AlertN where N is the Alert ID. The Set Delivery Options button launches the Delivery Option dialog (shown in Figure 49). The Use current options as default checkbox determines if the selected options will remain in effect the next time the Send Message dialog is launched. When the Send Message dialog is launched and delivery options are in effect, the dialog is automatically expanded (as shown in Figure 50) to display the delivery options. The Send Message dialog is also automatically expanded when delivery options are initially set (after clicking OK from the Delivery Option dialog).
Figure 49. Send TelAlert Message Dialog (Delivery Options and Message Recipients dialogs also shown)
20
Security Features
20.1 Overview
TelAlert is deployed in a wide variety of enterprise environmentsenvironments that, for all their diversity, share the same pressing need for network security. This chapter describes the key features with which TelAlert has been equipped in order to ensure a high degree of security when deployed as part of an enterprise network. This chapters aim is to familiarize system administrators with TelAlerts security features, and to demonstrate the ways in which these features make TelAlert an exceptionally security-conscious application.
20.2
Any good site administrator is concerned with security and knows that each new product added may carry security risks that jeopardize applications, data, or the network as a whole.TelAlert addresses these concerns by adopting engineering approaches which insure that potentially troublesome areas (modem connections to the outside world, for instance) are secured. TelAlert has been developed within the enterprise model and with years of guidance from our usersmost of whom run enterprise sites. Thanks to this heritage, TelAlert is able to address these and other points of risk and offer a strong level of security. Understanding TelAlerts heightened securityconsciousness begins with a look at its architecture, which spans four main areas:
Architectural Area
Description The communications hub through which all traffic flows Processes that manage connections to external networks (such as those of paging carriers). telalerte passes messages to these processes for delivery and returns messages from them to clients. Examples include processes such as telalerts (the network media controller) and telalertm (the modem media controller). TelAlerts administrative components. These components let an administrator control TelAlerts operation and configuration Programs (such as telalertc) that let end users and applications pass messages into TelAlert. Potential risks associated with each area can be addressed by safeguards built into TelAlert. TelAlert allows administrators who want maximum security to enable security features like Owners, Users, passwords, and authentication.
telalerte
TelAlert Media Controllers
Potential risks associated with each area are anticipated by safeguards that are built in to TelAlert. TelAlert allows administrators who want maximum security to enable number of security features. The following sections take a look at the security features of each area of TelAlerts architecture.
2.
3.
telalerte communicates via a private protocol. For hackers to spoof network traffic,
they would require a full understanding of the TelAlert binary protocol. As with all TelAlert components, all connection set-ups between are logged.
4.
2.
3.
4.
5.
6.
Circumventing all of these measures still would not give an intruder access to the host platform. For this to be possible via an external interface such as a modem, the system must have software listen on the port and pass incoming data to a special process (such as a login process). TelAlert does not provide this capability. If an intruder were to gain access to a TelAlert port and bypass TelAlert, he or she would be met with the datacom equivalent of dead air. 7. TelAlert can be configured so that telalerte requires a special password be provided each time a message is initiated, thus preventing a client from sending unauthorized messages through a gateway. Clients such as telalert take great care to check every packet to prevent buffer overrun. This makes it difficult for a rogue client to force access to TelAlert or the system underneath it via traditional intrusion methods.
8.
It is worth noting that the activity of media controller processes, like that of all TelAlert components, can be logged to the various log files (for example telalertm1.log, telalerts2.log, telalert.trail, etc.) The level of detail for logging is configurable. See the [Files] section in Chapter 2 of the TelAlert Keyword and Command Reference and Chapter 15 of this manual for information on configuring log file features.
20.3
Password Encryption
TelAlert 5.4 adds password encryption. You can activate this security feature by setting EncryptPasswords to True under [Limits] (the default is False). With this setting, all plain-text passwords found in any section of telalert.ini (i.e., [Users] and [Owners]) will be encrypted before being written to the telalert.sects file. Likewise, with this setting, a userprovided password is encrypted before being compared with its stored counterpart. Passwords are scrambled in such a way as to allow TelAlerte to determine that they are indeed scrambled. This is done by recording the encrypted passwords with a leading "#" character. Encrypted passwords are saved in the telalert.sects file with a leading "#" character. When a telalert.sects password is found starting with a "#", it is considered to be encrypted, and the user-provided password is encrypted before being compared with the stored version. Otherwise, the plain-text version is compared. These comparisons are done for both [User] and [Owner] passwords. Whenever a [User] or [Owner] entry is changed, its password is encrypted if EncryptPasswords=True and it isn't already encrypted. If EncryptPasswords=False, the password is left alone. For example, in TelAdmin, after setting:
[Limits] EncryptPasswords=True
and modifying the user Johns password in the Web UI as follows:
.sects file,
As a general rule, passwords specified on the command-line or via Stored Authentication must be plain-text.
20.4
As mentioned above, the telalert.hosts file controls which TelAlert clients can connect to the TelAlert server. For a client to connect, the machine on which it is installed must be named in this file. Starting with TelAlert 5.4, the ability of a client machine to connect can be governed by a schedule. To do this, you alter telalert.hosts so that each machine is identified by a name in curly brackets. To the keyword Address, assign the machines IP address or hostname. To the keyword Schedule, assign a value matching the name of a TelAlert-defined schedule. For example:
telalert, telalerths, and C/Java APIs with admin telalertc and C/Java APIs without admin capabilities. telalerth.
This is accomplished using new keywords added to the [Limits] section: AdminLoginsRequired, ClientLoginsRequired, and WebClientLoginsRequired. The default value for these variables is False; if set to True, logins are required. There are two approaches to passing the Administrator and password on the command line. If you are using host to specify multiple TelAlert servers to which clients should attempt to connect, you must provide the appropriate Administrator and password following each specified host. Consider this partial command line: -host
1.2.3.4[user1:pass1] 5.6.7.8[user2:pass2]
If you have only one TelAlert server to which clients can connect, you can begin using -host and this associated method of providing Administrator and password. Note that there must not be any space between the final character of the host specification and the opening bracket of the Administrator/password combination. Alternatively, you can use two new command line options, Again, here is a partial command line:
-loginuser Joseph -loginpassword 1k2j345 AdminLoginsRequired is False, admin clients can use this command
20.6
TelAlert supports remote functionality in which one TelAlert server connects with another and borrows its modem. This is a useful way to avoid toll charges. In TelAlert, remote access is governed by telalert.remote files, which are similar in form to telalert.hosts. The following command line options have also been added:
-acceptremote -refuseremote
These parallel accept and -remote and are used with -insert, -delete, -reload, -verify, and -write to modify and display the contents of telalert.remote. Refer to Chapter 6: Setting Up a Remote Port for more information on working with remote connections.
20.7
A keyword, Security, can be used in the [Notifications] section to trigger specified actions in response to security-related state changes within TelAlert. A single security eventmarked as [11]Security/Licenseis comprised of a number of new state changes:
[107]No Web Clients [108]License Expired [109]License Limit Exceeded [110]Admin Unacceptable [111]Client Unacceptable [112]Master Unacceptable [113]Remote Unacceptable [114]Invalid Admin Login [115]Invalid Client Login [116]Invalid Master Login [117]Invalid Remote Login [118]Not A Gateway [119]Master Already Connected
20.8
[Configurations] definitions of Type=InteractiveModem and Type=InteractiveTTS support two keywords. NoUserValidation suppresses the password prompt presented to dialin users, and NoMessageResponse suppresses the acknowledge prompt.
20.9
Skytel has multiple Internet servers that can accept connections from TelAlert customer servers. The servers associated with the hostname skysock.skytel.com accept "normal" connections; the servers associated with the hostname secure-apps.skytel.com accept encrypted connections using the SSL protocol. TelAlert itself only supports normal Internet connections. To utilize SSL connections, third-party software is required. This documentation shows how to implement an SSL "wrapper/proxy" utility using freely-available, open-source third-party software; customers can also use commercial thirdparty software. This SSL wrapper/ proxy software is not downloadable from MIR3. These instructions assume that the SSL wrapper/proxy will be installed on the TelAlert server machine, so that TelAlert can start or stop the wrapper/proxy at the same time TelAlert starts or stops its other processes. Some customers may prefer to install the SSL wrapper/proxy software on a firewall or gateway machine, instead of on the TelAlert server. This will work, but since TelAlert will no longer be able to start or stop the wrapper/ proxy, the customer is responsible for insuring that the wrapper/proxy is running whenever TelAlert is running.
A prebuilt SSLeay Windows binary can also be obtained from http://www.stunnel.org/download/binaries.html Prebuilt UNIX binaries are not available at the time of this writing. Here is the OpenSSL link. Notice that OpenSSL was derived from SSLeay, and is more up-to-date than SSLeay, so it is probably the better library to use if you are building your own stunnel. www.openssl.org (Main site) If you are installing them on the TelAlert server, you can put them with TelAlert's executables in the directory pointed to by the TELALERTBIN environment variable; or, you can put them in another directory of your choice. If you use another directory, ensure that it has the proper permissions. Make sure that the [Process] {Stunnel} definition you create to ensure that Stunnel is running simultaneously with TelAlert (see below) references the correct directory. If you are installing them on a separate "gateway" or "proxy" server machine, the directory to use is entirely your choice.
Ensure that Stunnel will always be running, with the proper parameters, whenever TelAlert is running.
If you have installed stunnel on the TelAlert server, you can use a [Process] definition; a sample is given below. This sample has TelAlert run the ExecProc utility, which then runs Stunnel, instead of having TelAlert directly run stunnel. ExecProc adds features to more smoothly integrate Stunnel with TelAlert; for instance, ExecProc will report to TelAlert if stunnel dies, and will cleanly terminate stunnel on command from TelAlert during a TelAlert shutdown. ExecProc is a new program in the 5.4 release of TelAlert. Parameters that may need to be customized in the following [Process]{Stunnel} definition: MaxAutoActivates controls how many times TelAlert should automatically restart Stunnel if Stunnel dies. Increase this value if observation shows that the Stunnel connection to Skytel often times out. The following are subparameters in the
Command= line:
-debug 0 is the debug flag for ExecProc, not for Stunnel. Use 1 instead of 0 to activate debugging. Debugging information is written to execproc.log. -cfg and exec are ExecProc parms indicating the (-exec) executable file name, and ( -cfg) directory path where the file is located, for the program that ExecProc is to
create as a child process. Not shown in the above example are the TelAlert [Process] standard -file, -back, and -size parameters relating to the execproc.logfile, so the defaults are being used. The -parms string is passed unchanged from ExecProc to the child stunnel process, so the values in parms are more fully documented in the Stunnel documentation. Briefly: "-d 7778" is the socket that Stunnel will use to communicate with TelAlert. "-r secure-apps.skytel.com:7778" is the DNS name/IP address socket that Stunnel will use to communicate with Skytel. (If the your DNS server does not resolve secure-apps.skytel.com, use IP addresses 204.153.80.31 or 204.153.81.31). "-c" indicates that stunnel will run in client mode. "-o stunnel.log" is Stunnel's logfile name. Not shown in this example is "-D 5", which is the default control for the level of debugging information Stunnel writes. To increase the level of information, use -D 6 or -D 7.
Note that the -d socket value must match the TelAlert {SkytelxxxxSSL} definition's Service value, and the -r socket value must match one that Skytel actually monitors, but the d and -r socket values do not need to be identical - it's simply a convenience.
[Process] {Stunnel} Active=True WriteExecsToTrail=True MaxAutoActivates=3 Shell="" Command=${TelAlertBin}/ExecProc ${Message} -debug 0 -cfg ${TelAlertBin} -exec stunnel -parms "-d 7778 -r secure-apps.skytel.com:7778 -c o stunnel.log" Start=${TimeStamp} Start Reset=${TimeStamp} Reset Status=${TimeStamp} Status #Control=${TimeStamp} Control ${Message} #Switch=${TimeStamp} Switch Stop=${TimeStamp} Stop
If you install stunnel on a machine other than the TelAlert server, starting or stopping Stunnel, and providing the proper parameters, is your responsibility. Stunnel can be run under an "inetd"-type arrangement on a UNIX "gateway" machine; refer to the Stunnel documentation. In this situation, the [Process]{Stunnel} definition is not used.
{SkyTelSNPPSSL} # SkyTel National SNPP Text Paging System for Interactive TwoWay Pagers # Uses SSL over the Internet # Dial Backup does NOT use SSL Type=InteractiveTextPager Protocol=SNPP # ProtocolMask sets special protocol options: # 1 - PIN is included in command replies, non-standard # 2 - SkyTel time format which is non-standard ProtocolMask=3 Model=Internet
MaxMessagesPerCall=100 # Host=127.0.0.1 connects to Stunnel running on the TelAlert server. # If Stunnel is on a gateway machine, adjust accordingly Host=127.0.0.1 # Connects to Stunnel using the same socket Stunnel is listening on; # by convention, this is one of the two sockets that Skytel is # listening on (7778 and 8889), but if necessary TelAlert and Stunnel # can use ANY socket that is not otherwise in use on this server. # This must match the Stunnel -d parameter Service=7777 TextPagerWait=30s # To enable dial backup, set DialBackup to a value > 0. DialBackup=0 # May need to have Parity=Even instead of Parity=None to have SkyTel # recognize the protocol properly when we failover to the modem DialBackupProtocol=TMEX Parity=None Speed=19200 AreaCode=800 Number=679-2778 To test
After the TelAlert configuration changes have been made, make sure to stop and start TelAlert to put them into full effect, particularly since the changes involve creating new child processes (ExecProc and stunnel). Finally, the new SSL-aware configuration should be tested.
This method must be rewritten to read from a stream This method must be rewritten to close a TCP stream Post file events to the legacy interface Post heartbeat events to the legacy interface Post notification events to the legacy interface
In addition, one should redefine UserAppStart and UserAppStop to support opening and closing access to the legacy system itself. In a true production environment, one would also redefine error handlers, etc. In this example, we will assume everything works as expected. Consider the following JAVA code; with the exception of the legacy interface, this JAVA code meets the requirements defined earlier in this document.
* * * * */ /**
This class provides an example for those wishing to write their own User subclass. While this class does nothing useful, developers can use this class as a model for a subclass that might work with a database or legacy system.
* First, import the IO package AND our object definitions */ import java.io.Reader; import tanotObjects.*; /** * Get normal JAVA language components */ import java.lang.*; import java.net.*; import java.io.*; /**
* First, subclass the user class and reference THIS class in the shell * THIS IS HOW ONE WOULD CREATE THEIR OWN USER OBJECT
/** * In this example, the class gets its input from a socket not a * file, Therefore, this class must override the OpenStream and
* CloseStream methods to start. Create the necessary objects for * the socket.
/** * Our local constructor does nothing */ public DBUser() { } /** * The post routines do nothing different from the base class * so well just call the base method via super. If not defined * here, the base class methods would be used anyway. * subclass might used an attached database connection, * and use these routines to build and execute insert statements. */ Here a real
public boolean UserPostFileEvent(taNotifyFile event) { /**@todo: Override this tanotify.User method*/ return super.UserPostFileEvent( event); } public boolean UserUnknownAttribute(String elementName, String attrName, String attrValue) { /** Here we would override this method to handle unknown attributes */ /**@todo: Override this tanotify.User method*/ return super.UserUnknownAttribute( elementName, } attrName, attrValue);
public boolean UserAppStart(String[] parm1) { /**@todo: Override this tanotify.User method*/ /** The username and password strings are defined by magic here. /** In real code, youd need to define the logic */ myLegacy.OpenLegacy(usernameRef, passwordRef); return super.UserAppStart( parm1); } public void UserExit() { /**@todo: Override this tanotify.User method*/ mylegacy.CloseLegacy(); super.UserExit(); } public boolean UserPostNotificationEvent( taNotifyNotification event) { /**@todo: Override this tanotify.User method*/ /** Here one should serialize the object into a collection of strings and place them into a vector (data) */ Vector data = /* Get strings out of event */ return myLegacy.PostEvent(Notification, data) } public boolean UserPostHeartBeatEvent(taNotifyHeartBeat event) { /**@todo: Override this tanotify.User method*/ /** Here one should serialize the object into a collection of strings and place them into a vector (data) */ Vector data = /* Get strings out of event */ return myLegacy.PostEvent(HeartBeatEvent, data) } public boolean UserPostError(Exception ex) { /**@todo: Override this tanotify.User method*/ return super.UserPostError( ex); }
*/
public boolean UserAppStop() { /**@todo: Override this tanotify.User method*/ return super.UserAppStop(); } public boolean UserTick() { /**@todo: Override this tanotify.User method*/ return super.UserTick(); } /** * OVERRIDE : OpenStream * This new method gets input from a socket, not a file. */
public Reader OpenStream(String[] parm1) { /** * Get the port number for the server socket were listening on */ String listenPortString = parm1[0]; Integer iValue = new Integer(listenPortString); int portNum = iValue.intValue(); try { /** * Set up the socket and get Reader and Writer interfaces from it * once its active. */ serverSocket = new ServerSocket(portNum); activeSocket = serverSocket.accept();inputReader = new InputStreamReader(activeSocket.getInputStream()); PrintWriter outputWriter = new PrintWriter(activeSocket.getOutputStream()); outputWriter.println("XML Parser ready"); return inputReader; } catch (IOException ioex) { ioex.printStackTrace(); return null; } Chapter 20: Security Features | 349
} /** * OVERRIDE : CloseStream * Close the stream opened by OpenStream */ public void CloseStream() {
21
Integrating XML Output
21.1 Overview
TelAlert 5.3 and beyond now supports notifications in XML format. This new interface allows developers to post notifications to third-party systems with minimal effort. In addition, developers can use this interface to provide customer database and legacy system support. This chapter describes the steps needed to integrate a TelAlert installation into a third-party backend. Note that this chapter assumes the reader is familiar with TelAlert, its notification interfaces, and JAVA programming.
21.2
1.
The
TelAlert has two distinct circumstances in which it can produce XML output.
[File] section; the [Heartbeat] section; and definitions in the [Notification] sections can specify XML format for the event data they produce. All
three of these sections provide event-driven output, triggered by internal TelAlert events in the alert lifecycle. TelAlert includes a DTD (tanote.dtd) that defines the XML output for these events. TelAlert also includes some documentation of an example application that receives and processes this XML event data stream.
2.
The telalert show and showalert commands have been enhanced to produce XML-like output. This is somewhat of a curiosity; no DTD is provided, and no method of passing the output to another application is implemented (other than the standard >> redirection of command output to a file on both Windows and UNIX, and the "|"piping of command output on UNIX.)
To have [File], [Heartbeat], or [Notification] produce XML output, simply include [XML] in the appropriate event keyword definitions. For example, a [Notification] definition that includes the keyword-value pair
AlertStarted=[XML]
would produce output looking like this:
<Notify><NotificationEvent><AlertStarted tanTimeStamp="2002-03-19T00:31:44+00:00" tanServerHost="integrationrd2.telamon.com" tanEventNum="20" tanStateNum="20" tanStatusData="[20]Alert Started" tanState="[20]Alert Started, Display" tanParagraph="NotifyLogXML" tanDefinition="NotifyLogXML" tanAlertID="41" tanDestination="Display" tanMessage="test" tanPriority="50" tanUser="" tanCheck="" tanGroup="<None>" tanIPCheck="" tanNodeAddr="" tanRemark="" tanReplyTo="" tanSource="" tanSubject="" tanTicket="0" tanMaskedTicket="0" tanClientHost="integrationrd2.telamon.com" tanClientUser="Administrator" tanGroupFullName="<None>" tanCmndID="342"/></NotificationEvent></Notify>
Among other differences, notice that the timestamp in the first example is in "local" time according to the server clock (PST in this case), while the timestamp in the second example is in UTC (Greenwich) time. For certain variables like ${TimeStamp}whose value according to XML standards differs from older TelAlert defaults, it is now possible to define event keyword-value definitions that use TelAlert ${variablenames}and XML standards; the definition
2002-03-19T00:31:44+00:00 Alert Started 41 Display 0 [20]Alert Started, Display [File], [Heartbeat] and [Notification] can direct their XML-formatted output to all of the same places they can direct their legacy-formatted output: appended to text files; sent to UNIX syslog or Windows Application Event Log; etc. In addition, the "helper" application tconntfy, which is normally used to send event data to Vyteks TelaConsole product, can also be used to direct XML-formatted output to another application listening on a TCP/IP socket, such as the sample JAVA application discussed later in this chapter.
The [Limits] section has a NotificationITV keyword that enables a [Notification] definition to be invoked for every TelAlert event (most [Limits] Notificationxxx keywords are only invoked for a specific subset of events). This keyword is useful for creating an XML data stream containing all events.
[Limits] ... NotificationITV=NotifyXML ... [Notification] ... {NotifyXML} Shell="" Command=${TelAlertBin}/tconntfy ${Message} -size 50000 -raw -host backend:8512 FIFOFileName=${TelAlertTmp}/tconntfy_xml.fifo EndOfData=${TimeStamp} EOD AlertDelayed="[xml]" AlertStarted="[xml]" AlertError="[xml]" AlertNotSupported="[xml]" AlertOffDuty="[xml] AlertFilter="[xml] AlertCleared="[xml]" AlertCompleted="[xml]" AlertReleased="[xml]" AlertCheck="[xml]" Started="[xml]" Error="[xml]" NotSupported="[xml]" OffDuty="[xml]" Filter="[xml]" Change="[xml]" ReplyChange="[xml]" Reply="[xml]" BadPassword="[xml]" Acknowledged="[xml]" NotAcknowledged="[xml]" Cleared="[xml]" Completed="[xml]" Released="[xml]" Connect="[xml]" Activation="[xml]" Engine="[xml]" Analog="[xml]" Sensor="[xml]" Relay="[xml]" Power="[xml]" Battery="[xml]" Talk="[xml]" Request="[xml]" ErrorLimit="[xml]" Warning="[xml]" AcknowledgedHeld="[xml]"
21.3
In this example, assume the TelAlert administrator has a running TelAlert server, and that the server has been configured to emit notifications via XML (consult the TelAlert documentation for details on XML output). Furthermore, for simplicity, assume that the administrator has chosen to have notifications carry all possible attributes. Finally, assume these notifications are being broadcast on a socket connection to our new backend process. We will assume this backend process will listen to TCP port 8819, hostname backend. (The toolkit can easily be extended to support any interface, but TCP/IP sockets are convenient mechanisms and require minimal setup.) In our backend process, once data is available, we want it to be posted to a legacy system. This system could be a database, a proprietary controller or a set of disk files. In this document, we will not discuss the legacy interface. Rather, we will assume that a JAVA package for the legacy interface is already available to the developer with the following class object.
public class LegacyMigration extends Legacy { public boolean OpenLegacy(String account, String password); public boolean CloseLegacy(); public boolean PostEvent(String recordType, Vector data); }
The manual page for this class reads:
The legacy class must be extended by the developer to provide three basic interfaces. boolean OpenLegacy(String account, String password) This method will be called when applications wish to open a session with the legacy system. It expects a valid account name and password pass as strings. It will attempt to log into the legacy system. On success, it returns true. On failure, it returns false and generates an error in the system log. boolean CloseLegacy() This interface closes the active session with the legacy system. On success, it returns true, false on failure.
boolean PostEvent(String recordType, Vector data) The PostEvent method is used to post new data into the system. Itexpects a record type (String) and a list of data objects, all type String. Data is simply read from the vector until all elements have been exhausted. As with other legacy routines, it returns true on success, false on failure. On failure, the entire record is rejected.
Given this interface, one can post events to the backend system. In this example, we assume the backend system can make sense of the data and that, in fact, errors never occur. In a true system, legacy routines would manage error events and return events upstream. Our task is to get a stream of notification events from a single TelAlert server and post those events into the legacy system via this interface.
21.4
TelAlerts XML stream, like all XML, consists of a text stream describing data. To debunk an old myth, XML does not have meaning, it is simply a representation of the data. Applications require a definition document to describe that data to describe to them what a given block of data means in terms of objects. Simply having XML does not give you interoperability. This document, also supplied with TelAlert, is the data-type-document or DTD. A DTD describes the structure of an XML document what is allowed where and how often. While meaning is still absent, applications can at least trust that their content is syntactically correct. As an analogy, a JAVA class contains data in various objects. Any application can access that class and its data akin to the XML document and DTD - but the meaning of the sub-objects is still left to the developer. A string is a string, is a string In TelAlerts XML streams, objects begin with the <Notify> tag. This tag signals the start of an event. The event will end when a </Notify> tag is received. One and only one event will be encapsulated within these tags.
After a notify object, a single object event may follow. TelAlert supports three basic object types:
Events related to the file system and log files within the server Events indicating various actions inside TelAlert Events TelAlert sends out to let other systems know about its general health
As one might expect, these events are indicated by XML tags named <FileEvent>, <NotificationEvent> and <HeartBeatEvent> respectively. As with all XML, these objects are encapsulated inside the notify events:
</EventData>.
Within each event, several string attributes can be defined. Consult the TelAlert documentation for the meaning of these strings. For our purposes, assume that a given notification <N1> has attributes a, b, and c. Each attribute must contain a string value. Therefore the XML would look like:
21.5
Given the above XML, some code must be written to perform the following tasks: 1. 2. 3. 4. Open an access port to the XML from some server using the appropriate communications media a socket, a file, a serial port, etc. Create a parser designed to parse that XML into usable objects For each object parsed, pass that object to a third-party interface When done, close the third-party interface and access stream
Fortunately, our XML parser toolkit has written much of the basic skeleton already. Using this kit, a developer will most likely need to change only one class. Overall, the toolkit consists of three JAVA packages, only one of which requires development effort. (Source code for the entire package is provided for those who wish to extend the package.) Package Files Purpose This is the parser framework. It is the XML-aware code in the toolkit. Once started, it drives the parsing and calls appropriate publish routines. Normally, developers will not need to change this package. This package defines the JAVA objects that hold processed notifications. Unless a developer wishes to add an entirely new type of notification, this package can be considered read only. The shell for the parser. A developer calls this package to start the application and to interface his special methods into the parser. Typically, only two files will require work.
SAXTools
SaxTools.java
TANotObjects
TANotify
Since the majority of these files require no changes, this document will not discuss the files BasicNotification.java, SAXTools.java, and Application.java. The reader may consult the source code for details in these sections. Furthermore, the entire project is written using the Xerces SAX Parser specification (http:// www.apache.or/xml). This specification assumes the reader is familiar with JAVA event-based programming. For those unfamiliar with event-based programming, rather than having a standard code module that calls procedures as they occur, event programs register with a dispatcher. During startup, the program requests that, on an event X the dispatcher should call function funcX. This is how SAX works. Simply reading the code might confuse the reader there is no obvious code flow. Looking deeper into SAXTools however, one finds that the constructor registers functions on various XML events. When an element starts or ends, or during an unknown attribute, our parser events are called by the dispatcher. Therefore, rather than drawing a typical code diagram, this document will use an event response matrix. This matrix can be read as When event X occurs, call funcX.
21.6
On Event
Call Method
Purpose
This method in the user object is called when the application first starts. Developers may use this method to set up any special structures and/or threads.
Application Startup
UserAppStart
Application
Shutdown
Shell
UserAppStop
Called just before shutdown. Developers may use this method to perform any final cleanup.
Internal Error
UserExit
When called, it means that a shell or parser component found an error it is not prepared to handle. This method is called to perform a quick, abort-style shutdown.
Unknown Attributes
in XML
SaxTools
UserUnknownAttribute
This method is called by the parser when it finds an attribute or element not in its dictionary. This routine can simply ignore or correct the error, or shut the system down completely.
Shell
UserOpenStream
The shell calls this routine when the shell wants the user class to open the input stream.
Shell
UserCloseStream
Called by the shell when it wants to close the input stream. This routine is called during parsing if invalid XML is found. It may correct or ignore the error, or shutdown the process completely.
Error in XML
Shell SaxTools
UserPostError
On Event
A FileEvent record has been posted
In File
SaxTools
Call Method
Purpose
This method is called during normal processing. Once the XML parser has completely parsed a file event, it passes the JAVA file class to this routine for post-processing.
UserPostFileEvent
SaxTools
UserPostHeartBeatEven t
This method is called during normal processing. Once the XML parser has completely parsed a HeartBeat event, the parser loads a JAVA HeartBeat class and passes it to this routine.
SaxTools
UserPostNotificationE vent
This method is called during normal XML processing. When the parser has completely processed a Notification record, it loads a JAVA Notification object and passes it to this method.
Periodic maintenance
Shell
UserTick
The user tick routine is called every N records during processing. (Default is five records.) During the tick, the user object can perform any side tasks it needs to do. Examples might be purging old records from a database or updating internal health counters.
All of these events are managed by the JAVA User object . This base class (in User.java) does little more than read records from a file and print diagnostic data to the system console. In a real application, one needs to override this object and its methods. This is most often performed by two steps: 1. 2. 3. Define a new User object, say DBUser which extends the User class. Override the various methods above with application-specific methods. Edit the shell code, looking for the line that says User userobject = new User. This is the line that needs to change. The new line should become something like DBUser userobject = new DBUser(). Since DBUser has extended User, all internal routines will work, but our override methods will now take effect. Activate the new object by calling the parsers SetUserObject routine, passing our object.
4.
21.7
As stated above, developers need only create their own User object and redefine necessary methods. (Those methods which are not redefined will simply come from the base class so no harm will occur if someone forgets to redefine a method.) The section below defines the twelve methods that may be defined and their functions: Constructor Calling convention Purpose Returns User None The constructor can be used to set up the user objects data Nothing
OpenStream Reader OpenStream (String [] args) OpenStreamis called by the shell to open the input stream. It accepts a list of ARGV style strings. By convention, these strings define the parameters needed to access the stream. Typically, one parameter might be the file name, port number, etc.
Returns
CloseStream void CloseStream () CloseStream is called by the shell to close the input stream created by OpenStream.
Nothing
UserAppStart boolean UserAppStart (String [] args) UserAppStart is called by the shell just after application startup. It can be used as a pre-parse step. It is similar in concept to the constructor in that it can set up data structure, but it may be called after startup as well. As with OpenStream, it accepts a collection of ARGV style strings which can be used as a parameter list. Returns true if startup was successful, false otherwise. If the method returns false, the shell will exit. UserAppStop boolean UserAppStop () UserAppStop is called by the shell just before shutdown. Returns trueif termination was successful, false otherwise. If the method returns false, the shell will exit.
Returns
UserExit void UserExit () UserExit is called by the shell or parser code when an abort is needed rather than a graceful termination. Nothing
Returns
UserTick boolean UserTick () UserTick is called by parser and shell every n records. (The default is every five records.) During this idle task event, the code may perform any actions needed out of band of parsing. Returns true if the shell is to continue on, falseif a shutdown is required.
Returns
UserPostError boolean UserPostError(Exception ex) UserPostErroris called by the parser when the parser discovers malformed XML. Normally, this would cause a SAX-exception. In this case, the parser calls the user UserPostError passing the exception to the method. The user method may either return true indicating the error is not critical or has been corrected, or falseif termination is required.
Returns Returns true if the error has been corrected, false if termination is required.
UserUnknownAttribute boolean UserUnknownAttribute(String elementName, String attrName) UserUnknownAttribute is called by the parser when it detects an attribute or element not found in the DTD. The event is passed to the user object. If the user object determines the element and/or attribute are acceptable, it should return true. Otherwise, it will return falseand terminate the parser.
Returns Returns true if the error has been corrected, false if termination is required.
UserPostFileEvent boolean UserPostFileEvent(taNotifyFile event) Once the parser has found, and parsed a <FileEvent>XML stanza, it decodes the XML and passes the decoded JAVA object to this post method. The post method should perform whatever action is required to post the event to appropriate systems. Once posted, it should return true. Returning false indicates posting failed and that the shell should terminate.
Returns
UserPostHeartBeatEvent boolean UserPostHeartBeatEvent(taNotifyHeartBeat event) Once the parser has found, and parsed a <HeartBeatEvent>XML stanza, it decodes the XML and passes the decoded JAVA object to this post method. The post method should perform whatever action is required to post the event to appropriate systems. Once posted, it should return true. Returning false indicates posting failed and that the shell should terminate. Returns true on posting success, false if the shell should terminate.
Returns
UserPostNotificationEvent boolean UserPostNotificationEvent(taNotifyNotification event) Once the parser has found, and parsed a <NotificationEvent>XML stanza, it decodes the XML and passes the decoded JAVA object to this post method. The post method should perform whatever action is required to post the event to appropriate systems. Once posted, it should return true. Returning false indicates posting failed and that the shell should terminate. Returns true on posting success, false if the shell should terminate.
Returns
21.8
Given the user object, one can now pass data objects to backend systems. The current codekit defines three objects: 1. 2. 3.
taNotifyFile-The object representing [File] events taNotifyHeartBeat-The object representing [HeartBeat] events taNotifyNotification-The object representing [Notification] events
All three of these objects are implemented as JAVA beans. As with all JAVA beans, the actual variables for various components are marked private. Code accesses the contents of a bean via its getX methods. For example, a [File] event has an attribute ServerHost. Rather than accessing the value of this attribute with code such as String value = taNotifyFile.ServerHost, standard JAVA beans suggest something closer to String value = taNotify.getServerHost(); This isolates the developer from the actual value of ServerHost. The method will return it as a string regardless of its internal representation. For all notifications, consult TelAlert documentation for the appropriate attribute list. For each attribute X, each object has a getX method.
21.9
Development Example
Returning to the development example, the code needs to read input from a stream socket and send the parsed data to a legacy system through a defined Legacy interface object. With the information above, one can now consider the code required to accomplish this task:
java.lang.* tanotify.*; taNotObjects.*; LegacyMagic.*; // LegacyMagic is the packet that // contains the legacy adapter.
In addition, one should redefine UserAppStart and UserAppStop to support opening and closing access to the legacy system itself. In a true production environment, one would also redefine error handlers, etc. In this example, we will assume everything works as expected. Consider the following JAVA code; with the exception of the legacy interface, this JAVA code meets the requirements defined earlier in this document.
package tanotify; /** * This class provides an example for those wishing to write their * own User subclass. While this class does nothing useful, developers * can use this class as a model for a subclass that might work with * a database or legacy system. */ /** * First, import the IO package AND our object definitions */ import java.io.Reader; import tanotObjects.*; /** * Get normal JAVA language components */ import java.lang.*; import java.net.*; import java.io.*; /** * First, subclass the user class and reference THIS class in the shell * THIS IS HOW ONE WOULD CREATE THEIR OWN USER OBJECT */ public class DBUser extends User { /** * Create a Legacy object here */ Legacy mylegacy; /** * In this example, the class gets its input from a socket not a * file, Therefore, this class must override the OpenStream and * CloseStream methods to start. Create the necessary objects for * the socket. */ ServerSocket serverSocket; Socket activeSocket; InputStreamReader inputReader; /** * Our local constructor does nothing */ public DBUser() { } /** * The post routines do nothing different from the base class * so well just call the base method via super. If not defined * here, the base class methods would be used anyway. Here a real * subclass might used an attached database connection, * and use these routines to build and execute insert statements. */ public boolean UserPostFileEvent(taNotifyFile event) { /**@todo: Override this tanotify.User method*/ return super.UserPostFileEvent( event); } public boolean UserUnknownAttribute(String elementName, String attrName, String attrValue) { /** Here we would override this method to handle unknown attributes */ /**@todo: Override this tanotify.User method*/ return super.UserUnknownAttribute( elementName, attrName, attrValue); } public boolean UserAppStart(String[] parm1) { Chapter 21: Integrating XML Output | 365
/**@todo: Override this tanotify.User method*/ /** The Administrator and password strings are defined by magic here. /** In real code, youd need to define the logic */ myLegacy.OpenLegacy(AdministratorRef, passwordRef); return super.UserAppStart( parm1); } public void UserExit() { /**@todo: Override this tanotify.User method*/ mylegacy.CloseLegacy(); super.UserExit(); } public boolean UserPostNotificationEvent( taNotifyNotification event) { /**@todo: Override this tanotify.User method*/ /** Here one should serialize the object into a collection of strings and place them into a vector (data) */ Vector data = /* Get strings out of event */ return myLegacy.PostEvent(Notification, data) } public boolean UserPostHeartBeatEvent(taNotifyHeartBeat event) { /**@todo: Override this tanotify.User method*/ /** Here one should serialize the object into a collection of strings and place them into a vector (data) */ Vector data = /* Get strings out of event */ return myLegacy.PostEvent(HeartBeatEvent, data) } public boolean UserPostError(Exception ex) { /**@todo: Override this tanotify.User method*/ return super.UserPostError( ex); } public boolean UserAppStop() { /**@todo: Override this tanotify.User method*/ return super.UserAppStop(); } public boolean UserTick() { /**@todo: Override this tanotify.User method*/ return super.UserTick(); } /** * OVERRIDE : OpenStream * This new method gets input from a socket, not a file. */ public Reader OpenStream(String[] parm1) { /** * Get the port number for the server socket were listening on */ String listenPortString = parm1[0]; Integer iValue = new Integer(listenPortString); int portNum = iValue.intValue(); try { /** * Set up the socket and get Reader and Writer interfaces from it * once its active. */ serverSocket = new ServerSocket(portNum); activeSocket = serverSocket.accept();inputReader = new InputStreamReader(activeSocket.getInputStream()); PrintWriter outputWriter = new PrintWriter(activeSocket.getOutputStream()); outputWriter.println("XML Parser ready"); return inputReader; } catch (IOException ioex) { 366 | TelAlert 6e Administrator Guide - Version 6.1.29
*/
ioex.printStackTrace(); return null; } } /** * OVERRIDE : CloseStream * Close the stream opened by OpenStream */ public void CloseStream() { try { activeSocket.close(); serverSocket.close(); } catch (IOException ioex) { ioex.printStackTrace(); } } }