Intelligent information routing system and method6539538Abstract An intelligent information router system comprising a telephony controller coupled to a private branch exchange through a link interface. The telephony controller may communicate with a handle manager and a script interpreter engine. The telephony controller may receive information from the link interface regarding telephone calls being placed to the private branch exchange. The telephony controller may initiate actions with the script interpreter engine that access information stored in a database through a database controller. In response to action of the script interpreter engine, the telephony controller may instruct the private branch exchange to route the call to an appropriate location within a company depending on the information received by the private branch exchange through automatic transmission of data or interaction with the calling party. Claims What is claimed is: Description TECHNICAL FIELD OF THE INVENTION
global g_nICRLLogLevel as integer
local hUser32HandLe, hGDI32Handle
local hDeskTop as integer
local hPen, hPen2, hOldPen as integer
local rad as integer
local cx, cy, icx, icy as integer
local pi, angle, x, y as double
local ntimes as integer
local RAND_MAX as double
local 1time as integer
g_nICRLLogLevel = 0
hUser32Handle = LoadModule ("user32", "user32")
hGID32Handle = LoadModule ("gdi32", "gdi32")
if (hUser32Handle <> 0 and hGDI32Handle <> 0) then
if (BindFunction (hUser32Handle, "MessageBoxA",
"MessageBox", "INT", 4) ) then
println "Bind on MessageBoxA succeeded !"
else
println "Bind on MessageBoxA failed !"
endif
BindFunction (hUser32Handle, "wprintfA", "sprintf", "INT",
-1, 0, 1000)
BindFunction (hUser32Handle, "GetDC", "GetDC", "INT", 1)
BindFunction (hUser32Handle, "ReleaseDC", "ReleaseDC",
"INT", 2)
BindFunction (hGDI32Handle, "LineTo", "LineTo", "INT", 3)
BindFunction (hGDI32Handle, "MoveToEx", "MoveToEx", "INT",
4)
BindFunction (hGDI32Handle, "CreatePen", "CreatePen",
"INT", 3)
BindFunction (hGDI32Handle, "SelectObject",
"SelectObject", "INT", 2)
BindFunction (hGDI32Handle, "DeleteObject",
"DeleteObject", "INT", 1)
hdesktop = -1
hdesktop = GetDC(0)
println "hdeskcop == " + hdesktop
hPen = Createpen(0, 3, 0x000000ff)
hPen2 = Createpen(0, 3, 0x0000ff00)
hOldPen = SelectObject (hdesktop, hPen)
rad = 150
pi = 3.141592654
RAND_MAX = 0x7fff
1time = time(0)
println "time() == " + 1time
srand (1time)
rand()
cx = ConvertToDouble (rand())
cy = ConvertToDouble (rand())
cx = (cx * 1000) / RAND_MAX
cy = (cy * 700) / RAND_MAX
# icx = ConvertToInt (cx)
# icy = ConvertToInt (cy)
for ntimes = 0 to 10 step 1
println "ring no. " + ntimes
1if ((ntimes / 2) == ((ntimes + 1) / 2)) then
SelectObject (hdesktop, hPen)
else
SelectObject (hdesktop, hPen2)
end if
for angle = 0.0 to 2*pi step pi/60.0
x = rad * sin (angle) + cx
y = rad * cos (angle) + cy
if (angle == 0.0) then
MoveToEx (hdeskTop, ConvertToInt (x),
ConvertToInt (y), 0)
end if
LineTo (hdesktop, ConvertToInt (x), ConvertToInt (y))
next
next
SelectObject (hdesktop, hOldPen)
ReleaseDC (0, hdesktop)
DeleteObject (hPen)
DeleteObject (hPen2)
# MessageBox (0, "Cool !!!", "Cool !!", 0)
end if
In addition to the detailed description of set forth above, Design and User's Guide documentation directed toward a specific embodiment of the present invention (Intelligent Information Router) is provided below. This document is provided for the convenience of the reader and does not limit the scope of the invention to that embodiment. Design Document for Intelligence Information Router Intelligent Information Router (IIR) Introduction: This document presents the design of AnswerSoft, Inc.'s Intelligent Information Router. The design description begins with an overview of the IIR design and continues with detailed descriptions of the subcomponent units which implement the design. This document ends with a closure section discussing extensibility issues of IIR for the future. The IIR design is based on two overriding principles. First, extensibility is of utmost importance. Second, field maintenance requires that field upgrades be easy and cost effective to implement. This can mean, among other things that field upgrades should be possible without stopping the system. To support these requirements, the design uses a multiple module single level communication bus. Four main components, shown in FIG. 5 and explained below, make up the IIR: the Intelligent Call Routing Language scripting engine (ICRL), the Intelligent Call Routing Telephony module (ICRTEL), the Intelligent Call Routing Customer Database module (ICRDB) and the Intelligent Call Routing General Utilities module (ICRMSC). Each module is responsible for the creation of information sets (data objects) which pertain to the module's subject. The information sets are created on behalf of ICRL. Once created and initialized handles to the information packets are given to ICRL which then manages access and destruction of the information sets. This is discussed in detail in the ICRHANDLE API Specifications. The information sets can be accessed and manipulated through the dynamically bound API's exposed to ICRL (and therefore available to scripts) by any of the functional modules. In order to support internal Q/A, field technical support and user level debugging, IIR implements a multiple level Audit Trail execution dump facility. Audit Trail files provide a complete log of the execution path of a script and the code executed by the script. It is instructive, at this point, to present a short example of a call route prior to detailed descriptions of the modules which perform the work. 1. An incoming call arrives at the PBX 2. ICRTEL receives a corresponding event via the telephony system communicating with the CTI link. 3. ICRTEL creates (allocates) a data information packet which holds all known information about the call, including ANI, DNIS, Prompted Digits, etc. 4. ICRTEL calls a fixed (known) entry point inside the ICRL module which begins the call routing process. 5. The ICRL interpreter runs the relevant scripts to process the call. In doing so, the scripts can and will use the functions exported by the various dynamically bound components. 6. Using the function calls exposed to the ICRL interpreter, the scripts call ICRDB to access a customer database to either find or create a new customer record. 7. If a customer record is found, the script receives a handle to the record in which that customer's data is cached (in memory). 8. The script then calls another ICRDB function to look up the most recent agent to service the customer. 9. Finally the script calls an ICRTEL function to route the call to the agent's phone. It is important to understand that the functionality used by the script, i.e. function calls, are not defined in the language of IRCL. They are defined by the functional modules, such as ICRTEL and ICRDB, and provided to the ICRL engine at system start time, or any time thereafter in the form of other (more basic) script language function calls. This is known as dynamic binding and language extension. ICRL depends heavily on dynamic binding to extend the functionality of its scripting language, without itself requiring changes. This dynamic extension of the ICRL interpretive language allows extreme flexibility to functionality upgrades as well as field repairs to bugs. The Intelligent Call Router Language (ICRL) Overview: ICRL is a free-form, interpreted language which has structured programming features. All functionality beyond language definition will be handled externally through script function calls, provided to ICRL, by other modules within the system. ICRL defines nothing about the services it gains from other modules of IIR, but requires them in order to carry out any interesting actions such as a call route. ICRL is built as a stand alone Windows DLL or a Novell NLM. The ICR prefix of the name is a misnomer of the project which bore out this design. ICRL is useful to any task automation process where information feeds can be attached and script functionality defined to access and manipulate the information. Running Environment All external modules of IIR will communicate only indirectly with the ICRL engine. ICRL provides a couple of intrinsic functions through which scripts can load an external module and then bind script function names to functions within the external module. ICRL adds these functions and the syntactical names to its table of known tokens in the interpreter. This dynamic function extension mechanism alone provides virtually infinite extensibility of ICRL with no coding changes to ICRL itself. It is usually a good practice to run a set of scripts at system startup time which perform the operations of loading the various external IIR modules and binding all the functions each of these modules provide. This not only speeds up the process of a script later accessing an external function, but also simplifies it because the script writer need not bother loading the external module or binding the function that is needed. Once the function tables are initialized (at startup), the ICRL engine will go into a listening mode waiting for incoming script run requests. ICRL Protocol The run-time behavior of the ICR system with the ICRL engine at the core will be controlled through the following protocol. ICRL Startup Phase: At system startup time, the ICRL engine will initialize itself which might include location and loading of global scripts. ICRL Accept Request Phase: After step 1, the ICRL engine will go into a listening mode where it will wait for command process requests from any of the modules. The individual modules then may call ICRL API any time in this mode. The ICRL engine provides two simple calls in its API either one of which external IIR modules can use to run scripts directly. They are ICRLRunScript( ) and ICRLRunScriptEx( ). There are two other functions provided by ICRL that can be used together run scripts in a two step process: ICRCreateScriptThread( ) and ICRExecuteScriptThread( ). ICRExecuteScriptThread( ) and ICRLRunScriptEx( ) accept variable number of arguments which are handed to the script as command line-like arguments. For example, when an incoming call reaches ICRTEL, ICRTEL creates or updates the related information packet and calls ICRCreateScriptThread( ) and ICRExecuteScriptThread( ) with its module ID and the handle which identifies the modified information packet as an argument. The handle contains pertinent information about the call for which the event triggered a script run, such as CallID, ANI, DNIS, etc. The Telephony component creates such a handle for each active call. Functions called from scripts back into the telephony component can use the handle to retrieve information about the call. Handle usage and specifications are discussed in detail in ICRHANDLE API below. System Startup: At system startup time, the ICRL engine loads a pre-defined script and runs it. This script may, in turn, load and run other scripts using ICRLRunScript( ) or ICRLRunScriptEx( ). Any of the startup scripts can make calls to the two ICRL intrinsic functions: LoadModule( ) and BindFunction( ) which allow loading of all external IIR modules and binding of script function names to function pointers within the external module. The beauty of this design is that the ICRL engine requires no knowledge of the outside world--i.e. which events stimulate script runs and which functions are available during a script execution. The entire system is fully dynamic. This is the key to field upgradability. Since ICRL allows infinite external modules, different versions of the same module can be run at the same time. This allows the IIR to be upgraded while running. The generation of script execution threads and script caching is handled in a layer built over ICRL and which interfaces to the functional modules of the IIR. This layer also handles issues closely related to the ICRL script engine by providing miscellaneous utilities such as memory management, information packet access referencing and destruction of the information packets when appropriate. One thing to note is that ICRL itself does not (and need not) distinguish between functions provided by this layer and functions provided by other components. All functions in the function table can assume information packets which they manipulate are handle-based. That is, the allowed parameter types and return types of external functions are pre-defined and cannot be changed or added to. Though this may seem like a severe restriction, it is actually the exact opposite. This implementation frees ICRL from issues with respect to different data types, allowing it to indirectly handle all data types. The implication of is that ICRL does not support data structures or user defined types. If an ICRL script has to handle fields in a data structure, ICRL has to be given a set of Get/Set functions (in the function table) which work on a handle to that type of structure and return/set the individual fields in that structure. Therefore compatibility issues like Unicode or multi-byte (international character set) compliance do not arise as the script will have external handlers which do the necessary work to provide compliance as necessary. ICRL Features The various language constructs which will be supported by ICRL are listed in the IIR user documentation. Implementation Issues The ICRL interpreter engine is implemented using the UNIX compiler generation tools Lex and Yacc. Lex and Yacc together form a powerful compiler definition tool set through which syntax for a language definition can be specified in human readable form. The C source code generated by Lex and Yacc is encapsulated in a C/C++ layer that forms the complete parser/interpreter engine. In addition to the ICRL parser, two other issues are handled by the ICRL module--memory management and string management. Memory management is completely handle based. All functional modules allocate their information packets on behalf of the ICRL engine. These packets are known as handles which relate events to the tied information. Handle aggregation is the technique used to tie the disparate pieces of information with reference counts and the modules that created and can act on the packets. The ICRL module performs all handle management and owns all handles even though the functional modules create and initialize them. ICRL must own the handles because there may be multiple scripts running and accessing the same information simultaneously. Rather than let each module implement its own referencing strategy, a common strategy is implemented by ICRL. This is explained below in detail in ICRHANDLE API Specifications. Error Reporting and Audit Trail Logging ICRL allows two forms of error reporting. First, a syntax pre-parse of scripts will be performed on all scripts. Prior to running a script, whether for simulation purposes or actual implementation, ICRL reads and parses the script in order to build an execution tree. At each point in the script parsing, ICRL knows whether the script is in proper ICRL form and matches syntactical rules. If the rules are broken at any point in a script, ICRL will provide error reports stating the line number and expected syntax at the point the script is in violation and terminate the pre-parse. Termination is not strictly required, as the recursive decent parser of ICRL is capable of continuing, the parse state after a syntax error can't be guaranteed and significant syntax fallout can occur. In such a case, large amounts of errors will be generated which could actually be erroneous errors. Second, as all modules of IIR require, ICRL will provide audit trail logging of each code entry point entered during the script execution. It is not possible to define, completely, at this point how much audit trail logging will exist in any given entry point. At the least, each entry point will provide two logs. First the entry which logs all parameters passed into the entry point. Second, the exit point and all parameters and all return values. Any information packet handle will be recursively dumped to the audit trail file. It is useful to allow levels of audit trailing. The recursive dumps of handles can be expensive in terms of file space, as the information contained in the handle can be large. Therefore, ICRHANDLE objects will be logged based on the bLog member of the handle. This way, a script can turn ICRHANDLE level logging on and off at will to control the size of the audit trail dump. ICRHANDLE API Specifications The ICRHANDLE type is the object by which all IIR subsystems transfer their information into and out of the ICRL engine. All subsystems of the IIR must support the use of the ICRHANDLE to hold store and/or frame allocated information packets. The base handle consists of the following members listed below in Table 1:
TABLE 1
struct tagICRHANDLE
{
CTINT nModuleID; This is the unique module identifier
CTINT nReferences; Counter of entities which are
currently referencing this object.
If the references ever decrease to
zero, the IRCL engine will
automatically destroy the handle via
the handle's virtual HandleDestroy
API.
CTINT bLog; TRUE if this object should be dumped
to the audit trail log. FALSE
otherwise. This defaults to FALSE.
int Pointer to function, provided by the
(*pHandleCompareFunc subsystem, which is used by the ICRL
) ( engine to compare any two handles
ICRHANDLE h1, belonging to that subsystem.
ICRHANDLE h2);
int Pointer to function provided by the
(*pHandleDestroyFunc subsystem which is used by the ICRL
) ( ICRHANDLE h); engine to free memory associated
with that handle after its lifetime.
};
typedef struct tagICRHANDLE ICRHANDLEINFOSTRUCT;
typedef void* ICRHANDLE;
Making the ICRHANDLE a void* hides the ICRHANDLEINFOSTRUCT data members from modules which do not need to know what an ICRHANDLE is. They treat ICRHANDLEs as black boxes. Private modules which do need the ICRHANDLE structure can type cast an ICRHANDLE to the specific structure pointer they want. Any subsystem which registers itself with the ICRL engine must export the following entry points with respect to a handle as listed below in Table 2:
TABLE 2
CTINT This entry point compares two
HandleCompare(ICRHANDLE handles and returns -1, 0 or 1 for
hl, ICRHANDLE h2); h1 < h2, h1 == h2 and h1 > h2
respectively.
void This entry point cleans up all
HandleDestroy(ICRHANDLE); issues with respect to a handle of
information and frees the handle
itself.
void Dumps the handle to the currently
HandleDump(ICRHANDLE); active Audit Trail file.
The ICRHANDLE API will handle all storage and lookup of all handles. The API exposes a high speed lookup mechanism for locating handles based on the contained information and the HandleCompare entry point. The following functions are exported to other subsystems by the ICRHANDLE API itself and need not be overridden or duplicated as listed below in Table 3:
TABLE 3
HandleFind (ICRHANDLE Locates a handle in the handle
hLooksLikeThis); tables via a (possibly
temporary) handle filled with
enough information to complete
calls to the HandleCompare
method. At a minimum, the
nModuleID must be provided, as
well as any information
required by the calling
module's HandleCompare entry
point.
HandleAddToTable (ICRHANDLE Adds a handle to the table of
hAdd); handles currently known to the
system. This method should
always be called after handle
creation and initialization.
Note that the ICRHANDLE APT
does not call HandleAddRef.
This way calls to
DecrementReference do not have
to distinguish between whether
a handle has a reference and
if so, is it in the tables.
The handle must be fully
initialized before calling
this entry point.
HandleRemoveFromTable Removes a handle from the
(ICRHANDLE hRemove); table of handles currently
known to the system. This
method should be required only
rarely handle manager will
automatically remove handles
from its tables when they are
about to be destroyed
void HandleDump (ICRHANDLE); Dumps the base handle portion
of a handle to the current
Audit Trail file.
HandleDestroy (ICRHANDLE Destroys the handle. This
hDestroy); method automatically locates
the correct module and entry
point in that module to call
for proper destruction.
HandleAddRef (ICRHANDLE This method increases the
hThis); reference count on a handle.
Handles will not be destroyed
until the reference count has
dropped to zero or less.
HandleRelease (ICRHANDLE This entry decrements, by one
hThis); the reference count of a
handle. If the reference count
drops to zero, the handle will
be removed from the handle
tables and its destruction
entry point will be called via
DestroyHandle.
As a simple example, a telephony subsystem would allocate information blocks which hold interesting information about telephony events similar to the following Example 2: EXAMPLE 2
struct tagTELINFOSTRUCT
{
CTINT nCallID;
CTINT nCrossRefID;
CTCHAR szDevice[32];
CTCHAR szInstrument[32];
.
.
.
};
typedef tagTELINFOSTRUCT TELINFOSTRUCT,
*PTELINFOSTRUCT;
struct tagTELHANDLE
{
ICRHANDLEINFO BaseHandle;
TELINFOSTRUCT iTelInfo;
}
typedef tagTELHANDLE TELHANDLE, *PTELHANDLE;
CTINT g_nModuleID;
static FUNCTIONTABLE s_ftTable; /* this gets filled out
somewhere */
CTINT
TelCompareHandle (ICRHANDLE h1, ICRHANDLE h2)
{
PTELHANDLE p1 = (PTELHANDLE) h1;
PTELHANDLE p2 = (PTELHANDLE) h2;
CTINT nCompare = p1->nCallID - p2->nCallID;
return nCompare >0 ? 1
nCompare < 0) -1 :
0;
}
void
TelDestroyHandle (ICRHANDLE hThis)
{
PTELHANDLE pThis = (PTELHANDLE) hThis;
/* close files, cleanup net connections, free store */
UtsMscFree (pThis);
}
ICRHANDLE
RegisterAndMakeOne ()
{
PTELHANDLE pThis = (PTELHANDLE) UtsMscMalloc (sizeof
(TELHANDLE) );
g_IRCLModuleID = ICRLRegister (s_ftTable,
TelDestroyHandle, TelCompareHandle);
HandleAddToTable ( (ICRHANDLE) pThis);
return (ICRHANDLE) pThis;
}
BOOL
TelProcessEventFromPBX (PEVENTTHING pEvent)
{
TELHANDLE hTest;
PTELHANDLE pThis;
memset (hTest, 0, sizeof (hTest) );
hTest.nModuleID = g_TelModuleID;
hTest-->nCallID = pEvent->nCallID;
pThis = HandleFind( (&hTest);
if (!pThis)
{
/* make a new handle and fill it up */
pThis = (PTELHANDLE) UtsMscMalloc(sizeof
TELHANDLE);
if (pThis)
}
pThis->nCallID = pEvent->nCallID
/* and so on
HandleAddToTable ( (ICRHANDLE) pThis);
}
}
/* do whatever should be done to actually handle the
event
* like fill up the structure and whatnot
* /
return CTIERR_ALL OK;
}
Intelligent Call Routing Telephony Module (ICRTEL) Overview: The IIR's main purpose at revision level 1.0 will be efficient, intelligent call routing. For this to take place, a complete telephony module must be included which implements the functionality required to perform the route command based on the decision logic in the routing scripts. ICRTEL is this module. The functionality of this module is rather limited, in that its only job is to provide Get/Set methods on the information packets created to represent active calls, methods to perform route sequences. Routing sequences are defined in the ICRL scripts. The route requests within the scripts are carried out by this module. The general nature of this module follows: 1. A Call becomes available at the PBX 2. The PBX delivers the call events across the CTI link to the telephony server 3. ICRTEL receives the event message and creates an information packet which holds all pertinent information and history about the call. 4. ICRTEL calls ICRCreateScriptThread( ) and ICRExecuteScriptThread( ) to run a script and passes the ICRHANDLE which represents the information packet. 5. The Script makes Database lookups as necessary to determine the correct route 6. The Script calls ICRTEL indirectly through the dynamically bound script functions. 7. ICRTEL performs the desired request, which may be a Get/Set request or a route. A route takes two forms, temporary or terminating. A temporary route is a request to route the call to a VDN in order to collect additional InfoDigits. The script which requests a temporary route does not terminate, rather it is suspended until the VDN collection is complete, after which the script resumes. Prior to resuming the script, ICRTEL fills additional InfoDigit packets in the call information packet corresponding to the call. This additional InfoDigit information is appended to the InfoDigit information already present. Appendage is required in order to allow historical decisions based on the VDN paths during a complete route. Terminating route requests are routes which are known to have reached the call's final destination. This is representative of a call being sent to a specific agent or agent group. The terminating call route does not, however, terminate the script. It simply terminates the call's ability to be routed to additional sites. The only exception to this rule is if PBX allows a call to be removed from a queue, assuming the call is still in a queue. In such a case, another ICRTEL script API might provide access to that functionality. The script resumes even after a terminating route request, though, so additional logging might be made or other not-routing commands. Since the ICRL engine provides for information packet handle management, ICRTEL does not attempt to manage the handles it creates. ICRTEL inserts, via HandleAddToTableso), handles to the information packets it creates. No other memory and/or handle management is required. Examples of ICRTEL API exposed to scripts follows in Example 3. EXAMPLE 3
ICRTEL API
ICRTELGetANI (ICRHANDLE); qwer
ICRTELSetANI (ICRHANDLE); qwer
ICRTELGetDNIS (ICRHANDLE); qwer
ICRTELSetDNIS (ICRFANDLE); qwer
ICRTELGetCallID (ICRHANDLE); qwer
ICRTELRoute (ICRHANDLE); qwer
ICRTELRouteInfoDigits (ICRHANDLE); qwer
Intelligent Call Routing Database Module (ICRDB) Overview: The IIR's main purpose at revision level 1.0 will be efficient, intelligent call routing. For this to take place, a complete database module must be included which implements the functionality required to perform the route command based on customer database information. ICRDB is a generic implementation of customer records. The first version of ICRDB allowed only simple single field queries. The current version of ICRDB (ICRDBSQL) implements a generic SQL query and update ability. The most important feature of this external module is that it is designed to be independent of the actual database engine used. ICRDB provides methods to perform queries on the database, find the count of records matching a query and standard forward/reverse traversals (enumeration) of the records. Additionally, within each record, ICRDB provides Get/Set methods per field. This is a difficult issue and may change in design before final shipment of the IIR. The nature of this module is as follows: 1. A Call becomes available at the PBX 2. The PBX delivers the call events across the CTI link to the telephony server 3. ICRTEL receives the event message and creates an information packet which holds all pertinent information and history about the call. 4. ICRTEL calls ICRCreateScriptThread( ) and ICRExecuteScriptThread( ) to run a script and passes the ICRHANDLE which represents the information packet. 5. The Script makes a query on the customer database based on ANI. 6. ICRDB runs an SQL statement against the database engine which generates a record set of matches. The records are stored in an ICRHANDLE subclass and the handle is returned to the Script. 7. The Script requests from ICRDB, the number (count) of matching records in the record set. 8. The Script rolls (traverses) through the matching records and calls ICRDB to determine, for instance, the speaking abilities of the customer. 9. The Script decides, after locating the correct record, that a Spanish speaking agent is required. 10. The Scripts requests ICRTEL to route the call to a Spanish speaking agent. Since the ICRL engine provides for information packet handle management, ICRDB does not attempt to manage the handles it creates. ICRDB inserts, via HandleAddToTable( ), handles to the record sets created during the running of a script. The disadvantage of this is that it is the responsibility of the script programmer to request that ICRL remove the record set handles prior to script termination. No other memory and/or handle management is required. Examples of ICRDB API exposed to scripts follows in Example 4. EXAMPLE 4 ICRDB API ICRDBRunQuery( ) ICRDBGetStringFieldValue( ) ICRDBSetStringFieldValue( ) ICRDBGetNumericFieldValue( ) ICRDBSetNumericFieldValue( ) ICRDBMoveNextRecord( ) ICRDBMovePreviousRecord( ) ICRDBMoveUpdateRecord( ) Future The design of ICRL is based on extensibility requirements. The separation of language features from external functions and dynamic binding of functions makes ICRL very flexible. New functions or even whole components and media (information) feeds could be added to the IIR with minimal effort. The usage of Lex and Yacc guarantees not only good maintenance of code but also extensibility of language features for future releases. User's Guide Documentation for Intelligent Information Router
TABLE 4
1 - Getting Started
Requirements
Hardware
Software
Getting Help
Understanding Typographical Conventions
Installing the Program
Installing Over Existing Files
Beginning the Installation Routine
Installing the System Modules
Using the Program for the First Time
2 - Using the Database Administrator
Setting Up Fields
Defining Primary Key Fields
3 - Using the Agent Station
Searching the Database
Using Wild Card Characters
Modifying the Database
Adding a Record
Modifying a Record
Deleting a Record
4 - Writing Scripts
Using the Simulator Window
Changing the Appearance of the Simulator
Window
Writing a Script
Opening a Script
Formatting a Script
Saving Your Script
Printing a script
Previewing a script
Setting up the printer
Selecting a printer font
5 - Testing and Implementing your Scripts
Testing Scripts
Test Non-Telephony Scripts
Testing telephony Scripts
Viewing the Results
Making the Script Available
Using the VDN Administrator
Adding a Script
Starting and Stopping a Script
Refreshing the VDN Settings
Deleting a Script
Modifying the VDN Settings
6 - Using the Scripting Language
Understanding the IIR Environment
Integrating IIR with the AT&T Switch
Using Operators and Expressions
Variables (Declaration, Usage)
Simulating Constants with Variables
Arithmetic Operators
Relational and Logical Operators
Assignment Operators and Expressions
Script Output and String Operators
Comments
Control Flow
Statements and Blocks
If-Else-Endif
Select Statement
Loops: For-Next and Do-Loop Until
Program Structure
IIR Function Categorization
Guidelines to Follow
Command Summary
A - Command Reference
Function ClearRecord
Function ClearDBHandle
Function CreateTimeHandle
Function DestroyDBHandle
Function DestroyTimeHandle
Function GetAgentAvailable
Function GetAgentState
Function GetAgentTalkState
Function GetAgentWorkMode
Function GetAscTime
Function GetCallingDevice
Function GetCurrentTime
Function GetDayOfMonth
Function GetDayOfweek
Function GetDayOfYear
Function GetDst
Function GetHour
Function GetIncomingUUIData
Function GetIncomingUUILength
Function GetIncomingUUIType
Function GetIVRCollection
Function GetIVRDigits
Function GetVRIndicator
Function GetIVRType
Function GetLookAheadHours
Function GetLookAheadMinutes
Function GetLookAheadPriority
Function GetLookAheadSeconds
Function GetLookAheadSrcVDN
Function GetLookAheadType
Function GetMinute
Function GetMonth
Function GetNumericFieldValue
Function GetNumIVRSets
Function GetSecond
Function GetStringFieldValue
Function GetTrunk
Function GetVDN
Function GetYear
Function ICRLAtoi
Function ICRLLeft
Function ICRLMid
Function ICRLRight
Function ICRLStrCopy
Function ICRLStrIndex
Function ICRLStrLen
Function ICRLStrStr
Function InsertRecord
Function MoveNextRecord
Function MovePreviousRecord
Function QueryAgentState
Function RouteFinal
Function RouteMore
Function RouteUnknown
Function RunQuery
Function SetCurrentIVRSets
Function SetDestRoute
Function SetDirectedAgentCallSplit
Function SetNumericFieldValue
Function SetOutgoingUUI
Function SetPriorityCall
Function SetRouteSelected
Function SetStringFieldValue
Function SetUserProvidedCode
Function UpdateRecord
B - Sample Scripts
C - Terms and Acronyms
D - Error Codes
IIR Simulator Errors
IIR Database Administration Tool
IIR Agent Tool
Error Codes
Time Command Errors
Database Error Codes
Telephony Error Codes
Miscellaneous Low Level Error Codes
Chapter 1--Getting Started The Intelligent Information Router (IIR) is a server-based application for routing incoming telephone calls based upon call information and a set of rules. The IIR application has the following components:
TABLE 5
On the Route Engine A collection of network loadable
NetWare modules:
Server A script engine determines which
scripts to start and subsequent
routing/distribution decisions.
A telephony module allows the
route engine to talk to the T-
server
A database module allows the
script engine to communicate
with the databaseDatabaseData
that you enter into the system.
The database contains 15 text
fields and 5 numerical fields.
On the Simulator Module used for writing and
Client testing scripts, viewing output.
Database Module that allows the
Administrator administrator to label and
define the fields in the Agent
Station. The administrator also
assigns Agent viewing and
modifying privileges for all
fields.
Agent Station Module that allows agents to
search, view, and (in some
cases) modify database
information.
VDN Module which matches scripts to
Administrator Vector Directory Number (VDN)
information for the routing
engine. It also starts and
stops scripts.
Requirements Check your system to be sure that you have the hardware and software the Intelligent Information Router needs to operate successfully. Hardware The following hardware requirements listed in Table 6 are minimum requirements.
TABLE 6
For your NetWare For your client
server machines
Pentium, 100 MHz 486-33 MHz
5 megabytes free hard 10 megabytes free hard
drive space drive space
Recommend I gigabyte
with 12 ms
access time
24 megabytes RAM 8 megabytes RAM (16
megs recommended)
Software The following software requirements listed in Table 7 are minimum requirements.
TABLE 7
For your NetWare For your client
server machines
Novell NetWare 3.11 Windows 3.1
Novell Telephony MS-DOS 5.0
Services, v. 2.2
ATT G3 PBX Driver, Win32S (for IIR
v. 2.2 Simulator only)
Btrieve 6.15.525 Btrieve ODBC Interface
(v.1.0) for Windows
Btrieve Client Engine
for Windows,
v. 6.15
Getting Help The following IIR User Guide documentation explains how to use the Intelligent Information Router. Chapter 1 describes the basic requirements needed to run IIR successfully, explains how to install the program files for both the server and client components, and discusses the architecture of the system. Chapter 2, "Using the Database Administrator," describes the graphical user interface the Database Administrator uses to set up and modify the fields on the Agent Station. Chapter 3. "Using the Agent Station," discusses the features and operating techniques for the graphical user interface used by the Agents. Chapter 4, "Writing Scripts," provides detailed instructions for operating the script editor and the script simulator window. Chapter 5, "Testing and Implementing your Scripts" explains how to test scripts and how to move them to your production environment. It also introduces the VDN Administrator module. Chapter 6, "Using the Scripting Language," provides comprehensive information for writing scripts. This chapter describes the components of scripts in detail. Appendix A provides reference commands for the scripting language you will use to build the IIIR scripts. Appendix B shows samples of typical scripts. Appendix C lists the terms and acronyms used in this manual. Appendix D lists the error messages and the appropriate actions to take for each. From within the program, you can also open the online help topics for quick access to commonly-requested information. Each module has its own self-contained help file. You can open online help from the help menu in any major window for the topics specific to that window. Understanding Typographical Conventions The information below will help you find and use the information in the documentation for the Intelligent Information Router. Sequential instructions are numbered steps that must be followed in the order in which they are presented. Filenames appear in this font: autoexec.bat (filename) to set it apart from information in the text. Text that you are to type, such as text for scripts, is shown as this: declare local variable. Installing the Program The installation routine for the Intelligent Information Router allows you to install all or a portion of the program files. You will need to know a few details about your system to install the files successfully, so please take a moment to review this chapter before you begin to ensure that you have all the information you will need. 1. Read each section carefully before you begin. 2. Write the information required for each step beside the illustrations as you review the chapter to make it readily accessible at the appropriate step. 3. Open Windows (Program Manager or File Manager). 4. Make sure that you have Btrieve installed on the server and the Btrieve ODBC Interface for Windows installed on the client (see Hardware Requirements). 5. Make sure that you are logged on to the NetWare server when you begin installing the program. Installing Over Existing Files If you are reinstalling any of the IIR modules over a previous installation, you must follow the steps below before beginning the new installation. 1. Make certain that any existing NetWare Loadable Modules/(NLMs) are not running on the server. All existing NLMs must not be running when you install the NLM. Check this by running "modules" at the NetWare system prompt. Key IIR NLMs include ICRCTL, ICRL, CTNET, CTIPX, CTUTS. To Unload Existing NLMs, quit ICRS CONSOLE and unload ICRS by running "ulicrs" lat system console prompts. Also, if you are installing NLMs on a separate NetWare and Telephony servers, you must move three NLMs (osfasnl.nlm, tslib.nlm, attpriv.nlm) from NetWare server to the Telephony server. 2. Back up your existing scripts and databases (both production and simulation) in a directory other than the one to which you are installing now. The current installation overwrites some of these files, though you should receive a warning prompt for this action. Beginning the Installation Routine To start the installation, 1. Insert Disk 1 of the set of installation disks into your floppy disk drive. 2. From the File menu, select Run. 3. In the command line, type a: .backslash.setup where a: is the floppy drive. 4. Press Enter. Entering Your User Information As shown by FIG. 6A, The first window to appear is the setup window 500. This window identifies you as the user. 1. Type your first and last names 501. 2. Type the name of your company 502. Installing the System Modules As shown by FIG. 6B, in the IIR Setup window 503, you can select which of the IIR module you want to install. You may install the modules in any order, although if you are installing the IIR on a system with no previous IIR installations, it usually works best to install from top to bottom (i.e., begin with NLMs; end with database administrator) Installing All Modules--General Information To use the setup window 503 for each module 504, follow the general options below. 1. Click the button of the module 504 you want to install (the order is unimportant). 2. In the setup window, type the information required. When typing a path and filename, include the drive. For example, c:.backslash.crs.backslash.admin.backslash.admin.exe If you type a path for a directory that does not exist, the IIR installation routine creates the directory for you. 3. Click the Start Install button. 4. Change diskettes when prompted. 5. Click the OK button in the dialog box announcing successful installation. 6. Select a program group for the icon. 7. (Optional) Check the option for Add to Start Up Group to open the module every time you start Microsoft Windows. 8. Click the OK button to return to the IIR Setup window 503. In the IIR Setup window 503, you can continue installing IIR modules, or you can exit the window. Notes about the Database Path When you install the modules, the installation looks for existing database files. If you have existing database files, a dialog box appears and asks if you want to overwrite the old database. Use the following guidelines. If you have backed up the database file, click the Continue button (you can copy your old database file later into the directory if necessary). If you have not backed up the database file, but do not want to overwrite the file, click the Quit button to stop the installation process and return to the IIR Setup window. If you want to overwrite the old database, click the Continue button. When you install more modules within the same installation session, the message will not appear again. NLM As shown by FIG. 6C, the NLM window 505 installs the NetWare Loadable Module (NLM) on the server. If you are reinstalling this module over an old one, make certain that the existing IIR NLM module is not running. Type the following information. For Mapped Drive and Path 506 type the drive and path where IIR will install the files. For NetWare Volume 508 type the server's volume name (for example ASI1). For Switch ID 510 type (pull-down list only) the name of the telephony switch (should display the default switch ID). Simulator As shown by FIG. 6D, the simulator window 511 installs the script simulator, designed to run on Win 32S. For Install Path 512 type location to install the Simulator module. For Database Path 514 type location for the IIR to create the database. If this path does not exist, the IIR creates it. If the path and database do exist, the IIR overwrites them. For User Ini Files Path 516 type location for the user initiation files VDN Administrator As shown by FIG. 6E, the VDN Administrator window 517 installs the VDN Administrator for matching scripts to the Vector Directory Number (VDN). For Install Path 518 type location to install the VDN Administrator module. For Server IPX Address 520 type IPX address of your server. The IPX address is defined in the autoexec.ncf file in the system subdirectory of the NetWare server. The line titled ipx internal will provide the first eight characters of the IPX address (network address) followed by the entity within the network or server domain (usually "1" for the server). For example, if the line says "ipx internal net 6125100A" then the address is "6125100A.000000000001." For User Ini Files Path 522 type location for your user initiation files. Agent Station As shown by FIG. 6F, the Agent Station Window 523 installs the Agent Station module, which Agents use to modify information in the database. For Install Path 524 type location to install the Agent Station module. For Database Path 526 type location of the production database path on the network server. This path is a combination of the network drive with the NLMs and the subdirectory containing the database. For example, if your network drive is L, and your subdirectory is .backslash.iir, then use the database path L: .backslash.iir.backslash.data. Database Administrator As shown by FIG. 6G, the Database Administrator Window 527 installs the Database Administrator module, which Administrators use to set up the Agent Stations. For Install Path 528 type location to install the Database Administrator module. For Database Path 530 type location of the production database path on the network server. This path is a combination of the network drive with the NLMs and the subdirectory containing the database. For example, if your network drive is L, and your subdirectory is .backslash.iir, then use the database path L: .backslash.iir.backslash.data. When you have finished installing the modules that you selected, you can exit the installation process from the Installation Setup window (see FIG. 6B --Setup Window). Click the Exit button. This program returns you to the Windows Program Manager. Using the Program for the First Time The IIR does not use a common interface for all tasks. Ordinarily you simply open the IIR folder and click the icon for the module you want to use. If you have just installed the IIR, however, you will first want to understand where to go from here, and why. You have just installed up to four client applications for the Intelligent Call Router: Database Administrator, Agent Station, Simulator and VDN Administrator. You can, of course, open any of the applications, but the logical sequence below is for using the IIR the first time: 1. Set up your field labels--You must define and set up the labels and properties of the fields in your customer database. To do this, open the Database Administrator. Chapter 2 discusses this module. 2. Populate the customer database. 3. Write the scripts--The scripts are the heart of the IIR. The tool for writing scripts is the Simulator. Chapter 4 discusses the Simulator window and how to use the scripting editor. If you are unfamiliar with script writing, you can read Chapter 6 for a comprehensive overview and guide to the IIR scripting language. 4. Test your scripts--When you have written a script, you must use the Simulator to test it. Chapter 5 explains this process. 5. Associate the script to a Vector Directory Number (VDN)--When you have tested your script and found it to be successful, you must associate it with the VDN, using the VDN Administrator. The last section of Chapter 5 explains how to associate the VDN to the script and create settings for each script. 6. Modify customer records--This step comes only after the IIR is running successfully and executing scripts. To modify records in the customer database, use the Agent Station module, as discussed in Chapter 3. Chapter 2--Using the Database Administrator The Database Administrator allows anyone with administration privileges to set up the database and perform other tasks which globally affect the Intelligent Information Router. As shown by FIG. 7, the Database Administrator has a single window 600, which allows you to set up the fields that appear in the IIR Agent Station window. You can label the fields, designate agent privileges (view and modify) for each of the fields, and define the primary key fields. Setting Up Fields You may label up to 15 text fields and 5 numeric fields. For each field, you may also designate agent viewing and modifying privileges. 1. Type the labels (maximum 20 characters) next to the field number. 2. To allow agents to view the field, click the View check box. 3. To allow agents to modify the contents of the field, click the Modify check box. Notes: Check box with an X (X) means that the option is enabled. Modify option is void unless you also check the View field. Field 1601 has special weight. If you allow agents to view and modify this field, agents can add or delete any record. If you allow agents to view but not modify this field, you can check the modify option on other fields. Agents can then modify information in fields other than Field 1. They cannot add or delete records. Text fields may contain spaces (for example, an address field: New York). Numeric fields default to integers. Defining Primary Key Fields The Primary Key fields 602 protect against duplicate data. You can choose one of three options in the Primary Key Definition area. None 604 turns off the Primary Key Field designation. Field 1606 sets the first field as Primary Key. Field 1 and 2608 sets the first and second fields as Primary Keys. To select an option, 1. Click the option button for the option you want. 2. Click the Apply button to activate your labels and key definition. The next chapter explains how to use the Agent Station window that you have just defined. Chapter 3--Using the Agent Station As shown by FIG. 8, the Agent Station window 700 is predefined by the Database Administrator (described in the previous chapter). With this window, an agent can modify the information in the database. To modify the fields shown, you must have modification privileges (see "Setting Up Fields"). Searching the Database The first four fields contain information that the IIR engine uses to search the database. When it finds a match, it displays all fields for the record. To search the database, 1. Type the search information in the Search Field(s) 701. 2. Click the Search button 702. The search results appear in the fields 703 outside/below the Search Fields section. To move forward or backward in the database, click the Prev 704 or Next button 706. These buttons scroll one record at a time. Using Wild Card Characters When you search the database, the IIR produces exact matches only, with one exception. If you type "Donald" but have no matching data, IIR continues searching for any wild card characters to the right of the letters you type. So, for example, if the database contains a Donaldson, the IIR also finds that name. Multiple Characters If you are unsure of the spelling, use the percent sign as a wild card. For example, if you want to find a name but are not sure if the spelling is Anderson or Andersen, you would type "Anders%n." The IIR search engine finds all records that match the other letters: Anderson, Andersen, Andersan, Andersun, Andersian (the wild card can represent more than one letter). The search engine would display the first available match and you could then use the Prev or Next buttons to scroll back and forth through additional records. Depending upon your ODBC drivers, the search may or may not be case sensitive. Single Character You can also search for a single wildcard character by using the underscore character (_). (Insert: (_)). For example, in the case above with the name Anderson, if you type Anders_n, the search would not match the name Andersian, because it has two characters between the letters s and n. Modifying the Database Modifying the database includes adding, changing, or deleting information. Because the changes affect the record in the database, you must have privileges assigned by the Database Administrator. Adding a Record To add a record you must have modification privileges to Field 1. 1. Type the information in the fields 703 below the Search Fields 701. 2. Click the Add button 708 to create a new record. Modifying a Record To modify a record, you must have modification privileges to the field you want to modify. 1. Search the database for the record you want to modify, if it is not already displayed. 2. Click the Update button 710 to change the information. Deleting a Record To delete a record, you must have modification privileges to Field 1. 1. Search the database for the record you want to modify, if it is not already displayed. 2. Click the Delete button 712. The record erases the record from the database and is not recoverable. Chapter 4--Writing Script Scripts are powerful tools that enable you to write a set of commands to automate for running repetitive tasks. The Intelligent Information Router engine reads and executes the commands, which you write in a special scripting language. The scripts are made even more powerful by allowing you to use conditional logic. This chapter introduces you to the scripting process, including creating, modifying, and printing with the IIR script editor. Using the Simulator Window As shown by FIG. 9A, the Simulator window 800 has two sections: script section 801 and output section 803. The script section in the upper portion of the window displays the script windows. Each window serves as a script editor for writing and modifying your scripts. Use the output section 803 in the bottom of the window to view the results of testing your script commands. When you open the window, this section also contains initialization information for related files. If you do not see this information, the simulator is not properly initialized. You may open multiple edit windows and organize them in various arrangements (tile, cascade, etc.). The simulator window 800 shown in FIG. 9A has two scripts open. By default, the window opens with a blank page in the script window. When you save this script, the name of the script appears in the title bar of the script window. Changing the Appearance of the Simulator Window You can change the appearance of the Simulator window 800 to allow more workspace. From the View menu 802, click Toolbar and/or Status Bar to hide or unhide these objects. From the Windows menu 804, select Cascade to stagger your script windows. From the Windows menu 804, select Tile to see the scripts in rows. From the Windows menu 804, select Arrange Icons to align minimized (iconized) script windows. Move the output window. This window is dockable, meaning that if you move it to another border, it attaches itself to the border. You can also use it as standalone. To move the output window, grab it with your mouse and drag to another location. If you close the output window, you cannot reopen it until you exit the Simulator window and reopen. Writing a Script The IIR allows you to write as many scripts as you need. The IIR Script Editor is a simple ASCII text editor with a few enhanced options. With the IIR script editor, you can use formatting options (including fonts) and you can copy from other scripts, using standard Windows-based copy-and-paste techniques. Opening a Script When you open the Simulator application, a blank window appears by default. You can use this window to write a new script, open additional new windows, or open existing scripts. New Script If no blank windows are available, or to open additional blank windows, 1. From the File menu, select New. 2. Proceed to the section on page 19, "Formatting the Script." Existing Script To open an existing script, 1. From the File menu, select Open. 2. In the Open dialog box, select a script (scripts have the file extension icr). This dialog allows you to search your directories for scripts. When you install the IIR Simulator, it creates a subdirectory named userscr for storing your scripts. If you want to have this dialog box open to this subdirectory, follow these steps. In Windows program manager, click to select the IIR Simulator icon. From the File menu, select properties. In the "working directory" field, enter the full path of the userscr directory. For example: c: .backslash.iir.backslash.sim.backslash.userscr. Click the OK button. 3. Click the OK button. 4. Proceed to the section, "Formatting the Script." Formatting the Script The general procedure for editing a script includes the steps below: 1. Place your cursor in a script window. 2. Begin typing. For information on the IIR scripting language, please refer to Appendix B. 3. From the File menu, select Save or Save As to save your script. The IIR uses the standard Windows Save dialog. The formatting options are available from the Settings menu. Select Tab Stops to set the number of spaces to use for tabs. You may select from 1 to 16 spaces for tabs. The tab settings affect only the active script. Select Editor Font to select a font for the script editor (see "Choosing Fonts" on page 19 for information. The font setting affects all script windows. Select Word Wrap to wrap text from one line to the next without a line break. The Word Wrap option affects only the active script. Copying from Other Scripts The IIR script editor allows you to copy from other scripts by using Windows techniques for copy-and-paste. The script editor does not support drag-and-drop copying. Please refer to your Windows documentation if you need help with these techniques. Choosing Fonts Font choices apply to all scripts. You cannot maintain scripts with different fonts. IIR allows you to select True Type fonts for both screen and printer, although these fonts may produce undesirable results. Most True Type fonts are proportional, which means that each character uses a different amount of space. For example, the letter i uses less space than the letter w. In contrast, nonproportional fonts such as the Courier typeface are proportional. All these letters take up exactly the same space. For printing, proportional fonts are considered easier to read. For formatting scripts, however, you cannot always vertically line up individual characters or lines of text if you use proportional fonts. If spacing is important to you, use a nonproportional font such as Courier, Terminal, MS Sans Serif, or MS Serif. Also, you can edit any IIR script in any ASCII text editor, but not all text editors can use proportional fonts. If you open a script in one of these editors, your spaces and alignments will change and font appearance may be unpredictable. Using the Find Dialog To find a string of characters, 1. Place your cursor in the script you want to search. 2. From the Edit menu 808, select Find. 3. As shown by FIG. 9B, in the Find What field 809, type the string. 4. (Optional) Check the Match Case option to find only occurrences with exact match of uppercase and lowercase letters. 5. Check the direction for your search, Up (this point to beginning of script) or Down (this point to end). 6. Click the Find Next button to go to the string. The dialog box does not close, allowing you to continue searching through the script text. Using the Find and Replace Dialog To find and replace a string of characters: 1. Place your cursor in the script you want to search. 2. From the Edit menu 808, select Find and Replace. 3. As shown by FIG. 9C, in the Find What field 811, type the string that you want to replace. 4. In the Replace With field 813, type the new string. 5. (Optional) Check the Match Case to find only occurrences with exact match of uppercase and lowercase letters. The editor replaces these strings with the exact case of the string in the Replace With field. 6. Click the Find Next button to go to the string. 7. When the string is found, click the Replace button to replace the string and find the next occurrence. Or, click the Replace All button to replace all matching strings. 8. Click the Cancel button to close the window. The dialog box does not close, allowing you to continue searching through the script text. Saving Your Script You can save your changes at any time. When you close the script or exit the IIR Simulator with unsaved changes, a dialog message prompts you to save your changes. To save anytime, choose one option. From the File menu 806, select Save. If you are saving an existing script, this dialog saves changes to the existing file name. From the File menu 806, select Save As. If you are saving an existing script, this dialog prompts you for a new filename. It saves changes to the new filename, leaving the old file unaffected. To save changes when you exit the IIR Simulator, 1. From the File menu 806, select Exit. 2. In the Save dialog message, choose click one button. Yes--Saves the changes to the filename shown in the dialog. No--Closes the application without saving any changes. Cancel--Returns to the program. Changes in your script are still intact, but the script is still unsaved. Printing a script As shown by FIG. 9D, the IIR editor allows you to print your screen to paper or a file (ASCII). Your dialog window 820 may differ slightly from the one in FIG. 9D, depending upon your printer driver. Please refer to your Windows documentation if you need help with using the Print dialog window. Previewing a script Before you print, you can see your script as it would print. 1. From the File menu 806, select Print > Preview. 2. Use the command buttons at the top of the Preview window to change the view. 3. Click the Close button to return to the editor. Setting up the printer The IIR uses the Windows print setup dialog. Selecting a printer font By default, the IIR uses the System (non-True Type, nonproportional) font. You can change this font. Please refer to "Choosing Fonts" for information about proportional versus nonproportional fonts and how they affect your scripts. To select a printer font, 1. From the Settings menu 822, select Printer Font. 2. Select Change to open the Font dialog box. Select Same as Display to use the same font that you use in the editor (no dialog box). The next chapter provides more information on using the Simulator window. Chapter 5--Testing and Implementing Your Scripts The following stages explain the basic processes of creating and using scripts. Create the script, using the script editor in the IIR Simulator window. Test your scripts with simulated data and view their output in the IIR Simulator window. Implement the scripts with the VDN Administrator. This module sets up the scripts to work on your development platform. This chapter explains how to test and implement the scripts. Testing Scripts The IIR Simulator opens with a blank page in the screen editor. As shown by FIG. 9A, you can use the editor to write a script on this blank page or open an existing script. Generally, your scripts fall into one of two categories: telephony (involving data received from an incoming call or data supplied by the caller dialing more digits) or non-telephony (scripts which do not test telephony calls). The non-telephony calls probably represent a very small percentage of your scripts. Testing Non-Telephony Scripts To test a script, 1. Open the script if it is not already open. 2. Click the title bar of the script to make it active. A script must be active (on top, if you have more than one screen showing) for you to test it. 3. (Optional) From the Settings menu, select Hide While Running to hide the entire window while you are running the Simulator. 4. From the File menu, select Run Direct. Or, click the Simulate icon {character pullout} on the toolbar. Testing Telephony Scripts To test a script, 1. Open the script (see "Opening a Script" for help) if necessary. 2. Click the title bar of the script to make it active. 3. (Optional) From the Settings menu, select Hide While Running to hide the entire window while you are running the Simulator. 4. From the File menu, select Simulate. Or, click the Simulate icon {character pullout} on the toolbar. Using the Telephony Handle Simulator As shown by FIG. 10A, a new window 910 appears if you are simulating a telephony script. This window allows you to enter the information here to simulate the information that the route request would ordinarily provide for a live call. To use this window 1. Enter the information you want to simulate. See Table 8 below. 2. Click the OK button. The results of the test or simulation appear in the output window.
TABLE 8
Fields Description
VDN Enter the VDN that would normally
handle calls for this script. If
you do not use VDN in your
script, you do not need to enter
anything in this field.
CallingDevice Enter the calling device that
represents a call that would
normally route through your
script. If you do not use
CallingDevice in your script, you
do not need to populate this
field.
Trunk Enter a trunk group that
represents a call that would
normally route through this
script. If you do not use Trunk
in your script, you do not need
to populate this field.
UUI Enter User-To-User Information
(UUI) that represents a call that
would normally route through this
script. If you do not use UUI in
your script, you do not need to
populate this field.
UserEnteredCode Enter UserEnteredDigits that
Digits represents a call that would
normally route through this
script. If you do not use
UserEnteredDigits in your script,
you do not need to populate this
field.
UserEnteredCode Enter UserEnteredType that
Type represents a call that would
normally route through this
script. If you do not use
UserEnteredType in your script,
you do not need to populate this
field.
UserEnteredCode Enter UserEnteredIndicator that
Indicator represents a call that would
normally route through this
script. If you do not use
UserEnteredIndicator in your
script, you do not need to
populate this field.
UserEnteredCode Enter UserEnteredVDN that
CollectionVDN represents a call that would
normally route through this
script. If you do not use
UserEnteredVDN in your script,
you do not need to populate this
field.
LookAheadInfo Enter LookaheadType that
Type represents a call that would
normally route through this
script. If you do not use
LookaheadType in your script, you
do not need to populate this
field.
LookAheadInfo Enter LookaheadPriority that
Priority represents a call that would
normally route through this
script. If you do not use
Lookahead Priority in your
script, you do not need to
populate this field.
LookAheadInfo Enter LookaheadHour that
Hours represents a call that would
normally route through this
script. If you do not use
Lookahead Hour in your script,
you do not need to populate this
field.
LookAheadInfo Enter LookaheadMinutes that
Minutes represents a call that would
normally route through this
script. If you do not use
Lookahead Hour in your script,
you do not need to populate this
field.
LookAheadInfo Enter LookaheadSeconds that
Seconds represents a call that would
normally route through this
script. If you do not use
Lookahead Seconds in your script,
you do not need to populate this
field.
LookAheadInfo EnterSourceVDN that
SourceVDN represents a call that would
normally route through this
script. If you do not use
Lookahead SourceVDN in your
script, you do not need to
populate this field.
When you have entered the information required, you can begin the test. Click the OK button 912 to begin the simulation. Click the Cancel button 914 to end the Simulation. Viewing the Results As shown by FIG. 10B, if you have print or println commands in your script, the results of your test appear in the output window 920 at the bottom of the screen. Changing the Position You can move the output window to any position on the screen, including leaving it as standalone or docking it to the top or sides of the window, but not resize it. To move the window, 1. Click the window in the gray border area. 2. Drag to the new location. To clear the output window, select Clear Output from the Edit menu. Making the Script Available When you have tested a script and viewed the successful output, you are ready to make the script available to your production environment. To copy the script to another location, 1. Click the title bar of the script to make it active. 2. In the File menu, select Save As. 3. Save the script to your production subdirectory on the NetWare server usually .backslash.userscr. You can also use Windows File Manager to copy the script to the appropriate subdirectory. When the script is in place, it is ready for you to associate with a Vector Directory Number (VDN), using the VDN Administrator. Using the VDN Administrator As shown by FIG. 10C, the VDN Administrator matches the scripts to the VDN and starts and stops the scripts on the production system. When you open the VDN Administrator window 930, a list box 932 displays all scripts that are set up for the system. You can click the column title (VDN or Script) to sort the list on that column. Adding a Script To add a script, 1. Click the New button 936 to open the VDN Properties window 938 shown by FIG. 10D. 2. Enter a VDN to associate with the script. 3. Enter the script filename (use the Browse button to find it). 4. Check one or both options. Set Default Route Session 940 to set all unassigned VDNs to run a designated script. Set Start Script Route Session 942 to assign a VDN to a script and sets the script to start immediately. You may set only one script for one VDN, but you may set more than one VDN for a single script. Starting and Stopping a Script Returning to FIG. 10C, if a script is not started or is inactive, the check box is empty and the script name appears as light gray. You may start a script with any of three methods. Click the Start button 943. Click the check box next to the VDN in the VDN Administrator window. Click the check box for Start Script Route Session in the VDN Properties window. Refreshing the VDN Settings The Refresh feature is helpful for determining which scripts are currently active or "started." For example, if a script is accidentally deleted or stopped, this window reflects the status when refreshed. Using Refresh Command To force the VDN Administrator to refresh the settings at any time, click the Refresh button 944. You can also set the screen to refresh automatically as shown in the next section. Setting the Refresh Time Rate As shown by FIG. 10E, to set the automatic refresh rate, 1. Enter the refresh time using seconds. 2. Click the Start Timer button 946. The default is ten (10) seconds. You may set any value from 10 to 64. To set the refresh to never refresh automatically, click the Cancel button 948. Deleting a Script Returning again to FIG. 10C, the Delete command in the VDN Administrator window does not remove the script from the directory. Instead, it removes the script from the window only. 1. Select the script you want to remove. 2. Click the Delete button 950 below the script list box. Modifying the VDN Settings Use the VDN Properties window to modify settings also. 1. Select a script in the list box. 2. Click the Modify button 952 to open the VDN Properties window 938. 3. Change the settings (see "Adding a Script" for further information). 4. Click the OK button to save your changes and close the window. Chapters 5 and 6 have explained the overall concepts of the IIR Simulator window. The next chapter provides a detailed look at the IIR scripting language. Chapter 6--Using the Scripting Language The Intelligent Information Router (IIR) system is designed to route calls in a call center environment. The IIR is more intelligent and flexible than the existing ACD/PBX equipment, using the IIR Script as the mechanism through the system obtains the advanced intelligence and flexibility. To develop the IIR scripts, you can use the IIR Simulator, a primary component of the IIR. The IIR Simulator provides an interactive script development environment for testing and debugging of scripts without leaving the tool. If you have not already become familiar with the IIR Simulator tool, please read the sections on "Writing Scripts" (beginning on page 17) and "Testing and Implementing your Scripts" (page 23) before continuing. This chapter provides development-related details on the IIR script language, including standards, pragmas, and syntax. Understanding the IIR Environment It is important to understand how the IIR scripts integrate with other components in the call center. The IIR is an intelligent adjunct router when viewed from the switch perspective. The AT&T switch views the IIR as one of possibly several adjunct processors that will provide call routing direction back to the switch when requested. Although the PBX/ACD can make rudimentary decisions about routing of calls through vector processing commands, it makes global routing decisions rather than customer-oriented routing decisions. For example, the PBX/ACD can determine routing based upon the number of agents available for a particular queue or time of day (for after-hours handling). The routing capability stops there, however, as the PBX/ACD does not have access to customer specific data nor the operations available to process such data in the vectoring commands. Although this type of routing was an advanced feature a few years ago, today's call centers are demanding more customer-oriented routing capabilities which is where the IIR takes over. By integrating the IIR to the PBX/ACD as an adjunct routing controller, an option available through the vectoring capabilities on the switch, the IIR easily performs customer-specific routing. Through sophisticated logic control combined with access to customer-specific databases, the IIR increases productivity and service by allowing customer-specific routing. Customer-specific routing can combine information such as ANI, customer-entered digits, or the VDN from which the caller is being routed to make determinations about the routing destination of the caller. For example, when the IIR receives the adjunct route request, it also receives the TSAPI route request message containing all pertinent information about the caller including ANI, originating VDN (DNIS), user-entered digits (DTMF collected), and many other fields. The IIR then uses this information to provide a database lookup and an eventual route based upon the logic in the IIR script. The service and efficiency possibilities become almost limitless with this intelligent adjunct router. Consider the following scenario where the routing of the caller is determined by multiple factors in a specified order of priority. A call center manager needs to provide three levels of service for the bank card customers. All bank card customers have been classified into three membership categories including Platinum, Gold, and Standard. The customer classification, along with the customers home phone, business phone, account number, current balance, account limit, and other information are stored in the IIR customer database. The call center manager designs multiple service queues for the different customer classification to provide the shortest waits along with the most experienced Customer Service Representatives (CSRs) to the Platinum, while the standard customers receive the longest queue times and least experienced representatives. The switch sends all service calls to the IIR, The IIR then performs a lookup on the ANI information. If it finds a match, it determines the customer classification and returns the route for the appropriate agent queue. If it does not find a match, the IIR performs a RouteMore command that sends the call back to the switch for collection of account number digits. Then, based upon these digits, the IIR performs a lookup, matches the customer classification, and routes the call to the correct agent queue. Through this very simple case, the call center has transparently provided differentiated service without having to manage, publish, and maintain updates on different marketing numbers for different classes of service. At this point, the call center administrator might decide to provide continuity to its Platinum members by always queuing them to a specific customer service agent, if available, while a customer related problem maintains an open state. The IIR can then match the service, determine Platinum, and then route the call to a specific agent, based upon dynamic updates made by the customer service agents. The IIR can determine not only if a specific agent is logged in, but also determine whether the agent is currently on an active call. By using combinations of priority and agent skills, the IIR could queue Platinum callers to a specific agent for preferential treatment. The routing possibilities are extraordinary with the use of the IIR adjunct. The remainder of this chapter will explain how to develop an IIR script instead of the logical application. Scripting constructs, control flow, program structure, and script language reference will provide you with the knowledge to empower your call center. Integrating IIR with the AT&T Switch The section above discussed at a high level the integration of the IIR and some possible applications. Before attempting the language constructs, you will need to examine the functional integration of the IIR with the AT&T switch. The first integration issue to consider is the component which actually controls whether the IIR is requested to determine a route: the PBX/ACD. The mechanism on the PBX/ACD which invokes the IIR is a combination of the Vector Directory Number (VDN) and call vectoring. Call vectoring is a limited "scripting" language on the switch which provides sequential handling of calls. A standard Part of the call vectoring language is the adjunct route request step. The adjunct route request step requires that the adjunct connect to the PBX/ACD via the ASAI link. In this case, a system running telephony services for the AT&T DEFINITY G3 connects to the switch and serves as the "information link" between the IIR and the switch. When the adjunct route request is encountered in the call vectoring sequence, the switch sends a Route Request Service from the switch to the IIR via the telephony server. This route request contains detailed information about the call that the IIR uses to route the call (which includes ANI, originating VDN, trunk, user-entered data [DTMF collected digits], and other information). The IIR, a client to the telephony server, receives the route request service event and associates the originating VDN with one of the IIR scripts. All of the information in the Route Request Service request is available within the IIR script to use in determining the appropriate route. The IIR also has access to a customer database using one or several of the route request fields as a key to the database (i.e., it can match ANI against the phone number in the database to determine a record match). Once the IIR has determined where to route the call, it issues a Route Select Service message back to the PBX/ACD via the telephony server. The Route Select Service message contains a destRoute field that the IIR fills in with the destination extension number (can represent VDN, agent login-id, etc.). The Route Select Service message can also be sent back with other fields used for application to application communications. The general concept is fairly simple. The AT&T switch requests a route to be performed through the adjunct route request step in call vectoring. This sends a Route Request Service message to the IIR. The IIR determines which IIR script to execute based upon the origin VDN and executes this script. The script interacts with the customer database, applies logic to the information, and determines a route destination. This information is placed into the Route Select Service message which returns to the call vector awaiting routing direction. The logic within the IIR script varies with each script, but the same basic process exists in each script. The following sections detail the actual functions used to perform these operations, along with details on all logic capabilities available in the IIR script language. Using Operators and Expressions This section explains operators and expressions of the IIR script language. Operators include arithmetic, logical (comparison), assignment operators, and others. Expressions include variable declarations, assignment expressions, and general expressions. The sections below explain how operators and expressions interact. Variables (Declaration, Usage) Variables fall into two classifications in the IIR scripting language: local and global. You must define all variables before referencing them in the script. Normally, you declare the variables near the top of a script, although you can declare them just before the section where they are used. Local variables require the keyword local before the name of the variable. All local variables are variant in nature: they can contain either numeric (integer or float) or string data. The information associated with a variable depends upon the type of data assigned to the variable. Normally, the assignment is to a numeric or string valued returned from one of the IIR functions. Local variables are created for each script execution and only exist throughout the execution of the script. Future invocations of the same script for a different call will reinitialize variables to default values. Local variables can be declared one per line, or can be combined on a single line within the script as shown by Example 5. EXAMPLE 5
local varOne
local varTwo
local varThree
local varOne, varTwo, varThree
Variable names can consist of up to 32 characters, and can have a combination of numeric and alpha characters and mixed case. Good programming practice dictates comments for each variable or set of variables. Comments can exist on the same line as the declaration, and each is prefaced with a `#` (pound) sign. The value of a local variable cannot be referenced until it has been assigned a value within the script as shown by Example 6. EXAMPLE 6
local varOne #This is the first variable
in the script
local varTwo #This is the second
variable, used for string
manipulation
local varThree #This is the third
variable . . .
Global variables are IIR specific variables that can be referenced or set in the script. These variables normally pass system information into the script (such as the script name, script execution id, or logging level for the particular script). The global variables are not global between scripts, but instead apply to the instance of the script being executed. In addition, no global variables other than those defined by the system can be declared. In other words, the global definition only provides access to pre-existing system global variables and is not a declaration of a new global variable. Global variables are defined in the script by prefacing the variable name with the keyword global as shown by Example 7. EXAMPLE 7
global g_nICRLLogLevel # Global variable
to control logging
level from this
script
global $0, $1 # $0 is the name
of the script
being executed
# $1 is the
telephony event
hande used to
obtain the call
information
NOTE:
Global variables `$0` and `$1` are necessary for obtaining the route
request information for all telephony functions. These global variables
should be, as a practice, exposed in all scripts by declaring them as
shown above.
Simulating Constants with Variables This scripting language does not provide true constants, although good programming practice defines at the top of the script the local variables that would normally be set as constants for ease in maintenance. The following examples of Example 8 show variables declared and then assigned to be used as constants throughout the application. Note that the variables have been declared in all capitals, which is not necessary but allows for differentiation throughout the script. EXAMPLE 8
local RET_OK # Valid return from all
but handle allocations
of 0
local DEFAULT_RTE # Default route to send
caller to
local AFTERHR_RTE # After hours default
route
RET_OK=0
DEFAULT_RTE=2999
AFTERHR_RTE=3999
By defining these values at the top of the script, you can easily modify these values in a single location, even if you reference them many times in the script. This practice is particularly useful in setting up default routes that might change on an infrequent basis. Arithmetic Operators The binary arithmetic operators are (+, -, *, /). You can apply these operators to any numeric variables in the script, basing the result upon whether the arguments are integers or float. If either variable being operated on is float, the result is a float. If both variables are integer in type, the result is integer. You may combine integer and float variables in arithmetic operations without casting. The following Example 9 shows examples of code and the result: EXAMPLE 9
local numOne, numTwo, result # declare
variables for math
ops
numOne = 4.8
numTwo = 2
result = numOne/numTwo <result = 2.4>
result = numTwo * numTwo <result = 4>
result = numOne - (numTwo * numTwo) <result = 0.8>
Relational and Logical Operators The following relational operators in Table 9 can compare numeric as well as string data.
TABLE 9
"==" comparison of equal
"<>" comparison of does not equal
"<" comparison of less than
">" comparison of greater than
"<=" comparison of less than or equal to
">=" comparison of greater than or equal to
The logical operators for forming expresssions are shown by Table 10:
TABLE 10
"Not" "And" "Or"
Some legal combinations of the above in an `if` statement are shown by Example 10: EXAMPLE 10 # If varOne is less than varTwo and varOne is not zero if ((varOne <var Two) And (varOne <>0)) then . . . if ((varone <varTwo) And (Not varOne)) then . . . Assignment Operators and Expressions The only valid assignment operator is the "=" (single equal sign). This assignment operator can be used to assign numeric or string values to any variable. For example, the following assignments in Example 11 are all valid: EXAMPLE 11
local variantVar
variantVar = 2
variantVar = 3.0
variantVar = "Eric"
The variable contains the last value assigned to it. The expressions to the right of the "=" assignment operator can be complex and can also evaluate to a binary value. In this scripting language, binary values are stored as integers with `1` as true, `0` as false. See Example 12. EXAMPLE 12
local varOne, varTwo, result
varOne = 10
varTwo = 5
result = ((varOne/varTwo) == 2)
println "Result is = "+ result <would print
"Result is =
1">
The following Example 13 shows the precedence order from top (highest) to bottom (lowest) of the expression operators. EXA | ||||||