Avaya Solution & Interoperability Test Lab
Application Notes for the JTAPI Agent Viewer Sample
Application – Issue 1.0
Abstract
The JTAPI Agent Viewer is a GUI based application which demonstrates common contact
center agent call handling features using the Avaya Aura™ Application Enablement (AE)
Services‟ JTAPI SDK, including login/logout, call answer/disconnect, and change of Agent
State. It also allows the user to monitor the State of the Agent and of Calls in which the Agent
is involved.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
1 of 66
JTAPIAgentView
1.
Introduction ............................................................................................................................. 3
1.1
How this document is organized ..................................................................................... 4
2. Hardware and Software Requirements ................................................................................... 5
3. AgentView User Experience................................................................................................... 6
3.1
AgentView Environment and Startup options ................................................................ 6
3.2
Work State Scenarios ...................................................................................................... 7
4. AgentView Software Design and Structure .......................................................................... 21
4.1
Folder Structure and Contents ...................................................................................... 21
4.2
Sequence Diagrams ....................................................................................................... 25
4.3
Logical Flow of the Agent View Application............................................................... 32
5. Configuring AgentView........................................................................................................ 37
5.1
Pre-requisites for Running the Application .................................................................. 37
5.2
Configuring the Environment to Run the Application .................................................. 37
5.3
Configuring a Communication Channel between AE Services and Communication
Manager .................................................................................................................................... 38
5.4
Configuring the JTAPI Client to make AE Service Requests ...................................... 39
5.5
Configuring a Station for the Agent.............................................................................. 39
5.6
Configuring a Station to Initiate Calls .......................................................................... 39
5.7
Configuring a Hunt-group to Route Calls to the Agent ................................................ 39
5.8
Configuring an Agent with Login ID 50001................................................................. 40
5.9
Editing the Agent.properties File ...................................................................... 40
5.10 Tracing .......................................................................................................................... 41
5.11 Building and Executing the Application ....................................................................... 42
6. Troubleshooting .................................................................................................................... 52
7. References ............................................................................................................................. 54
Appendix A: Avaya Communication Manager Hunt-Groups ...................................................... 55
A-1 Configuring and validating the Hunt Group ..................................................................... 55
A-2 Configuring the Agent ...................................................................................................... 58
A-3 Configuring Station on Communication Manager ............................................................ 62
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
2 of 66
JTAPIAgentView
1. Introduction
JTAPI AgentView is a GUI based application implemented using Java. It is designed to
demonstrate the Call Center Agent related capabilities provided by the Java Telephony API
(JTAPI) library which is a part of the Avaya software suite. This application simulates an Agent
and showcases a set of operations that can be performed by an Agent. This application allows
the Agent actions and operations such as:

Agent login and logout,

Call monitoring,

Call handling services such as „answer‟ and „disconnect‟ offered by the JTAPI API,

Agent state changes using the enablePending feature,

Monitoring and display of Agent State (READY, NOT READY, BUSY or WORK
NOT READY), and,

Access to additional information such as the state of the call/connection and the
calling/called extensions (ANI/DNIS).
Through examination of the AgentView sample application, its structure and code base,
developers will gain greater insight into the value and use of the Avaya AE Services JTAPI SDK
in creating similar tools.
Developers should be familiar with basic principles of Computer Telephony Integration (CTI),
JTAPI and CSTA, and have a working knowledge of Core Java. Eclipse has been used by
Avaya to compile this application, and the Avaya IP Communications Development
Environment (IPCoDE) supporting Avaya Communication Manager and Avaya AE Services was
used as a test environment.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
3 of 66
JTAPIAgentView
1.1 How this document is organized
Section 2 describes the hardware and software required to use the application.
Section 3 describes the application from a user perspective, providing examples of the various
agent functions enabled through the software.
Section 4 provides an overview of the software design and structure, including sequence
diagrams.
Section 5 provides information on the installation and compilation of the software, as well as
necessary configuration steps to utilize the application with Avaya IPCoDE.
Section 6 provides information on troubleshooting the installed application.
Section 7 includes pointers to reference materials on JTAPI.
Appendix A provides information on configuring Hunt Groups in Avaya Communication
Manager.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
4 of 66
JTAPIAgentView
2. Hardware and Software Requirements
The hardware and software used for developing and testing the application is listed in Table 1:
Hardware and software requirements.
Hardware/Software
Avaya S8300 Media Server with Avaya G700 Media Gateway running with Avaya
Aura™ Communication Manager 5.2.1
Avaya Aura™ Application Enablement Services 5.2.0
Microsoft Windows Vista Business with Service Pack 1
Java version 1.6
Eclipse version 3.5
Table 1: Hardware and software requirements
The application has also been tested against the IPCoDE configuration, which is listed in Table
2.
IPCoDE Configuration
Avaya Communication Manager 5.0
Avaya Application Enablement Services 4.2.0
VMWare WorkStation 5.0
Table 2: IPCoDE configuration
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
5 of 66
JTAPIAgentView
3. AgentView User Experience
The AgentView application provides for two basic scenarios: Auto In and Manual In work
modes. These work modes differ only in the state to which the Agent automatically moves after
handling a call. In the Auto In mode, the Agent changes to the READY state automatically
when the call is terminated. In contrast, in the Manual In mode, the Agent state remains WORK
NOT READY after handling a call, requiring the Agent to take explicit action to move to the
READY state in order to receive another call.
The Manual In work mode allows the Agent to have sufficient time to complete post-call work
items, such as order processing, documenting call notes or obtaining training feedback.
3.1 AgentView Environment and Startup options
The following scenarios assume a basic environment consisting of one contact center agent,
configured with a login ID of 50001 and utilizing a station at extension 40010. There is also
assumed to be a hunt group for routing calls to the agent, having a group extension of 49000.
In lieu of an inbound PSTN trunk, a second station (configured at extension 40011) is used to
simulate the calling party. Configuration steps are described in more details in section 5.2.
3.1.1 Application Startup
The application jar file is provided along with the source code. To run the application, navigate
to the AgentView\Release folder and double-click on the Agent.bat file.
The application will first read the Agent.properties file. For more information on this file,
please refer to Section 5.9.
When the user double-clicks on Agent.bat, the LoginGUI window requesting user information
is displayed. The user will need to enter the input values for all the required fields such as
Station Extension (for example, 40010), Agent ID (for example, 50001) and Agent Password
(optional). The user will also need to select the Agent Work Mode (either Auto In or Manual
In); this will be the initial Work Mode for the Agent after login.
3.1.2 Understanding Agent State
It is important to understand the concepts of Agent State. Agent State describes the availability
of the Agent to accept or participate in a call.
Valid values for Agent State are:

READY: Indicates that the Agent is available to accept a call.

NOT READY: Indicates that the Agent is unavailable to accept a call. Typically, they
are not doing any call-related work (e.g. they are on a break).

