Chat

Concept and Architecture

caution

ChatConnector is no longer part of Siebel Central Components

The following figure shows the path that the messages of a chat take when a customer initiates a chat session and is routed by CCE/CCE to an appropriate agent who is using the Siebel Communications Toolbar. The chat channel differs from the voice and email channel as in addition to the control-messages also the payload itself is passed across the Connects for Siebel components.

Step	Description
1	Chat message is sent from the customer’s end user to the chat server
2	Chat server forwards chat message to the ChatConnector’s chat service user
3	ChatConnector generates a route request for the chat session and sends it to the MediaManager
4-5	MediaManager forwards route request via the CCE MR PG to the CCE Central Controller
6	CCE Central Controller runs routing script and selects an available agent
7	Information about selected agent is sent from the CCE Central Controller via the CCE MR PG back to the MediaManager
8a	MediaManager informs the ChatConnector about the selected agent
8b	MediaManager informs the CCE Agent PG about the selected agent
8c	MediaManager informs ConnectMCAL about the selected agent
9	ConnectMCAL sends information about the selected agent to Siebel CRM via the Communication Toolbar Adapter
10	Siebel CRM forwards the chat session alerting to the Siebel Web Client
11	Agent acceptance is sent from the Siebel Web Client to the Siebel CRM
12	Siebel CRM forwards agent acceptance to ConnectMCAL
13	ConnectMCAL forwards agent acceptance the MediaManager
14	MediaManager informs the CCE Agent PG about the agent’s acceptance
15	Agent PG confirms agent acceptance to the MediaManager
16a	ConnectMCAL is notified about the confirmation of the agent acceptance
16b	MediaManager notifies the ChatConnector about the agent acceptance
17	Siebel CRM is notified about the confirmation of the agent acceptance
18	Siebel CRM informs the Siebel Web Client agent desktop about the acceptance confirmation
19	ChatConnector sends content of the chat session to the MediaManager
20–21	Chat session content is sent from the MediaManager via ConnectMCAL to Siebel CRM
22	Siebel CRM forwards the content of the chat session to the agent’s Siebel Web Client

Required Components

For using the chat channel with the b+s Connects for Siebel, installation and configuration of at least the following components is required:

• b+s Connects for Siebel
  • Communication Toolbar Adapter
  • ConnectMCAL
  • MediaManager
  • ChatConnector
• CCE
  • Central Controller (Router, Logger, Administration Workstation)
  • Agent PG
  • Media Routing PG
• 3rd Party
  • Chat server supporting the eXtensible Messaging and Presence Protocol (XMPP)
  • Customer-facing chat clients supporting XMPP

Customer-facing Components

b+s Connects for Siebel, or more precisely the ChatConnector component, connects CCE/CCH to a chat server using the XMPP protocol. XMPP (originally named Jabber) is an open technology for real-time communication, using the eXtensible Markup Language (XML) as the base format for exchanging information. In essence, XMPP provides a way to send small pieces of XML from one entity to another in close to real time. XMPP uses a client-server architecture where clients do not talk directly to one another. The model is decentralized; anyone can run a server and by design, there is no central authoritative server. For using the chat channel with the b+s Connects for Siebel a chat server that supports the XMPP protocol is required. The chat server is placed between the customers chat clients and the ChatConnector.

Every user on the XMPP network has a unique XMPP address, called Jabber Identifier (JID). The JID is structured like an email address with a username and a domain name for the chat server where that user resides, separated by an at-sign (@), such as <username@yourdomain.tld>.

Chat Client

An XMPP chat client is any software or application that enables the connection to an XMPP-based chat server for instant messaging. There are many free or commercial chat clients for many different devices and operating systems available. The ChatConnector has an XMPP chat client integrated and uses it to register one or multiple users on the chat server. For allowing the customers to reach the contact center via chat, each customer must be able to use an XMPP-enabled chat client too. The following two figures show how an XMPP-enabled chat client can be used by a customer to reach the ChatConnector’s chat service users. In Figure 2 the customer is using an XMPP chat client integrated into a modern web browser whereas in Figure 3 the XMPP chat client is part of a fat client (i.e. installed on the customer’s workstation).

Web-based chat client

Fat chat client

As mentioned before, XMPP is implemented by a large number of clients. These implementations are provided under a variety of software licenses. The list of chat clients provided by Jabber.org can serve as an entry point for the selection of a customer chat client. The list is accessible under:

