Can you confirm that Nprinting Apr 2018 has monthly reload option, which was missing in Feb edition.
My requirement is to send a report on a 1st of every month. Since monthly schedule option is not available I created Qlik Sense front end variable called 'day' to display day part of today. At Nprinting side I have created a condition on 'day' =1 to publish the report. But practically condition is failing everyday including on the 1st of month.
I understand that your application (qvw) is reloaded on QlikServer and you would expect NPrinitng to pick it up refreshed when NPrinting report will be generated. In order to do this you MUST regenerate metadata in NPrinitng for your LOCAL connection which in case of big files (like you said can be time and resource consuming)
I understand your approach and agree that opening time for big applications will be much longer than for small qvw. What i am unsure about is if since you are actually using 2 connections to generate report (one for conditions and one for actual application with data) NPrinitng might still open both of them despite having condition only on one. - This is something you can check by yourself by inspecting session 0 on NPrinitng box.
Down to LOCAL connections and big files like from your example - i think it is very unefficient to go this way as you have to make sure your NPrinting server has enough memory and CPU to open and perform snapy calculation on LOCAL QlikVIew instance. Therefore you are wasting hardware as you simply duplicating hardware to allow qvw to be opened also on NPrinitng server. Instead you could use QVP connection and leave ALL heavy lifting job to QlikVIew server and NPrinting server can be then say 8 cores 16 gb ram small machine. Since it will use QVP you can have warm start or even pre-load files to memory, you will not have to re-generate metadata every day and you will have single file to maintain.
I would only go for LOCAL connection in case if you have no QlikView server!
It is all about choices i guess, and i would never choose LOCAL connection option - long term it will still drain all the resources from the machine where the LOCAL instance is running since it will not care about resource management (RAM & CPU).
cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
The reason I've used LOCAL connection is that i do not want NPrinting to put pressure on the QVS machine. We have applications that necessarily aren't accessed on the QVS machine(s) on the same day as NP report execution and by opening up a QVP connection we will consume memory and CPU on the QVS to produce the reports. We also have quite a lot of NP specific applications that we do not want to publish to the QVS(s).
These are some reasons why we have decided to go "LOCAL" only at this stage.
I will update this case with my findings if both connections are "re-freshed" at time of task execution. If NP loads both qvw's there's no reason to have a specific condition check connections at all.
Also, a better approach for monthly / weekly triggers is most likely to use API and the task execution end-point and start the NP job from QMC instead.
I really appreciate your time and effort answering my questions and/or concerns!