canderson | 2016-08-15 15:08:27 UTC | #1
I'm having problems setting up a callback in the future. The SDK calls for a DateTime object so I set that property on the command but the callback hits to the queue immediately.
I found this other thread that seems like it might be a related problem: https://developer.mypurecloud.com/forum/t/how-to-set-aggregation-query-granularity/85
Is the CallbackScheduledTime property supposed to be a string instead of a nullable datetime?
tim.smith | 2016-08-15 15:13:07 UTC | #2
Are you on the latest SDK version? There was an issue with how the .NET SDK was serializing DateTime objects that was fixed in 0.69.0.327.
Can you provide the correlation ID from the response and the DateTime value you're expecting to be sent? I can take a look at what actually came through.
canderson | 2016-08-15 15:27:50 UTC | #3
I wasn't on the latest SDK version but I am now. I was on 0.69.1.328, now I'm on 0.72.2.333, retrieved from Nuget.
I'm still having the problem.
I didn't see a Correlation Id when I looked at the response. I found this info, though:
Conversation Id: 9aa9095e-76ed-41a0-a6b3-7000fe197b68 Callback Id - External: 084af0e7-d055-40fe-8330-808fa52b6c70 Callback Id - ACD: a556afd7-1966-4374-96a8-4714ee5d5ba1
The date time I'm passing in is: 8/16/2016 3:00:00 PM
I'm setting it by allowing the user to select date and time in the local timezone, then doing this:
command.CallbackScheduledTime = datetime.Value.ToUniversalTime();
where "command" is a CreateCallbackCommand.
Thanks.
tim.smith | 2016-08-15 16:10:01 UTC | #4
It looks like there's a discrepancy with the dateTime value. The .NET SDK is sending the timestamp with a precision of 7 digits after the decimal for the seconds, but the API is rejecting the value entirely because it expects a precision of no more than 3 digits after the decimal. The analytics APIs allowed the larger precision, but it appears that the conversation APIs don't. I'm working with the dev team to determine where the fix is going to be made. I'll update this thread later with the resolution once we have one.
If you need a fix for this immediately, you can update the DateTime serializer to adhere to the shorter format required by the conversation service and compile the SDK locally.
canderson | 2016-08-15 16:18:06 UTC | #5
Appreciate the quick responses.
Looking at the DateTime serializer it looks like it's already calling ToUniversalTime(). Does that mean I should pass in a local time and let the serializer handle the conversion, or will calling ToUniversalTime() twice not cause any problems?
tim.smith | 2016-08-15 16:23:17 UTC | #6
It will make no difference if you call ToUniversalTime or if you include timezone information. The SDK will convert it to UTC either way; the .NET DateTime object knows if it has timezone information or is already in UTC. It's not strictly necessary for anyone to invoke it before sending the value since ISO-8601 supports specifying a timezone offset, but I think there may have been a bug or quirk I was working around so I left that call in there.
canderson | 2016-08-15 19:13:34 UTC | #7
I pulled down the code from GitHub, as you suggested, and modified the DateTimeConverter. The date format I have it outputting now is:
2016-08-16T07:10:00.000Z
Unfortunately, it is still immediately triggering the callback in the queue.
tim.smith | 2016-08-15 19:44:18 UTC | #8
canderson, post:7, topic:294
Unfortunately, it is still immediately triggering the callback in the queue.
I was hoping I would figure that out before you asked. :) I saw that as well. There's something wrong with the API itself and it's not passing the value to the back end (it's null). I'll let you know what I find on that one.
Edit: tracked as API-1850
tim.smith | 2016-08-15 20:47:10 UTC | #9
Good news: I have checked in a fix for the SDK for this issue. The fix truncates the fractional seconds to 3 digits to work around a core Java parsing issue in the server-side API.
Bad news: I can't publish a SDK build right this second because of an issue with the build server. Should be resolved this week though.
Mediocre news: This conversation is irrelevant at this point in time because the scheduled callbacks feature is not yet released. The property made it into the API documentation, but the API is intentionally clearing the value because the feature isn't available. It's pending other backend work and the current target is late Q3 or early Q4. Once the scheduled callbacks feature has been officially released, this parameter should begin working.
tim.smith | 2016-08-18 15:08:49 UTC | #10
The SDK now includes explicit DateTime formatting.
canderson | 2016-08-18 19:30:52 UTC | #11
Thanks for the update.
I do have a client that was planning on using this feature. Our current timeline has us in UAT during the middle of October. It would be great if this feature could be available to us by then.
I understand it's not completely under your control, but if you can keep this thread updated, I'd really appreciate it.
tim.smith | 2016-08-18 19:35:35 UTC | #12
You can keep an eye on the PureCloud Release Notes to find out when the scheduled callback feature is released.
canderson | 2017-01-11 20:25:55 UTC | #13
Tim, do you have an update on this? It was supposed to be released in Q3 or Q4 but I didn't see anything about it in the release notes. Did it get pushed back or did it just get missed in the release notes?
anon31479118 | 2017-01-11 23:12:14 UTC | #14
Scheduled callbacks are in Limited Availability at the moment pending the completion of analytics to support it. I apologize for any inconvenience this may cause you with the endpoint being exposed. We can submit your use case details, company and requirements to the appropriate PM for inclusion in the Limited Availability period, with the understanding that, during the LA period, there are no analytics. If this is something your company might be interested in doing, please let me know and we'll get the details over to the PM for discussion/decision.
Regards, Bill
system | 2017-08-28 19:26:27 UTC | #15
This post was migrated from the old Developer Forum.
ref: 294