"Qva is not defined" error in Workbench 10

[Brian_Munz]

Hi all,

I'm hoping this is a very simple issue since I'm not trying to do anything overly complicated. I'm trying to set up a workbench page, and I did all the needful steps of getting it installed, etc. So, when I try to create a new object, I find the document no problem, choose the type of object and the object ID no problem. However, when I try to actually view the page in Debug made, the spots where the objects should be are blank and I get an error of "Qva is not defined."

The server has the workbench license on it, so that's not the problem.

Any suggestions?

Thanks.

[#2]

Hi Brian

How have you set up the workbench? Are you using IIS and connecting Visual Studio to it?

The most common problem when you get the QVA undefined is that the javascript files are not loaded correctly.

If you have the server on the same machine as you have the workbench installed then I suggest the following setup.
Use the IIS as the webserver and set it as the development server for Visual Studio.

If you dwell deeper into the problem it is due to "same-origin" principle, the client does not see the javascript to come from the same server as the aspx pages and will therefore throw an error which results in "Qva is not defined".

//John

[Brian_Munz]

Hi John,

Thanks for the response. I'm running workbench on an IIS server, and when I installed workbench itself, it asked for the path to the virtual directory with the QvAjaxZfc in it and it all checked out. Shouldn't that mean it knows where to find the js files?

Thanks.

[#4]

Hi Brian

Technically yes but if the QvAjaxZfc folder is located on another computer the IIS server will see this as not being the same origin as the rest of the serverside files.

This was not a problem in QV 9 as all the ajax was contained inside the workbench but as of QV 10 it is separated.
There will be a workaround for this in the SR1 release.

Until then you either have to have the QV server on the same server as IIS and run IIS for both (not the built in one) or you will have to separate the backend from the front end, eg move the QvAjaxZfc folder to the IIS as a virtual directory and hence "trick" QV that the javascript files are local.

Hope this helps.

best

//John

[Brian_Munz]

Ok, now I understand what you're saying. The only thing is I'm using the SR1 release of workbench right now.

[#6]

The SR1 release hasn't been released yet, I'm guessing you mean you are using the IR (Initial Release).

We just have to wait and hope 🙂

[Brian_Munz]

I'm a QV employee so I have it early 😉

The other thing is that I have a QvAjaxZfc virtual directory set up and it points local to C:\Program Files\QlikView\Server\QvClients\QvAjaxZfc

I've pointed the Workbench to there.

Thanks, by the way, for your help and fast responses.

[#8]

Haha always a good thing.

Have you manage to use the javascript api in a webpage without the workbench? Debating if I should reverse engineer an ajax application to see what javascript files are needed and how the proper procedures is to make the connection to the server.
Would be nice to be able to use other ways then just IIS 😛

[Brian_Munz]

Yes, I've done that before. The good news is that it's possible, the bad news is that whatever you do will be deemed as unsupportable and custom because obviously you're getting under the hood and sot of "voiding the warranty" 😉

The cheapest, easiest and worst way to do it would be to just save the page that's rendered by AJAX down to HTML using just a browser. Then you can get in there and manipulate things as you want. Otherwise you need to pick things apart and get a better idea of how the Ajax calls work and how the data is passed back and forth with QVS.

[#10]

Great thanks.

I have done it for both 8.5 and 9 so will probably get my hands dirty sooner or later. But good to know I will be stuck "unsupported" (same thing happened with my QV9 solutions so I'm used to it).

Web interfaces, here we come!

//John