Enterprise Class Structure
Hi Team,
In the below question the answer is given as B, but i guess 5 rules should be sufficient as there are 5 Divisions . Please provide what is the need to include in this class "MyCo-FW-LoanApp-Work".
Pegasystems Inc.
US
Hello Mohan,
This KC question is good because it gets people thinking.
The correct answer is 6. Because things can change in the future and we build for change. For instance when there will be a general GetRating in the future, you can implement this at the ....-Work and all divisions who will use this general version can just inherit it. It will not be needed to implement the same GetRating for those divisions.
Tara, Pega Academy Support Team
Agora-Group
US
I disagree with POTTT...Also 'build for change' has no relevancy here..Question itself is little context sensitive (from the point of view of the person who framed it). Hopefully such questions can be marked as non-standard to test someone's understanding from Pega Academy Quiz as well as Certification Exams.
Pegasystems Inc.
US
GovardhanReddy-
This question brings together concepts covered in several lessons, such as the alignment of rulesets to application layers, as well as the behavior of blocked and withdrawn rules. It's this implicit understanding of these other concepts that yields a best practice of 6, rather than 5.
In fact, the principle behind this question, and the one prior to it on the quiz, is the same.
Consider a situation where the GetRating rule for DivA needs to be removed from the application. The best practice is to create a higher version of the ruleset that contains the targeted version of GetRating, and then save to this ruleset a version of GetRating with the availability set to "Withdrawn". This prevents the application from calling the previously defined GetRating rule for DivA.
The problem then becomes what version to call. If GetRating is not defined in a class further down the inheritance tree, the system can't call any copy of GetRating, and the application returns an error. To get around this issue, a copy of GetRating should be defined in the framework layer.
GovardhanReddy-
This question brings together concepts covered in several lessons, such as the alignment of rulesets to application layers, as well as the behavior of blocked and withdrawn rules. It's this implicit understanding of these other concepts that yields a best practice of 6, rather than 5.
In fact, the principle behind this question, and the one prior to it on the quiz, is the same.
Consider a situation where the GetRating rule for DivA needs to be removed from the application. The best practice is to create a higher version of the ruleset that contains the targeted version of GetRating, and then save to this ruleset a version of GetRating with the availability set to "Withdrawn". This prevents the application from calling the previously defined GetRating rule for DivA.
The problem then becomes what version to call. If GetRating is not defined in a class further down the inheritance tree, the system can't call any copy of GetRating, and the application returns an error. To get around this issue, a copy of GetRating should be defined in the framework layer.
This type of preparation would also provide a benefit should the company decide to create divisions DivF, DivG, and DivH. If these divisions do not require a customized variant of GetRating, the best practice is to have each division "fall back" to a base version in the framework. This allows an application developer to alter one rule - the framwork instance of GetRating - and have the change take effect immediately in DivF, DivG, and DivH (and any other division which did not require a division-specific version of GetRating).
The previous question on the quiz asks:
Consider the following scenario: Organization: MyCo Five Divisions: DivA, DivB, DivC, DivD, DivE Framework: LoanAppFW The LoanAppFW contains an “IsApproved” rule, that directly calls the “GetRating” rule. The requirements for GetRating are the same for DivA – DivD, but different for DivE. All work types use these rules. In a best-practice design, how many GetRating rules are there? (Choose One)
In this case, the correct answer is:
- Two, in: MyCo-FW-LoanApp-Work, MyCo-DivE-LoanAppDivE-Work
For DivA, DivB, DivC, and DivD, the appliction cannot call a division-specific version in the appropriate division ruleset, because those versions of GetRating would not have been defined. As a result, the system "falls back" to the version in the framework layer, at MyCo-FW-LoanApp-Work.
Agora-Group
US
Pegasystems Inc.
US
This is a question on enterprise class structure, so the question is strictly testing the framework vs. implementation. Putting build for change aside, you definitely need this to be defined in MyCo-FW-LoanApp-Work because the GetRating is referenced by a rule defined in the framework layer. The five rules that you define on division classes are part of implementation layer, so when you are creating an IsApproved Rule in the framework layer it REQUIRES GetRating in the framework layer for compilation since the framework is a separate application and does not require any implementation for all rules to work.
Agora-Group
US
That's well explained and sounds promising on why the rule should exist in FW layer. Thanks Ram. Catchy thing here is 'IsApproved' rule of FW layer directly calling 'GetRating' rule. If 'GetRating' rule doesn't exist, (assuming this LoanAppFW is built directly on PRPC; not on another FW which contains a rule instance named 'GetRating' and OOTB PRPC also doesn't have one) there is no way PRPC would allow creation of 'IsApproved' rule.
N/A
NL
Hey All,
By now this topic is pretty cold, tho perhaps like me, others will think about this question and topic again...
The first question with the 5 divisions with specific requirements for the "GetRating" rule having the answer of implementing 6 versions of "GetRating" got me thinking.
At the time of the scenario pointed out in the question, what implementation/functionality could possibly be put in the framework FW version of the "GetRating" rule?
From technical point of view i think i follow the discussion and arguments and the idea of a 'fallback' in the framework layer and the fact that "IsApproved" exists in FW class depending on a "GetRating". So ideally at any time u'd want a "GetRating" available when "IsApproved" is called, to prevent errors.
Though if there are only 5 divisions at this time and there are no shared requirements for "GetRating". Then is there a meaningful implementation in the FW class possible?
The idea of fallback in this context seems to me like creating a 'dummy' or a stub function, which in my view could cause potential unexpected behavior.
Should in the future "IsAppoved" be called in scope of one of the 5 currently existing divisions and at runtime the FW version of "GetRating" is selected.
What should it do/return?
Ok, perhaps "GetRating" in FW layer could be implemented to cause a 'Graceful crash' displaying a meaningful message, but that doesn't sound right to me.
Hey All,
By now this topic is pretty cold, tho perhaps like me, others will think about this question and topic again...
The first question with the 5 divisions with specific requirements for the "GetRating" rule having the answer of implementing 6 versions of "GetRating" got me thinking.
At the time of the scenario pointed out in the question, what implementation/functionality could possibly be put in the framework FW version of the "GetRating" rule?
From technical point of view i think i follow the discussion and arguments and the idea of a 'fallback' in the framework layer and the fact that "IsApproved" exists in FW class depending on a "GetRating". So ideally at any time u'd want a "GetRating" available when "IsApproved" is called, to prevent errors.
Though if there are only 5 divisions at this time and there are no shared requirements for "GetRating". Then is there a meaningful implementation in the FW class possible?
The idea of fallback in this context seems to me like creating a 'dummy' or a stub function, which in my view could cause potential unexpected behavior.
Should in the future "IsAppoved" be called in scope of one of the 5 currently existing divisions and at runtime the FW version of "GetRating" is selected.
What should it do/return?
Ok, perhaps "GetRating" in FW layer could be implemented to cause a 'Graceful crash' displaying a meaningful message, but that doesn't sound right to me.
Regarding the "Build for Change" argument. Isn't it enough that there is the flexibility of having the FW class in the first place?
How i see it, should there be requirements that allow a shared implementation of "GetRating" in the future, then at that time a "GetRating" rule could be created in the FW class so that it can be reused for any/all of the divisions.
Perhaps i don't grasp the 'Build for Change' philosophy yet, tho building rules without meaning or without valid scope seems to me to be harmful to reusability and clarity. In that way actually harming "Build for Change"...
Perhaps this is the gray area we all face when designing a system where insights and preferences vary per person..
What are your thoughts on this?
Updated: 12 May 2016 16:46 EDT
SiXworks Limited
GB
Hi,
Unless I've missed something, this is less about best practice and more about getting rules to save at design-time.
If you have a rule sitting in the Framework application, it is not able to call rules in the Implementation Layer at design time - This is because we are governed by the "Required Rulesets and Versions" in the Ruleset Version rule form.
What this means is that if you try to add the "GetRating" rule into "IsApproved" , Pega 7 will only allow it to save if there is a version of "GetRating" in the FW layer (a stub, as you rightly point out). At run-time, the correct divisional rule will be picked up and run.
What I'd suggest is trying it for yourself (ensuring the calling rule is in the FW, and the called rule is in the Imp. Layer), as it should clear up any ambiguity.
In terms of how much detail is in the rule at the FW layer, I imagine it is very dependent on your particular situation. If you are unlikely to ever actually run that version of the rule, then it could be left as a stub. It would, however, be useful to have a functional rule in the scenario of an implementation not using any division.
I hope this was useful,
Ben