Genesys Co-browse sessions are sticky. This means that all requests from the customer and agent sides have to be routed (stick) to the same Co-browse node within a given session.
Although the stickiness principles are mostly important for load balancing, the Co-browse application adheres to them even in a single-node setup (for example, in a demo or test environment). Moreover, if you use URL-based stickiness for the agent side (for example, when using Co-browse with Workspace Web Edition), the proper configuration is required even for the single node.
Generally, stickiness in Co-browse works like this:
- The customer initiates a session on any server, which is routed by Load Balancer using the round-robin method or any other load-balancing technique. For more on load balancing, see Configure the Load Balancer.
- After the session is created, the customer sticks to that server. All further requests must go to the server that owns the session.
- After it has been given the session token, the agent side must figure out on which server the session was established. This is done via special request to any Co-browse node.
- After that, all requests from the agent side must be routed to that same server.
There are two ways to achieve this stickiness:
In a cookie-based scenario, the Co-browse application sets the gcbSessionServer cookie in every one of the following situations:
- When a Co-browse session is created.
- When a chat session is created.
- When an agent joins an existing session.
After the cookie is set, Load Balancer must use it to route requests to the specified node.
In the URL-based stickiness, the agent side receives a public URL for the Co-browse node that owns the current session. The public URL is configured via the serverUrl configuration option. After receiving the URL, the agent application routes all further requests to that URL. If serverUrl is configured for URL-stickiness, the agent side always uses the URL instead of cookies for stickiness.
To avoid making co-browse nodes publicly accessible, you can hide them behind the Load Balancer and differentiate them, for example, by a query parameter.