SPMCSteve | 2019-05-21 19:53:41 UTC | #1
Just recomplied some code and now I'm getting this error:
{"Error calling PostAnalyticsUsersAggregatesQuery: {\"status\":400,\"code\":\"bad.request\",\"message\":\"Can not deserialize value of type com.inin.analytics.model.constants.DimensionApiModel from String \\\"queueId\\\": value not one of declared Enum instance names: [divisionId, organizationPresenceId, systemPresence, userId, routingStatus]\\n at [Source: java.io.PushbackInputStream@2c3232c0; line: 1, column: 96] (through reference chain: com.inin.analytics.api.v6.aggregates.AggregationQueryV6[\\\"groupBy\\\"]->java.util.ArrayList[0])\",\"messageParams\":{},\"contextId\":\"2631792b-fd6f-4397-9533-aad641454646\",\"details\":[],\"errors\":[]}"}
On a call to postanalyticsusersaggregatesquery.
I am only passing a userid, intervalstring (1 day) granularity of 1day and grouping by queueid and userid.
This code has worked fine for months and hasn't been changed. Anyone have any ideas? Is the system telling me I am now unable to group by QueueID for user analytics??? If so this is a major deal breaker for my client.
tim.smith | 2019-05-21 21:41:07 UTC | #2
I checked with the analytics dev team and they indicated that there hasn't been a change to which dimensions are allowed for user status aggregate queries and that grouping by queue was never a feature for that API. This is documented on the User Status Aggregate query page under Limitations:
Filtering and group-by is limited to the userId dimension only
SPMCSteve | 2019-05-23 00:34:12 UTC | #3
Well that's confusing as it had worked for 6+ months and has suddenly stopped.
I see now specifically what happened.
Previously this didn't result in an error it was just ignored, so the AggregationQuery object I was using between two calls could be reused. Now the user query throws the error, whereas it had ignored it before. I will adjust the code, but it is a change in behaviour for sure.
tim.smith | 2019-05-23 18:42:46 UTC | #4
SPMCSteve, post:3, topic:5209
Now the user query throws the error, whereas it had ignored it before.
These types of changes should be announced per the change management policy. It seems like this one slipped through likely because it wasn't changing anything about valid requests, though it is a change in behavior of the API.
system | 2019-06-23 18:42:47 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: 5209