Posted: 3 Oct 2016 15:10 EDT Last activity: 4 Oct 2016 17:05 EDT
Preview trimmed version Report Rules in FW Layer Vs Implementation Layer
When we receive requirement on report is most generic. We may develop the report rules in FW layer. Intially, I thought it should be run in FW Layer application. But What happened is, I open the report rule in FW layer by log into impln layer application. Now I am able run report, But What I wonder is, the source of table is refer from FW layer and data are coming from Impln layer table.
We have seperate table for both FW layer and implementation layer.
Sounds like you are querying cases using an FW-layer Report Definition that has "Report on descendant class instances" checked in the "Data Access" tab. If you were logged into your FW-layer Application and had created cases at the FW layer your report would show you those cases. However, it appears you have only created cases at your Implementation layer. When you log into your Implemenation layer Application you add new rulesets at the top of your ruleset stack. Within those added rulesets are case type classes that extend/inherit-from/descend-from your FW-layer case type classes. The FW-layer Report Definition has the ability to recognize this situation. Rather than issue a query for FW-layer cases it will issue a query for Implementation layer cases.
Thanks for your answer. I did not see the config on << Data Access Tab>>. Can We buid reports in FW layer that can be run in impln layer Sections/Mgr Portal etc. But As I observe, there is union query is doing for FW layer, the decendent of Impln Layer.
Let say We have below structure
ABC-FW-SampleFW-Work (Report Rule is here, Report on decentent classes is checked
If I run report on IN Impln layer, Does Pega do union on FW, IN Impln and US Impln classes table mapped.
Posted: 4 years ago
Updated: 4 years ago
Posted: 4 Oct 2016 17:03 EDT Updated: 4 Oct 2016 17:05 EDT
There is no UNION. You would not have IN and US rulesets in the same Implementation layer Application. Instead they would be different Applications with different Access Groups, Class Groups, and Work Pools - work being stored in different tables. You would need a VIEW to to see cases in two different work tables.