Genesys Cloud - Main

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

#ArchitectureandDesign
#Integrations
#Routing(ACD/IVR)

------------------------------
-------------------------------
Mark Goldsmith
NTT Australia
https://www.global.ntt/
------------------------------
------------------------------

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
------------------------------

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
------------------------------

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

Have you tried getting attributes through Data Action and API instead?

I use that in for example scripts where the script wouldn't automatically update the value when it changes.

------------------------------
Jan Heinonen
Contact Center Specialist
GlobalConnect AB
------------------------------

Original Message:
Sent: 01-29-2023 16:45
From: Mark Goldsmith
Subject: Participant data updates via the API - performance guarantee?

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

Paul,

Thanks for taking the time to share your thoughts. I agree that having Architect reach out to our external application would provide a more resilient solution and FYI the reason we don't do this is because our external application lives in a private address space that cannot receive a request from the public internet. We did consider posting the participant data to an intermediate service and then having Architect retrieve it from there, but decided against the approach as it added an additional cloud service and that in turn increased the operating cost as well as the dissemination of sensitive customer information.

Cheers
Mark

------------------------------
-------------------------------
Mark Goldsmith
NTT Australia
https://www.global.ntt/
------------------------------
------------------------------

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
------------------------------

Have you considered using a Lambda/VPN connection to provide access to the private address space for this use case?  There's relevant links here: https://help.mypurecloud.com/faqs/can-i-use-data-actions-with-an-on-premises-solution/

Also, I could be mistaken on this, as it's been a while, but I believe Architect is fetching the participant data at the start of the flow, and operating off of that local cache for the entirety of the flow instance.  If that's the case, performing the "Get" function in a loop is extraneous.  One option would be to leverage the "transfer to flow" operation, which would call a new flow instance (which would fetch the participant data at it's start).  Hopefully someone else can chime in if this is still the case with regards to participant data in Architect.  

------------------------------
Richard Schott
Genesys - Employees
------------------------------

Original Message:
Sent: 01-29-2023 16:38
From: Mark Goldsmith
Subject: Participant data updates via the API - performance guarantee?

Paul,

Thanks for taking the time to share your thoughts. I agree that having Architect reach out to our external application would provide a more resilient solution and FYI the reason we don't do this is because our external application lives in a private address space that cannot receive a request from the public internet. We did consider posting the participant data to an intermediate service and then having Architect retrieve it from there, but decided against the approach as it added an additional cloud service and that in turn increased the operating cost as well as the dissemination of sensitive customer information.

Cheers
Mark

------------------------------
-------------------------------
Mark Goldsmith
NTT Australia
https://www.global.ntt/
------------------------------
------------------------------


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