http://xmpp.org/software/clients.html

The b+s Connects for Siebel or more precisely the ChatConnector does not support certain specific chat clients for the customer side as the decision which chat client is chosen depends heavily on the environment and requirements of each contact center system.

Chat Server

An XMPP server provides basic messaging, presence, and XML routing features. As mentioned before, XMPP uses a decentralized client-server architecture similar to the architectures used for the World Wide Web. In XMPP chat servers can also enforce important security policies such as user authentication, channel encryption, and prevention of address spoofing. Like for the chat clients XMPP is implemented by a large number of chat servers which are provided under a variety of software licenses. There are many free or commercial chat servers for many different operating systems available. b+s Connects for Siebel or more precisely the ChatConnector supports a selection of chat servers which are listed in the
b+s Connects for Siebel Release Notes.

ChatConnector

The ChatConnector is a software component of the b+s Connects for Siebel which connects the MediaManager (also a component of the b+s Connects for Siebel) to a chat server using XMPP. The ChatConnector registers one or several XMPP users, called service users, on the chat server. These service users represent the services or queues of the contact center and are the ingress point for chat requests by customers. A CCE/CCH Script Selector is associated with each service user so that incoming chat requests can be routed to an available agent by using CCE/CCH’s routing logic.

The configuration of the ChatConnector component is stored in an initialization file. Please refer to the ChatConnector Configuration Guide document for a full description of all configuration parameters of the ChatConnector.

Configuring Siebel

Siebel Workflows

Activate the following default Siebel Workflows to handle chat requests:

• Chat Display Name Update Process
• Chat Standard Accept Process - v3
• Create Service Request For Chat Action
• View Activity For Chat Action
• View Contact For Chat Action

Activate Chat State Button in Siebel Tools

Execute the following steps to get a chat state button in the Siebel Communications Toolbar:

1. Open Siebel Tools and enable all required objects in «Object Explorer» hierarchy (Menu "View > Options > Option Explorer")

   • Enable "Command" tree
   • Enable "Toolbar" tree

2. Select Project "Communication Administration" in drop-down menu

   

3. Select "Detail" in "Object Explorer"

   

4. Select "Toolbar" in "Object Explorer"

5. Lock Project ("Menu: Tools > Lock Project")

   

6. Select "Toolbar > Communication > Toolbar Item > Agent State For Chat" in tree view and set "Inactive" to "FALSE"

7. Select "Toolbar > Communication > Toolbar Item > Agent State For Email" in tree view

   

8. Select link "HTML_Comm_Email_Not_Ready" in column "Command"

9. Right click on record "HTML Comm Email Not Ready" in window "Commands" and select "Copy record"

10. Change the following fields in the copied record:

    Field	Value
    Name	HTML Comm Chat Not Ready
    Display name – String Override	Not Ready for Chat
    HTML Bitmap	Comm Chat
    HTML Disabled Bitmap	Comm Chat Disabled
    Method	NotReadyForChatGroup
    Status Text – String Override	Not ready for chat
    Tooltip Text – String Override	Not ready for chat

    

11. Compile Project

Configuring ChatConnector

ClearHistoryOnTransfer-Parameter

Oracle Siebel CRM has its own capability to provide the full chat transcript to the agent who receives a transferred chat. It is therefore not required that the ChatConnector uses its transcript-forward mechanism. Add the parameter ClearHistoryOnTransfer into the ChatConnector’s configuration file, section [Gate_mcil], and set it to true to clear the chat buffer before the transfer to another agent is processed.

...

[Gate_mcil]
...
ClearHistoryOnTransfer=true

...

XMPP Presence & Idle Connections

Overview

Every active chat session requires a so called AgentTask-resource on the ChatConnector. To clean up this resource, the ChatConnector needs appropriate information signaled by the end user. XMPP’s presence capabilities can be used for this purpose, but one difficulty here is that presence information is only provided to subscribed users.

An AgentTask-resource is created upon the first message sent from an end user to the ChatConnector (yellow arrow). Without presence information (green arrows), the ChatConnector can only free its AgentTask-resource if the agent, the other participant of the active chat session, releases (i.e. wrap-up/end) the chat session by clicking the appropriate button on the agent desktop UI or an end user’s chat client sends the keyword __close in an XMPP message stanza. Thus, an agent has no information about an end user status without XMPP presence information.

