Avaya Interaction Center Release 6.1 Electronic Data Unit Server Programmer Guide

Avaya Interaction Center Release 6.1 Electronic Data Unit Server Programmer Guide 585-248-206 Issue 1.1 August 2003

2003 Avaya Inc. All Rights Reserved. Notice While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document may be incorporated in future releases. Preventing toll fraud "Toll fraud" is the unauthorized use of your telecommunications system by an unauthorized party (for example, anyone who is not a corporate employee, agent, subcontractor, or person 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 telecommunications services. Avaya fraud intervention If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at +1-800-643-2353 for the United States and Canada. For additional support telephone numbers, see the Avaya Web site: http://www.avaya.com Select Support, then select Escalation Lists. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Providing telecommunications security Telecommunications security (of voice, data, and video communications) is the prevention of any type of intrusion to (that is, either unauthorized or malicious 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, subcontractor, or person 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) equipment or interfaces for reasons of: Use (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 intrusion should occur, it could result in a variety of losses to your company (including, but not limited to, human and data privacy, intellectual property, material assets, financial resources, labor costs, and legal costs). Your responsibility for your company's telecommunications security The final responsibility for securing both this system and its networked equipment rests with you, an Avaya customer's system administrator, your telecommunications 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 Your Avaya-provided software applications, as well as their underlying hardware/software platforms and interfaces Any other equipment networked to your Avaya products. Warranty Avaya Inc. provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product, while under warranty, is available through the following Web site: http://www.avaya.com/support Link disclaimer Avaya Inc. is not responsible for the contents or reliability of any linked Web sites and does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all of the time and we have no control over the availability of the linked pages. Trademarks All trademarks identified by the or are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. Avaya, Conversant, CustomerQ, Definity, DefinityOne, MultiVantage, Nabnasset, Quintus, and WebQ are registered trademarks or trademarks of Avaya Inc. in the United States or other countries or both. Ordering information: Avaya Publications Center Voice: +1-207-866-6701 1-800-457-1764 (Toll-free, U.S. and Canada only) Fax: +1-207-626-7269 1-800-457-1764 (Toll-free, U.S. and Canada only) Write: Globalware Solutions 200 Ward Hill Avenue Haverhill, MA 01835 USA Attention: Avaya Account Manager Web: http://www.avayadocs.com E-mail: totalware@gwsmail.com Order: Document No. 585-248-119, Issue 1.0 August 2003 Avaya support 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 in the United States. For additional support telephone numbers, see the Avaya Web site: http://www.avaya.com Select Support, then select Escalation Lists. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Avaya Training Avaya provides training for Avaya Operational Analyst. For more information, contact Avaya University at: Web site: http://www.avaya-learning.com/logon_form.asp E-mail address: avaya.u.helpdesk@accenture.com US telephone: 1-800-288-5327 Outside US telephone: +1-303-406-6089 Comments To comment on this document, send e-mail to crminfodev@avaya.com. Acknowledgment This document was written by the CRM Information Development group.

Avaya Interaction Center Release 6.1 Electronic Data Unit Server Programmer Guide Contents Typographical Conventions............................... 7 Notes, Tips, and Cautions................................ 8 Contacting Technical Support.............................. 8 Product Documentation................................. 9 Readme File..................................... 9 Electronic Documentation............................... 9 Printed Documentation................................ 10 License to Print the Electronic Documentation..................... 10 Right-To-Print License Terms............................ 10 Educational Services.................................. 11 Chapter 1: The EDU Server................................ 13 Overview....................................... 14 Interaction with the IC Repository............................ 14 Interaction with the DUStore server........................... 15 Cooperation of EDU servers.............................. 16 Multiple EDU servers................................. 17 Chapter 2: The Electronic Data Unit........................... 19 Definition of an EDU.................................. 20 The EDU lifecycle................................... 20 EDU creation..................................... 20 EDU activity..................................... 21 EDU termination................................... 22 Listing active EDUs................................... 23 The EDUID...................................... 24 The EDU data table.................................. 25 Pre-defined data names................................ 26 history...................................... 29 Containers....................................... 30 Overview....................................... 30 Container names and special tokens.......................... 31 Limitations of container syntax............................. 32 The agent container.................................. 33 Container configurations................................ 33 Issue 1.1 August 2003 3

Contents Chapter 3: Event Monitoring............................... 35 EDU event monitoring................................. 35 Starting and stopping event monitoring......................... 38 Setting event monitoring criteria............................. 39 Monitoring criteria: syntax............................... 39 Relational operators.................................. 41 Boolean operators.................................. 42 Monitoring criteria: wildcards............................. 42 Monitoring criteria: examples............................. 43 Chapter 4: Alarms..................................... 45 Chapter 5: EDU Server Configuration.......................... 49 System considerations................................. 49 EDU server alias name................................. 49 Configuration effect on EDU termination......................... 50 Configuration parameters................................ 51 EDU tab....................................... 52 Persistence tab.................................... 58 Debug tab...................................... 59 Configuration tab................................... 60 The Filter dialog box................................. 61 Chapter 6: IDL Specification............................... 63 Chapter 7: EDU Server Methods............................. 65 Method Objectives................................... 65 Exception information................................. 66 Routing requests.................................... 66 Resurrecting EDUs................................... 67 EDU method overview................................. 67 VDU.Assign..................................... 70 VDU.Create..................................... 71 VDU.CreateExtended................................. 73 VDU.Deassign.................................... 74 VDU.DeleteOne................................. 74 VDU.DeleteSubTree................................. 75 VDU.Deletes.................................. 75 VDU.EventsIn.................................... 76 VDU.Find....................................... 77 VDU.FindByKey................................... 79 VDU.FindExtended.................................. 80 VDU.FindOrCreate.................................. 81 VDU.ForceTerminate................................. 82 VDU.ForwardEvent.................................. 82 VDU.GetActive.................................... 83 VDU.GetOne.................................. 84 4 Electronic Data Unit Server Programmer Guide

Contents VDU.GetSomes................................. 85 VDU.GetSubTree................................... 86 VDU.GetUserSessions................................ 87 VDU.Gets.................................... 88 VDU.GetHistory................................. 89 VDU.GetsHistory................................ 90 VDU.GetVariouss................................ 92 VDU.Incr.................................... 93 VDU.Monitor..................................... 94 VDU.RemoteWatcher................................. 95 VDU.SetAndTerminate................................ 95 VDU.SetAndTransfer................................. 96 VDU.SetDefaultHistoryFilter.............................. 97 VDU.SetHistoryFilter................................. 98 VDU.SetOne.................................. 100 VDU.SetOrIncrement................................. 101 VDU.Sets.................................... 102 VDU.SetsExtended............................... 103 VDU.Terminate.................................... 104 VDU.TerminateAndCreate............................... 105 VDU.TerminateDuplicate............................... 106 VDU.TerminateMine.................................. 107 VDU.Touch...................................... 107 VDU.Transfer..................................... 108 Chapter 8: The DUStore Server.............................. 109 Overview....................................... 109 DUStore database................................... 110 DUStore database table................................ 110 DUStore functions................................... 111 EDU behavior..................................... 111 Configuration parameters................................ 112 DUStore tab..................................... 112 Debug tab...................................... 113 DUStore processing.................................. 114 DUStore processing for idle DU records........................ 114 Processing as a backup of EDU data.......................... 115 Temporary EDUID storage............................... 116 Deleting EDUIDs................................... 117 EDUIDs in Report server vs. DUStore server...................... 117 Removing records from database tables........................ 118 Troubleshooting and testing.............................. 118 Parameter setting example.............................. 119 Customer Situation A................................ 119 Customer Situation B................................ 121 DUStore server method overview............................ 125 Appendix A: VDU.Create Example............................ 127 Issue 1.1 August 2003 5

Contents 6 Electronic Data Unit Server Programmer Guide

Typographical Conventions Before You Begin This section includes the following topics: Typographical Conventions on page 7. Notes, Tips, and Cautions on page 8. Contacting Technical Support on page 8. Product Documentation on page 9. Educational Services on page 11. Typographical Conventions This guide uses the following font conventions: Font Type command commandvariable italics link Meaning This font signifies commands, information that you enter into the computer, or information contained in a file on your computer. This font indicates variables in a command string. This font is used to add emphasis to important words and for references to other chapter names and manual titles. Blue underlined text in online documents indicates a hypertext jump to related information. To view the related material, click the blue underlined text. Issue 1.2 August 2003 7

Before You Begin Notes, Tips, and Cautions Note: Important: Tip: CAUTION: Note: A note calls attention to important information.! Important: An important note calls attention to a situation that has the potential to cause serious inconvenience or other similar repercussions. 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. 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. and Canada: 1-888-TECH-SPT (1-888-832-4778) - Direct line for international and domestic calls: 1-512-425-2201 - Direct line for faxes: 1-512-997-4330 8 Electronic Data Unit Server Programmer Guide

Product Documentation Sending email with your question or problem to crmsupport@avaya.com. You may be asked to email one or more files to Technical Support for analysis of your application and its environment. Note: Note: If you have difficulty reaching Avaya Technical Support through the above URL or email address, please go to http://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 a PDF 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. Avaya may also deliver an Addendum to the Readme, which will be posted on the Avaya Technical Support Website. The Readme Addendum will contain similar information uncovered after the manufacture of the product CD-ROM. 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. You can also view the documentation set online at http://www.avayadocs.com. Issue 1.2 August 2003 9

Before You Begin Printed Documentation You can purchase printed copies of these manuals separately. For details, see Ordering information: Avaya Publications Center 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. 10 Electronic Data Unit Server Programmer Guide

Educational Services 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/logon_form.asp Over the telephone at 800-288-5327 (within the U.S.) +001 303-406-6089 (outside of the U.S.) Through email at Avaya.U.Helpdesk@accenture.com Issue 1.2 August 2003 11

Before You Begin 12 Electronic Data Unit Server Programmer Guide

Chapter 1: The EDU Server This chapter provides an overview of the EDU server and describes its interactions with the IC 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. This section includes the following topics: Overview on page 14 Interaction with the IC Repository on page 14 Interaction with the DUStore server on page 15 Cooperation of EDU servers on page 16 Issue 1.1 August 2003 13

The 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 it is terminated by an agent. Once 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 requests from Avaya 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 EDU data, including contact wrap-up information, is passed to the database. Interaction with the IC Repository The IC Repository archives terminated EDUs for long-term storage in a relational database. The Avaya Operational Analyst reporting package draws on this information to generate reports. A subset of the EDU is 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 EDU Server Methods on page 65) and with the filter configuration parameter (described in EDU Server Configuration on page 49). 14 Electronic Data Unit Server Programmer Guide

Interaction with the DUStore server Interaction with the DUStore server The DUStore server maintains a database of inactive EDUs. This EDU data is 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 The DUStore Server on page 109 for a description of the DUStore server. Issue 1.1 August 2003 15

The EDU 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 & Domains for 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. 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 EDU server that created it and the time when 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. 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 reside.! CAUTION: CAUTION: When the EDU server is shut down improperly, it is possible to lose data that has not yet been written to the DUStore server. Therefore, it is important to follow proper shutdown procedures. Please refer to IC Administration Volume 1: Servers & Domains and IC Installation and Configuration Guide for more information on server shutdown procedures. 16 Electronic Data Unit Server Programmer Guide

Cooperation of EDU servers Multiple EDU servers An installation may have more than one EDU server. A process (for example, another server) assigns to one EDU server for EDU information. That EDU server communicates with all the other EDU servers so that the process has access to the EDU information in all of the EDU servers through the one to which it is assigned. Some EDU methods categorize EDU servers as either local or remote. The local EDU server is the one to which the process is assigned. Other EDU servers, if any, are remote EDU servers. A method which operates locally considers only those EDUs in the local EDU server. A method that operates globally considers all EDUs in all servers. WAN EDU Servers refers to the set of all EDU servers, local and remote. The process can choose which EDU server to assign to by interface name, alias name, or UUID. Usually, the assignment is made by interface name, so that the EDU server is chosen by the domain setup. If an EDU server is unavailable, the domain setup includes information allowing the next available EDU server to be used. If the assignment is made by alias name or UUID, then the process explicitly chooses an EDU server to assign to, and none other are considered. (Refer to EDU Server Methods on page 65 for more information on specifying servers in methods.) Note: Note: Note that the documentation consistently refers to any installation containing multiple EDU servers as a "WAN environment". This is no longer true. On the other hand, EDU methods specifically use the term "WAN" to indicate "all EDU servers", so this term cannot be eliminated without changing the product as well as the documentation. Therefore, the concept of WAN is used as delicately as possible. Issue 1.1 August 2003 17

The EDU Server 18 Electronic Data Unit Server Programmer Guide

Chapter 2: The Electronic Data Unit This chapter describes the Electronic Data Unit (EDU). This section includes the following topics: Definition of an EDU on page 20 The EDU lifecycle on page 20 Listing active EDUs on page 23 The EDUID on page 24 The EDU data table on page 25 Pre-defined data names on page 26 history on page 29 Containers on page 30 Issue 1.1 August 2003 19

The Electronic Data Unit Definition of an EDU Each telephone call, chat, or email 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 collects information about activity performed on behalf of the contact and updates that information as the contact traverses the contact center. A typical EDU might contain the time the call arrived, transfers between agents, the time the call concluded, and customer service actions performed by the agent. The EDU lifecycle This section describes the EDU lifecycle stages: This section includes the following topics: EDU creation on page 20 EDU activity on page 21 EDU termination on page 22 EDU creation Every contact must have a corresponding EDU. Whenever an inbound contact 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 media server (Telephony server, Chat server or Email Management server) invokes VDU.Create(). The EDU server responds by creating an EDU for the contact and returns the unique identifier (EDUID) for the new EDU to the media server by invoking VDU.Create.Response(). 20 Electronic Data Unit Server Programmer Guide

The EDU lifecycle EDU activity The EDU is a real-time detail record that collects strings of text from multiple sources. During its life, the job of the EDU is to collect information ({name, value} data couples) entered by the agent or the automated software, and to notify assigned clients of changes to the EDU. 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 35.) 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 (GetOne(), GetSomes(), and so on) to ask the EDU server to return values in an EDU. Refer to EDU Server Methods on page 65 for descriptions of the methods that support 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. Issue 1.1 August 2003 21

