Is there a way to trigger a task in Nprinting Version: 188.8.131.52 after completion of a QVW task in QMC like it was done in Nprinting 16.Can anyone please help me on this.
I don't think version 17,0,2,0 had API's.
I suggest you upgrade your environment and use below mentioned solution.
When applicable please mark the appropriate replies as CORRECT. 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.
BTW - there is no other way to achieve this, so eventually you will have to upgrade anyway
Thanks Lech for your response, If we upgrade the Nprinting to latest version is this supports Qlik 12.02040 SR5 version.
Apart from this method, Did we have any other possible way to achieve this.
1. Using API is the only way of achieving this.
Api reference is here https://help.qlik.com/en-US/nprinting/November2017/Content/Extending/Intro-Extending.htm
2. BTW - make yourself friend with this website - it will answer 99% of your questions --> https://help.qlik.com/
3. Re version?
I am not super familiar with the versions however you need to meet following requirements
QlikView Desktop is required on the Qlik NPrinting engine computer, even if QlikView Server Enterprise Edition or Small Business Edition is also installed on that server. QlikView Server and QlikView Desktop must be the exact same version, including the release number.
QlikView Desktop must be installed locally on the same physical or virtual computer as the Qlik NPrinting engine.
QlikView Desktop is not required if you are only connecting to Qlik Sense apps.
An alternative to API triggered events is to use a 'polling' trigger in NPrinting that looks at Qlik variables in your app to represent the last reload:
and a time 5 minutes ago or whatever tolerance you want - could be every hour if the report doesn't need to arrive immediately after the reload:
I used a SET statement in a Qlik Sense load script so that NPrinting would evaluate these vars at NP report time rather than at QS reload time, which is what a LET statement would do.
Next, set up a Condition in NPrinting that says:
vLastReload >= vFiveMinsAgo is True
Then set up a Publish Task trigger to run every 5 minutes (or other tolerance if different as per above) with the condition applied. If the condition is False the report won't run and no significant resources are used. If the app has been reloaded and the condition is True, the report runs.
I've used this successfully for a NPrinting report using Qlik Sense v3.2.5 and NP Sept 2017, but should be similar for Qlikview and I can't think much has changed with variables since NP v184.108.40.206? Of course I could be wrong about the latter as that's a pretty old version now
Let me know if this works for you.
very good point Chris And it is a good solution if you have say few publish tasks.
THe only problem is when you have a lot of them (say 100-300). Then throttleing such solution will be difficult and resource consuming
regardles for small deployment your solution i simpler an better!
Admittedly it might not scale well if there are 100's or 1000's of dependent reports like this, but we have over 1,000 apps in our Qlik Sense site, over 100 reload tasks but only a handful that need dependent reports sent out, so it works well. Most reports are sent on an independent schedule.
Of course this example suggests a 5 minute 'poll' resulting in 288 triggers/day, but if the tolerance for firing the report is longer, say within 30mins of the data reload, this needs only 48 poll triggers/day.
To give an idea of the resources involved, using a condition only fires the trigger event and a check of the condition, which is minimal in terms of resources - takes less than a second on our site:
No worries - and like i said this is a great idea and i am not questioning this... My concern was around numbers of reports which require this kind of dependency - and as you pointed 1-2, few... maybe 20 is not a problem..
I was talking rather about 100 publish tasks which can require 5 min pulling frequency to check condition - then it becomes sort of heavy.
...but to be honest - I like your idea better then API solution!!!
Cheers and Thanks
I think we're agreeing
100's of dependent reports - go the API route, which is more resource efficient.
10's of dependent reports - consider a polling trigger, which is easier to implement.