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 2 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 3 hours.
In response to your first question, the guide states "The exam requires several solutions to be created from this starting point ...." This indicates that not ALL questions will be built on the exam starting point. For example, retired exam question 1 is a standalone application.
Please note: The exam starting point is similar to, but not exactly the same as the application given in the CLSA 7.3/7.4 course.
In response to your second question, Yes - this is one of 6 questions which are included in that exam scenario. The first question has also been posted in this group. There are different exam scenarios, and each scenario consist of 3 to 6 questions.
The core of the change is in coordinatorreview_flow (see attached screen). New cases will end up in manager acknowledgement assignment where the assignee will be able to view and accept the event (it's not possible to reject anymore).
Push routing, instead of the previous pull/push hybrid, needs to be implemented. The fastest way to accomplish this is to leverage "ToLeveledGroup" OOTB routing activity that takes into consideration the load of every user. Sadly there is one major issue: the activity works by selecting users from a workgroup. In our application ALL users are mapped to the same workgroup (which is a bit strange). That means that this activity will potentialy route cases to Hotel Managers for example (which is clearly wrong). One solution would be to set a separate workgroup for event manager but workgroup selection should not be carried out on a implementation need but on a organization need. It actually would make a lot of sense to talk to business stakeholders in order to set up proper workgroup but we can't assume it will be done. So in the end, for this exercise, i would opt for a custom routing activity
The other major aspect is how to manage in flight cases. Since i modified the flow without deleting any shape no case will get corrupted if opened. I've set up an activity that runs a report in order to find all in flight cases in Pending-Assignment status. A ticket is then thrown in order to move each one in the new assignment.
Since we have a 4 hour downtime window it's quite plausible to assume that the sysadmin will have plenty of time to install and update all the in flight cases
I have two questions about your approach, only to clarify:
- I don't understand why create new work group for Event Managers is not an option. It makes sense create a work group for people that manage similar work, and this is not a conflict with an organization need or not.
- About how to manage in flight cases, I don't understand why you need old shapes if you run the activity after deployment to move each one in the assignment. For me it looks like extra effort, but propbably I'm missing something. Based on the CLSA course (HANDLING FLOW CHANGES FOR CASES IN FLIGHT), there are 3 differents approaches to solve this scenario that works one indepently of each other. You're using both approach 2 and 3, but only Approach 3 is required based on my understanding.
I'm facing some issues with the ToLeveledGroup routing.
Below is what i have done:
1. Created a new workgroup EventManagers@FSG.. Added EventManager1 as Manager and Default workbasket as Booking:EventManager
2. Assigned it to all the operators EventManager1, EventManager2 and EventManager3
3. Updated the workqueue Booking:EventManager to point to the new work group and Unit Managers.
When i use the ToLeveledGroup all the event assignments are assigned to EventManager1. None of the cases are getting assigned to EventManager2 or EventManager3.
From tracing i get that the first step of ToLeveledGroup (@pickBalancedOperator(Param.workgroup, Primary, myStepPage, null, 0, 100, 10, tools)) is not returning any thing and hence the assignments are routed to the workgroup manager (EventManager1) in my case.
In audit i have found the below message:
This assignment has been reassigned to Operator EventManager1.Booking, as EventManager3.Booking is unavailable.
However, in the operator the available for work is selected.
Can anyone provide shed some light on how to debug this?
You also have a third option. You can update the process in a high version of your application. Then you will have both old and new version of your application running in production at the same time. I don't like so much this option because require swith application to manage the inflight old version processes. This approach also require extra effort to avoid that operators create new cases in the old version applications for example.
According to me Third option is the best one reason is
Number of assignments is small
downtime 4 hour is there so no actual impact to users if we do bulk processing.
Users when start working next day there is no confusion of version 1/version 2 of assignment process.
The second approach sounds good as well but the disadvantages will be
When user process inflight assignment it will led to a confusion, as the event manager assigned in the previous assignment might not be the one to whom in new version of flow assigns . (ToLevelledWorkGroup might find another appropriate eventmanager).
We can put a fork to check if .EventManger already exist then same assignment with toOperator router can be used.
My Question related to PRPC software version for CLSA exam. App Prep clinic video, the instructor has given a link to download 7.3 version but looks like package is corrupted. so, instead of V7.3 can we use 7.4 PE. Any help is appreciated.
Ultimate goal is to process in-flight cases and make sure that new work object assignments will work as expected as well.
In my opinion, approach 3 alone will not work. It will have to be combination of approach 2 (modify flow while keeping old assignments and adding new assignment for acknowledging event with "ToLevelledWorkGroup" router and connecting start shape with new assignment) and approach 3 (run a utility with ticket). New assignment "Acknowledge Event Assignment" will have ticket associated with it.
Downside of using Approach 3 alone is that it means we will be deleting 2 flow shapes "Manager Assignment" and "Accept Assignments" which are not needed anymore. If we try to run any utility after that, it gives error saying that assignments/flow is not found.
If someone has alternate approach,would like to know.
The best way also has to be the most reliable way. If you run an activity in batch mode, it has to be fullytested. After all, it is operating on production cases. The activity may be more complex than just restart/change stage or set ticket, it could also involve updating the case and perhaps a subcase as well.
Your activity may work perfectly against a single case making you feel confident that it works but when used against numerous cases back-to-back something goes wrong. You could end up doing a lot of "damage" fast. A PegaDATA schema backup prior to attempting the activity would be wise. Things that could go wrong might include declaratives not firing, or data not committing as expected (link-attachments say).
Perhaps investigate if there is a way that these cases could "fix themselves" the next time a human operator attempts to work on the case. That way there is someone looking at the case and the action taken to "upgrade" the case is interactive, meaning rules that fire per-interaction such as Data Pages work as expected.
Have to question the use of the batch job approach unless the activity that is run is simplistic. "What is the rush?" in other words. If a case has yet to be converted to the future state, i.e., the state the newly created cases would start out in, what harm does that "behind the times" case do?
Reporting could be affected, especially assignment reports. What is wrong with those reports taking into account the old and the new? Hard to come up with an example where Security could be an issue. There are multiple ways to enforce assignment and case Security.
@pedel I agree the idea of correcting the cases on next access rather than a potential issue that we uncover later after corrupting lots of production data. However when requirement states "All currently open Event Booking Assignmentspending Event Manager Assignment and/or acceptance must be automatically assigned toEvent Managers as described above.", it puts me into confusion state that if we have that choice to make or requirement is firm. From requirement, it looks like these cases pending assignment won't be accessed by anyone other than one chosen by system based on workload automatically behind the scenes. This calls for need of an batch activity/agent. If not, what would be trigger point for assignment in that case?
If all that needs to be done is to restart the flow, a flow action can be added to every "deprecated" assignment, that flow action leading back to the start shape. This is a combination of Approach 2: Process existing assignments in parallel with the new flow and Approach 3: Move existing assignments. An agent can call ResumeFlow naming the new flow action. Messy from the Case Designer's point of view but gets the job done.
Of course SetTicket would work as well. In either case Flow rules are used, here the changes are very simple.
On my wish list is that there would be a way to record multiple steps similar to Scenario Testing while allowing certain data to be changed. For example when someone reschedules an exam, there is more to do than just change the start date. For example a new Confirmation email needs to be sent and the EMAIL subcase that delivers the exam, according to the new start date, needs to be refreshed. This is very challenging to do programmatically. Plus having two different ways to do the same thing can be a maintenance concern. Recorded scenarios though can become stale, the same as when using robotics and the interface they were defined against has changed.
Can you please clarify my doubts here regarding the inflight cases handling.
Handling by adding a migration activity for Pending-Assignment cases and routing them to the desired assignment by adding a ticket or by initiating Change Stage in the Co-ordinator Review flow is simple.
But if we prefer users to interactively handle the inflight assignments-
1. From Manager Assignment step-(where user chooses the routing to desired event managers) -Its easy to put a flow action and route them to start the flow by adding some custom message to handle the same and freezing the current available flow actions
2. From Approval flow-where Event manager choose to accept or reject, how can we force them to handle by launching some action as pyApprovalFlow(note-this is in UIKit RS)
Security would be defining a Privilege such that only an Administrator would be allowed to execute the Batch Activity. It should not be hackable, e.g., ?pyActivity=.
This sounds scary: Delete existing assignments and restart stage.
Assignments are deleted automatically during FinishAssignment. You can configure pxChangeStage to remove the original assignment.
In an exam you would not need to include as many screenshots and explain what the process currently is in detail. You could summarize. The focus should be on analyzing alternatives and choosing the best one.
I am stuck at the part of the requirement that said 'least amount of urgent work'. Urgent work could be defined as urgency >40 (or another number) or only assignments beyond their goal time, or simply we might look at sum of urgency of all assignments with an operator.
What are we expected to do if we have a question of this kind during the exam? Should we seek clarification (which might result in lost time) or are we allowed to make an assumption, document it and continue with our approach?
Your first instinct should be to ask the customer if they would be satisfied using an OOTB, supported, routing activity rather than devoting time and resources toward the development of a custom routing activity, plus the time and effort to test (and test and..) plus increasing the total maintenance burden of the application.
Part of what the App Build exam tests is your ability to "see the Big Picture". If clarification was asked during the exam we would likely respond saying "that is your decision as a potential LSA".
I have tried to document the design and implemented the same based on the design. This worked as per requirement. Attached the design document. Would you kindly review and let me know the areas can be improve to answer this question or any suggestion.
That would be great help!
I am not attaching this export, please let me know, if this can be attach for review also.
Third option can be improvised by executing an activity to pull old cases and invoke pxRestartStage OOTB activity on these cases, so that it restarts on the corresponding stage and does not require to update the flow.
Please let me know if any one has comments on this approach pros and cons.
In this example restart stage works since the stage consists of a single flow and there would be little difference between before as far as what assignment the user should see when re-launching the case.
If, however, the stage is lengthy and would require numerous clicks to advance the case back to where it was originally, what then? An upstream Ticket within the Flow would be a better option.
Question: Is it allowable for the flow to run its course as originally designed or is there a requirement mandating that every assignment with the flow absolutely must "reverse course" as soon as possible and start over?
A smooth transition from one state to the next, not dramatically impacting end-user productivity, would the ideal if allowed.
Exactly my consideration. Given it is only a single flow in the stage, both ticket and restarting stage would give the same result. But in terms of scoring this question, will suggesting adding a ticket in the flow that is only used ONCE affect the score? Should suggesting removing the ticket in succeeding releases have any effect in score addition/deduction?
Also If I were to give a scenario that a parallel development might be happening that could change the number of flows in the stage and I will recommend to use a ticket which limits the impact within the flow itself, will I get extra credit?
Did anyone faced this error in "Assignment" stage ? just imported "LSA-AppBuildStart-73-20181021" and was examining "assignment" stage . No change is done , all RSV are locked as provide in build start.