topic Web based access vs. Client Installs in QlikView

Web based access vs. Client Installs

john_duffy — Wed, 13 Apr 2011 16:07:13 GMT

Hello All.

We are currently using QlikView installed windows clients to access our applications. We are going to upgrade from QV 8.5 to QV 9.

As part of the upgrade project, I am investigating the pros and cons of web based access using an IE Plug-in vs. our current method of installed clients.

Any feedback on the pros and cons of either method would be appreciated.

If anyone has switched from installed clients to web based access and can share their experiences, that would also be very helpful.

Thanks,

John.

Web based access vs. Client Installs

johnw — Wed, 13 Apr 2011 17:48:33 GMT

We are in the process of switching. Our users I think are still using the windows client, but I'm using the IE client to access anything we've published, as are most other developers, I believe. I've not been involved in whatever it took to make the IE client available, so I can't speak to that part of it. However, as a "user", I've seen no problems whatsoever. Other than the obvious (it comes up in a browser instead of in QlikView), everything seems functionally and visually equivalent or identical.

Web based access vs. Client Installs

Wed, 13 Apr 2011 18:14:44 GMT

All developers (me) use the Windows Client and all users access the documents via QV Server and the plugin. Quite painless to set up and install although we use IIS and our own asp menus rather than AccessPoint (to allow us to align them with group standards).

When installing the plugins, we wrap it up with some vbs that sets each machine to 'trust' macros in documents from the server as named and also to change the default locations of user files (to 'My documents' as only these get saved on our network). The vbs also prompts for the email values in user preferences as a one time set up ready for personalised reports. All these are just registry settings.

You might actually want to review your licencing at some point when you need to buy more. With v9 came document CALS and others which are a lot cheaper than Named CALS (which allow access to unlimited documents and so is expensive if a user only needs to see 1 or 2)

With our upgrade to v9 we took advantage of the 'collapse' of the licencing structure and where server 'leased licences' allows a named CAL to lease a Windows Client licence from the server (needs to connect to the server every 30 days to refresh). This allows us to distribute documents to certain users who can then access them off-line.

Regards,

Gordon

Web based access vs. Client Installs

john_duffy — Wed, 13 Apr 2011 18:31:15 GMT

John/Gordon - Thank you for your responses.

Could you please provide me with any reasons why you are switching to web based access via the plug-in (in John's case) or why you develop using the Windows Client but have the users access the applications via the plug-in (in Gordon's case).

Performance? Ease of Deployment? etc.

Thanks again,

John.

Web based access vs. Client Installs

johnw — Wed, 13 Apr 2011 18:52:57 GMT


John Duffy wrote:Could you please provide me with any reasons why you are switching to web based access via the plug-in

I'm not so much involved with any technical reasons for doing it. But I think it's a good idea because it's one less piece of software that the users have to think about. Send a user an Access Point link, and they already know how to bookmark it and bring it up later. Install QlikView on their machine, and they'll need some instruction on how to bring up Access Point, and if they don't use it frequently, may forget between uses.

What we really wanted to do was switch to AJAX. We wanted a zero footprint client. We didn't want to have to maintain software on the user machines at all. We didn't want to be tied to a specific browser. Unfortunately, there are just too many things that don't look right or work right with AJAX. We kept hoping for a long time, but eventually gave up and decided that the IE plugin was the way we'd go.

From MY perspective, deployment is EXACTLY the same regardless of client. But I don't know what sort of details there are in the background. I believe there's a default Access Point web page it'll generate with probably a minimum of configuration, though I think we customized ours.

I wouldn't think there would be any performance differences of significance, but I haven't tested. I figure it's basically the same code running on the same machines, with just a slightly different display.

AW:Re: Web based access vs. Client Installs

Wed, 13 Apr 2011 18:56:54 GMT

Hello John,

we tell our customers to develop with win client (fat client). As far as I know, there is right now no other possibility. All others (analyst) are using WEB-Technologie. I do not view creating collaboration objects as developing; but scripting, data-modelling, designing user-interfaces.

I visited Qonnections 2011 in Miami, Fl. A great part of the roadmap for V11 the QT-guys were presenting is going to support more and more WEB-Interfaces. Browsers, independent of the underlying hardware. This means they see mobiles being the BI-Future. Jeff Boehm (QT): "starting with V10SR2 there will be no more any difference between any type of browser (mobile, desk top, tablet)." And then he showed a very new feature on his ipad: creating a PDF and store it as an I-Book. And the audience: standing ovations .... (except me, think was the only one without an i*)

HtH, Roland

AW:Re: Web based access vs. Client Installs

danielrozental — Wed, 13 Apr 2011 19:57:48 GMT

The only difference I can think of between having the IE Plugin or the thick client installed would be that with v9 people with the thick will be able to develop applications locally unless you disable license lease from the server.

This might or might not be something you want them to do.

You might want to consider going straight to QV10, SR2 is around the corner...

Web based access vs. Client Installs

Thu, 14 Apr 2011 11:10:52 GMT

Our setup is mainly historical in that the WIndows client ('Enterprise') was a LOT more expensive than the IE plugin ('Analyser') so it was the obvious way to go at the time.

