Question
Multiple PRPC applications share the same PRPC database instance.
I understand PRPC in general support multiple applications sharing the same PRPC rule base. But Is this the recommendable approach for enterprise application ?
I can see there are some overhead or restrictions in this approach
1. For SSO, if one user access multiple application, user might end up in wrong application and has to manually switch applications.
2. Overhead in separating assignments, queue items, attachment links among shared tables.
3. Overhead in purge and archiving.
3. Performance, sometime core application in production can be impacted by other shared applications.
4. Individual application production migration and upgrade
5. AES monitoring, need to separate production diagnostic for each application.
What is Pega stand on this approach ? Any other pros and cons in this approach ?
Many Thanks !!
Tom
***Updated by moderator: Lochan to add Categories***
Accepted Solution
Hi Tom,
Thanks for submitting the question. Pega's architecture is very different from that of a usual enterprise application and thus it may appear restrictive in some ways but these very differences provide Pega its unique capabilities.
Development, testing, migration and monitoring in Pega will have its differences and you'll have to leverage Pega's best practices and features to perform those jobs.
In fact, this architecture provides huge advantages and makes collaborative Pega development, migration and management easy. Use of Pega technology by large corporations to build and host their enterprise applications is a testament to that.
1. For SSO, if one user access multiple application, user might end up in wrong application and has to manually switch applications.
>>> As Eric pointed out, the user will be presented with the application that corresponds to the default access group for a normal login.
SSO can be set up such that different applications have unique URLs and a logged in user can be presented with a different application interfaces.
2. Overhead in separating assignments, queue items, attachment links among shared tables.
>>> Pega does the job of separating these items for you. OTB wizards that package Work will take care of putting together appropriate assignments, attachments etc. when migrating work.
https://pdn.pega.com/sites/pdn.pega.com/files/help_v722/procomhelpmain.htm#tools/packagework/aboutpackagework.htm
3. Overhead in purge and archiving.
>>> Same applies here - OTB wizards help in selecting appropriate Work items to purge and archive.
https://pdn.pega.com/sites/pdn.pega.com/files/help_v722/procomhelpmain.htm#tools/purgearchive/aboutpurgearchivewizard.htm
3. Performance, sometime core application in production can be impacted by other shared applications.
>>> This is where high availability architecture comes to rescue.
https://pdn.pega.com/sites/pdn.pega.com/files/help_v722/procomhelpmain.htm#tools/purgearchive/aboutpurgearchivewizard.htm
4. Individual application production migration and upgrade
>>> Individial applications can be packaged up and exported for migration using Rule Admin Product Rules.
https://pdn.pega.com/exchange/components/remote-configuration-command-line-tool-prpcserviceutils
5. AES monitoring, need to separate production diagnostic for each application.
>>> Monitoring is done at the Pega node level, so I am not sure what you mean by separating diagnostic for each application.
Regards,
Vipin
Well, there's alot of questions there but I can answer a small part:
>>> For SSO, if one user access multiple application, user might end up in wrong application and has to manually switch applications
Pega's internal and external authentication features, starting with the operator ruleform that refers to a default access group, will allow you to specify which application that user will see when they first log in. They'll only need to manually switch if their operator form has multiple access groups and the one specified as their default one is not the one they need to use.
/Eric