Identifying and evaluating design options
4 Tasks
30 mins
Scenario
This challenge aims to demonstrate the thought process of identifying and evaluating design options and then recommending a solution.
REST connector calls must be run to retrieve reference data from a legacy system. The data must be refreshed once a week (for example, on Sundays), provided that the data can be cached for that duration until refreshed again. The REST connector calls are quite long. As a result, the number of REST connector calls that you make should be minimized. An example of where the data is needed is for display in an autocomplete control. The environment is a cluster of Web Tier and Background Processing nodes.
Identify and compare the design options for a possible solution.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks.
Role | User name | Password |
---|---|---|
Admin | admin@deliveryservice | rules |
Detailed Tasks
1 Identify the design options
The solution has at least two design options, as described below:
Option 1: Data Page with REST Connector source
- The auto-complete control sources a node-level Data Page that, in turn, sources a REST connector.
- The node-level Data Page refreshes once every week.
Option 2: Data Page with Live Data Source
- A Job Scheduler runs the REST connector calls and persists the retrieved data in a local table.
- The auto-complete control sources a node-level data page that, in turn, sources a Report Definition that queries the locally persisted data.
- The node-level data page can refresh often (such as once per day), because its data queries are local.
- The Job Scheduler is configured to run once every week on a single node.
2 Evaluate design options
Option 1 works and is simple to implement. Option 2 also works but is more complex to implement.
Option 1 requires that each WebTier node updates itself by calling the very slow REST connector, which might cause an unpleasant user experience on the initial load. However, with Option 2, the very slow REST connector is only called once, and runs on a background processing node. Option 2 WebTier users never see this initial delay because the WebTier node that their browser talks to has a node-level DP that has queried fast-to-load local live data.
These two design options provide a trade-off between time to implement and maintain, and improved user experience. The recommended option depends on which factors are more important. Option 1 may be acceptable and more desirable because of its simplicity. Option 2 guarantees an improved initial user experience, which may be preferable.
3 Identify additional design options
Option 3:
Option 3 is similar to Option 1, but makes use of the Load data page method to request the data page load asynchronously at some point earlier in the process. This gives sufficient time for complete loading before the data is needed. At worst, this happens on Login. Preemptive loading can be accomplished by using a smart shape, or similar.
This option provides the following results:
• A kind of background processing (uses a background requestor).
• Optimal memory management (just as many node-scoped data pages as Option 1).
• No need to persist the remote data in the Pega application.
• Makes one trip to the remote data store for each node; Option 2 makes one trip for each cluster.
Option 4:
A variant of Option 2, but runs the Job Scheduler on all nodes to have it automatically trigger loading the node-scoped data page at the same time every week for each node (perhaps after flushing any data page that is still deemed fresh, which can be performed with an activity).
This option provides the following results:
• Requires the same number of remote trips as Option 1.
• Removes the need to persist a local copy.
• Provides the same user experience as Option 2 (assuming that the data pages are loaded before a user needs the data).
For Options 3 and 4, the wished-for design for a solution is a trade-off between time to implement and maintain, with little difference in user experience between the two options, because the initial loading problem is solved. Other contributing factors that might weigh into the evaluation are potential rule reuse and future evolution of the application.
4 Review summary
Lead System Architects on any platform should be able to formulate options, identify strengths and weaknesses, and then make justifiable recommendations based on criteria such as:
• Effort (cost)
• Complexity (which indirectly affects effort and maintenance)
• Maintenance
• Resource management (memory/database)
• User experience/responsiveness
For this example, it is expected that candidates should identify Options 1 and 2 at a minimum. Options 3 and 4 are ideally still considered by the candidate, under the caveat of, “These are also possible design approaches, but further research should be performed to demonstrate the ease of implementing them with Pega Platform™." Identifying and evaluating all possible options demonstrates a preferred level of analysis that should always be performed by PCLSAs, as opposed to “jumping in” to implement a solution just because it works, without carefully considering the long-term consequences of all available options.
Recommended reading: Alan's chess thought process.
Confirm your work
Available in the following mission:
Want to help us improve this content?