Nprinting Qlik Entity report needs Cache refresh

[Udo]

Hi all,

We have set up two Qlik entity reports in NPrinting, that export a table to CSV. I't seems, we need to run the metadata cache refresh regular before we run the report. If we do not refresh the cache we are getting empty csv's. We are sure, no structural changes except a reload are done on the Qlik apps, where the report is sourcing from. Both Qlik apps are built on binary loads. Is this a known behavior or is there something we can look at?

Thanks,

Udo

Edit: Updated labels...

[Lech_Miszkiewicz]

Hi,

...and as always regarding this question we have to ask - what type of connection are you using? LOCAL or QVP (Server Claster)? 

more on that here: https://community.qlik.com/t5/Qlik-NPrinting-Discussions/Do-I-need-to-create-a-trigger-on-NPrinting-... - have a read where I explain importance of the connection type used and how it affects data flow. 

cheers

[David_Friend]

@Udo have a look at this article:

https://community.qlik.com/t5/Knowledge/NPrinting-reports-include-outdated-data-until-connection/ta-...

Let me know if this helps!

[Udo]

Hi Lech, sorry I tagged this with QlikView, but we are using QlikSense... So there is no differentiation between local or qyp...

Thanks,

Udo

[Frank_S]

@Udo

Yes, 

it's important to have the correct info so we can respond accurately. Lech was otherwise correct in the direction he was heading as per QlikView connections as QVP not local connections are necessary with QlikView for up to date data.

But since you've updated this discussion from QlikView to Qlik Sense, then yes you must reload your NPrinting connection 'after' a reload of your Qlik Sense app reload if you want to have the most up to date data in any NPrinting type of NP report including entity reports. 

Although it could be written better, the point is made here...more or less:

• Reloading connection metadata

This is also mentioned in the article shared by David.

Kind regards...

[Lech_Miszkiewicz]

ok guys - this does not make sense in my opinion.

@Frank_S - this is news to me, I am very surprised. Where in documentation we have that "you must reload your NPrinting connection 'after' a reload of your Qlik Sense"? - This was always a case for QlikView LOCAL connection only-right? We are not talking here about changing objects we are only talking about report being generated with most up to date data. Did something change and it wasn't announced or do you refer to "best practices and recommendations" which are treat different to "requirements"?

@Frank_S  @David_Friend @Ruggero_Piccoli - guys - lets clarify this topic - we had in the past the same question over and over here on community and we never were able to commit and say that you MUST ALWAYS regenerate metadata if you want to have the most up to date report when running it from Qlik Sense connection. In my opinion this is only the scenario where you have Qlik Sense task reloading Qlik Sense app and right after triggering NPrinting report generation meaning that there is very short period of time between app reload and report being produced which I guess is something what can cause problems. Is that the case? Is this what Franks link to recommendations talks about. If so - we should document it in help document as clear requirement and explain why you would need to do that each time when running report from Qlik Sense. 

So my extreme scenario question is very simple and you guys are experts in this are so should be straight forward. Also this is most common scenario when using API in task chaining so obviously the most common:

1. I have Qlik Sense app and I have bar chart in it which i use in my NPrinting report
2. Every day I have NPrinting task distributing this report to people
3. If this NPrinting task is started 1 second AFTER Qlik Sense app is reloaded (via QMC) will NPrinting pickup the most recent data for my chart? Yes or No?
   1. Yes - ok - then why it does not work for @Udo scenario with Entity report?
   2. No - why? - We never had documentation regarding this (all documentation is in regards to QlikView LOCAL connection which is different for obvious reasons)

Now - links:

• Davids link applies to QlikView, so it is not applicable to Qlik Sense
• Franks help page link describes what we know and it also describes recommendations/best practices and I agree it says it is recommended to have metadata refresh when frequent data reloads are in place - it doesn't say it is a requirement though which is very big difference.

Appreciate your comments and thanks in advance.

cheers

Lech

[Digvijay_Singh]

@Lech_Miszkiewicz 

just sharing my experience on this! I have observed this below scenario multiple times. I trigger nprinting task right after the reload through rest connectors in the script - 

"In my opinion this is only the scenario where you have Qlik Sense task reloading Qlik Sense app and right after triggering NPrinting report generation meaning that there is very short period of time between app reload and report being produced which I guess is something what can cause problems."

Thanks,

[Lech_Miszkiewicz]

Hi @Digvijay_Singh 

Well - my point is that if that is the case then it should be documented and communicated. I had in the past similar issues where some of variables were not updated on time and those variables were used in conditions - so you can imagine the impact of them not being up to date. I started building a support case but I couldn't replicate issue so i stopped. Then we had multiple questions from various users "when should they regenerate metadata" etc.. and we always said that it is only required for QlikView LOCAL connection and if there is structural change to app (new object, field, variable etc)

Now this seems to be known issue that on some rare occasions NPrinting picks up old data from Qlik Sense despite app being just refreshed. I just want from Qlik statement that this happens on some occasions and that we must generate metadata always to ensure most up to date data in reports. This obviously puts big target on Qliks back because for all that time they claimed it is not required for connection to Qlik Sense. Well - we may also hear that maybe in our scripts we should put a Sleep () command when starting script triggering NPrinitng task via API to allow previously reloaded Qlik Sense app to be stored on server drive and also loaded to the memory. That would then be also clear, direct statement to what we must do - otherwise it is not reliable enterprise tool, right?

what do you think?

[Ruggero_Piccoli · Accepted solution]

Hi,

You must refresh the connection cache when the structure of the app/document changes (you add/remove a field or a chart etc) and to see the effects you must also close and restart the Designer because it reads the caches on opening. You have also to refresh the connection cache when new distinct values enter in a field and you want to see them in the Filters editing. This is for all types of connections. 

If nothing changes in the structure you also must reload the connection cache for QlikView local connections. This is to force the closure of all Qv.exe processes that will be reopened with fresh data when creating reports. You could also manually kill the Qv.exe or create something that kills them without doing the reload. The best practice is to do connection reload via Web Console, trigger or APIs so the process is managed by Qlik NPrinting and your connections will be completely updated.

Qlik Sense connections do not require a cache reload if you need only to have the data updated (no changes in the app structure). The connection cache reload forces the reset of the session and I don't see any issue in doing a reload before generating the reports so you can keep this solution.

To investigate what is happening I suggest you to open a support case with everything we need to reproduce the issue. 

Best Regards,

Ruggero

[Udo]

Hi @Ruggero_Piccoli 

Thanks, in this case we will create a support case. Sinse we are using Qlik Sense, there are no structural changes, and still the report is empty, if the cache is not refreshed. 

Thanks,
Udo