MRE Architecture & Communication Flow

Getting Started

This guide describes the concept of Precision Queue, its contributing elements, and configuration. MRE triggers (getting newly created agents from UMM, new configuration application in MRE, task selection triggers in MRE) and limitations of MRE (MRE, Mre Microservice & Mre UI).

Architecture and Communication Flow

Following components are involved in MRE:

MRE

Mre is a Java-based backend service that routes tasks to agents. MRE contains routing logic, when a new task is initiated, this task is enqueued in a precision queue in MRE which routes this task to Longest Available Agent

Mre-Microservice

Mre-microservice is Node.js based backend API which is directly connected to MongoDB and stores the following configurations in the database:

Agents (replica of UMM agents)
Attributes
MRDs
Precision Queues

MRE Microservice exposes APIs for CRUD of mentioned configurations

MRE-UI

Mre-UI is UI part of Mre-Microservice which consumes these APIs and is used to CRUD operations of these configurations. MRE-UI connects to Mre-Microservice via UMM (UMM is middleware for microservice architecture).

UMM

User Management Module stores agents in its database which is accessible via its APIs.

The following diagram shows the flow of communication between these components.

In this image, green-colored boxes represent ActiveMQ queues, and other boxes represent Media Routing Engine components.

The communication flow is as follows:

Administrator logs into MRE-UI, this request is sent to UMM for authentication
MRE-UI fetches data from Mre-Microservice via UMM
When clicked on the Agents tab, MRE-Microservice fetches agents from UMM to sync if any new agent is added in UMM, Agents list takes some time to load in MRE-UI and this is the reason for its slowness
When / if new agents are added, Mre-Microservice pushes this information to the “routing engine” queue, MRE listens to this queue and receives that information
Mre updates its agent list
When an attribute / mrd/ precision queue is added is Mre-UI, Mre-microservice pushes this information to “routing engine” queue from where MRE gets this information and acts accordingly

MRE Start / Restart Steps

When MRE is restarted/started, the following steps are performed:

MRE calls UMM API to get all agents (depending upon user type i.e. CC or DB)
MRE associate all agents with Default Precision Queue
MRE pushes the following commands to the mre-microservice queue in the same order as written below

Get all Attributes
Get all Agents
Get all MRDs
Get all Precision Queues

Mre-Microservice consumes messages from the mre-microservice queue, gets the information from DB according to a command received, and pushes data to the “routing engine” queue.
MRE receives configuration events from the “routing engine” queue and acts accordingly

How Media Routing Works

Media Routing Features & Definitions

MRD (Media Routing Domain)

MRD organizes how requests for each communication medium are routed to agents. An MRD for each media channel is configured in deployment.

Types of MRDs

These are major categories:

Interactive/Non-Interactive MRDs
Interruptible/Non-Interruptible MRDs

Interactive/Non-Interactive MRDs

Interactive MRDs maintain a session b/w customer and agent, in which both communicate in real-time. E.g. chat, SMS, etc.

Non-interactive MRDs do not maintain a session. E.g. eMail. These tasks are asynchronous as customers can send an eMail, close the window, and check back later for a response.

Interruptible and Non-Interruptible MRDs

Interruptible: Agents handling tasks in the MRD can be interrupted by tasks from other MRDs. Non-interactive MRDs, such as an email MRD, are typically interruptible.
Non-Interruptible: Agents handling tasks in the MRD cannot be interrupted by tasks from other MRDs. The agents can be assigned tasks in the same MRD, up to their maximum task limits.

MRE only supports Interruptible & Interactive MRDs until this version. Non-Interactive & Non-interruptible MRDs support is still in pipeline

Engine Components

Media Routing Engine consists of two components:

Communication Server
Routing Engine

Following is a brief introduction of both components:

Communication Server

Communication Server manages the Agent States & Task States for non-voice MRDs. Communications Server subscribes to Finesse notifications for Agent & Dialogs Voice MRD states. It enables the Communication Server to provide Media Blending.

Routing Engine

n-interruptible chat tasks; if the agent is currently handling two chat tasks, the media routing engine can assign the agent another chat, but cannot interrupt the agent with an email. Interactive MRDs, such as a chat MRD, are typically non-interruptible. Voice is non-interruptible.
Mixed: agent's active chat sessions will remain active while he'll continue to receive the inbound call as well because MRE will not change the agent's Finesse state.

Handling interrupts

Following approaches are used to handle interrupts:

