Configuring PeopleSoft MCF Queues and Tasks

This chapter discusses how to:

Define queues.
Configure tasks.
View the cluster summary .
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	Define 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, cannot end in a numeral, but can 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 that are assigned to the child physical queue will receive a message notifying them to sign out of their MultiChannel Consoles when the logical queue is deleted.

Physical Queue

Identifies that part of a logical queue that is 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 that is added.

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

MCF Cluster ID

Identifies the MCF cluster that services this physical queue. Click Select Cluster to choose from configured MCF clusters.

Each MCF cluster can service only 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 to select 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 that are 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 that are specified on this page are available to all agents who are signed in to this queue.

Contact Type

Select 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

Enter 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

Enter 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

Enter the queue push URL.

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

All static URLs that are 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
MCF Task Configuration	MCF_TASKCFG_PG	Use one of the following navigation paths: PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Tasks PeopleTools, Multichannel Framework, Third-Party Configuration, Tasks	Configure tasks such as chat, email, voice, and generic alerts using the queue server or third-party routing system.

Page Name

Object Name

Navigation

Usage

MCF Task Configuration

MCF_TASKCFG_PG

Use one of the following navigation paths:

PeopleTools, MultiChannel Framework, Universal Queue, Configuration, Tasks

PeopleTools, Multichannel Framework, Third-Party Configuration, Tasks

Configure tasks such as chat, email, voice, and generic alerts using the queue server or third-party routing system.

Configuring Tasks

Access the MCF 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.

After you define or change values for a task, you must use Refresh Task Properties button on the Cluster Notify page to propagate the changes to clusters. If you are working with MCF tasks, use the Cluster Notify page (MCF_CL_NOTIFY_PG) by navigating to PeopleTools, Multichannel Framework, Universal Queue, Configuration, Notify Cluster. If you are configuring third-party tasks, use the third-party Cluster Notify page (MCFTP_CL_NOTIFY_PG) by navigating to PeopleTools, Multichannel Framework, Third-Party Configuration, Cluster Notify.

Default Cost of Task	Enter the cost of the task. Cost is a measure of the workload that each task places on an agent. The cost of a task is an estimate of the task's expected complexity and of the time that is required to resolve the task. The minimum value is 0, and no maximum value exists. The costs of tasks that are assigned to an agent are added up and evaluated against the maximum workload for each agent to determine whether 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	Enter 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 no maximum value exists. 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 that is 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	Enter the minimum agent skill that is required to handle this task. The queue server assigns this task type to an available agent with the lowest skill level on that queue that is greater than or equal to the skill level that is required by the task. The minimum value is 0, and is no maximum value exists. The value that is 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 : 2 Note. Only the third-party routing server supports voice channel. The queue server does not route voice tasks.
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 that is 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 : 10 Note. Only the third-party routing server supports voice channel. The queue server does not route voice tasks.
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 that is 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: 1 Note. Only the third-party routing server supports voice channel. The queue server uses CTI to route voice tasks.
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 valid on a chat session only after it is accepted by an agent, and has no effect on voice tasks (CTI). The value that is specified here can be overridden in the EnQueue() or InitChat() built-in function call. Default escalation timeouts are: Chat: 10 Email: 480 Generic: 480 Voice : 2 Note. Only the third-party routing server supports voice channel. The queue server uses CTI to route voice tasks.
Seed for Sequence Number	This field displays the current cumulative count of tasks of this type that are 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 that is 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.

If you make changes to a cluster parameter, you must use the Notify Cluster page to propagate the changes.

See Notifying Clusters of Changed Parameters.

The following table lists the cluster tuning parameters you can modify and describes the default values and usage of each.

Key	Default value	Usage
bcastinterval	60	The interval, in seconds, after which the number of unassigned tasks per physical queue and the number of agents that are 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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Using the Monitor Queues Page and Sample Monitor - Queue Statistics Page, Using the Monitor Agents Page and Sample Monitor - Agent States Page.
clhbinterval	30	The 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. For a queue server, to avoid a session timeout for the client when CPU usage of the machine on which the client is running is high, increase the heartbeat interval of the client. Note. For third-party server, increase the heartbeat interval on the third-party server side to avoid a session timeout. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Using and Demonstrating JSMCAPI.
donelistsize	100	The number of completed tasks that are stored in the list that is used to calculate average task duration. Configure the donelistsize value depending on the task volume that is encountered and the interval over which you want to monitor tasks. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Using and Demonstrating JSMCAPI.
dumpagents	No	Enter 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 about agent performance. This is a task parameter. If you change the value of this parameter you must use the Refresh Task Properties button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Viewing the Agent State Summary.
dumpinterval	600	The 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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Viewing the Queue Server State, Viewing the Queue State Summary.
highwater	100	The maximum number of persistent tasks that are retrieved from the database and cached in memory in the queue server. The highwater 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. This is a threshold parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
logDMPQ	No	Enter Yes if you want PSMCFLOG to log REN server event notifications resulting from bcastinterval broadcasts. Only the event is logged, not its contents. This is a logging parameter. If you change the value of this parameter you must use the Refresh Logging Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Viewing Event Logs.
logStat	No	Enter Yes to log the statistics that are returned by the queue server for the onStat1 user and group events to the database. This is a logging parameter. If you change the value of this parameter you must use the Refresh Logging Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Using and Demonstrating JSMCAPI.
log_broadcast	No	Enter Yes to activate logging of the broadcast messages that are sent. This is a logging parameter. If you change the value of this parameter you must use the Refresh Logging Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Viewing Broadcast Logs.
log_chat_ses	No	Enter Yes to activate logging of the contents of chat sessions. This is a logging parameter. If you change the value of this parameter you must use the Refresh Logging Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Viewing Chat Logs.
log_cti	No	Select Yes to activate logging of CTI events. This is a logging parameter. If you change the value of this parameter you must use the Refresh Logging Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, CTI Event Logging.
lowwater	5	The minimum number of persistent tasks that are 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 highwater 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. The lowwater value should be greater than or equal to the maximum number of agents that are logged onto any physical queue at one time. This is a threshold parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
masterinterval	15	The interval, in seconds, after which a cluster master updates its timestamp in its cluster tables. Slave clusters check the timestamp to determine whether 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 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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
reeperinterval	60	The interval, in seconds, after which deleted tasks 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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.
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. This is a task parameter. If you change the value of this parameter you must use the Refresh Task Properties button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters, Using and Demonstrating JSMCAPI.
timinginterval	60	The 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. This is a timing parameter. If you change the value of this parameter you must use the Refresh Threshold/Timing Parameters button on the Cluster Notify page to notify clusters of the changed parameter. See Notifying Clusters of Changed Parameters.

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 or 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 or 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 all agents who are 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/timing parameters	Click to reload threshold and timing parameters that have changed on the Cluster Tuning page for the selected MCF cluster.
Refresh logging parameters	Click to reload logging parameters that have 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, cannot end in a numeral, but can 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 that are assigned to the child physical queue will receive a message notifying them to sign out of their MultiChannel Consoles when the logical queue is deleted.
Physical Queue	Identifies that part of a logical queue that is 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 that is added. Physical queue IDs are automatically generated. The maximum number of physical queues is nine.
MCF Cluster ID	Identifies the MCF cluster that services this physical queue. Click Select Cluster to choose from configured MCF clusters. Each MCF cluster can service only 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 to select 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 that are 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.