Are you saying that instead of using an app name like "Sales Discovery" you have to use "db8261a8-9a61-4b5e-afbd-77cfc246b119" in the qDocName property? I agree the OpenDoc qDocName property doesn't match with the contents of getDocList qDocName property. Looks like you have to use the qDocId from getDocList as the qDocName property in OpenDoc.
On Qlik Sense server, the name of the file on disk is actually the guid and not the friendly name. So I can't say it's a bug, but it's not totally clear what the contents of qDocName need to be when accessing the engine from the server versus desktop.
I created this app with the Repository API (App: Make copy) and I used an UUID for the name (this is not the file name on disk, if there is any on server..). For some reason I do not need a friendly app name here so I just use this UUID I created with my Java websocket client. But as you can see in my screenshot OpenDoc doesn't work with Qlik Sense Server (but does works with Deskotp!). So I assumed this must be an issue..
My example runs against the Qlik Sense server. Did you use the engine api to create your app? If so you I assume you used the CreateApp method and added a name to the qAppName. When you do that the response is the qAppId.
If you run an OpenDoc method against the created qAppId using the qAppId as the qDocName:
You see you receive a response that looks like this:
As you can see you receive a handle for the document.
I agree, the engine documentation for 1.1 doesn't tie with what one sees in the engine api, but it is working from the server just fine in my implementation if I use the created qAppId as the qDocName. I think the UUID you used for your app ends up being the AppName and not the Respository created guid for the app which is really what you need.
I use the Repository API to copy the app from another one and I use a UUID as the new name. I also get a message back with the Doc ID I can use to open the app with OpenDoc, but this is not the point here. I cannot open the app with the Doc Name I used to copy...
On the server, the application name - I'll call it a friendly name - is not how you open an application using the engine api with Qlik Sense Server. You use the guid that gets created when an app is created, imported, or duplicated.
The difference between the desktop client and the server is that the actual file names are different. The desktop client uses a file name like the friendly name where the server uses the guid to identify the file. The point of the guid is to mitigate filename conflicts in the shared development environment.
Ultimately, I don't think it's a bug. It's a difference in how files are named in the different environments. Like I said earlier, I think the documentation needs to show an example using the desktop protocol tester versus the server protocol tester.
No it's the correct behaviour. Actually in Desktop it's just a coincidence that qDocName works as it should be qDocId even for Desktop. Now in Desktop your qDocName _might_ be the same as the qDocId however you have the possibility to change the name of a app without changing the actual filename on disk, we decoupled filename and app name in Sense.
Now I do agree it's somewhat confusing that the documentation references qDocName and not qDocId but c'est la vie
The next issue you are likely to run into will be sessions and errors that the app is already open etc. If you do, don't hesitate to drop me an email and I'll walk you through how we separate identities on the websocket connection.