WORK NOT READY: Indicates that the Agent is unavailable to accept calls and is busy
processing call information after disconnecting the call.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
6 of 66
JTAPIAgentView

BUSY: Indicates that the Agent is unavailable to accept a call because it is busy with
another call.
3.2 Work State Scenarios
The remainder of this section describes the following scenarios:

Scenario 1: Basic Auto In work mode.

Scenario 2: Basic Manual In work mode.

Scenario 3: Requesting Agent State changes during a call (e.g. when Agent State =
BUSY and enablePending check is selected/cleared).
3.2.1 Scenario 1: Auto In Work Mode
The Auto In work mode scenario involves:
1. Logging in an Agent in the Auto In work mode.
2. Receiving and answering an incoming call using the application.
3. Disconnecting the call using the application.
4. Logging out the Agent.
3.2.1.1 Login of an Agent in the Auto In Work Mode
Run the application by navigating to the AgentView/Release folder and double-clicking on the
Agent.bat file. The Agent login screen will be displayed (Figure 1). Enter the values for the
input fields Station Extension, Agent ID, and Agent Password (if applicable). Select the Auto
In radio button and click the Login button to log in.
To close the application, click the Exit button.
Figure 1: Agent Login in the "Auto In" Work Mode
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
7 of 66
JTAPIAgentView
After a successful login, the application will display the Agent State GUI window (Figure 2).
Figure 2: Agent State GUI after clicking the Login button
The Agent State output area (first box from the top of the Agent State GUI) shows the Agent‟s
current state. An Agent State of READY is set at initial login. Note that the Answer and Drop
buttons are disabled because there is no active call at the Station Extension. The Agent State
and the Agent Work Mode are highlighted in the figure (in white background text area).
If an error is encountered during Agent login, the application will display an error message box
with an appropriate message. Click OK in the error message box to return control back to the
Agent Login dialog.
3.2.1.2 Receiving and Answering an Incoming Call
Using the alternate station 40011, a call is placed by dialing the Hunt Group Extension 49000.
When the call is offered to the Agent by Avaya Communication Manager, the Agent State GUI
will display call alerting information. The message displayed in the Agent State GUI indicates
that there is an incoming call from Station (a.k.a. Device) 40011 to Device 40010 (i.e. the
Agent). Device 40010 is ringing and Device 40011 is talking in the call. The Answer button
becomes enabled and the Drop button remains disabled as shown in Figure 3.
At this time, the Agent State changes from READY to BUSY.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
8 of 66
JTAPIAgentView
Figure 3: Incoming Call to Agent
The Agent then clicks the Answer button to accept and answer the incoming call.
Once the call is answered, the Answer button becomes disabled and Drop button becomes
enabled as shown in Figure 4.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
9 of 66
JTAPIAgentView
The highlighted message shown in Figure 4 indicates that the device 40010 has answered the
call. At this time the Agent State remains unchanged i.e., BUSY.
Figure 4: Answering an incoming Call
Note: The call can also be answered manually by going off-hook on the Station.
3.2.1.3 Disconnecting the Call
The Agent can disconnect the active call by clicking the Drop button. This will instruct the
application to disconnect the active call.
Once the call is disconnected, both the Answer and Drop buttons are disabled. The text area on
the Agent State GUI (Figure 5) indicates that the call between 40010 and 40011 has been
disconnected.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
10 of 66
JTAPIAgentView
Figure 5: Agent State GUI dialog after the Call is disconnected
Note the change in the Agent State. Since the call is now complete and this is an Auto In work
mode scenario, the Agent State automatically changes to READY.
3.2.1.4 Logging Out the Agent
To log out, the Agent should click Logout button, which will instruct the AgentView application
to perform a logout operation on behalf of the Agent.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
11 of 66
JTAPIAgentView
The Agent is logged out and the LoginGUI window is displayed again with the Agent‟s previous
login details already populated as shown in Figure 6. This enables the user to log in as the same
Agent again.
Figure 6: The LoginGUI dialog after Agent logout
Note: The Agent can also be logged out manually by pressing the logout access code on the
phone. In case the Agent is logged out manually; the application is notified and displays a
message box as shown in Figure 7. On clicking the OK button on this box, the
LoginGUI window is displayed again as shown in Figure 6.
Figure 7: Manual Agent logout dialog
3.2.2 Scenario 2: Manual In Work Mode
This scenario covers Agent login with the Manual In mode to demonstrate the difference
between the Auto In and Manual In modes. In contrast to the Auto In work mode, when a call
is disconnected (either by the Agent or the caller), the Agent State is moved automatically to
WORK NOT READY, and the Agent must take manual action to return to a READY state in
order to accept new calls. This scenario involves:
1. Logging in an Agent in the Manual In work mode.
2. Receiving, answering and disconnecting an incoming call using the application.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
12 of 66
JTAPIAgentView
3.2.2.1 Logging in an Agent in the Manual In Work Mode
On the LoginGUI window, select the Manual In radio button and press the Login button as
shown in Figure 8. This will instruct the application to perform a login operation on behalf of
the Agent.
Figure 8: Agent Login in "Manual In" Work Mode
After a successful login in the Manual In Work Mode, the application will display the Agent
State GUI window as shown in Figure 9.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
13 of 66
JTAPIAgentView
The Answer and Drop buttons are disabled, since there is no call at the Station Extension.
After login, the initial Agent State is READY. The Agent State and Agent Work Mode are
highlighted in the Figure 9.
Figure 9: Agent State GUI window in the “Manual In” Work Mode
3.2.2.2 Receiving, Answering, and Disconnecting an Incoming Call using the
Application
After logging in the Agent in the Manual In Work Mode, follow these steps in the specified
sequence:
1. Dial the Hunt-group extension 49000 using the alternate Station 40011. The call will be
offered to the Agent.
2. Click on the Answer button to answer the call. The buttons‟ state changes and messages
similar to those covered for the Auto In work mode are displayed in the message text
area.
3. Click on the Drop button to disconnect the call.
Please note that as the Agent has logged in using the Manual In work mode, the Agent State
changes from READY to WORK NOT READY as shown in Figure 10. This suggests that
whenever the Agent logs in with the Manual In work mode, the Agent State changes to WORK
NOT READY as soon as the Agent completes a Hunt-group call. The Agent is now required to
change its state to READY to receive another call offered through the Hunt-group.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
14 of 66
JTAPIAgentView
Figure 10: Agent State changes to WORK NOT READY after the Agent disconnects a Call in “Manual In”
Work Mode
Select the READY radio button and click the Change State button to change the Agent State to
READY.
Note: The Agent State is unaffected when a call is made directly either to the Station Extension
or to the Agent ID.
3.2.3 Scenario 3: Requesting Agent State Changes
There can be many situations where an Agent wishes to explicitly modify their state to ensure
that, upon call completion, no additional calls are presented to them. Typically, this occurs when
an Agent that is logged in under the Auto In work mode requires additional time to handle postcall matters, and wishes to override the default Auto In action, that would automatically move
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
15 of 66
JTAPIAgentView
their Agent State to READY upon call completion, to a WORK NOT READY/BUSY state
instead.
Alternatively, the Agent may be scheduled for a break and wishes to change their state to NOT
READY upon call completion. In high volume contact centers, calls may be presented to the
Agent at such a rate as to make changing the Agent State manually only after call termination
impractical, and thus it is necessary to offer some mechanism that provides for pending Agent
State changes.
It is important to understand that enablePending will only have an effect if, at the time of
request, the target Agent State is different from the current Agent State.
3.2.3.1 Requesting Agent State Changes during an Active Call
Using the more typical Auto In work mode scenario, the pending state change involves
additional steps in the process:
1. Logging in an Agent in the Auto In work mode.
2. Receiving and answering an incoming call using the application.
3. Requesting a pending change to Agent State during the call by using the application.
4. Disconnecting the call using the application, and transitioning to the requested Agent
State based on the pending state change value.
5. Manually changing the Agent State from BUSY or NOT READY to READY.
Select the NOT READY radio button on the Agent State GUI window and press the Change
State button. This will instruct the application to send a “Change Agent State (CAS)” request to
JTAPI Service.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
16 of 66
JTAPIAgentView
If the Agent is currently handing a call, the Agent State cannot be changed. In this case, the
AgentView application will receive an error message from the JTAPI Client, and therefore
displays a message box indicating that the Agent State cannot be changed while the Agent is
handling a call (Figure 11).
Figure 11: Error message displayed while changing the Agent State when the Agent is handling a Call
However, the Agent can submit a request to queue the state change request by selecting the
enablePending checkbox, and clicking the Change State button again.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
17 of 66
JTAPIAgentView
The highlighted message (Figure 12) indicates that the request to change the state of the Agent
has been made with the enablePending flag checked.
Figure 12: Selecting the enablePending flag to queue the Agent State change request
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
18 of 66
JTAPIAgentView
When the enablePending checkbox is selected, the request for state change is queued and the
effect of the state change request is not seen until the call is completed. This can be seen once the
call is completed (Figure 13).
Figure 13: Change in Agent State due to pending Agent State change request
Since there was a pending request for changing the Agent State to NOT READY, the JTAPI
Client is able to act on this request. As a result, the Agent State is now changed to NOT
READY.
The use of enablePending and a request for a State Change to NOT READY is one method by
which an Agent can indicate that he is not ready to receive a new call, and ensure that Avaya
Communication Manager does not automatically send them a new call.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
19 of 66
JTAPIAgentView
3.2.3.2 Requesting Agent State changes when not in a Call
When the Agent is not handling a call (i.e., when the Agent is in the READY State), the Agent
State can also be changed without using the enablePending checkbox.
Again, using the more typical Auto In work mode scenario, the pending state change involves a
new step in the process:
1. Logging in an Agent in the Auto In work mode.
2. Receiving and answering an incoming call.
3. Disconnecting the call using the application.
4. Changing the Agent State after the call.
5. Changing the Agent State to Ready or Logging out the Agent.
An Agent can change their state by selecting the WORK NOT READY radio button and then
clicking the Change State button on the Agent State GUI window (no need to select
enablePending). This will instruct the AgentView application to send a “Change Agent State
(CAS)” request to the JTAPI Client.
In response to the request, the Agent State is changed to WORK NOT READY (Figure 14).
Figure 14: Changing the Agent State without using the enablePending flag
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
20 of 66
JTAPIAgentView
4. AgentView Software Design and Structure
4.1 Folder Structure and Contents
The AgentView application is designed as a GUI based application. It has two windows - one
for Agent login and the other which displays Agent and Call states. This application implements
the Observer design pattern, where the AgentStateUI class acts as an observer and the
AvayaCallCenterUserAgent and CallManager classes act as Observables. The
AvayaCallCenterUserAgent class notifies the AgentStateUI class whenever the Agent State
changes, and similarly the CallManager class notifies the AgentStateUI class for
call/connection state changes.
The AgentView application is designed such that only one instance of the application can be
started, and the application checks for any other running instances during initialization.
After importing the project into Eclipse, the AgentView project will contain the following
folders:

bin

config

lib

Release
– This contains the class files, generated when the source files are compiled.
– This contains the configuration files for the application. Edit these files to
change AgentView‟s configuration.
– This contains the jar files for the JTAPI client and the log4j tracing library.
– When the project is built, this folder is populated with all the files needed to
run AgentView. Note that any changes made to the files in this folder will be lost when
the project is built. The folder is populated as follows:
o Agent.bat, Agent.properties, log4j.properties and TSAPI.PRO come
from the config folder.
o Ecsjtapia.jar and log4j-1.2.12.jar come from the lib folder.
o agentview.jar is generated from the compiled files in the bin folder.

src
– This contains all the source files for AgentView. It is made up of three packages:
o com.avaya.aes.agenttest.apicomm which handles communication with the
JTAPI Client.
o com.avaya.aes.agenttest.callcontrol which processes incoming events.
o com.avaya.aes.agenttest.ui which creates the Graphical User Interface.

in the root folder of AgentView is the Ant configuration file. It contains rules
to Clean, Build and Run AgentView.
build.xml
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
21 of 66
JTAPIAgentView
The application class diagram is shown in Figure 15. For clarity, some attributes and operations
are omitted.
Figure 15: Class diagram of the AgentView sample application
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
22 of 66
JTAPIAgentView
Descriptions of the class files found in the src folder are as follows:
ui

AgentViewApp: This class initializes the application and is responsible for instantiating
the CallManager. It is also responsible for displaying the LoginGUI window.

LoginUI:

AgentStateUI:

AgentStateInterface:

CallStateInterface:
This class represents the LoginGUI window. It receives user input for Station
Extension, Agent Login, Password and Agent Work Mode. This class inserts default
values, validates the user input and creates an instance of the
AvayaCallCenterUserAgent class. This class is also responsible for instantiating the
AgentStateUI class which displays the Agent State GUI window.
This class represents the Agent State GUI and contains various UI
controls such as the Answer/Drop/Change State/Logout buttons/radio buttons for
selecting the Agent State (READY/NOT READY/WORK NOT READY) and a
checkbox for the enablePending flag. This class acts as an observer for observing
call/connection states as well as agent state for displaying Agent and call information.
This interface defines Agent States that may be sent to an
observer. In this application, the AgentStateUI class implements this interface and
registers as an observer of the AvayaCallCenterUserAgent class.
This interface defines call/connection States that may be sent to
an observer. In this application, the AgentStateUI class implements this interface and
registers as an observer of the CallManager class.
callcontrol


CallManager:
This class is at the core of the call control. Its responsibilities include:

It manages the event queue which is used to pass incoming event transactions from
the JTAPI Client thread to the WorkerThread for processing.

It holds a list of CallDetail objects which represent active calls.

It holds a list of calls which are on-hold.

It sends the call/connection state change notifications to its registered observers. In
this application, AgentStateUI acts as an observer and receives all the state change
notifications forwarded by the CallManager class.
AvayaCallCenterUserAgent:
This class represents an Agent and contains functionality
typically performed by an Agent such as login/logout, answering/disconnecting calls,
changing the Agent State etc. This class also polls for the Agent State at fixed time
interval (5 seconds). When the application receives a call state change notification, the
application preempts the polling cycle and makes an immediate request to get the current
Agent State. This class sends Agent State change notifications to its registered observers.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
23 of 66
JTAPIAgentView
In this application, the AgentStateUI class registers itself as an observer, and displays
Agent State change notifications forwarded by the AvayaCallCenterUserAgent class.

CallDetail:

CallUtilities:
This class stores details about a single call.
This class implements several utility methods that are used by the event
handler classes.

CallControlUpdate:

Eventhandler:

EventTransaction:

WorkerThread:

AgentAnswerHandler:

AgentDisconnectHandler:

ConnectionAlertingHandler:
This class stores information about the current state of the call and
its connections. It is passed from the CallManager to the AgentStateUI.
This interface is the parent from which all event handlers must inherit.
By implementing this interface, a handler may be added to an EventTransaction.
This class holds a number of Events and their associated Handlers.
One transaction contains the events for a single Meta event.
This class monitors the CallManager‟s event queue. It removes each
transaction from the queue and executes each event handler, one at a time.
This class attempts to answer the Agent‟s terminal. It is triggered
when the user clicks the Answer button on the Agent State GUI.
This class disconnects the Agent‟s terminal. It is triggered
when the user clicks the Drop button on the Agent State GUI.
This class processes an Alerting event received from the
JTAPI Client.

ConnectionDisconnectedHandler:
This class processes a Disconnected event received
from the JTAPI Client.

ConncetionEstablishedHandler:
This class processes an Alerting event received from
the JTAPI Client.

ConnectionInitiatedHandler:
This class processes an Initiated event received from
the JTAPI Client.

TerminalConnectionHeldHandler:
This class processes a TerminalConnectionHeld
event received from the JTAPI Client.

TerminalConnectionTalkingHandler:

TerminalConnectionUnknownHandler:
This class processes a
TerminalConnectionTalking event received from the JTAPI Client.
This class processes a
TerminalConnectionUnknown event received from the JTAPI Client.
apicomm

JTAPIInterface:
This class acts as a wrapper for the JTAPI Client library. It invokes
methods provided by the JTAPI Client. For example, to establish a session with the AE
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
24 of 66
JTAPIAgentView
Services server, it invokes the JTapiPeer.getProvider() method. It is used by
AvayaCallCenterUserAgent to start/stop monitoring an agent and to request the current
status of the agent.

CallControlTerminalConnectionProxy: This class extends
CallControlTerminalConnectionAdapter from the JTAPI Client.
It has the following
responsibilities:

It receives, from the JTAPI Client, Connection and Terminal Connection events for
the monitored agent‟s terminal.

It selects the handler class that is appropriate for the incoming event.

A Meta event may cause several Connection and/or TerminalConnection events. The
AgentView application should not begin to process any of these events until all
events for the Meta event have been received. To ensure this, the
CallControlTerminalConnectionProxy bundles events (and their handlers)
associated with a Meta Event into a single Transaction.

Once all events have been received for the Meta event, the
CallControlTerminalConnectionProxy places the transaction on the event queue
of the CallManager.
4.2 Sequence Diagrams
The application flows under various conditions. These sequences are:

Login

Logout

Receive
o Receiving Agent State changes
o Receiving call/connection State changes

Manual Action
o Logout
o Change State
o Answer/Disconnect
Some of these flows are described using the sequence diagrams below.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
25 of 66
JTAPIAgentView
4.2.1 Login Sequence
The Agent Login flow diagram (Figure 16) depicts the sequence in which different objects get
instantiated along with the interaction between them.
Figure 16: Agent login sequence
The steps followed when a user tries to log in as an Agent are:

When the user clicks on the Login button, the supplied credentials are verified by the
onLoginRequest() method of the LoginUI class.

After successful verification, the LoginUI class instantiates the
AvayaCallCenterUserAgent class.

The AvayaCallCenterUserAgent class sends a monitor request to AE Services by
calling the startMonitor() method of the JTAPIInterface. This will allow the
application to receive call/connection state notifications for call activity on the Station.

After the monitor request, the application calls the addAgent() method of the
LucentTerminal class to log in the agent.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
26 of 66
JTAPIAgentView

The application then starts up the Agent monitoring timer thread by calling the
queryAgentState() method. This polls the agent state every 5 seconds. See section
4.2.3 for details of the timer‟s operation.

After the Agent has successfully logged in, the application creates an instance of the
AgentStateUI class and displays the Agent State GUI window.

The AgentStateUI class registers with the CallManager and
AvayaCallCenterUserAgent classes to receive notifications for call/connection state and
Agent State changes respectively.
4.2.2 Logout Sequence
The Agent Logout sequence (Figure 17) shows the steps taken by the application when the
Logout button is clicked.
Figure 17: Agent logout sequence
This sequence is as follows:

Clicking the Logout button causes the onBnClickedLogout() method of AgentStateUI to
be called. This in turn calls onCancel().

onCancel()
invokes the agentLogout() method of the AvayaCallCEnterUserAgent
class.

agentLogout()
invokes the removeAgent() method of the LucentTerminal class to log
out the agent.

invokes queryAgentState() so that it will pick up the new state
of the Agent as soon as possible. This will lead to the sequences in 4.2.3 and 4.2.4 being
performed.
agentLogout() then
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
27 of 66
JTAPIAgentView
4.2.3 Receive Agent State Change Sequence
Figure 18 shows the sequence when the Agent State change events are received by the
application.
Figure 18: Receive sequence – receiving Agent State

Each time the AgentStateTimerInterval timer elapses, AvayaCallCenterUserAgent
invokes the getState() method of the LucentV7Agent object to poll for the current
agent state.

If the state has changed, AvayaCallCenterUserAgent calls the updateAgent() method.
This informs its observers by calling the notifyObservers() method that it inherited
from the Observable class.

As an observer of AvayaCallCenterUserAgent, AgentStateUI receives the state change
as a call to the update() method.

AgentStateUI
passes the update to the agentUpdate() method which updates the GUI
with the new state.
4.2.4 Agent Logout Sequence
The Agent Logout sequence (Figure 19) shows the steps taken by the application when it
discovers that the Agent has logged out. The sequence is the same if the Agent Manually logs
out or clicks the Logout button as described in 4.2.2.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
28 of 66
JTAPIAgentView
Figure 19: Receive sequence – receiving Agent Logout