The Electronic Data Unit EDU termination When a contact ends, so does the need for an EDU. The agent may need to enter wrap up information in the contact record, but the EDU should be closed after wrap up. 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, those EDUs that appear to have been lost. Any EDU that is idle for an extended period (thirty minutes, by default) is timed-out and automatically terminated, if the Enable Persistence configuration parameter is not selected. You can configure the EDU server to enable persistence of the EDU with the Enable Persistence parameter. You can also change the number of minutes the EDU can remain active with the Idle Time configuration parameter. Refer to EDU Server Configuration on page 49 for a discussion of how various configuration parameters affect the timing of EDU termination. 22 Electronic Data Unit Server Programmer Guide

Listing active EDUs Listing active EDUs You can view a list of active EDUs and the clients interested in them with the listvdu utility. To use this utility: 1. Copy listvdu.exe from the Avaya IC61/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. a. Click the Agent tab and select the Agent New menu option. b. Define the name of the agent, the login Id, the group (either Admin or Default is acceptable), and the domain. c. Click Apply. 3. From the vesp account, enter: listvdu -uusername -ppassword -iinterface Where: -u = user name to log in as (often Admin) -p = password of user -i = interface to use (ADU server or EDU server, or an alias or uuid of such a server) 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 address and port number broken out. Resurrected EDUs are included in the list. Issue 1.1 August 2003 23

The Electronic Data Unit The EDUID When an EDU is created, it is automatically assigned 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 originator the software process and machine that created it. A combination of the IP address and the port identifies which EDU server is the originator of this EDU. The structure of an EDUID is illustrated in the following example. EDUID = 30f4216300000000780000261f430002 Bytes Example Contents 0 7 30f42163 Timestamp. Hex representation of number of seconds since 1 1 1970. 8 11 0000 Hex representation of uniqueness value 12 15 0000 Reserved 16 23 78000026 Hex representation of the IP address 24 27 1f43 Hex representation of a port 28 31 0002 Reserved 24 Electronic Data Unit Server Programmer Guide

The EDU data table The EDU data table EDU data consists of a 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 31 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 in Pre-defined data names on page 26. 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. s, the pieces of data that applications assign to a field, are strings that contain from 0 to 4096 characters. Although longer strings are technically permissible, they are discouraged. Any character except the null character ( \0 ) is legal. Typical EDUs contain approximately 100 values. It can hold more values, but additional values require more memory, which affects system performance. Each time the EDU server must allocate additional memory, the system slows briefly adversely affecting 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. All of the changes to data values are recorded, including information on who made the change and when the change was made. Issue 1.1 August 2003 25

The Electronic Data Unit Pre-defined data names The following pre-defined field names are a subset of what is available in the EDU. They 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 because doing otherwise could create problems with 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 ani call_ref_id contactendtime createtime createtime_t dnis duration loginid last termination owner persistence persistence.deletedate Automatic Number Identification. Caller s 10-digit telephone number. Call number that the switch uses to distinguish one call from other calls. The EDU server uses the EDUID to distinguish one call from another. Time of the last Terminate method to the EDU or equivalent such as removal of the EDU due to idleness. Date and time the EDU was created in yyyy-mm-dd hh:mm:ss format. Number of seconds between 1970-01-01 00:00:00 UTC (GMT) and the time of the EDU creation. Dialed Number Identification Service. Call recipient s (agent s) telephone number or extension. 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. Avaya IC loginid assigned to the contact center agent. Identifier of the last user who invoked the Terminate method, used as debugging information. Loginid or UUID of the application that created the EDUID or last used the Transfer/SetTransfer methods. (historical). Date and time that the EDU was last stored in the DUStore server. The field is used to modify purging behavior of the DUStore server. 26 Electronic Data Unit Server Programmer Guide

Pre-defined data names Field name suspend termination time transfercount vdu_id L_ucid Reason the EDU was last removed from server memory. normal all involved parties 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. Reason the EDU was terminated: 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 this number has been exceeded. The oldest EDU is terminated to make room for subsequent EDUs. expired the EDU was idle too long, it is terminated even though there are still interested parties. exit the EDU server is being shut down. Not set. This field is inserted into each event that is set to reporting packages and is reserved for that purpose. Number of times Transfer/SetAndTransfer was used on this EDU. (historical) Unique identifier of the EDU. Universal Call ID as implemented for versions 6 and beyond of the Avaya (formerly Lucent) Definity switch, CallVisor version 6.0.4. Issue 1.1 August 2003 27

The Electronic Data Unit Field name iidigits lai_dnis 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 Supported on the legacy Definity code only. Phone number to which the call is currently routed. The number dialed by the contact arrives as DNIS, and it is stored in the EDU under primary_dnis. The number dialed by the contact (ANI) is stored under primary_ani. Both fields survive multi-site-hetero-switch transfers. They are written when the first contact center receives the call for the first time, and are not updated. 28 Electronic Data Unit Server Programmer Guide

history history Typically, a name in an EDU is set once and not modified. However, it may be useful to maintain a history of the 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 31) to gain the same effect. Note: Note: The GetHistory() 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 history of a value. The value history is maintained only in the DUStore database. It is not retained in the IC Repository. Issue 1.1 August 2003 29

The Electronic Data Unit Containers The Avaya TS automatically collects information about the agents who handle contacts on Avaya IC. This information is stored in objects known as containers, structures that hold repeated instances of a value under a common name. This section includes the following topics: Overview on page 30 Container names and special tokens on page 31 Limitations of container syntax on page 32 The agent container on page 33 Container configurations on page 33 Overview The Avaya TS creates two kinds of containers to store this information: Voice contact containers store information about the contacts using Avaya IC. This section documents voice contact containers. Agent containers store information about the agents who handle these contacts. This section documents agent containers. Agent containers are documented in the Agent Data Unit Server Programmer s Guide. 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 are provided 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. 30 Electronic Data Unit Server Programmer Guide

Containers Container names and special tokens You can specify container names or the EDU server can generate container names for you based on your instructions. A number of special tokens are provided for 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. You can use up to 31 dots (32 tokens total) in a container name. Note that processor usage for container names is low, but is proportional to the number of tokens in the name. There are four special tokens available for use with container names: Token + 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 51, 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 Issue 1.1 August 2003 31

The Electronic Data Unit Token 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 Sets: 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 42. Limitations of container syntax There are some syntax limitations to consider when using special tokens: 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: Note: Some methods do not support all of the special tokens. Most methods do not support * and some (Gets and methods like it) do not support +. For example, in the method invocation Gets( a.+.x ), the + token would be interpreted as create the next number in the sequence, which is not meaningful for the Gets method. 32 Electronic Data Unit Server Programmer Guide

Containers The agent container The Avaya TS creates a special container, called an agent 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 Avaya TS 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 agent uses the name agent.1, and creates names below it agent.1.callduration, agent.1.reasoncode, and so on. The next agent uses the name agent.2 and sets that agent s own values in that subtree agent.2.callduration, and so on. The use of the agent container allows clients to assign with agent.*, realizing a large resource savings over using multiple assigns. (Refer to Telephony Server Programmer s Guide for more information on agent containers.) Container configurations Containers are enabled or disabled for the Avaya TS through the "Enable Call Containers" configuration parameter in IC Manager. The "Enable Call Containers" and "Use 6.0 State Fields" parameters are enabled by default on the TS Server Editor on IC Manager. These parameters are required for the creation of containers on Avaya IC. The following table describes the configuration parameters that pertain to containers on Avaya IC. Refer to IC Administration Volume 1: Servers & Domains for more details. Parameter Name Default Enable Agent Containers enabled Turns ADU Containers on/off for agent containers. Enable Call Containers enabled Turns EDU Containers on/off for voice contact containers. Use 5.6 State Fields disabled Determines if call state statistics are written to the container in the old style (5.6). Use 6.0 State Fields enabled Determines if call state statistics are written to the container in the new style (6.0). Issue 1.1 August 2003 33

The Electronic Data Unit 34 Electronic Data Unit Server Programmer Guide

EDU event monitoring Chapter 3: Event Monitoring This chapter describes the events sent by the EDU server. It also explains how to assign and how to establish monitoring criteria. This section includes the following topics: EDU event monitoring on page 35 Starting and stopping event monitoring on page 38 Setting event monitoring criteria on page 39 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 contact handled by a particular agent. The client receives event messages about EDUs that match the specification. The client continues to receive all events generated for those EDUs as long as they match the specified monitoring criteria. Issue 1.1 August 2003 35

Event Monitoring 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 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 monitored EDU was changed. All affected {name, value} couples and the EDUID. VDU.Delete VDU.Drop VDU.End VDU.LostConnectivity s were deleted from the EDU. The EDU has changed and it no longer matches the assign criteria. It is no longer monitored. If there are more EDU changes that make it again meet the assign criteria, the client gets a VDU.Watch event. The EDU was terminated. When it terminates, the EDU server sends a VDU.End message to all of the monitoring applications. Two connected EDU servers lost their connection to each other. All deleted values. The EDUID. All of the data elements in the EDU. The clients assigned to these servers who prepended notify/drop to their assign criteria receive this event. VDU.Transfer The EDU was transferred. The new client and the EDUID. VDU.Watch The EDU matches the monitoring criteria. All of the data elements in the EDU. When a client first assigns monitoring criteria to the server: All existing EDUs are checked to see if any of them match the client s specification. All subsequently created EDUs are checked for a match. Any EDUs that do match the monitoring criteria are placed under watch. 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. 36 Electronic Data Unit Server Programmer Guide

EDU event monitoring Note: Note: When a client has assigned to the EDU server, the client should monitor the event data stream for the data it wants, rather than repeatedly invoking VDU.Get () methods. 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, which makes them variable. Issue 1.1 August 2003 37

Event Monitoring Starting and stopping event monitoring The EDU server methods VDU.Assign()and VDU.Monitor() set up monitoring conditions. The VDU.Deassign() method revokes them. Note: Note: By default, a client does not receive change events for the EDU changes it initiates. This reduces needless event traffic. The client does receive other sorts of events, as well as event messages for changes caused by other clients. If the change causes a VDU.Watch or VDU.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 (assigned to) EDU server should be monitored, as described in Monitoring criteria: syntax on page 39.) 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 22.) 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. 38 Electronic Data Unit Server Programmer Guide

Setting event monitoring criteria Setting event monitoring criteria EDUs are selected for monitoring by criteria matching. 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 finds a match, the EDU is watched. Subsequent changes are sent to the client as change events. The createtime, duration, endtime (historical), owner (historical), termination, and transfercount cannot be used in an Assign criteria. This section includes the following topics: Monitoring criteria: syntax on page 39 Relational operators on page 41 Boolean operators on page 42 Monitoring criteria: wildcards on page 42 Monitoring criteria: examples on page 43 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. The EDU will 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 (assigned to) EDUs (those in the local EDU server) to be watched. This monitor criteria used by IC Manager. It should be avoided by other applications because it generates heavy event traffic. Setting the monitor criteria to a null value ( ) stops monitoring. Issue 1.1 August 2003 39

Event 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 EDUindependent meaning. The Assign and Monitor methods contain criteria strings that allow additional syntax. At the end of the string is a list of fields, called a projection list, enclosed in curly brackets where filter criteria can be specified. The list is comma separated with no spaces between the fields. For example: {specification,specification } You can specify the type of field name in three ways. To specify the type of field name: 1. Use a simple field name, such as a, b, or c. 2. Enter 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. Issue 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} 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. This assign criteria watches all EDUs in the system because all EDUIDs 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: 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. 40 Electronic Data Unit Server Programmer Guide

Setting event monitoring criteria Relational operators s can be compared to each other as described below. The following table illustrates the supported relational operators. In the description column, the term couple refers to a name/value pair. Symbol Definition = 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 (stringbased). : exactly equal to For a given name, find a couple that exactly matches the specified value. Wildcards are not accepted. # not Expressions are not equal to each other. 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. Issue 1.1 August 2003 41

Event Monitoring Boolean operators Boolean comparisons that return evaluations of true or false can be performed between two values. The two boolean operators are described below. Symbol Definition & and Both expressions must be true. or True if one or both expressions are true. For example: ani=508* dnis=3315 selects all contacts received from the 508 area code or all contacts 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 replace 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. Each? symbol can stand in for one character. The * symbol can either be placed at the end of a value (a value trailing wildcard), or can be entered by itself to find EDUs with an instance of any value (selects all EDUs as matching). Wildcard Definition Example? Match one character pbx =??? Find all couples named pbx which contain a three-character value. * Find all VDUs transfercount= * Find all EDUs that have been transferred. 42 Electronic Data Unit Server Programmer Guide

Setting event monitoring criteria 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 wildcard token can be used instead. A simple way to have an EDU transferred to the attention of an agent would be for: 1. Assign the agent to the EDU server using: agent.* : agentloginid 2. Change the application setting: agent.+agentloginid to a value of agentloginid. In this way, the Assign criterion is satisfied because there is 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. Monitoring criteria: examples The following examples demonstrate how to have the server to monitor EDUs that meet specific criteria. The last three examples all identify the same set of EDUs those from area code (203). Choose the method that best fits the current circumstances. Criteria Example ani = "8008863244" (ani > "2029999999") & (ani < "2040000000") ani = "203*" ani = "203???????" Identify any EDU containing the value "8008863244" in the field ani. Monitor all calls from the 203 area code. Monitor all calls from the 203 area code. (This is the most efficient way to do this.) Monitor all calls from the 203 area code. Issue 1.1 August 2003 43

Event Monitoring 44 Electronic Data Unit Server Programmer Guide

Chapter 4: Alarms IC Manager provides system administration tools for monitoring alarm events. Visual and sometimes auditory alarms (beeps) are triggered when 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 traffic on the Alarm server, alarms that occur repeatedly are gathered by the EDU server and raised periodically. The repeat count of the alarm 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 Cause/Recommended Action AssignFail Emergency Cannot Assign to EDU %s; ignoring it BadVDUInDS Emergency Bad UUID %s in DS s list of EDU servers Another EDU server across the WAN is unavailable. A site has been cut off. WAN features may not be available. Corruption in the DS has made it impossible to identify other EDU servers for WAN work. Contact Avaya Technical Support. Issue 1.1 August 2003 45

Alarms Alarm Name Priority Cause/Recommended Action 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 EDU Server Configuration on page 49 for a discussion of EDU termination rules. FailVDUCon High Connection to <uuid> closed; n dropped watchers [reason] LostVDUEvents High n events lost due to network congestion or error 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. Event handling requests are timing out. n represents the approximate number of events that have been lost. 46 Electronic Data Unit Server Programmer Guide

Alarm Name Priority Cause/Recommended Action 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 NoMeInDS Emergency This EDU server is not listed in the DS for this EDU server s domain. NoVDUOS Emergency Cannot request of DUStore, %lx (losing EDUs) VDUbad High EDU %s corrupt, and cannot be resurrected 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. The configuration of servers and domains is incorrect. Contact Avaya Technical Support. 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. An EDU was requested but could not be restored due to database damage. VDU.Unknown ToADU High This server is not known to server %s. A new EDU server is created. If it continues to display, the DS may not have been updated with the new EDU server. 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. Issue 1.1 August 2003 47

