joel_hellman | 2022-04-13 15:57:00 UTC | #1
I'm using the AWS S3 export and the POST recording jobs endpoiint with an query analytics payload to target the conversations where conversations should be exported.
In the docs above for the conversationQueryAsyncConversationQuery parameter it says (my highlight)
conversationQueryAsyncConversationQuery Conversation Query. Note: After the recording is created, it might take up to 48 hours for the recording to be included in the submitted job query.
The actual export to AWS seems to complete pretty fast, but as I used the post recording jobs endpoints to select the conversations to export, I noticed that although my query analytics query yielded 20 conversations, when I created the export to AWS job, the job poll it said it only found 16 conversations.
In my case, I had conversations that were less than 48 hours old. I can't confirm it but altough the AWS export itself is quick, it the https://developer.genesys.cloud/analyticsdatamanagement/recording/#post-api-v2-recording-jobs endpoint not suitable for exporting more recent export?
In my case, all the 20 recordings are available in the Genesys UI, but 4 conversations that ended 8 hours after I run the https://developer.genesys.cloud/analyticsdatamanagement/recording/#post-api-v2-recording-jobs were reported to not be included in the AWS export.
Can you clarify if the AWS export endpoint as I use it here is not able to pick up more recent recording, i.e. that this export to AWS S3 is bound (the same?) restrictions as the query jobs are, i.e. longer-interval jobs that will make it unsuitable to export more recently ended calls?
If that's the case, is the only option to fall back to downloading more recently ended calls to use the analytics query together with https://developer.genesys.cloud/analyticsdatamanagement/recording/#post-api-v2-recording-batchrequests and then manually download them from the URIs the batchrequest endpoints yields?
In my case, using the built in Admin > Policy > AWS S3 export option is not usable because we need to apply some pre-filtering that is not supported by that interface.
joel_hellman | 2022-04-22 08:46:55 UTC | #2
Perhaps you have some insight here @Jerome.Saint-Marc ?
Jerome.Saint-Marc | 2022-04-22 10:18:37 UTC | #3
Hello,
Unfortunately, I don't. I mean I know that a recording can only be exported once (via API/manual export or via Policy) as mentioned in the Create a policy page: "Note: Genesys Cloud exports recordings one time. If you create an export that matches a recording that has already been exported, that recording will be skipped."
I don't know if this can help troubleshoot but you could have a look at what is returned using GET /api/v2/conversations/{conversationId}/recordingmetadata or GET /api/v2/conversations/{conversationId}/recordingmetadata/{recordingId} I mean if exportDate or exportedDate attributes are set. In this case, I'd assume the recording cannot be exported again.
If that doesn't appear to be related to this, I'd suggest to open a ticket with Genesys Cloud Customer Care as we can't investigate customer data/logs from the forum.
Regards,
joel_hellman | 2022-04-22 12:45:50 UTC | #4
Thanks for the reply. My concern is about the difference in delay from call ended and recording being available in Genesys, and the recording being exportable using the AWS S3 export triggered via API, and the issue here doesn't seem related from what I can see to whether I'm doing multiple export attempts or not.
My expectation was that triggering the AWS S3 export via API would export the recordings if the recording was available in the org, as the S3 export you can set built-in Admin > Policy does.
The actual seems to be the export jobs analytics query used in the API-triggered version of the S3 export imposes the limitations set by an analytics query job, even though the record is technically ready to be exported (=as in, available with an analytics query). With the result of not being able to export recent call recordings, but having to delay the exports for quite a while from the time the call ended.
But I'll do some more tests, and see if I can find a clear pattern.
tim.smith | 2022-04-22 13:34:18 UTC | #5
quote="joel_hellman, post:1, topic:14313"] In my case, I had conversations that were less than 48 hours old. I can't confirm it but altough the AWS export itself is quick, it the [https://developer.genesys.cloud/analyticsdatamanagement/recording/#post-api-v2-recording-jobs endpoint not suitable for exporting more recent export? [/quote]
Take note of the concept of data availability for analytics jobs: https://developer.genesys.cloud/analyticsdatamanagement/analytics/jobs/conversation-details-job#data-availability. Depending on when you're querying, jobs will have data including and up to 24 to 0 hours ago.
joel_hellman, post:4, topic:14313
The actual seems to be the export jobs analytics query used in the API-triggered version of the S3 export imposes the limitations set by an analytics query job , even though the record is technically ready to be exported (=as in, available with an analytics query ).
You are correct. The AWS S3 integration uses an analytics job query in the background and thus comes with the same data availability considerations. I've asked that this information be included in the AWS S3 integration documentation.
joel_hellman | 2022-04-22 13:47:44 UTC | #6
Thanks Tim. And I assume there is no alternative here to switch from the job to i.e. using a query or similar? Since I know that the S3 Export integration used in Admin > Policy, seems to not have that restriction.
ralegner | 2022-04-22 13:54:11 UTC | #7
The bulk recording endpoint needs to source analytics data from an endpoint that's designed for bulk requests. This is why it queries specifically the analytics jobs endpoint because it's designed to query large amounts of data. As a consequence it comes with the caveat that it can't be updated in realtime which by nature is why the bulk exports can't get recordings in realtime. It's not designed to feed recordings in in realtime.
Policy based exports can trickle in and query the data at a much slower rate, something that's more typical of a production feed of data that the system is designed to handle. That would open us up for production performance issues if the bulk endpoint switched to hitting the analytics realtime details endpoints.
joel_hellman | 2022-04-22 13:57:17 UTC | #8
That makes sense. Thanks guys for helping me clarify the situation! :grinning:
system | 2022-05-23 13:57:59 UTC | #9
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: 14313