Configuring MCF Queues

This chapter discusses how to:

Define queues.
Configure tasks.
View the cluster summary page.
Tune cluster parameters.
Notify clusters of changed parameters.

Defining Queues

To define queues, use the MCF Queue (MCF_Q_CONFIG_CMP) component.

This section discusses how to:

Define queues.
Define chat responses.
Define static push URLs.

Pages Used to Define Queues

Page Name	Object Name	Navigation	Usage
Queues	MCF_QUEUE_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Queue, Queue	Add a queue.
Chat Responses	MCFSYSMSG_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Queue, Chat Responses	Define messages that every agent can use.
Static Push URLs	MCFQUEUEURL_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Queue, Static Push URLs	Define URLs that each agent can push to a client.

Defining Queues

Access the Queues page.

Queue ID

Queue IDs must be alphanumeric, may not end in a numeral, but may include underscore characters.

Delete Queue

Click to remove this queue.

Deleting a logical queue means that no work or agents can be assigned to the queue, and the queue is removed from all agents' available queues.

You can delete a logical queue only if all of its constituent physical queues are inactive and have no tasks. Verify that no application code assigns tasks to a queue before deleting the queue. All agents assigned to the child physical queue will receive a message notifying them to log off of their MultiChannel Consoles when the logical queue is deleted.

Physical Queue

The Physical Queue field uniquely identifies that part of a logical queue serviced by the selected MCF cluster.

Physical queue IDs always end in a number; for example, Sales2. The physical queue identifier automatically increments by one for each physical queue added.

Physical queue IDs are automatically generated. The maximum number of physical queues is nine.

Cluster ID

The Cluster ID field identifies the MCF cluster that services this physical queue. Click Select Cluster to choose from configured MCF clusters.

Each MCF cluster can only service one physical queue per logical queue. For example, an MCF cluster could service physical queue Sales1 or Sales2, but not both.

An MCF cluster can service multiple physical queues belonging to different logical queues. For example, an MCF cluster could service physical queues Sales1, Marketing2, and COBOL1.

Select Cluster

Click Select Cluster to choose a cluster from a list of available MCF clusters.

The selected MCF cluster will service this physical queue. The primary queue server in this cluster will manage tasks and agents assigned to this physical queue.

Active

Select Active or Inactive from the drop-down list box.

The queue server will not send new tasks to an inactive physical queue. Agents and existing tasks will remain on an inactive physical queue. The physical queue must be active to receive new queued tasks.

Only inactive physical queues can be deleted from a logical queue. Inactivate a physical queue and complete or transfer all assigned tasks before deleting the physical queue.

Active and inactive status support “follow-the-sun” practices. For example, Sales1 could be supported in the London office, and Sales2 could be supported in the San Francisco office when the London office is closed by activating and inactivating the appropriate queues.

Defining Chat Responses

Access the Chat Responses page.

Chat responses specified on this page are available to all agents logged on to this queue.

Contact Type

Specify one of the following contact types:

Chat
Email (not currently supported)
Generic (not currently supported)

Response Name

The response name appears in the agent's Template Messages drop-down list box for all agents who belong to a physical queue on this logical queue

All chat responses are downloaded when the agent launches the agent chat console by accepting a customer chat. Template messages are not available in collaborative chat.

Response Text

The specified message appears in the client chat window when selected by the agent.

Defining Static Push URLs

Access the Static Push URLs page.

Static URLs enable the agent to push a predefined URL to the customer, which appears in a pop-up window for the customer. The agent can edit these URLs in the chat window after selecting them.

URL Name

Specify a name to identify the URL.

The URL name appears in the agent's Static URL drop-down list box for all agents that belong to this logical queue

URL Description

Specify a description of the URL.

This description appears only on this page to further describe this URL or, for example, its reason for inclusion.

URL

Specify the queue push URL.

The URL must include the opening http:// and any required parameters.

All static URLs defined for the queue are downloaded when the agent launches the agent chat console by accepting a customer chat. Static URLs are not available in collaborative chat.

If you send a static push URL that is a PeopleSoft Pure Internet Architecture URL, be sure that the recipient has permissions to access that portal , node, or page.

Configuring Tasks

To configure tasks, use the MCF Task (MCF_TASKCFG_CMP) component.

This section discusses how to configure tasks.

Page Used to Configure Tasks

Page Name	Object Name	Navigation	Usage
Task Configuration	MCF_TASKCFG_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Tasks	Configure tasks such as chat, email, voice, and generic alerts.

Configuring Tasks