Alarms 48 Electronic Data Unit Server Programmer Guide

System considerations Chapter 5: EDU Server Configuration This chapter describes the system considerations for the EDU server. It also explains how to configure the EDU server. This section includes the following topics: System considerations on page 49 EDU server alias name on page 49 Configuration effect on EDU termination on page 50 Configuration parameters on page 51 System considerations The Max Active Vdus configuration parameter, which is described in EDU tab on page 52, 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, or contact, requires 10K in memory. Complex contact flows might require 30K or more. You can conserve memory 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. The local EDU server is the server to which the process has assigned. 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 & Domains for information about setting alias names for servers. Issue 1.1 August 2003 49

EDU Server Configuration Configuration effect on EDU termination Several configuration parameter settings interact to determine when EDUs are terminated. The EDU 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 reduced 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. 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 cleanuptime, these are spread over several scans, causing any individual scan to do less work. 50 Electronic Data Unit Server Programmer Guide

Configuration parameters Configuration parameters The EDU server is configured on the Server Editor of IC Manager. This section provides EDU server configuration parameters sorted by the multiple tabs of the EDU server Editor. This section includes the following topics: EDU tab on page 52 Persistence tab on page 58 Debug tab on page 59 Configuration tab on page 60 The Filter dialog box on page 61 For configuration instructions, refer to IC Administration Volume 1: Servers & Domains. Note: Note: For configuration parameters specific to the DUStore server, refer to Chapter 8. Issue 1.1 August 2003 51

EDU Server Configuration EDU tab Field Recommended entry Notes Idle Time (min) No User Interval (sec) Random Kill Interval (sec) Enter the maximum length of time, in minutes, that Avaya IC should maintain an EDU record if an agent is idle. Default varies by channel: voice = 60 email = 30 chat = 45 Minimum is 1 minute Maximum is 15 hours Enter the minimum number of seconds an EDU may reside in memory when there are no users active for it. Default varies by channel: voice = 1,800 email = 120 chat = 90 Minimum is 1 second, Maximum is 60 minutes. Enter the maximum number of seconds an EDU stays in memory after the usual timers have expired. Default varies by channel: voice = 30 email = 120 chat = 60 Make sure that the number of minutes entered in this field is greater than the length of a typical contact. Very low values may cause thrashing if cooperating applications allow any gap passing EDUs among themselves. Random intervals are useful when a large number of EDUs are simultaneously terminated causing the IC Repository and the DUStore server to be flooded with requests. Handling the requests over a 2-minute period decreases database server stress. In situations where this 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. 52 Electronic Data Unit Server Programmer Guide

Configuration parameters Field Recommended entry Notes Scan Interval (sec) Max Active ADUs Allowed Assigns Pool Size Enter the number of seconds to wait between checking various EDU server timers. Default varies by channel: voice = 4 email = 3 chat = 6 Enter the maximum number of EDUs that the EDU server keeps active at the same time. Default varies by channel: voice = 2,048 email = 4,096 chat = 2,048 Enter the number of clients interested in assigning to EDU servers. Default is 8,192 for all channels. Enter the initial amount of memory allocated for data belonging to each EDU. Default varies by channel: voice = 8,000 email = 5,000 chat = 10,000 Higher values may save some CPU time; lower values make for more predictable behavior during prototyping and testing. Assume that other timers in the EDU could be off by as much as (this interval + 1) to start. If more than this number of EDUs are created, the EDU server sends an alarm and forcibly terminates the oldest one to make room for each new one. To start, this should be equal to the number of agents in the contact center (or across all contact centers in a WAN environment), plus a few extra. Increase the pool size if a large amount of data is stored and performance needs to be improved. Advanced Properties Enable Reporting Interface Pool Growth Increments Check to enable HISTADD reporting. Default is checked for all channels. Enter the amount of memory (in mg) by which to increase pool size allocation when more memory is needed to store strings or events. Default is 1024 for all channels. Checking this field displays the "filter" parameter, which is described at the end of this table. Issue 1.1 August 2003 53

EDU Server Configuration Field Recommended entry Notes Initial Number of Fields Pool Re-Pack (%) Poll Wait (ms) Maximum Number of Revisions Maximum Number of Cached EDU events Enter the number of fields expected in an EDU. Default is 128 for voice and email, 256 for chat. If using containers, increase this value to 256 or 512. Specify the percentage of memory that is free in the ADU pool, when the ADU server will repack the pool to save memory. Default varies by channel: voice = 20 email = 15 chat = 10 Enter the interval value, in hundredths of a second, for the IC Toolkit's Select() method. Default value is 2 (ms) for all channels. Enter the number of revisions of a value kept for access with the GetsHistory() method. Default is 1 for all channels, which is recommended. Enter the maximum number of events to be kept in memory for each EDU. Default varies by channel: voice = 128 email = 64 chat = 192 This parameter does not limit the number of fields, but when this number is exceeded, the server must reallocate space. Sites at which performance is critical and memory is plentiful should consider using a value of 100. Low values increase CPU utilization. High values (over 100) may affect the accuracy of the scaninterval parameter. Caution: Do not enter 0 in this field. If this 0 is entered, the EDU server keeps all revisions, which could result in a failure due to lack of system resources. A setting of 64 is recommended as a reasonable number of events to be kept in memory. High values may increase Eventsink throughput. Low values may conserve memory. 54 Electronic Data Unit Server Programmer Guide

Configuration parameters Field Recommended entry Notes Subcontainer Instances Retry Interval (sec) Reset Interval (sec) Enter the number of instances of a subcontainer created with the + token that can exist at one time, in the format <containername>.<integer>. If more instances than this number are created, the earliest instance is deleted. Default is 0, which specifies no limit (all instances of a subcontainer are kept). A setting of 4 is recommended. Enter the number of seconds to wait between automatic attempts to reassign to IC servers. Default is 60 (1 minute) for all channels. Minimum is 6 seconds Maximum is 172800 seconds (48 hours) Enter the number of seconds to wait between attempts to reassign to servers after receiving a VDU.FailVDUCon alarm. Default is 2 seconds for all channels. Minimum is 0 Maximum is 172800 seconds (48 hours) Exampled limit the number of subcontainers of the ts container, set gencount to voice.3. When voice.+ creates voice.4, voice.1 is deleted. When voice.5 is created, voice.2 is deleted and so on. The gencount must be set for the "voice", "chat", and "email" containers on the Configuration tab using the following name/value pairs: "gencount", "voice.4" "gencount", "chat.4" "gencount", "email.4" It is not recommended to set this value below 30 seconds in a production environment. It performs a synchronous DS call for a list of EDU servers and attempts an asynchronous Assign to any of them that it isn't already assigned to. If the Assign fails (the request function itself fails), the offending EDU server is removed from the list and not retried automatically. The retry is only attempted if the Assign callback reveals an error or a ServerFailed event arrives. Issue 1.1 August 2003 55

EDU Server Configuration Field Recommended entry Notes Data Element Names Suspend Interval (sec) Enter the names of the data elements in EDU events to be sent to the server specified on the Event Sink option. Enter the number of seconds before an EDU, which is suspended by use of the Suspend method by all users, is considered for Suspension. Default is 30 seconds for all channels. Minimum is 1 Maximum is 1200 seconds (20 minutes). Enter each element on the Edit dialog. If this option is not set, all data elements are stored. The EDUID field is always stored. The use of wildcards is permitted. Use this parameter with care; filtering elements from the End event may adversely affect reporting capability. This parameter can be overridden by a higher value in the Suspend method. 56 Electronic Data Unit Server Programmer Guide

Configuration parameters Field Recommended entry Notes EDU Data Percent filter Enter the percentage of EDUs sent to the EDU data feed to be used for random sampling. Default is 0 for all channels. Minimum is 0 Maximum is 100 Set the filter to determine which EDU events are sent to the Report server. Event types are start, change, delete, transfer, user, and data. A plus sign (+) marks the event type for storage, a minus sign ( ) excludes the event type from storage. End events cannot be filtered out. This field is enabled when the "Enable Reporting Interface" field is checked. The data parameter encompasses all event types. - data is the default. Each filter criterion must be entered on a separate line, with subsequent lines taking precedence. Examples: data +change only change and end events are stored: +change data only end events are stored Note that drop and watch events are sent to clients but are not included with the +data filter. Names of data elements in ADU events to be sent to the server are specified with the Eventsink configuration parameter. Each element must be entered on a separate line. If this parameter is not used, all data elements are sent. (The ADUID field is always stored.) Use of wildcards is permitted. Use this parameter with care. Filtering elements from the End event may adversely affect reporting capability. Issue 1.1 August 2003 57

EDU Server Configuration Persistence tab Field Recommended entry Notes Enable Persistence Checkpoint frequency (secs) Database Search on Create Lookup Field 1 (indexed) Lookup Field 2 (indexed) Info Field 1 Info Field 2 Info Field 3 Info Field 4 Check to enable the EDU server to persist its data units (EDUs) using the DUStore server. Enter the minimum interval period in seconds between requests to checkpoint a specified EDU into the DUStore server. Check to enable a DUStore search on the FindOrCreate over the WAN. Default is checked. Enter the name of one of the fields used to index the EDU in the DUStore server. Enter the name of one of the fields used to index the EDU in the DUStore server. Enter the name of one of the fields used to identify the EDU in the DUStore server. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is media. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is site. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is blank. EDUs are pushed into the database from the EDU server s memory by the DUStore server. If check pointing is enabled, the EDUs are saved at a regularly specified interval. This is used for failure recovery because EDUs persist across server shutdowns. A value of 1 means do not checkpoint. For example, loginid. Used with the Find method. For example, queueid. Used with the Find method. For example, type. Used with the Find method. For example, media. Used with the Find method. For example, site. Used with the Find method. Additional info field with no default value. 58 Electronic Data Unit Server Programmer Guide

Configuration parameters Field Recommended entry Notes Info Field 5 Info Field 6 Info Field 7 Info Field 8 Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is blank. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is blank. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is blank. Enter the name of one of the fields used to identify the EDU in the DUStore server. Default is blank. Additional info field with no default value. Additional info field with no default value. Additional info field with no default value. Additional info field with no default value. Advanced Properties Persistence Service Name DUStore EDU Batch Size Enter the name of the server that stores inactive EDUs. Default is DUStore Controls the number of terminated EDUs that are removed by the server at one time. Default is 50 Minimum is 1 This server stores EDUs in a database of inactive EDUs. When an EDU server method is invoked for an EDU that is no longer in memory, this server restores the EDU as if it were assigned to an active contact. The default value of 50 is recommended for most deployments. Setting this parameter too high results in network congestion problems. Debug tab The Debug tab does not include any EDU server-specific parameters. Issue 1.1 August 2003 59

EDU Server Configuration Configuration tab The following configuration parameters are not presented on the EDU tab in IC Manager. Set these parameters on the Configuration tab of the EDU Server Editor dialog: Field Recommended entry Notes vduhskeepname gencount padwidth Enter the names of the data elements in EDU events to be sent to the server specified with Eventsink. Each element name must be entered on a separate line. Enter the number of instances of a subcontainer created with the + token that can exist at one time. Default is 0. Enter the number of digit positions required in a container name token. This parameter is ignored if the Eventsink server is the Report server. If this parameter is not used, all data elements are sent. (The VDUID field is always stored.) Use of wildcards is permitted. Use this parameter with care. Filtering elements from the End event may adversely affect reporting capability. If more than this number are created, the earliest is deleted. For example, to limit the number of subcontainers of the ts container, you could set gencount to ts.3. When ts.+ creates ts.4, ts.1 is deleted. When ts.5 is created, ts.2 is deleted, and so on. The default is 0, which specifies no limit (all generations of a subcontainer are kept). The gencount value should be set to accommodate the maximum number of active contacts for each media channel. Numbers are padded with zeroes to this position. For example, to specify the number of digit positions for the second token of the ts container, you could set padwidth to ts.4. Subcontainers would then be named ts.0001, ts.0002, and so on. The default is 0, which specifies no padding. 60 Electronic Data Unit Server Programmer Guide

Configuration parameters The Filter dialog box The Filter dialog box in IC Manager allows you to set the filter for determining which EDU events are sent to the server. The Event Filter option (described in the previous section) performs the same function but differs in that the Event Filter setting does not take effect until the server is restarted, and then is persistent. The Filter dialog box settings take effect immediately but are lost when the server is restarted. The server must be running when this tab is used. Enter the event types to be filtered from the database. The possible values are '+charge', '+start' and '-data' which are used to turn on change and start events. The default value "- data" turns everything possible off. Note: Note: Previous versions of Avaya IC included the VDU History server, which has been replaced by the Report server. To support existing installations during a transitional period, events can be sent to both servers. 1. Use the default for the eventsink parameter (HISTMAP.EventsIn) to send events to the Reporting server. 2. Set the Reporting server s eventforward parameter to VDUHS.EventsIn. The Reporting server forwards all EDU events to the VDUHS. The vduhs parameter, used in previous versions of the EDU server to enable access to a database server, should no longer be used. Issue 1.1 August 2003 61

EDU Server Configuration 62 Electronic Data Unit Server Programmer Guide

