Recherches récentes
Pas de recherche récente

Support
Adhésion le 01 déc. 2022
·
Dernière activité le 27 sept. 2024
Suivis
0
Abonnés
0
Activité totale
7
Votes
0
Abonnements
2
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Support
Support a créé une publication,
My Zendesk support plugin integrates with a backend that uses AWS Load Balancer to route traffic to the most efficient target. AWS Load balancer uses cookies to enable sticky sessions, which handles directing subsequent requests to the same target as the previous requests from the same session. I cannot find documentation suggesting that the ZAFClient supports passing the cookies from the browser to the final endpoint. This prevents ZAFClient requests from leveraging the sticky session functionality provided by Amazon. This lack of compatibility for sticky sessions is causing performance defects; the user receives cached data when routed to the wrong target.
My plugin uses the ZAFClient to handle all API requests, it cannot use standalone AJAX requests without the ZAFClient because secure settings are needed to handle authenticating the API. Do you have any recommendations for how to add support for sticky sessions with ZAFClient calls to AWS Load Balancer?
Publication le 27 sept. 2024 · Support
0
Abonnés
1
vote
1
Commentaire
Support a ajouté un commentaire,
How was this issue resolved? I am facing the same issue in a new demo account.
Chat transcript data is visible in the UI but the ticket.conversation array returns an entry array of the correct size, but each property within each entry is null. Outgoing agent messages are the only messages that do not appear null.
Is this happening because the account is still in the trial period or is there something I can do to fix this? Thanks.
Afficher le commentaire · Publication le 19 déc. 2023 · Support
0
Abonnés
0
Votes
0
Commentaire
Support a ajouté un commentaire,
Thank you. Unfortunately using indexes would not work in our application because not every translation is returned immediately, sometimes other messages are created/sent before a translation is returned. We need a way to store relationships between comments, and indexes alone would not be stable or reliable enough.
Afficher le commentaire · Publication le 07 déc. 2022 · Support
0
Abonnés
0
Votes
0
Commentaire
Support a ajouté un commentaire,
Yes, there are sometimes duplicate agent reply messages that disappear after reload.
Our app is a translation plugin that displays the comments, translations, and the relationship between the two. When a message is translated, we store the timestamp from the source comment and the translation in our API so we can properly match the translations to the correct source comments. So, when there is a discrepancy between the timestamps stored in Zendesk and the timestamps stored in our API, the relationship between the source and translation breaks. Ideally, our app needs a stable piece of identifying data from each comment that would be supported in chat, messaging, and tickets.
Afficher le commentaire · Publication le 05 déc. 2022 · Support
0
Abonnés
0
Votes
0
Commentaire
Support a créé une publication,
Our support plugin uses the ticket.conversation.changed listener to detect new messages. The array of message entries does not contain any unique identifier data, other than text and timestamps. Text alone cannot be used as an identifier, and the timestamps are intermittently unstable. After posting an agent reply, the timestamp we record in our plugin remains consistent around 75% of the time. Intermittently, this timestamp will shift forward anywhere from 0-2 seconds, sometimes more than two seconds. This causes our app's expected behavior to break, since the timestamp we have recorded no longer exists in the array of entries.
I am wondering if there is a cause for the shifting timestamps, I have not observed a direct cause. Including stable message IDs in the ticket.conversation array of entries would allow developers to not have to rely on unstable timestamps to uniquely identify messages.
These are timestamps recorded on creation of two conversation entries from our plugin
These are the timestamps for the same two entries logged from Zendesk after the page is reloaded
Thanks!
Publication le 01 déc. 2022 · Support
2
Abonnés
3
Votes
5
Commentaires