Skip to main content

Designing an email application

Archived

2 Tasks

10 mins

Visible to: All users
Advanced
English
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.

Scenario

Front Stage employees need to be able to generate, and if necessary edit, emails that can be automatically or manually sent at a future date. It should be possible to incorporate this capability into present and future applications generated for Front Stage.

Produce a design document for a solution that satisfies Front Stage's requirements for delayed email editing and sending capabilities. The design document should describe the thought process and include at least three (3) viable alternative solutions, a comparison of the Pros and Cons of each, and the recommended solution.

Detailed Tasks

1 Possible approaches

Three approaches are possible for this solution:

  1. Spun-off Email process defined by a (pyMode=Component) component
  2. Advanced Agent-processed Email data instances
  3. Spun-off Email subcase defined by a (pyMode=Application) component application

Spun-off Email process Component

The functionality needed to send emails at a scheduled time could be defined in a process included in a (pyMode=Component) component. Case types would reference this process within their Life Cycle. The Component-defined process would spin-off a second process. The spun-off process would contain an assignment with an SLA. The SLA would react to a datetime property defined by the Component, one that any case type would inherit.

Pros

  • Simple design - easy to implement

Cons

  • Editing the email requires locking the case
  • Specialization options limited

Job Scheduler-processed Email data instances

The Data-Corr-Email class would be extended to include scheduling information. Instances of that class would be stored separately. Users would be able to open instances that are related to cases to which they have access, A Job Scheduler would periodically query these Data instances looking for those where the time-to-send is in the past, but the email has not been sent. When the Job Scheduler successfully sends the email it updates the Data instance to flag it as having been sent.

Pros

  • Locking is independent of the case that created each instance

Cons

  • More difficult to manage

Email subcase component application

Create a (pyMode=Application) component application with a single Email case which is always spun off as a subcase. Data propagation would be used to tell the Email case when to send an email. The Email case would assume that its cover's most recently attached Data-Corr-Email instance, prior to it being spun off contains the email’s information. The case would support a UI to allow the email to be edited prior to it being sent.

Pros

  • Subcase can be configured as Do not lock parent or inherit Optimistic locking from its parent
  • Has its own life cycle, data model, settings, and views
  • Simplified reporting and security
  • Could be configured to be self testable on its own

Cons

  • If an event is canceled, email subcases need to be withdrawn
  • More complex to implement

2 Recommended design approach

The Email subcase component application option is preferred because it:

  • Fully satisfies the requirements
  • More configurable
  • Simplifies testing


Available in the following mission:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice