Designing an email application
3 Tasks
20 mins
Scenario
Front Stage needs to schedule the sending of automatically generated emails at a specific date and time in the future. When generating emails using this feature, FSG employees need to edit the content of the email. At any time before the email is scheduled to send, Front Stage employees must be able to easily edit the contents of the email, cancel it, or send it manually. If the email is not canceled or sent manually ahead of schedule, the system needs to send the email automatically at the scheduled date and time. It must be possible to incorporate this automatic email generation, scheduling, and editing capability into any present and future applications built for Front Stage.
Produce a design document for a solution that satisfies Front Stage's requirements for the automatic email generation, scheduling, and editing functionality. The design document describes the thought process used to arrive at the recommended approach and includes at least three viable alternative design options, a comparison of the Pros and Cons of each of the approaches considered, and an explanation as to why the recommended approach is preferred.
Detailed Tasks
1 Identify design options
There are at least three possible approaches for a solution:
- Spun-off email process (flow) that is part of a Pega Component (pyMode=Component) component
- Job scheduler-processed email data instances
- Spun-off email subcase defined by a (pyMode=Application) modular built-on application
Spun-off email process component
The functionality that needs to send emails at a scheduled time can be defined in a process that is included in a (pyMode=Component) component. Case types reference this process within their life cycle. The component-defined process spins-off a second process. The spun-off process contains an assignment with a service-level agreement (SLA). The SLA reacts to a DateTime property defined by the component, one that any case type inherits.
Job scheduler-processed email data instances
The Data-Corr-Email class is extended to include scheduling information. Instances of that class are stored separately. Users can open email instances that are related to cases to which they have access. A job scheduler periodically queries these data instances to look for emails where the time-to-send is in the past, but the email has not been sent. When the job scheduler successfully sends the email, the job scheduler updates the data instance to flag the message as having been sent.
Email subcase component application
Create a (pyMode=Application) component application with a single email case that is always created as a child case. Data propagation is used to tell the Email child case when to send an email. The Email child case assumes that the parent case's most recently attached Data-Corr-Email instance contains the information about the email to be sent. The email child case supports a UI to allow email editing before the message is sent.
2 Evaluate design options
Design | Pros | Cons |
---|---|---|
Spun-off email process |
|
|
Job scheduler-processed email data instances |
|
|
Email subcase component application |
|
|
3 Recommend the best solution
The email subcase modular built-on application option is preferred because it:
- Fully satisfies the requirements
- Is more configurable
- Simplifies testing
Available in the following mission:
Want to help us improve this content?