Documents related to Qlik NPrinting.
I've released the NPrinting Governance Dashboard at the following location.
It is a Qlik Sense App that loads a large amount of information from the NPrinting PostgreSQL repository to help administrators better visualize and understand their NPrinting Deployments.
The app will load and display details about the NPrinting environment whether you use Qlik Sense as the back end or QlikVIew. But the app itself is a Qlik Sense App.
Requires the use of NPrinting April 2020 and later. Earlier versions of NPrinting are not supported.
1. Deployment Summary
- Summarizes the version , features deployed and amount of content deployed
2. Report Delivery Overview
- Shows directional report names and volume to desitnations and recipients per month
3. Data Connections
- Over view of all data connections and their status
4. Qlik Lineage
- Shows the lineage from Qlik App -> App Object -> Report as well as a score of the reports complexity vs executions
5. App Content
- Aggregates a list of all tasks, reports, filters etc.. by NPrinting App . Also shows dependencies between all objects ( Tasks -> Reports -> Connections , Report Filters -> Filters -> Connections , Task Conditions -> Conditions -> Connections etc...)
6. Task Recipients
- Shows a grid of all groups and recipients and which tasks / subscriptions they are configured to receive
7. Execution Analysis
- Lists all Publish Tasks, Subscriptions, and OnDemand requests showing a range of each execution time
- Lists all users and the groups, roles, tasks, subcriptions, ondemand requests that they own or belong to
9. Execution Log Messages
- Shows all messages from the repository about executions. Does not load information from the logs themselves.
Great job! Thanks!
Love it!!! Such a great app.
My comments below and possible room for further improvements which are not currently in but (i think) will not be too hard to add:
Anyway - thanks very much for such a great effort. I really appreciate this app!!!
hi @Lech_Miszkiewicz . Thank you for the feedback. Yes the field level would be a whole new level of governance and oversight and powerful. While it would be relatively easy to add the ability to drill into fields for filters, I was contemplating and ultimately left out (for now) the idea of associating fields to not just filters, but reports, connections, conditions maybe tasks, and ultimately users. That would allow a lot lineage and dependency questions to be answered. i feel like that is real target to harness the associative magic of the engine but i know it wouldn't be a simple fact table add, i would need to add new fact type records for most of the fact tables in the model and new link table record tyupes for the link tables. I've done a lot of that already and the structure is there (i think) to expand the model. But i'll wait to see what other feedback there is before doing that. Already the style of the app is one that will likely need updates with every version if/when the repository expands so i'll have to set aside time to keep up with things. Anyways really appreciate the feedback there.
For complexity, i know and agree that most reports will come out as "complex" . To answer your , question its 'non-official' from a qlik standpoint and the rationale has to do with the # of content resolver requests that would be generated by the report and content resolution is the biggest part of report execution which is , basically waiting for NPrinting to issue and retrieve all the data requests from QV or QS . I do feel like a report with even a single level that iterates 3-4 objects can result in often dozens of separate associative queries (or content resolver requests). When you take into account all the objects, selection states that are driven by levels, pages, and cycles, it easily becomes a lot of requests. Having 5 objects or a single multiplier (level/page etc..) is enough to bump up the complexity . A 4 core NP engine out won't have enough cores to handle 5 concurrent content resolver requests , and an 8 core engine won't be able to handle 10 requests. So if you want to run a complex report (10 requests+) quickly you should have a 12 core engine or engines. Otherwise , and probably in spite of, there will be serial processing most of the time . So even mildly complex reports can take a bit more time and that's where the designation comes in. Hope that helps a bit. if you feel there is another driver of complexity besides this kind of estimation of performance / load please share . Once again thank you very much
Really great work, very helpful. Will give it a test drive for sure.
it was written there all along 🙂
This is awesome! Thanks Jonny
I got an error (copy below) when reloading. There was no public.smtp_destination_to_to table in my database. I just commented out that part of the code and now works perfectly. We are running Qlik NPrinting February 2020 (Version: 18.104.22.168)
The following error occurred:Field 'smtp_destination_id' not foundThe error occurred here:SQL SELECT "smtp_destination_id","email"FROM "nprinting"."public"."smtp_destination_to_to"
Hey @haty ,
I had the same 'issue' on a November 2019, but from my point that should be expected since one of the requirements is having "NPrinting April 2020 and later"Just as you, I commented that section and everything worked smoothlyRiccardo
Correct. In April 2020, new fields were introduced into the repository to support dynamically resolved additional email addresses in the publish task generated recipient emails.
It's that enhancement that is responsilble for the load error in < APril 2020 versions.
Commenting out may allow the load script to complete but i'm not able to comment on accuracy of the data .
Has anyone attempted to build a scheduler off of this data? Is it possible to create a table that shows potential trigger times? This would be the next biggest piece of help in a dashboard such as this! Really great work though, and thank you for the detailed document on how to implement.
Great application, we have that deployed and is working perfectly.
November 2020 version introduced Audit Trail feature. Are You planning to extend Governance dashboard by adding details from Audit Trail?