My goal is to monitor the presence of 35 different agents in my call center and display their statuses to my end users on my website.
Each end user will be able to view 6 of the 35 agents at a time. Any given agent's presence needs to be able to be viewed by 1-∞ users on my website.
Currently, when a user logs into my website, I poll Salesforce for the 6 agents that we need to monitor and then set up a single Notification Channel for each of these agents. Each notification channel has one subscription which is to the agent's presence. I then open up a web socket for each channel that handles updating my pages with the relevant presence information that I'd like to display.
I'm running into an issue though where sometimes the web sockets stop updating after a few minutes. I'm not sure if this is in response to more users signing on to my website and too many channels being created or if multiple subscriptions to the same web socket is earlier subscribers out?
Is there some issue with opening up channels for all 35 of these users?
If my web socket is open for one logged in user and then another logged in user also needs the same agent's presence and I get a new channel and open up a new web socket for that agent, will the first user's subscription to the agent's web socket die?
I suggest you take a look at the Notifications API page. Based on the docs you can only open up 20 channels per user per application.
Channels remain active for 24 hours. To maintain a channel for longer than 24 hours, resubscribe to topics.
You can create up to 20 channels per user and application. When the channel limit is reached, then the new channel replaces the oldest channel that does not have an active connection.
Each WebSocket connection is limited to 1,000 topics. If you subscribe to more than 1,000 topics, then the notification service returns a 400 error code.
Each channel can only be used by one WebSocket at a time. If you connect a second WebSocket with the same channel ID, the first WebSocket disconnects.
A couple of questions:
Are the users logging into your website using code-auth and obtaining their own OAuth token? The number of channels available is tied to the OAuth client being used to create the channel. If you are using an intermediary service using a client credential grant you could inadvertently create more channels than are allowed and this could account for the behavior you are seeing.
You do not need to create a channel for each agent. A better approach would be to have a single channel for the logged-in user and then have multiple subscribed topics. Each topic subscription is tied to the user id of the agent whom you want to track.
Also make sure you don't reuse the same channel id to open multiple WebSockets. This will cause the WebSocket that is already open on the channel to close.
Let me know your thoughts about the points above. I have worked with the notification service before and the items I identified are common antipatterns.
Thanks,
John Carnell
Manager, Developer Engagement
Users do not log into our site using code-auth and obtain their own OAuth token, so we are likely running into the issue you described in number one with our client credentials creating more channels than are allowed.
I like your solution for number 2, but obviously as I've now shared, having one channel for each user is impossible given that we are using a client credential grant flow.
As for number 3, in my limited experience so far, I've seen that we can use the same connect uri (aka web socket url or channel id?) for a given channel across multiple browsers at the same time, which validates to me that it can work in our production environment where many of our users would all use the same channel (which contains subscriptions to all of our agents) and they'd each have a web socket open to the channel without closing other users' subscriptions. Am I playing with fire here? It seems to work okay... each of the browsers receives events on the web socket at the same moment when the presence changes for a user that the channel is subscribed to.
Or maybe I'm misunderstanding. Are you saying not to start a channel with a set of subscriptions, then use the same channel to open up a new set of subscriptions because it would invalidate the previous wss web socket url?
Thank you very much for sharing your expertise on this topic as I am certain we are using some of the common antipatterns, as this is our first foray with the notification api.
For the number 3 comment, I will double check that with the dev team. I always understood that the channel/websocket url were unique. I am wondering if there is a way for the generated channel id to be duplicated (e.g. is it unique in most circumstances).
Since it seems like your best option here is that if you are using a single OAuth credential in your app is to open a single channel and then create 35 topic subscriptions, one for each agent. I would then filter out any of the 29 agents a user would not be interested in and only display the 6 agent's information specific that the user is interested in. A single channel can handle up to a 1000 topic subscriptions so you should be fine if you are monitoring 35 agents total. If you are using the client credential grant that would completely eliminate all of the channels.
Thanks,
John Carnell
Manager, Developer Engagement
Hey there,
I agree, that seems like the best approach for us, so long as we can open up a web socket to the same wss connect uri from multiple users' browsers without issue. In that case, we'll filter the information we need each time any of their presences change.
If you find out any more information from the dev team about the ability to open up many web sockets to the same uri, please let me know.
Blockquote
^ They may sometimes be able to connect the same channel ID more than once if they get lucky and hit a different Hawk instance every time, but there are only so many instances and it will eventually kick off the existing connections with the same ID.
One thing you could do is have a single channel open to our notification service and then republish to individual and separate WebSockets that are built and managed by your application. The notification service channel would listen to all 35 agents and when data comes in you would filter the data out and then publish it to individual WebSockets that you opened and manage for each agent. I personally have not done this, but conceptually it seems like it could be done.
The challenge is that while the notification service can work with a client credential grant, the concept behind it was to allow individual users to open a channel. Hence, why I originally asked about whether you are using a code-authorization flow where each user authenticated and had their own token.
Thanks,
John Carnell
Manager, Developer Engagement
Okay, that's very good to know. Not ideal for us, but glad we found that out now.
I think conceptually we could make what you described work with our own set of web sockets, it'll just take a good deal of extra effort, unfortunately. We'll probably begin going down that road as I don't see another option.
Specifically, in regards to our OAuth flow, I'm not sure we have the option of moving to the code authorization flow because our users are unlicensed users. We are using the web chat widget for external chat to our internal agents and we want to be able to show presence to these users without needing them to also be licensed and have their own Genesys Cloud login.
Thanks for your help in investigating this issue and helping us think through potential solutions!