Qlik Community

Qlik NPrinting Discussions

Discussion Board for collaboration on Qlik NPrinting.

Announcements
Now Live: Qlik Sense SaaS Simplified Authoring – Analytics Creation for Everyone: READ DETAILS
cancel
Showing results for 
Search instead for 
Did you mean: 
kdmarkee
Specialist
Specialist

NPrinting Nov 2020 metadata reloads stay in Running status

We recently upgraded to NP Nov 2020 and QlikView April 2020 SR2 and I am observing 2 things with NP metadata reloads:

1) progress always seem to show 0%, even for reloads that work - is this normal?

2) some reloads are not working - is there a app size limit by chance in which a metadata reload will work?    I have tested 2 metadata reloads... one was 196 kb and the reload was successful in 10 mins, the other is 339 kb and this one stays stuck in "Running" status when I expect it to finish in at least 15-20 mins based on the experience of the other reload.  Never had an issue with app size before.  And yes, both apps pass the "Verify Connection" test.  I don't find the logs helpful either.

Labels (2)
7 Replies
Ruggero_Piccoli
Support
Support

Hi,

Try to upgrade to QlikView 12.50 SR3.

Be sure that the connected QVWs has not unsupported features like macros, always one selected or triggers. 

Be sure you are not using a QlikView leased license from a server. You must use a named CAL or a license key with control number for each Qlik NPrinting Engine. 

You could also enable the debug mode for logs to check if there are specific errors.

Best Regards,

Ruggero



Best Regards,
Ruggero
---------------------------------------------
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 with a LIKE if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads with LIKEs if you feel additional info is useful to others.
kdmarkee
Specialist
Specialist
Author

I was able to figure out what NP did not like about my app.  Basically, once I had a filter value selected in my app, saved it, and then deployed it to Access Point, NP liked having a filter on vs when I did not have any filters selected at all prior to deployment to Access Point. (maybe NP treats a filtered app as if it were a smaller app?)   And here is how I stumbled upon this... this was one of 3 apps that get distributed via Simple Reduce tasks in the QMC from a single QVW.  In that single source QVW I did have a year filter selected with 2020, and saved, prior to deploying my 3 apps.  Well, the problematic NP metadata reload was on the app where the Simple Reduce was for years older than 2017 (meaning it lost the filter selection of 2020 since it did not exist), but the metadata reload for the other 2 apps worked just fine (one being even larger than the problem one, by the way).  So I used a different field to make a selection on, one that exists in all 3 of my deployed apps regardless of the filters I had set in my Simple Reduce tasks, and once I did that, all 3 successfully reloaded their NP metadata.   An interesting find, but I can't help but wonder if that is by design or a bug.

Lech_Miszkiewicz

Very interesting find Kris. I am glad you get it all figured out and I bet you it is very valuable lesson for many of us. Personally I have never experienced anything like this before and I am sure I would be scratching my head on why this is not working. 

thanks for detailed explanation!

@Ruggero_Piccoli - do you think this is something R&D could replicate now and test?

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.
Ruggero_Piccoli
Support
Support

Hi,

I suspect there is something wrong in the QVW that is generating the issue. I suggest to set the logs to DEBUG level, reproduce the issue and check if there are specific error messages. 

When a QVW is not using unsupported features like "Always one selected" option the Qlik NPrinting caching process will remove all filters saved before generating the cache. The Access Point doesn't impact on the cache generation.

Best Regards,

Ruggero



Best Regards,
Ruggero
---------------------------------------------
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 with a LIKE if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads with LIKEs if you feel additional info is useful to others.
kdmarkee
Specialist
Specialist
Author

I did not find any unsupported items in my qvw, and I even ran a few more tests to solidify my earlier findings. 

I took my qvw (which has 4 years of data loaded into it) and ran the following scenarios and got the following results (app size is 510 kb):

  • No selections made in the app prior to deploying to Access Point – NP metadata reload was still running 2 hrs later, so I aborted it
  • Made a selection in a field in the app and saved that selection prior to deploying to Access Point – NP metadata reload took 30 mins to complete

I then took that same qvw but only loaded 2 full years of data into it and ran the following scenarios and got the following results (app size is 265 kb):

  • No selections made in the app prior to deploying to Access Point – NP metadata reload was still running 50 mins later, so I aborted it
  • Made a selection in a field in the app and saved that selection prior to deploying to Access Point – NP metadata reload took 25 mins to complete

The final test: I then took that same qvw but loaded a very small subset of data into it and ran the following scenarios and got the following results (app size is 38 kb):

  • No selections made in the app prior to deploying to Access Point – NP metadata reload took 2 mins to complete

There might be some other obscure thing playing into this, but I have yet to find it.  There’s just no denying however that the same sized qvw deployed with and without a selection are not behaving the same way with regards the NP metadata reload.

Lech_Miszkiewicz

very strange Kris, such small app taking so long to (few kilobytes as you say 30kb-500kb). You can run this on the min spec laptop. There is clearly something wrong with this app or environment if you get such results. Creating empty app is already taking few kb so I am not sure how it is possible....

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.
Ruggero_Piccoli
Support
Support

Hi,

Do you have issues only with this specific QVW?

Best Regards,

Ruggero



Best Regards,
Ruggero
---------------------------------------------
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 with a LIKE if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads with LIKEs if you feel additional info is useful to others.