We are using custom rule type in our project extensively. We have report definition running on Data-Rule-Summary (table pr4_rule_vw ). Now we are trying to add additional column to pr4_rule_vw table. Before 7.1.8 , pr4_rule_vw table are controlled by database triggers. After 7.1.8 , looks like pega engine handles data population to pr4_rule_vw table.
We creted 2 property :- one under Rule- and one under Data-Rule-Summary and created corresponding database column in pr4_rule and pr4_rule_vw. When we create the new custom rule, pr4_rule table gets populated whereas the pr4_rule_view table didnt get populated. Is there any steps
Do we need to follow any steps apart from above whenever we need to add additional columns to pr4_rule_vw table (since it is handle by pega engine after 7.1.8 upgrade)?
If that is the case , I would say this as a bug in the product. With clients using custom rule type in prpc , this table should be extendable to use some of the out of the box features in prprc and there is no details on the 7.1.8 release notes either that this table is no longer extendable
Is it ok to use custom database trigger to populate this table? What is the recommendation from the product team?
Our use case is to add a category(property) to the custom rule form and categorize each and every custom rule. In our project , we have around 500 custom rules and we have a separate portal to maintain those 500 + rules.
We have report definition under Data-Rule-Summary that fetch these rules and renders on the portal and if user click a rule, it goes to pr4_rule and open that custom rule and display. So we would like to add these additional column to the pr4_rule_vw table, so that we can use the existing report definition to fetch the data.
My question is that , if there is a custom rule type in the product and it allows customer to use it, then these tables should be extendable. ( might be with some restriction ).
Is there a reason why Pega restrict the client/customers from extending these tables and keep the data population code within the engine and not exposing to customer or client?. or if the code is within engine, is there any recommended approach?
Maybe I am not able to follow the use case correctly. Kindly clarify why the report definition is on Data-Rule-Summary when you want to fetch rules that are custom (I am assuming your own rule type)? Would it be possible to write the report on that specific rule class so that you get this data from that table where the column is exposed?
Also, as Jamie suggested, we don't want customers to write their own database triggers. Would a Rule-Declare-Trigger help solve the issue for you if do need to definitely have this information in pr4_rule_vw table?
I would be a little nervous about adding even a Rule-Declare-Trigger to update Data-Rule-Summary and the pr4_rule_vw table. I believe that Data-Rule-Summary needs to be regarded as "read only" as far as the application is concerned. Any changes could have the potential to break product functionality. Ultimately, Data-Rule-Summary is not currently designed to be extensible as far as adding new properties goes.
As Rajiv suggests, perhaps there is a way to satisfy your requirement by reporting directly against your rule table(s).
An issue in the custom application code or rules. Data-Rule-Summary and the corresponding pr4_rule_vw table need to be regarded as "read only" as far as the application is concerned. Any changes could have the potential to break product functionality. Ultimately, Data-Rule-Summary is not currently designed to be extensible as far as adding new properties goes.
We had used index table to populate the new column and used a join to pull the data.