Nprinting Import User from multiple files Best Practices

[ghaliabed]

Hello,

Question around best practices for Nprinting and report distribution.

Currently we are leveraging Filters at the level of the User to define and customize different Distributions.

Ex: User A receiving distribution from Application A around Costs data. This user has associated with it a Filter holding Project IDs. When Publish tasks runs this user will receive report filtered on Project IDs.

This User is receiving distributions from multiple tasks and from multiple applications and each is applying different filters for the User.

I have currently the following structure:

• Around 15 different distributions being done on Nprinting Production environment
• Around 8 different Nprinitng Applications each developed and being managed by different developer
• Leveraging 7 different Excel Import Task files to populate the list of Users & linking them to Filters to be used for the different Distribution Tasks
• Same user exists in multiple Files for the Import task
• Each import task has a different configuration regarding the Update of Users and Filters
• Order of execution of Import Users task is important and needs to be managed

Problem being faced:

• Having multiple Import task for the users causes sync issues 
• If the correct order of Import is not followed we end up with users missing Filters defined in one of the Import files
• Need for sync across different developers to manage these issues

Possible solutions being considered:

• Adding an ETL process that combines all Excel files used for the Import User tasks into a single Excel File and only have this single excel file Imported inot Nprinting
• Try and remove all Import Files holding mapping between Users and Filters and move logic into the Data Model of the Qlik Sense applications to handle all logic for distribution 
• Find a new way to organize the import tasks to remove sync issues

Any advice or best practices on how to handle this situation ?

Regards,

Abed

[Lech_Miszkiewicz]

My approach is always 1 source of recipient import (LDAP or single XLS file), recipient filters managed in it by using dedicated apps and connections so you can have user loaded with all required filters for all reports.

[ghaliabed]

So you would recommend having a single file imported over say moving all logic to Application data model.

And is there a way to make nprinting read from the LDAP and have user filters defined dynamically (besides API calls)?

Currently i am thinking of having each developer create their individual excel import files in a common folder, and have a separate ETL process that reads these excel files that should all be of the same format. And combine them together.

That way each developer can still create their own needed logic but it's still a single import file for nprinting

[Lech_Miszkiewicz]

My comments in blue:

So you would recommend having a single file imported over say moving all logic to Application data model.

I am not sure what do you mean by: "moving all logic to Application data model". You don;t need to move anything to the application data model unless there is some specific requirement. All what you do is create dedicated apps and connections in NPrinting. 

When I develop report I can create NPrinitng App A with connection A  and develop report A. I can then create NPrinting App B with connection B and develop report B. Both reports can go to the same user X and this user can have both filters for report A and report B allocated in single xls file which is source for NPrinting recipient import. 

Then the logic goes as follows:

• when creating publish task I allocate user group as the task recipient
• I also add in xls recipient file group to recipients i need to send those reports to
  • in our example i may have user X allocated to Groups: ReportA and ReportB
  • i also may allocate filter A (filtering report A) and Filter B (filtering report B) to that user
    • those filters will be respected based on Apps and Connections so they will not intersect each other!!!
• therefore i can create all those filters in the same file.

And is there a way to make nprinting read from the LDAP and have user filters defined dynamically (besides API calls)?

No, there is no way to do that from LDAP

Currently i am thinking of having each developer create their individual excel import files in a common folder, and have a separate ETL process that reads these excel files that should all be of the same format. And combine them together.

I think this will be over-complicated for no reason to be honest... Why cant you/developers maintain single file? User record remains the same (email, name, Domain Name, locale etc...) developers should only update filters and groups and add them/associate them to users as comma separated values in recipient import file... so there is not much of the overall maintenance. 

As long as they understand what they are doing there will be no issue.

Creating ETL combining everything can cause more problems and errors than having just single file...

[ghaliabed]

Thnx for the explanation , and please find further detailing of my points below in RED

So you would recommend having a single file imported over say moving all logic to Application data model.

I mean here having the filter values you would normally assign in the excel file be in the Data Model of the Sense Application.

So in your example user X in App A is assigned filter A;

Instead of having filter A defined in Nprinting; We have in the App A the relation of filter A with the user applied there, and then in NPrinitng something like Cycling or Advanced conditional filtering with section access applied.

Currently i am thinking of having each developer create their individual excel import files in a common folder, and have a separate ETL process that reads these excel files that should all be of the same format. And combine them together.

Cooperating over the same file might not be feasible as not all developers are in the same team so their tasks cannot be fully synced. Also, the content of individual files are created using ETLs as the data is large and complex.

Ex: One distribution is for Project Managers to see data on their projects every month.

We have over 200 PMs and over 800 defined Projects, and the relation between the PMs and the Projects gets changed Monthly.

So the individual files are mostly already being created in a Dynamic ETL process that's scheduled to run.

[Lech_Miszkiewicz · Accepted solution]

My comments in blue again 🙂

Thnx for the explanation , and please find further detailing of my points below in RED

So you would recommend having a single file imported over say moving all logic to Application data model.

I mean here having the filter values you would normally assign in the excel file be in the Data Model of the Sense Application.

So in your example user X in App A is assigned filter A;

Instead of having filter A defined in Nprinting; We have in the App A the relation of filter A with the user applied there, and then in NPrinitng something like Cycling or Advanced conditional filtering with section access applied.

Cycling does not work like filtering - different use case

Agree with section access idea as long as you have 1 report per 1 source (Qlik Sense app). If you want to use 1 document for 2 reports and user needs 2 different sets of filters then section access approach will not work 

Currently i am thinking of having each developer create their individual excel import files in a common folder, and have a separate ETL process that reads these excel files that should all be of the same format. And combine them together.

Cooperating over the same file might not be feasible as not all developers are in the same team so their tasks cannot be fully synced. Also, the content of individual files are created using ETLs as the data is large and complex.

Ex: One distribution is for Project Managers to see data on their projects every month.

We have over 200 PMs and over 800 defined Projects, and the relation between the PMs and the Projects gets changed Monthly.

So the individual files are mostly already being created in a Dynamic ETL process that's scheduled to run.

I see - that is a fair comment. In that case yes - ETL to create a merged version would be ideal solution. You would have to come up with naming convention though for filter and group names so they are unique.