Access the Task Configuration page.

Define values for different types of tasks that the queue server uses to assign tasks to appropriate agents, and to manage tasks that are not accepted or closed within configurable time limits.

Default Cost of Task	Specify the cost of the task. Cost is a measure of the workload each task places on an agent. The cost of a task is an estimate of the task's expected complexity and of the time required to resolve the task. The minimum value is 0, and there is no maximum value. The costs of tasks assigned to an agent are added up and evaluated against the maximum workload for each agent to determine if the agent can receive additional tasks. For example, if an agent has a maximum workload of 100, and the default cost of a chat is 20, the agent can manage five concurrent chat sessions, assuming the default cost is not overridden in the InitChat() built-in function call and that no other task types have been assigned. Note. Although priority has no effect on voice tasks (which are not queued), voice task cost is included in calculating an agent's workload. Default costs are: Chat: 5 Email: 2 Generic: 1 Voice: 10
Default Priority of Task	Specify the priority of this task. A higher value means a higher priority. Tasks are ordered on a physical queue based on their assigned priority. The minimum value is 0, and there is no maximum value. A queue server gives precedence to a task of higher priority value over a task of lower priority value when looking for an agent to assign the task to. This means that the queue server will always assign a task of priority 100 to a qualified available agent before it looks for an agent for a task of priority 10. If two tasks have the same priority, they will be assigned in the order of their enqueue time. The value specified here can be overridden in the EnQueue() or InitChat() built-in function call. Note. Priority has no effect on voice tasks, which are not queued; however, voice task cost is included in calculating an agent's workload. Default priorities are: Chat: 5 Email: 2 Generic: 1 Voice: 10
Default Skill Level of Task	Specify the minimum agent skill required to handle this task. The queue server assigns this task type to an available agent with the lowest skill level on that queue greater than or equal to the skill level required by the task. The minimum value is 0, and there is no maximum value. The value specified here can be overridden in the EnQueue() or InitChat() built-in function call. Default skill levels are: Chat: 1 Email: 1 Generic:1 Voice (not currently supported): 2
Default Acceptance Timeout in Seconds	Specify the period of time that an agent has to accept an assigned task (to click the flashing icon on the MultiChannel Console). If the task is not accepted within this time the task is re-enqueued for assignment to another agent. The queue server uses an algorithm to minimize reassignment of tasks which previously timed out to the same agent. The value specified here can be overridden in the EnQueue() or InitChat() built-in function call. Default acceptance timeouts are: Chat: 30 Email: 30 Generic: 30 Voice (not currently supported): 10
Default Overflow Timeout in Minutes	Specify the overflow timeout. The overflow timeout is the time period that a queue server has to find an agent who accepts a task (click flashing icon on the MultiChannel console). If the task is not accepted within this time, the task is removed from the queue and placed in the overflow table. This table can be managed from the Overflow Administration page. The value specified here can be overridden in the EnQueue() or InitChat() built-in function call. Default overflow timeouts are: Chat: 2 Email: 120 Generic: 120 Voice (not currently supported): 1
Default Escalation Timeout in Minutes	Specify the default escalation timeout. The escalation timeout is the time period within which a task must be closed. If the task is not closed within this time, the task is removed from the queue and from the agent's accepted task list (that is, the task is unassigned) and the task is placed in the escalation table. This table can be managed from the Escalation Administration page. Escalation timeout is only valid on a chat session after it is accepted by an agent, and has no effect on voice tasks (CTI). The value specified here can be overridden in the EnQueue() or InitChat() built-in function call. Default escalation timeouts: Chat: 10 Email: 480 Generic: 480 Voice (not currently supported): 2
Seed for Sequence Number	This field displays the current cumulative count of tasks of this type enqueued. Do not modify this value until it has reached its upper limit of 2,147,483,647. This value does not apply for the voice task type.
Inactivity Timeout in Minutes	Specify the inactivity timeout Inactivity timeout applies to chat only. The inactivity timeout is the time period within which an agent or customer must participate in a chat. If the chat session is dormant for more than this time, the chat is terminated. The default value is 15 minutes.
Interval for Greeting in Seconds	Specify the interval, in seconds, over which the initial greeting appears in a customer chat window while the system searches for an available agent.

Note. All task parameters are delivered with sample values. Determine a range for these values appropriate to your business requirements. For example, task cost could vary over a range of 1 to 100 instead of 1 to 10.

Viewing the Cluster Summary

To view the Cluster Summary page, use the Cluster Summary (MCF_RSERV_CFG_CMP) component.