Chapter 6: IDL Specification The Interface Definition Language (IDL) is defined within CORBA standards. It is used to create interfaces that are called by client objects and provided by object implementations. The following is the IDL description of the EDU server. interface genericdu virtual { ORBStatus Create( in SeqCouple values, out stringvduid ); ORBStatus Terminate( in stringvduid ); void TerminateMine(); ONEWAY EventsIn(in string vdu_id, in SeqEvent events); ORBStatus FindByKey( in string name, in string value, out stringvduid ); ORBStatus Find( in string search_criteria, in unsigned long, scope, out SeqString matches ); ORBStatus FindExtended( in string search_criteria, in unsigned long scope, out SeqCouple matches ); ORBStatus GetOne( in string vduid, in string name, out string value ); ORBStatus Gets( in string vduid, out SeqCouple c ); ORBStatus GetActive( out SeqString vduseq ); ORBStatus SetOne( on string vduid, in string name, in string value ); ORBStatus Sets( instring vduid, in SeqCouple values ); ORBStatus Delete( in string vduid, in string pattern ); ORBStatus Incr( in string vduid, in string name, in long incr, out string newvalue ); ORBStatus Assign( in stringmonitorcriteria ); ORBStatus Monitor( in stringmonitorcriteria ); ORBStatus Transfer( in string vduid, in string to ); ORBStatus SetAndTransfer(in string vduid, in string to, in SeqCouple values ); ORBStatus GetsHistory( in string vduid, in unsigned long flags, out SeqLong headers, out SeqString names, out SeqSeqSeqString values ); ORBStatus GetHistory( in string vduid, in string name, out SeqString values, out SeqString when, out SeqString who ); ORBStatus GetSubTree( in string vduid, in string name, out SeqCouple matches ); ORBStatus GetSomes( in string vdu_id, in string name, out SeqCouple matches ); ORBStatus SetsExtended( in string vdu_id, in SeqCouple data, out SeqString newnames ); ORBStatus Deletes( in string vdu_id, in SeqString names ); ORBStatus DeleteOne( in string vdu_id, in string name ); ORBStatus DeleteSubTree( in string vdu_id, in string name ); Issue 1.1 August 2003 63

IDL Specification ORBStatus SetAndTerminate( in string vdu_id, in SeqCouple data ); void GetUserSessions( in string vdu_id, out SeqString users ); //Server ONLY ORBStatus RemoteWatcher( in unsigned long handles, in string cri ); ORBStatus ForwardEvent( in unsigned long handles, in Event Event ); void SetDefaultHistoryFilter( in unsigned long mask ); ORBStatus SetHistoryFilter( in unsigned long mask ); } interface EDU : genericdu, General { const unsigned long NO_OS = 0x00; const unsigned long ASK_OS = 0x01; const unsigned long NET_NO_OS = 0x02; const unsigned long NET_ASK_OS = 0x03; }; 64 Electronic Data Unit Server Programmer Guide

Method Objectives Chapter 7: EDU Server Methods This chapter defines the methods provided with the EDU server. This section includes the following topics: Method Objectives on page 65 Exception information on page 66 Routing requests on page 66 Resurrecting EDUs on page 67 EDU method overview on page 67 Method Objectives Clients request Avaya IC servers to perform various functions by issuing server-specific method invocations. These methods behave in a similar fashion across all of the servers. For example, when you invoke any EDU server method, existing values are overwritten and values that did not previously exist are created. With the exception of the Delete methods, all of the EDU server methods generate change events to indicate changes or additions. If an error occurs, exceptions are raised. Note: Note: In some program examples the line length was longer than could fit across the page. An actual program line cannot be arbitrarily split. Issue 1.1 August 2003 65

EDU Server Methods Exception information If an error occurs, EDU server methods returns an exception. The following exception information may be returned: Cannot use empty token Improper special token for this method Improper use of a special token No listing for home server for that VDU No such name: <name> No such VDU: <vduid> No WAN VDU services in this version Not a VDU id: <vduid> Server only attribute Too many characters in token Too many dot separators Too many names at once Unknown error VDU is read-only You are not a server Cannot find subcontainer for that owner First token must be normal here No match (or illegal usage) Cannot access invalidated member Routing requests In an environment with several EDU servers, any method that accepts an EDUID routes the request to another EDU server if the EDU named is not local to the first server. EDUIDs contain location data, so an EDU server can identify which system owns each EDU. 66 Electronic Data Unit Server Programmer Guide

Resurrecting EDUs Resurrecting EDUs Unless otherwise noted, all methods that accept an EDUID resurrect the EDU if it has been retired to the DUStore. Refer to The DUStore Server on page 109 for more information about resurrecting EDUs. EDU method overview The following is a brief description of the methods available for use with the EDU server. Name VDU.Assign VDU.Create VDU.CreateExtended VDU.Deassign VDU.DeleteOne VDU.DeleteSubTree VDU.Deletes VDU.EventsIn VDU.Find VDU.FindByKey VDU.FindExtended Create a session with the EDU server. Create a new EDU. Create a new EDU and return the time that the EDU was created. Destroy a session with an EDU server. Removes the name and value history from the EDU. This is equivalent to Deletes with a single name. Performs DeleteOne on the given name and every name in the subcontainer beneath it, cutting a branch from the tree a container represents. Given a list of names, this method removes the name and value history from an EDU, in effect making the EDU smaller. Adds a user-defined EDU event to an EDU. Returns a list of EDUIDs that match a simple criterion. Finds one active local (assigned to) EDU based on a single search criterion. Identical to the Find method, but for each EDU found, it returns an EDUID and values that are indexed by the DUStore server. Issue 1.1 August 2003 67

EDU Server Methods Name VDU.FindOrCreate VDU.ForceTerminate VDU.ForwardEvent VDU.GetActive VDU.GetOne VDU.GetSomes VDU.GetSubTree VDU.GetUserSessions VDU.Gets VDU.GetHistory VDU.GetsHistory VDU.GetVariouss VDU.Incr VDU.Monitor VDU.RemoteWatcher VDU.SetAndTerminate VDU.SetAndTransfer VDU.SetDefaultHistoryFilter VDU.SetHistoryFilter Searches the local (assigned to) EDU server for an EDU that exactly matches all names and values in the search criteria. Forces the EDU object to be deleted from both memory and from the database, so it can no longer be used. Reserved. Finds all the active EDUs at the time the call is made. Retrieves one value from an EDU. Returns all names and values matching a container name. Returns all names and values matching a subcontainer name. Returns the sessions of all clients believed to have an interest in the EDU. Retrieves all of the values of an EDU. Returns everything that is known about the named field's values in an EDU. Returns everything that is known about all values in an EDU. Returns specified values of an EDU. A useful alternative to using SetOne and GetOne to modify a value when there is a risk that two applications might conflict. Changes Assign criteria. Reserved. Combines a Sets and a Terminate. Combines Sets and Transfer into a single call, as these operations often occur together. (historical) Reserved. Allows the caller to specify which types of events are saved when an individual EDU is sent to the IC Repository, overriding the default history filter for one EDU. 68 Electronic Data Unit Server Programmer Guide

EDU method overview Name VDU.SetOne VDU.SetOrIncrement VDU.Sets VDU.SetsExtended VDU.Terminate VDU.TerminateAndCreate VDU.TerminateDuplicate VDU.TerminateMine VDU.Touch VDU.Transfer Sets one EDU data element. Sets one or more EDU data elements unless the first character of the element to be set is either "+" or "-". In which case, the value is of the element is incremented by the number specified with the "+" or decremented by number specified with the "-". Sets one or more EDU data elements. Performs a Sets, but in addition returns a parallel list of names that it created while resolving container names. Removes the client's name from the list of interested parties for one EDU. Replaces VDU.FindOrCreate, which is obsolete. Locates all EDUs that match the search criteria, removes them, creates a new EDU, and initializes the new EDU. Notifies the EDU server that duplicate EDUs require elimination. Removes the client's name from the list of interested parties for all EDUs. Touches an EDU when it is called. Transfers an EDU. (historical) Issue 1.1 August 2003 69

EDU Server Methods VDU.Assign IDL Syntax ORBStatus Assign( in string monitorcriteria ) ; This method creates a session with the EDU server. When a session is created, events are sent to the Avaya IC client. When multiple EDU servers are in use, Assigns watch all calls in the domain of the EDU servers and notify the client with events when they occur. This makes Assign a relatively expensive operation. Design clients 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. (Refer to Cooperation of EDU servers on page 16, for additional information.) Input Parameters monitorcriteria Information used to select EDUs for monitoring, consisting of name and value strings. If values contain anything other than letters and numbers (for example, spaces), they should be enclosed in double quotes, and \ or " characters must be quoted by a \ character. Refer to Event Monitoring on page 35 for more information. Returns VESP_SUCCESS VESP_ERROR Request was successful. Request was unsuccessful. Example status = Vesp_Assign_Request( "VDU.Assign", callback, user_data, event_callback, session, "login=user" ); 70 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.Create IDL Syntax ORBStatus Create( in SeqCouple values, out VDU_ID vduid ) ; This method creates a new EDU. It is performed by the Avaya TS and is hidden from normal application development. The Avaya TS sets the creation timestamp and other information about the call. Refer to VDU.Create Example on page 127 for a programming example of an asynchronous create. Input Parameters values Initial values of the EDU, not to exceed 1023. Output Parameters vduid Electronic Data Unit identifier. Returns VESP_SUCCESS VESP_ERROR Request was successful. Internal error in EDU server. Issue 1.1 August 2003 71

EDU Server Methods Example _IDL_SEQUENCE_Couple *seq_couple; VDU_ID vduid; /* receives the id of the created VDU */ /* Create space for values */ seq_couple = vesp_couple_seq_create(); /* fill in the field for the new VDU entry */ vesp_couple_seq_add_couple_values( seq_couple, "name1", "value1" ); vesp_couple_seq_add_couple_values( seq_couple, "name2", "value2" ); vesp_couple_seq_add_couple_values( seq_couple, "name3", "value3" ); /* Create the new VDU */ status = Vesp_Request( "VDU.Create", callback, 0x2132, session, seq_couple, &vduid ); vesp_couple_seq_delete( seq_couple ); 72 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.CreateExtended IDL Syntax ORBStatus CreateExtended( in SeqCouple values, out VDU_ID vduid, out string timet) ; This method creates a new EDU and returns the time that the EDU was created. It is performed by the Avaya TS and is hidden from normal application development. The Avaya TS sets the creation timestamp and other information about the call. Input Parameters values Initial values of the EDU, not to succeed 1023. Output Parameters vduid timet Electronic Data Unit identifier. The time the EDU was created. Returns VESP_SUCCESS VESP_ERROR Request was successful. Internal error in EDU server. Issue 1.1 August 2003 73

EDU Server Methods VDU.Deassign IDL Syntax ORBStatus Deassign( ) ; This method destroys a session with the EDU server. When a session is deassigned, the flow of events from the EDU server to the client stops. Events may continue to arrive until the response for this method is received. It is not an error to deassign when no session exists. Returns VESP_SUCCESS Request was successful. VDU.DeleteOne IDL Syntax ORBStatus DeleteOne( in VDU_ID vduid, in string name) ; This method removes the name and value history from the EDU. This method is equivalent to Deletes with a single name. If used with a container name ( a.b ), you only delete that one name, a.b. This method is unable to address names below that point. Although a.b.c may still exist, the EDU server cannot find it, even though GetSubTree on a still sees them. Resolving a.b.c depends on resolving a.b, which no longer exists. You should not delete elements from non-leaf positions. Input Parameters vduid name Electronic Data Unit identifier. Name whose values are to be deleted from the EDU. 74 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.DeleteSubTree IDL Syntax ORBStatus DeleteSubTree( in VDU_ID vduid, in string name) ; This method does a DeleteOne on the given name and every name in the subcontainer beneath it, cutting a branch from the tree a container represents. If given a simple container name ( data ) it deletes the entire container. Input Parameters vduid name Electronic Data Unit identifier. Name whose values are to be deleted from the EDU. VDU.Deletes IDL Syntax ORBStatus Deletes( in VDU_ID vduid, in SeqString names) ; Given a list of names, this method removes from the name and value history from the EDU, in effect making the EDU smaller. s are deleted from active memory only. This method does not interact with the database. If used with a container name ( a.b ), you only delete that one name, a.b. The EDU server is unable to address names below that point. Although a.b.c may still exist, the EDU server cannot find it, even though GetSubTree on a still sees them. Resolving a.b.c depends on resolving a.b, which no longer exists. You should not delete elements from non-leaf positions. Input Parameters vduid name Electronic Data Unit identifier. List of names whose values are to be deleted from the EDU. Issue 1.1 August 2003 75

EDU Server Methods VDU.EventsIn IDL Syntax ONEWAY EventsIn(in string vdu_id, in SeqEvent events); This method adds an EDU event to an EDU. s in the EDU are updated to reflect the names and values in the event. Input Parameters vduid event Electronic Data Unit identifier. The event information. Each event must include an event name to describe the event. Requests without an event name are rejected. Returns Example No return value. One-way requests do not have any returns. Event *event; /* Create space for record */ event = vesp_event_create( "Update" ); vesp_event_add_couple( event, "name1", "value1" ); /* Create the new VDU History event entry */ status = Vesp_Request( "VDU.EventsIn", callback, 0x2132, session, vduid, event ); /* release memory we allocated */ vesp_event_delete( event ); 76 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.Find IDL Syntax ORBStatus Find( in string search_criteria, in unsigned long scope, out SeqString matches ) ; This method returns a list of EDUIDs that match a simple criterion. The EDUs found may be active, or stored in the DUStore server, or in other WAN EDU servers or DUStores, depending on the setting in scope. EDUs found in the DUStore server are not resurrected. If the search includes DUStores (VDU_ASK_OS, VDU_NET_ASK_OS ), the criterion is limited to an expression of the form: name = value & name = value in which the names are limited to indexed fields (defined by the Index configuration parameter). If the search does not include DUStores, the criteria can be any expression an Assign method would accept. The Find method, especially one distributed across the WAN, can take time, because it cannot reply until it receives a response from all the other servers it contacts and combines the lists it receives. A WAN-wide search proceeds in parallel across all involved EDU servers, but the speed is still limited to the speed of the slowest single search. In the worst case, the request may start other servers that had not been started yet, which can entail a significant delay. Input Parameters search_criteria scope Criteria to be used for the search, consisting of name and value strings. If values contain anything other than letters and numbers (for example, spaces), they should be enclosed in double quotes, and \ or " characters must be quoted by a \ character. Scope can be: VDU_NO_OS Check the local EDU server only. VDU_ASK_OS Check the local EDU server and local DUStore only. VDU_NET_NO_OS Check the WAN EDU servers but no DUStores. VDU_NET_ASK_OS Check WAN EDU servers and their DUStores. Issue 1.1 August 2003 77

EDU Server Methods Output Parameters matches List of VDUIDs meeting the search criteria. Note that an empty list is considered valid and returns VESP_SUCCESS. Returns VESP_SUCCESS VESP_PARTIAL_SUCCESS VESP_ERROR Request was successful if all the servers involved in the search responded even if no matches to the search were found. Some of the servers did not respond causing the results of the search to be incomplete. The search criteria was invalid or, in some cases, where a search that was expected to return results did not return results. Don't use the ORBStatus to determine if matches were found, check the length of the output sequence. If you need a complete list, check the to see if the VESP_PARTIAL_SUCCESS error code is received, and which server ids may not have been returned that otherwise would have. 78 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.FindByKey IDL Syntax ORBStatus FindByKey( in string name, in string value, out VDU_ID vduid ) ; This method finds one active local (assigned to) EDU based on a single search criterion, or key. Each EDU contains at least one unique element, typically the unique call ID supplied by the PBX/ACD. VDU.FindByKey() is used by the Telephony server. FindByKey() searches only the local EDU server for active EDUs. It does not resurrect EDUs from the DUStore database. Input Parameters name value Search key to find EDU. to match if name is found. Output Parameters vduid Electronic Data Unit identifier. Returns VESP_SUCCESS Request was successful. Example Locate a VDU having a key containing 1137. status = Vesp_Request( "VDU.FindByKey", callback, 0x2132, session, "key", "1137", &vduid ); Issue 1.1 August 2003 79

EDU Server Methods VDU.FindExtended IDL Syntax ORBStatus FindExtended( in string search_criteria, in unsigned long scope, out SeqSeqCouple matches ); The FindExtended() method is identical to the Find method, but for each EDU found, it returns a sequence of couples, the first element of which is the EDUID, and subsequent elements are values that are indexed by the DUStore. If the only purpose of finding a set of EDUs is to discover the values of fields that happen to be indexed by the DUStore, this method yields the needed values without the cost of resurrecting the EDUs that match. Input Parameters search_criteria scope Criteria to be used for the search, consisting of name and value strings. If values contain anything other than letters and numbers (for example, spaces), they should be enclosed in double quotes, and \ or " characters must be quoted by a \ character. Scope can be: VDU_NO_OS Check the local EDU server only. VDU_ASK_OS Check the local EDU server and local DUStore server only. VDU_NET_NO_OS Check the WAN EDU servers but no DUStores. VDU_NET_ASK_OS Check WAN EDU servers and their DUStores. Output Parameters matches List of EDUIDs meeting the search criteria and values indexed by the DUStore server. Note that an empty list is considered valid and returns VESP_SUCCESS. 80 Electronic Data Unit Server Programmer Guide

EDU method overview Returns VESP_SUCCESS Request was successful. VDU.FindOrCreate IDL Syntax ORBStatus FindOrCreate( in SeqCouple match, in SeqCouple oncreate, out string vdu_id) ; This method searches the local (assigned to) EDU server for an EDU that exactly matches all names and values in the match. It does not support wildcards. If a match is not found on the local EDU server, it searches other EDU servers. If a match is found, it returns the EDUID. If multiple matches are found, the EDUID of the most recently created EDU is returned. If no match is found, the local EDU server creates the EDU with the names and values from the combined list of match and oncreate. The EDUID is then returned. Note: Note: This method is obsolete in this release. It is still supported but we recommend you use the VDU.TerminateAndCreate method, which is documented in this book. Input Parameters name value Search key to find EDU. to match if name is found. Output Parameters vduid Electronic Data Unit identifier. Returns VESP_SUCCESS VESP_ERROR Request was successful. Requires values to find EDU. The match parameter may be empty. Issue 1.1 August 2003 81

EDU Server Methods VDU.ForceTerminate IDL Syntax ORBStatus EDU.ForceTerminate(in string duid) This method forces the EDU object to be deleted from both memory and the database, so it can no longer be used. VDU.ForwardEvent IDL Syntax ORBStatus ForwardEvent( in unsigned long handleis, in Event Event) ; This method is reserved. EDU servers use this method to pass events to each other. Client applications should not call this method. 82 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.GetActive IDL Syntax ORBStatus GetActive( out SeqVDU_ID vduseq ) ; This method finds all of the active EDUs that are in memory at the time the call is made. Only EDUs currently in memory, not those stored to disk by the DUStore, are found. Output Parameters vduseq A list of active EDUs. Returns VESP_SUCCESS Request was successful. Example SeqVDU_IDvdu_ids; /* Initialize a sequence of VDUs (0 specifies no limit) */ vdu_ids._maximum = 0; vdu_ids._length = 0; vdu_ids._buffer = NULL; status = Vesp_Request("VDU.GetActive", callback, user_data, session, &vdu_ids ); Issue 1.1 August 2003 83

EDU Server Methods VDU.GetOne IDL Syntax ORBStatus GetOne( in VDU_ID vduid, in string name, out string value ) ; This method retrieves one value from an EDU. Input Parameters vduid name Electronic Data Unit identifier. EDU element to be returned. Output Parameters value One returned value from the EDU. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDUID or name not found. Example Get the value of "myfavoriteelement" from the EDU named by vduid. char *value; status = Vesp_Request( "VDU.GetOne", callback, 0x2132, session, vduid, "myfavoriteelement", &value ); 84 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.GetSomes IDL Syntax ORBStatus GetSomes( in VDU_ID vduid, in string name, out SeqCouple matches) ; This method returns all names and values matching a container name. It is one of the few that accepts the * token. As such, a name of data.*.emergency returns names such as data.1.emergency, data.scott.emergency, and so on. Input Parameters vduid name Electronic Data Unit identifier. A name. By intent, a container. Output Parameters matches All names and values in the subcontainer. Issue 1.1 August 2003 85

EDU Server Methods VDU.GetSubTree IDL Syntax ORBStatus GetSubTree( in VDU_ID vduid, in string name, out SeqCouple matches) ; This method returns all names and values in the subcontainer named by name. It can be given a container name (agent) or a subcontainer name (agent.2) and returns all names and values from that point down. Input Parameters vduid name Electronic Data Unit identifier. A name. By intent, a container or subcontainer name. Output Parameters matches All names and values in the subcontainer. 86 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.GetUserSessions IDL Syntax ORBStatus GetUserSessions( in string vduid, out SeqString users) ; This method returns the sessions (as strings) of all clients believed to have an interest in the EDU. If empty, the EDU is being held in memory by a grace timer, such as nonuserinterval. Input Parameters vduid Electronic Data Unit identifier. Output Parameters users Session of interested clients. Returns VESP_SUCCESS Request was successful. Issue 1.1 August 2003 87

EDU Server Methods VDU.Gets IDL Syntax ORBStatus Gets( in VDU_ID vduid, out SeqCouple values ) ; This method retrieves all of the values of an EDU. Input Parameters vduid Electronic Data Unit identifier. Output Parameters values A sequence to contain EDU information. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDUID was not found. Example Get all of the data elements active in a specific EDU. _IDL_SEQUENCE_Couple *values; /* init an empty, unlimited sequence of Couples */ seq_couple = vesp_couple_seq_create(); status = Vesp_Request( "VDU.Gets", callback, 0x2132, session, vduid, seq_couple); 88 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.GetHistory IDL Syntax ORBStatus GetHistory( in string vduid, in string name, out SeqString values, out SeqString when, out SeqString who ) ; This method returns everything that is known about the named field's values in an EDU. It reports on all the values the field has had (up to the limit specified with the maxkeptrevisions configuration parameter), who set them, and when. The returned arrays are parallel, the lowest element is the most recent. Input Parameters vduid name Electronic Data Unit identifier. The name of an EDU field. Output Parameters values when who A list of values to which the named field has been set. When the field was set to each value, time_t string. The login ID (consistent with EDU.GetsHistory) of the client that set each value. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDUID was not found. Issue 1.1 August 2003 89

EDU Server Methods VDU.GetsHistory IDL Syntax ORBStatus GetsHistory( in VDU_ID vduid, in unsigned long flags, out SeqLong headers, out SeqString names, out SeqSeqSeqString values ) ; This method returns everything that is known about all of values in an EDU. For each named field in an EDU, this method reports on all the values the field has had (up to the limit specified with the maxkeptrevisions configuration parameter), who set them, and when. By providing the various VDU_GSGET flags, you can control which of these values are returned. The output in headers is a list of your specified flags, one per long integer. This indicates the order in which the bottommost sequence of strings in the values parameter are filled. Thus, if you specify (VDU_GSGETVALUE VDU_GSGETTIME), headers would come back with two long integers, one containing VDU_GSGETVALUE and one containing VDU_GSGETTIME. The bottommost sequences in the values parameter would list values in the same order. The output in names is a list of all the data names within the EDU. Container elements each get their own entry. The topmost sequences in values are in the name order, so if names[3] is x, values[3] is the sequence that describes the history of x. s itself runs three deep. The topmost level is parallel to the names sequence. The next level down represents one entry for each value that names has had over time. If a value has only been set once (a common case) this sequence only has one element. The lowest level runs parallel to the headers parameter, and has one element for each of the kinds of data requested (any combination of text, time, and who). For example, field quark was set twice, once at EDU creation (11:37:00am, by Scott, to truth ) and again at call transfer (11:38:00, by Jane, to charm ). Specifying flags = VDU_GSGETTIME VDU_GSGETVALUE VDU_GSGETWHO would yield: header[0] = VDU_GSGETVALUE; header[1] = VDU_GSGETTIME; header[2] = VDU_GSGETWHO; //first subelement is the text //second is time //third is who names[?] = quark ; //one of the names returned will be quark 90 Electronic Data Unit Server Programmer Guide

EDU method overview values[?][0][0] = truth ; values[?][0][1] = 8145264302 ; values[?][0][2] = Scott ; values[?][1][0] = charm ; values[?][1][1] = 8145264362 ; values[?][1][2] = Jane ; //values[13] is parallel to names[13], and the //first value that was set was truth //the time_t it was set (11:37:00am) //Scott set it //next value set was charm //set at this time //by this loginid Input Parameters vduid flags Electronic Data Unit identifier. One or more of the VDU_GSGET flags, OR'd together. Flags are: #define VDU_GSGETVALUE 0x01 #define VDU_GSGETTIME 0x02 #define VDU_GSGETWHO 0x04 Output Parameters headers names values A list of VDU_GSGET values. A list of EDU data names. A list of data values (one per name), which are lists of value histories (one per value), which are lists of fields (text, when, and who). Returns VESP_SUCCESS VESP_ERROR Request was successful. EDUID was not found. Issue 1.1 August 2003 91

EDU Server Methods VDU.GetVariouss IDL Syntax ORBStatus GetVariouss( in string vduid, in SeqString names, out SeqCouple data) ; This method retrieves specified values of an EDU. Input Parameters vduid names Identifier of EDU from which to request values. Name(s) of the value(s) to retrieve. Can contain wildcards to provide a different number of outputs and inputs. The order of outputs does not correspond to the order of inputs and duplicate outputs are removed. Output Parameters data Returned values of the EDU. 92 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.Incr IDL Syntax ORBStatus Incr( in VDU_ID vduid, in string name, in long incr, out string newvalue ) ; This method is a useful alternative to using SetOne and GetOne to modify a value when there is a risk that two applications might conflict. It changes one EDU data element. Elements that do not exist, are created, existing elements are overwritten if permission allows. The value of the element is treated as a number, and converted to a long integer (by use of the C atol function). The specified increment is added, and the element s value is set to the result. Elements that do not exist are treated as if they contained a zero (0). The increment may be a negative value. The atol function returns 0 if it cannot recognize a number.this method stores the resulting, incremented value as a decimal digit string without extraneous spaces or leading zeros. Thus, incrementing x2 by one results in 1 and incrementing 00034E6 by one results in 35. Input Parameters vduid name incr Electronic Data Unit identifier. Name of the element to change or create. The increment value. Output Parameters newvalue The new value of the element, after the increment. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDUID was not found or the element cannot be changed. Example char *result; status = Vesp_Request( "VDU.Incr", callback, 0x2132, session, vduid, "some_numeric_element", 1L, &result ); Issue 1.1 August 2003 93

EDU Server Methods VDU.Monitor IDL Syntax ORBStatus Monitor( in string monitorcriteria ) ; This method changes Assign criteria. It works like Assign in all respects. You must have previously assigned (and have not since deassigned) to use this method. Input Parameters monitorcriteria Monitor criteria, consisting of name and value strings. If values contain anything other than letters and numbers (for example, spaces), they should be enclosed in double quotes, and \ or " characters must be quoted by a \ character. Refer to Chapter 3, Event Monitoring for additional information. Returns VESP_SUCCESS VESP_ERROR Request was successful. Invalid monitor criteria. 94 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.RemoteWatcher IDL Syntax ORBStatus RemoteWatcher( in unsigned long handleis, in string cri) ; This method is reserved. Client applications should not call this method. When multiple EDU servers are listed in one directory, any Assign, Monitor, or Deassign method invocation is communicated by the local (assigned to) EDU server to all other EDU servers by a RemoteWatcher method invocation. RemoteWatcher events are included in the EDU server log file following Assign, Monitor, or Deassign events. They take the form: uuid.remotewatcher( nnnn, "abcde" ) where: uuid is the UUID of the EDU server nnnn is a number used internally abcde is a string identifying the Assign or Monitor criteria. A blank string indicates a Deassign method invocation VDU.SetAndTerminate IDL Syntax ORBStatus SetAndTerminate( in VDU_ID vduid, in SeqCouple data ) ; This method combines a Sets and a Terminate. It is recommended for efficient call wrapup. Input Parameters vduid Electronic Data Unit identifier. data s to be set, not to exceed 1023 values. Issue 1.1 August 2003 95

EDU Server Methods VDU.SetAndTransfer IDL Syntax ORBStatus SetAndTransfer( in VDU_ID vduid, in string to, in SeqCouple values ) ; This historical method combines Sets and Transfer into a single call, as these operations often occur together. If the operation succeeds, it generates a Transfer event containing all changes made to the VDU. This operation is usually performed by Telephony components, not client software. Input Parameters vduid to values Electronic Data Unit identifier. A string representing the receiving client. A list of names and values to apply to the EDU, not to exceed 1023. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDU not found, set failed, or client not a valid string. Example /*Transfer a VDU. */ char *to; _IDL_SEQUENCE_Couple *values; /* init an empty, unlimited sequence of Couples */ seq_couple = vesp_couple_seq_create(); /* fill in the field for the new VDU entry */ vesp_couple_seq_add_couple_values( seq_couple,"loginid", "meritha" ); to = ORB_object_to_string( VESP_ORB, &environment, to_object); status = Vesp_Request( "VDU.SetAndTransfer", callback, 0UL, session, vduid, to, seq_couple ); vesp_couple_seq_delete( seq_couple ); 96 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.SetDefaultHistoryFilter IDL Syntax void SetDefaultHistoryFilter( in unsigned long mask ) ; This method is reserved. Client applications should not call this method. This method allows the caller to specify which types of events are saved when EDUs are sent to the IC Repository (or other database specified with the eventsink configuration parameter). The filter takes effect in subsequently created EDUs, not existing ones. All events generated for all subsequent EDUs are checked against the permissions in the bits set in the mask argument. Events already generated are not affected. The SetHistoryFilter() method can be used to override the default filter for individual EDUs. The bits are defined in the file "vespidl.idl" as: HS_NOSTART HS_NOCHANGE HS_NOTRANSFER HS_NOUSER HS_NODELETE (unsigned short)0x01 Do not record new events (unsigned short)0x02 Do not record change events (unsigned short)0x04 Do not record transfer events (unsigned short)0x08 Do not record user-defined events (unsigned short)0x10 Do not record delete events End events (VDU.End) cannot be filtered out. They must be included in the stored EDUs. Issue 1.1 August 2003 97

EDU Server Methods VDU.SetHistoryFilter IDL Syntax ORBStatus SetHistoryFilter( in VDU_ID vduid, in unsigned long mask ) ; This method allows the caller to specify which types of events are saved when an individual EDU is sent to the IC Repository (or other database specified with the eventsink configuration parameter), overriding the default history filter for one EDU. The filter takes effect immediately. All subsequent events generated are checked against the permissions in the bits set in the mask argument. Events already generated are not affected. The bits are defined in the file vespidl.idl as: HS_NOSTART HS_NOCHANGE HS_NOTRANSFER HS_NOUSER HS_NODELETE (unsigned short)0x01 Do not record new events (unsigned short)0x02 Do not record change events (unsigned short)0x04 Do not record transfer events (unsigned short)0x08 Do not record user-defined events (unsigned short)0x10 Do not record delete events The end event (VDU.End) cannot be filtered out. It must be included in the stored EDU. Input Parameters vduid mask Electronic Data Unit identifier. Permission bits to be set. Returns VESP_SUCCESS Request was successful. 98 Electronic Data Unit Server Programmer Guide

EDU method overview Example Vesp_Request_Sync( "VDU.SetHistoryFilter", /* method identification */ &ev, /* environment pointer */ session, /* session object */ &request, /* pntr to pntr to request structure */ vduid, /* a vdu id */ HS_NOUSER /* check ev for errors as needed */ Vesp_Request_Delete(session, request); /* The permission bit to be set for this VDU */ ); Issue 1.1 August 2003 99

EDU Server Methods VDU.SetOne IDL Syntax ORBStatus SetOne( in VDU_ID vduid, in string name, in string value ) ; This method sets one EDU data element. An element that does not exist is created. An element that exists is overwritten if permission allows. The following fields are restricted and cannot be changed by applications: vduid transfercount createtime endtime owner termination duration update_time Setting values can generate Watch, Change, and Drop events. Input Parameters vduid name value Electronic Data Unit identifier. The name of the EDU element to change or create. The value to be set. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDU not found or the element cannot be set. Example /*Set one value. */ status = Vesp_Request( "VDU.SetOne", callback, 0x2132, session, vduid, "my_favorite_element", "new value" ); 100 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.SetOrIncrement IDL Syntax ORBStatus SetOrIncrement( in vduid, in SeqCouple values, out string newvalue ) ; This method sets one or more EDU data elements unless the first character of the element to be set is "+" or "-". In this case, the value of the element is incremented by the number specified with the "+" or decremented by number specified with the "-". The current element value is treated as a number. It is converted to a long integer using the C function atol. The specified increment is added and the value of the is set to the result of the increment. The new value is written back using sprintf with a "%Id" specifier. If the value that is being incremented or decremented is not set, not numeric, or empty, it is treated as "0". For example, if the EDU contains the element "contactcount" with a value of 17x, the method SetOrIncrement, with a single couple {"contactcount", "+3"}, finds the value of "contactcount", evaluates it as a number, and adjusts it up by 3. The element "contactcount" is stored back into the ADU with a value of "20". If the value of the couple is {"contactcount", "3"} without a "+" or "-" as the first character of the value, this method sets the value of the ADU to "3". Input Parameters vduid values Electronic Data Unit identifier. The name of the ADU element to change or create and the increment value. Output Parameters newvalue The new value of the element after the increment. Returns VESP_SUCCESS VESP_ERROR Request was successful. The EDUID was not found or the element cannot be changed. Issue 1.1 August 2003 101

EDU Server Methods Example char *result status = Vesp_Request( "VDU.SetOrIncrement", callback, 0x2132, session, vduid, "newvalue" ); VDU.Sets IDL Syntax ORBStatus Sets( in VDU_ID vduid, in SeqCouple values ); This method sets one or more EDU data elements. Data elements that do not exist are created. Existing elements are updated if permission allows. The following fields are restricted and cannot be changed by applications. vduid transfercount createtime endtime owner termination duration update_time Setting values can generate Watch, Change, and Drop events. Input Parameters vduid values Electronic Data Unit identifier. A sequence containing EDU information, not to exceed 1023 values. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDU not found or the values not able to be set. Example /* Example of an initialized sequence with fixed values: */ status = Vesp_Request( "VDU.Sets", callback, 0x2132, session, vduid, &values ); 102 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.SetsExtended IDL Syntax ORBStatus SetsExtended( in VDU_ID vduid, in SeqCouple data, out SeqString newnames) ; This function performs a Sets, but in addition returns a parallel list of names that it created while resolving container names. For example, if the data SeqCouple contained two names, agent.!.x and data.+, the newnames list might be returned containing agent.2.x and data.4. This method is useful for applications that need to know how names were generated, especially for applications that make repeated use of the + token and need to be able to go back and fill in values in the various subcontainers they have created. The following fields are restricted and cannot be changed by applications: vduid transfercount createtime endtime owner termination duration update_time Setting values can generate Watch, Change, and Drop events. Input Parameters vduid Electronic Data Unit identifier. data s to be set, not to exceed 1023. Output Parameters newname List of names created to resolve container names. Issue 1.1 August 2003 103

EDU Server Methods VDU.Terminate IDL Syntax ORBStatus Terminate( in VDU_ID vduid ) ; This method indicates that the application is finished with the EDU and no longer needs to access it. This gives it permission to be deleted entirely from the servers, which includes DUStore but not IC Repository. If an application is done with an EDU for the moment but expects to need it again later, it should call the Suspend method instead of Terminate. EDUs are not deleted until all applications have called a Terminate method against them or if the EDU remains unused in the DUStore server for a specified number of days. Input Parameters vduid Electronic Data Unit identifier. Returns VESP_SUCCESS VESP_PARTIAL_SUCCESS VESP_ERROR Request was successful. the EDU is gone. The EDU was not found in memory. Specified EDU does not exist. Example status = Vesp_Request( "VDU.Terminate", callback, 0x2132, session, vduid ); 104 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.TerminateAndCreate IDL Syntax ORBStatus TerminateAndCreate( in string type, in SeqCouple criteria, in SeqCouple data, out string vduid ) ; This method is used to create an EDU that is unique for a resource. The new EDU is created on the local (assigned to) EDU server and initialized based on the type, criteria, and initial values provided. This method then searches local and remote EDU servers for all other EDUs that match the specified type and criteria, with the exception of EDUs persisted in the database. This method deletes any matching EDUS that are found and returns the EDUID of the new EDU. Input Parameters type criteria data Type of EDU to be found and created. This is the value in the type field in the EDU. Search criteria, in addition to type, used to establish which EDU is to be found and created. For example: {{"loginid", "kevin"}} s, in addition to type and criteria, used when the new EDU is initialized. Output Parameters vduid Identifier of the EDU that is created. Returns VESP_SUCCESS VESP_PARTIAL_SUCCESS VESP_BAD_PARAMETER VESP_ERROR Request was successful. One or more remote EDU servers could not be found. A parameter is invalid. An error occurred performing the request. Example status = Vesp_Request( "VDU.TerminateAndCreate", callback, OUL, session, "per", criteria, data, &new_vduid ); Issue 1.1 August 2003 105

EDU Server Methods VDU.TerminateDuplicate IDL Syntax ORBStatus TerminateDuplicate( in string type, in SeqCouple criteria, in unsigned long scope, in string validdu ) ; This method is used to eliminate duplicate EDUs if they are detected. This method searches the local and (if requested) remote EDU servers for all EDUs that match the specified type and criteria. This method than deletes any EDUs that are found other than the valid EDU (duplicate EDUs). Input Parameters type criteria scope validdu Type of EDU to be found. This is the value in the type field in the EDU. Search criteria, in addition to type, used to establish which EDU is to be found. For example: {{"loginid", "kevin"}} Indicates which EDU servers are checked and whether the DU Store should be included in the search. s are: NO_OS local EDU server only ASK_OS local EDU server and its DUStore server NET_NO_OS All EDU servers NET_ASK_OS All EDU servers and their DUStore servers. ID of the current and valid EDU. This EDU should not be terminated. Returns VESP_SUCCESS VESP_PARTIAL_SUCCESS VESP_BAD_PARAMETER VESP_ERROR Request was successful. One or more remote EDU servers could not be found. A parameter is invalid. An error occurred performing the request. Example status = Vesp_Request( "VDU.Duplicate", 0UL, 0x2132, session, "queue", criteria, EDU_NO_OS, known_vduid ); 106 Electronic Data Unit Server Programmer Guide

EDU method overview VDU.TerminateMine IDL Syntax void TerminateMine( ) ; Returns When an EDU is created, read, modified, or transferred, the client's name is added to an internal list of clients. When this method is invoked, the client's name is removed from the list for all EDUs. When each EDU's list is empty, the EDU is purged and, optionally, sent to the IC Repository. The Terminate() method is marginally faster than TerminateMine(), and is therefore preferable when the EDUID is known. It is important to realize that transferring a call does not automatically end a client s responsibility toward the EDU. The client must use the VDU.Terminate() or the VDU.TerminateMine() method to signal that it has no further interest in each EDU. There is no return value. Example status = Vesp_Request( "VDU.TerminateMine,"callback, 0x2132, session) ; VDU.Touch IDL Syntax ORBStatus Touch( in string vduid ) ; This method accesses an EDU when it is called to prevent it from being harvested from memory out of idleness. It adds the caller to the list of interested parties for the EDU. If the caller is already on the list, this method does nothing. Input Parameters vduid Electronic Data Unit identifier. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDU not found in memory or the DUStore server. Issue 1.1 August 2003 107

EDU Server Methods VDU.Transfer IDL Syntax ORBStatus Transfer( in VDU_ID vduid, in string to ) ; This historical method transfers an EDU. A successful transfer changes the value of the transfercount element and generates an EDU.Transfer.event to any process watching the VDU. This operation is usually performed by Avaya IC components, not client software. Transferring an EDU does not end the client s responsibility to the EDU. When the client has finished processing the EDU, the client must use VDU.Terminate() to signal that it has no further interest in modifying the EDU. Input Parameters vduid to Electronic Data Unit identifier. A string representing a new client. Returns VESP_SUCCESS VESP_ERROR Request was successful. EDU not found or the client is not a valid string. Example /* Transfer a VDU */ char *to; to = ORB_object_to_string(VESP_ORB, &environment, object); Vesp_Request( "VDU.Transfer", callback, 0UL, session, vduid, to); 108 Electronic Data Unit Server Programmer Guide

Overview Chapter 8: The DUStore Server This chapter describes the Avaya DUStore server. This section includes the following topics: Overview on page 109 DUStore database on page 110 DUStore functions on page 111 DUStore server method overview on page 125 Overview As Avaya IC has evolved to provide connectivity to multiple media channels such as voice, chat, and email, the need to manage the resulting objects that may remain in memory for a longer period becomes more important to the contact center. Improving the recovery of ADU and EDU data during system faults is also important because customer interactions, previously measured in seconds and minutes for telephone calls, are now measured in hours or even weeks for emails and chats. The DUStore server has been developed to replace the VDUOS server to address these issues. The DUStore server interfaces to a database of inactive EDUs. It stores EDUs in the database in their entirety. When an EDU server method is invoked for an EDU that is no longer in memory, the DUStore server restores the EDU as if it were assigned to an active contact. This ability is transparent to the client application. You can also delete expired EDUs from the database using the DUStore server. Issue 1.1 August 2003 109

The DUStore Server DUStore database The DUStore server interfaces to a DCO-enveloped database to take advantage of the database independent features provided with DCO. The database must be previously installed and fully functioning on the system. The data that is stored by the DUStore server is encoded by the EDU server and cannot be decoded by other clients or servers, including the DUStore server. EDU records are accessed by key fields, which are specified with the EDU server s Index configuration parameter. A maximum of three key fields, in addition to the EDUID key field, can be specified. An additional two non-key fields may also be specified. DUStore database table The following table describes the DUStore database table: Field Name Index Type Width vdu_id Yes char 32 The EDUID of the object from EDU server. This field is unique for all of the records in the database. deletedatetime Yes char 32 The date and time, at or after, when the object should be deleted. data No Var-length char NA EDU data information in proprietary format. datalength Yes char 32 The number of bytes in the Data field. lookup1 Yes char 32 Indexed field that can be associated with the EDUID. lookup2 Yes char 32 Indexed field that can be associated with the EDUID. info1 No Var-length char info2 No Var-length char info2 Ni Var-length char NA NA NA Additional information that can be associated with the EDUID. Additional information that can be associated with the EDUID. Additional information that can be associated with the EDUID. 110 Electronic Data Unit Server Programmer Guide

DUStore functions DUStore functions The DUStore server works with DU (ADU and EDU) servers. These servers provide two main functions. Allow idle DU records to remain active in the system for extended periods without adding to the overhead of the associated DU server. Provide a backup server to store DU records in the case the DU server is shut down, either normally for maintenance or abnormally due to an abnormal shutdown. The other DUStore server functions are: Deleting EDUs when they are ended. Purging EDUs that have been forgotten. EDU behavior In the DUStore server model, an EDU is either Active or Deleted. If an EDU is Active, it may be Cached in the EDU server s memory or Persisted in the DUstore database. An Active EDU can therefore be in one of the following states: Active:Cached Active:Persisted Deleted The EDU server treats EDUs in either of these Active states the same with the possible exception of some timing implications. When an EDU is created, it is in the Active:Cached state. It remains in that state until one of the following occurs: It is idle for a configured period of time, usually under 3 hours. It needs to be removed from cache to make room for another EDU. All users who have read or written the EDU have done a Terminate or Suspend method on the EDUID. The server is shut down. If the EDU is brought from the DUStore server to the EDU server, it remains cached until these same conditions occur. The EDU server can store copies of EDUs in the DUStore server without changing the status of the EDU to Active:Persisted for backup purposes in the event of an EDU server failure. This is called checkpointing and it is a configurable parameter for the EDU server. Refer to Configuration parameters, on page 51 for more information. Issue 1.1 August 2003 111

The DUStore Server Configuration parameters Each EDU server is associated with a DUStore server through its domain setting in IC Manager. Information on assigning servers to domains is provided in IC Administration Volume 1: Servers & Domains. Refer to Configuration parameters on page 51 for a complete description of the EDU server configuration parameters. The DUStore server is configured on the Server Editor of IC Manager. This section provides DUStore server configuration parameters sorted by the multiple tabs of the DUStore Server Editor. Refer to IC Administration Volume 1: Servers & Domains for more information on setting these configuration parameters. For configuration instructions, refer to IC Administration Volume 1: Servers & Domains. This section includes the following topics: DUStore tab on page 112 Debug tab on page 113 DUStore processing on page 114 DUStore tab Enter or modify these parameters on the DUStore tab of the DUStore Server Editor. Right mouse click on the screen and select the Show Advanced Properties option to display all of these parameters: Field Recommended entry Notes IC Data Source Default deletion age (Days) Select the IC Data Source, which is the ADL file, for the IC Repository database. Enter the number of days that Avaya IC holds an EDU in absence of other information. Default is 60 days. If you used the default name, select: ccq_contact for CallCenterQ repository for IC Repository interaction_center for IC Avaya ICAfter this period, the DUStore deletes the EDU from the DUStore table and retires the EDU to the database. 112 Electronic Data Unit Server Programmer Guide

Configuration parameters Field Recommended entry Notes Deleted per scan Scan Interval (min) Purge Alarm Enter the number of EDUs the DUStore retires to the database when it scans the system for expired EDUs. Default is 1000. Enter the period of time, in minutes, the server scans for expired EDUs. Default is 15. Check to raises an alarm if a delete scan finds any EDUs that meet the criteria for deletion and retirement to the database. Default is checked. Higher values may save some CPU time; lower values make for more predictable behavior during prototyping and testing. Assume that other timers in the EDU could be off by as much as (this interval + 1) to start. Advanced Property Table Enter the name of the table in which the DU data is stored. Debug tab The Debug tab does not include any DUStore server-specific parameters. Issue 1.1 August 2003 113

The DUStore Server DUStore processing The DUStore server interacts with DU (ADU and EDU) servers. The DUStore server provides two main functions. A way for idle DU records to remain active in the system for extended periods without adding to the overhead of the associated DU server. A backup server to store DU records in the case the DU server is shut down, either normally for maintenance or abnormally due to an abnormal shutdown. For configuration instructions, refer to IC Administration Volume 1: Servers & Domains. This section includes the following topics: DUStore processing for idle DU records on page 114 Processing as a backup of EDU data on page 115 Temporary EDUID storage on page 116 Deleting EDUIDs on page 117 EDUIDs in Report server vs. DUStore server on page 117 Removing records from database tables on page 118 Troubleshooting and testing on page 118 Parameter setting example on page 119 DUStore processing for idle DU records Every contact interaction that is tracked by Avaya IC has an associated EDU record. Agents and queues have associated ADU records. Client components work with EDUs and ADUs by issuing requests to the DU (EDU or ADU) server. Each client must terminate its interest in DUs that are read or updated. The DU server maintains a record of all clients that have used particular DUs. The DU stays active until all clients have terminated their interest in it. The DU servers have a configuration parameter, idle time, which is the approximate number of minutes a DU record will be maintained by the DU server without any client requests. If a DU is active in the DU server and has not been requested or updated for a length of time greater than the specified idle time, the DU server removes the DU from its control. If a DUStore server is used, the record is then processed by the DUStore server and written to the DUStore database. If a client makes a subsequent request for the DU record that is no longer in memory, the DU server will request the record from the DUStore. The DUStore then retrieves the record from the database and provides the DU record to the DU server. The DU server then completes the request. 114 Electronic Data Unit Server Programmer Guide

DUStore processing Considerations for configuring the DUStore server idle time setting: Overhead is required to use the DUStore, so the idle time should set at longer than the maximum amount of time a voice or chat contact will be in the system without active EDU server activity. Email contacts are often in queue for significant periods of time. For example, the center may operate Monday through Friday, but email can arrive anytime. An email contact could be in queue for several days. It is unusual for chat or voice contacts to be in queue or in process with the agent for more than 30 minutes. For this reason, the DUStore server often acts as part of the normal process for email, but as an exception process for voice and chat. You may want to use the DUStore server as part of standard processing for voice or chat when using special processing such as virtual hold applications. As a general rule, idle time should be set at a value that is long enough to keep the EDU in active status on the EDU server for all interactions that actively involve a customer or agent. Allow the EDU to be stored in the DUStore server when the customer or agent is not working actively with the interaction. Processing as a backup of EDU data You can use EDU Data to store critical information. When the EDU record is normally ended (all interested parties have terminated interest), the critical data contained in the EDU record is written by the Report server into the IC Repository database. When the EDU server sends EDUs to the DUStore server, it issues a VDU.auRevoir event to the Report server. If the EDU server is shut down with active EDUs, the data associated with those EDUs will be lost unless the DUStore server backs up the data. The following EDU server configuration parameters are related to backup functionality. Enable Persistence. If checked, the DUStore server is used for backup functions. If unchecked, backup functionality is not provided. Avaya IC performs with full integrity with Enable Persistence turned off in situations where the data stored in the EDU is not used for back end reporting. Possible scenarios for disabling persistence could be an ADU server or an EDU server using voice or chat only. Checkpoint frequency. The default value is -1, which means that no checkpointing is performed. If the -1 value is used, the DUStore server is not used for backup functions unless the EDU server is shutdown normally. During the shutdown process, all active EDU records are written to the DUStore server, providing backup functionality. Checkpoint frequency should be set if the data contained in the active EDU is critical enough to merit the checkpoint overhead. If enabled, at an EDU server scan interval, all active EDUs that have not been written to the DUStore server within the checkpoint frequency will be updated. Issue 1.1 August 2003 115

The DUStore Server Note that this does not guarantee that changes will not be recorded for the given length of time. It does guarantee that a rapid series of changes will not cause a rapid series of updates to the database. Changes are gathered so that database is not hit more often than Interval seconds apart. When checkpointing is enabled, the goal is to record DU data in the database as soon as possible, because the reason for checkpointing is to assist recovery if the system crashes. The checkpoint interval merely prevents rapid changes from accessing the database faster than it can respond. In the case of the alarm at server shutdown, the server only writes to the DUStore server the data it needs to, to insure the DU is intact. When the system has recovered, a client requesting the specific EDU causes the EDU to be restored from the DUStore server. If a client request is not made, the EDU is not recovered. Temporary EDUID storage The DUStore server is used by the EDU server to temporarily store certain EDUID. The DUStore server stores the EDUID and all of its information as a binary "blob" in the qw_dustore table (normally of the same IC Repository database). Note that in Oracle, the actual binary "blob" is stored in the qw_bytes table with a key to the qw_dustore table. When the EDU server receives a request (VDU.Sets, VDU.Gets, etc.) on a particular EDUID that is not in its memory, it issues a request (DUStore.Retrieve) to the DUStore server to see if the EDUID is temporarily stored. If the EDUID exists in the DUStore server, the EDU server reactivates and uses it as if it was in the EDU server's memory. The EDU server sends an EDUID to the DUStore server the following ways: 1. When an EDUID reaches the value set in the Max Active Edus (vdus) parameter on the EDU server, the EDUID is sent to the DUStore server via the DUStore.Store method. The EDU server also raises an alarm indicating that its Max Active Edus have been reached, the oldest active EDUID is sent to the DUStore server. The default value for the Max Active Edus is 2048. The values depend on the number of calls your contact center can receive. 2. The EDU server has a timer called Idle Time (idletime), which has a default of 30 minutes for a contact. In pre-econtact 5.6, if a contact's EDUID reaches the Idle Time, it was terminated and, if applicable, the terminated EDUID was sent to the Report server for storage in the IC Repository database. This has changed in versions econtact 5.6, IC 5.6 and IC 6.0. The EDUID is not terminated, it is sent to the DUStore server and an HISTMAP.EventsIn is issued to the Report server for a VDU.auRevoir. 3. When the EDU server is shut down in IC Manager, all of the EDUIDs in the EDU server's memory are sent to the DUStore server via the DUStore.Store method. 116 Electronic Data Unit Server Programmer Guide

DUStore processing When an EDUID is sent to the DUStore server, it is assigned a Default Delete Deletion Age value. The default is 60 days. After such days, the EDUID is deemed to be expired. The DUStore server scans for expired EDUIDs based on Scan Interval and l deletes the expired EDUIDs from the qw_dustore table based on the Deleted Per Scan setting. Deleting EDUIDs This section describes how the DUStore server deletes EDUIDs. 1. The DUStore server scans the expired EDUID and depending upon "Deleted per scan" parameter (The number of EDU s that are deleted each time the system is scanned for EDUs that have expired, Default is 1000.), it deletes the expired EDUIDs from the qw_dustore table. It then issues a VDU.ForceTerminate to the EDU server for each expired EDUID. The EDU server, if applicable, issues a HISTMAP.EventsIn with a VDU.end to the Report server to store each of the EDUIDs. 2. The number of days EDUIDs are held before they are deemed to be expired depends on the "Default delete deletion age" parameter, which is the number of days that the EDUIDs are held. This value is set when EDUIDs are sent from the EDU server to the DUStore server. The value is stored in the qw_dustore.deletedatetime field and is a specific date and random time. The default value is 60 days. EDUIDs in Report server vs. DUStore server The Report server stores EDUIDs that were terminated by the EDU server. This means that either all of the clients of the EDUID terminated their interest in the EDUID or the EDU server forced a termination of the EDUID. The EDU server issues a HISTMAP.EventsIn method to the Report server for a VDU.end. The DUStore server stores EDUIDs that are still active (clients still have interest in the EDUID) and need to be moved from the EDU server's memory, for one reason or another. The EDU server issues a DUStore.Store method to the DUStore server and sometimes a HISTMAP.EventsIn method for a VDU.auRevoir to the Report server. Note that if and when all clients of an EDUID that is stored in the DUStore server terminate their interest in the EDUID, the EDU server issues a DUStore.Retrieve method to retrieve the EDUID from the DUStore server. Then the EDU server sends a HISTMAP.EventsIn method for a VDU.end to the Report server to store the EDUID in the IC Repository database. Issue 1.1 August 2003 117

The DUStore Server Removing records from database tables Under normal processing, DUStore data is deleted from DUStore database tables when the associated EDU is written to IC Repository. When all interested clients terminate their interest in the EDU, the Report server writes the mapped DU data to the IC Repository database tables. The EDU server then tells the DUStore server to delete the associated EDU the DUStore database tables. The DUStore server can also purge forgotten or orphaned EDUs from the DUStore database. The DUStore server configuration parameter Default delete deletion age has a default value of 60 days, which is appropriate for contacts (such as email) that are active for an extended time. Forgotten voice and chat contacts should be purged sooner, for example within 1 day. When an EDU is written to the DUStore server, the DUStore server adds the number of days in the deletion age parameter to the current date and time to determine the purge date and time. A random time is added to the value as well to reduce the number of EDUs that will be purged at the same time due to a server shutdown. The purge alarm check box causes alarms to be raised when EDUs are purged. In normal processing, EDUs should not be purged, but should be deleted as part of the normal termination process. For this reason, turning this alarm on is appropriate to enable diagnostic analysis if EDUs are purged. When an EDU is purged, the EDU server is notified to cause the EDU to be ended on the EDU server. This sends the appropriate information to the Report server. The Report server writes this information to IC Repository. Troubleshooting and testing During the test cycles, the integration team should monitor the DUStore server logs and the DUStore database tables to ensure that the DUStore server is working as expected. For example, if the DUStore server is associated with an EDU server configured for voice only and checkpointing is turned off (-1), testing should show no activity in the DUStore server. If EDUs are written to the DUStore server, the associated EDU may have been forgotten. This can be caused by workflows or IC Scripts failing to terminate interest in the EDU. This can also occur when vectoring or other switch based processing does not communicate the status of a contact to the Avaya TS. In this case, the Avaya TS maintains interest in the EDU after the contact has been completed. If it is acceptable for EDUs to be forgotten, take care to ensure the EDUs are purged from the DUStore server over an acceptable period of time. 118 Electronic Data Unit Server Programmer Guide

DUStore processing In a voice only configuration, the DUStore server deletion day s parameter should be set to 1 day. This setting causes the forgotten EDU to be written to IC Repository 1 day after the EDU was initially written to the DUStore server. This keeps the number of EDUs in the DUStore server to a minimum. It may also be desirable to increase the scan frequency setting. This reduces the number of DUStore records that can be purged in each scan. Purging large numbers of records can make the EDU server and the Data server too busy. This makes these servers unresponsive to other requesting clients. If you find EDUs have been forgotten, you may want to purge these EDUs faster than the scheduled purge date and time, or at a specific date and time. To turn on purging for these EDUs, manually change the deletedatetime field on the database record using a database query tool. Changing the value to a date and time prior to the current date and time initiates the purge on the next scan interval. The value can also be set to schedule purging to occur during light system use periods such as early in the morning or during contact center closed hours. The deleted per scan parameter limits the number of EDUs the DUStore server deletes in one cycle. This helps reduce database contention that may occur when purging EDUs. If more records need to be purged, the DUStore server performs that purge processing immediately after purging the prior set of EDUs. The DUStore server does not wait until the next scan interval. It has been determined that changing this setting to eliminate problems with unresponsive EDU servers does not help because processing continues until all scheduled EDUs are purged. Parameter setting example The following parameters are based on the following customer situations: Customer Situation A The following table contains the parameters that apply to Customer Situation A: Element Media Channels: EDU Data: ADU Data: Expected Forgotten DU records per hour: Interaction Time with no DU activity Voice Only Required for backend reporting, ok to lose active DU data in case of abnormal shutdown, not ok to lose active DU data in normal server shutdown. Not used for reporting 60 15 minutes Issue 1.1 August 2003 119

The DUStore Server EDU server Set the following configuration parameters on the EDU server for Customer Situation A: Parameter Setting Reason Checkpoint frequency -1 DU data is not required for abnormal shutdown and not worth the overhead associated with the database activity. If the server is shutdown, the active DU records will be written to the store. Idle Time 30 Double the interaction time with no activity. If an exception occurs where 30 minutes is exceeded (long queue time or long agent conversation), the DUStore will be used and the DU restored when the next activity occurs. Enable Persistence Checked We want to use the DUStore for EDU records Persistence Server Name DUStore The name of the service is used. The EDU server will find the DUStore in the servers failover path. ADU server Set the following configuration parameters on the ADU server for Customer Situation A Parameter Setting Reason Enable Persistence Unchecked We do not want to use the DUStore server for ADU data because the data is not used for back end reporting and will not impact the customer if lost. 120 Electronic Data Unit Server Programmer Guide

DUStore processing DUStore server Set the following configuration parameters on the DUStore server for Customer Situation A Parameter Setting Reason Default delete deletion age 1 Reduced from the default of 60. This will cause forgotten DU records to be purged after 1 day. Deleted per scan 50 Reduced from the default of 1000. This setting will reduce the length of the database lock when deleting from the QW_DUStore and QW_Byte tables Scan Interval 15 Will cause purge processing to occur every 15 minutes. With 60 expected per hour, the purge will delete 15 each scan. Purge Alarm Unchecked Because we expect forgotten DU records, we do not need the alarm. Customer Situation B The following table contains the parameters that apply to Customer Situation B: Element Media Channels: EDU Data: ADU Data: Expected Forgotten DU records per hour: Interaction Time with no DU activity Voice and Email Required for backend reporting, ok to lose active DU data in case of abnormal shutdown, not ok to lose active DU data in normal server shutdown. Not used for reporting 600 voice, 0 email. 15 minutes for voice, 15 days for email. Issue 1.1 August 2003 121

The DUStore Server EDU server 1 (voice) Set the following telephony configuration parameters on the EDU server for Customer Situation B: Parameter Setting Reason Checkpoint frequency -1 DU data is not required for abnormal shutdown and not worth the overhead associated with the database activity. If the server is shutdown, the active DU records will be written to the store. Idle Time 30 Double the interaction time with no activity. If an exception occurs where 30 minutes is exceeded (long queue time or long agent conversation), the DUStore will be used and the DU restored when the next activity occurs. Enable Persistence Checked We want to use the DUStore for EDU records Persistence Server Name DUStoreVoice The name of the service alias is used. EDU server 2 (mail) Set the following email configuration parameters on the EDU server for Customer Situation B: Parameter Setting Reason Checkpoint frequency -1 DU data is not required for abnormal shutdown and not worth the overhead associated with the database activity. If the server is shutdown, the active DU records will be written to the store. Idle Time 120 Set to 2 hours. This will cause any emails in the queue longer than 2 hours to be written to the DUStore as well as deferred emails that will not be completed within 2hours. Enable Persistence Checked We want to use the DUStore for EDU records Persistence Server Name DUStoreMail The name of the service alias is used. 122 Electronic Data Unit Server Programmer Guide

DUStore processing ADU server Set the following configuration parameters on the ADU server for Customer Situation B Parameter Setting Reason Enable Persistence Unchecked We do not want to use the DUStore server for ADU data because the data is not used for back end reporting and will not impact the customer if lost. DUStore server (Voice) Set the following telephony configuration parameters on the DUStore server for Customer Situation B: Parameter Setting Reason Default delete deletion age 1 Reduced from the default of 60. This will cause forgotten DU records to be purged after 1 day. Deleted per scan 50 Reduced from the default of 1000. This setting will reduce the length of the database lock when deleting from the QW_DUStore and QW_Byte tables Scan Interval 5 Will cause purge processing to occur every 2 minutes. With 60 expected per hour, the purge will delete 20 each scan. Purge Alarm Unchecked Because we expect forgotten DU records, we do not need the alarm. Issue 1.1 August 2003 123

The DUStore Server DUStore server (Mail) Set the following email configuration parameters on the DUStore server for Customer Situation B: Parameter Setting Reason Default delete deletion age 30 Reduced from the default of 60. This will cause forgotten DU records to be purged after 30 days which roughly double the maximum work time for an email. Because we do not expect any forgotten mail EDU records, this should not occur. Deleted per scan 50 Reduced from the default of 1000. This setting will reduce the length of the database lock when deleting from the QW_DUStore and QW_Byte tables Scan Interval 15 Will cause purge processing to occur every 15 minutes. Purge Alarm Checked Because we do not expect forgotten DU records for email, we need the alarm. 124 Electronic Data Unit Server Programmer Guide

DUStore server method overview DUStore server method overview The following is a brief description of the methods available for use with the DUStore server. DUStore.Store DUStore.Retrieve DUStore.Delete DUStore.DeleteByRule DUStore.DeleteDuplicate DUStore.Find Stores a DU in the database. Retrieves a DU from the database. Deletes a DU from the database. Purges the database of DUs. Notifies the DUStore server that duplicate DUs require elimination. Finds zero or more the DUIDs in the database and returns the relevant DUIDs. Note: Note: The DUStore.Store and DUStore.Retrieve methods are reserved for Avaya software. Using these methods with any other software is not supported. Issue 1.1 August 2003 125

The DUStore Server 126 Electronic Data Unit Server Programmer Guide

Appendix A: VDU.Create Example The programming example shown on the following pages demonstrates an asynchronous VDU.Create method invocation. /***************************************************************************** * Copyright (c) 1997, 1998 Avaya Inc, USA * All rights reserved* *****************************************************************************/ #include <orb.h> #include <stdio.h> /* This macro looks at the return value of vesp requests and * looks up what the error was, if any */ #define CHECK(_a)\ {\ ORBStatus _stat = (_a);\ if(_stat!= VESP_SUCCESS)\ {\ fprintf(stderr, "ERROR: %s\n", vesp_find_error(_stat));\ exit(1);\ }\ } int irequestoutstanding = 0; VDU_ID pcvduid; /* this must be static */ /* callback for the vdu create request, notice that vduid is VDU_ID* */ ORBStatus CreateResponse( Identifier interface, ORBStatus status, Environment *ev, long user_data, Session session, SeqCouple *data, VDU_ID* vduid ) { irequestoutstanding--; /* the double dereference of vduid here is important */ printf( "Created VDU: %s\n", *vduid ); return VESP_SUCCESS; } int main(int argc, char *argv[]) { Object client_obj; Environment ev; Session session; Request request; SeqCouple *ptseqin; /* login to vesp */ CHECK(Vesp_Login("vesp","", &client_obj)); printf( "Login.\n" ); Issue 1.1 August 2003 127

VDU.Create Example /* create a session and set some parameters */ CHECK(Vesp_Session_Create(client_obj, &session)); Session_set_message_timeout(session, &ev, 0x1000); set_log_name("create_test.log"); printf( "Create Session.\n" ); ptseqin = vesp_couple_seq_create(); vesp_couple_seq_add_couple_values( ptseqin, "test_name", "test_value"); /* asynchronously create a VDU, use address of the pointer to VDU_ID */ CHECK( Vesp_Request( "VDU.Create", CreateResponse, 0UL, session, ptseqin, &pcvduid ) ); printf( "Create.\n" ); irequestoutstanding++; /* wait for the callback to be invoked */ while( irequestoutstanding <0 ) { Vesp_poll( 1000UL ); printf( "Polling.\n" ); } printf( "All done.\n" ); return 0; } 128 Electronic Data Unit Server Programmer Guide

