Jim,
Appreciate you weighing in here and providing some insights into the architecture of the cloud. I wonder if you can shed any light on whether there is any caching of participant data within a flow?
Our flow executes a Get Participant Data task within a loop to make multiple attempts (max 5) to retrieve the participant data, with a 1 sec delay between each attempt. One thought was whether the initial failed attempt to retrieve the participant data is being cached and resulting in all subsequent attempts returning the same "null" result.
Thanks
Mark
------------------------------
-------------------------------
Mark Goldsmith
NTT Australia
https://www.global.ntt/------------------------------
------------------------------
Original Message:
Sent: 01-26-2023 11:20
From: Jim Crespino
Subject: Participant data updates via the API - performance guarantee?
Mark,
I have to agree with Paul that the best and most guaranteed approach here would be to have Architect invoke a Data Action out to the other platform and pull the data, instead of having the external platform push it in.
As for the intermittent delay you are seeing... Genesys Cloud is a microservice architecture. The PATCH request you are making is received by the APIs which update the JSON in the Conversation Service. That update triggers an event on our message bus, and any other services "listening" for events on that conversation will pick up those changes. There are many factors that could play into how fast the Conversation Service can update the JSON and how fast the update can be propagated through to the other services. That's why it would be better to "pull" the data into Architect when you need it to guarantee it is available when the routing decisions need to be made.
------------------------------
Jim Crespino
Senior Director, Developer Evangelism
Genesys
https://developer.genesys.com
Original Message:
Sent: 01-25-2023 10:13
From: Paul Simpson
Subject: Participant data updates via the API - performance guarantee?
Mark,
Whilst I am not about to question your logic here, I feel I must point out that having Architect reach out to your external application via a Data Action to obtain the required data would allow you to have much more control over it's arrival into the flow at the appropriate time - although I'm guessing you knew that already!
Anyway, you don't say if the delayed updates are different in any way to the non-delayed ones. I do know that Architect warns you that updates made to Participant Data within a task are not available until that tasks ends. I wonder if something similar is happening here?
Sorry I can't offer any more insight.
------------------------------
Paul Simpson
Eventus Solutions Group
Original Message:
Sent: 01-24-2023 16:59
From: Mark Goldsmith
Subject: Participant data updates via the API - performance guarantee?
Hi Folks,
In our solution, we have an external application that uses the platform API method "PATCH /api/v2/conversations/{conversationId}/participants/{participantId}/attributes" to update the participant data on an interaction whilst that interaction is being routed using a Architect Flow. Whilst the method call works 100% of the time, there is a lot of variability in the delay before the participant data becomes visible to the flow (i.e. can be read in the Flow using a Get Participant Data task). In the vast majority of cases the data becomes available almost immediately, however in say 1% of cases, it can take more than 10 sec for the data to become visible to the flow. This is impacting our flow logic which is wanting to make a routing decision based on the participant data.
My questions are:
1. Are there any performance guarantees provided for how quickly participant data updates are made available to an executing flow
2. Is there any performance difference between these two API methods when updating a voice interaction:
- PATCH /api/v2/conversations/{conversationId}/participants/{participantId}/attributes
- PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/attributes
With thanks
Mark
#ArchitectureandDesign
#Integrations
#Routing(ACD/IVR)
------------------------------
-------------------------------
Mark Goldsmith
NTT Australia
https://www.global.ntt/
------------------------------
------------------------------