Jump to: navigation, search

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

InteractionEntered

This momentary action is generated on a StagingArea (Interaction Queue) upon receiving the EventPlacedInQueue event or the EventSubmitted event with attr_itx_state = 0, when the interaction is entered into the specific Interaction Queue.

For more information about Stat Server actions, see InteractionEntered.

InteractionDistributedToQueue

This retrospective action is generated on a StagingArea (Interaction Queue1 specified with the attr_old_queue attribute) upon receiving the EventPlacedInQueue event on an Interaction Queue2 (specified with the attr_itx_queue attribute) when the interaction is entered into the Interaction Queue2 from the Interaction Queue1.

For more information about Stat Server actions, see InteractionDistributedToQueue.

InteractionDistributed

This retrospective action is generated on a StagingArea (Interaction Queue) upon receiving the EventTakenFromQueue event, when the interaction is diverted from the specific Interaction Queue to be processed by an agent based on Actor information (attr_party_type = 2) provided in the event. Note: At this point an association between the Interaction Queue and the interaction still exists.

For more information about Stat Server actions, see InteractionDistributed.

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

Extension:DynamicPageList (DPL), version 2.01 : Warning: No results.

InteractionCleared

This retrospective action is generated on a StagingArea (Interaction Queue) upon receiving the EventTakenFromQueue event, when the interaction is diverted from the specific Interaction Queue to be processed not by an agent based on Actor information (attr_party_type != 2) provided in the event. Note: At this point an association between the Interaction Queue and the interaction still exists.

For more information about Stat Server actions, see InteractionCleared.

Object Hierarchy

Relationships are defined between various contact center objects within Configuration Server. DNs are defined to a switch. Queues might be assigned to queue groups. Agents might be affiliated with places, and so forth. Relationships can exist only between compatible objects. The listing of objects for which interrelationships could exist form an object’s compatibility group. The Table below shows those groups of objects whose members Stat Server considers to be potentially compatible.

Stat Server Compatibility Groups
Regular DN
Compatibility Group
Mediation DN
Compatibility Group
Campaign
Compatibility Group
Interaction Queue
Compatibility Group
Routing Strategy
Compatibility Group
RegDN RoutePoint Campaign StagingArea RoutingStrategy
Agent Queue CallingList
Place GroupQueues CampaignGroup
GroupAgents Switch CampaignCallingList
GroupPlaces
Tenant

For telephony objects, some of these relationships are illustrated below. Objects' relationships defined within an Outbound campaign are illustrated in Hierarchy of Stat Server Campaign Objects. The Stat Server Java Extensions calculate statistics on multimedia objects, such as StagingArea, Tenant, and RoutingStrategy. Starting from release 8.5.1, Stat Server calculates regular statistics on StagingArea object type for InteractionCleared, InteractionCreated, InteractionDeleted, InteractionDistributed, InteractionDistributedToQueue, InteractionEntered, InteractionAbandonedDuringOffering, InteractionAccepted, InteractionAnswered, and InteractionReleased actions. For calculation of these statistics Stat Server Java Extensions do not need to be loaded. Despite similarity between some statistics calculated with Java Extensions on StagingArea and these regular statistics, they are designed differently and serve different purposes.

Hierarchy of Stat Server Telephony Objects

Hierarchy of Stat Server Telephony Objects

Associations Between Agents and DNs/Media Channels

Stat Server creates an association between an agent and a DN/media-channel using both the configuration data for the corresponding objects in the Configuration Layer, and the real-time events in the contact center. When an agent logs in to a DN or media-channel, the following sequence takes place:

  1. Stat Server takes a LoginID value from EventAgentLogin.
  2. Stat Server compares the LoginID value against the agent login objects that are configured for the corresponding switch in the Configuration Layer:
    • If a matching Agent Login object exists, Stat Server checks whether it is assigned to any Person configuration object that has been configured as an agent (that is, with the Is Agent check box selected). The agent whose configuration contains the specified Agent Login is linked with the DN/media-channel.
    • If no matching Agent Login object exists, or if it exists without an association with any Person configuration object, Stat Server checks the configuration of all Person objects that have the Is Agent check box selected. The agent whose configuration contains an Employee ID that matches the LoginID value from EventAgentLogin is linked with the DN/media-channel.
    • If neither Agent Login nor Employee ID in the configuration matches the LoginID value from EventAgentLogin, Stat Server does not associate any agent with the DN/media-channel.

DN Association with Queues

For every queue, the login correspondence defines the list of DNs that currently are logged in to the queue. This correspondence also can be considered to define, for every regular DN, the list of queues to which the DN is currently logged in. The login correspondence between queues and regular DNs is updated whenever Stat Server receives EventAgentLogin with a nonnull value specified for the ThisQueue attribute, EventQueueLogout, or EventAgentLogout from T-Server.