To simplify the XMPP subscription handshake that needs to happen between the ChatConnector’s service users and the various end users, the ChatSub-tool can be used.

Ignite realtime Openfire

• With the Openfire chat server one can pre-configure all roster entries and its subscription state manually.
• It is also possible to import appropriate users by using the Export/Import-plugin.
• Make a ChatSub-tool run to subscribe service users to end users.
  An active ChatConnector will provide a positive answer and a reverse subscription request to every incoming subscription request.

Cisco Unified Communications Manager Instant Messaging and Presence (CUCM IMP)

• Make a ChatSub-tool run to subscribe service users to end users.
• CUCM IMP version 10 does not provide subscription notification to active ChatConnector service users, so a ChatSub-tool run with service user as end user is necessary or a tool run with /rev.

Cisco Unified Presence Server (CUPS)

• Same behavior as for CUCM IMP

ChatSub-Tool

Although a single-sided subscription (service user to end user) is sufficient the ChatSub-tool is meant to work towards an active (already running) ChatConnector and its service users. The result is a bidirectional subscription for both involved user groups.
Unfortunately, this works only for certain chat servers, like Openfire, where subscription requests are conveyed to other users makes them to react appropriately. To get the same subscription state for chat servers that do not provide corresponding notifications, either exchange list entries (end users become service users and vice versa) or just use reverse mode (/rev) of the ChatSub-tool. This will do a complete subscription run on both groups, as long as you provide also the password information for the service users. The following figure show the subscription handshake between an end user and a service user.

ChatSub-Tool Example Configuration

<?xml version="1.0" encoding="utf-8"?\>
<Subscribers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"\>
    <EndUsers\>
        <Account Username="user1" Password="pwd" /\>
        <Account Username="user2" Password="pwd" /\>
        <Account Username="user3" Password="pwd" /\>
    </EndUsers\>
    <Services\>
        <Account Username="sales" /\>
        <Account Username="support" /\>
        <Account Username="admin" /\>
    </Services\>
    <Domain\>mydomain.com\</Domain\>
    <NetworkHost /\>
</Subscribers\>

Element	Description
Account	An account element can be used to add a user (username, password) to the end user or service user list.
EndUsers	End user list, used for customer clients (a bunch of reused accounts)
Services	Service user list, used by the ChatConnector’s service users
Domain	Domain of the chat server
NetworkHost	Network host name/address, used if domain differs from server address.

Available Command Line Parameters

Parameter	Description
file	Path to the account configuration file (see ChatSub-Tool Example Configuration)
template	Generate an example account configuration file
rev	Subscribe end user towards service user and service user towards end user
waittime	Guard time between subscription requests. Wait a certain amount of milliseconds before sending the next subscription inquiry to the chat server.
loglevel	Increase/decrease logging output. Text output colors: Debug: Gray Info: Green More: White Warn: Yellow Error: Red Fatal Error: Magenta
mode	Besides subscribing, which is default, it is also possible to unsubscribe users by set mode to unsubscribe.
rmri	Unsubscribe also removes corresponding roster items.
run	Set this to Parallel to run all user subscribe tasks in parallel.

Example Run

The following figure shows a console output of a ChatSub-Tool run using Openfire as chat server.

info

Please note that the yellow warnings appear because a self-signed certificate is used on the chat server

Logging

To get a file with detailed log output invoke the ChatSub-tool like this:

chatsub accounts.xml > log.txt 2>&1

Cleanup Idle Connections

Depending on the chosen vendor a chat server can disconnect clients of which the connection appears to be lost. Lost connections are detected based on the amount of time that a client has been idle. Furthermore, some chat servers can send so called XMPP Ping requests (XEP-0199) to clients that are idle before they are disconnected. Clients must respond to such a request which allows the chat server to determine if the client connection has indeed been lost. The ChatConnector supports XMPP Ping by default which means that it responds to XMPP Ping requests with an appropriate response. Please refer to the official documentation of the chosen chat server product for detailed information about the support and configuration of idle connections policies and XMPP Ping requests.

Module Scripting in CCE

The ChatConnector offers scripting helper functionality modules that can be used while a customer is waiting for an agent (i.e. waiting in the queue). For example: the ChatConnector can send chat messages to the customer or analyze chat messages from the customer remotely controlled from the CCE/CCH routing script.