Accept Interrupts
- When an agent is interrupted by a task from a non-interruptible MRD while working on a task in an interruptible MRD, an interrupt event is accepted.
- The agent state in the interrupted MRD change to INTERRUPTED.
- The agent cannot perform dialog actions while a task is interrupted.
Ignore Interrupts
- When an agent is interrupted by another task while working on a task in an interruptible MRD, the interrupt event is ignored.
- The new task does not affect any of the agent's other assigned tasks. The agent state & task dialog state in the interrupted MRD does not change.

Mixed-mode for routing is not supported as per this release, so is Ignore Interrupts.

The agent can perform dialog actions on original task and the interrupting task at the same time. The agent's time on the original task does not stop while the agent is handling the interrupting task.

Example: An agent has an email task for 20 minutes, and is interrupted for 3 of those minutes with a chat task. The handled time for the email task is 20 minutes, and the handled time for the chat task is 3 minutes. This means that during a 20-minute interval, the agent handled tasks for 23 minutes.

Max Concurrent Tasks per agent per MRD

Hybrid Chat allows you to configure the maximum number of chat sessions an agent can handle at any given point. Max Concurrent Tasks Limit can be configured in Communication Server properties. However, the default max concurrent tasks limit is 5.

Tasks Routing to Agent

It depends upon:

Agent State: Agent’s state in MRD. Following are agent states

Ready
Reserved/Active/Work-Ready/Interrupted/Busy
Not-Ready

* Every MRD has its own state

Conditions for a task to be routed

The task is routed to the agent if ALL these conditions are TRUE:

The agent is in the ready state, AND
The agent has not reached Max task limit in MRD, AND

The agent is NOT working on a task in a different Non-Interruptible MRD.

Scenario	State	Description
If the agent is in between a conversation but the state is pending not ready	PENDING_NOT_READY	No more tasks will be routed to the agent until he changes his state from pending not ready to the ready state.
If the agent is in an active state and has reached Max task limit	ACTIVE	No more tasks will be routed to the agent, as he is already handling a number of chats and has reached the limit of Max task limit, and the state will be changed to busy.
If the state is ready and Max task limited has not reached	READY	The task will be routed to the agents.
If the agent is in an interrupted state	INTERRUPTED	No chat will be routed to that agent in the INTERRUPTED state, agent chat state will be restored when the voice call ends.

Agent Selection Criteria

The agent is selected on the following criteria:

Longest Available: The task is routed to an agent who was available for the longest time i.e.

The agent is in the READY state for the longest time AND the agent is handling no tasks, OR
When all the agents are in ACTIVE/BUSY state then the agent who is in ACTIVE state for the longest time AND does not has more active tasks than any other available agent.
The following table shows an example when there are 3 agents available for the Chat MRD:
Agent Current State
&
State Change Time Previous State Number of
Active Chat
Tasks
Agent 1 READY
Time: 10:00 NOT READY 0
Agent 2 READY
Time: 10:05 NOT READY 0
Agent 3 READY
Time: 10:10 NOT READY 0