Index A ADU Data..................... 119, 121 ADU methods ADU.SetOne............... 101 ADU.SetOne................. 101 Alarms DUStore.................... 112 Alias name, reserved............... 49 ani........................ 26 Assign method.................. 70 Assign, request to monitor edus........ 35, 38 AssignFail..................... 45 B BadVDUInDS................... 45 C call_ref_id..................... 26 Checkpoint frequency............ 120, 122 Clients...................... 35 Configuration parameters DUStore.................... 112 contactendtime.................. 26 Containers description of................. 30 Limitations of tokens.............. 32 Names and tokens............... 31 cooperation of edu servers............ 16 Create a new edu............. 20, 71, 73 Create method................ 71, 73 createtime.................... 26 createtime_t.................... 26 D data....................... 110 Data names, reserved............... 26 datalength.................... 110 Deassign method................. 74 Default delete deletion age....... 121, 123, 124 Deleted per scan........... 121, 123, 124 deletedatetime.................. 110 Destroy a server session.............. 74 dnis........................ 26 DumpVDU.................... 46 duration...................... 26 DUStore database.................110 DUStore method overview list........... 125 DUStore.Delete................. 125 DUStore.DeleteByRule.............. 125 DUStore.DeleteDuplicate............. 125 DUStore.Find.................. 125 DUStore.Retrieve................ 125 DUStore.Store.................. 125 E edu activity..................... 21 creation.................... 20 data description................. 25 definition.................... 20 description................... 20 selecting.................... 35 server cooperation............... 16 termination...... 22, 50, 104, 105, 106, 107 EDU Data..................... 119, 121 edu method overview list.............. 67 edu methods DeleteOne................ 74 DeleteSubTree................. 75 Deletes.................. 75 GetSomes.............. 85, 92 GetSubTree.................. 86 GetHistory................ 89 GetsHistory................ 90 SetAndTerminate................ 95 SetDefaultHistoryFilter............. 97 SetHistoryFilter................. 98 SetsExtended.............. 103 VDU.Assign.................. 70 VDU.Create.................. 71 VDU.CreateExtended.............. 73 VDU.Deassign................. 74 VDU.DeleteOne.............. 74 VDU.DeleteSubTree.............. 75 VDU.Deletes............... 75 VDU.EventIn.................. 76 VDU.Find.................... 77 VDU.FindByKey................ 79 VDU.FindExtended............... 80 VDU.FindOrCreate............... 81 VDU.ForwardEvent............... 82 VDU.GetActive................. 83 Issue 1.1 August 2003 129