Configuration in CCE

A chat integration needs at least one CCE/CCH routing script, a CCE/CCH Dialed Number / Script Selector List entry which is assigned to this routing script and the correct ScriptSelector-configuration in the ChatConnector’s ini-file (see chapter Chat Users for more information). Additionally, CCE/CCH Network VRU Script List entries are required to access the ChatConnector’s scripting helper functionality modules. The ChatConnector supports the usage of the following Network VRU Scripts / scripting helper functionality modules:

VRU Script Name	Name	Timeout (in seconds)	interruptible
120;CHAT	WRITE_TEXT_CHAT	30	No
131;CHAT	GET_SELECTION_CHAT	300	Yes
132;CHAT	CLR_SELECTION_CHAT	30	No
134;CHAT	SET_PARAMETER_CHAT	30	No
135;CHAT	GET_PARAMETER_CHAT	30	No

ChatConnector Modules

The ChatConnector supports the following scripting helper functionality modules.

Write Text

This module can be used to send a text to the customer’s chat client.

RunScript	WRITE_TEXT_CHAT (120;CHAT)
BS_inout	“Message”
BS_inout	“ReturnValue“

Field Name	Field Type	Comment
Message	String	Message sent to customer

Field Name	Field Type	Comment
ReturnValue	Number	Return Value: 0 Successful 9 Error

Get Selection

This module can be used to capture customer input.

RunScript	GET_SELECTION_CHAT (131;CHAT)
BS_inout	“NumberOfChar[;WaitTime[;param]]”
BS_inout	“ReturnValue“

Field Name	Field Type	Comment
NumberOfChar	Number	Number of chars to read 0 = Read all chars If value of ‘NumberOfChar’ is greater than number of chars in buffer, ‘ReturnValue’ will provide all chars from buffer.
WaitTime	Number	Time to wait until ChatConnector replies (in milliseconds).
param	String	Additional parameter for selection. Format: {Name=Value}. Name Value Action AT EMAIL (Default) Parse for @ AT WORD Parse for space AT: Analyze Type Example: AT=EMAIL

Field Name	Field Type	Comment
ReturnValue	String	Return Value OK: Read Value Return Value Failure: 0 Successful 9 Error

Clear Selection

This module can be used to clear the selection buffer.

RunScript	CLR_SELECTION_CHAT (132;CHAT)
BS_inout	“”
BS_inout	““

Set Parameter

This module can be used to set certain parameters.

RunScript	SET_PARAMETER_CHAT (134;CHAT)
BS_inout	“ParamName=ParamValue”
BS_inout	“ReturnValue“

Field Name	Field Type	Comment
ParamName	String	Parameter name
ParamValue	String	Value

info

Do not place spaces around the equal character!

- OK: ParameterName=ParameterValue  
- Not OK: ParameterName = ParameterValue

Field Name	Field Type	Comment
ReturnValue	String	Return Value OK: 0 Return Value Failure: 0 Successful 9 Error (variable not found/BS_inout empty)

Parameter	Value	Description
SYS.CA	String	Customer Accepted Overwrites ‘CustomerAccepted” setting. Not used in ChatConnector 2.3
SYS.CBBA	[0, 1]	Clear CED Buffer Before Appending
SYS.CBF	String	Chat Being Failovered Overwrites ‘ChatBeingFailoveredMessage‘ setting
SYS.CBT	String	Chat Being Transferred Overwrites ‘ChatBeingTransferredMessage’ setting.
SYS.CPF	String	Chat Partner Found Overwrites ‘ChatPartnerFound’ setting.
SYS.CH	-	Clear History buffer
SYS.HCSIC	[0,1]	Save chat messages [1] = On, [0] = Off.
SYS.SC	String	Session Closed Overwrites ‘SessionClosedMessage’ setting.
SYS.SUBJECT	String	Set subject

Get Parameter

This module can be used to get certain parameters.

RunScript	GET_PARAMETER_CHAT (135;CHAT)
BS_inout	“ParamName”
BS_inout	“ReturnValue“

Field Name	Field Type	Comment
ParamName	String	Parameter name

Field Name	Field Type	Comment
ReturnValue	String	Return Value OK: Read Value Return Value Failure: 0 Successful 9 Error

