Details
-
New Feature
-
Status: Closed (View Workflow)
-
P2
-
Resolution: Done
-
None
-
None
-
-
XXL < 30 days
-
Vega
-
-
100
-
Already in progress, and how emails are incrementally sent will affect the bundling of multiple items in a single notice too.
-
R1
-
R1
-
R1
-
R1
-
R1
-
R4
-
R1
-
R1
-
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.
TestRail: Results
Attachments
Issue Links
- relates to
-
CIRC-407 Sending patron loan notices, make number of emails to be processed in a given timeframe configurable
-
- Closed
-
-
MODSENDER-12 Performance testing - time-based patron loan notices (one item)
-
- Closed
-
-
CIRC-370 Process non real-time patron notices
-
- Closed
-
-
MODSENDER-8 [SPIKE] Investigate sending multiple messages at the same time.
-
- Closed
-
- requires
-
FOLIO-2153 Create separate environment for Team Vega performance/load testing of sending patron notice emails
-
- Closed
-
-
MODSENDER-10 [SPIKE] Learn JMETER and how to write/run performance tests
-
- Closed
-