Qlik Community

Ask a Question

QlikView Administration

Discussion Board for collaboration on QlikView Management.

Announcements
On Demand Webinar: See Why Thousands of QlikView Users Have Switched to Qlik Sense. REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
kdmarkee
Specialist
Specialist

QlikView 12 QMC Simple Reduce functionality

I want to get a better understanding of how the Simple Reduce in a QMC Publish Task works in combination with the script logic within the load script used to Reload the qvw that has the Simple Reduce applied to it.  For example, I have a qvw called Data Model.qvw that is loaded by my UI qvw called Cogito Analytics.qvw.  One of the Publish Tasks on Cogito Analytics.qvw  is going to do a Simple Reduce on a field in my Fact table that will limit the data rows in the final Cogito Analytics that is published to Access Point.  If my Data Model has "where exists" logic in it for my dimension tables so only the associated rows get loaded as dictated by my Fact table, will it honor that "where exists" logic after the Simple Reduce is applied?  Another way of putting it, how do I make sure that my dimension tables are not being loaded in their entirety?  Is the Simple Reduce smart enough to know that if Fact table rows do not meet the Simple Reduce criteria, then the associated dimension table rows should be excluded as well?  More simply put...what is the order of processing... does the Data Model script run in full and then the Simple Reduce takes place on that end result?   I did some testing with and without my "where exists" logic and it my resulting qvw sizes are only slightly different, so I'm not able to determine what is actually happening during publication.   Hopefully that makes sense.  Thanks.

simple reduce qmc.PNG

Labels (1)
1 Solution

Accepted Solutions
hopkinsc
Partner
Partner

Sorry, i think i left out the most important bit 🙂

the script will always run first, so it will respect your where clause, then it basically makes a selection on the field in the simple reduce and reduce the data based on each of the values in that field and produce QVWs or PDFs (whatever your setup is) in smaller chunks. 

View solution in original post

6 Replies
hopkinsc
Partner
Partner

Hi, Any where clause in the data model will run when the data model is run, so the resulting data after the reload will exclude any data that falls outside of the where clause. 

So when the front end QVW is run and the reduction is done in the QMC and distributes smaller datasets to the recipients, the dataset it starts with will be what was created in the dataload.qvw.

The front end qvw will never see ALL of the data if dataload is restricting it. 

 

Is that what you mean?

hopkinsc
Partner
Partner

Sorry, i think i left out the most important bit 🙂

the script will always run first, so it will respect your where clause, then it basically makes a selection on the field in the simple reduce and reduce the data based on each of the values in that field and produce QVWs or PDFs (whatever your setup is) in smaller chunks. 

View solution in original post

Brett_Bleess
Support (Former)
Support (Former)

Hopkinsc is spot on here, but I wanted to try to summarize things to ensure everything makes sense to you.  The reload will occur first as Hopkinsc noted, which means any data restrictions done via where statements there will reduce the data that is then going to be in the resulting qvw, but after that occurs, Publisher will then apply your static reduction selection to the data model, and it will drop all values that are not associated with that selection, which Hopkinsc alluded to as well, but I wanted to be sure you followed that the non-matching values are in fact dropped from the model completely. 

What you may be thinking of here is using Section Access and Dynamic Data Reduction fields, in that case, the QVW generally has the full data model, and you are relying on the Section Access Reduction fields to reduce what the users see, but the underlying model does in fact contain all the data in that case.  

This is the beauty behind the Publisher Reduction setup, the resulting QVW only has the data that applies to the user associated to the reduction(s) you put into place.  Hopefully this helps further clarify things and Hopkinsc, sorry for stepping on your toes, you get full credit here, I just wanted to try to make things a bit more clear, and hopefully I pulled that off.

Regards,
Brett

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.
hopkinsc
Partner
Partner

Thanks @Brett_Bleess . that was a bit more plain english than my version Smiley LOL

kdmarkee
Specialist
Specialist

Ok, thanks for clarifying so quickly.  I assumed but wanted to be sure that in fact the reload in the script happens first, gives you a resulting qvw, and then from there the QMC task does the reduce on that resulting qvw.  Thanks!

kdmarkee
Specialist
Specialist

Thanks for the extra detail, always appreciated in the Community.  You mentioned Section Access...I am actually implementing that as well in my script loads.   In light of sharing, we have a complex set up because we have internal and external users.  We have a REALLY large qvw that has data from 2010 through today in it and it includes data from all of our client groups.  I use Section Access to allow our internal users to see all the data for all client groups, whereas our external users can only see data associated to their productivity.  I use QMC Simple Reduce to distribute a qvw for each client group so the external users only can see and log into their group's data, and I am also now going to use Simple Reduce to split my large qvw into 2 apps  as well (one with the last 4 years and one with all the older years).  So the Section Access is controlling the data rows visible to users, and the Simple Reduce is to help with performance by trying to keep the qvw sizes in Access Point somewhat tolerable.