With the licencing changes and every 'Analyser' licence now 'becoming' 'Enterprise' do I still think its the way to go?

I guess it all depends on if the business wants/needs users to have the ability to develop documents; if not then the plugin is much smaller in terms of install space than the client and upgrading them is (arguably) simpler/quicker. It also feels 'right' knowing the plugin can do no more than make requests of the server and has no ability to interact with qvw's (ie business data) itself.

In conclusion, give the user the simplest method of getting their job done and calling up a web page, pointing and clicking seems to be that to me and administratively it is easier.

Regards,

Gordon

Web based access vs. Client Installs

nathanfurby — Thu, 14 Apr 2011 12:05:13 GMT

I've only just started at looking at it - but there are also some limitations in terms of reloading the document if the user only has access to the documents via AccessPoint right?

Web based access vs. Client Installs

nathanfurby — Thu, 14 Apr 2011 12:08:54 GMT

Sorry - that question wasn't very clear. I mean the user cannot reload the document on the fly in the same way as if they were using the Windows client?

Web based access vs. Client Installs

Thu, 14 Apr 2011 12:56:21 GMT

Another feature that we have made use of within the server/publisher/ browser user experience is that (correct publisher licence permitted) we can tailor which applications users can see based on there login credentials.

Personally I prefer the IE Plug-in route as users are familiar with internet browsers and are far less inclined to poke around in different menu options and through the browser its easier to control security permission. The browser route also allows you to provide clients with an off site BI tool where you host the server/publisher and just sell licences for external clients (from where you extract the data)

Lewis

Web based access vs. Client Installs

john_duffy — Thu, 14 Apr 2011 15:57:00 GMT

Hi Nathan.

I believe you are correct. Currently, we are on v8.5 and our users access the applications through Analyzer. Therefore, they do not reload the documents. Only the developers can reload the documents using QlikView Developer. Our production documents are refreshed via Publisher.

When we go to v9, if we go the plug-in route, the same rules will basically apply - users will access the applications via the plug-in with no update capabilities. The developers will have the developer client installed with full update capabilities.

If we decide to continue with client installs (ie. no plug-in) in v9, we will have to determine the best method of preventing users from having update capabilities as all clients will have developer privileges. From what I have read in the v9 reference manual, user functionality can be controlled by registry settings. This is not really my area.

Here's another question - With v9 client installs, what methods (registry settings, security) have been used to limit user functionality?

Web based access vs. Client Installs

nathanfurby — Fri, 15 Apr 2011 09:04:04 GMT

I thought it was quite easy to set User security permissions - in the Document Properties? Have never needed to use it.

I'm actually coming from the opposite angle on this one - I want to allow reload of some documents via AccessPoint / IE Plugin. I don't have a publisher licence so looks like it can't be done. Will need to do some reading online - I'm sure a command line macro would do the trick.

Web based access vs. Client Installs

Fri, 15 Apr 2011 09:19:33 GMT

Nathan

The command line re-load would be something like the following

"C:\Program Files\QlikView\QV.exe" /r "C:\[PATH TO YOU QVW]\[APPLICATION NAME].qvw"

You can incorporate this into a batch file (or i imaging a macro although i've not done it - and i'm not sure if you could reload data to an application that you are currently viewing through the Access Portal - if you figure it out i would be interested to know how) and then just get that to run. I've done something similar where i have the command in a batch file which is just set up as a scheduled task.

This is a copy of one of my batch files. As it runs it updates a relaod.log file with the times the schedule started and ended so i can keep tabs on hos long its taking to run. It also looks for any errors contained within the generated log file that the application creates when it performs the re-load. I can then just look in the error log to see if everything has run successfully. The one that i have running on clients sites then has a command to ZIP the generated QVD data files up before then FTP'ing them back from our clients sites into our data center

echo off

echo.

cd\

echo Initialize the log file with Command Line reload...

echo %date% %time% "inforM Command Line Reload Start" >> "C:\inforM Data Collector\Apps\inforM_Reload.log"

echo Run QlikView and Reload Data...

"C:\Program Files\QlikView\QV.exe" /r "C:\inforM Data Collector\Apps\inforM Data Collector.qvw"

echo Look through the log file for Errors...

echo Create Log File for MTS if a Data Load error is found...

Find /i "Error:" < "C:\inforM Data Collector\Apps\inforM Data Collector.qvw.log" >> "C:\inforM Data Collector\Apps\MTS_error.log"

echo %date% %time% "inforM Command Line Reload Finished" >> "C:\inforM Data Collector\Apps\inforM_Reload.log"

Hope some of this helps!

Lewis

Web based access vs. Client Installs

nathanfurby — Fri, 15 Apr 2011 09:49:41 GMT

Thanks Lewis - that's really useful. Especially the logging script stuff.

Web based access vs. Client Installs

Fri, 15 Apr 2011 10:00:22 GMT

The only thing I have found when running the task via a scheduled task is that the server/PC needs to have someone logged into it. If you try to run the task in unattended mode it won't like it. So for our clients we use what we call a data collector, we build the collector and then schedule the tasks. Once done we then just lock the pc/server and leave it like that

Lewis