Parameter	Value	Description
SUB.	String	Query all ‘customer’ chat client provided variables (see Transmitting Customer Data to CCE)
SYS.CLUN	String	Chat Local User Name Address of ChatConnector service user account Bare JID (To)
SYS.CRUN	String	Chat Remote User Name Address of customer account (i.e. end user) Bare JID (From)
SYS.InteractionId	String	Unique ID of session.
SYS.IRR	bool	Initial Route Request True for first route request of session per DN
SYS.IsChatTransfer	bool	True for transferred chat session
SYS.SUBJECT	String	Get Subject

info

Consider to check the length of GET_PARAMETER_CHAT or GET_SELECTION_CHAT output in the used CCE routing script.

Transmitting Customer Data to CCE

It might be desired that certain data about the customer and/or the customer’s intention is passed from the end user chat client via the chat server and the ChatConnector to CCE or to the agent itself. Having such data available in CCE makes it possible to refine the agent selection process in the CCE routing script.

Passing Data to the ChatConnector

If the chat solution used for the customer’s chat client has access to the child element <subject/> of the XMPP message stanza, it can be used to transmit data to the ChatConnector. If not, the payload of the first XMPP message, i.e. the child element <body/> of the first XMPP message stanza, can be used for this. The data that should be transmitted to the ChatConnector must follow a certain format of key/value-pairs so that it can be queried from the CCE routing script by using the Get Parameter-module (see description below).

Required format for key/value-pairs in the XMPP message stanza (subject or body):

{key:value<CRLF>}

Key-names can be freely selected, but keep them short (CCE / RunScript limitations). The size of a key and value is determined by the configuration of the special ECC variable user.BS_inout. Maximum length is 210 characters. All keys are automatically prefixed with SUB. before they are stored in an internal list in the ChatConnector.

Example Option 1: Using Subject Child-Element

<message
      from='customer@gui.net'
      to='chatsupport@bucher-suter.com'
      xml:lang='en'>
    <subject>Name:Hans
             SRNumber:1-24EC18
             SUBJECT:Request
    </subject>
    <body>Hello</body>
</message>

Example Option 2: Using Body Child-Element

<message
      from='customer@gui.net'
      to='chatsupport@bucher-suter.com'
      xml:lang='en'>
    <body>Name:Hans
          SRNumber:1-24EC18
          SUBJECT:Request
    </body>
</message>
<message
      from='customer@gui.net'
      to='chatsupport@bucher-suter.com'
      xml:lang='en'>
    <body>Hello</body>
</message>

An exception is the key/value-pair with key-name SUBJECT, which causes the ChatConnector to internally store two variables. The first variable is handled similar to all the other detected key/value-pairs and stored as SUB.Subject. The second variable is used by the ChatConnector to fill the subject-field in the route-request sent to the MediaManager. The MediaManager takes the value from the subject-field and puts it into the designated CED-field on the route request sent to CCE. This CED-field has a maximum length of 36 characters. In the CCE routing script the value stored in the CED-field is directly accessible through the variable named CallerEnteredDigits.

In addition to <CRLF> you can use your own key/value pair delimiter defined by setting KVPTransferDelimiter (see chapter 4 MediaManager-Gate Configuration). See an example using KVPTransferDelimiter’s default value of “|” (pipe character):

<message
      from='customer@gui.net'
      to='chatsupport@bucher-suter.com'
      xml:lang='en'>
    <subject>Name:Hans|SRNumber:1-24EC18|SUBJECT:Request</subject>
    <body>Hello</body>
</message>

Getting the Data from the CCE Routing Script

The ChatConnector offers scripting helper functionality modules that can be used in the CCE routing script while a customer is waiting for an agent (i.e. waiting in the queue). The transmission of customer data from the end user’s chat client to CCE requires the usage of the Get Parameter-module.

Example using the child-element <body/> of the first XMPP Message Stanza

<message
      from='customer@gui.net'
      to='chatsupport@bucher-suter.com'
      xml:lang='en'>
    <body>Service:TestIntegration
          Location:Metropolis
          Comment:Free text
          Subject:Request
    </body>
</message>

After the ChatConnector has finished processing the key/value-pairs, all values can be queried from the CCE routing script by using the Get Parameter-module:

GET_PARAMETER_CHAT SUB.Service  → “TestIntegration”
GET_PARAMETER_CHAT SUB.Location → “Metropolis”
GET_PARAMETER_CHAT SUB.Comment  → “Free text”
GET_PARAMETER_CHAT SUB.Subject  → “Request”

