Legacy Dev Forum Posts

wchavez | 2020-07-23 16:29:37 UTC | #1

Good morning forum:

The NOTRESPONDING routing status for all operation queues needs to be monitored. I am testing some Platform APIs in order to get and filter information about the NOTRESPONDING routing status of an specific queue, and I found the Analytics Queue Observations API endpoint:.

We need to get three questions answered in order to check if this API would be enough for our purposes:

1. Why the response is the same for a queue when I use a chat or voice media type predicate? Response gotten: "Unable to decompose query into a set of (queueId, mediaType) pairs."
2. By the time I tested the API I had understood that metric filters, like tNotResponding, are not supported; how or what API endpoint can we use in order to filter the NOT_RESPONDING count based on tNotResponding metric greather than X value?
3. How can we group this observations per queue in order to get a result as: "{queueId1-->#agentsWithNotResponding, "queueId2-->"#agentsWithNotResponding", ...}".

Thank you.

wchavez | 2020-07-23 16:56:25 UTC | #2

I am testing too the Notifications API. I can have this information gotten by subscribing to "v2.analytics.queues.{id}.observations" topic.

I identified the difference of the NOTRESPONDING count statistics with two queues which have some agents in common; I could not see that difference when I use the Analytics Queue Observations API endpoint. In a test I did an agent was not answering an inbound interaction in QueueA and I requested the NOTRESPONDING count statistic in QueueB - that has that agent in common - and then, as a result, the API response had the same count in NOT_RESPONDING for both queues A and B. Is it how it behaives?

Thank you.

tim.smith | 2020-07-24 14:04:05 UTC | #3

wchavez, post:1, topic:8373
Why the response is the same for a queue when I use a chat or voice media type predicate? Response gotten: "Unable to decompose query into a set of (queueId, mediaType) pairs."

I can't say for sure since I don't know what your query was, but you need to have a filter for mediaType AND queueId. If either is missing or you use an OR filter, you'll get that error.

wchavez, post:1, topic:8373
By the time I tested the API I had understood that metric filters, like tNotResponding, are not supported; how or what API endpoint can we use in order to filter the NOT_RESPONDING count based on tNotResponding metric greather than X value?

Observation queries can only request observation metrics (ones that start with o). The valid values are documented on the resource's request: POST /api/v2/analytics/queues/observations/query. To get routing statuses, use oUserRoutingStatuses.

wchavez, post:1, topic:8373
How can we group this observations per queue in order to get a result as: "{queueId1-->#agentsWithNotResponding, "queueId2-->"#agentsWithNotResponding", ...}".

This is what a well-formed queue observation query does.

wchavez, post:2, topic:8373
I identified the difference of the NOTRESPONDING count statistics with two queues which have some agents in common; I could not see that difference when I use the Analytics Queue Observations API endpoint. In a test I did an agent was not answering an inbound interaction in QueueA and I requested the NOTRESPONDING count statistic in QueueB - that has that agent in common - and then, as a result, the API response had the same count in NOT_RESPONDING for both queues A and B. Is it how it behaives?

A routing status is a property of a user, not a queue, and a user always has exactly one routing status at a time. When you make a queue observation query for a queue, it considers the users that are members of that queue and tallies their routing statuses. Whether or not the user is a member of other queues is irrelevant to computing the data for the requested queue.

wchavez | 2020-07-29 15:07:33 UTC | #4

Thank you Tim for your explanations. They were clear to me.

system | 2020-08-29 15:07:39 UTC | #5

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.

This post was migrated from the old Developer Forum.

ref: 8373