As described in section 4.2.3, AvayaCallCenterUserAgent polls the Agent‟s state every
5 seconds. When it discovers a change in state, it notifies it‟s observers. In this way, the
update() method of the AgentStateUI is called.

As the notification is from the AvayaCallCenterUserAgent, AgentStateUI passes the
update to the agentUpdate() method. This recognizes that the agent has logged out and
calls the agentLoggedOut() method.

The agentLoggedOut() method stops monitoring the Agent‟s extension by calling the
agentStopMonitor() method of AvayaCallCenterUserAgent. This, in turn, calls the
stopMonitor() method of JTAPIInterface which removes the
CallControlTerminalConnectionProxy.

agentStopMonitor(), in turn, calls the stopMonitor() method of JTAPIInterface
which removes the CallControlTerminalConnectionProxy and stops listening for events for
the Agent‟s terminal.

agentStopMonitor()
then stops the Agent Status Poll timer.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
29 of 66
JTAPIAgentView

AgentStateUI closes the Agent State UI window
of LoginUI to have the Login UI displayed again.
and calls the agentLogOut() method
4.2.5 Receive Call State Changes
There are several different Call State Update sequences. Figure 20 describes what happens when
a call is made to the Agent.
Figure 20: Receiving sequence – receiving Call/Connection state

The CallControlTerminalConnectionProxy receives a SingleConnectionMetaStart
event which indicates that a transaction is about to begin. It creates a new
EventTransaction to hold the incoming events.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
30 of 66
JTAPIAgentView

The CallControlTerminalConnectionProxy then receives a
ConnectionEstablishedEvent. It creates a ConnectionEstablishedhandler and adds it
to the transaction.

The CallControlTerminalConnectionProxy then receives a
TerminalConnectionTalkingEvent. It creates a TerminalConnectionTalkingHandler
and adds it to the transaction.

The CallControlTerminalConnectionProxy then receives a ConnectionAlertingEvent.
It creates a ConnectionAlertingHandler and adds it to the transaction.

The CallControlTerminalConnectionProxy then receives a
TerminalConnectionRingingEvent. AgentView does not use this event and ignores it.

The CallControlTerminalConnectionProxy receives a SingleConnectionMetaEnd
event. It places the transaction onto the Event Queue.

The WorkerThread is monitoring the Event Queue and removes the transaction for
processing. It executes each handler in the transaction in turn.

In this case ConnectionEstablishedhandler and
TerminalConnectionTalkingHandler do nothing. In other circumstances, they may
perform some actions.

In this case, ConnectionAlertingHandler calls addNewCall() on the CallManager to
inform it that a new call has started. It then calls updateCall() with the new call state
information.

The CallManager notifies its observers that the call state has changed. In this way, the
update() method of AgentStateUI is called.

AgentStateUI recognizes that the incoming notification
and calls cmUpdate() to display the new call state.
is due to a change of call state
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
31 of 66
JTAPIAgentView
4.2.6 Manual Action Sequence – Answer a Call
Figure 21 shows the steps taken by the application when any action is taken by manually
pressing the Answer button on the Agent State GUI window.
Figure 21: Manual Answer Sequence

When the user clicks on the Answer button on the Agent State GUI window, the
onBnClickedSetAgtState() method of the AgentStateUI class is called.

This method calls the agentAnswerCall() method of the CallManager class.
agentAnswerCall() creates an EventTransaction containing an AgentAnswerHandler
and places it on the Event Queue.

The WorkerThread is monitoring the Event Queue and removes the transaction for
processing. It executes each handler in the transaction in turn.

