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.
Contents
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
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:
- Stat Server takes a LoginID value from EventAgentLogin.
- 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:
- 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.
- Updates the affected, “logged-in” virtual agent groups by removing the agent from such groups.
- 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.
- 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).
| 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.
| 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.
| 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.