A new task arrives and is routed to Agent 1 at 10:15 because he was available in the READY state for the longest time i.e.
Agent Current State
&
State Change Time Previous State Number of
Active Chat
Tasks
Agent 1 ACTIVE
Time: 10:15 READY 1
Agent 2 READY
Time: 10:05 NOT READY 0
Agent 3 READY
Time: 10:10 NOT READY 0
A new task (#2) arrives and is routed to Agent 2 at 10:20 because he was available in the READY state for the longest time i.e.
Agent Current State
&
State Change Time Previous State Number of
Active Chat
Tasks
Agent 1 ACTIVE
Time: 10:15 READY 1
Agent 2 ACTIVE
Time: 10:20 READY 1
Agent 3 READY
Time: 10:10 NOT READY 0
A new task (#3) arrives and is routed to Agent 3 at 10:25 because he was available in the READY state for the longest time i.e.
Agent Current State
&
State Change Time Previous State Number of
Active Chat
Tasks
Agent 1 ACTIVE
Time: 10:15 READY 1
Agent 2 ACTIVE
Time: 10:20 READY 1
Agent 3 ACTIVE
Time: 10:25 READY 1
A new task (#4) arrives and is routed to Agent 1 at 10:30 because he was available in the ACTIVE state for the longest time i.e.
Agent Current State
&
State Change Time Previous State Number of
Active Chat
Tasks
Agent 1 ACTIVE
Time: 10:15 READY 2
Agent 2 ACTIVE
Time: 10:20 READY 1
Agent 3 ACTIVE
Time: 10:25 READY 1
In the same fashion MRE will assign task # 5 to Agent 2 and task # 6 to Agent 3.

Precision Queue Routing

Precision routing offers a multidimensional alternative to skill group routing. Routing Engine runs on precision queues.

To configure Precision Routing, you must do the following in Media Routing Engine Administration:

Create attributes. Attributes are characteristics that can be assigned a True | False value or a Proficiency rating from 1 to 10.
Assign attributes to agents. Routing Engine fetches agents from EF User Management Module.
Create precision queues. Create Expressions and Steps while creating Precision Queues.

There is no need to add an agent to a precision queue; agents become members of precision queues automatically based on their attributes. If a precision queue requires an agent who lives in Boston, who speaks fluent Spanish, and who is proficient in troubleshooting a specific piece of equipment, an agent with the attributes Boston = True, Spanish = True, and Repair = 10 is automatically part of the precision queue. A Spanish caller in Boston who needs help with equipment is routed to that agent.

A precision queue includes:

Terms: A term compares an attribute against a value. For example, the administrator can create the following term: Spanish == 10. The term of the attribute is the highest proficiency in Spanish. Each precision queue can have multiple attributes, and these attributes can be used in multiple terms. For example, to select an agent with a Spanish proficiency value between 5 and 10, one term for Spanish > 5 and another for Spanish < 10 would be created.
Expressions: An expression is a collection of one or more terms. The terms in an expression must share the same operator—they must all be AND or must all be OR relationships.

Steps: A precision queue step is a time-based routing point within the precision queue. A step is a collection of one or more expressions. A step may also include wait time. Use wait time to assign a maximum amount of time to wait for an available agent.

The default queue used for Task Routing is the FIFO queue.

FIFO Queue

This is the default queue used in the Routing Engine. The first task to enter the queue is the first to be served. Precision Routing uses FIFO queues.

Task Scheduler

The Task Scheduler decides which of the available agents is to be allocated the next task after a signal or property change.

Task Scheduler Invocation

Here are events/signals/property changes which invoke Task Scheduler for a specific queue in an MRD:

An agent changes state to READY for the MRD

A possibility of an unattended task in queue remains when an agent changes state to READY for MRD i.e. task is in queue and 1st agent gets READY for handling.

A new task arrives for the MRD
- Possibility of an unattended task in queue remains in this scenario e.g. Single agent handling tasks, voice call interrupts tasks, new tasks arrived and agent state was INTERRUPTED so he was not selected on new task arrived trigger, and after end of voice call, agent becomes ACTIVE/READY. Trigger in following bullet states this issue.
Agent state transition from INTERRUPTED to ACTIVE/READY for the MRD

Possibility of unattended task in queue remains in this scenario e.g. Single agent handling tasks, voice call interrupts tasks, new tasks arrived and agent state was INTERRUPTED so he was not selected on new task arrived trigger, and after end of voice call, agent becomes ACTIVE/READY

Agent state transition from BUSY to ACTIVE for the MRD

Possibility of unattended tasks in queue e.g. agent is busy with max task sessions, new task arrives and is not assigned to the agent, after sometime agent ends a task.

Every queue in an MRD has its own Task Scheduler.

FIFO Queue

This is the default queue used in Routing Engine. First task to enter queue is the first to be served. Precision Routing uses FIFO queues.

Default Precision Queue

Upon startup, MRE fetches all agents from UMM with the MRE_Agent role. MRE creates a precision queue named DefaultPrecisionQueue and associates all agents with this queue. Meaning any task submitted to this queue will be routed to any available agent.

Limitations

As per current release, here are limitations regarding MRE, Mre-Microservice & MRE-UI:

Attributes must not be deleted in MRE-UI, otherwise unexpected behavior cannot be avoided
Precision queues can be updated but not be deleted in MRE-UI, if a precision queue is deleted, MRE will need to be restarted to take effect

Agent	Current State & State Change Time	Previous State
Agent 1	READY Time: 10:00	NOT READY
Agent 2	READY Time: 10:05	NOT READY
Agent 3	READY Time: 10:10	NOT READY

Agent	Current State & State Change Time	Previous State	Number of Active Chat Tasks
Agent 1	ACTIVE Time: 10:15	READY	1
Agent 2	READY Time: 10:05	NOT READY	0
Agent 3	READY Time: 10:10	NOT READY	0