Websocket Functionality Within Sisense

[Wyatt]

Websocket Functionality Within Sisense

Introduction

Sisense uses the WebSocket Protocol to load dynamic content within the platform. It’s important to remember that the WebSocket Protocol is simply an upgrade of HTTP(S) traffic, relying on the same basic network connectivity as standard HTTP(S) connectivity to the Sisense application, for example, logging in or loading a dashboard.

Symptoms

In quite a few instances we have found that Sisense customers experience issues with the following:

• Data tab functionality
• Previewing data in a cube
• Build logs not showing up
• Preview data after custom SQL
• Pivot Tables not loading

In the Developer console, you will likely see WebSocket errors referencing the “ws” or “wss” protocols like this:

You may also see a message like "error during WebSocket handshake" in the developer console. In the Network Tab, you will also see failed WebSocket connections, sometimes timing out after a significant period of time.

Troubleshooting

Several things can impact WebSocket traffic specifically, while regular HTTP(S) traffic remains functional. These include unreachable members of Load Balancing pools for multi-node environments, unusual routing configurations, multiple network interfaces being used, interference from end-user security environments, interference from third-party security tools, and other similar issues.

In most cases, the best method of troubleshooting these issues is to identify the point at which the traffic is failing by performing web traffic analysis (HAR file), and gathering unencrypted Wireshark captures from the end-user PC and server(s). For Windows end-user PC’s, you may need to enable SSL Keylogging, and collect that log as well for the duration of the troubleshooting session. Server-side logging is also useful for identifying requests and responses amongst the many network connections for both of these endpoints.

To analyze this data, follow the requests and responses to see exactly where the traffic fails. With the unencrypted traffic, you should be able to identify features such as the Sisense generated x-request-id’s and WebSocket traffic being initiated in plaintext, along with plaintext responses as well. The x-request-id’s are available within the network trace, and will be tied to the parent dashboard request, like this:

For issues where WebSocket traffic fails in transit, you’ll need to investigate the network pathway taken by the WebSocket traffic to ensure routing availability and consistency.

If WebSockets themselves are loading successfully, you should see data populating in the “messages” subtab of the Networking pane within the developer console, like this:

 

Summary

In summary, Sisense uses the WebSocket Protocol, an upgrade to standard HTTP(S) traffic, enabling bidirectional communication between client and server to support dynamic content. If this functionality is not working as expected, I hope this article will provide a good starting point for any investigations.