Discussion
Pegasystems Inc.
US
Last activity: 7 Apr 2020 22:57 EDT
7.3 / 7.4 CLSA Architecture Application Build Exam - Retired Exam Question 3
The CLSA Architecture Application Build exam consists of 3 to 6 questions of varying complexity which evaluates the ability of a candidate to develop and architect solutions using the PEGA platform. Please refer to the Exam preparation guide for further details.
Question 3 from a retired exam scenario is attached to this post. You are encouraged to work through this question by collaborating in this discussion thread. A solution will not be provided.
It is estimated that a candidate proficient in design and implementation would be able to complete this task in 6 hours.
The starting point migration file for this first retired exam is called Booking_20171102_10000.zip and can be downloaded here
Areteans
AU
Has anyone tired this?
My solution is,
Creating your own WBCheckin with another name since it is final, and save as PostActionCheckIn in FSG ruleset and Called my customerized WBCheckin activity from that.
In my WBCheckIn Activty, i'm checking relevant logic and call Approval process.
Morgan Stanley
IN
Hi,
Is it recommended to have the rules being used in approval process be part of a new ruleset so that i could be used in any application if required just by adding this ruleset.
or should we place the integration rules in FSGInt ruleset and data rules in FSG so that they are available by default for all apps.
Updated: 7 Sep 2019 5:40 EDT
ING Bank N.V.
NL
Has anyone tried solving this recently ?
I was trying it out, and following are my observations:
(1) Instead of customising the rule approval changes I wrote a wrapper Flow which would then invoke the OOTB RuleApprovalChanges flow :the invocation is conditional upon the rule being a decision table and a PEGA Unit Test passing.
(2)To simulate PEGA Unit Test I used the below expression:
@pzRound(@random(0.9,0.1),1)>=0.5
This function generates a number between .1 and .9 randomly and checks whether the generated value is more than .5 or not. This would give a random True/False answer, and will simulate Pega Unit Test case result.
(3) I am facing a problem when trying to bypass the approval process for rules which are not decision tables, and for Decision tables which have failed the Pega Unit Test: it seems no case/assignment is being generated, and the rule remains locked for sometime, after which I can release lock and work on the rule again. I tried unlocking the case by using Work-.UnlockWork activity, but it does not seem to have worked.
Has anyone tried solving this recently ?
I was trying it out, and following are my observations:
(1) Instead of customising the rule approval changes I wrote a wrapper Flow which would then invoke the OOTB RuleApprovalChanges flow :the invocation is conditional upon the rule being a decision table and a PEGA Unit Test passing.
(2)To simulate PEGA Unit Test I used the below expression:
@pzRound(@random(0.9,0.1),1)>=0.5
This function generates a number between .1 and .9 randomly and checks whether the generated value is more than .5 or not. This would give a random True/False answer, and will simulate Pega Unit Test case result.
(3) I am facing a problem when trying to bypass the approval process for rules which are not decision tables, and for Decision tables which have failed the Pega Unit Test: it seems no case/assignment is being generated, and the rule remains locked for sometime, after which I can release lock and work on the rule again. I tried unlocking the case by using Work-.UnlockWork activity, but it does not seem to have worked.
Is there something which I am missing here ?
Pegasystems Inc.
IT
Hello All,
I am practicing to the Question #3. My approach was to extend the existing OOTB process to a new version of the Booking application.
There were no requirements of extensibility but best approach is to made a component application so the new Check In approval logic can be shared by other teams and projects.
Regarding the implementation.
- I modified ApprovalChanges flow adding the logic to check for Decision Table rules for automatic approval depending on result of the Test Suites.
- I have implemented a REST connector to call the pzExecuteTest REST API and simulated with a random function (similar to the one proposed in previous posts) that decide if the tests were successful or not
- I have used the "auto process" option on the Evaluate Assignment of Approval Changes flow (see attachment) to to automatically submit the Approve flow action if result of tests were positive, otherwise the approval remain manual.
- In this approach i have found an issue: when there is automatic approval the rules that are parked in RS CheckInCandidates before approval (used the OOTB configuration), are not deleted, even if the rules are automatically checked in related ruleset. To solve i need to delete the rule in this RS manually.
In terms of extension I see a possible use of the feature in a Dev Ops pipeline to automate and control check in of rules in a multi team shared master development environment.
Hello All,
I am practicing to the Question #3. My approach was to extend the existing OOTB process to a new version of the Booking application.
There were no requirements of extensibility but best approach is to made a component application so the new Check In approval logic can be shared by other teams and projects.
Regarding the implementation.
- I modified ApprovalChanges flow adding the logic to check for Decision Table rules for automatic approval depending on result of the Test Suites.
- I have implemented a REST connector to call the pzExecuteTest REST API and simulated with a random function (similar to the one proposed in previous posts) that decide if the tests were successful or not
- I have used the "auto process" option on the Evaluate Assignment of Approval Changes flow (see attachment) to to automatically submit the Approve flow action if result of tests were positive, otherwise the approval remain manual.
- In this approach i have found an issue: when there is automatic approval the rules that are parked in RS CheckInCandidates before approval (used the OOTB configuration), are not deleted, even if the rules are automatically checked in related ruleset. To solve i need to delete the rule in this RS manually.
In terms of extension I see a possible use of the feature in a Dev Ops pipeline to automate and control check in of rules in a multi team shared master development environment.
Regards,
Eliseo Olla
LTIMindtree
DE
Here, rather than to 'Create a REST connector to connect to “pzExecuteTestSuite” REST Service which runs the test suite' can't we directly call OOTB activity pxRunTestSuite to execute test suite ?
Ernst & Young LLP
IN
Hi Keshav,
I am also experiencing the same. It will be helpful if someone can provide a solution. I need to look into the questions.
Thanks,
C.Shivakumaaran