AccessPoint in QlikView May 2023

[Fran_by]

We have a cluster of 2 QV servers.

Access for users is organized through QlikView Desktop Client.

The user run QlikView Desktop and takes the following steps:

1. File -> Open URL…
2.  go to http://qvs/qlikview/index.htm
3. choosing an application in AccessPoint page

Usually apps opened in QlikView Desktop mode, but after updating to the QlikView May 2023, apps opening in Ajax Client mode inside QlikView Desktop.

Are there any settings allowing to return previous behavior?

P.S.

File -> Open in Server -> QVP: // QVS

It works as before, but Load Balance does not work like that.

[marcus_sommer]

Within the QMC by the Web-Server/Access Point is global setting which client should be the preferable one. Further has each application by Documents own settings which clients are available. Maybe these settings have an impact to your issue.

[Fran_by]

Thanks for the assistance, but this didn't help.

QMC have 3 options:

1. IE plugin
2. Ajax Client and Small Device
3. Download

By defaul select «Ajax Client and Small Device».

If select “IE plugin”, Desktop Client didn’t open app.

It shows an error from the screenshot below, but the settings from the message cannot be made inside QlikView Desktop.

If select "Ajax Client and Small Device", then it will open in AJAX mode.

But before updating to the QV May 2023 version, when select "Ajax Client and Small Device" and opening the application in QlikVew Desktop, app opened in Desktop mode (QVP protocol).
It definitely worked just like that from QV 2017 to QV 2022

Select “Download” parametr – open app in Ajax Mode.

May be possible to correct something in Config files to return the behavior to update to May 2023?

[marcus_sommer]

The IE is officially outdated since several years and without any support - just tolerated. Since the last year it was more or less hard disabled from MS. It depends on your OS and your company policies if there is further any indirect access. Indirect means mainly the access and usage of the underlying libraries. QlikView used them for the inbuilt web-view from the desktop client, authentication stuff and much more.

For the most usage-scenarios there should be alternatives like the IE mode within Edge. I don't know if all use-cases are covered but I know there were already various posting about similar stuff within the community. Also the release note of the last releases contain some information in which release was what changed / replaced.

[Fran_by]

I know about IE, I do not need it.

I need to open the app in Desktop Mode from the AccesPoint page,  like all versions before May 2023.

Release note not contain information about my problem.

[marcus_sommer]

By us it worked never in this way else if I'm using open url it opens always the browser and there is no option for accessing with the desktop client. AFAIK this are the standard-settings because I never changed here anything.

This means if it worked for you like described there might some customization been included - like any re-direct logic to open the application in reality with the QVP protocol. I could imagine such method but I don't know how and where it might be implemented. I hope you have further access to the previous configuration to compare them against the current ones. If it was done sensible you should find the related settings quite quickly - if I change anything directly in the various config-files I backup the origin ones with an added timestamp in the file-name directly in the source as well as in special admin-folder of the environment + at least a few lines of documentation.

[Fran_by]

Today for the test I installed QV May 2022 SR2 on a new clean server, I haven't customized anything.

Everything works as I described earlier.

1. File -> Open URL

2. See SectionAcces in QV Desktop

Note: If select "View details" button, can see only QlikView.

Afte select app, it open in QV desktop mode.

In QV May 2023:

and result 😞

[marcus_sommer]

Maybe it's related to the option to download the qvw which is a global option also available within the QMC in the web-server section by Access Point. We never enabled this option because no normal user should get access to the physical file and users with developer-needs gets a direct access for a classical file --> open (whereby it's more common to use the QlikView start-window or a central control-app which provides the possibility to access all applications, logs and data from a single point).

If it's the case that your applied approach isn't an OnOpen on the server else a download of the qvw to the local machine from the users I suggest to re-think this method - because with it you couldn't really ensure the data-security and the single-point-of-truth of the data - it would be quite the same as if each user plays with it's own Excel files ...

Another noticeable aspect is that you refer within the url to localhost - it's just for you as admin that you access the Access Point from the server-machine or are all other user also connected to the server? If so - why using then the Access Point to open a qvw?

[Fran_by]

Download option not selected in QMC.

I use Localhost for an example, users set the server name where installed QlikViewWebServer Service.

QVW are loaded on the servers, this can be seen in QMC.

QMC -> Status -> QVS Statistics.

I think this is due to the transition to WebView2 , the qlik developers apparently forgot to transfer this functionality.

And it is sad, because huge apps work very slow in web version 😞

[marcus_sommer]

Never heard of WebView 2 whereby it's not really surprising because of the above mentioned IE disabling. Could you share some information about it - when it was released. The search in the community returned just a hint within the current release notes about a third party bug by high resolution but nothing more.

Further there were a hint in the release notes about disabling of TLS 1.0 / 1.1 which might be related to such a re-direct logic. Maybe https://community.qlik.com/t5/user/viewprofilepage/user-id/13651 could help or transferring it to the R&D.

The webview within the desktop-client must be slower because the rendering is now performed on the local machine and HTML has a lot more overhead as a classical window especially if no browser is directly used else there is now an extra layer between the data and the UI rendering. This leads to the question are there special reasons why using the desktop client as default client and not AJAX which would be rendered by the web-server?