Client say has 10+ applications in the scope of upgrade. All the applications are separate installations altogether leading to 10+ independent upgrades. They want to check the feasibility to merge 3 small- medium sized applications(say one in 7.1.8 and two in 7.1.6 and 7.1.5) through a POC.
While doing so, high level plan is to merge the rules of the selected 3 applications -
Import the Rules RAP of 7.1.6 and 7.1.5 application in 7.1.8 Rules schema and start maintaining one Rules Schema (just like performing Install and Migrate approach). Data schema would be separate for 3 of them. 7.1.6 and 7.1.5 Data Schema would be upgraded to 7.1.8. So eventually there is one Rules Schema and 3 separate Data Schema. Post the merge in 7.1.8, it will be upgraded to 7.3....Rules at one go and Data separately for 3 apps.
1)What considerations should be taken at the App server configuration to support the above mentioned change? On App server side, Would we require to configure JNDI settings by logically separating into separate JVMs.
2) Is there any potential impact in split schema configuration with one rules and multiple data schema to support multiple applications?
3) Any best practice suggestions if there is any technical constraint or severe cons which may impact maintainability down the line.
For example - if Rules Schema of 3 apps are merged some infra sizing at the hardware end might be required, or say with this approach in future all applications have to upgrade at the same.
I understand that you want to have 3 deployments but want to have a single rule schema, and 3 different data schema. I assume that all the 3 applications reside in a single database server but in different schemas. If my assumption is wrong the following points can be ignored.
In this case you will need to have 3 app server instances to run these applications parallely. Just the JNDI configurations need to be altered in each app servers / profiles (Websphere.). However we might have slow performance in this scenario because we are interacting with the same DB server but in different schemas. We might need to alter the connection pool settings. Discuss with your DBA's and proceed further on this.
With this approach if you are going to upgrade to newer version. You need to perform 1 rule schema upgrade and 3 data schema upgrade separately. This might increase the production down time because we are going to keep the apps down till all the data schema upgrades are completed.