What is the Qlikview Best Approach?

[#1]

Hello World!

Since I started to use Qlikview I have been constructing my opinion on this question. What is the best approach for a QlikView architecture?

Case Study / Environment:

I have a set of partners that want to explore the Management and Financial information inside of the organization.

First Approach:

Every partner have a Qlikview Client license and they should use it to access to a solution with QVW extension.

Second Approach:

You have a Qlikview Server, Publisher and Workbench license and you develop the reports in a website with the Qlikview components.

What is your opinion? For me the benefits of the 2^nd seems to be only the online factor. How about the financial factor? What is the best? There are any other benefit or a must have that I'm not considering?

Thanks in advance!

Regards,

Joao

[johnw]

If the partner is directly opening the QVW without using a QlikView Server, their own desktop PC must be powerful enough to host and process all of the data for the documents they open. For any reasonably-large documents, that means using 64-bit QlikView with a 64-bit operating system and with lots of RAM. I haven't priced hardware, but I suspect it will be much cheaper to have a good server, and not have to worry about what machines the partners have on their desks. It should provide much better economies of scale.

Also, if the partner is opening the QVW directly, rather than through QlikView Server, they have full development access to make changes as desired, or even delete the document. I suppose you could control it by giving them read only access in Windows, but QlikView itself would still let them make modifications, and then they'd only find out they couldn't do that when they tried to save, I suspect. Not the end of the world, but not really what you want either.

There's a third approach of having the partners do an "open in server" instead of using QlikView Publisher and Access Point. We used to do it that way, and now we use Publisher and Access Point. I prefer the Access Point approach, but I'm not the one paying for the software.

[#3]

Hello John

Thank you for your reply it was very helpful. So I can say as well that performance is a benefit for sure to use an Server and Workbench approach. Tell me something… in this architecture why I would need to use a Publisher? Its worthy? You have to apologize me but I'm quite a freshman using Qlikview. I had a idea before that the Publisher was used to schedule the reload of data into Qlikview, but if you are using the Workbench it doesn't mean that you have a direct connection to your database? Do you still have to schedule an reloading?

Regards,

Joao

[johnw]

I'm not a Publisher expert, though I've certainly configured my share of tasks in Publisher. I think of Publisher as more like a scheduling program that is specific to QlikView, allowing you to do things like loop through values of a field, generating a separate document for each. For instance, you might want a separate document for each customer (which you could send to those customers) rather than one document for all customers. Publisher has a lot of QlikView-specific options like that where a general-purpose scheduler would not. Still, many shops can and do make do with general-purpose schedulers.

You DO want a scheduler of some sort, though. You do not want your users hitting the reload button, even if that is technically an option. From their perspective, this can take a while. A typical reload in our shop might take one to five minutes, which is longer than users are going to want to wait to see data. Our worst reload takes about three hours. I've heard of someone else's reload at another shop taking ten hours. Users aren't going to wait. That's something you need to schedule.

Also, I wouldn't want my users having a direct connection to my database. In fact, I don't want my user DOCUMENTS having a direct connection to my database. My general rule (which we do admittedly violate on occasion) is that you should ONLY connect to the database from a special purpose QVW with NO user objects in it, that exists only for the purpose of writing out a QVD. User documents then load only from QVDs. This centralizes database access to a single spot. One database read can support many applications. Reading from a QVD is typically MUCH faster than reading from the database, so this can speed things up overall even if it involves an extra layer of complexity. Also, you could completely switch your DBMS, or change to a flat file read, or an Excel read, and the user applications wouldn't need to change. You would only have to change a single document, and one that is nothing but a simple script with no user objects. The QVDs created in this way slowly become a de-facto data warehouse, at least if you're careful when creating them to make sure they can all work together.

[#5]

Thanks again John!

I have to read carefully all this information to understand it better, but I think I have all the information that I need (in this first step).

Before your answer I was thinking that the Workbench Controls in the ASP.NET are a Components that have an DataSource. Right now I think I can say that they use the Qliview virtual database right? (Like a QVVW document). I never used Workbench but I'm going to use it soon (I'm waiting for the license).

In your words I think I can say as well that a reload its like an ETL that transfer the data from the database for the virtual database. That's why you are saying that you want to schedule it (like a job right?).

Very interesting...

Thanks again!

Regards,

Joao

[johnw]

jpestana wrote:Before your answer I was thinking that the Workbench Controls in the ASP.NET are a Components that have an DataSource. Right now I think I can say that they use the Qliview virtual database right? (Like a QVVW document).

I'm not familiar with ASP.NET, so can't answer.

jpestana wrote:In your words I think I can say as well that a reload its like an ETL that transfer the data from the database for the virtual database. That's why you are saying that you want to schedule it (like a job right?).

Yes, a QlikView reload is an ETL that transfers the data from the real database (or other data source) to a QlikView-specific copy of the data, whether that's in a QVD or QVW. ETL usually takes more time than you want your users to sit through, so this should generally be scheduled.

There IS yet another option, which is real time update. I have not used that, and don't know how it works, but there is a way to tell QlikView to remain in sync with the database, I would assume through some database triggers of some sort sending data to QlikView directly every time a row is inserted, updated or deleted.

[#7]

Ok John! Right now I'm really interested about Qlikview integration with ASP.NET (I think I can say that it means Qlikview Workbench). Anyone knows more about the topic? There are any limitations?

Apreciate that!

Regards,
Joao

[suniljain]

I alredy posted workbench installation and configuration document in share qlikview. pls refer it.

and if you have still any query pls reply me.

[#9]

Hello Sunil,

My problem its not with installation and configuration, it's more about the purpose and concept behind Qlikview. Do you know why I should use Workbench and not to use a direct link acess to a QVW report?

Regards,

Joao