Genesys Cloud CX

 View Only
Discussion Thread View
  • 1.  Participant data updates via the API - performance guarantee?

    Posted 4 days ago

    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 Goldsmith
    NTT Australia

  • 2.  RE: Participant data updates via the API - performance guarantee?

    Posted 3 days ago

    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

  • 3.  RE: Participant data updates via the API - performance guarantee?

    Posted 2 days ago

    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