Question
CGI
US
Last activity: 9 Feb 2018 9:22 EST
Specializing an application by overriding rulesets - Course content query
Hello, This question w.r.t to the course content.
7.3 Lead System Architect Course -> #4 Asset Design and Reuse -> Designing for Specialization
Topic: Specializing an application by overriding rulesets (present in page 7 of that lesson)
Question: This topic explains how to create an application by overriding rulesets. Based on what was explained there, is that not how any implementation application is built? If not like this, how else can an application be built?
Say App2 is built on App1. App2 has its own ruleset RS2. App1 has its own ruleset stack. They are calling the App2 as an application built by overriding rulesets. This to me seems like any other implementation application. I'm trying to understand what I'm missing in this "creating an application by overriding rulesets".
Accepted Solution
Pegasystems Inc.
US
Suppose the reason for specialization is because a company has expanded into a new market geographically. Assume it is acceptable to host each region-specific application on a different server. Ruleset specialization can be used for both region-specific applications since each has its own database.
The original application that the two new applications are built on must then be locked down. Updates to the original application would be carefully managed in the future since two applications are now dependent on it. This is no different than declaring the original application a framework from the beginning, but there is no need to.
Each new application would primary specialize "Process", "User Interface", and "Decision" rules in accordance with their region.
Note that this is possible despite never using class specialization. Mentioning the region within the Application's name is sufficient to tell the two apart.
Pegasystems Inc.
US
Yes App2 is built-on App1 and, yes, App2 contains a new ruleset the same as using the New Application Wizard.
The difference here is that App2's ruleset does NOT contain any class that extends a class in App1, at least not until you decide to manually create them.
When using the New Application Wizard and telling it to be built-on another application, it will ask you which case types you want to extend.
On submit the New Application Wizard will first create a new workpool class that extends the built-on application's workpool class,
Then for each selected case type the New Application Wizard will generate a new case type class that directly extends the selected case type.
The basic ruleset override approach does not affect existing case type instances.
In contrast, the case types generated by the New Application Wizard would have different class names, hence, if there are existing case type instances the mixture of the original and the new workpool case type classes which would problematic.
Updated: 7 Feb 2018 16:45 EST
CGI
US
Thanks for the clarification. That actually helped. I've couple more questions after connecting the dots.
- Using wizard and building App2 on App1 - App2's workpool/case type classes extend from the App1's. We want this happen when creating an implementation for a FW, for example.
- Specializing an app by overriding rulesets
- Questions
- Now, what I don't understand is, why would we specialize an app if we don't extend its work pool class or case types? (Example I can think of a scenario like this is, building our initial app on UIKit app)
- If we don't extend the case types, can we just not add that as a component (rule type) instead of specializing the application?
- Questions
With above questions, I'm trying to understand what we can uniquely achieve using "overriding rule sets" concept.
Pegasystems Inc.
US
Your logic is java-centric. In java you can only specialize classes using direct inheritance. In Pega you can specialize class behavior using ruleset resolution. You can also specialize classes using direct and pattern-inheritance but you should avoid doing so until you truly need to. The Single Responsibility Principle within the five SOLID design principles speaks to this.
Components should not include case types. Applications should include cases types. A Component cannot be used to override a case type.
The attached diagram illustrates what the 7.3 LSA course prescribes regarding application specialization.
CGI
US
Inheritance concepts in Pega makes sense to me. I'm trying to understand why to specialize (by ruleset override) an app if we don't extend its classes/case types. We can specialize app in 2 ways: 1. Using wizard 2. Using ruleset override.
Only difference I see is that, using option #2, we extend classes/case types only on need basis. Incase I decide not to extend now. Without extending, what part of the application can we specialize? May be only integration assets, function libraries or utility activities can be specialized. (If that is the case, we can put these assets into a separate ruleset and use it as a component(rule type). I wouldn't go for app specialization using ruleset override if I don't want to extend case types. Ofcourse, I would use a wizard to specialize an app if I want to extend case types. Is my understanding here correct?
Accepted Solution
Pegasystems Inc.
US
Suppose the reason for specialization is because a company has expanded into a new market geographically. Assume it is acceptable to host each region-specific application on a different server. Ruleset specialization can be used for both region-specific applications since each has its own database.
The original application that the two new applications are built on must then be locked down. Updates to the original application would be carefully managed in the future since two applications are now dependent on it. This is no different than declaring the original application a framework from the beginning, but there is no need to.
Each new application would primary specialize "Process", "User Interface", and "Decision" rules in accordance with their region.
Note that this is possible despite never using class specialization. Mentioning the region within the Application's name is sufficient to tell the two apart.
CGI
US
PEDEL, Thanks a lot for the help. I clearly understand now and I'm back on track. Sounds like a familiar concept after you giving me the example. :)
So, I think to use separate DB for the specialized app, we'll have to save the updated Data-Admin-DB-Table mapping(for the workpool class) into the specialized ruleset.
Pegasystems Inc.
US
If you use Ruleset Specialization, the workpool class and work table mappings are decided by the locked-down, built-on application. There is no need to change Data-Admin-DB-Table mappings when each specialized application is deployed to a different database. You cannot deploy two Ruleset specialized applications to the same database since the workpool class is the same for both apps; the Data-Admin-DB-Table mapping would translate to the same work table.