VDU.GetOne............... 84 VDU.GetSomes............ 85, 92 VDU.GetSubTree................ 86 VDU.GetUserSessions............. 87 VDU.GetHistory.............. 89 VDU.Gets................. 88 VDU.GetsHistory............. 90 VDU.Incr................. 93 VDU.Monitor.................. 94 VDU.RemoteWatcher.............. 95 VDU.SetAndTerminate............. 95 VDU.SetAndTransfer.............. 96 VDU.SetDefaultHistoryFilter........... 97 VDU.SetHistoryFilter.............. 98 VDU.SetOne.............. 100 VDU.Sets................ 102 VDU.SetsExtended........... 103 VDU.Terminate........... 104, 105, 106 VDU.TerminateMine............. 107 VDU.Transfer............... 107, 108 educational services................ 11 eduid defined..................... 21 structure of................... 24 edus resurrecting................... 67 Enable Persistance........... 120, 122, 123 Event monitoring criteria boolean operators.............. 42 defined................... 39 examples.................. 43 relational operators............. 41 syntax................... 39 wildcards.................. 42 starting................... 35, 38 stopping.................... 38 Event types.................... 36 EventIn method.................. 76 Events, monitoring data stream........... 37 Exception information............... 66 Expected Forgotten DU records per hour..................... 119, 121 F FailVDUCon.................... 46 Find method.................... 77 FindByKey method............... 79, 81 FindExtended method............... 80 ForwardEvent method............... 82 G GetActive method.................. 83 GetOne method................ 84 GetUserSessions method.............. 87 Gets method................. 88 H History, maintaining duplicate............ 61 I IC Repository, interaction with............ 14 Idle Time.................. 120, 122 iidigits....................... 28 Incr method.................. 93 info1....................... 110 info2....................... 110 info3....................... 110 Interaction Time with no DU activity......119, 121 L L_ucid....................... 27 lai_dnis....................... 28 last termination................... 26 listing active edus................. 23 Listvdu utility.................... 23 LocalVDU, as alias name.............. 49 loginid....................... 26 lookup1..................... 110 lookup2..................... 110 LostVDUEvents................... 46 M Media Channels......................119, 121 methods exception information.............. 66 Monitor method................... 94 Multiple database servers, use of.......... 61 N Name/value pairs.................. 25 reserved names................. 26 NoEventSink.................... 47 NoMeInDS..................... 47 NoVDUOS..................... 47 130 Electronic Data Unit Server Programmer Guide

