[UXPROD-4332] Reimplementation of Bursar Scheduling to use Quartz Created: 01/Jun/23  Updated: 30/Nov/23  Resolved: 27/Jun/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Poppy (R2 2023)

Type: New Feature Priority: P3
Reporter: Irina Pokhylets Assignee: Tim Auger
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PDF File GSE-UXPROD-3944 NFR Scorecard-120523-134424.pdf    
Issue links:
Defines
defines MODEXPS-213 Reimplementation of Bursar Scheduling... Closed
defines MODEXPW-411 Investigate Bursar and Quartz job sch... Closed
defines MODEXPS-214 Bursar Quartz scheduling testing - re... Closed
defines MODEXPS-221 Deletion Of Old Jobs from Job Table Closed
defines MODEXPS-222 Bursar Quartz regression testing Closed
Release: Poppy (R2 2023)
Development Team: Volaris
PO Rank: 0

 Description   

Current situation or problem:

Currently scheduling configuration stored in memory and module can work only with 1 instance. It causes different issues with scaling, restarting modules, storing scheduling configs in memory, etc.

After feature implementation scheduling configuration will be stored in Quartz internal tables, can be scaled, and will fully satisfy stateless principles and other NFRs (see attachment).

In scope

  1. Rework ExportScheduler
  2. Reimplement schedules and triggers using Quartz.
  3. Regression testing

Proposed solution:
Re-use approach for implementation of Edifact Scheduling using Quartz ( MODEXPS-203 Closed )

Links to additional info

  • NFR Scorecard (attached)


 Comments   
Comment by Khalilah Gambrell [ 06/Jun/23 ]

Hey Noah Overcash  - can you review this feature and determine if it conflicts with the work Team Bama is doing?

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