Designing an email application
Archived
2 Tasks
10 mins
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:
- Spun-off Email process defined by a (pyMode=Component) component
- Advanced Agent-processed Email data instances
- 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