Professional Documents
Culture Documents
CENTER HANDLER
DEVELOPMENT
CLASS MANUAL
Interaction Dialer and Interaction Scripter are registered trademarks of Interactive Intelligence, Inc.
The foregoing products are 2000-2017 Interactive Intelligence, Inc. All rights reserved.
Messaging Interaction Center and MIC are trademarks of Interactive Intelligence, Inc. The foregoing
products are 2001-2017 Interactive Intelligence, Inc. All rights reserved.
Interaction Conference is a trademark of Interactive Intelligence, Inc. The foregoing products are
2004-2017 Interactive Intelligence, Inc. All rights reserved.
Interaction SIP Proxy and Interaction EasyScripter are trademarks of Interactive Intelligence, Inc. The
foregoing products are 2005-2017 Interactive Intelligence, Inc. All rights reserved.
Interaction Desktop is a trademark of Interactive Intelligence, Inc. The foregoing products are
2007-2017 Interactive Intelligence, Inc. All rights reserved.
Interaction Process Automation, Deliberately Innovative, Interaction Feedback, and Interaction SIP
Station are registered trademarks of Interactive Intelligence, Inc. The foregoing products are 2009-
2017 Interactive Intelligence, Inc. All rights reserved.
Interaction Analyzer is a registered trademark of Interactive Intelligence, Inc. Interaction Web Portal
and IPA are trademarks of Interactive Intelligence, Inc. The foregoing products are 2010-2017
Interactive Intelligence, Inc. All rights reserved.
Interaction Speech Recognition and Interaction Quality Manager are registered trademarks of
Interactive Intelligence, Inc. Bay Bridge Decisions and Interaction Script Builder are trademarks of
Interactive Intelligence, Inc. The foregoing products are 2013-2017 Interactive Intelligence, Inc. All
rights reserved.
Other brand and/or product names referenced in this document are the trademarks or registered
trademarks of their respective companies.
DISCLAIMER
INTERACTIVE INTELLIGENCE (INTERACTIVE) HAS NO RESPONSIBILITY UNDER WARRANTY,
INDEMNIFICATION OR OTHERWISE, FOR MODIFICATION OR CUSTOMIZATION OF ANY
INTERACTIVE SOFTWARE BY INTERACTIVE, CUSTOMER OR ANY THIRD PARTY EVEN IF SUCH
CUSTOMIZATION AND/OR MODIFICATION IS DONE USING INTERACTIVE TOOLS, TRAINING
OR METHODS DOCUMENTED BY INTERACTIVE.
Chapter 6: Troubleshooting
Module 6.1 Troubleshooting 6-02
HANDLER ENVIRONMENTS
Development The development environment is where handlers are designed and built. The
development or modification of a handler does not require a connection to an IC server. All the
developer needs is a copy of Interaction Designer running on their workstation and the handlers
that they will be modifying. The developer can make the handler modifications, do an intermediate
publish, and complete the publishing process on the development IC server. Now the handler is
ready to move into the testing environment.
Testing The testing environment is where handlers are tested. The testing environment should be
as close to the production environment as possible. All Interaction Center functionality should be
available in the testing environment. Every possible scenario of the handler should be tested, which
includes both proper functionality and error handling. Only after the handler has been thoroughly
tested should it be promoted to the production environment.
This section offers an overview of the entire process of building and editing handlers. Reading this
section is recommended, before you begin using Interaction Designer to build or modify handlers.
Research In this step, you gather information about:
Currently used handlers
The task to be completed
The handlers you will interact with
Design Map out the functionality you plan to build and figure out how it will run with the other
handlers and subroutines. In this step, you will design the handler on paper. This design may be in one
of the following forms:
Flowcharts
Pseudocode
Build Begin creating and linking steps to perform the new functionality. In this step, you use
Interaction Designer to build the handler.
Activate When you finish building the handler or subroutine, it must be compiled and moved to the
Interaction Center server, using the automated Publishing process. Handlers and subroutines are
published through Interaction Designer. In this step, you use Interaction Designer to save, publish,
and manage the handler.
Test In this step, you run the handler on your test system and ensure that it is functioning correctly.
Promote In this step, you move the handler from the test system to the production environment.
The first step in building handlers and subroutines is research. You must be familiar with the
handlers currently being used on your Interaction Center server. You will have to decide if the
handler you are planning can be integrated into a current handler, if a new handler is needed, or
if the functionality you require is already available in Interaction Attendant. Many functions that
previously required handler modifications can be accomplished in Interaction Attendant by adding
an operator.
There are several places you can look for information on the existing handlers. First, view the
contents of the Interaction Designer Help menu.
Also, review the reference and procedural topics in this Help system. The Tools help available
from the Help Topics can help you learn the function of each step in a handler or subroutine. The
procedural topics and various introductions can help you understand how handlers work.
Research the other systems the handler may interact with such as databases, LDAP directories, or
other programs.
You would find this information in the Handler Help, Dependency Viewer, and by referring to any
technical specifications given to you.
In many cases, new functionality can be implemented within Interaction Attendant. If Interaction
Attendant cannot be used, you may need to modify an existing handler to implement the new
functionality.
If you decide to modify an existing handler or subroutine, strongly consider using the customization
points provided. Customization points ease future upgrades because they will not be overwritten.
Creating a handler If you are planning a significant addition or change in functionality, you
probably need to build a new handler. A base handler will start when an event occurs on the server
to start that handler. Most of the events that occur on the Interaction Center server already have a
handler associated with them. Unless you are adding third-party products that generate their own
unique events, you will probably build a subroutine.
An example of a piece of third-party equipment that might generate a unique event is a machine
monitor. For example: a hospital has a computer monitoring a piece of equipment. Anytime that
equipment fails, the monitoring computer creates an alarm event. This event could be passed into
Interaction Center and start a handler designed to watch for an alarm event.
Design Process Tools Before creating a handler in Interaction Designer, design the functionality
first, on a whiteboard or on paper using a flowchart or pseudocode. Try to think in terms of the
Interaction Designer tools and what groups of tools create the needed logic. Remember that creating
handlers is programming; planning at the outset saves time when you start building the handler.
Flowchart: A flowchart is a graphic or diagram which shows how a complex operation takes
place. The flowchart breaks down that operation into its smallest and simplest parts. The table
below lists some of the more common flowcharting symbols and their purposes. There are many
more flowcharting symbols to represent more functions such as database operations, printing,
calling a subroutine.
Symbol Purpose
Terminator Indicates the end of the logic for this particular program. If
this is a subroutine, control will return to the calling handler.
Pseudocode 1
1. A call is placed from a station.
2. Is it an Emergency call?
Is there a tool associated with the return to the calling handler? How will the subroutine know when
to return?
BUILD
Once you have mapped out the functionality and decided to implement the logic, you are ready
to start modifying or building the handler in Interaction Designer. When building handlers, it is
important to understand the tools and their parameters that will be required for the logic.
To access Help for a tool, click the Help button on its tabs, or select a tool on the Tools page of
the Design palette and press the F1 key. The help for each tool consists of a general description
of the step, its parameters, and its exits. You can also find help on working with steps from the
contents page of the Help. It may also be helpful to view how steps are used in other handlers. Use
Dependency Viewer to find other handlers that use a specific tool.
ACTIVATE
Once you have finished building or modifying a handler, it must be published so that the changes
take effect. Publishing a handler is the automated process of compiling the code into a proprietary
format and placing the compiled code on the Interaction Center server.
Subroutines must be published before they can be called from other handlers. Once you have
published a new subroutine, a new subroutine tool appears on the subroutine page of the Design
Palette. Use new subroutine tool to create a new step in the handler that calls that subroutine.
There may be times when you do not want to publish your handlers on the same server on which
they were created. If so, use the intermediate publish to generate an .i3pub file. Then it can be
moved to the appropriate server and the publishing process can be completed.
When a handler is first published, you can activate it immediately. If you do not do activate it
immediately, or if the handler has been imported from another server or previously been made
inactive, activate it in the Manage Handlers notebook so it can be used in Interaction Center.
TEST
After you have published the handler, ideally to a test server, thoroughly test the functionality of
the handler you have built. If you do not have a test server, then test the handler during down time.
Never implement an untested handler or untested handler modification on a production server!
Testing is critical. Untested handlers can cause a server to malfunction.
CAUTION
Only after the handler has been thoroughly tested should it be published and managed on the
production IC server.
GENERAL
Build to the right or down: Design your handlers so they start from the upper left corner and
build to the right or down. This makes your handlers easier to follow.
Use Dual Monitors and Zoom Feature: It is easier on the eyes to use dual monitors. Using the
Zoom feature allows you to view more or less of the handler as needed instead of scrolling back
and forth trying to see the whole thing.
Extend step to show whole selection step: Expand step size to show the values and the step label.
Use one Selection step instead of multiple condition steps when appropriate: One step is easier
to read and more efficient.
Avoid huge selection steps: Especially with string expressions. Selection steps can be a significant
bottleneck if used incorrectly. Selection steps evaluate expressions from the top down until an
expression resolves to true. Each selection expression is evaluated independently of any of the
previous selection expressions, so any repeated expressions will be evaluated again.
In a Selection step, place the most-often-occurring expression at the top of the list: Expressions
are evaluated from the top of the list to the bottom.
Use Hungarian Notation for Variable Names: By doing so, you can glance at a variable name and
know its data type.
DOCUMENTATION
Use File/Properties to document handler: Use the file properties window to document a handler
instead of the notes for the initiator.
Use the step notes to document the step: Use the notes area on each step to document
information regarding the intended use of the step.
Indicate changes in step label: anytime you make changes to a production handler or a handler
that someone else wrote, indicate which steps you changed by changing the step notes.
1-09The Development Environment 2017, Interactive Intelligence, Inc.
OVERALL PROJECT TIPS
Protect default handlers and customized handlers: Keep custom handlers in their own separate
directory. Write-protect the default system handlers either at the file or directory level to avoid
inadvertent changes. Store modified default system handlers separate from the default handlers
and any custom handlers. Avoid making any changes to the default handlers. If you must make
changes, use subroutines if possible. If you often make changes to certain default system
handlers, request the addition of a customization point by Interactive Intelligence development.
Reuse code across projects: Avoid naming handlers and variables and other items after clients or
projects so that you can easily reuse the handlers for other clients or projects. This is especially
true with subroutines that act like functions.
Follow good project management practices: Plan out handlers using call flow diagrams
developed in Microsoft Visio or a similar application. Make sure all paths for all options in the
call flow end with specific requirements. Make sure that the diagrams are complete, including
even minor details. Get a sign-off on the call flow scope of work before starting.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 1: Research and Design
Lab 2: Handler Development Precautions
Lab 3: Hello World
Handler Basics
Defining Handlers
2
Object, Attributes, Events, and Initiators
Building Handlers
Working with Basic Tools
Debugging Handlers
Dependency View
Working with Subroutines
Working with Expressions
DEFINING HANDLERS
A handler is an .ihd formatted file that is made up of individual steps that form logic.
This logic responds to events and processes them, depending on the specific event and information
passed to the handler.
Like any program, handlers perform a series of actions. Actions in the handler are graphically
represented by a step, creating a flowchart look.
Steps (or actions) are performed in an order determined by how the steps are linked together.
Each step performs a different action. This combination of actions determines what happens
when the handler runs.
Some steps start other handlers, called subroutines.
The Handlers folder is created on the same partition in which IC is installed during the Interaction
Center install. The handlers and associated directories can be found in the following locations:
\I3\IC\Handlers\40Handlers This is the default location of the Interaction Center handlers. It
contains all the base handlers and subroutines, including all Interaction Attendant handlers that
It is always recommended that you make copies of these folders and store them on a separate
CAUTION
machine in case a handler is deleted or damaged.
HANDLER STANDARDS
Certain design standards have been implemented at Interactive Intelligence in order to maintain a
level of quality and consistency when designing handlers. For ease of understanding, we recommend
that you follow these standards where appropriate.
Boilerplate Text Every system handlers dialog box lists customization points that are called from
within the handler. Here is an example of boilerplate text from System_IncomingCall.ihd:
Use this page to document any subroutine calls that you add to the handler.
Variables (locally scoped) For consistency in variable naming, a convention similar to Hungarian
notation is used. There is a prefix for the name of each variable that indicates the data type, in
lowercase, followed by the variable name. The following table outlines normal (basic) data type
prefixes for handler variables:
Integer i iCount
Numeric n nPayRate
Boolean b bSuccess
String s sName
Labs
There are no labs associated with this module.
OBJECTS
TYPES OF OBJECTS
Call Objects Whenever a call comes in to the Interaction Center, a new call object is created. That call
object can have actions performed on it. For example, it can be transferred or placed in a user queue.
Chat Objects In IC, chat objects are online, real-time, typed conversations between an Interaction
Center user and a remote chat participant browsing a website. Chat sessions are similar to telephone
conversations, except that the information is typed and not spoken.
Email Objects Email objects are created when an email message comes into an ACD workgroup.
Generic Objects A generic object is typically a third-party interaction, such as a proprietary web
chat, that is ACD routed by an Interaction Center server. When a request comes in, Interaction
Designers Create Generic Object tool is used to specify the name of an ACD or agent queue. The tool
step assigns a generic object ID to the object, which is similar to a call object ID. The generic object ID
is used by the Interaction Center to reference the object when it is routed from an ACD queue to the
agent. The object itself is stored in Queue Manager.
There are many other types of objects, such as user queue objects and fax objects.
FOR YOUR
INFORMATION
ATTRIBUTES
Attributes are pieces of information about something. For instance, in the case of a person,
attributes include hair color, weight, eye color, and so on. A more pertinent example would be the
case of an inbound call into IC. The call comes into the system with attributes which can be read,
changed, and added to by system processes and handlers. There are two fundamental types of
attributes in IC:
Object Attributes Telephone calls, chat sessions, and email are objects processed by the
Interaction Center. Object attributes are pieces of information about that object that travel with
it throughout the Interaction Center. Developers can define generic objects that have custom
attributes. Developers can define custom attributes for any type of object. Telephone calls, chat
2-06Handler Basics 2017, Interactive Intelligence, Inc.
sessions, email, and generic objects are entities that have attributes associated with them.
Inbound calls have ANI/DNIS information, Station Name, and other attributes that move with a call
EXAMPLE
and can be extracted for use.
If you need them, you can also add your own user-defined attributes. You can add a call object
attribute with the Set Attribute tool, and you can retrieve its value with the Get Attribute tool.
Other objects have similar tools for working with attributes.
Directory Service Attributes Directory Services (DS) attributes cache information about
Directory Service keys in the Windows Registry. The information stored in DS attributes are the
values that are set in Interaction Administrator.
Examples of handler tools used to access and work with DS attributes include: Get Ds Attr, Get Ds
Attrs, and Lookup toolsteps, and the corresponding Put Ds toolsteps under the System tab of the
Design Palette.
Whereas DS attributes reside in Directory Services and can be retrieved at any time, object
FOR YOUR
INFORMATION
attributes travel with an object as long as it is in the system. When the object is no longer in the
system, the attributes are gone as well.
OBJECT ATTRIBUTES
A variety of entities create attributes, including the Interaction Center itself. For example, the
Telephony Services subsystem creates many default call object attributes when a call object is
created. Handlers, Interaction Center applications, and programs developed using various system
APIs can create and modify attributes.
Attributes are name/value pairs. To retrieve the value of a call or chat object attribute, you specify
an attribute name. The value returned for an attribute is usually string data. However, chat and call
attributes can contain 32-bit binary data in DWORD format. Email objects return data that is stored
in Interaction Designers list variable format.
Object attributes can be thought of as temporary storage. They only last as long as the object. Each
type of object (call, chat, email, and so on) has its own set of attributes.
Tool Description
Set Attributes Assigns one or more values to a list of one or more call attributes.
Tool Description
Email Interaction Get Message This tool gathers the email attributes for the specified email object.
Tool Description
Get Generic Object Attribute Retrieves one attribute from a specified object.
Set Generic Object Attribute Sets the value of an attribute for a specified object.
These tools cannot be used to retrieve values of attributes for Directory Services keys. To get
FOR YOUR
INFORMATION
those values, use the Get DS Attr, Get DS Attrs, or Lookup tools located under the System tab in
the Design Palette.
EVENT
Events correspond to actions that are associated with objects. For example, when Telephony
Services receives an incoming call, it creates a call object with a unique Object ID. Telephony
Services then generates an event called Incoming Call. Every time an IC subsystem performs an
action associated with an object, it generates an event. Some handler tools also generate events,
2-08Handler Basics 2017, Interactive Intelligence, Inc.
such as ACD Initiate Processing which generates an ACDProcessQueueItem event, and Blind
Transfer which generates a Call to Non-System Queue event. Hardware or software that is not part
of the Interaction Center system can generate events, such as a security card reader or a computer
that monitors a piece of equipment.
Events serve two purposes in Interaction Center. Events:
Start an instance of a handler An event can tell Interaction Processor to start an instance of a
handler designed to respond to that event. When Telephony Services generates an Incoming Call
event, the Notifier tells Interaction Processor that the event has occurred. Interaction Processor
starts an instance of any handlers configured to run when the Incoming Call event occurs.
Carry information about an object An event can carry information about the object. For
example, an event generated by an incoming call carries information about that call, such as
the caller ID and the name of the line that the call is coming in on. This information is stored as
attributes. These attributes can be used by the handler to make decisions about what to do with
the object.
Examples of events:
Incoming Call
Disconnected Call
Station Off Hook
Incoming Email
INITIATORS
An initiator is always the first step in a handler. It tells Interaction Processor which event starts an
instance of that handler.
Here is an analogy: You are stopped at a traffic light and the light turns green. The changing of the
light is an event that starts a series of actionsyou press down on the accelerator, the car moves
forward, and so on.
In Interaction Center, the action caused by the event depends on an initiator. When one of the
modules in Interaction Center, such as Telephony Services, generates an event, that event is
seen by the Notifier. Notifier then tells other modules about that event. One of these modules is
Interaction Processor where the handlers are registered. When the Notifier tells the Interaction
Processor about an event, Interaction Processor starts an instance of a handler.
When you publish a handler, the handlers initiator tells Interaction Processor which event to watch
for. An event is something that happens to an object. For example, a call (object) can be sent to voice
mail (event). If you configure an initiator in a handler to start when calls are sent to voice mail, then
Interaction Processor starts that handler any time it is notified of that event.
IN CLASS EXERCISE
Find the following handlers in Interaction Center and determine if they are event or subroutine initiated.
SystemIVR.ihd
System_CallOfferingNonSystemQueue.ihd
System_StationOffHook.ihd
InteractionAttendantEntryPoint.ihd
ACDAvailableAgent.ihd
CustomAnswer.ihd
SystemIVRTransfer.ihd
When the same event occurs multiple times (such as an Incoming Call), each event spawns an
instance of the same handler. This behavior allows Interaction Center to handle many of the same
type of events at the same time.
When the first event is recognized in Interaction Center Notifier alerts the Interaction Processor
that there is a particular event happening. The Interaction Processor matches the event properties
with the properties of an initiator and spawns an instance of a handler.
When a second event of the same type happens The exact same process happens again except
there is a second instance of the handler spawned. These two instances can run simultaneously.
CHANGING AN INITIATOR
On the Initiator Properties page, there are three settings for most initiators. (HTML, Timer, and
Subroutine initiators are different.) The combination of these three settings determines when
Interaction Processor will start an instance of a handler containing that initiator. These three
settings are described below:
Notification Object Type An object type is an entity that can be used or managed by Interaction
Center. Examples of some of these objects include calls, chat sessions, and faxes. Queues are also
objects, including user, station, workgroup, and line queues. The Notification Object Type of an
initiator cannot be changed.
Object ID One property for an instance of an object is a unique object ID. This object ID is a unique
number that differentiates one instance of an object from another. In most cases, you should leave
this setting to {all} so that the handler starts for an object with any Object ID.
Every call that comes through Interaction Center has a unique Object ID. The default value for this
EXAMPLE
setting is {all} to allow an initiator to start for every occurrence of an event to an object. In most
initiators, this setting cannot be changed.
Notification Event An event is an action that is associated with an object. Examples of some of the
events that occur on a call object are transfer, send to voice mail, and new outgoing call request.
Events also carry information that can be retrieved by the initiator for use in the handler.
Object ID {all}
Event Bark
With these initiator settings, the handler would start any time any dog barked.
Object ID Fido
Event Bark
With these initiator settings, the handler would start any time a dog named Fido barked.
Object ID Fido
Event {all}
With these initiator settings, the handler would start any time a dog named Fido did anything.
Object ID {all}
Event {all}
With these initiator settings, the handler would start any time any dog did anything.
In a situation where an event matches two primary handler initiators, the handler with the initiator
FOR YOUR
INFORMATION
which most closely matches the event will be ran. Unless both initiators are exactly the same, then
neither handler will run, and an error will be written to the event log.
Initiators can pass information (attributes of the object) to a handler. The information initiators pass
into handlers is specified on the initiators Outputs page.
The Incoming Call initiator passes into its handler the Call Identifier, the Line Identifier, the number
EXAMPLE
the caller dialed, and other information. A handlers uses this information to perform actions on the
incoming call object.
CLASSIFICATIONS OF HANDLERS
We have already learned that handlers can be classified according to their initiator as:
Event Initiated
Subroutines
Handlers are also classified according to their functions. All handlers are stored in the same
directory by default. They have the same .ihd extension and appear to be identical. The only thing
that visibly distinguishes the various types of handlers from each other is their naming convention.
Primary handlers are handlers which may act directly on objects in the system. Only one primary
handler can be activated for a given initiator, to prevent two or more handlers from performing
conflicting actions on a single object.
Monitor handlers have the word monitor somewhere in their file name.
Customization point handlers are subroutine handlers which are distinguished by the word
custom in their file name.
SUBROUTINE HANDLERS
Subroutines Subroutines are handlers that are called (or initiated) by other handlers. Subroutines
are used often in IC to make existing handlers more manageable. There are also special subroutines
that are designed to allow handler developers to customize the system. These special subroutines are
called customization points.
Customization Points Many handlers contain customization points. Customization points are
handlers in which you can implement customized logic and not worry about future IC releases
overwriting your custom logic. Customization points are just subroutines. These customization
subroutine calls will always be in the same location, so you can easily preserve your custom logic.
Interactive Intelligence will not overwrite these handlers during service update or upgrade installs.
Your logic or customized code will not be disturbed.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following lab in your lab manual:
Lab 4: Triggering Handlers
BUILDING HANDLERS
The only supported modifications to base handlers are through customization points. To modify a
handler, open the handler and find the appropriate customization point. Now open the subroutine
handler that the customization point calls by right-clicking on the customization point and selecting
Download Subroutine From Server. This action will allow you to browse to a location in which to
save the most recent version of the downloaded customization handler. Now you can add the steps
for the new logic that you require.
Interactive Intelligence STRONGLY recommends against modifying base system handlers that ship
CRITICAL
with our products. Use the customization points as much as possible. Submit request for new handlers
to ideas.inin.com. Using the customization points is a best practice for a maintainable system from SU
to SU and version to version. Modifying base handlers introduces risk when applying updates and will
require migration effort to maintain your customizations with each update.
If you choose to modify any of the base handlers, it is at your own risk. When Support determines
that an incident is due to modification of a base handler, they will close the case. Also, since the
Service Update process is automated, a customized base handler may be overwritten any time an
SU is applied, and your custom functionality will be gone until you merge your changes back into the
new base handlers supplied in the SU.
PARTS OF A STEP
Icon The unique icon that corresponds with the step type. For example, all Generate HTML steps
have the same icon as the Generate HTML tool. You cannot change a steps icon.
Step Type The type of tool from which the step was created. For example, if the step was created
from the Assignment tool, the step type is Assignment.
Step Label The custom name a handler author has given this step. Use these labels as quick
reminders of a steps purpose in a handler. If you do not enter a name for a step, the step label is the
same name as the step type. Assignment and Condition steps can be auto labeled. With auto labeling
the current assignment or condition is set as the label.
Exit Paths The paths a step can take as a result of a steps action. It is through these exits that steps
link to other steps. For example, a Condition step has two exit paths: True and False. If the condition
evaluated by the Condition step is true, the step will exit along the true path. If the condition
evaluated by the Condition step is false, the step will exit along the false path.
If a step has no exit paths, or no links from an exit path, the handler or subroutine ends after the
FOR YOUR
INFORMATION
completion of that step.
Step Numbers Each step also has a number. This number is the order in which the step was created
in this handler and will never change. The step number does not indicate the order in which the steps
should be placed. The steps should be placed in a logical order so that the handler functions properly.
If you delete a step, the number is not deleted. Any additional steps will begin numbering with the
next value after the value of last step added.
CONNECTING PATHS
Entry Paths These are the paths taken by objects entering a step. They are shown in red when the
step is selected. A step can have multiple entry connections.
Exit Paths These are the paths taken by objects exiting a step. They are shown in green when the
step is selected. Each exit path can only have one connection.
Connection Lines Connection lines connect the steps together. They are black unless connected to
a step that is selected. They will remain connected if you move the step.
Modifying Connecting Paths You can modify the links between tool steps by clicking and dragging
on a wire in the link. Once a wire has been moved and placed in this fashion that wire will remain fixed
regardless of how the two connected tools are moved. The first and last sections of a link cannot be
fixed in this manner. If you want to add more wires to a link, right-click on the wire and select Add
Anchor.
CONNECTING STEPS
STEP PROPERTIES
The Properties notebook is a collection of tabbed pages that make up a step. It is on these pages that
you customize the properties of the action that the step will perform. You can view the properties of
the step by double-clicking the step, or right-clicking the step and selecting Properties from the menu.
Each step may have one or more of the following pages:
General page
Statement or Settings page
Inputs page
Outputs page
2-20Handler Basics 2017, Interactive Intelligence, Inc.
GENERAL PAGE
Every step has a General page. In this page, you enter the step label and any notes about the step.
This page is often ignored by novice programmers but is very important. When you are building
a handler, the purpose of each step is well known to you. However, several handlers later or after
months have passed this information will not seem so clear. The passage of time is why it is so
important to document the purpose of each step at the time that the handler is written.
Use the label area to give the step a descriptive name that will allow you, or any other handler
developer, to quickly locate the step.
Use the notes area so that you, or any other handler developer, can determine the purpose of the
step and any other useful information concerning the step.
Some of these parameters are be optional. A Statement or Settings page is usually present if the
step has no input or output parameters.
2-21Handler Basics 2017, Interactive Intelligence, Inc.
INPUTS PAGE
This page lists all the parameters needed by the step to perform the action. If a step has an Inputs
page, at least some of the parameters have usually been defined in a previous step. Some of these
parameters are optional.
OUTPUTS PAGE
This page displays the values that are created as a result of the step performing some action. Since
these output values are stored in variables, they can be accessed by other steps in the handler.
For a description of the properties and pages of each step, see the Tools section of the Help. You can
FOR YOUR
INFORMATION
also click the Help button inside a steps Properties notebook for help on that tool.
Whenever a handler contains unsaved changes, Interaction Designer will indicate there are unsaved
changes by placing an asterisk (*) beside the handler name in the title bar.
Saving a handler in Interaction Designer is no different from saving a file in any other Windows-
based program. From the File menu, just select Save or click the save button.
You cannot save a handler and then save another handler with the same name to the same location.
FOR YOUR
INFORMATION
It will overwrite the existing handler. To save a handler with the same name as an existing handler, it
must be saved to a different location.
PUBLISHING A HANDLER
1. From the File menu, choose Publish or click the Publish button on the toolbar.
2. Type a description of your handler in the Publish Handler dialog box that appears. If you want
the handler to be active upon being published, select the Activate Handler check box and select
whether the handler is a Primary or Monitor handler.
4. Click OK in the Publish Handler dialog box to continue the publish process.
INTERMEDIATE PUBLISH
It is possible to design and build your handlers on a development IC server, perform an intermediate
publish, then load them onto the production server to complete the publishing process.
Generating an .i3pub file is a means of breaking the publishing process into two stages so that a
handler can be assembled, packaged into an intermediate format and saved to disk, then transferred
and published on an entirely different server.
This intermediate file contains the .class file, the configuration data for DirectoryServices, the audio
prompt data, and a copy of the .ihd file, along with everything else needed for the publish.
A separate executable is released with Interaction Center called EICPublisherA.exe that allows
users to install the i3pub files without the need for Interaction Designer.
EICPublisherA is a simple command-line utility that can read .i3pub files and finish publishing
them to the current IC server. In addition to publishing, EICPublisherA will also activate the handler
if selected by the Interaction Designer user who created the intermediate file. Users can right-click
on a *.i3pub file, choose Open With, browse to \I3\IC\Server and choose EICPublisherU.exe as
the associated application, allowing a .i3pub file to be published just by double-clicking it.
PUBLISHING INDICATORS
The state of a handler is indicated by a face icon on the Palette toolbar and on the Handler Messages
tab of the Messages Palette.
Icon Meaning
The Red face indicates that the handler is not in a state that
will allow it to be published (for example, contains steps with
required fields not yet assigned values).
A green smiling face does not necessarily mean that the handler will function as intended, merely
FOR YOUR
INFORMATION
that all required fields have been assigned values and the handler is in a state that can be published.
Messages Palette The Messages palette provides information about why a handler is not able to
be published. If a condition exists that would stop a handler from being published, it will be displayed
in the Messages palette.
When a handler or subroutine is first published, you can make it active immediately. If you choose
not to activate the handler, or if the handler has been imported from another server, or previously
been made inactive, you will need to activate it in the Manage Handlers notebook before it can be
used in Interaction Center. Manage Handlers is available under the Utilities menu or in the Server
Configuration in Interaction Administrator. You must have the User Right to Manage Handlers
given in Interaction Administrator to perform this task.
As we have discussed, once a handler has been built it must go through a three-step activation
process. The handler must be:
Saved
Published
Activated
There is a slight difference between publishing a handler which is not yet active and publishing one
which is already active.
A New Handler:
Saving creates the handler as an .ihd file in a location that you specify.
Publishing compiles the handler into a proprietary format and stores it as a .class file.
Activating a handler registers it with the Interaction Processor and puts the handler into
effect immediately.
A handler can be activated during publishing.
This procedure can be performed only after you have published your handler(s).
1. On the Interaction Designer menu bar, choose Utilities... Manage Handlers.
2. On the Primary Handlers page, select the handler(s) in the Inactive Handlers list.
If you do not see the handler listed in the Inactive Handlers list, check the Active Handlers list to
FOR YOUR
INFORMATION
see if the handler is already activated. If so, you do not need to activate the handler and can quit
this procedure now. It may also be that the handler is running as a Monitor Handler.
3. Click the Add button to move the selected handler to the Active Handler list. When you click
OK, the handler is activated and is available for use on the Interaction Center server. You can
now debug the handler.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 5: Managing Handlers
Lab 6: Intermediate Publish
BASIC TOOLS
The Basic tools are versatile tools that provide common programming functionality to the handlers.
They are used to create variables, assign values to variables, and evaluate the values of variables.
Although you will find more tools under the Basic tab in Interaction Designer, we cover only these
four tools in this section:
Assignment
Condition
Selection
Notify Debugger
Each step has a basic function and performs some of the most common tasks in all handlers. These
Basic steps are the building blocks of handler creation. The following pages discuss each step in
more detail.
ASSIGNMENT TOOL
This tool declares a variable and assigns a value to that new variable or to an existing variable.
The assigned value can be the value of another variable, a literal value, or a complex expression
constructed with the Expression Editor Assistant. Once you declare a variable, it is available to all
steps throughout the handler.
For example, an assignment step might copy the value John to the contents of the variable named
sFirstName.
CONDITION
This tool tests a conditional expression and follows the link associated with the result of that test.
A conditional expression resolves to a Boolean value (either True or False). Therefore, a conditional
step has a True exit path and a False exit path.
A conditional step might compare a variable sFirstName to a string value John. If the value of
EXAMPLE
sFirstName contains the string John, then the handler continues execution on the True branch of
the conditional step. However, if sFirstName does not contain the string John, then the handler
continues on the False branch.
SELECTION
This tool tests a list of condition statements. The tool begins testing with the first condition in the list,
then the second, and so on. Each condition in the list has a corresponding exit path. The first condition
that evaluates to true causes the handler to follow the exit path associated with that condition.
Statements Page On the Statements page you can add, edit, delete, or change the order of the
conditions. The conditions in the list are evaluated in the order they are listed. The first true
conditions exit path will be followed.
Condition list This is a list of any conditions you have built using the Add or Edit button. There is an
exit path for every condition in this step.
Add button Click this button to create a condition in the Condition list. You can use the Expression
Editor Assistant to build the condition expression. Adding a condition will also add an exit path that
corresponds to that condition.
Edit button Click this button to edit the selected condition in the Condition list.
Delete button Click this button to delete the selected condition from the Condition list. Deleting a
condition will also delete its corresponding exit path.
Move Up button Click this button to move the selected condition higher in the Condition list.
Move Down button Click this button to move the selected condition lower in the Condition list.
Exit Paths The exit paths for this tool are the conditions in the Condition list. An exit path will
appear for each condition. A default exit path is always present and is taken if no conditions evaluate
to true.
NOTIFY DEBUGGER
Settings Page:
Label Enter the unique label for this debug session. This is a required field. If you add another
Notify Debugger step to this handler, it must have different name.
Exit Path:
Next This step always exits along the Next exit path.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 7: Programming Logic: Variables
Lab 8: Programming Logic: Condition and Selection
Lab 9: Working with Basic Tools
DEBUGGING HANDLERS
Debugging allows you to monitor a handler as it runs and to pause it at locations or situations of your
choosing by setting breakpoints. When the handler runs on the server, it pauses when it reaches the
selected initial breakpoint, either the initiator or a Notify Debugger step. You can then establish other
breakpoints in the handler and let the handler execute until it reaches the next breakpoint.
By setting a breakpoint on a particular step, you can allow the handler to execute normally until
it reaches that step, at which point execution will pause.
By setting a breakpoint on a change in a variable, you can have the debugger pause execution
(break) whenever the handler changes the variables value.
When debugging a handler, you are viewing the handler in read-only mode. You can view step
properties by double-clicking the step.
When a subroutine step is encountered you can step into the subroutine to debug it, by clicking
the Step Into button on the toolbar.
Normal Mode is used for designing and working with handlers, while Debug Mode is used for
debugging and dissecting handlers. Each mode is described more completely on the following pages.
In Normal Mode:
You can edit steps.
The Normal Mode icon appears in the Title Bar.
In the title bar, the file name is followed by .ihd.
The Debug toolbar is not visible.
The Debug palette is not displayed.
The wallpaper is white and may have the grid display if you have the option selected.
The Interaction Designers Debug mode is closely integrated with Interaction Processor to support
debugging over a network. This integration allows you to run Interaction Designer on a client
workstation to debug a handler even though that handler is actually executing on the server.
In Debug Mode:
You cannot edit steps.
The Debug Mode icon appears in the Title Bar.
The Debug watermark appears in the handler.
The Debug toolbar is displayed.
The Debug Palette is displayed.
You can set execution to a prior step.
You can change the value of variables under the Watch Variables, Step Variables, or Handler
Variables tabs of the Debug Palette.
Stop Session Stops the debug session. A prompt gives you the choice to allow the handler to
complete its execution or to terminate it at the current step.
Run Advances to the next breakpoint or the end of the handler if there are no more
breakpoints.
Step Allows you to advance through the handler one step at a time.
Step Into Subroutine Opens up the subroutine associated with the current subroutine step, in
debug mode. This option is only selectable if the current step is a subroutine step.
Step Out of Handler Used to step out of the current handler. If the current handler is a
subroutine, the debug session returns to the calling handler. Otherwise, the debug session stops
and the handler executes to the end.
Show Step Being Executed in Current Handler Brings focus to the step currently being executed.
Add Handler to Debug Session Opens the Add Handler(s) to Debug Session dialog which
allows you to select one or more handlers to debug.
Restart Debug Session Used to start a new debugging session for the handler.
DEBUG PROCESS
Use one of the following methods to place a handler into debug mode:
From the Utilities menu, choose Debug Handlers.
Select the handler(s) that you want to debug and press OK. You can select multiple handlers
using shift-click or control-click.
OR
Open the handler(s) that you want to debug.
Publish the handler(s) if you have made changes to it.
From the File menu, choose Debug Immediate or click the Debug tool on the Standard Toolbar.
THEN
Invoke the event that starts the handler. This event is defined by the handlers initiator.
Move through the steps of the handler using the Debug tools.
Use the Debug palette to monitor variable values.
1. From the Utilities menu, choose Debug. The Debug Handler(s) dialog box appears.
2. Select the handler you want to debug from the list of handlers.
You can select multiple handlers to place in Debug Mode using Ctrl-click and Shift-click.
FOR YOUR
INFORMATION
If the handler contains at least one Notify Debugger step, you will be prompted to select the
initial breakpoint.
A read-only copy of the handler appears in Interaction Designer. Active breakpoint steps appear
in red.
When the handler is started on the Interaction Center server, the initial breakpoint in the handler
becomes highlighted and the handler execution pauses. The handler is now running in debug mode.
While in debug mode, you can check the values of variables and determine which step is changing
the value of a variable.
SETTING A BREAKPOINT
A breakpoint causes a handler running in debug mode to pause execution. While the handler is
paused, you can check the values of variables. There are two ways to create breakpoints in handlers.
Publish a handler with Notify Debugger steps.
Create a breakpoint on a step after the handler is in debug mode.
If a handler does not have a Notify Debugger step in it, the Initiator will serve as a breakpoint when
FOR YOUR
INFORMATION
debug mode is started.
When you run a handler in debug mode, the Debug Palette is automatically opened. The Debug
Palette contains four tabs for viewing the activity of a handler during a debug session - Watch
Variables, Step Variables, Handler Variables, and Call Stack.
The Watch Variables page is used to select specific variables that you are interested in monitoring
during the debug session. To add a variable to the Watch Variables page:
Right-click in the page and select Add Watch from the menu.
Double-click Break On Value Change if you want to create a breakpoint when the variable
value changes.
Click any underlined value to change the variable value while debugging.
Values displayed in red have been changed by the current step. If a variable is of a List type, you can
FOR YOUR
INFORMATION
see all of the values in the list by clicking the plus sign (+) to expand it.
The Step Variables page is used to view variables used by a particular step in a handler running
in debug mode. As you step through the handler or advance to the next breakpoint this page will
display all variables used by the currently selected step. You can step through the handler keeping
the Step Variables page open to view variables and their values for every step. You can click any
underlined value to change that value manually for the debug session.
Values displayed in red have been changed by the current step. If a variable is of a List type, you can
FOR YOUR
INFORMATION
see all of the values in the list by clicking the plus sign (+) to expand it.
The Handler Variables page is used to view all of the variables that are defined for a handler running in
debug mode. You can click any underlined value to change that value manually for the debug session.
Values displayed in red have been changed by the current step. If a variable is of a List type, you can
FOR YOUR
INFORMATION
see all the values in the list by clicking the plus sign (+) to expand it.
You can select entries in the page to view other handlers that are in the call stack. For example, in
the illustration above, if you double-click the 1 in the Level column, focus will be set to that handler.
The calling step is displayed with a dashed line around it.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following lab in your lab manual:
Lab 10: Debugging Handlers
DEPENDENCY VIEWER
Track dependencies in handlers by using Dependency Viewer.
Interaction Designer supports the ability to track dependencies for the following objects used
in handlers:
DB Profiles
Global Variables
HTML Templates
Initiators
International String Resources
Prompt Resources
Sequence Resources
Subroutines
Tools
Choose the dependency that you want to view by selecting the appropriate item from the
Dependency: list box. Users can choose to group each type of dependency information in two
ways. You can either select to view the dependency information by what items (variables, tools, and
so on) are used by a handler or by handlers that use each item by clicking the appropriate Group
By radio button on the dialog.
One thing to remember is that the dependency information displayed in this dialog is for published
FOR YOUR
INFORMATION
handlers only. Actions performed on a handler that has not been published will not cause an update
in the dependency information.
Other Options:
Export Dependency to XML Opens a Save As dialog to allow you to specify a file name and
folder in which to store the XML file.
Download Handler Opens a Browse for Folder dialog so that you can select a destination for
the selected handler when downloaded and opens that handler in Interaction Designer.
Debug Handler Opens the selected handler in debug mode.
The Dependency Viewer will allow you to place an inactive handler into debug mode, which can lead
CAUTION
to confusing behavior. Even though the handler looks like it is awaiting notification, it will not run.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following lab in your lab manual:
Lab 11: Using the Dependency Viewer
SUBROUTINES
As we have already discussed, subroutines are handlers started by other handlers, as opposed to
handlers started by events on the Interaction Center server.
When an event initiated handler begins it is because an event in Interaction Center matches the
initiators properties. The handler executes step by step until it ends or encounters a subroutine call step.
Each subroutine that you create has its own unique subroutine call step.
When a handler executes a subroutine call step, it calls another handler that has a subroutine
initiator. Subroutines can only be started by a subroutine call from another handler. The subroutine
executes all of its steps. When the subroutine ends, control is returned to the subroutine call step of
the calling handler.
When the properties in Handler1s initiator are met, an instance of the handler begins. When it
EXAMPLE
reaches a subroutine call step the handler begins to execute the commands of Subroutine1. This
subroutine is like a detour. When all the steps are finished in the subroutine, the process is returned
to Handler1 to continue processing.
USING SUBROUTINES
Organizing Handler Logic Subroutines make handler building more visually manageable and
understandable. By localizing groups of steps into subroutines, you can cut down on the number of
steps that appear in the calling handler. Handlers with hundreds of steps can be difficult to understand
and manage; a few subroutines can make a large handler easier to modify and understand. Essentially,
by using subroutines properly, you break down the logic into bite-sized pieces.
Creating Logical Blocks of Code A subroutine can encapsulate a set of logic into a single callable
action. You can reuse a subroutine by calling it from any handler where that set of logic is appropriate.
Imagine that you have created a subroutine called LookupAccountNumber. Given a name, that
EXAMPLE
subroutine will open a customer database, look up the associated account number, and return
the account number to the handler that called it. Now, imagine a system of handlers that deals
with customer support. In such a system, the need to retrieve customer account numbers is
a common one. Thus, when you build the customer support system, you would be able to call
LookupAccountNumber from any handler that needs such information.
Easing the Maintenance Burden Recall the first example of LookupAccountNumber. Suppose that,
after your customer support handlers are finished and working, the customer database is redesigned.
Instead of directly tying customer name to account number the database has been changed to tie
CREATING A SUBROUTINE
When publishing a subroutine, select or enter a subroutine category on the Publish Handler dialog.
If you want to create a Subroutine category, type the name in the Subroutine Category box. This
action tells Interaction Designer to create a tab on the Subroutines Page of the Design Palette when
you publish the subroutine.
Subroutine categories are collections of subroutines. They appear together in the Subroutines Page
of the Design Palette. During the publish process, Interaction Designer creates a subroutine tool on
the Subroutines Page of the Design Palette in the category you specify.
When you publish HandlerClass_InputSomeDigits, the Publish Handler dialog box appears. When
EXAMPLE
you type in the new Subroutine Category, HandlerClass, a subroutine call is created under that
category on the Subroutines Page of the Design Palette.
Make the subroutine active either by checking the Activate Handler check box when you publish it
CRITICAL
or through the Utlities|Manage Handlers menu choice.
When a subroutine is published, a tool for that subroutine appears on the Subroutines Page of the
Design Palette. To create a call to the subroutine from any handler, just drag the subroutine tool
from the Subroutines Page of the Design Palette and drop it onto the handler.
To call the HandlerClass_InputSomeDigits subroutine, drag the subroutine call step from under the
EXAMPLE
HandlerClass Subroutines category into the handler, then connect it to the appropriate steps.
After adding the subroutine call into the handler, you may need to enter parameter information into
FOR YOUR
INFORMATION
the subroutine call step.
Input Only is another parameter that may have to be defined. It defaults to Input Only = False.
FOR YOUR
INFORMATION
SUBROUTINE PARAMETERS
The subroutine initiator Properties dialog is used to define parameters that will be passed between
a subroutine and its calling handler or used as variables in the subroutine. When you publish any
subroutine, the parameters that you created on the parameters page will become parameters in a
subroutine tool that calls the subroutine. The subroutine tool will appear on the Subroutines Page
of the Design Palette.
PASSING PARAMETERS
Notice the cleared check box. Because it is not checked, any change to the variable will be passed
back to the calling handler. The new value is used for any proceeding steps. In other words, the
variable is defined as an input/output variablea copy goes into the subroutine and comes back,
changing the original.
When the check box is checked, any changes to the variable are not sent back to the calling handler.
The calling handler will retain its value for the variable and use that for any subsequent steps. In
other words, the variable is defined as an input only variablea copy goes into the subroutine, but
does not come back.
IN CLASS EXERCISE
Using the previous diagram, find the value of X in Handler 1 given the following conditions:
True True
True False
False True
False False
When a parameter is added to the Subroutine Initiator, it appears as a parameter on the Subroutine
Call step. There may be three pages on the Subroutine Call step: A standard properties sheet, an
input page, and an output page.
Inputs Page This page shows any of the parameters defined in the Subroutine Initiator as being
Input Only=True. This information means the value of the variable will be passed into the subroutine
but the value of the variable will not be returned to the calling handler. If there are no parameters
with this setting, there will be no Inputs page on the Subroutine Call step.
OBJECTS IN SUBROUTINES
To have an object move through a subroutine, you must make reference to it as a parameter in the
subroutine initiator. Otherwise, the object will not pass into the subroutine and you will not be able
to act on it in the subroutine.
Objects that are passed into a subroutine must be defined as any other variable in a handler.
Playing audio to a caller in a subroutine requires passing a Call ID variable with the following
EXAMPLE
information into that subroutine from a base handler:
Property Value
Label Interaction1
Type CallID
Variable Interaction1
Creating a variable for this object then passes it into the subroutine so the audio steps can interact
with the object.
If you did not configure the object being passed into a subroutine properly, the handler will not see
CAUTION
the object and therefore cannot act on that object.
Labs
Complete the following labs in your lab manual:
Lab 12: Working with Interaction1
Lab 13: Passing Parameters
EXPRESSIONS
Expressions are formulas that process literal values, variables, and operators to create a value.
You will find this type of processing useful in all but the simplest handlers, so understanding how
to create expressions will allow you to create flexible and powerful handlers. This topic offers the
information needed to begin building your own expressions.
You can create an expression for any input parameter that takes a normal value. You cannot create
FOR YOUR
INFORMATION
expressions for input parameters that take extended values, such as Call ID. You cannot create an
expression in an Output parameter. Output parameters can contain only variables.
EXPRESSION COMPONENTS
Literal Values Literal values are the simplest of expressions. For example, if an email Address input
parameter takes a string value, you can type joebob@aol.com. When the tool executes, the email is
sent to the specified address.
Remember that literal string values must be placed within quotation marks joebob@aol.com.
FOR YOUR
INFORMATION
One of the more useful features of literal values is that they can form part of a larger expression. For
example, you might have a Play Audio step that looks for the Do Not Disturb recording for a user.
Your expression might look something like this: StrUserName & _Do_Not_Disturb.wav.
This expression appends the string value contained in the variable StrUserName to the literal text
_Do_Not_Disturb.wav to form a unique file name when the tool executes.
Variables Variables are containers for values. Variables exist for both normal and extended types,
however you can declare variables only for normal types. Extended type variables are declared
automatically when you insert a step that processes an extended type value. There are multiple ways
to create a variable in a handler.
Explicitly declare one with the Assignment tool.
Implicitly create them when you drag a tool into a handler where that tool contains variable
names. For example, if you insert an Extended Place Call step into your handler, the variable
Digits is automatically declared in the handler.
Explicitly create one using the Variables Palette.
Create a variable within a Subroutine Initiator
Operators Operators are reserved words in expressions that act on literal values and variables. For
each normal data type, there is a set of operators that produce that data type. For example,
mathematical operators perform addition, subtraction, multiplication, and other operations on
integer and numeric values. String operators process strings, and so on.
EXPRESSION TYPES
Expressions have types depending on the result expected. Interaction Designer will not allow the
creation of an expression if the result does not match the type of the expression.
If an expression has a type of string, then the value can be Dog but not Dog or 4.
EXAMPLE
2+2 Integer
2+2 Integer
2+2=5 String
2+2=5 Boolean
You can use the Expression Editor Assistant in any parameter that has the right-arrow button at the
end of it. When you click this button the Expression Editor Assistant appears.
Categories The box on the left contains a list of operator Categories to select from when building your
expression. For each normal value type, there are several operators that produce a value of that type.
Variables Any variables defined in this handler of the expected type will be listed here.
Literal values These operators work with literal values, such as for string types or 1 for
integer types.
Type Conversions These operators convert one type of data to another.
Mathematical operations These operators perform math operations.
Comparison operations These operators compare two values and return a Boolean value.
String operations These operators perform string operations.
Symbols and Values This lists the available operators for each category based on the expression type.
Expression Type This is the type of expression expected.
Expression Editor Assistant limits your choice of operators to those that are legal for the input
parameter or selected operand. For example, if you are editing an input parameter that expects a
string, then only operators that result in strings are displayed in Expression Editor Assistant. This
rule also applies to operands. If you select an operand that expects an integer, Expression Editor
Assistant limits your operator choices to those that produce an integer.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following lab in your lab manual:
Lab 14: Building Expressions
Default Handlers
3
Outbound Calls
Incoming Calls
1. When a call is made from a telephone handset, a Station Off Hook event triggers the System_
StationOffHook handler. This handler then generates an Outgoing Call Request event.
OR
When a call is made from the Interaction Desktop, an Outgoing Call Request event is
generated.
2. This event spawns an instance of the System_InitiateCallRequest handler. The main function of
this handler is to place an intercom call or a call on an outside line.
3. The System_InitiateCallRequest handler then passes the number dialed from Interaction
Desktop or handset into a subroutine called I3DialPlan.
4. I3DialPlan performs several important functions:
a. It gathers information about the phone number that was configured in the Phone Numbers
container in Interaction Administrator, such as Classification, Account Code information, Line
Groups, Display String, Dial String, and so on.
b. If there is no classification, I3DialPlan will determine if the call is internal, and if so, what user,
station or workgroup queue is being called. If I3DialPlan determines the call is external, it will
continue processing the call as such.
c. It determines if the call is coming from the system queue, a user queue, or a station queue.
d. If the call is from the system, I3DialPlan determines if the call is to an internal or external
number. If it is internal, the handler checks to see if it is to a user, station, or workgroup
queue and returns to System_InitiateCallRequest. If it is from the system queue and external,
I3DialPlan grabs the information that was configured in IA in the Phone Numbers container and
passes that information back to System_InitiateCallRequest.
e. If the call is from a valid station or user, then the classifications that are allowed for the
station or user. Classification settings are configured in Interaction Administrator. I3DialPlan
grabs the information that was configured in IA in the Phone Numbers container and passes
that information back to System_InitiateCallRequest.
f. Ultimately, I3DialPlan will return control to System_InitiateCallRequest, passing parameters
back to System_InitiateCallRequest which determines how to handle the call (e.g., Dial Plan
error, invalid security, external call, invalid extension, or internal call).
Event That Starts the Process Placing a call from a SIP station generates Station Off Hook event.
Purpose Allow multiple methods of making outbound calls.
Labs
Complete the following labs in your lab manual:
Lab 15: Navigating Outbound Calls
Interaction Center stores calls in areas of the system called queues. There are several different
kinds of queues, but you can think of each of them as a holding place or bucket with an
effectively infinite capacity.
System Queue When a call first comes into Interaction Center, an Incoming Call Event is
generated. When this happens, the call is placed on the System Queue until Interaction Center
determines that calls destination.
Non-System Queue If the caller dials an extension, a Call to Non-System Queue Event is generated.
Interaction Center looks up the numbers dialed and matches them with a user, a station, a station
group, or an ACD workgroup and directs the call to the appropriate location. (There are other queues,
such as line queues, but we will focus on the ultimate destination of the call in this discussion.)
Not allowing System_IncomingCall to complete can cause the loss of some call processing. You may
CAUTION
need to duplicate this functionality in CustomAnswer if System_IncomingCall is not going to execute
this functionality.
SystemIncomingCallAnalysis This subroutine calls the CustomIncomingCallAnalysis
subroutine which evaluates whether an unanswered incoming call resides on a line that is
marked for outbound calls only. CustomIncomingCallAnalysis retrieves the LineName attribute
from the call object and looks up the line in Directory Services to determine if it is Inbound,
Outbound, or Inbound/Outbound. If the line is Outbound only, the call is disconnected. If the line
is Inbound, or Inbound/Outbound, this subroutine ends and the call continues as normal.
CustomIncomingCall Modify this handler to add custom behaviors for incoming calls after
they have been answered. These behaviors can be a custom greeting, call screening, or some
other behavior. Currently this handler returns bTransferred = False. If you add customizations
that could send the call out of the normal IVR, be sure to set bTransferred = True so that
System_IncomingCall ends.
Any modifications you make to this subroutine are not overwritten when you upgrade to newer
versions of Interaction Center.
SystemDNISRouting This handler examines the number dialed on an inbound call and tries
to match it against a number in the Interaction Administrator DNIS routing table. If a match
cannot be found, this handler ends. If a match is found, this handler looks up and determines
the queue type. If the number is found, a Blind Transfer step is called that generates a Call
Offering Non-System Queue event which starts the System_CallOfferingNonSystemQueue
handler. Otherwise, control is returned to System_IncomingCall.
InteractionAttendantEntryPoint Passes the call on to the Interaction Attendant handlers
for processing.
SystemIncomingTAPI If the Protocol ID of the incoming call is TAPI, this subroutine is called.
This situation would only apply when IC is installed to work with Cisco CallManager. Otherwise,
control is returned to System_IncomingCall.
SystemIncomingSIP If the Protocol ID of the incoming call is SIP, this subroutine is called.
Otherwise, control is returned to System_IncomingCall. SystemIncomingSIP provides the
subroutine CustomIncomingSIP as a customization point for inbound SIP calls.
Event That Starts the Process A Call Offering Non-System Queue event.
Purpose This handler routes a DID call to the appropriate Non-System Queue.
Handlers:
System_CallOfferingNonSystemQueue This handler starts any time a Call to Non-System
Queue event is generated. (The Blind Transfer tool generates this event.) This handler
determines the type of queue the call should be sent to and starts an appropriate
subroutine (either SystemIVRCallOfferingStationGroupQueue, SystemIVRStationQueue,
SystemIVRWorkgroupQueue, or SystemIVRUserQueue) to process the call.
When the call returns from the appropriate subroutine, System_CallOffering- NonSystemQueue
checks to see if the call is intended for voice mail and calls the voice mail subroutine to process it.
Exit Conditions:
If the queue type is Workgroup, SystemIVRCallOfferingWorkgroupQueue is called and this
handler ends.
If the queue type is Station Group, SystemIVRCallOfferingStationGroupQueue is called and this
handler ends.
If the queue type is Station, SystemIVRCallOfferingStationQueue is called and this handler ends.
If the queue type is User, SystemIVRCallOfferingUserQueue is called and this handler ends.
If the queue identifier is not valid, the Query Queue Type step will fail and this handler ends.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 16: Navigating Incoming Calls
Lab 17: Understanding p_bTransferred
Interaction Attendant
4
Call Processing and Interaction Attendant
Suppose that your company offers two levels of technical support: Silver and Gold. Silver
EXAMPLE
members call 555-1111, and Gold members call 555-2222. To tell Attendant how to handle
support calls, you would use Attendant to create an inbound profile for each telephone number.
Each profile filters calls to match one of the numbers. When callers dial 555-2222, their call is
processed by the profile for Gold support. When callers dial 555-1111, their call is processed
by the profile for Silver technical support. In this scenario, Attendant uses Dialed Number
Identification Service (DNIS) to determine the number dialed. Since Attendant knows the dialed
number, it can perform unique processing on the call. For example, it can play special messages
or offer alternate menu choices.
The main idea is that profiles are compared to calls to see if the call matches a profile
characteristic of some sort. For example: Was this particular number dialed? Did they call our
800 number? You can define as many profiles as you need to define.
Here is another scenario: Suppose that Marketing needs special call routing. They want to
automatically route calls from their biggest customer directly to the person who manages that
account. To catch these calls, you would define a profile that examines the telephone number of the
caller, rather than the number dialed. A profile of this type uses a process called Automatic Number
Identification, or ANI for short. ANI is sometimes called Caller ID, and it is the opposite of DNIS.
DNIS indicates the number that was called. ANI provides the telephone number of the caller.
Labs
There are no labs associated with this module.
Interaction Attendant has many operators that can be used to customize the automated attendant
for an IC system. With Interaction Attendant, you can perform transfers, database lookups, get user
input, send and receive faxes, and much more.
The Subroutine Initiator Operator is an operator in Interaction Attendant that works with
the CustomSubroutineInitiatorRouter handler to allow you to call subroutines from within
Interaction Attendant.
Customization points are calls to customization subroutines. Customization subroutine calls will always
be in the same location to ensure that they are not overwritten by future hotfixes or service updates.
The Subroutine Initiator Operator within Interaction Attendant provides a means of calling
subroutines from within an Interaction Attendant menu, making Interaction Attendant extensible.
The Subroutine Initiator properties specify the name of the subroutine to be called when this
operator is selected, either by a number press from a caller or a call from another menu item. This
functionality is achieved by the CustomSubroutineInitiatorRouter.ihd handler which is modified to
contain a selection step to invoke the functionality of the subroutine. Once the selection is added to
the selection step, connect it to your subroutine call step.
USING VARIABLES
Previously, we defined a variable as a symbol or name that stands for a value. In handlers, there are
three kinds of variables that you can use:
Local variables A local variable can only be used in the handler in which it is defined.
The value of local variables can be passed through to subroutines only if they are defined in the
subroutines initiator. Local variables are created by doing one of the following:
Using an Assignment step to define the variable.
Using the Variables palette to define the variable.
Using the Initiator to define the variable.
Global variables are defined in the Global Variable Manager which is accessed either through
File>Import Global Variables... or by right-clicking in the Variables palette and selecting Import
Global Variables...
Global variables are locked throughout the duration of a handler instance. For this reason, create
subroutines that read and/or modify a global variable to minimize the time the global variable is locked.
Server Parameters In Interaction Administrator, you can define Server Parameters which are
available on the IC server on which they are defined. To access the parameter value from within a
handler, you use the Get DS Parameter tool. You can also create the parameter using this tool.
Server Parameters are typically used for values that may need to be changed by an IC Administrator.
The administrator can change the value in Interaction Administrator without ever opening
Interaction Designer. Once the value is changed, any handler that references the parameter will
read the new value. Server Parameters are always of string data type.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 18: Using CustomSubroutineInitiator
Lab 19: Using Server Parameters
Lab 20: Team Build
Automatic Call Distribution (ACD) with Multimedia Queuing is a system that intelligently routes
interactions (calls, Internet chat sessions, call-back requests, email, and so on) to available agents.
There is no limit to the number or size of the ACD queues configured to receive interactions.
Interaction Centers ACD quickly finds the best match between agent and interaction by calculating
agent scores and interaction scores. These scores are calculated by a subsystem on the Interaction
Center Server called the ACD Server. Using Custom ACD, you can configure the formula used to
calculate these scores, and customize the ACD system to meet your needs.
Simple (or Basic) ACD When an ACD workgroup has been assigned a queue type of ACD in
Interaction Administrator, interactions can be routed to an agent based upon:
Time an agent has been available
Agent cost
Agent skill proficiency
The priority of an interaction
Time an interaction has been in the queue
The Interaction Center Custom ACD capabilities are configured through both Interaction
Administrator settings and handlers. The attributes of each agent (skills, proficiencies, cost, or other
attributes you create) are assigned in Interaction Administrator. Whether you are adding an agent,
or updating an agent profile, the change takes effect immediately.
The skill, priority, and cost requirements for an interaction are assigned through handler
modifications. Interaction Center generates a list of available qualified agents who can take the
interaction. Then Interaction Center selects the most appropriate agent to take the interaction
based on any combination of skills, cost, other attributes, and/or availability. If an interaction goes
unanswered or remains on hold too long, you can flag that interaction for special processing.
In this class, we will be focusing on Custom ACD processing.
FOR YOUR
INFORMATION
INTERACTION TYPES
Callbacks A callback is a request sent from a customer at a website that will generate an outbound
call to the customer from an available agent. Aside from how the call is made, this interaction is
essentially a standard telephone call.
Calls Telephone calls are the most common type of interaction routed by ACD processing.
Chats Chats can be processed in the ACD just like telephone calls with two exceptions:
Chats cannot be assigned to phone-only agents.
Chats cannot use hunt groups.
Email Workgroups can be configured to receive ACD routed email from multiple mailboxes. email
queuing is configured in Interaction Administrator in the Workgroups container. From Workgroups
properties, select the ACD page and select Routing.
The Interaction Center ACD is designed to intelligently match interactions to available agents under
two scenarios:
Interactions < Agents The first scenario occurs when an interaction arrives in the ACD queue and
there are many agents available to answer the interaction. In this scenario, the goal is to select the
most appropriate agent for that interaction. You configure the ACD processing to select the most
appropriate agent based on skills, cost, and the amount of time an agent has been available. You can
also create custom attributes on which the agent is selected.
Interactions > Agents The second scenario occurs when there are many interactions waiting to be
picked up from the queue and an agent becomes available. The goal for this scenario is to select
the most appropriate interaction to present to the available agent. Again, you configure the ACD
processing to select the appropriate call based on agent skills, interaction priority, and amount of
time an interaction has been waiting in the ACD queue or the Interaction Center system.
1. An interaction arrives.
Each time an interaction arrives in Interaction Center, it is evaluated and routed to the
appropriate queue. Possible queues are user queues, workgroup queues, station queues, and
ACD queues. Any interaction sent to an ACD queue is flagged for ACD processing.
2. A list of available agents is generated.
Every agent with a status of Available who is not already engaged in an Interaction is added to
the list of agents that could answer the interaction.
3. The agent list is filtered based upon skill requirements.
If the interaction requires a skill, agents without the minimum skill requirements are removed
from the list.
4. Agent scores are calculated.
Now Interaction Center calculates a score for each agent in the list using the agent score formula.
5. The agent with the highest score is selected to receive the interaction.
Skills A skill is an agent attribute, and each agent can have one or more skills. (Agents can also
inherit one or more skills when they become a member of a certain workgroup.) Along with each
skill is a proficiency level. Proficiency levels are used in calculating both agent and interaction
scores. Interactions can require minimum proficiency levels for one or more skills. If an agent has a
Microsoft Word skill with a proficiency of 50, that agent will not be assigned to any interactions with
a Microsoft Word proficiency requirement of 51 or greater.
Also, associated with each skill is a measure of that agents desire to use that skill. (Alternately,
desire to use could be the organizations desire for an agent to use that skill.) This value can also
be used to increase agent score, and therefore increase chances of the agent for receiving an
interaction that requires that skill.
Attributes Attributes are agent and interaction characteristics such as skills, cost, and priority.
Agent attributes are assigned in the Interaction Administrator.
Interaction attributes are assigned and modified in handlers. A weight is associated with each
attribute that determines how that attribute affects the agent or interaction score. Interaction
Center provides the option of creating custom agent attributes.
5-11Customizing the System 2017, Interactive Intelligence, Inc.
Cost Cost is an agent attribute. Agent cost can be used in calculating agent scores. You can
configure your ACD to prefer agents with low cost or high cost. While cost can be related to agent
salary, you might assign a high cost to agents that will take longer to determine a solution. It might
also be cost to the customer.
INHERITED SKILLS
Inherited Skills When a user belongs to a workgroup, they inherit all the skills for that workgroup.
These skills appear in the Inherited Skills box. If the user has their own user-specific skills, they
appear in the skills box.
Multiple Workgroups When ACD Server evaluates required skills, it first looks for skills that were
explicitly assigned to that agent from Interaction Administrator.
If the required skills were not explicitly assigned, ACD Server looks at the skills that the agent
inherited from any workgroups to which he or she belongs.
The agents entire set of skills is used to evaluate an interaction on a workgroup queue.
1. Create a workgroup.
2. Create a queue.
3. Select a queue management type.
4. Activate the workgroup.
5. Assign members.
6. Assign agent utilization.
Create a Workgroup From Interaction Administrator, create a workgroup in the Workgroups
container.
Assign a Queue On the Configuration tab, select the Workgroup has Queue check box for this
workgroup to receive interactions. If this check box is not checked, the workgroup will not have a
queue and will not be able to receive interactions.
Assign a Queue Management Type A Queue Management Type defines how a workgroup will
behave when an interaction reaches the queue. This feature allows you to set up simple ACD and
hunt groups with no handler modifications.
ACD This is simple (or basic) ACD requiring no handler modifications. When an interaction
enters the workgroup, it will be assigned to an agent based upon the following properties:
Who has been in Available status the longest
The cost setting in Interaction Administrator
The proficiency level of a skill
Sequential When an interaction enters the workgroup, individual members of that workgroup
who are logged on and available will be alerted. Members are alerted to the interaction in the
order specified in Workgroup Configuration properties> Members page > Currently Selected
Users. If setting up a Hunt Group, check the Maintain order on this page.
Activate the Workgroup On the Workgroup Configuration tab, the Active check box is selected by
default. If you clear this check box, the workgroup will not receive interactions.
For a workgroup to receive interactions, it must have a queue and be active.
CAUTION
Assign users:
The Members page of the Workgroup properties allows the administrator to add or remove users
from this workgroup. The Maintain Order check box is used with the Sequential Ring Queue
Management Type to set up hunt groups.
Membership in workgroups can also be granted in the Users container.
Agents may be able to handle multiple phone calls, emails, and/or text chats simultaneously and in
any combination. Using the Agent Utilization feature, you can set how many interaction tasks an
agent can be presented at one time by using a percentage.
If the Chat category for an agent is set to 25%, it would mean that the agent could handle up to four
EXAMPLE
Chat events simultaneously. Indicating 100% for an event type would mean that the agent could
handle only one such event at a time. The percentages can vary from agent to agent based on their
experience. Agents are considered available if that the sum of the percentage utilization of all their
current interactions is less than 100.
If an agent is configured so that phone calls are set to 100 percent, chats to 25 percent, and emails
EXAMPLE
to 10 percent, then the agent could, process one phone call, or four chats, or two chats and five
emails, or one chat and seven emails, and so forth.
The Max. Assign. value allows you to further structure agent interactions. Using the previous
example, you can set agent emails to 10% so that the agent could take five emails while handling
two chats. However, you may never want the agent to handle 10 emails at one time. In that case, you
could set the Max. Assign. value to something less than 10 - we will use 6 in our example. That way
the agent will never be presented with more than six emails at any given time, even though that adds
up to just 60% utilization, but you can still achieve the total interaction values that you want.
Agent Utilization setting, set in the User Configuration, override Workgroup Utilization settings.
FOR YOUR
INFORMATION
It is recommended that you set the percent utilization for calls no lower than 51 percent.
CAUTION
Inherited Skills Skills can be assigned to workgroups in the Workgroup ACD configuration
screen. Any member of this workgroup automatically inherits those skills and default values for
the Proficiency and Desire to use fields. The complete set of skills assigned to each workgroup
to which the user belongs appears in this list.
Skills You can assign skills to each agent in addition to any skills inherited from the workgroups
to which the agent belongs. Agent total skill set is the union of Inherited Skills plus the agent skills
in this list. Agent inherited skills, Proficiency and Desire to use, can also be overridden.
Proficiency Type a positive whole number from 1 through 100 to assign a proficiency level for
the selected skill to this agent. The higher the number, the greater the skill level.
Desire to use Type a positive whole number from 0 through 100 to assign a Desire to use level
for the selected skill to this user. The higher the number, the greater the level of desire the agent
has to use this skill (or that the supervisor has for the agent to use the skill).
Type a positive number from 1 to 100 to define the cost attribute for this agent. This attribute could
be a relative number to represent agent salary or some other value. By default, the Agent Score
Formula prefers agents with a high cost. If you want it to prefer agents with a low cost, change the
Weight for Agent Cost attribute in the ACD Initiate Processing step to a negative value.
Examine the handlers involved in processing a call to a workgroup with a Queue Management Type
of Custom.
1. A call comes into the system and is handled by Interaction Attendant.
2. The caller listens to the menu and presses a key to be transferred to a Custom ACD workgroup.
3. The Interaction Attendant handler responsible for the Workgroup Transfer operation contains
a Blind Transfer step that will transfer the call to the workgroup. This generates an event called
Call to Non-System Queue which fires the System_CallOfferingNonSystemQueue handler.
4. System_CallOfferingNonSystemQueue calls the InteractionAttendantEntryPoint subroutine to
determine if this is a workgroup transfer to an ACD Queue Management type. If so, it begins the
ACD processing with the ACD Initiate Processing step. If not, as in this example, this subroutine
ends, and control returns to System_CallOfferingNonSystemQueue.
5. System_CallOfferingNonSystemQueue determines if this call should be transferred to a user
queue, workgroup queue, or station queue and calls a subroutine based upon the queue
type. In the case of Custom ACD processing, the subroutine that will handle the call is
SystemIVRCallOfferingWorkgroupQueue.
6. SystemIVRCallOfferingWorkgroupQueue checks to see if this is a call or some other type of
interaction. If it is something other than a call, it will be passed to a customization point named
SystemWorkgroupQueueInteraction where ACD processing for interactions other than calls
occurs. A call is passed to SystemIVRWorkgroupQueueAlert.
7. SystemIVRWorkgroupQueueAlert checks the queue management type for the workgroup. If it
is a Custom ACD workgroup, the call is passed into the CustomIVRWorkgroupQueue handler
where custom ACD processing begins with the ACD Initiate Processing step. Note that you
need to add the Selection step to CustomIVRWorkgroupQueue to decide which workgroup to
process. You also need to set p_bTransferred to True when the call goes to ACD processing.
Customizations required for custom ACD for interaction types, other than calls, are made in the
FOR YOUR
INFORMATION
CustomIVRWorkgroupQueueEmail, and CustomIVRWorkgroupQueueInteraction handlers.
This tool defines the requirements for a skill needed for an interaction. ACD Specify Interaction Skill
steps must precede ACD Initiate Processing steps if you are doing skills-based routing using Custom
ACD. You might also want to configure the ACD Initiate Processing step to assign the call to an
agent based on skill by increasing the values for Weight for Agent Skill and Weight for Skill.
When ACD Server evaluates a skills associated with a call, it first looks for skills that were explicitly
FOR YOUR
INFORMATION
assigned to that agent from Interaction Administrator. If the required skills were not explicitly
assigned, ACD Server looks at the skills that the agent inherited from the workgroup on which the
call currently resides. ACD Server will not consider skills inherited from other workgroups. For
example, if an agent belongs to both the Sales and Marketing workgroups, and an ACD call comes in
to the Sales workgroup, agent skills inherited from the Marketing workgroup are not considered.
Inputs Pages Both Inputs pages are used to establish the skill Proficiency and Desire to Use levels,
that are required for the interaction, and the weights of skill Proficiency and Desire to Use in
calculating the skill score.
Call Identifier The variable for the interaction for which you want to specify a required skill.
Skill Name The skill name as specified in Interaction Administrator.
Minimum Proficiency Level The minimum proficiency level required for this skill. Agents who
do not possess this minimum skill proficiency will not be eligible to receive this interaction.
Maximum Proficiency Level The maximum proficiency level required for this skill. Agents who
exceed this maximum skill proficiency will not be eligible to receive this interaction.
Weight for Proficiency Level How important Proficiency level is for this skill, as opposed to
other skills specified in other ACD Specify Interaction Skill steps. If this skill is the only skill you
are specifying, then leave the default value in this parameter. If you are more concerned with
this skill, then weight this parameter more heavily than Weight for Proficiency Level in other
ACD Specify Interaction Skill steps in this handler.
5-19Customizing the System 2017, Interactive Intelligence, Inc.
Minimum Desire to Use Level The minimum Desire to Use level required for this skill. Agents
who do not meet the minimum Desire to Use level specified here will not be eligible to receive
this interaction.
Maximum Desire to Use Level The maximum Desire to Use level required for this skill.
Agents who exceed the maximum Desire to Use level specified here will not be eligible to
receive this interaction.
Weight for Desire to Use How important Desire to Use level for this skill is, as opposed to
other skills specified in other ACD Specify Interaction Skill steps. If this skill is the only skill you
are specifying, then leave the default value in this parameter. If you are more concerned with
this skill, then weight this parameter more heavily than Weight for Desire to Use in other ACD
Specify Interaction Skill steps in this handler.
Inputs Page The first Inputs page contains parameters which affect the Agent Score.
Call Identifier The identifier of the interaction on which ACD processing is performed.
Inputs Page The second Inputs page contains parameters which affect the Interaction Score.
Weight for Skills If you are concerned with matching calls to agents with the best skill for that call,
then increase the Weight for Skills more than the weights for Priority, or Time in Queue or System.
Weight for Priority If you want calls with the highest priority to be answered first, then
increase the Weight for Priority more than the weights for Skills, or Time in Queue or System.
Outputs Page:
Call Identifier The variable for the interaction flagged for ACD processing.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following lab in your lab manual:
Lab 21: Building a Custom ACD Queue
DATABASE TOOLS
The Database tools allow handlers and subroutines to read from and update databases. With
database tools, you can:
Look up customer account numbers and retrieve their balance and then play the balance back to
them using TTS.
Accept input from the Telephony User Interface (TUI) to update a field in a database table, such
as the date and time that they will arrive to pick up an order.
Look up a password that has been input from the TUI so that a caller can gain access to information.
Look up information to populate fields on a webpage with personalized information.
Update customer information based upon input from a webpage.
Perform many other database-related tasks.
Beyond these databases, Interactive Intelligence should be able to communicate with any ODBC-
compliant database through the Database Tools, but such a connection is not guaranteed, nor will
Support agents necessarily be able to troubleshoot problems connecting to other databases.
Always check testlab.inin.com for the latest information regarding supported databases.
FOR YOUR
INFORMATION
DB OPEN
The DB Open tool opens an ODBC data source and passes along parameters like username and
password needed to access the data source. This step is usually followed by a DB Get Connection step.
Settings Page:
Data Source Specifies the previously created ODBC data source through which you want to connect.
User Name Type the database username which has the permissions needed to open the database.
Password Type the password for the database user.
Database Variable Name This is the name (handle) for the database you are opening.
Maximum Database Connections The number of connections this handler will open. If you are
going to be requesting multiple results from the query, you can specify more connections. Multiple
connections allow you to query the database, leave the result on the server, perform another query,
and go back later to continue getting records. It is recommended that you leave this setting at 1.
5-27Customizing the System 2017, Interactive Intelligence, Inc.
Exit Paths:
Success If this step executes successfully, it takes the Success exit path.
Failure If this step does not execute successfully, it takes the Failure exit path. This can occur when
the ODBC data source is not valid, the user name or password are incorrect, the step times out
before the DB can be opened, or the DB server is not available.
DB GET CONNECTION
The DB Get Connection tool opens up a connection to a database specified in DB Open. If you are
planning to use a DB Query step to retrieve a result set, keep in mind that each connection can
only hold one result set. If you want to retrieve more than one result set, get a connection for each
result set you want to retrieve. See the DB Query step for more information on result sets. This step
should always be preceded by a DB Open step.
Settings Page:
Database Variable Specifies which database to open. For this parameter, enter the database
variable created in a DB Open step.
Database Connection Variable Names the database connection.
Timeout Specifies how long this step will wait for a connection with the server before exiting
Failure. The default for this value is 60 seconds. Entering a value less than or equal to 0 results in this
step using the default value of 60 seconds. This parameter takes a numeric value, so you can specify a
decimal, such as 2.5.
Exit Paths:
Success If this step executes successfully, it takes the Success exit path.
Failure If this step does not execute successfully, it step takes the Failure exit path. This can occur
when the DB variable or DB connection variable is not valid, if the step times out before the
connection could be performed, or the DB servers connection limit has been reached. Failures on
open and connect depend on the type of database (Oracle, Sybase, and so on).
5-28Customizing the System 2017, Interactive Intelligence, Inc.
DB QUERY
The DB Query tool retrieves a result set from a table based on a Where clause. The result set
retrieved matches the conditions specified in the Where clause. You can then specify a variable
(bind) for each row of data returned.
Following is one example of a where clause, and the DB Query step to execute that where clause
The Select statement used to retrieve the value is: SELECT ID, Cost FROM Clothing WHERE
Name=strAgent1.
DB FETCH
DB Fetch retrieves a record from a result set generated in a DB Query step.
The first time the DB Fetch step executes, it retrieves record with ID 123, and takes the success
exit path. You can then pull values from any variables bound to the column values, as specified in
the DB Query step. Then the handler would be designed to loop around and execute this DB Fetch
step again. DB Fetch automatically retrieves the value of the next record, number 124. Each time
the DB Fetch step executes, it retrieves the next value. When it reaches the empty record, the DB
Fetch step fails and the loop ends.
In this example, you could write each value to a list of string for insertion into a webpage or some
other operation.
Settings Page:
Database Connection Variable The name of a variable you created in a DB Get Connection step.
Exit Paths:
Success If this step executes successfully, it takes the Success exit path.
Failure If this step does not execute successfully, it takes the Failure exit path. This can occur when
the parameters set in the DB Query step were invalid, the DB Connection Variable is invalid, if the
step times out before the fetch could be performed, or if there are no more rows to fetch from the
result set. If there were no more rows to fetch from the result set, this means either a) the fetch
cycle is now complete, or b) there was no successful query performed before the fetch (this means
that for this step, the handler author cannot tell the difference between a true failure [like a lost
DB connection] and a simple you are at the end of the result set indication.)
DB RELEASE CONNECTION
DB Release Connection releases a connection to the database server, freeing up the server for
another connection. This step is usually followed by a DB Close step.
You may not want to follow this step with a DB Close in cases where you have opened multiple
connections to the same data source. This is useful in cases where you want to perform nested
queries against the database.
For instance, suppose you execute a query step, then fetch a record, and then perform an additional
query (based on some data in that fetched record) in order to process the record. If you perform
that second query on the same connection, your first result set will be lost (the server keeps one
current result set for each connection). So, you open another connection (or use another one that
was opened before) and perform the second query on that query. Then you fetch the result from
that second query and finish whatever processing you needed to do for the original record. Now you
can go back and fetch the second record from the first query. To process the second record you will
probably do the same thing you did for the firstdo another query and fetch, then finish processing.
Settings Page:
Database Variable Specifies the database variable for the connection to release.
Exit Paths:
Success If this step executes successfully, it takes the Success exit path.
Failure If this step does not execute successfully, it takes the Failure exit path. This can occur when
the DB Connection Variable is not valid.
Settings Page:
Database Variable Specifies which database variable to close.
Exit Paths:
Success If this step executes successfully, it takes the Success exit path.
Failure If this step does not execute successfully, it takes the Failure exit path. This can occur when
the Database Variable is invalid.
DB SQL EXEC
This tool is useful when you want to do something with a database other than query. DB SQL Exec can
be used to insert data into a database, update a row already in a database, delete data from a database,
or run a stored procedure on the server (scripts stored on the database that operate on the data
tables). You can use this tool to create a temporary table, then run a DB Query against that table to
return data, allowing you to work around the DB Query limitation of querying from a single table.
To use this tool, build a SQL statement using one or more Assignment steps, and pass it in as a string
variable. Use this string variable as your SQL Statement Variable on the Settings page. You can use
the & (string append) function in several Assignment steps to build complex SQL statements.
This tool allows for the execution of any SQL statement that does not return a result set. If used for
queries or stored procedure calls that return result sets, you will not be able to retrieve the results.
Use DB Query and DB Stored Procedure for stored procedure calls that return result sets instead of
this tool.
This tool will optionally allow for the retrieval of the number of affected rows (INSERTs, UPDATEs,
and DELETEs only).
Like the DB list tools, this tool will grab a connection from the cache (or create one if one is not
available), perform the operation, then release the connection back to the cache. In other words, it
is self-contained, which means you do not need to call DB Open & DB Get Connection prior to using
this tool. However, a Data Source must be created in Interaction Administrator.
Inputs Page:
IC Data Source The name of the IC (not ODBC) data source to use.
SQL Command The SQL command to execute.
Timeout (seconds) The time, in seconds, before this tool will return with a timeout error. Where
supported by the RDBMS, the statement/query timeout on the server will also be set with this value.
Failure There was a SQL or internal error generated while trying to execute this command. Check
the IPDBServer.log for information on the error.
STORED PROCEDURES
With the database tools that we have discussed so far, a handler can query a single database table,
update or write a record to a table, or delete a record from a table. To perform more advanced
database functions in handlers, such as joins, table creation, use stored procedures.
A stored procedure is a function or script that is saved on a database server. This script can be
executed on the database server at the request of a database client. Stored procedures can receive
input from the client at the time they are executed. Stored procedures carry out their processing
on the server and can return data/results of that processing to the client. Database administrators
use stored procedures to carry out complex functions that are best performed on the server (as
opposed to the client). In addition, stored procedures often outperform normally submitted SQL
because the SQL in the procedure is pre-parsed, and execution plans pre-generated.
A definition of a stored procedure specifies parameters, the result set, and the return value.
A stored procedure parameter is similar to the standard programming concept of a function
parameter. These parameters can be input data, meaning the value passed in is used during
processing. They can also be output data, meaning the reference to a value will be filled in during
processing. They can also be both, meaning their initial value will be used during processing, and
that value may then be changed before processing completes.
The creation of stored procedures is a role of the Database Administrator and is beyond the scope
FOR YOUR
INFORMATION
of this class.
In Interaction Designer, under the Utilities menu, is a menu option for Stored Procedures. Selecting
the Stored Procedures options opens the DB Stored Procedures Definitions dialog that displays and
allows you to edit the definition of a stored procedure. This is either the definition as passed in by
the ODBC driver, or the definition that you have modified previously in this dialog box.
Use this dialog to augment a stored procedure definition if the ODBC driver did not pass in a
complete definition. ODBC drivers differ in the amount of information that they pass to Interaction
Designer. Some will pass all input and output parameters, some will not. Use this dialog if you realize
that your ODBC driver is passing an incomplete definition.
Consult with your database administrator to determine the behavior of your particular database server.
Parameters tab:
DB Connection The variable containing the database connection generated by the DB Get
Connection tool.
DSN (Catalog =) The name of the data source on which the procedure was created. The concept of the
catalog varies from one RDBMS vendor to the next. It usually corresponds to the physical database,
but there are exceptions. For example, with dBase and FoxPro it usually corresponds to the directory
in which the data files reside. IC assumes that the catalog is tied to the ODBC DSN. If access to multiple
catalogs is required, create and configure multiple ODBC DSNs.
Schema The schema in which the stored procedure resides. The schema is the official ANSI term
for what used to be commonly known as the qualifier. It is usually the creator/owner of the database
object. Worth noting is that Sybase and Microsoft SQL Server have a special schema name that is
used when the owner of the object is also the database owner: dbo.
Stored Procedure The name of the stored procedure as it is stored on the DB server.
You cannot change the actual name as it is defined on the DB server from this field.
FOR YOUR
INFORMATION
Runtime Stored Procedure An optional expression that results in a string that names a stored
procedure. This allows you to run a stored procedure dynamically from a handler. If you specify a
value here, the value in the Stored Procedure parameter is ignored.
This list is populated if the stored procedure fetches any data. You can bind variables to the fetched
data. If you do not see all of the column names that should be listed, the ODBC driver may not be
passing all of the column names to this tool. In this case, you may need to define these column names
and other result set properties in the DB Stored Procedure Definition dialog (which you can open
through the Utilities menu).
IC does not currently support retrieving multiple result sets. If the stored procedure generates
CAUTION
multiple result sets, then only the first result set can be retrieved.
Name The name of the column from which the data is fetched.
Position The ordinal position of the column in the result set, starting from 1.
Expression The variable to which the fetched data is bound. You can specify only a variable, not
an expression.
Bind Click the Bind button to bind the selected column to a variable.
Unbind Click the Unbind button to unbind a variable from a column.
Clear Bindings Click Clear Bindings to remove all bindings to all columns.
Exit Paths:
Success This step takes the Success exit path if the stored procedure is executed.
Failure This step takes the Failure exit path if it is not able to run the stored procedure. Probable
causes include:
Stored procedure not found. Usually this is due to a wrong or missing schema qualifier, or
insufficient permissions.
Insufficient execution permissions.
Data type mismatch with one of the procedure parameters or return value.
The best way to troubleshoot the cause of a failure is to examine the IPDBServer.ininlog fileit will
typically contain a useful RDBMS error message.
Labs
Complete the following lab in your lab manual:
Lab 22: Communicating with a Database
You can have prompts professionally recorded and import them into the appropriate prompt
library, or you can record them using a high-quality noise-canceling headset attached to IC. Before
recording, verify that the prompts will be saved in the correct format by opening the recording
software, such as Microsoft Sound Recorder, and checking the properties. Set prompts to CCITT
u-law, 8-kHz, 8-bit, mono.
Follow these steps to record a new prompt:
Open the prompt handler in which the new prompt will be stored.
Open the Play Prompt step.
Click the Edit button on the Inputs page of the Play Prompt step. This opens the Prompt Editor.
The Trim Leading Silence check box allows you to remove any silent moments at the beginning of a
new prompt. When you click the Stop button to end recording of a new prompt, the trim is applied.
You cannot trim silence from a prompt created in a previous recording session. The Trim Trailing
Silence option performs the same function at the end of a new prompt.
The prompt and its duration are displayed in the Prompt Name list. The Prompt is played back
automatically when the recording is finished.
Because there is no select button in the Prompt Editor, the prompt that is selected when you click
click OK is the prompt that appears on the Inputs page.
If the audio quality is inferior, check the Multimedia properties in Control Panel to make sure the
FOR YOUR
INFORMATION
Microsoft CCITT G.711 Audio codec is installed.
An alternative way to record prompts is to record the prompt in Interaction Attendant or to set your
status to an unavailable status and record the prompt as a voice mail. The .wav file that is produced
will be in the proper format and can then be imported into your prompt libraries. We will be using
this method in an upcoming lab.
The Assemble Prompt Phrase tool is used to define a sequence of prompt strings that will form the
structure of a single prompt. The sequence can consist of string variables or literals that can be read
using Text-to-Speech (TTS), text files, and existing prompts.
The Assemble Prompt Phrase tool only builds prompt phrasesit does not play them. The Play
FOR YOUR
INFORMATION
Prompt Phrase tool is used to play prompts.
For example, the phrase used in the default Dial-by-Name functionality that states, Please enter the
first four characters of your partys last name is made up of three strings: A prompt that says, Please
enter the first, a string variable which value is determined by a setting in Interaction Attendant, and a
prompt that says, characters of your partys last name.
The following shows the tabs for the Assemble Prompt Phrase step that is used to build the phrase.
General Contains the Label and Notes for the step. It is a good idea to enter the string that is being
assembled by this step into the notes field.
Call Identifier The identifier for the call on which the prompt phrase is assembled. The tool
uses the identifier to ascertain the language of the call.
Language The language code of the prompt phrase to be played. If no language is specified,
the language attribute of the call will be used. If no language is specified for the call either, the
default language will be used.
Singular if true This Boolean value permits simple handler-based control over the common
case of generating different prompt sequences for plural arguments than for singular ones
(for example, one car vs. two cars). Set to true to play the Single Sequence as defined in the
Sequence Strings tab. Set to false to select the Plural Sequence.
Prompt Strings This page allows the specification of zero or more Prompt Strings that can be
substituted dynamically into the phrase. Typically, the entries on this page are string literals
or the names of string variables. A Prompt String consists of one or more prompt identifiers
separated by white space. A prompt identifier can be scoped or unscoped by a handler name.
A scoped prompt identifier consists of the handler name, a colon, and the prompt ID (e.g.,
<HandlerName:PromptName>). All identifiers are case insensitive.
Variables A list of string type variables that are in the current handler. To assign a string to a
parameter, it must first be defined in the handler.
Parameters The substitution strings that are passed in at run-time to the sequence string.
The parameters are referenced as %1, %2, and so on in the sequence string, according to their
position in this list.
Prompt This read-only text box displays a prompt that has been selected using Pick Prompt,
but has not been assigned to a Parameter number.
Pick Prompt Opens the Prompt Editor for the selection of a prompt. After the prompt has
been selected, it will appear in the Prompt read-only text box. Pressing the >> button will add
the prompt to the Parameters list.
If you delete, edit, or insert a sequence string for a handler other than the current handler, save and
FOR YOUR
INFORMATION
publish that handler, too. When you attempt to publish the current handler, you will receive the
following window as a reminder:
In this example, DialByName04 is the Sequence String ID of the selected sequence. The same
sequence is entered into the Single Sequence and Plural Sequence fields because, in this case, there
is no plural to consider. The sequence for this example is:
<Prompt_Attendant:DialByName_PLEASE_ENTER_FIRST><%1><Prompt_Atten
dant:DialByName_CHARS_NAME_LAST>
This will result in the following prompt:
The prompt named DialByName_PLEASE_ENTER_FIRST from the Prompt_Attendant handler:
Please enter the first
The value of sCharacterPhrase which is the substitution string for %1:
3
The prompt named DialByName_CHARS_NAME_LAST from the Prompt_Attendant handler:
characters of your partys last name.
The Assemble Text Phrase tool is very much like the Assemble Prompt Phrase tool. It is used to build
FOR YOUR
INFORMATION
string sequences that will either be written to a log, email, or text media; or read using TTS. The Play
Prompt Phrase tool is used to have TTS read a Text Phrase.
To play prompts or to have TTS read text strings in handlers, use the Play Prompt Phrase tool. This
tool allows you to define a sequence of strings that define the structure of a prompt that you want
to play and then substitute values at run-time to play the actual prompt. This eliminates the need to
use multiple Play Prompt tools in order to play a sequence of prompts.
The Play Prompt Phrase tool has many of the same properties as the Assemble Prompt Phrase tool.
Input The Input tab, for Play Prompt Phrase, is similar to the Input tab for the Assemble Prompt
Phrase tool. However, there is an additional property that identifies the call to which the prompt will
be played.
Call Identifier The unique identifier for the interaction. This defaults to Interaction1.
In this example, the value of the sMenuPhrase variable will be substituted for <%1> in the sequence
string. This will play a phrase that has been put together in a previous Assemble Prompt Phrase step.
In this example, DialByName10 is the Sequence String ID of the selected sequence. The same
sequence is entered into the Single Sequence and Plural Sequence fields because, in this case, there
is no plural to consider. The sequence for this example is:
<%1><Prompt_Attendant:DialByName_RETURN_PREVIOUS_MENU>
This will result in the following prompt:The value of sMenuPhrase which is the substitution string
for %1. This phrase is built by several Assemble Prompt Phrase steps throughout this particular
handler. The final value of sMenuPhrase will depend upon settings in the Dial By Name operator in
Interaction Attendant. In the default system, the value of sMenuPhrase will be:
Please enter the first three characters of your partys last name. Use 7 for Q and 9 for Z. For
an operator, press zero. To hear the company directory, press the pound key (#).
The prompt named DialByName_RETURN_PREVIOUS_MENU from the Prompt_Attendant handler:
To return to the previous menu, press the star key.
LOCALIZING PROMPTS
Localizing IC for more languages is best achieved by applying a Localization Pack, if available, from
Interactive Intelligence.
Labs
Complete the following labs in your lab manual:
Lab 23: Create a Prompt
Lab 24: Using Tools Help
Lab 25: Working with Object Attributes
Lab 26: Using Custom Object Attributes
Lab 27: Using Custom DS Attributes
Lab 28: Looking Up Information in a Table
Troubleshooting
Troubleshooting
6
www.inin.com/education 2017, Interactive Intelligence, Inc.
6.1 Troubleshooting
TROUBLESHOOTING STEPS
There are times when a handler will not behave in the way that you expect it to behave, especially
if it is a new or modified handler. At these times, it is necessary to troubleshoot the handler. There
are many reasons why a handler does not perform as expected. For example, a variable value not
set properly, the logic of the handler is incorrect, or there is an infinite loop in the handler. (Because
infinite loops are so troublesome, we will address infinite loops in more detail in the next section.)
Debug The first step in troubleshooting a handler is to put the handler in debug mode and follow it
through its steps, viewing variable values as needed. Usually, running a handler in debug mode is all
that is required to pinpoint any logic errors in a handler.
IP Tracing Tools Occasionally, a handler will work as expected when debugged, but will fail when
running in normal mode. A more complex method of troubleshooting is to turn on IP tools tracing and
duplicate the problem. This procedure is discussed in the IP.ininlog section of this module.
INFINITE LOOPS
An infinite loop is caused when you attach an exit path from a step back to a previous step in a handler,
and nothing occurs in between that causes the flow to stop or a different exit path to be taken.
HANDLER CONFIGURATION
A handlers step limit, priority, and maximum number of concurrent handlers can be set in the Handlers
Configuration dialog of the Handlers container in Interaction Administrator.
IP MANAGER
The IP Manager dialog can be useful when trying to identify potential problems with handlers
running on the IC server. The Current Activity page shows specific information about handlers that
are currently running on the system.
The IP Manager dialog is available in the Interaction Processor or Handlers container. Right-click in
the data view or select IP Manager from the shortcut menu.
5. You can change the Topic Level in three different ways: with the radio buttons, the slide bar, or by
typing a number directly into the numeric edit box.
By increasing the trace level for the IP log (and especially the Tools topic), you will be able to use the
log file to see every step processed by the handler, the parameter values for the step, and so on.
THE IP LOG
The Log Viewer Utility must be used to read IC log files. The default location of the IC log files
including the IP log is: \13\IC\Logs.
The IP log is used mainly for troubleshooting handler problems. To trace a call through the IP log,
you must have the Call ID.
The best way to walk through an IP log to troubleshoot a handler is to have a copy of the handler
available along with the IP log.
3. Select the date folder that contains the logs you want to view.
4. From the list of files, select the log of the subsystem that you want to view, then click Open.
5. The appropriate log opens.
The Log Viewer Utility Menu The Log Viewer Utility menu allows you to control the Log Viewer
Utility console. A toolbar on the console allows you to perform many of the Log Viewer Utility
functions by clicking the appropriate icons.
6-08Troubleshooting 2017, Interactive Intelligence, Inc.
File The File menu allows you to open, reopen, or close log files. You can also export open logs
from the File menu in to ASCII format. This will allow the logs to be read in a standard text editor,
such as Microsoft Notepad or WordPad. By default, log files are stored in a binary format that
cannot be read without the Log Viewer utility.
View The View menu allows you to set how you view the open log(s) and message(s). You can
select a message in a log and then open that specific message by selecting the Show Message
Detail Window option. The message will open in a separate window.
Filter The Filter menu allows you to filter the open log to view specific message types or
threads. This will often only be necessary when troubleshooting a problem, as instructed by
Interactive Support. You can filter by topic, context, or thread ID, or set a filter based on a search
string which you enter. You can also remove all current filters to return to the default view.
Search The Search menu allows you to search for a specific message or to jump to a specific
time stamp in the log.
Log files for days before the current day are automatically zipped by the IC system. To view these
FOR YOUR
INFORMATION
logs, they must first be extracted from the zip file.
Large logs and complex filters can affect system performance. If a log file is large, it is recommended
CAUTION
that the log be snipped using Logsnipper before opening it in Log Viewer Utility.
Customers can push data to a support site without waiting for a support representative to make a
request. Customers can also choose to use the push feature to retain control of what logs are made
available outside their organization.
TROUBLESHOOTING TIPS
Use a Log Event step after a Failure path Add log event steps after most failure paths in order to
log the error to the Event log. Errors logged this way are much easier to find than consulting trace
logs. Use the Error log type sparingly. Use the Warning type instead unless the error is serious.
Use built-in constants to identify the handler name in the text of every Log Event step. Also
use constants to identify the previous step number that triggered the log event. Include a brief
description of the possible problem. Some telephony tools will follow the failure path even when
no real failure occurred. The Extended Get Key, for instance, will take the failure path if the caller
hangs up or is disconnected while the Get Key is playing prompts or waiting for input.
Use Informational log events to troubleshoot or verify handler functionality Informational
Event log messages can be created in a handler using the Log Event tool. Use them to verify
important steps in a handler or track major changes or unique events in a handler. They can also be
used to troubleshoot handlers by identifying failure paths or other unwanted behaviors. Use this
method rather than debugging handlers or consulting trace logs. Create an Assignment step with
the handler name to find errors in the Event logs easily.
Set break point in debug to skip over sections You can turn any step into a breakpoint after a
handler is already in debug mode. Your handler must already be in debug mode to set a breakpoint:
Right-click on the step you want to set as a breakpoint.
Choose Set Breakpoint from the menu that appears. The step color changes to red. When the
debug handler runs, it will automatically stop at this step.
Debug using custom notification Trigger your subroutine handler for debugging using a Send
Custom Notification command. Create a separate handler that has the Custom Notification initiator
followed by your subroutine.
Review Questions
Complete the review questions for this module in your study guide.
Labs
Complete the following labs in your lab manual:
Lab 29: View the IP Log
Lab 30: Using Custom Notification
Lab 31: Skills Evaluation
Lab 32: Using Constants (Optional)
Handler Tools
A
www.inin.com/education 2017, Interactive Intelligence, Inc.
A.1 Handler Tools
ACD TOOLS
The ACD tools are used to implement Automatic Communication Distribution (ACD) in IC. These
tools were discussed in a previous chapter.
ACCUMULATOR TOOLS
Accumulators are generic, on-the-fly global variables. The accumulator tools on the tool palette
allow the user to create and modify the way accumulators behave and the types of information they
accumulate. Accumulators provide a place to store an attribute. For example, accumulators provide
a way for someone to gather (accumulate) a total number of calls. Accumulators are defined in the
Interaction Administrator, and Interaction Designer users can decide when they want to gather the
information that is stored in the accumulators.
While accumulators are defined in Interaction Administrator, the accumulator tools create
instances of accumulators and modify the value of those instances.
BASIC TOOLS
The Basic tools are versatile tools that provide common programming functionality to the handlers.
They are used to create variables, assign values to variables, and evaluate the values of variables.
The Write Trace Message tool is used to write a message to the IP.ininlog file.
Table Lookup Tool The Table Lookup tool retrieves data from a table created in the Tables
container of Interaction Administrator (a subcontainer of the Interaction Processor container under
System Configuration).
This tool allows you to query specific columns within the table for specific values, and then return
corresponding values from the same row. Returned values must be bound to a variable to be used
within the handler.
CALENDAR TOOLS
The Calendar Tools can be used in a handler to place, retrieve, or edit data on a calendar server.
Presently, IC only supports the iPlanet, Microsoft Exchange, and Outlook calendar servers. This
release only supports Events, and only the Start Time, End Time, Location, Description, and
Summary Properties. Other calendars and features will be added in future releases.
The IC calendaring system is set up automatically when IC is installed to coincide with the mail
server that is selected during setup.
The Database tools allow handlers and subroutines to read from and update databases. Database
tools have many uses because they allow you to read from and write to a database outside the IC
server. While their uses are virtually unlimited, some uses are looking up passwords and retrieving
information to display in webpages.
DIRECTOR TOOLS
In Interaction Designer, tools for developing handlers with Interaction Director functionality appear
on a design palette tab named Director. Unless Interaction Director is installed, the palette will be
empty except for the Play Audio File (No Conference) tool, and that tool should not be used on a
non-Director system.
The Email tools are for sending, transferring, disconnecting, and otherwise manipulating emails and
email objects in Microsoft Exchange, Lotus Notes/Domino, or other supported email server.
Many of these tools can be used with email Server Parameters. For more information on email
Server Parameters, see Server Parameters in the Interaction Administrator Help.
The email Server Parameters that can be created are:
Save Sent Mail
Monitored Mailbox
Mail CPR Interval
Mail Temp Directory
Mail Archive Directory
The email tools cannot access folders located on users local machines. In order for the Open Folder
FOR YOUR
INFORMATION
tool to work, the folder being accessed must reside on the mail server. In other words, if you plan to
allow users to access their voice mail messages remotely (over the telephone), then users must have
their email delivered to their mailbox on the Exchange or Domino server.
FAX TOOLS
A fax page list defines what will be faxed. The first step in any handler that sends a fax is the Create
Fax Page list tool. This tool specifies the Interaction Fax file or bitmap, and the pages within that file
to send.
2. Append Pages to the Fax Page List (optional)
You may need to use one or more Append Pages steps to add more pages to the fax. Append Pages
lets you create a fax from more than one file. This is useful if you want users to be able to request
multiple documents in a single phone call.
3. Create the Fax Object
Once you have compiled the fax page list, use a Create Fax tool to convert the list to a fax object that
can be processed by Fax Services.
Once you have a fax object, you can create a fax envelope, print the fax, or email the fax. Creating a
fax envelope is just specifying information about how the fax should be sent, such as the recipient
phone number, information that goes on the cover page, the time to send the fax, and an email
address to notify if the fax is sent or if the fax send fails. Fax envelopes are created using the Create
Envelope tool. You can also print the fax to a local or network printer using the Print Fax tool.
Finally, if you want to send the fax as an attachment to an email message, you can use the Send Fax
tool which is found under the Email Tools. You do not need to create an envelope if you are printing
or emailing the fax object.
5. Queue the Fax for Sending
If you want to send the fax via Fax Services, and you have created the fax envelope described in
step 4, you can queue the fax for sending with the Queue Fax For Send tool. This tells Fax Services
to send the fax using the information specified in the fax envelope. Once a fax has been sent, Fax
Services generates an Export Fax File event. This event starts the Fax Send Completed initiator.
Some File I/O tools create, read, and write to text files. For example, some non- Interaction
Center software can use or output text files. The text files created, read, or written to, can be
Whether you are connecting to a remote computer or the remote computer is connecting to
Interaction Center, first establish a connection. When you establish the connection, the resulting
connection handle is used by the read and write tools to communicate with the remote computer.
If you are connecting to a remote computer, use the Tcp Connect tool. If the remote computer is
connecting to Interaction Center, use the Tcp Listen tool to monitor a port.
When the remote computer makes a connection, the Tcp Listen tool generates an event that starts
the Tcp Connection Accepted initiator. This initiator generates the connection handle.
2. Send and Receive Strings and Integers
Once the connection handle is established, the Tcp Read String and Tcp Read Integer tools can take
data sent by the remote computer and place it in a variable to use within the handler. Tcp Write
String and Tcp Write Integer can send data to the remote computer.
3. Closing the Connection
When the handler has finished sending and receiving data, we recommend that you close the
connection with the remote computer. The Tcp Close tool closes the connection stored in the
connection handle.
The Generic Objects tools are for creating, transferring, disconnecting, and otherwise
manipulating objects.
Generic objects are used for routing additional interactions, such as a third-party chat, a video,
or a workflow document to agents in workgroups. These generic objects function like other
interactions within Interaction Desktop.
A generic object appears in the My Interactions tab in an agents workgroup queue in Interaction
Desktop, just like other interactions. When the agent clicks it, the application or document
pops open in Interaction Desktop. It can be transferred, disconnected, and so on just like other
interactions.
Interaction Center has several tools that allow Interaction Center to communicate with
mainframes via the TN 3270(E) and TN 5250 protocols. The Host Server, an Interaction Center
Server subsystem, can log on to and perform operations through a terminal emulation. A handler
containing the Host tools can tell the Host Server to start a Telnet session with a mainframe (or
AS400) and pass information via screen scrapes. This is similar to performing a database put or get,
but the operation is performed through a mainframe terminal emulation running on the Host server.
Screen scraping is the process by which information is read from or to the fields in a terminal emulation.
This process does not introduce any security risks because the Host Server logs on just like any other
A-11Appendix A 2017, Interactive Intelligence, Inc.
terminal emulation user, allowing mainframe administrators to use existing security precautions.
Before you begin using Host tools and Host Server, purchase a license from your reseller or
FOR YOUR
INFORMATION
Interactive Intelligence. With the license, you will receive a key. Once you have entered the key and
the number of simultaneous connections granted with the license, you can begin to use the host
tools. These settings are configured in Interaction Administrator System Configuration Container.
The Host tools will not work without a license key.
ICON TOOLS
ICon tools contain tools for building handlers that interact with Interaction Conference.
INTERNET TOOLS
Internet tools are for building handlers that interact with people over the Internet. These interactions
can be through a web browser or through Internet chat. Using these tools, Interaction Center can
generate custom webpages and pop-up chat applets for a person browsing your website, format
appropriate URLs, and connect an agent to a party that requested a callback from your website.
The IpNotes tool set allows the handler author to store and retrieve named entities consisting of an
arbitrary number of named attributes of any of the ID-defined types Integer, String, or Date/Time.
Each attribute is a list of values of a particular type. An IpNote is available to all handlers on a given
server and accessed by name. IpNotes can be removed from memory explicitly, or can be set to
terminate automatically after a time interval specified at creation.
While IpNotes were designed for use with multi-site, many handler authors use IpNotes as a
substitute for global variables. The advantage of IpNotes over global variables is that global
variables lock the handler in which they are being used and IpNotes do not.
LDAP TOOLS
Login The Login tool logs a user into an LDAP server. The Login step must execute once in the
handler before other LDAP tools are executed. You must specify a Login ID and Password. The other
LDAP tools will have permissions based on that users permissions. For example, if the tool logs in as
administrator, the handler might have read/write access to the entire DIT. An individual user login
might grant access to only that users entry.
List tools access and sometimes modify the contents of a list variable. List variables are like regular
variables, except that they can hold more than one value. For example, a variable of type ListofString
can contain two or more string values. List variables are created using the InsertAtHead and
InsertAtTail tools.
List variables allow you to hold multiple values of a specific type. For example, a List variable of a
string type could contain many string values. A list variable can be declared for each of the following
data types: String, Integer, Boolean, Database, DateTime, DBConnection, and Numeric. There is no
limit to the number of elements in a list.
Each element in a list variable is assigned a place number. The first place number is always zero, the
second is one, the third is two, and so on. The first element in a list is called a Head. Therefore, the
Head of a list is always at place number 0. The end of a list is called a Tail. The place number for a tail
is always the number of the last element in a list. Therefore, the place number of the tail can change
as elements are added or removed from a list.
You might want to use a list variable to store multiple items retrieved from multiple fetches to
a database. For example, if you have a handler that allows callers to retrieve information on all
financial transactions that have occurred for a specific account over the past five days, you could
have a step that fetches information on all transactions and stores them in a list variable.
List variables can be created for the following data types:
Accumulator Lock Key
Boolean
Call Id
Conference Id
Database
Date Time
DB Connection
Diagnostic Data
Fax Envelope Ids
Fax File Ids
Fax Object Ids
Fax Page List Ids
File Handle
Host Interface Connections
A-16Appendix A 2017, Interactive Intelligence, Inc.
Integer
Mail Folder
MQConnection
MQObject
Numeric
Prompt
Recording
Queue Period Statistics
Recording Id
Socket Handle
String
Web Connection
MONITORING TOOLS
Monitoring tools enable a handler to obtain information about a subsystem such as its CPU usage,
memory usage, thread count, or how long it has been running and use that information to build
an event log message. There are also Monitoring tools allowing a handler to restart or stop an IC
subsystem.
Monitoring tools were developed for internal testing purposes. Most customer sites would not
need to use these tools since Remoco provides most of this functionality.
Multi-Site tools are similar to IpNotes tools and UMF tools. They provide functionality for
developing handlers that work with multi-site.
OCR TOOLS
The OCR tools are an extra set of tools that ship with the IC OCR. These tools provide some of the OCR
functionality in IC, although you must also install OCR and Export Server before OCR will work correctly.
Personal Rules are settings inside your Interaction Desktop which allow you to automatically
manage interactions. For example, Rules enable you to route certain specified interactions directly
to voice mail at certain times of the day. There are many other possible Rules that a user can create
in Interaction Desktop.
With these handler tools, you can extend the Rule functionality to other events generated by IC.
The Rules create a list of actions. You can then look up any action on the list and get its parameters.
The Process Automation tools enable handlers to interact with the Interaction Process
Automation application.
The Reco tools support the use of speech recognition in handlers. Many of these tools provide
similar functionality as telephony tools. For example, the Reco Basic Input is similar to Extended Get
Key, except that it will recognize voice input and DTMF input.
REPORTS TOOLS
Every 30 minutes (or at some other interval you specify in Interaction Administrator), Queue
Manager generates statistical information about the activity of each queue. This information
includes the number of items that were in the queue and other statistical information about those
items. For reporting purposes, the statistical information can be generated in several ways:
First, Queue Manager always generates statistical information for specified queues for every item.
Second, you can designate certain items as belonging to Stats Groups. Stats groups can contain
items that can be dispersed among different queues. At the designated interval when other
statistics are generated, Queue Manager will generate statistics for Stats Groups, even if those
items reside on different queues. Stats Groups are a way for you to monitor a group of calls or
other items despite their location within the system.
Third, you can designate certain items as belonging to a Report Group. Report Groups are useful
for reporting on a subset of the calls within the queue or Stats Group. When Queue Manager
generates statistics for a queue, it additionally generates statistics for all the items belonging to
a Report Group. An item can belong to only one Report Group.
Short Message Services (SMS) tools allow users to exchange text messages over cell phones.
To make use of SMS Support, you will need to connect with an SMS Broker. An SMS Broker is a
company that takes care of routing the SMS Messages to cell phones and collects SMS Messages
from cell phones.
SOAP TOOLS
SOAP (Simple Object Access Protocol) is a lightweight XML-based messaging protocol used to
encode the information in Web service request and response messages before sending them
over a network. SOAP messages are independent of any operating system or protocol and can be
transported using various Internet protocols, including SMTP, MIME, and HTTP.
SOAP tools provide a means for a handler to call a web server, request information, and have the
information returned to the handler.
You might create a handler that has a Timer Initiator that accesses a web server that provides stock
EXAMPLE
quotes. Every 20 minutes, while the market is open, the handler would request stock quotes and
write them to a file.
There are many publicly available web services. www.xmethods.net lists many of these free
FOR YOUR
INFORMATION
web services.
These tools are used by Interaction Attendant to retrieve schedules that were created in Interaction
Administrator or Interaction Attendant. While it is possible these tools be used in other handlers,
the handler author should have a solid understanding of IC IVR handlers, call flow, retrieving
Directory Services (DS) attributes, and branching based on the values of DS attributes. These tools
are currently used out-of-the-box in the Interaction Attendant handlers. They can be used outside
Interaction Attendant in a future release.
STATALERTSERVER TOOLS
The System tools perform various functions. Among other things, the System tools allow you to
create handlers that look up, create entries, and update entries in the Interaction Center Directory
Services. Some of these tools allow you to gather diagnostic information, pause the handler, perform
certain call transfers, and so on.
TUI TOOLS
Note that Attendant Email Logical Transfer, TUI Get Catch, TUI Menu Attributes, and TUI Session
are for internal Interactive Intelligence use only.
The Telephony tools perform various call-related functions within Interaction Center, such as client
functionality like Pickup, Mute, Disconnect, Conference, and so on; getting and setting interaction
attributes, playing prompts and strings, recording calls, querying queues, and much more.
When using the Extended Get Key tool step to gather digits, it will log all of the captured digits in
CAUTION
plain text to the TsServer and IP subsystem trace logs. If you are gathering sensitive information,
such as credit card numbers, account Personal Identification Numbers (PINs), or Social Security
Numbers (SSNs), set Suppress logging of the input digits to true on the third Inputs tab of the
Extended Get Key tool step:
The Universal Messaging Facility provides a number of tools that a handler author can use to
construct arbitrarily complex messages and send them to other handlers published on the same
server. The sending of a message triggers one or more initiators. The initiators have inputs that
allow the author to specify which handlers will trigger based on data contained in each message.
The originating handler can create a message and add elements of various types. Then it can choose
to send the message as an event (asynchronously) to which it expects no reply or as a request
(synchronously). When a message is sent as a request, the tool step in the originating handler waits
for a message to be returned before continuing.
The receiving handler uses the tools that get data elements from the message. The receiving handler
can in turn use the message construction tools to create and send a message to yet another handler
or to send a response back to the original handler if appropriate.
This subsystem depends on some basic Interactive Intelligence components and on Microsofts
FOR YOUR
INFORMATION
MFC libraries. These items must be present in executable form at runtime, and represented by .lib
and .h files at compile time.
Web Interaction Tools are for working with ACD Interactions that originate from a web interface.
Much of the functionality provided by these tools mirror functionality provided by similar Telephony
tools used for calls. For example, Alert Interaction is similar to Alert, except that it is used with web
interactions instead of phone calls.
WEBSPHERE MQ TOOLS
XML TOOLS
XML tools can be used to create, manipulate, and use XML documents in handlers. XML tools can
be used to simulate a data structure in handlers. An XML document can be passed as a parameter of
XMLNode data type, among subroutines.
You can create an XML document that contains all of the attributes that you want to associate with
EXAMPLE
an interaction. Then, rather than using many attribute lookups you can refer to the XML document.
You can configure which tool categories appear in the tools page of the design palette by modifying
FOR YOUR
INFORMATION
the I3\IC\Server\DesignerRegisteredTools.lst files. This ASCII file contains a list of the DLLs that
populate the tools page of the design palette. Placing a # in front of a DLL will comment out that
line, preventing that category of tools from appearing in the palette. When Interaction Designer is
started, it first looks in the directory from which it was started for the DesignerRegisteredTools.lst
file. If it does not find it there, it checks the system path. The first DesignerRegisteredTools.lst file
found is the one that will be used.
The Interaction Center platform captures and processes every communication event, like: a user
lifting a telephone handset, a call coming in, a fax going out, an on-line customer clicking a button on
a web page, a new email, a call transferred from one extension to another, and so on.
Interaction Center is implemented as a distributed client-server application. The server portion, called
the Interaction Server, runs on a Windows 2008 Server. The Interaction Server serves as an interaction
processor, offering a digital PBX, ACD, IVR, email, voice mail, and fax processor, and dozens of other
coordinated roles that can be administered via a single interface, the Interaction Administrator.
Interaction Center has a modular software design that logically separates each communication
element from the other communications components. By taking this approach, if one part of the
product becomes fractured for some reason, the others will still function. Also, when one part
of the product is in need of updating, just the parts associated with it are updated. Therefore, the
entire system does not need to be upgraded.
SUBSYSTEM OVERVIEW
Before discussing handlers and objects, it is important to understand the underlying components
of the Interaction Center platform. The IC platform is a distributed client-server application. Many
subsystems provide one or more coordinating services to the other IC server subsystems. Each IC
subsystem provides specific functionality on the IC server.
Notifier subsystem Acts as the switchboard-hub through which the other IC subsystems
communicate with each other.
Directory Services (DS) subsystem Stores user, workgroup, line, and other configuration
information. The Interaction Administrator usually puts the configuration information into DS.
Web Services subsystem Provides Internet and chat functionality.
Automated Communication Distribution (ACD) server subsystem Performs the calculations
necessary for intelligently routing interaction to available and appropriate agents.
Review Questions
Complete the review questions for this module in your study guide.
Labs
There are no labs associated with this module.
HANDLER TERMS
Creating and modifying handlers requires that you think logically about the task at hand to develop a
handler program to perform that task. In other words, you will be programming.
In this section we are going to discuss the terms that we will use when defining, creating, and
manipulating handlers. It is important that we discuss these terms even if you have been developing
programs for many years. Some terms differ from one programming platform to another.
In this section, we will define the terms as they apply to the Interactive Intelligence development
environmentInteraction Designer.
LOGIC
Logic is the sequence of instructions in a handler. It is a set of ordered steps for solving a problem. To
work properly, these steps require unambiguous rules that have a clear stopping point.
DATA TYPES
Input and output parameters expect a specific type of data. The value and data type of a variable
must match to ensure data integrity. A parameter that expects a value of an integer cannot accept
a string. A parameter that expects a value of string cannot accept a Boolean expression (true or
false). If you try to assign the wrong type of value to a parameter, you will receive an error message
indicating that the expression is incomplete.
Data types can be categorized in two groups:
Normal
Extended
VARIABLES
A variable is a symbol or name that stands for a value. You can think of a variable as a container
that holds a value which can vary. For example, in the expression x+y, x and y are variables. The
value of x and y could be anything, such as 4 and 5, or 3.14 and 5.667.
Variables can represent numeric values, characters, or character strings. Variables play an important
role in computer programming because they enable programmers to write flexible programs. Rather
than entering data directly into a program, a programmer can use variables to represent the data.
Then, when the program is executed, the variables are replaced with real data. This makes it possible
for the same program to process different sets of data.
A variable is made up of three parts:
Name A label for the variable. You use the variable name to make reference to it.
Value A specific piece of data that matches the variables data type.
Data type This indicates what type of value a variable holds, such as an integer, a numeric, a
character, and so on The value of the variable must match this data type.
Literal Value A literal value is written exactly as it is meant to be interpreted. A literal value can be
a number, character, or a string.
x=7
EXAMPLE
(x is a variable, 7 is a literal)
In the above example, x can be evaluated as any number. It is a variable, but 7 can only be
evaluated as the number 7.
EXPRESSIONS
An expression is any legal combination of symbols that represents a value. Every expression consists
of at least one operand and can have one or more operators. Operands are values and operators are
symbols that represent actions.
x+5
EXAMPLE
CONSTANTS
Constants are similar to variables in that they also store values. However, as the name implies, the
value of a constant will not change throughout the execution of an application. There are several
built-in constants in Interaction Designer that can be used in handlers.
$ComputerName Returns the name of the computer on which the handler is running.
$CurrentStepID Returns an integer that contains the step ID of the currently executing step.
$HandlerName Returns the name of the currently running handler.
CONDITIONS
A condition refers to an action that takes place only if a specific condition is met. Conditional
expressions enable a handler to act differently each time it is executed, depending on the input.
Conditions evaluate a single expression to determine whether the outcome is true or false.
If the sun is up, it must be daytime, and I need to go to work.
EXAMPLE
LOOPING
A loop is a series of instructions that is repeated until a certain condition is met. Each pass through the
loop is called an iteration. You just experienced looping in the previous Selection example. We kept
checking the same variable but for different values. Looping is a necessary function in programming.
You have a list of employee records in a database and you want to verify that you have a home phone
EXAMPLE
number for everyone. The program logic needs to go through each record one at a time and see if
there is a phone number in the record.
OBJECTS
In Interaction Center, an object is an entity on which actions can be performed. Any entities that IC
can manipulate are considered objects.
Calls
Faxes
Chat sessions
Email
When a call comes in to IC, a call object is created. That call object can have actions performed on
EXAMPLE
it, like being transferred or being placed on a users queue.
ATTRIBUTES
Objects can have attributes. Attributes define characteristics of objects. For example, attributes of
a person can be brown hair, blue eyes, and so on Attributes that describe a call object are things
like Call ID, ANI/DNIS information, and so on.
EVENTS
An event is an action or occurrence detected by a handler. As discussed previously, calls, faxes, chat
sessions, email, and other entities that IC can manipulate are considered objects. These objects have
associated events that tell IC how to treat the object. Some of the events are outbound call, call
transfer, call hold, conference a call. Objects are entities that IC can manipulate. Events are what
IC can do to those entities.
Events serve two purposes in IC:
An event can tell Interaction Processor to start an instance of a handler Each handler has been
designated to respond to a particular event. For example, when Telephony Services generates an
Incoming Call event, the Notifier tells Interaction Processor that the event has occurred. Interaction
Processor starts an instance of the handler configured to run when the Incoming Call event occurs.
An event can modify the information regarding the object This information is stored as an
attribute of the object. For example, an event generated by an incoming call creates (or collects)
information about that call, such as the Caller ID and the name of the line carrying the incoming call.
The information contained in the attributes can be used by the handler to make decisions about what
to do with the object.
A handler is an .ihd formatted file that is made up of individual steps that form logic. Handlers
respond to events and handles them in various ways, depending on the logic of the handler.
A handler is nothing more than a series of discrete steps or tasks that, when combined, produce
some results or manipulate an object in some way. When linked together, handlers are powerful
programs that determine the behavior of IC. Handlers allow you to customize IC according to your
companys needs.
Certain handlers, called base handlers, should NEVER be modified. Customization points are
CRITICAL
provided for modifications.
Interaction Attendant uses handlers to perform the inbound call routing operations that you design
in Attendant. The Attendant handlers should NEVER be modified.
SUBROUTINES
Subroutines are handlers started by other handlers, as opposed to handlers started by events on the
IC server. Subroutines are useful for many reasons:
A subroutine nicely encapsulates a set of logic into a single callable action You can reuse a
subroutine by calling it from any handler where that logic is appropriate.
Subroutines ease your maintenance burden By keeping your logic in simple, small modules, you ease
the overall maintenance time by working on smaller components and not on a large monolithic file.
Subroutines make handler building more visually manageable and understandable Handlers with
hundreds of steps can be hard to understand and manage. A few subroutines can make a large
handler easy to modify and understand.
Essentially, by using subroutines properly, you break the handler logic down into bite-sized pieces.
Labs
There are no labs associated with this module.
INTERACTION DESIGNER
Interaction Designer is Interactive Intelligences graphical application generator. Interaction
Designer is the tool for viewing, debugging and writing the programs (handlers) that control the
various interaction processing behaviors within the Interaction Center.
Interaction Designer offers hundreds of tools that perform various functions, including:
Access a database
Send an email message
Send a fax
Transfer a call
Integrate with a mainframe
And many others
By logically linking these tools together in a handler, you can create almost unlimited functionality. For
example, the out-of-the-box remote voice mail retrieval functionality is comprised entirely of handlers.
ID has a menu bar similar to other Windows-based applications. Many menu selections have
corresponding toolbar buttons. Menu items that have an associated toolbar button display the
toolbar button icon beside the menu choice. The ID menu bar displays the following menus:
File Menu
Edit Menu
View Menu
Layout Menu
Utilities Menu
Window Menu
Help Menu
FILE MENU
EDIT MENU
The View menu determines which parts of the Interaction Designer window are displayed. You
cannot hide the Handler area.
LAYOUT MENU
UTILITIES MENU
HELP MENU
There are several areas in the Interaction Designer interface that require more explanation at
this time:
Standard Toolbar
Palette Toolbar
Layout Toolbar
Handler Area
Design Palette
Messages palette
Debug Palette
Variables Palette
Quickjump Palette
TOOLBARS
Standard Toolbar The standard toolbar provides many typical functions. These functions are also
found in the File menu or Edit Menu.
Layout Toolbar The layout toolbar provides a button to toggle the grid display, a list box that lets
you zoom in or out on the handler using predefined settings, and buttons that allow you to quickly
align selected steps. These functions are also found in the Layout menu.
HANDLER AREA
The handler area displays currently open and non-minimized handlers. Use the Windows menu to
determine how to display the open handlers or to choose the handler to display. The grid can be
used to align the handler steps and can be turned off under the Layout menu.
As you can see, a handler consists of steps connected together. These steps are sequentially
processed to form the logic of the handler.
The Design palette has two pagesthe Tools page and the Subroutines page.
Tools Page Use the Tools page to insert steps into a handler. Tools provide the functionality of the
handler. The Tools page is a virtual tool chest providing tools specific to handler development. Tools
allow the handler to:
Create variables and/or assign a value to a variable
Test conditions
Connect to and read from a database
Place calls
Play a .wav file
Test a condition and branch accordingly
And perform hundreds of other useful functions
A step is an instance of a tool in a handler. Most tools have parameters that must be completed
before the step is functional. A handler is made up of multiple steps that have been connected
together to form the logic of the handler. The steps will be completed in a sequential order.
Subroutines Page Use the Subroutines page to insert a subroutine call into a handler.
A subroutine tool will exist for every handler created with a subroutine initiator.
Each page of the subroutine palette contains a group of related subroutine tools. These groups
are called categories.
The categories and labels for the subroutine tools are created when subroutines are published.
A subroutine tool will not appear in the Design palette until the subroutine has been published.
B-21Appendix B 2017, Interactive Intelligence, Inc.
MESSAGES PALETTE
The Messages Palette contains two pagesthe Handler Messages page and the General
Messages Page.
Handler Messages If a condition exists within the handler that would prevent it from being
published, a message will be displayed in the Handler Messages page along with the Step ID to which
the message pertains. Double-clicking on the message will shift the design windows view to focus on
the relevant step and select that step.
General Messages The messages listed here describe problems that pertain to Interaction
Designer but not to any specific handler. These errors can relate to the COM API, loading libraries,
loading subroutines, and so on
DEBUG PALETTE
The debug palette contains four tabs for viewing the activity of a handler during a debug session.
Watch Variables This window will display the values of watch variables throughout the debugging
session and will also give you the option to have the handler pause whenever the value of one of the
watched variables changes.
Step Variables When execution is paused on a step, users can click the Step Variables tab in the
Debug Palette and Designer will show the variable values for all variables used by the currently
displayed executing step.
Handler Variables When execution is paused on a step, users can click the Handler Variables tab in
the Debug Palette and Designer will show the current values for all variables in the currently
displayed handler.
Call Stack This window contains the call stack for the currently executing handler. The information
in the call stack is in the format (step ID) Handler name. Users can select entries in the window to
view other handlers that are in the call stack. The calling step is highlighted with a dashed line. The
currently executing step will have a solid line around it.
The Variables Palette provides information about the variables that are currently defined within the
selected handler.
Handler authors can right-click on variables shown in the variable bar to display the following menu:
List Steps That Use This Variable Populates the QuickJump palette with steps in the current
handler that reference the selected variable. This option opens the QuickJump Palette if it is not
already open.
Add Selected Variable(s) to Watch Variables Tab Populates the Watch Variables page of the
Debug Palette with the selected variable or variables. This selection is only available when the
current handler is in debug mode.
Add Variable Opens the Declare Variable dialog in which you can create a variable and assign
it an initial value. This selection is not available in debug mode.
Rename Variable Opens the Rename Variable dialog in which you can change the name of an
existing variable. This selection is not available in debug mode.
Delete Selected Variables(s) Deletes the selected variable or variables. This selection is only
available if the selected variable or variables are not referenced in the current handler. This
selection is not available in debug mode.
Set Initial Value Opens the Initial Value dialog in which you can assign a literal initial value.
This selection is not available in debug mode.
The QuickJump Palette provides a way for you to quickly find a step in a handler. By double-clicking
the Step Label in the palette, ID will select that step and set focus to the portion of the handler that
contains the step.
You can set options for the display within the QuickJump palette in the Utilities menu.
Review Questions
Complete the review questions for this module in your study guide.
Labs
There are no labs associated with this module.