topic Re: Two QVWs during Nprinting design in Qlik NPrinting

Two QVWs during Nprinting design

Anonymous — Fri, 25 Sep 2015 06:31:11 GMT

Hi,

I have realized that when designing reports using NPrinting, you connect to a qvw which opens up when you run a task, job etc.

What happens when the same QVW is used in the server and users are logged in and have done some selections? does it mean you should have two QVWs connected to same QVDs, one being for live production and other being for NPrinting?

Regards

George

Re: Two QVWs during Nprinting design

Daniel_Jenkins — Fri, 25 Sep 2015 07:24:57 GMT

Hi George,

Yes, that is Best Practice. For best results, your QlikView document used as a connection in NPrinting should be as lean as possible. You should try to reduce data to only what is required. Also retain only the objects required for the reports. If you must have other charts and tables you should keep them minimized. If possible, move calculations used in Calculated Dimensions to the reload script instead. Remove Alternate States and all triggers.

HTH - Daniel.

Re: Two QVWs during Nprinting design

Anonymous — Fri, 25 Sep 2015 07:39:47 GMT

Thank you Daniel,

I was really stuck on this issue. now i believe it the best practice as well. Also making the qvw lite and lean is a good idea that i need to practice

Thanks and Regards

George

Re: Two QVWs during Nprinting design

Fri, 25 Sep 2015 12:03:38 GMT

An option I have done in a similar issue is to crate a new qvw jsut for the nprinting reporting, and have that qvw be a binary load of the original - this will allow the report to reference the same objects, have a lean appliation with minimal effort - jsut make sure if you ever change the base application, you will need to include the change in the binary load version as well

Re: Two QVWs during Nprinting design

bme — Tue, 29 Sep 2015 15:01:55 GMT

Just to be clear, there is no harm in running reports from the server copies of QVWs. This would essentially just create a new session for the Nprinting service account and other users would be no more impacted than they would be by a regular user.

If the application is not too large and well designed I often do not bother to create a separate QVW. Is a 5 or 10 second reduction in report generation time really that impactful. The flip side is also true if the application is large or poorly designed the impact could be dramatic. However what I like to do is use the first large QVW to create straight tables with only the necessary outputs, export those via an Nprinting task, reload those into a second QVW, and use that for reporting. Most of the aggregation is done by the first QVW in the straight tables allowing the second to loop records much more quickly.

Re: Two QVWs during Nprinting design

Tue, 31 May 2016 08:11:47 GMT

Hi Daniel

I have the original qvw and a light version with only the objects needed for the report. The orignal is large and complex so I may need to also reduce the history available in the light version.

Original and light are both processed from source docs in parralel and are distributed to user docs.

Original has the nprinting on-demand extension objects embedded. The on demand button is configured to pass through the uers filters.

The nprinting project connection points to light qvw.

The user goes to original qvw in access point using chrome, applies some filters and hits the on-demand button.

Are those filters the user applied in original applied when generating the report?

Thanks

Ross

Re: Two QVWs during Nprinting design

Daniel_Jenkins — Tue, 31 May 2016 22:32:54 GMT

Hi Ross,

Yes. When Use current selections is checked in the extension object Filter settings the current selections made in the original are passed on and applied to the light qvw (connection in the NSQ).

You should see an entry in the internal.log file that confirms this. Look in %AppData%\NPrinting\ODS

HTH - Daniel.