The AgentAnswerHandler checks that the extension is in a state where it can be
answered If it is, AgentAnswerHandler calls the answer() method of the
TerminalConnection class to answer the call.
4.3 Logical Flow of the Agent View Application
The basic flow of the AgentView application is described below:
1. Get a JTAPI Provider, i.e., when a user double-clicks on the application executable, a
Provider is obtained.
2. Present the LoginGUI window to the user.
3. Collect inputs from the user to populate the LoginGUI window.
4. Validate the data entered by the user.
5. Send a JTAPI request to add a call observer on the Station Extension.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
32 of 66
JTAPIAgentView
6. Log an Agent into a Station Extension.
7. Present the Agent State GUI window with the Agent‟s details.
8. Send JTAPI requests to change the Agent State.
9. Send JTAPI requests to query the Agent State.
10. Handle call state change events for calls at the Agent‟s Station.
11. Send a JTAPI request to answer/disconnect a call.
12. Send a JTAPI request to log out the Agent.
13. Handle the logout event for the Agent.
14. Send a JTAPI request to remove the call observer from the Station Extension.
4.3.1 Getting a JTAPI Provider
Before the Agent Login GUI window is displayed, a JTAPI Provider is obtained in the
openStream() method of the JTAPIInterface class; openStream()method is called during
application initialization.
Obtaining a JTAPI Provider involves the following steps:
1. Getting the JTAPI peer object.
2. Getting the Advertised Service Name.
3. Getting the Provider object.
These steps are elaborated below:
1. Getting the JTAPI peer object: The JtapiPeer interface in the javax.telephony
package represents an Avaya custom implementation of the JTAPI. An instance of the
JtapiPeer object is obtained using the JtapiPeerFactory class. The getJtapiPeer()
method of the JtapiPeerFactory class returns a JtapiPeer object which in turn,
enables applications to obtain the Provider object.
2. Getting the Advertised Service Name: The application needs to select the service name or
the CTI link to be used. All the available services are listed by the getService()
method in the JTAPIPeer interface. The application can use this method to get the list of
services and then select one of them for further use. This service will be used for
obtaining and establishing the application session with the selected AE Services server.
For simplicity, the application reads the service name from the Agent.properties file.
This file contains the name of the CTILink which the application uses to create a
Provider object.
3. Getting the Provider object: The next step for the application is to acquire a Provider
object. This is achieved with the getProvider() method in the JTAPIPeer interface. A
Provider represents the telephony software-entity that interfaces with a telephony
subsystem such as Communication Manager through Avaya AE Services server.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
33 of 66
JTAPIAgentView
4.3.2 Logging an Agent into a Station Extension
When the user clicks on the Login button of the LoginGUI window, the Agent‟s credentials are
verified. If all the parameters are correct, the AvayaCallCenterUserAgent class is instantiated
with the Agent‟s credentials and the agentLogin() method is called in the constructor to log an
Agent into a Station Extension. agentLogin() starts monitoring the Agent Extension, logs the
Agent on at the Extension and begins polling the Agent state. If the agent login is successful, the
LoginGUI disappears and is replaced by the Agent State GUI.
4.3.3 Request for a change in the Agent State
Figure 22 and Figure 23 show the Agent State diagram for the Auto In and Manual In Work
Modes, respectively.
Figure 22: Agent State transition in Auto In Work Mode
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
34 of 66
JTAPIAgentView
Figure 23: Agent State Transition in Manual In Work Mode
When the Agent logs in using either Manual In or Auto In work modes, the initial idle state of
the Agent is READY, but the difference between these two modes becomes prominent when a
call is disconnected. In the Manual In mode, the Agent State changes from BUSY to WORK
NOT READY whereas in the Auto In work mode, the Agent State changes back to READY
after the call is disconnected.
When the user clicks on the Change State button on the Agent State GUI window,
onBnClickedSetAgtState() method is invoked. This method invokes the setAgentState ()
method of the AvayaCallCenterUserAgent class which in turn invokes the setState() method
on LucentAgent to set the Agent State.
4.3.4 Method for Handling Call Events
A high level event, such as when a call is originated by an extension, is called a Meta event.
Each Meta event can cause several Connection and/or Terminal Connection events. It is
important that the application does not begin to process an event until all events are received for
the Meta event. It is also important that the application does not use the JTAPI Client thread to
process these events.
When the startMonitor() method if JTAPIInterface is called, it creates an instance of
CallControlTerminalConnectionProxy and registers it with the JTAPI Provider. All
CallControlConnection and CallControlTerminalConnection events for the monitored
extension will be received by this instance.
Each relevant event received by CallControlTerminalConnectionProxy will be bundled into a
transaction until all events for a given Meta event are received.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
35 of 66
JTAPIAgentView
Once all events for the Meta event are received, CallControlTerminalConnectionProxy
places the transaction onto the Event Queue.
The WorkerThread monitors the Event Queue. If the queue contains a transaction, the
WorkerThread removes and processes it.
4.3.5 Request to Query the Agent’s State
The application must poll the AE Services server to receive any Agent State changes. This is
because event notification for Agent State changes are not supported by Avaya AE Services.
This sample application polls AE Services server every five (5) seconds and checks for changes
in the Agent State. Whenever the Agent‟s state changes, AvayaCallCenterUserAgent notifies
its observers.
When the AgentView application knows that the Agent‟s state is likely to have changed (e.g. the
Agent has logged in) it calls the queryAgentState() method of AvayaCallCenterUserAgent.
This causes the Agents state to be updated immediately and the 5 second timer to be restarted.
4.3.6 Logging an Agent Out
When the user clicks on the Logout button of the Agent State GUI window, the lucent Agent is
removed from the terminal by invoking the agentLogout() method of the
AvayaCallCenterUserAgent class.
4.3.7 Request to Remove a Call Observer
Once the Agent has logged out, the next step is to remove the call observer. The method
stopMonitor() of the JTAPIInterface class is invoked from the AvayaCallCenterUserAgent
class to remove the call observer from the Station Extension.
4.3.8 Handling Exit Request from GUI
The user can send a request to shutdown the Provider by clicking the Exit button on the
LoginGUI window, whereupon the clearStream() method of the JTAPIInterface class is
invoked. This method in turn invokes the shutdown() method of the Provider class to
shutdown the provider.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
36 of 66
JTAPIAgentView
5. Configuring AgentView
5.1 Pre-requisites for Running the Application
Before executing the application, ensure that the following software requirements are met:
1. A desktop with Microsoft Windows installed on it. The application has been tested on a
desktop with Windows XP Professional edition Service Pack 2 installed on it.
2. Ensure that JRE 1.5.0 or higher version is installed on the desktop. If JRE is not already
installed then it can be downloaded from http://java.sun.com/ and can then be installed.
3. JTAPI Client need not be installed as the necessary jar files and configuration are
included with the AgentView application. For information on configuring the JTAPI
Client, refer to the Section 5.4.
5.2 Configuring the Environment to Run the Application
Before running the application, the user needs to ensure that the environment is correctly set up.
The following steps are needed to be performed to configure the environment for using this
application:
1. Configuring a communication channel between AE Services server and Communication
Manager.
2. Configuring JTAPI Client to make service requests.
3. Configuring a Station for the Agent – A Station with Extension 40010 where the Agent
will log in during the testing.
4. Configuring a Station for initiating calls – An additional Station with extension 40011
which will be used for initiating calls during the testing.
5. Configuring a Hunt-group for routing calls to the Agent – A Hunt-group having Group
Extension 49000.
6. Configuring an Agent with login ID 50001.
7. Editing the Agent.properties file as described in section 5.9.
Each of the above configuration steps is described in detail in the following section. A
schematic of the network configuration diagram for the application testing environment is
provided in Figure 24.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
37 of 66
JTAPIAgentView
Figure 24: Network configuration diagram for the application testing environment
5.3 Configuring a Communication Channel between AE Services and
Communication Manager
The first step needed to run this application is to ensure that the communication channel between
AE Services server and Communication Manager is correctly configured and is working
correctly.
For information on configuring the communication channel between AE Services server and
Communication Manager, refer to Chapter 1 in [3]. If the channel is already configured, refer to
the section titled Running tests from the OAM pages in the same document to verify that the
channel is configured correctly. Once the communication channel between the AE Service
Server and Communication Manager is validated, the developer can proceed to the next step.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
38 of 66
JTAPIAgentView
5.4 Configuring the JTAPI Client to make AE Service Requests
There is a file called TSAPI.PRO in the config folder of the AgentView project. A snapshot of
the contents of TSAPI.PRO is shown below.
[Telephony Servers]
192.168.17.128 = 450
Figure 25: The TSAPI.PRO file
The configuration entry in the TSAPI.PRO file above indicates that the JTAPI Client will connect
to port 450 of the machine 192.168.17.128 to obtain a list of advertised services. If necessary,
edit this file to the correct values.
Note: At the time of running this application, the user should ensure that the TSAPI.PRO file
contains at least one entry to enable the JTAPI Client to communicate with AE Services
server.
5.5 Configuring a Station for the Agent
A Station is an endpoint registered with Communication Manager. Each Station has an
extension number associated with it. A Station is used to make a call either to another Station
registered with the same Communication Manager, or to an external Station. It can also be used
to answer incoming calls.
The Agent will log in at the Station extension entered by the user in the LoginGUI window
while running the application.
Refer to Section A-3 for the steps to configure a Station and to verify that the settings of the
Station correctly match those required by the application to work correctly. While running the
application, it is assumed that a Station with extension 40010 will be provisioned where Agent
will log in.
Once the Station configuration is validated the developer can proceed to the next step.
5.6 Configuring a Station to Initiate Calls
Once the Station for an Agent is configured correctly, a second Station configuration is required
either for making test calls to the Agent or for receiving calls made by the Agent.
Refer to Section A-3 for configuring the Station Extension on Communication Manager.
While running the application, it is assumed that a Station with extension 40011 is already
configured.
5.7 Configuring a Hunt-group to Route Calls to the Agent
Hunt-group is a Communication Manager administered object, which contains a group of
Agents. If a call is made to a Hunt-group, this call gets routed to an Agent who is idle.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
39 of 66
JTAPIAgentView
Refer to Section A-1 for the steps to configure a Hunt-group and to verify that the settings of the
Hunt-group are correct as required by the application. While running the application, it is
assumed that a Hunt-group with extension 49000 is already configured.
5.8 Configuring an Agent with Login ID 50001
A voice response port or a person who answers the Hunt-group calls is called an Agent. Each
Agent has a login ID (for example, 50001) and a password with which the Agent logs in at a
Station.
An Agent is a Communication Manager administered object that can receive calls from a Huntgroup as well as calls that are not related to any Hunt-group. Calls dialed directly to an
individual Agent using the Agent‟s login ID are called extension-in (EXT-IN) calls. Outgoing
calls that the Agent dials are called extension-out (EXT-OUT) calls. Both EXT-IN and EXTOUT calls are considered as non-Hunt-group calls.
In order to log in an Agent on the desired extension, the Agent needs to be configured on
Communication Manager.
Refer to Section A-2 for the steps to configure an Agent on Communication Manager and to
verify that the Agent is correctly configured. While running the application, it is assumed that
the Agent with login ID 50001 is already configured.
Once the Agent configuration is validated, the developer can proceed to the next step.
5.9 Editing the Agent.properties File
The Agent.properties file, as shown in Figure 26, contains the CTI (Computer Telephony
Integration) credentials such as CTILink (also known as advertised service name), CTIUserID,
and CTIUserPassword. The application will first read this file. Using these credentials and
parameters, a session is established between the application and AE Services server to access the
specified CTILink. These values must be updated with the correct CTI credentials in
accordance with either IPCoDE or AE Services server before running the application.
The Agent.properties file also contains default values for the Agent‟s ID, Password and
Extension.
The Agent.properties file, along with other application files, is provided in the config folder.
The file is copied into the Release folder when the project is built.
The settings shown in the file below are as per the IPCoDE environment; please modify the
settings as per the test environment.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
40 of 66
JTAPIAgentView
CTILink = AYAVA#CMSIM#CSTA#AESSIM
CTIUserID = Avaya
CTIUserPassword = Avayapassword@123
Stationed = 40010
AgentID = 50001
AgentPW = 50001
Figure 26: The Agent.properties file
5.10 Tracing
Both the JTAPI Client and AgentView application use log4j to generate traces. It is possible to
control the level of tracing as well as the format by editing log4j.properties in the config
folder. The file is copied into the Release folder when the project is built.
The default contents of log4j.properties are shown below:
log4j.rootCategory=WARN, ROOT_APPENDER
log4j.appender.ROOT_APPENDER=org.apache.log4j.ConsoleAppender
log4j.appender.ROOT_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.ROOT_APPENDER.layout.ConversionPattern=[%t] %m%n
log4j.logger.com.avaya.aes.agenttest.apicomms=debug
log4j.logger.com.avaya.aes.agenttest.callcontrol=debug
log4j.logger.com.avaya.aes.agenttest.ui=debug
Figure 27: The log4j.properties file
This means:

