Can we have different/seperate JDBC data sources for RULES and DATA (Work) schemas
As per documentation, PEGA has started supporting split schema model in PRPC7.1. Even though, it supports two schemas in split schema model, application uses only one JDBC data source to access objects in both the schemas at run time. Is it possible to make PRPC application to use two JDBC data sources (one for Rules and One for DATA) instead of one? If so, could you please share some documentation?
Please find below our application server and DB details.
Application Server: Weblogic 12.1.3
Database: Oracle Proprietary information hidden.0
Accepted Solution
Pegasystems Inc.
US
What you are asking for is "split database". The short answer at the moment is NO, that's not supported.
Techncically, most of the time application and system queries will only reference items in one schema - rules or data - but there are some queries that join rules with data and they will not work if both schemas are not accessible from the same data source.
I agree that there are compelling arguements for true "split database", and it "mostly" works with a reasonable amount of effort but that is not a supported deployment pattern.
Pegasystems
IN
Is it possible to make PRPC application to use two JDBC data sources (one for Rules and One for DATA) instead of one?
Kindly share the use case for doing this.
Rulesware LLC
US
We have a multi data center environment in production and would like to have data center dedicated rules schemes and one common DATA scheme which will be shared by all data centers.
Accepted Solution
Pegasystems Inc.
US
What you are asking for is "split database". The short answer at the moment is NO, that's not supported.
Techncically, most of the time application and system queries will only reference items in one schema - rules or data - but there are some queries that join rules with data and they will not work if both schemas are not accessible from the same data source.
I agree that there are compelling arguements for true "split database", and it "mostly" works with a reasonable amount of effort but that is not a supported deployment pattern.