enable Chat Notification States

If XMPP Chat Notification States are enabled on the ChatConnector (Chatstates=False), the first XMPP message stanza is sent from the customer’s chat client to the ChatConnector when the customer presses a key.

Miscelaneous

Screen Transfer using Siebel Bookmark

When an agent performs an agent-to-agent or agent-to-queue chat transfer his screen can be saved as a Siebel bookmark with the chat transcript before being transferred to another agent. A Siebel bookmark is an URL that links to a specific record in Siebel. The Siebel bookmark represents the view which was current when a particular work item was suspended (i.e. the transfer triggered). The Siebel bookmark data is serialized and compressed into a string. For a chat transfer the Siebel bookmark is not sent to the Communication Toolbar Adapter respectively the DataStore but remains in Siebel next to the chat transcript. Then, when another agent accepts the transferred chat, the Chat Business Service retrieves the Siebel bookmark information from the chat transcript and populates the chat screen with the Siebel bookmark information. In this way, the agent receiving the transferred chat has access to all information relating to the chat and the agent transferring the chat.

Example of a chat transcript with the Siebel bookmark stored next to it:

    <transcript>
        ...
        <message userName="Agent Frank"  from="John Doe"  timestamp="12/8/2015  01:14:12 AM" >
           I'm going to transfer you...
        </message>
        <system-message timestamp="12/8/2015 01:14:52 AM" >
           The chat has been transferred.
        </system-message>
    </transcript>
    <bookmark>0IQGV4FA00qUg8JesQRtL...CkKPWnl0WFl5Feyxj!1qyRvKQxxBDZ482B1</bookmark>

To set up the Siebel bookmark-transfer feature for chat, configure the Siebel bookmark-transfer feature for each command by setting the ServiceParam.AttachContext command data parameter to "TRUE". The Siebel DEF-file shipped with the b+s Connects for Siebel has the ServiceParam.AttachContext set to "TRUE" for the commands ForwardChat, TransferChatToAgent and TransferChatToQueue.

[Command:ForwardChat]
   Description   = "Forward chat back to queue"
   FilterSpec    = "[@SelectedWorkItem:mediaType] = 'Chat'"
   ServiceMethod = "Chat UI Business Service.TransferChat"
   Hidden        = "TRUE"
   CmdData       = "ForwardChatData"

   [CmdData:ForwardChatData]
----> ServiceParam.AttachContext        = "TRUE"
      ServiceParam.DeviceCommand        = "RerouteTask"
      ServiceParam.InteractionId        = "{@SelectedWorkItem:InteractionId}"
      ServiceParam.NotifyText           = "Chat Transferred from {@UserName}..."
      ServiceParam.isTransfer           = "1" 
      ServiceParam.trackingId           = "{@SelectedWorkItem:DriverWorkTrackID}"
      ServiceParam.routeTarget          = "{@EditControl}"

[Command:TransferChatToAgent]
    Description   = "Transfer chat to agent with Popup"
    FilterSpec    = "[@SelectedWorkItem:mediaType] = 'Chat'"
    ServiceMethod = "Chat UI Business Service.TransferChat"
    Hidden        = "TRUE"
    CmdData       = "TransferChatToAgentData"

   [CmdData:TransferChatToAgentData]
       SelectApplet                      = "ACD Transfer Call Applet"
       SelectBusComp                     = "Employee"
       SelectBusObj                      = "Employee"
       SelectParam                       = "TRUE"
       SelectQuerySpec                   = "[Job Title]='Contact Center Agent'"
       SelectTitle                       = "Transfer to Agent:"
-----> ServiceParam.AttachContext        = "TRUE"
       ServiceParam.DeviceCommand        = "RerouteTaskWithParam"
       ServiceParam.InteractionId        = "{@SelectedWorkItem:InteractionId}"
       ServiceParam.NotifyText           = "Chat Transferred from {@UserName}..."
       ServiceParam.isTransfer           = "1" 
       ServiceParam.trackingId           = "{@SelectedWorkItem:DriverWorkTrackID}"
       ServiceParam.PreferredAgentInfo   = "[Login Name]"      

