Avaya™ Interaction Center
Release 6.0
Electronic Data Unit Server Programmer’s
Guide
DXX-1016-02
Issue 1.0
June 2002
2002, Avaya Inc. All Rights Reserved Notice
Every effort was made to ensure that the information in this book was complete and accurate at the time of printing. However, information is subject to change.
Preventing Toll Fraud
“Toll fraud” is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or working on your company's behalf). Be aware that there may be a risk of toll fraud associated with your system and that, if toll fraud occurs, it can result in substantial additional charges for your telecommu-nications services.
Avaya Fraud Intervention
If you suspect that you are being victimized by toll fraud and you need technical support or assistance, call Technical Service Center Toll Fraud Intervention Hotline at +1 800 643 2353.
Providing Telecommunications Security
Telecommunications security (of voice, data, and/or video communications) is the prevention of any type of intrusion to (that is, either unauthorized or mali-cious access to or use of your company's telecommunications equipment) by some party.
Your company's “telecommunications equipment” includes both this Avaya product and any other voice/data/video equipment that could be accessed via this Avaya product (that is, “networked equipment”).
An “outside party” is anyone who is not a corporate employee, agent, subcon-tractor, or working on your company's behalf. Whereas, a “malicious party” is anyone (including someone who may be otherwise authorized) who accesses your telecommunications equipment with either malicious or mischievous intent.
Such intrusions may be either to/through synchronous (time-multiplexed and/or circuit-based) or asynchronous (character-, message-, or packet-based) equip-ment or interfaces for reasons of:
• Utilization (of capabilities special to the accessed equipment) • Theft (such as, of intellectual property, financial assets, or toll-facility
access)
• Eavesdropping (privacy invasions to humans)
• Mischief (troubling, but apparently innocuous, tampering)
• Harm (such as harmful tampering, data loss or alteration, regardless of motive or intent)
Be aware that there may be a risk of unauthorized intrusions associated with your system and/or its networked equipment. Also realize that, if such an intru-sion should occur, it could result in a variety of losses to your company (includ-ing but not limited to, human/data privacy, intellectual property, material assets, financial resources, labor costs, and/or legal costs).
Your Responsibility for Your Company's Telecommunications Security
The final responsibility for securing both this system and its networked equip-ment rests with you - an Avaya customer's system administrator, your telecom-munications peers, and your managers. Base the fulfillment of your
responsibility on acquired knowledge and resources from a variety of sources including but not limited to:
• Installation documents
• System administration documents • Security documents
• Hardware-/software-based security tools • Shared information between you and your peers • Telecommunications security experts
To prevent intrusions to your telecommunications equipment, you and your peers should carefully program and configure your:
• Avaya-provided telecommunications systems and their interfaces • Avaya-provided software applications, as well as their underlying
hardware/software platforms and interfaces
• Any other equipment networked to your Avaya products. Avaya National Customer Care Center
Avaya provides a telephone number for you to use to report problems or to ask questions about your contact center. The support telephone number is 1-800-242-2121.
Ordering Information Avaya Publications Center Voice: +1 800 457 1235 International Voice: 410 568 3680 Fax: +1 800 457 1764
International Fax: 410 891 0207 Email: [email protected]
Write: GlobalWare Solutions Attention: Avaya Account Manager 200 Ward Hill Avenue
Haverhill, MA 01835 USA
Order: Document No. DXX-1016-02, Issue 1.0, June 2002 To order product documentation online, go to
http://www.avayadocs.com, click on Online Services, and select the appropri-ate product group.
Warranty
Avaya Inc. provides a limited warranty on this product. Refer to the “Limited use Software License Agreement” provided with your package.
Avaya Web Page
http://www.avaya.com
Trademarks
Avaya, Conversant, CustomerQ, Definity, DefinityOne, Nabnasset, Quintus, and WebQ are registered trademarks or trademarks of Avaya Inc. in the United States or other countries or both.
Portions of Avaya Interaction Center include technology used under license as listed below, and are copyright of the respective companies and/or their licen-sors:
ActivePerl is a trademark of ActiveState Tool Corp. This product includes software developed by the Apache Software Foundation
(http://www.apache.org/). Cognos, Impromptu and Powerplay are registered trademarks of Cognos Incorporated. YACC++ is a registered trademark of Compiler Resources, Inc. APEX, ComponentOne, VideoSoft, True DBGrid, VSVIEW, SizerOne, VS-OCX, VSFlexGrid, VSFORUM, VSREPORTS, VSDOCX, VSSPELL, and TrueDBList are either registered trademarks or trademarks of ComponentOne LLC. CT Connect, Dialogic, Intel, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Hummingbird is a registered trademark of Hummingbird, Ltd. SearchServer is a trademark of Hummingbird, Ltd. RISC System/6000 and DirectTalk/2 are trademarks of International Business Machines Corporation in the United States or other countries or both. IBM, OS/2, AS/400, CICS, WebSphere, CT, VisualAge, and DirectTalk are registered trademarks of International Business Machines Corporation in the United States or other countries or both. Lotus and Lotus Sametime are trademarks or registered trademarks of Lotus Development Corporation and/or IBM Corporation in the United States, other countries, or both. VisualX is a registered trademark of Intergroup Technologies, Inc. ActiveX, Visio, Internet Explorer, Windows, Windows NT, Windows 2000, Win32s, SQL Server, Visual Basic, Visual C++, Outlook, and FrontPage are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. TimesTen is a registered trademark of TimesTen Performance Software. Oracle is a registered trademark, and Oracle8i and
Oracle® SQL/Services are trademarks or registered trademarks of Oracle Corporation. Rogue Wave and .h++ are registered trademarks of Rogue Wave Software Inc. SourcePro is a trademark of Rogue Wave Software, Inc. Siebel is a trademark of Siebel Systems, Inc. BasicScript is a registered trademark of Summit Software Company. Sun, iPlanet, Java, Solaris JRE, J2EE, JavaServer Pages, and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. SPARC is a registered trademark of SPARC International, Inc. Products bearing SPARC trademarks are based on an architecture devel-oped by Sun Microsystems, Inc. In3D is a trademark of Visual Insights, Inc. InstallShield® is a registered trademark and service mark of InstallShield Software Corporation in the United States and/or other countries. ORBacus is a trademark of IONA Technologies PLC. Formula One is a licensed trademark and Tidestone Technologies, Inc. Visual Components, First Impression, and VisualSpeller are registered trademarks of Tidestone Technologies, Inc. JRun is a trademark of Macromedia, Inc. in the United States and/or other countries. Intervoice is a registered trademark of Intervoice-Brite, Inc. UNIX is a registered trademark of The Open Group in the United States and other countries. Acrobat is a registered trademark of Adobe Systems.
3
B
EFORE
Y
OU
B
EGIN
. . . 7
1
O
VERVIEW
OF
THE
EDU S
ERVER
. . . 11
EDU Server Overview . . . 11
Interaction with the IC Repository . . . 12
Interaction with the DUStore Server . . . 12
Cooperation of EDU Servers . . . 12
2
T
HE
E
LECTRONIC
D
ATA
U
NIT
. . . 15
Definition of an EDU . . . 15
The EDU Lifecycle . . . 15
EDU Creation . . . 15
EDU Activity . . . 15
EDU Termination . . . 16
Listing Active EDUs . . . 16
The EDUID . . . 17
The EDU Data Table . . . 18
Pre-defined Data Names . . . 19
Value History . . . 21
Containers . . . 21
Container Names and Special Tokens . . . 21
Limitations of Container Syntax . . . 23
The Agent Container . . . 23
3
E
VENT
M
ONITORING
. . . 25
EDU Event Monitoring . . . 25
Starting and Stopping Event Monitoring . . . 26
Setting Event Monitoring Criteria . . . 27
Monitoring Criteria: Syntax . . . 27
Contents
Relational Operators . . . 28
Boolean Operators . . . 29
Monitoring Criteria: Wildcards . . . 29
Monitoring Criteria: Examples . . . 31
4
A
LARMS
. . . 33
5
EDU S
ERVER
C
ONFIGURATION
. . . 35
System Considerations . . . 35
EDU Server Alias Name . . . 35
Effect of Configuration on EDU Termination . . . 35
Configuration Parameters . . . 36
The Filter dialog box . . . 41
6
C
APTURING
THE
EDU E
VENT
S
TREAM
. . . 43
Capturing Events . . . 43
EDUDATA Server Design . . . 43
EDUDATA in a WAN Environment . . . 44
Configuration Parameters . . . 44
Alarms . . . 46
7
IDL S
PECIFICATION
. . . 47
8
EDU S
ERVER
M
ETHODS
. . . 49
Exception Information . . . 49
Routing Requests . . . 50
Resurrecting EDUs . . . 50
EDU Method Overview . . . 50
9
T
HE
DUS
TORE
S
ERVER
. . . 75
Overview . . . 75
The DUStore Server Database . . . 75
Issue 1.0 June 2002 5 Contents
EDU Behavior . . . 76
DUStore Server Configuration . . . 77
DU Store Processing . . . 79
DU Store Processing for Idle DU Records . . . 79
DUStore Server Processing as a Backup of DU Data . . . 80
Temporarily storing EDUIDs in the DUStore . . . 81
Difference between the EDUID stored in Report Server and DUStore . . . 82
Removing Records from the DUStore Database Tables . . . 82
Troubleshooting and Testing DU records and the DU Store . . . 83
Parameter Setting Example . . . 84
DUStore Server Method Overview . . . 87
A
VDU.C
REATE
E
XAMPLE
. . . 89
7
B
EFORE
Y
OU
B
EGIN
Typographical Conventions
This guide uses the following font conventions:
Notes, Tips, and Cautions
Note: A note calls attention to important information.
Tip: A tip offers additional how-to advice.
Caution: A caution points out actions that may lead to data loss or other serious problems.
Contacting Technical Support
If you are having trouble using Avaya software, you should:
1 Retry the action. Carefully follow the instructions in written or online documentation.
2 Check the documentation that came with your hardware for maintenance or hardware-related issues.
Font Type Meaning
code This font signifies commands, information that you enter into the computer, or information contained in a file on your computer.
italics This font is used to add emphasis to important words and for references to other chapter names and manual titles.
It also indicates variables in a command string.
jump Blue text in online documents indicates a hypertext jump to related information. To view the related material, click on the blue text.
3 Note the sequence of events that led to the problem and the exact messages displayed. Have the Avaya documentation available.
4 If you continue to have a problem, contact Avaya Technical Support by:
Logging in to the Avaya Technical Support Web site
(http://www.avaya.com/support/qq).
Calling or faxing one of the following numbers from 8:30 a.m. to 8:30 p.m. (Eastern
Standard Time), Monday through Friday (excluding holidays):
Toll free in the U.S. only: 1-888-TECH-SPT (1-888-832-4778) Direct line for international and domestic calls: 512-425-2201 Direct line for faxes: 512-719-8225
Sending email with your question or problem to [email protected]. You may be
asked to email one or more files to Technical Support for analysis of your application and its environment.
Note: If you have difficulty reaching Avaya Technical Support through the above URL or email address, please go to www.avaya.com for further information.
Product Documentation
Most Avaya product documentation is available in both printed and online form. However, some reference material is available only online, and certain information is available only in printed form. A PDF document with detailed information about all of the documentation for the Avaya Interaction Center is included in the Doc directory on the product CD-ROM. This PDF document is also included on the separate documentation CD-ROM.
Readme File
The Readme file is an HTML file included on the Avaya Interaction Center software CD-ROM. This file contains important information that was collected too late for inclusion in the printed documentation. The Readme file can include installation instructions, system requirements, information on new product features and enhancements, suggested work-arounds to known problems, and other information critical to successfully installing and using your Avaya software. You may also receive a printed Addendum to the Readme, containing similar information
uncovered after the manufacture of the product CD-ROM. You should review the Readme file and the Readme Addendum before you install your new Avaya software.
Electronic Documentation
The electronic documentation (in PDF or HTML format) for each Avaya Interaction Center product is installed automatically with the program. Electronic documentation for the entire Avaya product suite is included on the product CD-ROM and the documentation CD-ROM.
Educational Services
Issue 1.0 June 2002 9
Printed Documentation
You can purchase printed copies of these manuals separately. For details, see on the back of this manual’s title page.
License to Print the Electronic Documentation
Online copies of documentation are included on the CD-ROM that accompanies every software release. An Avaya customer who has licensed software (a “Licensee”) is entitled to make this online documentation available on an internal network or “intranet” solely for the Licensee's use for internal business purposes. Licensees are granted the right to print the documentation
corresponding to the software they have purchased solely for such purposes.
Right-To-Print License Terms
Documents must be printed “as-is” from the provided online versions. Making changes to documents is not permitted. Documents may be printed only by any employee or contractor of Licensee that has been given access to the online documentation versions solely for Licensee's internal business purposes and subject to all applicable license agreements with Avaya. Both online and printed versions of the documents may not be distributed outside of Licensee enterprise or used as part of commercial time-sharing, rental, outsourcing, or service bureau use, or to train persons other than Licensee's employees and contractors for Licensee's internal business purposes, unless previously agreed to in writing by Avaya. If Licensee reproduces copies of printed
documents for Licensee's internal business purposes, then these copies should be marked “For internal use only within <Licensee> only.” on the first page or cover (where <Licensee> is the name of Licensee). Licensee must fully and faithfully reproduce any proprietary notices contained in the documentation. The copyrights to all documentation provided by Avaya are owned by Avaya and its licensors. By printing any copy of online documentation Licensee indicates its acceptance of these terms and conditions. This license only governs terms and conditions of printing online documentation. Please reference the appropriate license agreement for terms and conditions applicable to any other use, reproduction, modification, distribution or display of Avaya software and documentation.
Educational Services
Avaya University provides excellent training courses on a variety of topics. For the latest course descriptions, schedules, and online registration, you can get in touch with us:
Through the web at http://www.avaya-learning.com
Over the telephone at 800-288-5327 (within the U.S.) +001 303-406-6089 (outside of the U.S.) Through email at [email protected]
11
C
HAPTER
1
O
VERVIEW
OF
THE
EDU S
ERVER
This chapter provides an overview of the EDU Server and describes its interactions with the Customer Interaction (CI) Repository and the DUStore Server.
The function of the Voice Data Unit (VDU) Server and the VDUs that it creates has evolved to accommodate multiple types of media channels, and the name of the server has been changed to reflect this evolution. The server that was previously named the Voice Data Unit (VDU) Server is now called the Electronic Data Unit Server, and the data unit it creates has become the Electronic Data Unit (EDU). The server interface name has not yet been modified to reflect this change, so some of the filenames and program code still contain references to VDU. However, this manual uses the term EDU. The terms EDU and VDU are interchangeable.
EDU Server Overview
To successfully track a customer contact, such as a telephone call or an e-mail message, each contact must be associated with a unique detail record. That record must stay associated with the contact as it moves through the contact center system. Any system process wanting access to the contact or its associated data must explicitly reference this record. In the Avaya Interaction Center (Avaya IC), that unique detail record is the Electronic Data Unit (EDU).
An EDU provides the mechanism to coordinate telecommunication, electronic communication and data processing. Each EDU identifies a specific contact. It collects both system and customer service information from the moment the contact enters the Avaya IC system until the moment it is terminated by the service agent. When the contact is terminated, the information recorded in the EDU can be archived.
The EDU Server creates, stores, and manages EDUs. It creates EDUs in response to demands from Contact Engine Servers and client applications. The EDU Server manages an EDU throughout its lifecycle. It stores open EDUs, records events, and provides services that enable clients to interact with a contact.
When a contact ends, the server terminates its EDU. If you are using the DUStore Server or the IC Repository, or both, all data, including contact wrap-up information, is passed to the database.
Chapter 1 Overview of the EDU Server
Interaction with the IC Repository
The IC Repository archives terminated EDUs for long-term storage in a relational database. The QDecision reporting package draws on this information to generate reports.
Even though the entire contents of the EDU are archived in IC Repository, when an EDU has been archived it cannot be reconstructed and re-activated from the repository.
You can specify the types of EDU events that are saved with the methods
SetDefaultHistoryFilter() or SetHistoryFilter() methods (described in Chapter 8) and with the filter and vduhskeepname configuration parameters (described in Chapter 5).
Interaction with the DUStore Server
The DUStore Server maintains a database of inactive EDUs. This EDU data can be used in two ways:
Reactivating EDUs–EDUs can be brought back from disk to memory for reading or modifying. Recalling history–Data from retired EDUs can be used to provide additional information to an
agent and can be used to assist in call routing, without resurrecting them into EDU Server memory.
Refer to Chapter 9 of this manual for a description of the DUStore Server.
Cooperation of EDU Servers
When a new EDU Server is added to Avaya IC, the existing EDU Servers must be made aware of the new server. Refer to IC Administration Volume 1: Servers & Domainsfor information on updating servers.
When the EDU Servers have been made aware of each other, they can make requests of each other. This is most significant in the area of the Assign method. When a client assigns to an EDU Server, the Assign is relayed to other EDU Servers, and they watch for EDUs that match the client’s Assign criteria as well. This makes Assign a relatively expensive operation, and clients should be designed so they only need to Assign once to specify the EDUs in which they are interested. Assigning to multiple EDU Servers is unnecessary and causes numerous problems.
Every EDU identifies the server that created it and the time at which it was created. When a client requests access to an EDU, the EDU Server to which the client is assigned acts as a proxy to the EDU Server originating the EDU.
Cooperation of EDU Servers
Issue 1.0 June 2002 13
EDU Servers can also cooperate to search, in parallel, any number of DUStore Servers, making it easy to find particular EDUs no matter where they are.
Caution: When the EDU Server is shut down improperly, it is possible to lose data that has not yet been written to the DUStore. It is important, therefore, to ways follow proper shutdown procedures. Please refer to IC Administration Volume 1: Servers & Domains and IC Installation and Configuration Guide for more information.
15
C
HAPTER
2
T
HE
E
LECTRONIC
D
ATA
U
NIT
This chapter describes the Electronic Data Unit (EDU).
Definition of an EDU
Each telephone call, web chat, or e-mail message arriving at a contact center triggers the creation of a permanent detail record called the Electronic Data Unit (EDU). The EDU contains the information that enables Avaya IC to coordinate contact activities on the network.
In addition to uniquely identifying each call, the EDU collates information about activity
performed on behalf of the call and updates that information as the call traverses the service center. A typical EDU might contain the time the call arrived, transfers between agents, the time the call concluded, as well as the customer service actions performed by the agent.
The EDU Lifecycle
There are three stages in the lifecycle of an EDU: creation, activity, and termination. Each stage is discussed in this section.
EDU Creation
Every contact must have a corresponding EDU. Whenever an inbound call arrives at a telephone on the PBX system, a web chat or an e-mail message arrives, or a contact center agent dials out, the Telephony Server or Chat Server or Email Management Server invokes the VDU.Create() method. In response, the EDU Server creates an EDU and returns its unique identifier (EDUID) by invoking VDU.Create.Response() to the corresponding contact engine server.
EDU Activity
The EDU is a real-time detail record that collects strings of text from multiple sources. During its life, the dual job of the EDU is to collect information ({name, value} data couples) entered by the contact center agent or automated software, and to notify assigned clients of changes to the EDU.
Chapter 2 The Electronic Data Unit
Each EDU has a unique identifier, its EDUID. Any application that wants to interact with an EDU, or with its associated telephone call, web chat, or e-mail message, has to request it by EDUID. Upon request, the server passes the EDUID out to other processes, thus enabling applications to ask for access to the EDU and the telephone call, web chat, or e-mail message. Through this mechanism, the data and contact logically associated with the EDU can be routed to other software processes in the service center network. Each contact is uniquely identified and that identifier stays with the contact throughout its sojourn through the system, allowing Avaya IC to coordinate contact and data processing.
The EDU Server also honors requests to watch for EDUs that contain certain values. If any EDU matches the criteria, the EDU Server issues event messages (which contain the EDUID) to interested clients. (Refer to “EDU Event Monitoring,” on page 25.)
Typically, clients want to examine EDU contents, modify EDU values, receive event notifications, transfer an EDU, or terminate an EDU. These activities are supported through method invocations. For example, a client could invoke one of the Get methods (GetOneValue(), GetSomeValues(), and so on) to ask the EDU Server to return values in an EDU. Chapter 8, EDU Server Methods, describes the methods supporting these activities.
The data belonging to an EDU is modified under several circumstances, such as when clients invoke the Set methods to incorporate data into an EDU.
EDU Termination
When a contact ends, generally so does the need for an EDU. The contact center agent may need to enter wrap up information in the contact record, but afterward the EDU should be closed. The data in the terminated EDU can, optionally, be archived in the IC Repository and DUStore Server database, and the EDU is purged from the EDU Server.
Before an EDU can be closed, the EDU Server must first verify that all processes are done with it. For each EDU, the EDU Server maintains an internal list of processes that have read, transferred, or modified the EDU. Any process that invokes a method using the EDUID belonging to an EDU is added to the list. When a client invokes the method VDU.Terminate(), the client's name is removed from the list. When the list is empty, the EDU can be terminated.
Safeguards are built into the EDU Server to terminate “suspicious” EDUs, in other words, those that appear to have been lost. Any EDU that has been idle for an extended period (thirty minutes, by default) is timed-out and automatically terminated, if persistence enable is not selected. The idle time parameter can be changed with the Idle Time configuration parameter, as described in Chapter 5.
Refer to Chapter 5 for a discussion of how various configuration parameters affect the timing of EDU termination.
Listing Active EDUs
The EDUID
Issue 1.0 June 2002 17
To use this utility:
1 Copy listvdu.exe from the QeSxx/bin directory to the directory in which the vesp.imp and vespidl.pk files are located, which is /etc by default.
2 Create an account in IC Manager named vesp if one does not already exist.
Click the Agent tab and select the Agent…New menu option.
Define the name of the agent, the login Id, the group (either Admin or Default is
acceptable), and the domain.
Click Apply.
3 From the vesp account, enter:
listvdu -iinterface -uusername -ppassword
-i interface to use (often ADU or VDU, or an alias or uuid of such a server) -u user name to log in as (often Admin)
-p password of user
No space between -x and the text that follows. Example:
listadu -iBostonADU -uAdmin -pDaphnie
There are defaults for all of these, but if a login error occurs, always specify -u and -p.
The output contains a list of EDUs, listed by EDUID, and the interested clients for each EDU. Clients are identified by session ID, with the IP and port broken out. Resurrected EDUs are included in the list.
The EDUID
When an EDU is created, it is automatically given an identification number (EDUID) that uniquely defines the contact. The EDUID is a 32 byte hexadecimal string partially composed of the time and date of creation of the EDU, as well as its progenitor–the software process and machine that created it.
The structure of an EDUID is illustrated in the following example. EDUID = 30f4216300000000780000261f430002
Bytes Example Contents Description
0–7 30f42163 Timestamp. Hex representation of number of
seconds since 1–1–1970.
8–11 0000 Hex representation of uniqueness value
Chapter 2 The Electronic Data Unit
A combination of the IP and port identifies which EDU Server is the progenitor of this EDU.
The EDU Data Table
EDU data consists of series of sequenced {name, value} couples that represent information about a contact. For example, the name/value pair {ani,8008863244} represents the telephone number of an incoming call. The field name “ani” is the name data element and “8008863244” is the value that is assigned to the field. Applications gain access to data by references to field names.
Names are restricted to non-empty strings of less than 35 characters. Container names may contain more than 35 characters. Refer to “Container Names and Special Tokens,” on page 21 for
information on container names. Names may contain letters (a..z, A..Z), digits (0..9), and the underscore character (_). Data element names are case sensitive. “Foo”, “foo”, and “FOO” refer to three different data elements.
The set of field names that Avaya IC software reserves for its own system use are listed on page 19. Although they are not strictly reserved words in the technical sense, to use these field names for anything other than their pre-defined purposes could result in conflicts between applications.
Values, the pieces of data that applications assign to a field, are strings that may contain from 0 to 4096 characters. Although longer strings are technically permissible, they are strongly
discouraged. Any character except the null character (′\0′) is legal. Typical EDUs contain approximately 100 values, but there is no fixed limit on size except system memory. Be advised that storing many large EDUs can adversely affect overall system performance.
The EDU Server sets certain name/value data pairs, such as the EDUID. Other name/value data pairs are written into the EDU by the customer’s application. Because the EDU can accept input from a variety of sources, data could come from the PBX, other servers, or the agent's application. Typical entries might include the agent's login ID, the contact’s start time, and service codes. Changes to all data values are recorded, including information on who made the change and when the change was made.
16–23 78000026 Hex representation of the IP address
24–27 1f43 Hex representation of a port
28–31 0002 Reserved
Pre-defined Data Names
Issue 1.0 June 2002 19
Pre-defined Data Names
The following pre-defined field names can be used in client applications, however they should be treated just like reserved words with specific meanings. Do not use these names for other than these explicit purposes! Doing otherwise could result in misinterpretation. These data names are used by the EDU Server and several other Avaya IC components. Some are read-only values to clients.
Field name Description
ani Automatic Number Identification. Caller’s 10-digit telephone number. call_ref_id The call number that the switch uses to distinguish one call from other
calls, however, it is the EDUID that the EDU uses to distinguish one call from another.
createtime The date and time the EDU was created in yyyy-mm-dd hh:mm:ss format. createtime_t The time_t of the EDU creation.
dnis Dialed Number Identification Service. Call recipient’s telephone number or extension.
duration The difference, in seconds, between createtime and endtime. This field is not meaningful if the EDU was stored and restored, or if the EDU was removed due to idleness. Note that this value is the length of time the EDU was in memory, not the length of the call.
endreason Set to “normal” for a normal termination.
endtime The time of the last Terminate method to the EDU or equivalent such as removal due to idleness.
loginid The contact center agent's Avaya IC name.
last termination The identity of the last user of the Terminate method, used as debugging information.
modifier This field identifies the login id or uuid of the user who caused the event. It is inserted into each event that is sent to reporting packages.
owner The loginid or UUID of the application that created the EDUID or last used the Transfer/SetTransfer methods. (historical).
persistance The date and time that the EDU was last stored in the DUStore Server. persistance.delete
date
The field is used to modify purging behavior of the DUStore Server.
suspend The reason that the EDU was last removed from server memory. This can be any one of the following:
normal–all involved parties have suspended use of the EDU. expired–removed from memory due to idleness.
exit–server was shut down.
overflow–removed from memory for other EDUs. forced–removed by ForceTerminate method.
Chapter 2 The Electronic Data Unit
termination A string representing the reason for the termination of the EDU:
normal–all users are done with the EDU and the timers that hold it
in memory have expired.
overflow–the server has been configured to hold a maximum
number of EDUs and it has been exceeded. The oldest EDU is killed to make room.
expired–the EDU has been idle too long and is terminated even
though there are still interested parties.
exit–the server is being shut down.
time Not set. This field is inserted into each event that is set to reporting packages and is reserved for that purpose.
transfercount The number of times Transfer/SetAndTransfer was used on this EDU. (historical)
vdu_id The unique ID of the EDU.
L_ucid Universal Call ID as implemented for versions 6 and beyond of the Avaya (formerly Lucent) Definity switch, CallVisor version 6.0.4.
iidigits The digits found in the “originating line information” field supplied by the switch. Used for the Avaya switch only.
00–Identified line, no special treatment 01–Multiparty, ANI cannot be provided 02–ANI failure
06–Hotel/Motel DN without room ID 07–Special operator handling required 20–AIOD, listed DN of PBX sent
23–Coin or Non-Coin, line status unknown 24–800 Service Call
27–Coin Call
29–Prison/Inmate Service 34–Telco Operator Handled Call 52–OutWATS
60–TRS, Station Paid 61–Type 1 Cellular 62–Type 2 Cellular 63–Roamer Cellular
66–TRS, Hotel/Motel billed to room 67–TRS, Restricted line
70–Private paystation
93–Virtual Private Network call
lai_dnis This field is supported on the legacy Definity code only. This is the phone number the call is currently routed to. The number dialed by the caller arrives as DNIS, and it is stored in the eDU under primary_dnis. The number from which the caller dialed is stored under primary_ani. Both fields survive multi-site-hetero-switch transfers. They are are written once when the very first call center receives the call for the very first time, and are not updated.
Value History
Issue 1.0 June 2002 21
Value History
Generally, a given name in an EDU is set once and is not modified again. However, it may be useful to maintain a history of various values that a given name has had, as well as who set them and when they were set.
The ability to have a single name represent a list of values and remember when they were set (and by whom) can be a significant advantage in some kinds of applications, especially those recording the state of something that varies over time. Setting the same name with new values, and relying on the EDU Server to remember previous values and timestamps, is generally much more efficient than using a container with the autoincrement token (+) (described in “Container Names and Special Tokens,” on page 21) to gain the same sort of effect.
Note: The GetValueHistory() method fetches the previous history of a value. All the other methods (and the Assign criteria evaluations) always deal with the most recently set value for a given name. They ignore the past.
The value history is maintained only in the DUStore database. It is not retained in the IC Repository.
Containers
A container is a grouping of values under a common name. Containers are trees of data within an EDU. Some standard containers are maintained by Avaya IC. You can create additional containers to suit your application.
Methods exist to return an entire container or subcontainer. For example, assuming use of an Agent container, you could see all the data set by the second agent to handle the contact by using the GetSubTree() method on the EDUID and asking for “Agent.2”. With the exception of
GetSubTree() and DeleteSubTree() methods, there are no special container methods. Any method that involves getting or setting data can use container-based names.
Container Names and Special Tokens
You can specify container names or you can allow the EDU Server to generate container names for you based on your instructions. A number of special tokens are available for use when
constructing container names. These tokens expand into appropriate strings and automate many of the steps involved in using containers.
Container names have multiple parts (two or more) separated by dots. Each part, called a name token, is limited to 1–35 alphanumeric characters (underscore is also permitted), with entirely numeric name tokens reserved for use with the special tokens described below. Up to 31 dots (32 tokens total) are permitted in a container name. Note that processor usage for container names is low, but is proportional to the number of tokens in the name.
Chapter 2 The Electronic Data Unit
There are four special tokens available for use with container names:
+ The simplest special token is +. This expands into a numeric token that is greater than the last numeric token that was created with a + in that position for that container in that EDU. The first time it is used, it generates a 1. Any client that specifies a name of “agent.+”, is turned into “agent1” by the EDU Server. The next time a client uses “agent.+” in that EDU, it expands into “agent.2”. This makes it very easy to create subtrees within a container. The name generated in this way will never be the name of an existing subtree. (The gencount and padwidth configuration parameters, described in “Configuration Parameters,” on page 36, can affect subtrees created with the +
token.)
! The ! token expands into a numeric token that belongs to the client. Tokens that belong to a given client are created via a special use of the + token. Essentially, a
subcontainer created with + is assumed to belong to a caller (usually the one who created it), and the ! token will find it.
To create a subcontainer for another client, add the loginid of the client after the + token that creates it, as follows:
“agent.+jane”
Whatever number it creates, it is matched by a request for “agent.!” by client jane. If several subcontainers have been created for the same user, the ! token seeks out the highest numbered (most recently created) one. If no subcontainer has been created for the client, the use of ! generates an exception.
To find another client’s subcontainer, add the loginid of the client after the ! token: “containername.!loginid”
null The null token contains no characters. It matches the subcontainer most recently created with the + token, regardless of who it was created for or who the caller is. This is generally useful in creating and filling a subcontainer in one method call. For example, the following names given to SetValues:
“mydata.+” “mydata..age” “mydata..height”
would create a new, numbered subcontainer in mydata, and within that same subcontainer create age and height. If mydata.+ generated mydata.3, this would generate mydata.3.age and mydata.3.height.
Use of the null token should occur within the same method invocation as the use of the + token that it relates to. Otherwise, some other application might use the + token within the same container and EDU. This would change the meaning of the null token unexpectedly, unless the intent is to add data to the most recently created
subcontainer no matter who created it.
* The * token is permitted only within Assign methods and is described in “Monitoring Criteria: Wildcards,” on page 29.
Containers
Issue 1.0 June 2002 23
Limitations of Container Syntax
The first token in a container name cannot be a special token.
When a * token has been used, subsequent tokens in that container name must be either * or nonspecial tokens.
Special tokens other than * are illegal in any request that involves multiple EDUs at the same time (for example, Assign).
When a token creates a new subcontainer, subsequent tokens cannot be empty or !. No defaults or ownership has been established, so they cannot match.
Note that some methods do not permit some tokens. Most do not support * and some (GetValues and methods like it) do not (meaningfully) support +. For example, in the method invocation GetValues( “a.+.x”), the + token would be interpreted as “create the next number in the sequence,” which is not meaningful for the GetValues method.
The Agent Container
The Telephony Server creates a special container. As a contact moves between agents in a contact center, each agent may want to store information about the contact in a way that does not interfere with the next or last agent who handled the contact. To manage this, the Telephony Server creates an Agent container for each agent involved in the contact. Each agent takes a private subtree of the Agent container for the agent’s own use. The first uses the name agent.1, and creates names below it–agent.1.callduration, agent.1.reasoncode, and so on. The next uses the name agent.2 and sets that agent’s own values in that subtree–agent.2.callduration, and so on. (Refer to Telephony Server Programmer’s Guide for more information on the Agent container.)
The use of the Agent container allows clients to assign with agent.*, realizing a large resource savings over using multiple assigns.
25
C
HAPTER
3
E
VENT
M
ONITORING
This chapter describes the events sent by the EDU Server. It also explains how to assign and how to establish monitoring criteria.
EDU Event Monitoring
The EDU Server continuously monitors the contents of EDUs for changes, and reports those changes to interested clients through event messages.
Clients register their interest in EDUs by assigning themselves to the EDU Server with monitoring criteria, which is a specification describing the condition that should generate an event notice. For example, the client might request notification for every phone call originating from a specific ANI, or for every customer call handled by a particular agent. The client receives event messages about EDUs that match the specification, and continues to receive all events generated for those EDUs as long as they match the client's monitoring criteria.
The EDU Server generates seven types of events that describe changes to existing EDUs. The following table lists the events and the contents of the event messages written in the EDU and sent to monitoring clients.
Event Description Message
VDU.auRevoir When the EDU server sends the EDUs to the DUStore, it issues
"VDU.auRevoir" to the report server.
The ID of the object being send to the DUStore.
VDU.Change A modification has occurred in a monitored EDU.
All affected {name, value} couples and the EDUID.
VDU.Delete Values have been deleted from the EDU.
All deleted values.
VDU.Drop The EDU has changed and no longer
matches the assign criteria. It will no longer be monitored. If the EDU later changes so that it again meets the assign criteria, the client gets a VDU.Watch event.
The EDUID.
Chapter 3 Event Monitoring
When a client first assigns monitoring criteria to the server:
All existing EDUs are checked to see if any match the specification. All subsequently created
EDUs are checked for a match.
Any EDUs that do match the criteria are placed under watch and a VDU.Watch event message
is sent to the monitoring application.
Changes to EDUs under watch are reported to the application by a VDU.Change event.
Note: When a client has assigned to the EDU Server, the client should monitor the event data stream for the data in which it is interested, rather than invoking VDU.Get…() methods repeatedly. As values are set in the EDU, the EDU Server sends Change events to assigned clients. The timing, order, and content of the Change events depend on the components setting the values, and is therefore variable.
Starting and Stopping Event Monitoring
The EDU Server methods VDU.Assign()and VDU.Monitor() let you set up monitoring conditions, and the method VDU.Deassign() lets you revoke them.
Note: By default, a client does not receive change events for the EDU changes that it itself initiates to cut down on needless event traffic. It does receive other sorts of events, as well as event messages for changes caused by other clients. If the change causes a .Watch or .Drop event, it is reported to the client. To receive change events for the client's own changes, prefix the Assign or Monitor expression with a plus symbol (+).
For example:
[VDU.Assign("+*")]
(The asterisk (*) in the example indicates that all EDUs in the local EDU Server should be monitored, as described in “Monitoring Criteria: Syntax,” on page 27.)
Assigning to the EDU Server and monitoring an EDU does not add a client's name to the internal list of EDU-modifying clients. (This list of clients is described in “EDU Termination,” on
page 16.) Assigning allows the client to watch the activity of an EDU. The client does not have to issue a VDU.Terminate() for each EDU that is being watched.
VDU.End The EDU has been terminated. When it terminates, the server passes a VDU.End message to all monitoring applications.
All of the data elements in the EDU.
VDU.Transfer The EDU has been transferred. The new client and the EDUID. VDU.Watch The EDU matches the monitoring
criteria.
All of the data elements in the EDU.
Event Description Message
Setting Event Monitoring Criteria
Issue 1.0 June 2002 27
Setting Event Monitoring Criteria
EDUs are selected for monitoring by criteria matching. A criterion (plural: criteria) is an expression that selects some EDUs and rejects others according to a defined specification. If a criteria expression is provided as a parameter to the Assign() or Monitor() method, each name/value pair in the EDU is tested against it. If the criteria determine that a match exists, the EDU is watched. Subsequent changes are sent to the client as change events.
The following values cannot be successfully used in an Assign criteria:
Monitoring Criteria: Syntax
The general syntax of a criteria statement is:
method "name relationship value" [booleanop] "name relationship value"
For example:
VDU.assign "loginid=Joe & ani=808863244"
In the above example, the client has assigned to the EDU Server, asking it to watch for any EDU that contains these two values:
“Joe” in the field loginid originated from (800) 886-3244.
In other words, notify the client every time Joe gets a telephone call from Avaya Support.
You can construct complex statements that evaluate multiple conditions by grouping expressions together with parentheses to control the order of evaluation.
A single * character has a special meaning when used as a monitor criteria. It causes all local EDUs (those in the local EDU Server) to be watched. This is used by IC Manager and should generally be avoided by other applications, as it generates a very large amount of event traffic. Setting the monitor criteria to a null value (“”) stops monitoring.
The Assign method does not accept special tokens !, +, or the null token in container names. These tokens have specific meanings for a particular EDU and vary from one EDU to another. The Assign method has no provision for names that do not have EDU-independent meaning.
The Assign and Monitor methods contain criteria strings that allow you to use additional syntax. At the end of the string is a list of fields, called a projection list, enclosed in curly brackets where you can specify filter criteria. The list is comma separated with no spaces between the fields.
duration termination
owner (historical) transfercount
Chapter 3 Event Monitoring
For example, {specification,specification…} You can specify the type of field name in three ways:
1 A simple fieldname, such as a, b, or c.
2 A wildcard container name, such as a.* or a.*.d. The wildcard designation (*) can be used after a dot (.), at either end of the specification, or followed by a dot (.) in the specification.
3 A request to retrieve all of the fields below a specified point in a container tree, as in “a.b?”. This format collects all of the field names below the specified point in container tree. It does not collect field names at its own level or higher on the tree.
Example: +vdu_id> "" {call?,data.*,loginid}
Note: Spaces are optional after the selection criteria and before the projection list. The projection list itself is optional, but no filtering is done without one. If a projection list is used, it cannot be empty.
This assign criteria watches all EDUs in the system because all EDU IDs are longer than empty
strings.
Change events that do not reflect a change in the loginid, any matching data.*, or any
subcontainer of the call container are also suppressed.
Change events that not suppressed are trimmed to list only the names that are provided on the
projection list. The duid, time, and modifier fields are also provided.
Note: Watch and drop events are not modified and they are always sent with their full content. User events, which are very rare, would be modified as they are actually change events with a different name.
Relational Operators
Values can be compared to each other as described below. There are four permissible relational operators. In the description column, the term couple refers to a name/value pair.
Symbol Definition Description
= equal Find a couple that matches the specified name and value.
Wildcards are accepted.
< less than For a given name, find all couples with values less than the specified search value (string-based).
> greater than For a given name, find the set of couples with values greater than the specified criteria (string-based).
: exactly equal to For a given name, find a couple that exactly matches the specified value. Wildcards are not accepted.
Setting Event Monitoring Criteria
Issue 1.0 June 2002 29
The EDU Server compares the name/value data within an EDU against the criteria string one character at a time, starting with the leftmost character, until either a mismatch occurs or one field runs out of characters. Comparisons are case-sensitive. “Foo” is not the same as “foo” or “FOO”. To avoid ambiguity, enclose the specified value within double quotes (“”). Within a quoted string, (\") means quote and (\\) means backslash.
If the strings match character for character, they are equal. Strings can also be relatively compared. If one field runs out of characters without a mismatch, the relatively longer field is greater (for example, abc < abcd). If a mismatch occurs, the field containing the greater character is greater, (for example, 111 < 119). Because the comparison is string-based, not numeric, the field with the greater initial character is greater, (for example, 2 > 119).
Wildcards are permitted only with the equal (=) operator.
Boolean Operators
Boolean comparisons that return evaluations of true or false can be performed between two values. The two boolean operators are described below.
For example:
ani=508* | dnis=3315
selects all calls from the 508 area code or directed to extension 3315. Terms may also be grouped with parenthesis for more complex expressions.
Monitoring Criteria: Wildcards
Instead of specifying each individual instance of a set, you can use wildcard symbols to stand in for other values. The wildcard symbols can be used in setting criteria given the following restrictions:
Wildcard usage is restricted to the equal (=) relational operator. You cannot use wildcards with
the less than (<), greater than (>), or exactly equal to (:) operators.
Single character wildcards must have a character to match.
Symbol Definition Description
& and Both expressions must be true.
Chapter 3 Event Monitoring
Each ? symbol can stand in for one character. The * symbol can either be placed at the end of a value (a so-called value trailing wildcard), or can be entered by itself to find EDUs with an instance of any value (selects all EDUs as matching).
Container names used in an Assign can use limited wildcarding. Within an Assign, an expression like
agent.*.problem > “”
selects any EDU in which any subcontainer in agent having a name of problem has nonempty text. Note that the ! token is not available in an Assign, but this use of the wildcard token can be used instead.
A simple way to have an EDU transferred to the attention of an agent would be for the agent to Assign using:
agent.* : agentloginid
then having another application setting: agent.+agentloginid
to a value of agentloginid. In this way, the Assign criterion is satisfied (there exists a subcontainer in agent whose value is agentloginid, and that agent, on getting an event about the EDU, can use agent.! to refer to the subcontainer created for him).
Wildcard Definition Example
? Match one character pbx = ???
Find all couples named “pbx” which contain a three-character value.
* Find all VDUs transfercount= *
Setting Event Monitoring Criteria
Issue 1.0 June 2002 31
Monitoring Criteria: Examples
The following examples demonstrate how to instruct the server to monitor EDUs that fulfill specific criteria. The last three examples all identify the same set of EDUs–those from area code (203). As you can see, there is flexibility in specifying monitoring criteria. Choose the method that best fits the current circumstances.
Criteria Example Description
ani = "8008863244" Identify any EDU containing the value
"8008863244" in the field “ani”. (ani > "2029999999") & (ani < "2040000000") Monitor all calls from the “203” area
code.
ani = "203*" Monitor all calls from the “203” area
code. (This is the most efficient way to do this.)
ani = "203???????" Monitor all calls from the “203” area
33
C
HAPTER
4
A
LARMS
The IC Manager application provides system administration tools for monitoring alarm events. Visual and sometimes auditory alarms (beeps) are triggered whenever the system detects problems that require human intervention, such as server failures. Alarms are categorized as Emergency, High, Low, or Informational. (For more information about monitoring alarms, refer to IC Administration Volume 1: Servers & Domains.)
To minimize Alarm Server traffic, alarms that occur repeatedly are gathered by the EDU Server and raised periodically. The repeat count indicates how many times the condition has occurred since the alarm was last raised.
The following is a description of the alarms specifically associated with the EDU Server.
Alarm Name Priority Description Cause/Recommended Action
AssignFail Emergency Cannot Assign to EDU
%s; ignoring it
Another EDU Server across the WAN is unavailable. A site has been cut off. WAN features may not be available.
BadVDUInDS Emergency Bad UUID %s in DS’s
list of EDU servers
Corruption in the DS has made it impossible to identify other EDU Servers for WAN work. Contact customer support (1-800-886-3244).
DumpVDU High EDU overflow, killing
eldest
The EDU limit set by the vdus parameter has been reached. The oldest EDUs are being removed to make room for newer ones, which may disrupt contact handling. This alarm is generated for each EDU that is retired.
If this alarm is generated, the EDU Server is not configured properly. Increment the value of the vdus parameter. Determine if EDUs are being left in the server when they are no longer needed, and possibly adjust timer settings (nouserinterval, idletime). Refer to Chapter 5 for a discussion of EDU termination rules.
Chapter 4 Alarms
FailVDUCon High Connection to <uuid>
closed; n dropped watchers [reason]
A connection to a remote server has failed. The UUID of the remote server is reported, as is the number of clients that were assigned to the server. The reason is often VDU.ServerFailed.
LostVDUEvents High n events lost due to
network congestion or error
Event handling requests are timing out. n represents the approximate number of events that have been lost.
NoEventSink High Cannot find the server
named in the eventsink configuration parameter. A Vesp_Request call failed to send a request to the specified server
The server could not be reached. History is being lost. If you are not using a data repository, set the database configuration parameter to 0 and restart the EDU Server. Check the vesp.imp and
vespidl.pk installation files. If they do not list the eventsink server and interface, re-install the files and restart the EDU Server.
NoMeInDS Emergency This EDU Server is
not listed in the DS for this EDU Server’s domain.
The configuration of servers and domains is incorrect. Contact customer support (1-800-886-3244).
NoVDUOS Emergency Cannot request of
DUStore, %lx (losing EDUs)
The DUStore Server could not be reached. EDUs are not being archived. If you do not have a DUStore Server installed, set parameter DUStore to 0 and restart the EDU Server.
VDUbad High EDU %s corrupt, and
cannot be resurrected
An EDU was requested but could not be restored due to database damage.
Victims High Shutdown with %u
EDU%s in existence; %s. Saving to VDUOS or
Objects discarded
The EDU Server has been shut down with EDUs still active. If the DUStore service is available, the server attempts to save the EDUs there. This may take considerable time and delays server shutdown. If the DUStore is not configured, the EDUs are simply lost.
Alarm Name Priority Description Cause/Recommended Action
35
C
HAPTER
5
EDU S
ERVER
C
ONFIGURATION
This chapter contains configuration information for the EDU Server.
System Considerations
The Max Active Vdus configuration parameter should be set with consideration for system capability. The number of contacts that can be effectively handled by the EDU Server is proportional to the system's available memory and processor speed. A typical EDU (in other words,, a typical contact) requires 10K in memory. Complex contact flows might require 30K or more. Memory can be conserved by using the same data names in many EDUs. The memory space for name storage is shared. The memory used for storage of values, however, is not affected. Processor usage may be decreased by setting values in groups as opposed to one at a time. When possible, gather sets of name/value pairs and apply them all at the same time.
EDU Server Alias Name
When setting an alias name for the EDU Server, note that the name “local EDU” is reserved. In a WAN environment, it is used to segregate an EDU Server when it has been taken off-line. Refer to IC Administration Volume 1: Servers & Domainsfor information about setting alias names for servers.
Effect of Configuration on EDU Termination
Several configuration parameter settings interact to determine when EDUs are terminated.
The server periodically scans for EDUs that need to be cleaned out. This has the effect of batching DUStore Server operations to some degree. This interval is controlled with “scaninterval”, which can be dropped to 1 second if less batching is desirable.
The scan causes cleaned out EDUs to be sent to the DUStore Server. No more than “maxkills” EDUs are sent to the DUStore Server per scan. By changing scaninterval and maxkills, you can control how much work the EDU sends to the DUStore Server, and how quickly. The value of maxkills could be set to 256 at a busy site, and possibly higher for high values of scaninterval.
Chapter 5 EDU Server Configuration
If maxkills is too low, EDUs build up in memory, having no users and waiting to be shipped out to the DUStore Server on a subsequent scan. Eventually, the EDUs limit is reached, and you begin receiving “Dump VDU” alarms, because the oldest EDUs are terminated to make room for each new EDU created.
An EDU with no interested users is given “nouserinterval” seconds, plus a random number of seconds between 0 and “randomkillinterval” (120), to exist. When that time expires, it is picked up on the next scan. The worst case for an EDU without users is: remain active for
scaninterval+nouserinterval+randomkillinterval. Expected is:
scaninterval/2 + nouserinterval + randomkillinterval/2.
The random time addition avoids a situation where an application fails to terminate a number of EDUs, then stops. All of the EDUs that were opened by the application become candidates for cleanup at the same time. By adding some randomness to the cleanup-time, these are spread over several scans, causing any individual scan to do less work.
Configuration Parameters
The EDU Server is configured through the IC Manager. For detailed configuration instructions, refer to IC Administration Volume 1: Servers & Domains. The following table lists the label used when configuring with IC Manager, followed in parentheses by the parameter name as it is required internally by the server.
Note: For configuration parameters specific to the EDUDATA service, refer to Chapter 6. For configuration parameters specific to the DUStore Server, refer to Chapter 9.
Label Description
Checkpoint frequency (checkpoint.interval)
Minimum interval period in seconds between requests to checkpoint a specified EDU into the DUStore server. A value of –1 means do not checkpoint.
Idle Time (idletime)
Number of minutes an EDU may remain inactive before being terminated. The default is 90 minutes. Minimum is 1 minute, default is 30 minutes, maximum is 15 hours. No User Interval
(nouserinterval)
Minimum number of seconds an EDU may linger in memory when there are no users active for it. Default is 60 seconds. Minimum is 1 second, default is 15 seconds, maximum is 90 minutes.
Configuration Parameters
Issue 1.0 June 2002 37 Random Kill Interval
(randomkillinterval)
Maximum number of seconds an EDU stays in memory after the usual timers have expired. The default is 30, the range is 1 to 180 seconds.
Random intervals are useful when a large number of EDUs are simultaneously suspended or deleted, causing the DUStore to be flooded with requests. Handling the requests over a two-minute period decreases server stress.
Where such a situation is unlikely, more predictable timing and better memory usage result from a setting of 1. While testing to see if EDUs are being retired when they should be, 1 is also an appropriate setting.
Scan Interval (scaninterval)
Number of seconds to wait between checking various EDU Server timers. Higher values may save some CPU time. Lower values provide behavior that is more predictable during prototyping and testing. Default is 4 seconds. Minimum is 1 second, maximum is 60 seconds. Assume that other timers in the EDU could be off by as much as (this interval + 1) to start.
Max Active Edus (vdus)
The maximum number of EDUs that the EDU Server will keep active at the same time. If “Enable persistence” is selected, it will send an alarm and the Oldest EDU will be stored in DUStore.
This value should be somewhat greater than the number of agents using this server to handle calls. The default varies by release. Always set this value explicitly. The number of EDUs that can be effectively handled by the EDU Server is proportional to the system’s available memory and processor speed. A typical EDU requires 40K in memory. Active agent sessions might require 60K or more.
Watchers (watchers)
The number of clients who are interested in assigning to EDU Servers. To start, this should be equal to the number of agents in the contact center (across all contact centers in a WAN environment), plus a few extra. Default varies by release. Always set this value explicitly, as the default is very large and some memory is wasted in each EDU if the value is set too high. If set too low, Assigns are rejected.
Enable Reporting Interface
(database)
Should be checked if you want to enable the use of HISTADD reporting, unchecked if not. The default is checked.
Pool Size (poolsize)
The initial amount of memory allocated for data belonging to each EDU. Increase the pool size if a large amount of data is stored and performance needs to be improved. The default is 2000.
Pool Growth Increments (poolgrowsize)
The amount of memory to add to the string pool for each EDU if the pool runs out. Increase the pool size allocation when more memory is needed to store strings or events. The default is 1024.
Initial Number of fields (initialdatalength)
The number of fields expected in an EDU. This does not limit the number of fields, but when this number is exceeded, the server must reallocate space. The default is 128. If using containers, this value should possibly be increased to 256 or 512.
Pool Re-Pack (%) (repackfree)
When the specified percentage of the pool belonging to an EDU becomes free, the EDU Server repacks the pool to save memory. Sites at which performance is critical and memory is plentiful may consider using a value of 100. The default is 25. Enable persistance
(dustore)
Enables the use of the DUStore Server. Check the checkbox to enable or uncheck to disable.
Label Description
