TimoV | 2021-05-27 17:40:58 UTC | #1
Hi,
This has been asked before: https://developer.genesys.cloud/forum/t/how-to-identify-a-conversation-start-and-end-from-subscribed-notification-events/4345/2
Back then the response was: " Look at the participants. The earliest value for connectedTime is when the conversation started. If all participants have a value for endTime the conversation is disconnected and the latest value is when the conversation ended."
We're struggling with the same question and when comparing data we get out of Conversation Detail REST endpoint and notifications service, it seems that earliest 'connectedTime' does not reflect to conversation start.
On notifications service side, first occurence of 'connectedTime' is seen when we get first event having participant state set to connected ("state": "connected"). For all the events before that one, connectedTime attribute does not exist. Value of 'connectedTime' is not start time of the conversation, but start of the participant being connected. This can be seen by comparing conversation detail data for the same call, conversation start time is roughly first connectedTime minus dialing time.
Is this by design or a defect? If by design, is there a reliable way of determining the conversation start time?
Jerome.Saint-Marc | 2021-06-01 14:23:26 UTC | #2
Hello,
What you are looking for should correspond to the startTime attribute in the conversation context (retrieved with GET /api/v2/conversations/{conversationId}).
If the question is about getting this piece of info through a notification event, it does not seem possible (not propagated in the topic/event). This attribute is not present in the "v2.routing.queues.{id}.conversations" topic schema.
Regards,
TimoV | 2021-06-08 13:46:31 UTC | #3
Hi,
Yes, it was about getting the info through notification event. We're building near real-time pipeline for a customer and the plan is to consumer events as they occur and build conversation object from those, segment by segment.
If we don't have a way to get start time for a conversation, would you say we can trust events occurring in correct order and in real-time enough, to use local timestamps for tracking the start of conversation?
Thanks
tim.smith | 2021-06-08 14:17:23 UTC | #4
Using the timestamps when you receive an event will be close, but always inaccurate; the only reliable way to identify the start/end time of a segment is to read it as a property from the object. Notification events may be delayed by up to 15 seconds, or not received by the client at all. This means that the integrity of your data is subject to notifications being received.
The most correct way to retrieve this data is via analytics conversation detail jobs. However, if you have a use case for needing this data in real time and also need to keep it historically, you can use the conversation detail job to overwrite the data you aggregated from notifications; the data retrieved from the job is the correct source of truth in the case of any discrepancies.
If you need something in between real-time and job data, you can use the analytics query or conversation APIs to retrieve the conversation data in an ad-hoc fashion, but be careful not to hammer on those APIs as they aren't meant for bulk use; analytics jobs should be used to retrieve data en masse.
TimoV | 2021-06-08 14:36:12 UTC | #5
Thanks for prompt response. The need is near real-time as the customer have applications/processes operating in real-time and thus we do not see point in poking REST API. Analytics API jobs will not provide us with up-to-date data until the next day and as you said, we may run into problems with extensive use of query API.
The plan was to use AWS Event Bridge integration in the 1st place but as list of topics available in BETA is very limited and we have project schedules to meet, we were forced to start building on Notifications service.
Data integration guide at https://developer.genesys.cloud/api/rest/v2/analytics/data_integration_guide supports our view and suggests notifications being the best source for near real-time integrations. It's a pity that data is not consistent across the sources.
Becky_Powell | 2021-06-08 16:24:32 UTC | #6
Hi Timo,
There should be nearly 1:1 parity in the events we support with the Notifications API and the EventBridge integration. The primary exception is the conversation events. A new and improved version of these events will be available in Q3.
Were there any other events (topics) that you are missing in EventBridge?
Best,
Becky Powell
TimoV | 2021-06-08 16:43:09 UTC | #7
Hi,
Our first release will be consuming v2.routing.queues.{id}.conversations and v2.users.{id}.activity, and the latter is already there. So v2.routing.queues.{id}.conversations was the one we would have needed in order to be follow Eventbridge path right from the start.
Becky_Powell | 2021-06-08 17:40:00 UTC | #8
OK, yes, this will be covered in the new Analytics Detail event that we are releasing in Q3. I will inform all EventBridge beta participants when this new event is ready.
TimoV | 2021-06-09 05:48:44 UTC | #9
Tim,
When you're saying "events maybe not be received by the client at all", I assume you point to a fact that client side must ensure that there are multiple consuming clients ensuring resiliency in case of process crashes, server reboots, etc., and not that Notification service would be known to be loosing some events? Please confirm this?
tim.smith | 2021-06-09 13:33:55 UTC | #10
There are two reasons an event may not reach a client that would be expected to get it:
- Your websocket connection was severed due to some networking issue between your service and the AWS cloud. If an event is emitted while your app is reconnecting, your app will not receive that event. Notifications are not retried.
- If there's a server-side issue that causes the notification service to become extremely backed up to the point of failure, events may be discarded and not emitted to clients. This timeout period is 15 seconds, which is where the 15 seconds in my prior response came from. This behavior is intentional because the notification service is intended to be used with real-time user-based UI applications, so data that's delayed by more than 15 seconds isn't worth sending. This is extremely rare and is essentially a nuclear option; normal lag times are measured in milliseconds.
Event bridge solves both these issues. I understand that there are currently conditions preventing you from using event bridge at this time, but these reasons are pretty strong reasons to switch to using event bridge once the data you need is available there.
TimoV | 2021-06-09 18:11:10 UTC | #11
Tim, thanks for detailed clarification. Indeed, wish we had eventbridge available soon.
system | 2021-07-10 18:11:10 UTC | #12
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: 11048