Monthly feature is not present in April release.
Methodology and workarounds were described on community many times - please search before duplicating topics!
please read below linked documents - they provide working functionalities.
If your condition does not work, then definitely there is something wrong with your variables or syntax (like missing "=" sign in front of variable, grabbing wrong value (numeric or text, since it is an actual dual value) or something similar).
Please provide us with information of all steps (with the code you have used and screenshots from qlik sense syntax, condition syntax etc.. to help you troubleshoot)
I would follow this methodology to achieve it:
Instead of creating the variables needed for monthly / daily /weekly triggers on the connection you use to produce the report data my recommendation would be to create a simple qvw with a calendar containing all dates you need for all your NPrinting reports and then add the variables in here instead. Reload this qvw when needed and create the connection to this qvw for your NPrinting App.
The up-side with this solution would be that (hopefully) NPrinting does not need to reload the metadata for the "real" connection that might be a long-running and heavy on ressources task but instead reload the metadata for a very small qvw.
What you you say guys, it this a solution that will work not only on paper? It should not be any technical issues other than you will have a lot of connections to the same qvw but the million $ question would be;
Does Nprinting still needs to reload the master data for the "real" qvw - even though the data isn't needed to evaluate the task conditions?
When I have some spare time i will try to set-up a test case for this and see what the logs says (task execution logs for the reload metadata tasks)
I do not see a reason why would you implement second application for condition evaluation?
- Using LOCAL connection - I agree that this would speed up condition evaluation and metadata generation process for this small app however if you are sticking to LOCAL connection - then you need to reload your main qvw to fetch fresh data otherwise you will be left with stale data!
- USING QVP or QlikSense connection - you don't need to reload metadata to fetch fresh data from qvw at all so additional application would only create more confusion and work load and dependecy. Therefore condition in nPrinting application would not create any overhead in such case.
good point with QVP connection. I still think its valid for LOCAL connection though, one big app (lets say 4 GB compressed on disc) will take quite some time to load the data just to evaluate if today = monthstart. Will be a lot quicker on a calendar only app (a few mb maybee).
You can also create all variables and flag fields you need in one app and do not need to alter the main qvws just to change from 1st of month to 2nd of month.
I will perform some testing on this so Im sure that QVP connections are quick for condition checks and that my assumption that the main qvw aren't "reloaded" when not performing any condintion check on them.
I don't understand what you mean with "left with stale data!". I create local connections to my source document folder on QDS - those are just as updated with fresh data as my QVS folder(s).
My QVW used for condition checks will of course be scheduled for reload every day at 00:00.
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).
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!
Next release, June 2018, will have monthly and yearly schedules.
So evaluate if you can wait, I suppose, the end of June. I don't know the exact release date right now.
When applicable please mark the appropriate replies as CORRECT https://community.qlik.com/docs/DOC-14806. This will help community members and Qlik Employees know which discussions have already been addressed and have a possible known solution. Please mark threads as HELPFUL if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads as HELPFUL if you feel additional info is useful to others.