...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Table of Contents
Abbreviations
Short Name | Full Name |
GC | Generic Connector |
GC-Client | Generic Connector Client Application |
AMQ | ActiveMQ |
Finesse | Cisco Finesse |
Introduction
Purpose of this document
The purpose of this document is to assist Generic Connector client applications developers to understand the flow of messages between GC and GC-Client.
New In This Release
For new features in the 4.0 release, see the Generic Connector Install Guide V 4.0.
Before You Start
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.
...
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>
...
For more about GC deployment models, see Generic Connector Installation Guide.
What comes with the package?
GC installer comes with a preconfigured AMQ, GC and EF Service Manager. EF Service Manager is a mini tool to manage AMQ and GC services.
Environment and Tools
GC requires Java Runtime 8 to run. Download and install Java Runtime Environment 8 from here.
...
For more about setting up GC, see Generic Connector Installation Guide.
Message Pattern
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.
...
- <Command> is any of the supported commands. See All Commands
- <Agent_ID> is the agent’s login ID
- <Client_Destination> is the ActiveMQ topic which GC-client is subscribed on. On this AMQ Topic, GC will send all events to GC-Client
- In the JMS-Body, NULL represents an empty string and NOT a “NULL” string. If no command argument is needed, set the value to an empty string.
- Multiple Command arguments are mentioned in a comma-separated string.
Event Pattern
An Event is a message sent by GC in response to any command or it can be an async message representing a real-time System or Finesse event.
...
- JMS-Type carries nothing (An empty String)
- JMS-Body contains the complete event
- <Argument-N> represents event arguments. Event Arguments are separated by #
Error Pattern
If any command from client encountered by some error, GC will event contains error details.
Error Event Pattern | |
JMS-Type | NULL |
JMS-Body | <Error_For>#Error#<Error Details> |
<Error_For> | Possible values are:
|
<Error Details> | Details about error. See All Errors |
Client Communication Use Cases
There may be 2 type of GC-Clients:
- Desktop client - running one instance per agent like MS-CRM USD Client
- Server client - moderating and communicating on behalf of multiple agents per server as in the case of Siebel SCAPI Driver, SAP IC, etc.
Establish Connection
The client application must ensure proper establishment of connection with GC before invoking any agent operations.
...
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.
...
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.
...
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. |
| <SSO> | will pass SSO if user is SSO Enabled |
Expected Event (s) | |
Possible Error (s) | Two error are possible: |
Login
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 |
Expected Event (s) | Three events will be sent: |
Possible Error (s) | Following errors are possible: |
Mobile Agent Login
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: Mobile Agent Login | |
JMS-Type | MOBILEAGENTLOGIN#<agent_login_Id> |
JMS-Body | <agent_password>,<agent_extension>,<dialNumber>,<connection_mode> |
<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 |
| <dialNumber> | The phone number that the system calls to connect with the mobile agent |
| <connection_mode> | The connection mode for the call (connection mode to “true” for “call by call”, “false” for “nailed connection”.) |
Expected Event (s) | Three events will be sent: |
Possible Error (s) | Following errors are possible: |
Heartbeats
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.
Command: Logout | |
JMS-Type | Logout#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent need to be logout. |
Expected Event (s) | |
Possible Error (s) | |
LogoutWithReason
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
Command: logoutwithreason | |
JMS-Type | logoutwithreason#<agent_login_Id> |
JMS-Body | <reason_code> |
<agent_login_Id> | Login id of the agent needs to be logged out. |
<reason_code> | Logout reason code. Must be defined in Finesse. |
Expected Event (s) | |
Possible Error (s) | |
GetState
GetState command sends the user's current state on the finesse.
Command: GetState | |
JMS-Type | GetState#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
MakeNotReady (Supervisor Command)
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.
Command: MakeNotReady | |
JMS-Type | MakeNotReady#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
MakeNotReadyWithReason
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. |
Expected Event (s) | |
Possible Error (s) | |
MakeReady
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.
Command: MakeReady | |
JMS-Type | MakeReady#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Make WorkReady
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.
Command: MakeWorkReady | |
JMS-Type | MakeWorkReady#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Make WorkNotReady
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.
Command: MakeWorkNotReady | |
JMS-Type | MakeReady#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Make a Call
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.
Command: MakeCall | |
JMS-Type | MakeCall#<agent_login_Id> |
JMS-Body | <Extension_Number> |
<agent_login_Id> | Login id of the agent. |
<Extension_Number> | Extension of the other agent. |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
Answer a Call
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 .
Command: AnswerCall | |
JMS-Type | AnswerCall# <agent_login_Id> |
JMS-Body | <Dialog_ID> |
<agent_login_Id> | Login id of the agent. |
<Dialog_ID> | ID of new inbound call |
Expected Event (s) | The following events will arrive in a sequence: |
Possible Error (s) | |
Release a Call
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.
Command: ReleaseCall | |
JMS-Type | ReleaseCall# <agent_login_Id> |
JMS-Body | <Dialog_ID> |
<agent_login_Id> | Login id of the agent. |
<Dialog_ID> | ID of new inbound call |
Expected Event (s) | The following events will arrive in a sequence: |
Possible Error (s) | |
Hold a Call (UCCE Only)
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.
Command: ReterieveCall | |
JMS-Type | RetrieveCall# <agent_login_Id> |
JMS-Body | <Dialog_ID> |
<agent_login_Id> | Login id of the agent. |
<Dialog_ID> | ID of new inbound call |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
Blind Transfer
This command allows a user to transfer the call blindly without waiting for the other agent to receive the call.
Command: BlindTransfer | |
JMS-Type | Transfer_sst# <agent_login_Id> |
JMS-Body | <Other_Party_Extension_Number>,<Dialog_ID> |
<agent_login_Id> | Login id of the agent. |
<Dialog_ID> | ID of new inbound call |
<Other_Party_Extension_Number> | Extension of the other agent. |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
Consult Call
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.
Command: CosultCall | |
JMS-Type | ConsultCall#<agent_login_Id> |
JMS-Body | <Other_Party_Extension_Number>,<Dialog_ID> |
<agent_login_Id> | Login id of the agent. |
<Dialog_ID> | ID of new inbound call |
<Other_Party_Extension_Number> | Extension of the other agent. |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
Consult Transfer
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) |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
Conference Call
This command allows a user to initiate the conference call with the customer and the consulted agent.
Command: ConferenceCall | |
JMS-Type | Conferencecall#<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) |
Expected Event (s) | The following events will arrive: |
Possible Error (s) | |
GetDialogState
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.
Command: GetDialogState | |
JMS-Type | GetDialogState#<agent_login_Id> |
JMS-Body | <Dialog_Id> |
<agent_login_Id> | Login id of the agent. |
<Dialog_Id> | Id of Dialog whose state update is needed. |
Expected Event (s) | |
Possible Error (s) | |
Agent Logout Reason Codes
Logout reason codes represent reasons that agents can select when they change their state to logout.
Command: reasoncodelogout | |
JMS-Type | reasoncodelogout#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Agent Not Ready Reason Codes
Not Ready reason codes represent reasons that agents can select when they change their state to Not Ready.
Command: reasoncodenotready | |
JMS-Type | reasoncodenotready#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Agent Wrap-up Reasons
The Wrap Up Reasons represents a reason that an agent can apply to a call during call wrap-up.
Command: wrapupreasoncode | |
JMS-Type | wrapupreasoncode#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login id of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Update Dialog Wrap-up Reason
The Wrap Up Reason code represents a reason that an agent can apply to a call during call wrap-up.
Command: wrapup | |
JMS-Type | wrapup#<agent_login_Id> |
JMS-Body | <Wrapup_Reason>,<dialog_id> |
<agent_login_Id> | Login id of the agent. |
<dialog_id> | Id of dialog for which Wrap-Up code needs to be updated. |
<Wrapup_Reason> | The reason to be updated for the dialog |
Expected Event (s) | |
Possible Error (s) | |
Update Call Variable Data
This command allows a user to set or change call variables (including named variables or ECC variables) on a dialog.
Command: Update Call Variable | |
JMS-Type | update_call_variable#<agent_login_Id> |
JMS-Body | <dialog_id>,<variable_name>=<variable_value>| <variable_name>=<variable_value>.... |
<agent_login_Id> | Login id of the agent. |
<dialog_id> | Id of dialog for which variable needs to be updated. |
<variable_name> | The name of the variable to be updated. See Appendix 1 for variable names details |
<variable_value> | This value of the variable. |
Expected Event (s) | |
Possible Error (s) | |
Get Agents List
This command allows an admin user to get the list of all logged-in users.
...
| Note | ||
|---|---|---|
| ||
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 |
Get Team and Global Phonebooks
This command will get the global and team phonebooks for the agent
Command: Get_Phonebooks | |
JMS-Type |
|
JMS-Body | |
<agent_login_Id> | Login ID of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Get PhoneBook Contacts
This command will get the contacts of a specific phonebook
Command: Get_Phonebook_Contacts | |
JMS-Type |
|
JMS-Body | <PhonebookID> |
<agent_login_Id> | Login ID of the agent. |
| <PhonebookID> | The ID of the phonebook whose contacts are required |
Expected Event (s) | |
Possible Error (s) | |
Get Team PhoneBook
This command will get the phonebook of a specific team
Command: Get_Phonebook_Contacts | |
JMS-Type | |
JMS-Body | <TeamID> |
<agent_login_Id> | Login ID of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Get Queue Info
This command will get the list of Queues with all detail in a Queue
Command: Get_Queue_Info | |
JMS-Type | getqueuelist#<agent_login_Id> |
JMS-Body | |
<agent_login_Id> | Login ID of the agent. |
Expected Event (s) | |
Possible Error (s) | |
Silent Monitor (Supervisor Function)
This command will start silent monitoring of Supervisor team members
Command: Silent_Monitor | |
JMS-Type | silentmonitor#<agent_login_Id> |
JMS-Body | <Agent_Extension> |
<agent_login_Id> | Login ID of the agent. |
| <Agent_Extension> | Extension of the Agent |
Expected Event (s) | On Supervisor On Agent |
Possible Error (s) | |
End Silent Monitor (Supervisor Function)
This command will end silent monitoring of Supervisor team members
Command: End_Silent_Monitor | |
JMS-Type | endsilentmonitor#<agent_login_Id |
JMS-Body | <Dialog_ID> |
<agent_login_Id> | Login ID of the agent. |
| <Dialog_ID> | Id of dialog for which need to end silent monitoring |
Expected Event (s) | On Supervisor On Agent |
Possible Error (s) | |
Drop Participant (Supervisor Function)
This command will drop participant from call
Command: Drop_Participant | |
JMS-Type | dropparticipant#<agent_login_Id> |
JMS-Body | <Agent_Extension>,<Dialog_ID> |
<agent_login_Id> | Login ID of the agent. |
| <Agent_Extension> | Extension of the Agent |
| <Dialog_ID> | Id of dialog for which need to be drop |
Expected Event (s) | On Supervisor On Agent |
Possible Error (s) | |
Get Team Users (Supervisor Function)
This command will get team user and subscribe for team events
Command: Get_Team_Users | |
JMS-Type | getteamusers#<agent_login_Id> |
JMS-Body | <TeamID>,<true> |
<agent_login_Id> | Login ID of the agent. |
<TeamID> | The ID of the team which we want to get |
<true> | Pass true if you want to subscribe for team events |
Expected Event (s) | |
Possible Error (s) | |
Make a Barge Call (Supervisor Function)
This command will allow the supervisor to Barge In a call
Command: BargIn_Call | |
JMS-Type | bargein#<agent_login_Id> |
JMS-Body | <Team_Agent_Extension>,<Dialog_ID> |
<agent_login_Id> | Login ID of the agent. |
| <Team_Agent_LoginID> | ID of team agent which we want to bargeIn |
| <Dialog_ID> | Id of dialog |
Expected Event (s) | On Supervisor
On Agent |
Possible Error (s) | |
Get Team Users State (Supervisor Function)
This command will get Team user state
Command: BargIn_Call | |
JMS-Type | getteamuserstate#<agent_login_Id> |
JMS-Body | <Team_Agent_LoginID> |
<agent_login_Id> | Login ID of the agent. |
| <Team_Agent_LoginID> | ID of team agent which we want to bargeIn |
Expected Event (s) | |
Possible Error (s) | |
Accept Outbound Preview Call
This command will accept the outbound preview call
Command: Accept_Outbound_Call | |
JMS-Type | AcceptOutboundPreview#<agent_login_id> |
JMS-Body | <dialog_id>,<ACCEPT> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <ACCEPT> | String parameter |
Expected Event (s) | Before Call Accepted After Call Accepted |
Possible Error (s) | |
Reject Outbound Preview Call
This command will reject the outbound preview call
Command: BargIn_Call | |
JMS-Type | RejectOutboundPreview#<agent_login_id> |
JMS-Body | <dialog_id>,<REJECT> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <REJECT> | String parameter |
Expected Event (s) | |
Possible Error (s) | |
Close Outbound Preview Call
This command will close the outbound preview call
Command: BargIn_Call | |
JMS-Type | CloseOutboundPreview#<agent_login_id> |
JMS-Body | <dialog_id>,<CLOSE> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <CLOSE> | String parameter |
Expected Event (s) | |
Possible Error (s) | |
Get Skill Group (Only for UCCE)
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) | |
| Note | ||
|---|---|---|
| ||
CallbacksRegular 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:
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
Command: Schedule_callback_Call | |
JMS-Type | SHCEDULECALLBACK#<agent_login_id> |
JMS-Body | <targetMediaAddress>,<dialog_id>,<callbackTime>,<callbackNumber> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | The ID of the dialog |
| <targetMediaAddress> | The extension of the agent who is making the request |
| <callbackTime> | callback time |
| <callbackNumber> | callback number |
Expected Event (s) | |
Possible Error (s) | |
Update a callback call
This command will update a campaign callback call
Command: Update_callback_Call | |
JMS-Type | UPDATECALLBACK#<agent_login_id> |
JMS-Body | <targetMediaAddress>,<dialog_id>,<callbackTime>,<callbackNumber> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | The ID of the dialog |
| <targetMediaAddress> | The extension of the agent who is making the request |
| <callbackTime> | callback Time |
| <callbackNumber> | callback Number |
Expected Event (s) | |
Possible Error (s) | |
Cancel a Schedule callback Call
This command will cancel the scheduled callback call
Command: cancel_scheduled_Call | |
JMS-Type | CANCELSHCEDULECALLBACK#<agent_login_id> |
JMS-Body | <targetMediaAddress>,<dialog_id> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <targetMediaAddress> | The extension of the agent who is making the request |
Expected Event (s) | |
Possible Error (s) | |
Reclassify a Direct Preview Call
This command will reclassify an outbound direct preview call
Command: Reclassify _Call | |
JMS-Type | RECLASSIFYCALL#<agent_login_id> |
JMS-Body | <targetMediaAddress>,<dialog_id>,<Value> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | The ID of the dialog |
| <targetMediaAddress> | The extension of the agent who is making the request |
| <Value> | Reclassify value |
Expected Event (s) | |
Possible Error (s) | |
...
| Note | ||
|---|---|---|
| ||
We will use the same commands as we are using to accept direct preview calls and reject direct preview calls for accept and reject personal callback. we are just highlighting there for personal callback but we will use already implemented commands for direct preview campaign call |
Accept Personal Callback Call
This command will accept the personal callback call
Command: Accept_Outbound_Call | |
JMS-Type | AcceptOutboundPreview#< |
JMS-Body | <dialog_id>,<ACCEPT> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <ACCEPT> | String parameter |
Expected Event (s) | In UCCE Before Call Accepted After Call Accepted
In UCCX Before Call Accepted After Call Accepted |
Possible Error (s) | |
Reject Personal Callback Call
This command will reject the personal callback Call
Command: Reject_Outbound_Call | |
JMS-Type | RejectOutboundPreview#< |
JMS-Body | <dialog_id>,<REJECT> |
<agent_login_Id> | Login ID of the agent. |
| <dialog_id> | Id of dialog |
| <REJECT> | String parameter |
Expected Event (s) | |
Possible Error (s) | |
All Events
System#IN_SERVICE
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.
Event: AgentInfo | |
JMS-Type | NULL |
JMS-Body | For Agent <agent_login_Id>#AgentInfo#<agent_first_name>#<agent_last_name>#<Is_Supervisor>#<wrap_up_mode>#<agent_teamId>#<agent_full_name>#<agent_login_name> For Supervisor <agent_login_Id>#AgentInfo#<agent_first_name>#<agent_last_name>#<Is_Supervisor>#<wrap_up_mode>#TotalNumberOfTeams:TeamsCount#<team_1_id><team_1_name>|<team_2_id><team_2_name>#<agent_teamId>#<agent_full_name>#<agent_login_name> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<agent_first_name> | Agent’s First Name |
<agent_last_name> | Agent’s Last Name |
<Is_Supervisor> | 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:
|
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.
Event: State | |
JMS-Type | NULL |
JMS-Body | <agent_login_Id>#State#<agent_current_state>#<resonCodeId>#<agent_StateChangeTimeString>#<agent_PendingState>#<agent_StateChangeTime>#<agent_full_name>#<agent_login_Id>#<agent_Extension>#<agent_StateChangeReasonLabel>#<agent_full_name>#<agent_login_name> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<agent_current_state> | Current State of Agent. Possible states are:
|
<resonCodeId> | 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###.
Event: DialogStatus | |
JMS-Type | NULL |
JMS-Body | <agent_login_id>#DialogStatus#<dialog_ID>#DialogState#<fromAddress>#<Call-Variables>#<associated_dialog_ID>#AssDialogState#<fromAddress>#<Call-Variables> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<dialog_ID> | ID of the current active dialog |
<fromAddress> | From address of active dialog |
<Call-Variables> | Call variable of the dialog |
<associated_dialog_ID> | 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.
...
Event: ReasonCodes | |
JMS-Type | NULL |
JMS-Body | <agent_login_Id>#ReasonCodes#Category:<category>#<code_1>,<code_2>,… #Labels:<label_1>,<label_2>,…#<agent_full_name> |
<category> | Category of reason codes. Possible values:
|
<code_1>,<code_2>,..... | Numeric codes of reasons |
<label_1>,<label_2>,… | 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)
Event: InboundCall | |
JMS-Type | NULL |
JMS-Body | Normal:InboundCall#<Inboundcall_current_state>#DialogID:<dialog_ID>#<fromAddress>#<CallVariables>#<start_time>#CallType:<call_type>#ParticipantsCount:<participantsCount>#participants:<participants> Failure: <agent_login_Id>#InboundCall#FAILED#DialogID:<dialog_ID>#<Failure_Cause>#<agent_full_name> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<Inboundcall_current_state> | Current state of the dialog. Possible values are:
|
<dialog_ID> | ID of the current active dialog |
<fromAddress> | From address of active dialog |
<Call-Variables> | 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
|
<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.
Event: NewInboundCall | |
JMS-Type | NULL |
JMS-Body | NewInboundCall#<from_address>#<callvariable1,callvariable2,..>#DialogID:<dialog_ID>#CallType:<call_type>#<start_time> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<Dialog_ID> | ID of the current active dialog |
<fromAddress> | From address of active dialog |
<Call-Variables> | 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
|
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.
Event: DialogState | |
JMS-Type | NULL |
JMS-Body | <agent_login_Id>#DialogState#<dialog_state>#<dialog_ID>#<agent_full_name> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<dialog_state> | Current state of the dialog. Possible values are:
|
<dialog_ID> | ID of the dialog |
Event Category | agent_dialog |
Consult Call State
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.
Event: DialogState | |
JMS-Type | NULL |
JMS-Body | Normal: <agent_login_Id>#ConsultCall#<ConsultCall_current_state>#AssDialogID:<associated_dialog_ID>#<fromAddress>#<Call_Variable>#<Agent_Name> Failure: |
<agent_login_Id> | Agent’s login Id, which is logged in |
<ConsultCall_current_state> | Current state of the dialog. Possible values are:
|
<associated_dialog_ID> | ID of the associated dialog |
<Call-Variables> | 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.
Event: TeamInfoIDs | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#TeamInfoIDs#TeamID#<agent_team_ID_1>,<agent_team_ID_2>,… #<agent_full_name> |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
<agent_team_ID_1>,<agent_team_ID_2>,... | Comma separated team ids assigned to the agent. |
Event Category | supervisor_info |
Supervisor Team Info(Names) [Supervisor Event]
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.
Event: TeamInfoNames | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#TeamInfoNames#TeamName#<agent_team_name_1>,<agent_team_name_2>,… #<agent_full_name> |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
<agent_team_name_1>,<agent_team_name_2>,… | Comma separated team names assigned to the agent. |
Event Category | supervisor_info |
Queue Info [Supervisor Event]
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.
Event: QueueList | |
JMS-Type | NULL |
JMS-Body | UCCE Payload <agent_supervisor_login_Id>#QueueList# UCCX Payload For Supervisor <agent_supervisor_login_Id>#QueueList# For Agent <agent_login_Id>#QueueList# |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
<queue_name> | Name of Queue |
<Number_of_CallsInQueue> | No of Calls in Queue |
<Number_of_Agents_Ready> | No of agents in READY state |
<Number_of_Agents_NotReady> | No of agents in NOT_READY state |
<number_of_agents_talking_inbound> | No of agents TALKING on INBOUND calls |
<number_of_agents_talking_outbound> | No of agents TALKING on OUTBOUND calls |
<number_of_agents_talking_internal> | No of agents talking internal |
<number_of_agents_in_wrapup_ready_state> | No of agents in WRAPUP READY state |
<number_of_agents_in_wrapup_notready_state> | No of agents in WRAPUP NOT_READY state |
| <queue_1_WaitingCalls> | Number of calls in queue for a CSQ. |
| <queue_1_AgentsLoggedIn> | Number of agents in Logged-In state. |
| <queue_1_AgentsInAfterCallWork> | Number of agents in Work state. |
| <queue_1_AgentsTalking> | Number of agents in Talking state. |
| <queue_1_AgentsReserved> | Number of agents in Reserved state. |
| <queue_1_HandledCalls> | Number of calls that are answered by the agents in the CSQ. |
| <queue_1_AbandonedCalls> | Number of calls that are abandoned for a CSQ. |
| <queue_1_TotalCalls> | Number of calls that are presented to the CSQ. |
| <queue_1_LongestHandleTime> | Longest talk time of any call that the agent handled. |
<agent_full_name> | Full name of Supervisor |
Event Category | supervisor_queue_info |
Users [Admin Event]
Event: TeamUsersList | |
JMS-Type | NULL |
JMS-Body | <agent_login_Id>#AgentsList#LoginId=XXXX,Name=XXXX Extension=XXXX,State=XXXX,Team=XXXX|.......|....... |
<agent_login_Id> | Agent’s login Id, which is logged in |
Event Category | |
Team Users [Supervisor Event]
Event: TeamUsersList | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#TeamUsersList#FirstName:<user_1_firstName>,LastName:<user_1_lastName>,Extension:<user_1_extension>, |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
| <user_firstName> | User's first name |
| <user_lastName> | User's last name |
| <user_extension> | User's extension |
| <user_loginID> | User's login ID |
| <user_state> | User's state |
| <user_pendingState> | User's pending State |
| <user_mediaType> | User's media Type |
| <user_stateChangeTime> | User's state Change Time |
| <user_stateChangeLabel> | User's state Change Label |
Event Category | supervisor_team_user |
Team Member State Changed [Supervisor Event] (Not Using)
This event informs a Supervisor agent about the state change of an agent in the team.
Event: TeamMemberStateChanged | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#TeamMemberStateChanged#<teamID>#<agent_state> |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
Event Category | supervisor_team_info |
Conference Participants [Supervisor Event]
This event updates a Supervisor about participants of a call. Only extensions of conference participants are provided.
Event: ConferenceParticipants | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#ConferenceParticipants#<extension_1>,<extension_2>,… |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
Event Category | supervisor_queue_info |
Print Message in agent window as sent
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.
Event: Control | |
JMS-Type | NULL |
JMS-Body | <agent_login_Id>#Control#PrintStatusBar#<Message_To_Agent> |
<agent_login_Id> | Agent’s login Id, which is logged in |
<Message_To_Agent> | Message to print in agent’s window |
Event Category | agent_control |
Phonebooks
This event contains the names and IDs of global and team phonebooks
Event: Phonebook | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#Phonebooks#name:<phonebook_1_name>,type:<phonebook_1_type>,id:<phonebook_1_id> If no data found <agent_supervisor_login_Id>#Phonebooks#NoPhoneBookFound |
<agent_login_Id> | Agent’s login Id, which is logged in |
| <phonebook_name> | PhoneBook name |
| <phonebook_type> | PhoneBook type |
| <phonebook_id> | PhoneBook Id |
Event Category | phonebook |
Contacts
This event contains all the contacts for a specific phonebook
Event: Phonebook | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#PhonebookContacts#description:<contact_1_description>,firstName:<contact_1_firstName>,lastName:<contact_1_lastName>,phoneNumber:<contact_1_phoneNumber>,id:<contact_1_id> If no data found <agent_supervisor_login_Id>#PhonebookContacts#NoContactFound |
<agent_login_Id> | Agent’s login Id, which is logged in |
| <contact_description> | Description of contact |
| <contact_firstName> | Contact first name |
| <contact_lastName> | Contact last name |
| <contact_phoneNumber> | Contact phone number |
| <contact_id> | Contact Id |
Event Category | contacts |
Team PhoneBook
This event contains all the phonebook for a specific team
Event: TeamUsersList | |
JMS-Type | NULL |
JMS-Body | <agent_supervisor_login_Id>#TeamPhoneBooks#name:<phonebook_1_name>,type:<phonebook_1_type>,id:<phonebook_1_id> If no data found <agent_supervisor_login_Id>#TeamPhoneBooks#NoTeamPhoneBookFound |
<agent_supervisor_login_Id> | Agent’s login Id, which is logged in |
| <phonebook_name> | PhoneBook name |
| <phonebook_type> | PhoneBook type |
| <phonebook_id> | PhoneBook Id |
Event Category | phonebook |
All Errors
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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. |
CF_INVALID_LOGON_DEVICE_SPECIFIED
The request specified an invalid logon device.
Error: CF_INVALID_LOGON_DEVICE_SPECIFIED | |
JMS-Type | NULL |
JMS-Body | <Error_For>#Error#CF_INVALID_LOGON_DEVICE_SPECIFIED |
<Error_For> | Possible values are:
|
Error Origin | Finesse |
Error Summary | The request specified an invalid logon device. |
Expected Client’s Behaviour | Display the error message and ask the user to enter a valid extension. Send the request again. |
CF_RESOURCE_BUSY
An internal resource is busy.
Error: CF_RESOURCE_BUSY | |
JMS-Type | NULL |
JMS-Body | <Error_For>#Error#CF_RESOURCE_BUSY |
<Error_For> | Possible values are:
|
Error Origin | Finesse |
Error Summary | An internal resource is busy. |
Expected Client’s Behaviour | Send the request again. |
CF_INVALID_OBJECT_STATE
The object is in the incorrect state for the request.
Error: CF_INVALID_OBJECT_STATE | |
JMS-Type | NULL |
JMS-Body | <Error_For>#Error#CF_INVALID_OBJECT_STATE |
<Error_For> | Possible values are:
|
Error Origin | Finesse |
Error Summary | The object is in the incorrect state for the request. |
Expected Client’s Behaviour | Send the request again. |
PLEASE_RETRY
Invalid request params, IOException, request timeout.
Error: PLEASE_RETRY | |
JMS-Type | NULL |
JMS-Body | <Error_For>#Error#PLEASE_RETRY |
<Error_For> | Possible values are:
|
Error Origin | Generic Connector |
Error Summary | Invalid request params, IOException, request timeout. |
Expected Client’s Behaviour | Send the request again. |
MISSING_REASON_CODE
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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
| Info | ||
|---|---|---|
| ||
We will send # Binary number in case we recieve # in following events.
|
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.
...