When Stat Server receives EventAgentLogin for a DN, the list of queues becomes the union of the list of queues to which the DN was logged in before the event was received plus the set of queues that include the following:

  • Any queue that is received if the ThisQueue attribute was received with the event.
  • All queues that are listed in the Configuration Database as OriginationDN objects for groups of places that contain a place that is linked to the DN that received the EventAgentLogin TEvent.
  • For Stat Server 8.1.0-, all queues that are listed in the Configuration Database as OriginationDN objects for groups of agents that contain an agent who is logged in (after the event is received) at a place that is linked to the DN that received EventAgentLogin. (Here you can find more information about how Stat Server determines when an agent is logged in at a place for Stat Server 8.1.0-.)

When Stat Server receives EventQueueLogout, it:

  1. Adds a record to the LOGIN table of the Stat Server database. Stat Server only logs out the queue, and preserves the DN’s association with other queues, if any, as well as its association with a particular agent.
  2. Updates the affected, “logged-in” virtual agent groups by removing the agent from such groups.
  3. Unlinks the Queue object from the agent who is logged into the DN, by updating the AgentLogin, AgentReady, and AgentActive actions for the affected queue.
  4. Unlinks the Queue object from the DN that received the EventAgentLogin TEvent, by updating DNLogin, DNReady, and DNActive actions for the affected queue.

When Stat Server receives EventAgentLogout for a DN, the logged-in list of queues becomes empty.

Stat Server’s support of the EventQueueLogout TEvent was introduced in the 7.0.3 release. The scenario below illustrates what Stat Server records to its database given different releases of T-Server and Stat Server.

Sample Database Entries Given Differing Component Versions

The records Stat Server writes to its LOGIN table differ, depending on the versions of T-Server and Stat Server deployed in this environment. The Tables below illustrate the differences, given the following scenario:

On the G3 switch, Agent Ryan has three login IDs which are assigned only to him:

  • 2124 for logging into the system
  • 2126 for logging in to queue 8001
  • 2128 for logging in to queue 8002

He is usually stationed at place Sales21, which has a phone with one DN configured—601.

On one particular day, Ryan arrives at work and logs in to DN 601 at 10:00 AM. At 10:01, he logs in to queue 8001 to start receiving the calls from this queue. Four minutes pass before he determines that he can handle calls from an additional queue, so he logs in to queue 8002 at 10:05. At 10:40, however, he concludes that he can no longer handle calls from both queues, so he immediately logs out of 8002. At 10:50, he breaks for lunch and logs out of the system.

Stat Server writes records 4 and 5 (in Table "LOGIN Entries Given T-Server 6.5 and Stat Server 7.0.2 (or prior)") to the LOGIN table, because in T-Server 6.5, there was no notion of logout from just one queue—the EventQueueLogout TEvent did not exist. Instead, the model, at that time, called for the logging out of all queues (by sending the EventQueueLogout TEvent) and then the logging back in of the remaining queue(s).

Tip
LOGIN Entries are presented here in pseudo-table format. Refer to “The LOGIN Table” section in the Appendix of the Framework Stat Server Deployment Guide for the actual format of this table.
LOGIN Entries Given T-Server 6.5 and Stat Server 7.0.2 (or prior)
Record# Switch DN Queue Agent Place Status Time LoginID
1 G3 601 Ryan Sales21 LoggedIn 10:00 2124
2 G3 601 8001 Ryan Sales21 LoggedIn 10:01 2126
3 G3 601 8002 Ryan Sales21 LoggedIn 10:05 2128
4 G3 601 Ryan Sales21 LoggedOut 10:40
5 G3 601 8001 Ryan Sales21 LoggedIn 10:40 2126
6 G3 601 Ryan Sales21 LoggedOut 10:50

The latest version of T-Server 7.0 and forward releases, however, do send the EventQueueLogout TEvent—but Stat Server versions prior to 7.0.3 did not recognize it as noted in the table below.

LOGIN Entries Given T-Server 7.0+ and Stat Server 7.0.2 (or prior)
Record# Switch DN Queue Agent Place Status Time LoginID
1 G3 601 Ryan Sales21 LoggedIn 10:00 2124
2 G3 601 8001 Ryan Sales21 LoggedIn 10:01 2126
3 G3 601 8002 Ryan Sales21 LoggedIn 10:05 2128
4 G3 601 Ryan Sales21 LoggedOut 10:50

In the Table below, notice that Stat Server does add record # 4 upon receipt of the EventQueueLogout TEvent. In doing so, Stat Server logs out neither the DN nor the place.

LOGIN Entries Given T-Server 7.0+ and Stat Server 7.0.3+
Record# Switch DN Queue Agent Place Status Time LoginID
1 G3 601 Ryan Sales21 LoggedIn 10:00 2124
2 G3 601 8001 Ryan Sales21 LoggedIn 10:01 2126
3 G3 601 8002 Ryan Sales21 LoggedIn 10:05 2128
4 G3 601 8002 Ryan Sales21 LoggedOut 10:40
5 G3 601 0 Ryan Sales21 LoggedOut 10:50

Stat Server’s receipt of the EventAgentLogout TEvent logs out all queues and DNs to which Ryan was logged in. Stat Server does not write a queue value to the record upon receipt of EventAgentLogout.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on August 31, 2015, at 13:30.