Patron Notices (UXPROD-18)

[UXPROD-1797] Process patron notice emails in bulk for non real-time notices Created: 24/Jun/19  Updated: 16/Sep/20  Resolved: 06/Oct/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2019
Parent: Patron Notices

Type: New Feature Priority: P2
Reporter: Darcy Branchini Assignee: Darcy Branchini
Resolution: Done Votes: 0
Labels: cap-mvp, po-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to CIRC-407 Sending patron loan notices, make num... Closed
relates to MODSENDER-12 Performance testing - time-based patr... Closed
relates to CIRC-370 Process non real-time patron notices Closed
relates to MODSENDER-8 [SPIKE] Investigate sending multiple ... Closed
Requires
requires MODSENDER-10 [SPIKE] Learn JMETER and how to write... Closed
requires FOLIO-2153 Create separate environment for Team ... Closed
Epic Link: Patron Notices
Back End Estimate: XXL < 30 days
Back End Estimator: Kostyantyn Khodarev
Development Team: Vega
PO Rank: 100
PO Ranking Note: Already in progress, and how emails are incrementally sent will affect the bundling of multiple items in a single notice too.
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R4
Rank: Lehigh (MVP Summer 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Adding this feature (6/24/2019) because there wasn't a feature to represent it, yet work has already begun.

Purpose:
To create patron notice processor to process and send non real-time notices within system idle time, which will vary from institution to institution, but commonly between 1 am and 7 am. (TBD, start time and end time should be configured in mod-configuration)

Description:

  • There are three types of notices in FOLIO: user-initiated, time-based and a change in status.
  • Time-based notices could be real-time (higher priority, minimum delay to process and send) or non real-time and sent in batch or bulk. Batch emails are not lower priority, however, it is not important that they are sent immediately when a triggering event happens. As long as the entire batch scheduled for a particular night are all sent, it would be considered successful.
  • This story is about non real-time notices only.
  • Main idea is to process portions of non real-time notices within idle time (at night).
  • Processor is the same as for real-time messages, the only difference is run interval and predefined "idle window" for notice processing.
  • Performance testing is a must.

Context:
Libraries frequently have tens of thousands, and at peak times hundreds of thousands of notices to send out in bulk. For example, a library may have a fixed due date of the last day of the semester, and they plan to send courtesy reminder notices 5 days before the due date, and again 3 days and 1 day before the due date. Presumably with each notice sent, there's some attrition, because in theory, the first notice encourages some patrons to return their items, and the second notice encourages more patrons to return their item, etc.

It is not ideal to send these notices during the middle of the day when the ILS is assumed to be in heavier use. Administrators are accustomed to scheduling batch or bulk email notices in their current systems in order to maximize/utilize times when the system is not as heavily used, typically from 12 am - 8 am or 1 am - 7 am. Heavier use is typically seen during library open hours. When scheduling, administrators need to consider system resources as well as other batch processes that are also scheduled. Most batch processes are pre-scheduled and routine, such as an email batch scheduled for every evening at 2 am or a user import process that happens once a semester.



 Comments   
Comment by Darcy Branchini [ 02/Jul/19 ]

Based on the notes taken at the RA SIG meeting on 7/1/2019, I changed the status to "go-live" for Cornell, TAMU, Chicago and Lehigh.

Generated at Fri Feb 09 00:18:36 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.