This section discusses how to view the Cluster Summary page.

Page Used to View the Cluster Summary

Page Name	Object Name	Navigation	Usage
Cluster Summary	MCF_RENSRV_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Cluster Summary	View summary information about MCF clusters.

Viewing the Cluster Summary

Access the Cluster Summary page.

The Cluster Summary page displays the associated MCF cluster URLs and queue details for the selected MCF cluster. The information cannot be changed from this page.

Tuning Cluster Parameters

To tune cluster parameters, use the Cluster Tuning (MCF_SYSTEM_NV_CMP) component.

This section discusses how to tune cluster parameters.

Page Used to Tune Clusters

Page Name	Object Name	Navigation	Usage
Cluster Tuning	MCF_SYSTEM_KV_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Cluster Tuning	Modify MCF cluster parameters to tune performance.

Tuning Cluster Parameters

Access the Cluster Tuning page.

Use the Cluster Tuning page to set MCF cluster parameters to optimize performance or enable logging according to the following table:

Key	Default value	Usage
bcastinterval	60	Interval, in seconds, after which the number of unassigned tasks per physical queue and the number of agents logged into each physical queue are broadcast to the MultiChannel Consoles for display next to the queue names. A smaller value provides more accurate queue statistics, but increases the load on the queue server and REN server. A larger value decreases queue server and REN server load, but also decreases statistical accuracy. The bcastinterval value also determines how frequently onStat2 event statistics are calculated. A smaller value provides updated statistics more frequently. See Using the Monitor Queues Page and Sample Monitor - Queue Statistics Page. See Using the Monitor Agents Page and Sample Monitor - Agent States Page.
clhbinterval	30	Interval, in seconds, in which the queue server expects to receive a heartbeat from a connected JSMCAPI client. If the queue server receives no heartbeat during this interval the queue server stops the client session. See Using and Demonstrating JSMCAPI.
donelistsize	100	Number of completed tasks stored in the list that is used to calculate average task duration. Configure the donelistsize value depending on the task volume encountered and the interval over which you want to monitor tasks. See Using and Demonstrating JSMCAPI.
dumpagents	No	Specify Yes if the status of agent activity should be written to the database during the periodic state dumps. Logging agent status increases queue server load, but provides information on agent performance. See Viewing the Agent State Summary.
dumpinterval	600	Interval, in seconds, after which the queue state is written to the database. A smaller value increases load on the queue server, but provides more frequent statistics. A larger value decreases load on the queue server, but provides less frequent statistics. A value of less than one minute will significantly reduce queue server performance. See Viewing the Queue Server State. See Viewing the Queue State Summary.
highwater	100	Maximum number of persistent tasks retrieved from the database and cached in memory in the queue server. The high- and lowwater mark values determine how often, and how many, persistent tasks should be read into memory. A higher value causes the queue server to retrieve more persistent tasks at one time, which results in less-frequent access to the database, but also more tasks for the queue server to manage, slowing performance. A lower value speeds performance, but requires more frequent access to the database. If a large number of enqueued tasks cannot be routed by the queue server (for example, a call center handling a specific physical queue is offline), increase the highwater mark so that tasks that can be routed can fit into memory cache.
logDMPQ	No	Specify Yes if you want PSMCFLOG to log REN server event notifications resulting from bcastinterval broadcasts. Only the event is logged, not its contents. See Viewing Event Logs.
logStat	No	Specify Yes to log the statistics returned by the queue server for the onStat1 user and group events to the database. See Using and Demonstrating JSMCAPI.
log_chat_ses	No	Specify Yes to turn on logging of the contents of chat sessions. See Viewing Chat Logs.
log_cti	No	Specify Yes to turn on logging of CTI events. See CTI Event Logging.
lowwater	5	Minimum number of persistent tasks cached in memory in the queue server. When the lowwater value is reached, the queue server retrieves another batch of persistent tasks, up to the highwater value. The high- and lowwater mark values determine when, and how many, persistent tasks should be read into memory. A higher value requires the queue server to access the database more frequently. A lower value can cause the queue server to run out of persistent tasks before refreshing its queue. PeopleSoft recommends that the lowwater value be greater than or equal to the maximum number of agents logged onto any physical queue at one time.
masterinterval	15	Interval, in seconds, after which a cluster master updates its timestamp in its cluster tables. Slave clusters check the timestamp to determine that the master cluster is still running. A lower value enables rapid discovery of a failed master server, but increases queue server overhead. A higher value reduces queue server overhead, but delays discovery of a failed master server. If a only one queue server is configured for an MCF cluster, this value can be large. The masterinterval value also acts as a heartbeat interval for the master queue server connection to user consoles.
max_no_reply	5	Sets the maximum number of consecutive agent timeouts before the queue server automatically logs out the agent and sets the agent’s console status as Assumed Unavailable.
max_refresh	5	Sets the maximum number of consecutive times that results are discarded when refreshing the task queue from the database if there is an intervening notification of new persistent tasks.
reeperinterval	60	Interval, in seconds, after which deleted task are cleared from memory in the queue server. A lower value increases queue server load but clears memory more frequently. A higher value decreases queue server load but clears memory less frequently.
statdump	No	Specify Yes to write queue server state to the database during the periodic state dumps. The state dump interval is set by the dumpinterval parameter. See Using and Demonstrating JSMCAPI.
timinginterval	60	Interval, in seconds, after which the database is checked for expired or overflowed persistent tasks. This parameter does not affect real-time tasks. A lower value increases queue server load but detects timed out tasks more quickly. A higher value decreases queue server load but detects timed out tasks less frequently.

