Engine JSON API: GetDocList returns an empty list

[manta_dev]

Hello,

I have come across a problem while trying to connect to the a QS Enterprise server using the Qlik Engine JSON API and retrieve a list of all applications using the GetDocList method.

I connect to the server using a keystore with certificates and the connection is successful. Then, using a custom user (not admin), I am trying to retrieve a list of all apps that a user has access to, but the list returns empty. However, when I perform the same request using the Qlik Sense dev-hub, the response contains all applications on the server.

Does anyone have any idea what could be wrong or what I shall modify? I tried to assign RootAdmin security rule to the user I used for logging in, but with no success. Thanks for any suggestions.

[Damien_Villaret]

Hello @manta_dev 

Could you provide a sample of how your current code that is failing looks like ?

You are sending exactly the same JSON body as the one in the dev-hub ?

[manta_dev]

First I connect to the QS Enterprise server creating a websocket, using certificates (this definitely works, because the websocket is created - otherwise some connection error would be thrown).

Then I simply send

{"handle": -1,"method": "GetDocList","params":[],"outKey": -1, "id": 1}

message to the server, to address

wss://<serverURL>:4747/app/

 exactly the same as the dev-hub does. The only difference is that I have [] instead of {} at "params" argument, but dev-hub works the same if I put the [] in there as well.

The answer is a standard message with an empty list of applications.

This leads me to some unknown problem with privileges, I believe. When I do this on our development server it works flawlessly, but when I run this on customer's server, it doesn't work even when the userId+userDirectory used for logging in has RootAdmin privileges.

Can it have something to do with the fact that the client has got a multi-node Qlik Sense deployment?  As far as I know, there are 2 nodes running the QES, but I am not very familiar with this and how it could potentially affect everything.

If there is some more information that could help you with solving this issue, please let me know. I think I tried everything I know or that I could find and nothing works so far.

[Damien_Villaret]

Helllo @manta_dev 

Did you specify a X-Qlik-User header on your request specifying as which user you want to run the request ?

If you use certificates to connect to the engine, then it's the user specified in X-Qlik-User that is taken as the user running the request, not the actual Windows user you're running the code with.

'X-Qlik-user': 'UserDirectory=DOMAIN;UserId=Administrator'

[manta_dev]

@Damien_Villaret 

Yes, when I am creating a WebsocketClient instance, I explicitly set the header "X-Qlik-User" to value "UserId=(username used);UserDirectory=(customer's domain)".

The username used and customer's domain  are  the exact combination we tested in the dev-hub that returned the correct list of apps.

I believe that if this did not work, the websocket connection would not have been established at all.

[Damien_Villaret]

@manta_dev 

Could you enable the Engine Traffic logs and check in there how does the request look exactly when received by the Qlik Sense server ?
https://community.qlik.com/t5/Support-Knowledge-Base/The-Qlik-Sense-Engine-Traffic-Log-level/ta-p/17...

[Øystein_Kolsrud]

Wild guess here... Is it a multi-node system? Perhaps there is an issue with you load balancing rules? If the dev-hub leads you to a different node than the one you are direct connecting to, then those rules could explain what you are seeing.

[manta_dev]

@Øystein_Kolsrud 

Yes, it is a multi-node system. Is there any way I can verify that this is the problem?

[Øystein_Kolsrud]

Well, you can always try to direct-connect to the other nodes and see if you get a different behavior. You could also do a REST call to the endpoint /qrs/app and see if you get a different result. That would give you the apps you can see in the context of the QMC (unless you specify otherwise) which I think should be different if the set of load balancing rules is really the cause here.