The purpose of this document is to assist Generic Connector client application developers in understanding the flow of messages between GC and GC-Client.
You’re expected to have a good understanding of JMS and broker-based communication using ActiveMQ. You should know what are Topics and Queues, what is the difference between them and how they can be used in different contexts. While you are exploring ActiveMQ, many questions arise in your mind and those are answered here.
Apache ActiveMQ is the most popular and powerful open-source messaging and Integration Patterns server.
Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, and comes with easy-to-use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License
First of all, download, install and run ActiveMQ Broker. You can find some samples on the ActiveMQ site. A basic Hello World program can be found here. You can find more complex examples here. All of these examples are implemented in Java. If you are writing clients in language other than Java, you can find examples in respective technology on the ActiveMQ site.
ActiveMQ supports different types of topologies for communication. GC is using Client-Server topology with TCP protocol for communication. You need to develop at least a simple application that communicates on given specifications.
Generic Connector Communication Architecture
<Make diagram here showing GC-Client, GC, AMQ, Finesse>
Describe a little bit about broker-based communication using AMQ
On which protocol and ports GC communicates with AMQ
The client is expected to subscribe on AMQ <Topic>Destination
GC listens on AMQ <Queue>Destination
A message broker is an intermediary program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. Message brokers are elements in telecommunication or computer networks where software applications communicate by exchanging formally-defined messages. Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, and comes with easy-to-use Enterprise Integration Patterns.
GC uses ActiveMQ as a message broker for communication. By default, GC communicates with AMQ on port 61616 (openwire) using tcp protocol. You can change port in AMQ configurations. GC listens on Queue “Connector1”, all the commands from the client should be published to Queue “Connector1” and GC replies on the Topic, specified by the client in Hello command.
GC communicates via AMQ that follows simple open text JMS messaging over OpenWire. A message could either be a request/command from the GC-Client or it could be an event/response sent by GC. In the rest of the document, the term “Command” is used to mention the message sent by the GC-client and the term “Event” is used to mention the message sent by GC.
Command Pattern
In a Command, JMS-Type contains the command and JMS-Body contains command arguments.
Commands are grouped into categories for the sake of clean and easier to interpret documentation.
If GC-Client receives System#IN_SERVICE, the GC is assumed to be connected and ready to listen on.
GC-Client should then send Heartbeats at defined intervals.
Note: If GC-Client doesn’t receive System#IN_SERVICE after CONNECT_TIMEOUT (Max. 3 seconds suggested) period, it should periodically keep sending the Hello command.
Agent State Transition
Agents can change their own states on finesse. If the request to change an agent's state is successful, the response is sent with updated state. Changing the state may cause CF_INVALID_OBJECT_STATE error. The state is not changed according to the transition diagram/table.
The following figure illustrates the supported state transitions by Unified CCE agents.
The following table describes supported agent state transitions for Unified CCE.
From
To
Description
*
UNKNOWN
If the agent state is unknown, the state is UNKNOWN. This scenario is unlikely.
LOGOUT
LOGIN
To sign in to Finesse, the agent sets the state to LOGIN. LOGIN is a transient state and transitions to NOT_READY.
LOGIN
NOT_READY
After a successful LOGIN, the agent transitions to NOT_READY.
NOT_READY
LOGOUT
To sign out of Finesse, the agent sets the state to LOGOUT. An agent can set the state to LOGOUT only if that agent is in NOT_READY state.
NOT_READY
NOT_READY
To change their Not Ready reason code, agents can set a NOT_READY state from NOT_READY.
NOT_READY
READY
To become available for incoming or Outbound Option calls, agents set their state to READY.
NOT_READY
TALKING
An agent who places a call while in NOT_READY state transitions to TALKING.
READY
RESERVED
An incoming call arrives at an agent.
READY
RESERVED _OUTBOUND
An outbound agent becomes reserved to handle an Outbound Option Progressive or Predictive call.
READY
RESERVED_OUTBOUND _PREVIEW
An outbound agent becomes reserved to handle an Outbound Option Preview call.
READY
NOT_READY
Agents can change to NOT_READY to make themselves unavailable for incoming calls.
RESERVED
READY
An agent can become RESERVED but never take a call.
RESERVED
TALKING
When an agent answers an incoming call, the agent transitions to TALKING.
RESERVED _OUTBOUND
READY
An agent can change to READY state to leave RESERVED_OUTBOUND. If the system deems it necessary, that agent may transition back to RESERVED_OUTBOUND.
RESERVED _OUTBOUND
NOT_READY
An agent can change to NOT_READY state to leave RESERVED_OUTBOUND.
RESERVED _OUTBOUND
TALKING
An agent transitions to TALKING when an Outbound Option call arrives at the agent.
RESERVED_OUTBOUND _PREVIEW
READY
An agent transitions to READY if the agent was in READY state before being reserved in an Outbound Option Preview campaign.
RESERVED_OUTBOUND _PREVIEW
NOT_READY
An agent transitions to NOT_READY if that agent changes state to NOT_READY while reserved in an Outbound Option Preview campaign. This state change is a pending state change. The agent does not transition to NOT_READY until the call is complete or the Outbound Option Preview reservation is closed or rejected.
RESERVED_OUTBOUND _PREVIEW
TALKING
An agent transitions to TALKING when an Outbound Option call arrives at the agent.
TALKING
READY
If an agent is on a call that is dropped, the agent transitions to READY (if the agent was in READY state before the call).
TALKING
NOT_READY
If an agent is on a call that is dropped, the agent transitions to NOT_READY if that agent was in NOT_READY state before the call.
TALKING
WORK
If wrap-up is enabled, and the agent chooses NOT_READY while on a call, that agent enters WORK state after the call is dropped.
TALKING
WORK_READY
If wrap-up is enabled, an agent enters WORK_READY state after a call is dropped.
TALKING
HOLD
An agent puts a call on hold and transitions to HOLD state.
HOLD
READY
If an agent is connected to a held call and the call is dropped, the agent transitions to READY state (if the agent was in READY state before the call).
HOLD
NOT_READY
If an agent is connected to a held call and the call is dropped, the agent transitions to NOT_READY state (if the agent was in NOT_READY state before the call).
HOLD
WORK
If wrap-up is enabled and an agent is connected to a held call that is dropped, the agent transitions to WORK state if the agent chose to go NOT_READY during the call.
HOLD
WORK_READY
If wrap-up is enabled and an agent is connected to a held call that is dropped, the agent transitions to WORK_READY state.
HOLD
TALKING
When an agent retrieves a held call, the agent transitions to TALKING state.
WORK
READY
To leave WORK state, agents can set their state to READY.
WORK
NOT_READY
To leave WORK state, agents can set their state to NOT_READY. Agents automatically transition to NOT_READY after the wrap-up timer expires.
WORK_READY
READY
To leave WORK_READY state, agents can set their state to READY. Agents automatically transition to READY after the wrap-up timer expires.
WORK_READY
NOT_READY
To leave WORK_READY state, agents can set their state to NOT_READY.
All Commands
Following is the list of all possible commands supported by GC. Each of the commands is explained with parameters supplied, events expected against the command and possible error that can occur for that particular command.
Note: While sending a command message, set the value for the property Time To Live for the message to a certain time(milliseconds), after the specified time that message/command will automatically discarded by AMQ. It needs to do so that the old command should not be processed.
GC supports synchronous requests. To achieve this, you need to send JMSCorrelationID along with the command, GC will send the same JMSCorrelationID with the event that corresponds to that particular command.
Set ReplyTo attribute of command message to the topic on which the client is subscribed to receive events.
Hello
Hello is the first command sent from Client to GC for handshake purpose. If GC replies with some event means that your connection with GC has been established and the client is able to send further commands to GC. If the client does not receive any response from GC, either GC is dead or command is not delivered to GC. Before sending a Hello command you should know on which topic the client will listen from GC. You need to create that topic on ActiveMQ explicitly and subscribe to it. Specify that particular topic in hello command as <Client_Destination> parameter. If client receives System#IN_SERVICE, you can supply further commands to GC (other than hello command). Normally, Connect and Login commands are sent after a successful handshake to GC in order to start your session (Make and receive calls). If client receives System#OUT_OF_SERVICE or no response from GC, keep sending hello command.
Command: Hello
JMS-Type
Hello#<Client_Destination>
JMS-Body
<Client_Destination>
A unique string (ActiveMQ Topic name) on which GC will send events to client. Client should subscribe on this Topic in order to receive the events.
Expected Event (s)
There can be two possible events:
System#IN_SERVICE: GC is connected to finesse and can process command. You can send further commands to GC.
System#OUT_OF_SERVICE: GC is not connected to finesse. Your commands will not be processed by GC. You are expected to send Hello command continuously until you didn’t receive System#IN_SERVICE.
Connect
Connect is the first formal command send to GC after receiving System#IN_SERVICE in response to Hello command. This command is used to subscribe the user for finesse notifications. If invalid credentials are provided, GC will reply with subscription errors. In the case of a successful subscription, GC will not reply with anything. The login command should be sent next to the Connect command without waiting for any response for the Connect command.
Command: Connect
JMS-Type
Connect#<agent_login_Id>
JMS-Body
<client_destination>,<agent_password>,<SSO> (We will pass SSO as a third parameter if the user is SSO Enabled, otherwise we will send two parameters as we are sending previously )
<agent_login_Id>
Agent login Id to log on to finesse.
<agent_password>
Agent password to log on to finesse.
<Client_Destination>
A unique string (ActiveMQ Topic name) on which GC will send events to client. Should be same as sent with Hello command.
The Login command is used to actually login to finesse. Remember that Connect command only subscribes the user for finesse notifications. Still the user is not logged in to the finesse to make and receive calls. Login command parameters are agent login id, password and extension that allows the agent to login to finesse desktop. In case of successful login, GC raises Agent Info, AgentState and Dialog state events. Now the agent will be able to make and receive calls on the client application.
Command: Login
JMS-Type
Login#<agent_login_Id>
JMS-Body
<agent_password>,<agent_extension>
<agent_login_Id>
Agent login Id to log on to finesse.
<agent_password>
Agent password to log on to finesse.
<agent_extension>
Agent extension used to make and receive calls from finesse
The Login command is used to actually login to finesse. Remember that Connect command only subscribes the user for finesse notifications. Still the user is not logged in to the finesse to make and receive calls. Login command parameters are agent login id, password and extension that allows the agent to login to finesse desktop. In case of successful login, GC raises Agent Info, AgentState and Dialog state events. Now the agent will be able to make and receive calls on the client application.
Heartbeats keep clients up to date about connectivity to GC. Client sends Heartbeat command and GC replies with a system status event. Purpose of Hello and Beat looks similar. But, hello establishes the connection between GC and client for the first time and Beat ensures the connectivity periodically after the connection is established successfully. Response of Hello and Beat is the same.
Command: Beat
JMS-Type
Beat#<Client_Destination>
JMS-Body
<Client_Destination>
ActiveMQ Topic name on which GC will reply to the client. The client should subscribe on this Topic in order to receive the events.
Expected Event (s)
There can be three possible events:
System#IN_SERVICE: GC is connected to finesse and can process command. You can send further commands to GC.
System#OUT_OF_SERVICE: GC is not connected to finesse. Your commands will not be processed by GC. You are expected to send Hello command continuously until you didn’t receive System#IN_SERVICE.
DESTINATION RECONNECT: Indicates that the <Client_Destination> is not present in GC. Need to send Connect and Login for all the agents available in the client's agent list.
Logout (Supervisor Command)
A Supervisor can change the agent's state to logout by sending Logout. Before sending the logout command, the agent must be in a state in which it can change its state to logout. See agent state transition.
Once an agent is logged into the system, if he wants to leave the system, it should logout explicitly. Before sending the logout command, the agent must be in a state in which it can change its state to logout. See agent state transition. Client can get the configured reason on finesse by sending Agent Logout Reason Codes
A Supervisor can change the agent's state to Not Ready by sending MakeNotReady. Before sending this command, the agent must be in a state in which it can change its state to NotReady. See agent state transition.
An agent can change its state to Not Ready by sending MakeNotReady. Many times changing state to NotReady requires reason code. Reason codes can be configured in Finesse. The reason code must be sent along this request in the JMS body. Before sending this command, the agent must be in a state in which it can change its state to Not Ready. See agent state transition. The client can get the configured reason on finesse by sending Agent Not Ready Reason Codes.
Command: MakeNotReadyWithReason
JMS-Type
MakeNotReadyWithReason#<agent_login_Id>
JMS-Body
<reason_code>
<agent_login_Id>
Login id of the agent needs to be logged out.
<reason_code>
Not Ready reason code. Must be defined in Finesse.
An agent can change its state to Ready by sending MakeReady. Before sending this command, the agent must be in a state in which it can change its state to Ready. See agent state transition.
If wrap-up is enabled, an agent enters WORK_READY state after a call is dropped. To leave WORK_READY state, agents can set their state to READY. Agents automatically transition to READY after the wrap-up timer expires. Before sending this command, the agent must be in a state in which it can change its state to Ready. See agent state transition.
If wrap-up is enabled, and the agent chooses NOT_READY while on a call, that agent enters WORK state after the call is dropped. To leave WORK state, agents can set their state to NOT_READY. Agents automatically transition to NOT_READY after the wrap-up timer expires. Before sending this command, the agent must be in a state in which it can change its state to Ready. See agent state transition.
This command allows a user to make a call. To make a call, a new Dialog object is created that specifies the <Extension_Number> (the destination target). The new Dialog object is posted to the Dialog collection for that user.
This command allows a user to answer a call. To answer a call, a new Dialog object is created that specifies the <Dialog_ID> received in NEW INBOUND Call event .
This command allows a user to drop a call. To drop a call, a new Dialog object is created that specifies the <Dialog_ID> received in INBOUND CALL ACTIVE event.
This command allows a user to hold a call. To hold a call, a new Dialog object is created that specifies the <Dialog_ID> received in INBOUND CALL ACTIVE event.
Note: This Command is only supported for UCCE. UCCX does not send the hold event in response to this command.
Retrieve a Call
This command allows a user to unhold a call. To unhold a call, a new Dialog object is created that specifies the <Dialog_ID> received in INBOUND CALL ACTIVE event.
This command allows a user to initiate a consult call with other agent. Once the call is accepted by the other agent, the user can either transfer this call to the other agent or can initiate the conference call between all parties.
This command allows a user to transfer the customer call to the consulted agent. This will drop the consult call between agents and transfer the customer call to the other agent.
Command: TransferCall
JMS-Type
TransferCall#<agent_login_Id>
JMS-Body
<Agent_Extension>,<Dialog_ID>
<agent_login_Id>
Login id of the agent.
<Dialog_ID>
ID of new inbound call (Main Call Dialog Id)
<Agent_Extension>
Extension of the agent. (Extension of the 2nd agent)
While a call is active, the client can get the state of that particular dialog by sending GetDialogState command. Dialog state event will update the current state of the dialog.
We have an API that returns all the PhoneBooks and contacts related to an Agent as well as Global Type but we are not using it right now as we decided first we will implement the flow of commands as mentioned below
This command will get a list of skill groups from the database
Command: SkillGroup
JMS-Type
GETSKILLGROPU#<agent_login_id>
JMS-Body
<agent_login_Id>
Login ID of the agent.
Expected Event (s)
Possible Error (s)
Get Supervisors List (Only for UCCE)
This command will get a list of supervisors from the database
Command: supervisors
JMS-Type
GETSUPERVISOR#<agent_login_id>
JMS-Body
<agent_login_Id>
Login ID of the agent.
Expected Event (s)
Possible Error (s)
Callback
Callbacks
Regular Callbacks
Any agent who is assigned to the campaign can handle regular callbacks.
Personal Callbacks
Only an agent who dealt with the original call can set a personal callback. The dialer offers the agent the personal callback using a mode similar to the Preview dialing mode.
Personal callback supports three callback modes:
Use Campaign DN
If the agent is unavailable at the callback time, Outbound Option reserves another agent for the callback using the dialed number of the associated campaign skill group.
If an alternate agent is also unavailable from the Campaign DN script, the retry action is No Answer.
Reschedule the personal callback to the same time the next business day or Abandon the personal callback.
If the agent is logged in at any point during the callback period, Outbound Option reserves the agent and places the callback.
If the agent is unavailable during the entire callback period, the personal callback fails. The call is rescheduled or abandoned based on the configuration setup.
this configuration will be done at the campaign management side, we will only schedule a callback
Can we schedule a callback again on callback?
Yes, we can schedule a callback again on the callback.
Schedule a callback call
This command will schedule a campaign callback call
System#IN_SERVICE is the event that a client connected to GC receives frequently. Normally it is the response of Hello or Beat commands. It indicates that the GC is connected to Finesse and can perform actions in response to the command.
Event: System#IN_SERVICE
JMS-Type
NULL
JMS-Body
System#IN_SERVICE
Event Category
System
System#OUT_OF_SERVICE
Normally it is the response of Hello or Beat commands. It indicates that the GC is not connected to Finesse and unable to perform action in response to the commands. After sending this event, GC will stop receiving further commands from clients. Client should send Hello until it didn’t receive System#IN_SERVICE.
Event: System#OUT_OF_SERVICE
JMS-Type
NULL
JMS-Body
System#OUT_OF_SERVICE
Event Category
System
DESTINATION RECONNECT
GC replies to Heartbeat commands with System#<System_Status> if the destination is already present in GC. If the destination specified by Heartbeat is not present in GC, GC replies with this event. In response to this event, the client should send Connect and Login for all the agents available in the client's agent list.
Event: DESTINATION
JMS-Type
NULL
JMS-Body
DESTINATION#<Destination_Name>#RECONNECT
<Destination_Name>
Client destination on which GC will reply to client.
Event Category
Destination
CallBack Scheduled
We will send this event to the Client after successfully scheduling a callback.
Event: Callback
JMS-Type
NULL
JMS-Body
CallBack#<CallBack>
Event Category
Info
AgentInfo
AgentInfo event contains the basic information of the agent. Like, Agent’s first name, last name, wrapup mode, is this agent has supervisor rights and agent’s full name. GC sends this event only when the agent logged in successfully to the finesse. This event will never be sent again in a session.
Is this agent has the role of Supervisor. True | False
teams
it's a list of all teams. Each element is a team object as defined below.
team_id
id of the team
team_name
name of the team
<wrap_up_mode>
Configured wrapup mode for agent.
Allowed values for wrap_up mode are:
OPTIONAL
REQUIRED
NOT_ALLOWED
REQUIRED_WITH_ WRAP_UP_DATA
Event Category
agent_info
AgentState
AgentState describes the current state of the agent on finesse. Normally GC sends this event when the agent state is changed on finesse or in response to the GetState command from the client.
Reason code for state change. In case of LOGOUT and NOT_READY for the first time it will be -1. After that whenever you change state with reason code, that reason code will be sent along. In case of ready, it will be empty.
<agent_full_name>
name of the agent
<agent_login_Id>
login id of the agent
<agent_Extension>
login extension of the agent
<agent_StateChangeReasonLabel>
Label of any state change
Event Category
agent_state
State#RE_LOGIN
RE_LOGIN is a special case. It occurs when GC receives command from a client for a particular agent which is not present in GC. In this case, the client needs to send the Connect and Login commands again.
DialogStatus
When an agent login, GC explicitly gets the list of active dialogs of the agent and sends it. GC gets the list of dialogs for each agent upon failover. If there is any dialog active, even any dialog is associated with active dialog for the agent, GC will send detailed dialog status event to the particular agent. If there is no active dialog for an agent, GC will send DialogStatus###.
ID of dialog associated with the dialog of the agent.
Event Category
agent_state
Reason Codes
The ReasonCode object represents a reason code that can be applied when an agent changes state. There are two categories of reason codes: not ready reason codes and sign out reason codes.
Administrators can use either the ReasonCode APIs or the Finesse administration console to configure not ready and sign out reason codes. When using the APIs to configure reason codes, the administrator specifies the category of reason code in the request (NOT_READY or LOGOUT).
An additional reason code category is Wrap-up reason. The WrapUpReason object represents a reason that an agent can apply to a call during call wrap-up. WrapUp has only reason labels. There are no codes associated with the labels.
Labels for each code. <code_1> corresponds to <label_1>
Event Category
agent_work
Inbound Call State
This event is fired when GC receives an update about dialog from finesse for an inbound call. It is sent along with dialog id as multiple dialogs can be present simultaneously at a time. “#DialogID:<dialog_ID>” is only sent in case of (Failed,Dropped,Deleted,Hold.Held,Wrap_up). <Inboundcall_current_state> will be equal “DROP” in case of (Failed,Dropped,Deleted)
Call variable values are sent comma separated. Call variable names are not being sent.
<start_time>
start time of the call
<call_type>
call type
In Silent Monitoring the call type (at Agent & Supervisor) will be
SUPERVISOR_MONITOR (SM)
<Failure_Cause>
Cause of Dialog failure. Only in the case of State=Failed
Event Category
agent_dialog
New Inbound Call
This event occurs when an incoming call is ringing for the agent. This event specifies from address, call variables and dialog id for the agent. Client needs to activate the control for accepting or rejecting the call.
Call variable values are sent comma separated. Call variable names are not being sent.
<start_time>
start time of the call
<call_type>
call type
In Silent Monitoring the call type (at Agent & Supervisor) will be
SUPERVISOR_MONITOR (SM)
Event Category
agent_dialog
DialogState
While a call is active, the client can get the state of that particular dialog by sending GetDialogState command. Dialog state event represents the current state of the dialog.
This event informs the client about the current state of consult call for an agent. <associated_dialog_ID> denotes the id of associated dialog whose state is being sent.
Call variable values are sent comma separated. Call variable names are not being sent.
Event Category
agent_dialog
Supervisor Team Info(IDs) [Supervisor Event]
Informs a Supervisor agent about its team. It consists of the ID’s of all the teams assigned to the supervisor agent. This event is only available for supervisor agents.
Informs a Supervisor agent about its team. It consists of names of all the teams (comma separated) assigned to the supervisor agent. This event is only available for supervisor agents.
Informs a supervisor about its Queue. This event comes with the Queue Name, Calls in Queue, no of calls in queue, No of agents with their states. This is a supervisor only event.
Sometimes it needs to display some messages in the agent's windows. This event helps to achieve this objective. GC sends a message that should display directly in the agent's window.
All the possible errors are listed below with the suggested action on the client side. You can display friendly messages against these messages on the client end. Error origin is mentioned with each error that helps the developer to debug the issue.
SUBSCRIPTION_FAILED
This error occurs when GC tries to get a subscription of an agent with supplied credentials and those credentials are invalid.
Error: SUBSCRIPTION_FAILED
JMS-Type
NULL
JMS-Body
<Error_For>#Error#SUBSCRIPTION_FAILED
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Invalid credentials supplied for agent login
Expected Client’s Behaviour
Display the error message and ask the agent to enter valid credentials and send the command again.
UNABLE_TO_SUBSCRIBE_TO_FINESSE
This error occurs when GC tries to get a subscription of an agent with supplied credentials and those credentials are invalid. Same as SUBSCRIPTION_FAILED.
Error: UNABLE_TO_SUBSCRIBE_TO_FINESSE
JMS-Type
NULL
JMS-Body
<Error_For>#Error#UNABLE_TO_SUBSCRIBE_TO_FINESSE
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Invalid credentials supplied for agent login
Expected Client’s Behaviour
Display the error message and ask the agent to enter valid credentials and send the command again.
SESSION_INVALIDATED
Sometimes user requests connect from a new destination while he is already logged in from an older destination and his session is active. In such cases, GC will send this error to the older destination and process the connect request from the new destination. AgentState LOGOUT immediately after this error.
Error: SESSION_INVALIDATED
JMS-Type
NULL
JMS-Body
<Error_For>#Error#SESSION_INVALIDATED
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
The current session session for user has been invalidated, user has been logged in from a new destination. GC will send a logout message followed by this message
Expected Client’s Behaviour
Display the error message and ask the user to login again.
LICENSES_EXCEEDED
No. of simultaneous logged in users exceed to the allowed users in license.
Error: LICENSES_EXCEEDED
JMS-Type
NULL
JMS-Body
<Error_For>#Error#LICENSES_EXCEEDED
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
User license limit exceeded
Expected Client’s Behaviour
Display the error message.
MISSING_EXTENSION
Extension is missing in request.
Error: MISSING_EXTENSION
JMS-Type
NULL
JMS-Body
<Error_For>#Error#MISSING_EXTENSION
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Extension is missing in request.
Expected Client’s Behaviour
Display the error message and ask the user to enter valid Extension. Send the request again.
WRONG_EXTENSION
Extension provided in request contains alphabetic characters.
Error: WRONG_EXTENSION
JMS-Type
NULL
JMS-Body
<Error_For>#Error#WRONG_EXTENSION
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Extension is not valid (contains alphabetic characters)
Expected Client’s Behaviour
Display the error message and ask the user to enter valid Extension. Send the request again.
MISSING_PASSWORD
Password is missing in the request. The request should be sent along with the password.
Error: MISSING_PASSWORD
JMS-Type
NULL
JMS-Body
<Error_For>#Error#MISSING_PASSWORD
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Password is missing in request
Expected Client’s Behaviour
Display the error message and ask the user to enter a password. Send the request again.
USER_NOT_FOUND
Agent ID isn't found in Finesse.
Error: USER_NOT_FOUND
JMS-Type
NULL
JMS-Body
<Error_For>#Error#USER_NOT_FOUND
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Finesse
Error Summary
Agent ID isn't found in Finesse
Expected Client’s Behaviour
Display the error message and ask the user to enter valid credentials. Send the request again.
GENERAL_ERROR
When the root cause of error is unclear. This error is sent only for the Login command.
Error: GENERAL_ERROR
JMS-Type
NULL
JMS-Body
<Error_For>#Error#GENERAL_ERROR
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Finesse
Error Summary
When the root cause of error is unclear.
Expected Client’s Behaviour
Display the error message and send the request again.
CF_GENERIC_UNSPECIFIED
When the root cause of error is unclear. No specific details available. Can occur at any command.
Error: CF_GENERIC_UNSPECIFIED
JMS-Type
NULL
JMS-Body
<Error_For>#Error#CF_GENERIC_UNSPECIFIED
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Finesse
Error Summary
Root cause of the error is unclear. No specific details available
Expected Client’s Behaviour
Display the error message and send the request again.
GC/Finesse expects reason-code that wasn't provided by the client.
Error: MISSING_REASON_CODE
JMS-Type
NULL
JMS-Body
<Error_For>#Error#MISSING_REASON_CODE
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
GC/Finesse expects reason-code that wasn't provided by the client
Expected Client’s Behaviour
Send the request again with reason codes.
MISSING_DIALOG_ID
Dialog ID is missing in request.
Error: MISSING_DIALOG_ID
JMS-Type
NULL
JMS-Body
<Error_For>#Error#MISSING_DIALOG_ID
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Dialog id is missing in request
Expected Client’s Behaviour
Send the request again with dialog id.
MISSING_NUMBER
Number to dial is missing in request
Error: MISSING_NUMBER
JMS-Type
NULL
JMS-Body
<Error_For>#Error#MISSING_NUMBER
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Generic Connector
Error Summary
Number to dial is missing in request
Expected Client’s Behaviour
Send the request again with dialog id.
E_CTI_INVALID_CALL_ID
A request message was received with an invalid CallID value.
Error: E_CTI_INVALID_CALL_ID
JMS-Type
NULL
JMS-Body
<Error_For>#Error#E_CTI_INVALID_CALL_ID
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Finesse
Error Summary
A request message was received with an invalid CallID value.
Expected Client’s Behaviour
Send the request again with a valid call id.
CF_GENERIC_OPERATION
An operation error occurred (no specific details available).
Error: CF_GENERIC_OPERATION
JMS-Type
NULL
JMS-Body
<Error_For>#Error#CF_GENERIC_OPERATION
<Error_For>
Possible values are:
<Agent_ID>
<Supervisor_ID>
Error Origin
Finesse
Error Summary
An operation error occurred (no specific details available).
Expected Client’s Behaviour
Display error message according to the last command sent.
INVALID_CALL_DATA
A request message was received with invalid parameters.
Error: CF_GENERIC_OPERATION
JMS-Type
NULL
JMS-Body
<Error_For>#Error#INVALID_CALL_DATA
<Error_For>
Possible values are:
<dialog_id>
<variable_name>
<variable_value>
Error Origin
Generic Connector
Error Summary
Parameters missing in the request body.
Expected Client’s Behaviour
Display error message according to the last command sent.
# Symbol Handling
Note
We will send # Binary number in case we recieve # in following events.
Global and Team Phone Books Event
Team Phone Books Event
Phone Book Contacts Event
State Change Event
Team State change Event
Team User List Event
Call Vrariables
Appendix 1
This table lists down the default variables in CISCO finesse desktop layout. However, administrators can define the custom variables as well. For details refer to this manage call variables layout guide.
Label
Variable Name
Call Variable 1
callVariable1
Call Variable 2
callVariable2
Call Variable 3
callVariable3
Call Variable 4
callVariable4
Call Variable 5
callVariable5
Call Variable 6
callVariable6
Call Variable 7
callVariable7
Call Variable 8
callVariable8
Call Variable 9
callVariable9
Call Variable 10
callVariable10
BA Account Number
BAAccountNumber
BA Buddy Name
BABuddyName
BA Campaign
BACampaign
BA Customer Number
BACustomerNumber
BA Dialed ListID
BADialedListID
BA Response
BAResponse
BA Status
BAStatus
BA TimeZone
BATimeZone
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.
