All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.
The concept is simple.
1 - we need to define a standard database for scoping rules. Doesn't matter what it's called, using WRKSCOPE for the purpose of this idea.
2- we create all the relevant objects and relelvant scoping rules here - e.g. I need MARA.MATNR and I end up with a list in my (target) output table that has ZSOURCE/MATNR/ZACTIVE - i.e. my key fields + active flag
3 - I now have my material master object in my WRKDATA (example) database. As a part of snapshot management, when setting up/creating the metadata, I have the option of linking to my specific table in WRKSCOPE from a dropdown list. (e.g. **MARA_T)
When building the table(s) in ETL, so long as I've setup my WRKSCOPE table with the correct keys for the given table, I can use the link from snapshot management, and it automatically puts in the join to hte WRKSCOPE table and I only import active records from my SRC*** table into the WRKDATA..**_MARA_S table (example - i.e. filter SRC*..MARA with inner join to WRKSOURCE..*MARA_T where MANDT = MANDT and MATNR = MATNR, and so on....)
In other words, where we've got big tables, we reduce the load straightaway at point of working table generation. We already filtered the data, so why bring it in again?
We still have the option of doing further ZACTIVE rules to refine the data if needed at hte working table level.
If we're not going to do it this way, can we "default" the index of the ZACTIVE rule to be 30 & push everything else down?
For big tables with lots of manual rules or x-ref, etc, it makes sense to have the ZACTIVE immediately after the insert so that it can be used as a filter in the manual rules, sppeding processing performance. It's not as good an option as automating it into the insert/build, but every little helps....
Guest
Another grand idea, Rob. This entire idea veers much more into Methodology than Product. I do think we should re-evaluate the default order of ETL rules (moving zActive more to the top, others down, etc). But that only works once when the job is initially created. But still, something worth discussing. Linking insert rules or filtering the insert is very much a Methodology discussion. The KEY feature of the methodology is simplicity and repeatability. I believe MOST object (80%) don't need any fancy logic to limit the volume of data. The standard zActive logic is good. For the 20% cases - you can certainly insert from a View, use a Join, or do whatever (with the approval of your project lead). The product automation supports the 80% case - and allows for customizing the crazy 20%.
But - always open to debate. I think this one starts with the Methodology first before any changes to Product can occur.
Attachments Open full size