The output will appear on the Console.

The trace will show the Thread which was running and the trace message. The
information shown can be changed by altering the value for ConversionPattern.

The default trace level is warning. This means that, by default, very little trace will be
produced by any classes.

AgentView trace levels are set to debug. This means that all AgentView traces will
appear.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
41 of 66
JTAPIAgentView
5.11 Building and Executing the Application
Listed below are the steps for opening/building/executing this application:
Step 1:
Download the JTAPIAgentView.zip file from the DevConnect portal
(http://www.avaya.com/devconnect).
Step 2: Import
the application into the Eclipse workspace as described in the following steps.
a. Browse to File -> Import in the Eclipse window as shown in Figure 28.
Figure 28: Snapshot of the Import window
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
42 of 66
JTAPIAgentView
b. An Import wizard is launched. Select the import source as Existing Projects
into Workspace and click Next as shown in Figure 29
Figure 29: Selecting the Existing project into Workspace
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
43 of 66
JTAPIAgentView
c. Click Select archive file. Browse to the JTAPIAgentView.zip and click Finish
as shown in Figure 30
Figure 30: Snapshot of navigating to the saved Application location
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
44 of 66
JTAPIAgentView
Step 3:
Clean and build the project by browsing to Project and selecting the Clean option from
the list as shown in the screenshot in Figure 31.
Figure 31: Snapshot showing the Clean and Build operations
Step 4: Execute
the application from within Eclipse. The first time the application is run
requires some initial configuration.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
45 of 66
JTAPIAgentView
a. Browse to Run -> Run Configuration to start the Run configuration dialog as
shown in Figure 32.
Figure 32: Run Configuration Menu
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
46 of 66
JTAPIAgentView
b. Select Java Application and click the New button.
Figure 33: Run Configuration Dialog
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
47 of 66
JTAPIAgentView
c. Set the Name to AgentView. For the Main Class click Search…
Figure 34: Configure Application
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
48 of 66
JTAPIAgentView
d. The Main Class Search dialog will appear. Select AgentViewApp and click OK.
Figure 35: Main Class Selector
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
49 of 66
JTAPIAgentView
e. Select the Classpath tab, select User Entries and click Advanced…
Figure 36: Configure Classpath
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
50 of 66
JTAPIAgentView
f. Select Add Folders and click OK.
Figure 37: Advanced Options
g. Select the AgentView->config folder and click OK. This will add the
configuration files to the classpath.
Figure 38: Folder Selector
h. Click Run and the AgentView application will appear.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
51 of 66
JTAPIAgentView
6. Troubleshooting
This section explains how to troubleshoot the AgentView application under the various error
conditions listed out below:

When the Agent.properties file is missing from the required location, an error is thrown
as shown below:
Figure 39: Error message for missing Settings.ini file
This can be resolved by ensuring that the Agent.properties file is present in the same
folder where the application executable (Agent.bat) is present.

When the CTILink specified in the Agent.properties file is incorrect, the error message
shown below is thrown:
Figure 40: Unable to open ACS Stream error message
This can be resolved by ensuring that the Agent.properties file has the correct CTILink
value specified.

When either CTIUserID or CTIUserPassword is incorrect in the Agent.properties file,
the following error message pops up:
Figure 41: Invalid CTIUserID or CTIUserPassword error message
This can be resolved by correctly specifying the CTIUserID and CTIUserPassword.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
52 of 66
JTAPIAgentView

When the Station Extension is out of service, or the Agent ID/Agent password is wrong, or
if the Agent is already logged in, or there is already a call the station, the error message
shown below pops up:
Figure 42: Incorrect Station or Agent ID error message
This can be resolved by providing the correct Station Extension/Agent ID/Agent
Password, or by logging an Agent when the Station Extension is in the idle state.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
53 of 66
JTAPIAgentView
7. References
[1] AE Services JTAPI Programmer's Reference, Release 5.2, available on the DevConnect
portal at http://www.avaya.com/devconnect.
[2] Avaya Aura™ Application Enablement Services TSAPI and CVLAN Client and SDK
Installation Guide, Doc-ID 02-300543 Release 5.2 November 2009 Issue 6, available on the
DevConnect portal.
[3] Avaya Aura™ Application Enablement Services Administration and Maintenance Guide,
Release 5.2, Doc-ID: 02-300357, Issue 11, November 2009, available on the DevConnect
portal.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
54 of 66
JTAPIAgentView
Appendix A: Avaya Communication Manager Hunt-Groups
A-1 Configuring and validating the Hunt Group
To configure Hunt-Groups on Avaya Communication Manager:
a. Open the SAT Terminal of Communication Manager.
b. Use the command “add hunt-group 1” on the SAT terminal. A screen similar to Figure
43 will be shown.
c. Enter HuntGroup1 in the Group Name field.
d. Enter 49000 in the Group Extension field.
e. Change both the ACD and Vector values to “y”.
Figure 43: Configuring Hunt-group Extension on Communication Manager, Page 1
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
55 of 66
JTAPIAgentView
f. Press Esc+n to proceed to the next page. A screen similar to Figure 44 will be shown.
Figure 44: Configuring Hunt-group Extension on Communication Manager, Page 2
g. Change the Skill field to “y” and the Measured field to “internal”.
h. The default values for all the remaining settings are appropriate. Press Esc+e to save the
configuration. This will create the Hunt-group with extension 49000.
The Hunt-group extension 49000 is assigned to Hunt-group 1. This Hunt-group number 1 acts
as a skill number for the Agent.
To verifying the settings for the Hunt-Group are correctly set for this application, use the
“display hunt–group 1” command on the SAT terminal of Communication Manager and look
for the parameter ACD and Vector on page 1, and Skill and Measured on page 2. ACD,
Vector and Skill should have a value set to “y” as shown in Figure 45 and Figure 46.
Note: The user can give any other Hunt-group extension provisioned on Communication
Manager and as long as the configuration settings for the Hunt-group match what is
described here.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
56 of 66
JTAPIAgentView
Figure 45: Hunt-group parameters
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
57 of 66
JTAPIAgentView
Figure 46: Checking the „Skill‟ and „Measured‟ parameters on page 2
If these parameters are not set “y”, then use the “change hunt–group 1” command on the SAT
terminal of Communication Manager to change the parameters to “y”.
A-2 Configuring the Agent
Listed below are the steps to configure the Agent on Communication Manager:
a. Open the SAT Terminal of Communication Manager.
b. Use the command “add agent-Login 50001” on the SAT Terminal. A screen similar to
Figure 47 will be shown. (The user can choose any other extension as long as the
configuration settings for that extension match what is described here.)
c. Insert the Agent‟s name in the Name field. (Sample Agent is the name used here.)
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
58 of 66
JTAPIAgentView
Figure 47: Configuring Agent on Communication Manager, Page 1
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
59 of 66
JTAPIAgentView
d. Press Esc+n to proceed to the next page. A screen similar to Figure 48 will be shown.
Note: The Password field for the Agent is optional, but if password is configured for the
Agent, the same password must be entered while running the application.
Figure 48: Configuring Agent on Communication Manager, Page 2
e. Populate the SN (Skill Number) field with the Hunt-group Number, i.e., (as provisioned
earlier, and if Group Number of the Hunt-group is different then provide that number
here).
f. Provide the SL (Skill Level) for the Agent. For the purpose of running this application,
this value can be set to 1.
g. The default settings for all the remaining fields are appropriate. Press Esc+e to save the
configuration. This will create the Agent with login ID 50001.
To verify that the Agent is correctly configured for this application:
a. Open the SAT Terminal of Communication Manager.
b. Use the command “change agent-loginID 50001” on the SAT Terminal. A screen
similar to Figure 49 will be shown.
c. Check the Auto Answer field, which should be set to “station”. If this field is set to
some other value, then change this field to “station”.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
60 of 66
JTAPIAgentView
Figure 49: Verifying that Agent Station is correctly configured
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
61 of 66
JTAPIAgentView
d. Press Esc+n to move to the next page and look for the SN field, which should be set to
the Hunt-group number as provisioned above (“1” in this case). If this field is not set to
“1” or is empty, then set this value with the provisioned Hunt-group Number as shown in
Figure 50.
Figure 50: Checking the SN field on page 2
e. Press Esc+e to save the settings.
A-3 Configuring Station on Communication Manager
Listed below are the steps to configure Station on Communication Manager:
a. Open the SAT Terminal of Communication Manager.
b. Use the command “add station 40010” on the SAT Terminal. A screen similar to
Figure 51 will be shown. (The user can choose any other extension as long as the
configuration settings match what is described here.)
This extension will be used as the station (that is, Agent Terminal) where the Agent logs in and
receives and places the phone Calls. If IPCoDE is used, station 40010 is pre-configured with
these options.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
62 of 66
JTAPIAgentView
Figure 51: Configuring Station Extension on Communication Manager
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
63 of 66
JTAPIAgentView
c. Press Esc+n to proceed to the next page. A screen similar to Figure 52 will be shown.
Figure 52: Configuring Station Extension on Communication Manager, page 2
d. Change the Auto Answer field to “none”, in case it is set to some other value.
e. The default settings for all the remaining fields are appropriate. Press Esc+e to save the
configuration. This will create Station with Extension 40010.
To verify that the Station is correctly configured for this application:
a. Open the SAT Terminal of Communication Manager.
b. Use the command “change station 40010” on the SAT Terminal. A screen similar to
Figure 53 will be shown.
c. Check the Auto Answer field, which should be set to “none”. If this field is set to some
other value, then change it to “none”.
d. Press Esc+e to save the settings.
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
64 of 66
JTAPIAgentView
Figure 53: Page 2 of configuring Station on Communication Manager
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
65 of 66
JTAPIAgentView
©2010
Avaya Inc. All Rights Reserved.
Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by ® and ™
are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the
property of their respective owners. The information provided in these Application Notes is
subject to change without notice. The configurations, technical data, and recommendations
provided in these Application Notes are believed to be accurate and dependable, but are
presented without express or implied warranty. Users are responsible for their application of any
products specified in these Application Notes.
Please e-mail any questions or comments pertaining to these Application Notes along with the
full title name and filename, located in the lower right corner, directly to the Avaya DevConnect
Program at [email protected].
MF; Reviewed:
Solution & Interoperability Test Lab Application Notes
SPOC 6/28/2010
©2010 Avaya Inc. All Rights Reserved.
66 of 66
JTAPIAgentView