Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
Francis_Kabinoff
Former Employee
Former Employee

Inspecting Qlik Sense websocket communication is useful for a variety of reasons. Let’s see how to inspect websocket traffic, and then what to look for when it comes to websocket traffic from the Qlik Sense Engine.

 

HOW TO INSPECT WEBSOCKET TRAFFIC

Before you get started checking out websocket traffic from Qlik Sense, you must know how to use browser dev tools to inspect websocket traffic. Open a tab in Chrome and open the dev tools for that tab, then navigate to a Qlik Sense app or mashup. Now in dev tools, go to the network tab, and filter for WS. You should see the websocket listed, select it. Now notice the tabs for headers, frames, cookies, and timing. You can inspect request and response headers in the headers tab, see cookies sent with the request in the cookies tab, and check out the load time in the timing tab. But the frames tab is where the action is. Click on that and you can see all of the messages sent and received over the websocket.

 

websocket.png

 

WHAT TO LOOK FOR WITH QLIK SENSE WEBSOCKET TRAFFIC

All the communication with the Qlik Sense engine happens over the websocket. You can see the messages for authenticating and connecting, opening a doc, creating and fetching objects, getting layouts, and more. You’ll want to match messages sent, which are highlighted in green, with its response message. Both will have the same id.

 

Here’s an incomplete list of good uses for checking out the websocket communication:

 

 

CHECKING THE STATUS OF THE CONNECTION

The first two frames should always be the responses for authentication and connection. In the authentication response, you can see the user id and directory, the logout uri, and whether authentication is required or not. In the connection response, you can see that the connection was successful and whether a new session was created, or a session was attached to an existing session. If the session was attached, that means its sharing the session with another existing session. This is what you would want to check if you were opening up two or more websocket connections to the same app and wanted to make sure the connections were going to share the same session. You can also see the messages sent and received when opening a doc, which can sometimes be useful debugging any issues.

 

DEBUGGING

This one’s kind of obvious but should be mentioned. Here’s an example. If you’re trying to embed objects and they’re not showing up on the page, you should inspect the websocket communication. You can check to make sure that a connection is made, the doc has been opened successfully, and the getObject message has been sent. Then you can check the response message to see if it tells you anything about your issue. If you try to get an object but have the wrong id, for instance, you’ll see that you don’t get an error for anything, but the response just doesn’t contain an object, which is a good indication that you just requested an object that doesn’t exist.

 

 

LEARNING STUFF

I like to check out the websocket communication for native Qlik Sense objects. This let’s me see how native objects do things like paginate the data on scroll, or use the beginSelections and endSelections methods, so I can get ideas for replicating similar functionality in my own custom visualizations.