Notifying Clusters of Changed Parameters

To notify clusters of changed parameters, use the Cluster Notify (MCF_AD_NOTIFY_CMP) component.

This section discusses how to notify clusters of changed parameters.

Page Used to Notify Clusters of Changed Parameters

Page Name	Object Name	Navigation	Usage
Notify Cluster	MCF_CL_NOTIFY_PG	PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Cluster Notify	Notify a cluster of changes to parameters, configuration, or of shutdown.

Notifying Clusters of Changed Parameters

Access the Notify Cluster page.

Use the Notify Cluster page to notify an MCF cluster of certain changes to its parameters, constituent queues, or that its application servers are being shut down.

For example, after changing MCF cluster parameters on the Cluster Tuning page use the Notify Cluster page to refresh the tuning parameters.

Notify cluster of imminent shutdown	Click to send a message to every agent logged on to the selected MCF cluster that they have been logged off. Send this notification if the cluster's application servers are being shut down.
Refresh task properties	Click to load task properties that have been changed on the Tasks page for the selected MCF cluster.
Refresh threshold/tuning parameters	Click to reload parameters, other than logging parameters, changed on the Cluster Tuning page for the selected MCF cluster.
Refresh logging parameters	Click to reload logging parameters changed on the Cluster Tuning page for the selected MCF cluster.
Notify cluster of new queue	Click to notify the selected MCF cluster that the selected physical queue has been added.

Queue ID	Queue IDs must be alphanumeric, may not end in a numeral, but may include underscore characters.
Delete Queue	Click to remove this queue. Deleting a logical queue means that no work or agents can be assigned to the queue, and the queue is removed from all agents' available queues. You can delete a logical queue only if all of its constituent physical queues are inactive and have no tasks. Verify that no application code assigns tasks to a queue before deleting the queue. All agents assigned to the child physical queue will receive a message notifying them to log off of their MultiChannel Consoles when the logical queue is deleted.
Physical Queue	The Physical Queue field uniquely identifies that part of a logical queue serviced by the selected MCF cluster. Physical queue IDs always end in a number; for example, Sales2. The physical queue identifier automatically increments by one for each physical queue added. Physical queue IDs are automatically generated. The maximum number of physical queues is nine.
Cluster ID	The Cluster ID field identifies the MCF cluster that services this physical queue. Click Select Cluster to choose from configured MCF clusters. Each MCF cluster can only service one physical queue per logical queue. For example, an MCF cluster could service physical queue Sales1 or Sales2, but not both. An MCF cluster can service multiple physical queues belonging to different logical queues. For example, an MCF cluster could service physical queues Sales1, Marketing2, and COBOL1.
Select Cluster	Click Select Cluster to choose a cluster from a list of available MCF clusters. The selected MCF cluster will service this physical queue. The primary queue server in this cluster will manage tasks and agents assigned to this physical queue.
Active	Select Active or Inactive from the drop-down list box. The queue server will not send new tasks to an inactive physical queue. Agents and existing tasks will remain on an inactive physical queue. The physical queue must be active to receive new queued tasks. Only inactive physical queues can be deleted from a logical queue. Inactivate a physical queue and complete or transfer all assigned tasks before deleting the physical queue. Active and inactive status support “follow-the-sun” practices. For example, Sales1 could be supported in the London office, and Sales2 could be supported in the San Francisco office when the London office is closed by activating and inactivating the appropriate queues.