[Command:TransferChatToQueue]
    Description   = "Transfer chat to queue with Popup"
    FilterSpec    = "[@SelectedWorkItem:mediaType] = 'Chat'"
    ServiceMethod = "Chat UI Business Service.TransferChat"
    Hidden        = "TRUE"
    CmdData       = "TransferChatToQueueData"

    [CmdData:TransferChatToQueueData]
        SelectApplet                      = "Transfer Multiple LOV Popup Applet"
        SelectBusComp                     = "List Of Values"
        SelectBusObj                      = "List Of Values"
        SelectParam                       = "TRUE"
        SelectQuerySpec                   = "[Type] = 'CHAT_TRANSFER_QUEUE' AND [Active] = 'Y'"
        SelectTitle                       = "Please select queue to transfer"
------> ServiceParam.AttachContext        = "TRUE"
        ServiceParam.DeviceCommand        = "RerouteTaskWithParam"
        ServiceParam.InteractionId        = "{@SelectedWorkItem:InteractionId}"
        ServiceParam.NotifyText           = "Chat Transferred from {@UserName}..."
        ServiceParam.isTransfer           = "1" 
        ServiceParam.trackingId           = "{@SelectedWorkItem:DriverWorkTrackID}"
        ServiceParam.RerouteScript        = "[Name]"

Refer to the Siebel Chat Guide for more detailed information about the configuration of the Siebel bookmark-transfer feature.

Chat State Notifications

The b+s Connects for Siebel supports the usage of chat state notifications as described in the XMPP protocol extension XEP-0085. The extension allows to communicate the status of a user in a chat session, thus indicating whether a chat partner is actively engaged in the chat, composing a message, temporarily paused, inactive, or gone. Changing state in a conversation is done by embedding the corresponding chat state element into an XMPP message stanza. Chat state notifications can appear in two kinds of <message/> stanzas:

• A "content message" -- that is, a message stanza whose primary meaning is contained in standard messaging content such as the XMPP <body/> or any other properly namespace child element(s) other than those defined for chat state notifications in this specification.
• A "standalone notification" -- that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state

Example Inside Content Message

    <message from="customer12345@yourdomain.tld"
             to="customersupport@yourdomain.tld"
             type="chat">
    <body>Hello agent?</body>
    <active xmlns="http://jabber.org/protocol/chatstates"/>
    </message>

Standalone Notification

    <message from="customer12345@yourdomain.tld"
             to="customersupport@yourdomain.tld"
             type="chat">
    <composing xmlns="http://jabber.org/protocol/chatstates"/>
    </message>

Chat State Composing / Siebel Chat Feedback

The b+s Connects for Siebel supports currently only the XMPP chat states active and composing. Active means that a user is actively participating in the chat session, whereas composing indicates that a user is composing a message. The latter can be used for Siebel Chat Feedback. When agents are typing a response to an incoming chat, a feedback message appears on the recipient's (i.e. customer’s) chat pane:

Agent is typing . . .

Likewise, when customers are typing a response to the agent, the following message appears on the agent's chat pane:

Customer is typing . . .

In both cases, the feedback message appears at the bottom of the Siebel web client’s chat transcript area in the chat pane, and it is displayed for approximately 5 seconds before disappearing. The following figure shows the message flow through the system for the chat state composing respectively Siebel Chat Feedback.

Configuration

• To configure Siebel Chat Feedback messages to display during chat sessions between agents and customers, perform the tasks described in the appropriate Siebel Chat Guide.

• In the ChatConnector’s ini-file, set the parameter Chatstates to True (default is false)

If XMPP Chat Notification States are enabled on the ChatConnector (Chatstates=True), the first XMPP message stanza is considered as the one that is sent from the customer’s chat client (i.e. the end user) to the ChatConnector’s service user when the customer presses a key. This behavior must be considered when customer data should be transmitted from the end user to the ChatConnector’s service user with the first XMPP message. Please refer to the ChatConnector Configuration Guide, chapter Transmitting Customer Data to CCE for detailed information.

Terminology

Term	Definition
End User	An end user is a user that the customer’s XMPP client uses to communicate to the chat server.
Service User	A service user is a user that the ChatConnector’s XMPP client uses to communicate to the chat server. A service user can be seen as an abstraction of a contact center service or queue (e.g. technical support, product sales).
Customer	A customer is a human being who consumes a service of the contact center provider.
Contact Center Provider	A contact center provider provides services to a customer.
Agent	An agent handles requests from a customer.