O owner....................... 26 P persistance.................... 26 Persistance Server Name.......... 120, 122 persistance.deletedate............... 26 Pre-defined data elements............. 26 Purge Alarm.............. 121, 123, 124 R Recall, interaction with............... 15 RemoteWatcher method.............. 95 Requests, routing................. 66 Resurrecting edus................ 67 Routing requests................. 66 S Scan Interval............. 121, 123, 124 SetAndTransfer method.............. 96 SetOne method............ 100, 101 Sets method................. 102 Special tokens................... 31 Stop monitoring events............... 74 suspend..................... 27 system considerations............... 49 T Terminate method........... 104, 105, 106 TerminateMine method.............. 107 Terminating edus, rules for............ 50 termination.................... 27 The........................ 63 time....................... 27 Tokens...................... 31 Limitations of.................. 32 Transfer method............... 107, 108 transfercount................... 27 V history................... 29 s,defined.................. 25 VDU.Assign.................. 67, 70 VDU.auRevoir................... 36 VDU.Change................... 36 VDU.Create.................. 67, 71 VDU.CreateExtended............. 67, 73 VDU.Deassign................. 67, 74 VDU.Delete.................... 36 VDU.DeleteOne............. 67, 74 VDU.DeleteSubTree.............. 67, 75 VDU.Deletes............... 67, 75 VDU.Drop..................... 36 VDU.End..................... 36 VDU.EventsIn................. 67, 76 VDU.Find................... 67, 77 VDU.FindByKey................ 67, 79 VDU.FindExtended............... 67, 80 VDU.FindOrCreate............... 68, 81 VDU.ForceTerminate.............. 68, 82 VDU.ForwardEvent............... 68, 82 VDU.GetActive................. 68, 83 VDU.GetOne............... 68, 84 VDU.GetSomes............. 68, 85 VDU.GetSubTree............... 68, 86 VDU.GetUserSessions............. 68, 87 VDU.GetHistory............. 68, 89 VDU.Gets................ 68, 88 VDU.GetsHistory............. 68, 90 VDU.GetVariouss............. 68, 92 VDU.Incr................. 68, 93 VDU.LostConnectivity............... 36 VDU.Monitor.................. 68, 94 VDU.RemoteWatcher............. 68, 95 VDU.SetAndTerminate............. 68, 95 VDU.SetAndTransfer.............. 68, 96 VDU.SetDefaultHistoryFilter.......... 68, 97 VDU.SetHistoryFilter.............. 68, 98 VDU.SetOne.............. 69, 100 VDU.SetOrIncrement............. 69, 101 VDU.Sets............... 69, 102 VDU.SetsExtended........... 69, 103 VDU.Terminate............... 69, 104 VDU.TerminateAndCreate.......... 69, 105 VDU.TerminateDuplicate........... 69, 106 VDU.TerminateMine............. 69, 107 VDU.Touch................. 69, 107 VDU.Transfer.............. 36, 69, 108 VDU.UnknownToVDU............... 47 VDU.Watch.................... 36 vdu_id.....................27, 110 VDUbad...................... 47 VDUHS, backward compatibility........... 61 VDUOS, interaction with.............. 15 Victims...................... 47 W Wildcards..................... 42 Issue 1.1 August 2003 131

132 Electronic Data Unit Server Programmer Guide

Issue 1.1 August 2003 133

134 Electronic Data Unit Server Programmer Guide