111 lines
5.6 KiB
Plaintext
111 lines
5.6 KiB
Plaintext
GENERATOR SPECS
|
|
|
|
CASES
|
|
|
|
|
|
|
|
REQUIREMENTS
|
|
|
|
|
|
- Is accessible from OPERATIONS endpoint see core-long-running-operations.txt
|
|
|
|
|
|
Use db table OPERATIONS queue to submit jobs for generator to handle.
|
|
|
|
Generator looks in table periodically for work to do and if the criteria matches starts the job by calling out to the submitting code
|
|
- Generator is only concerned with the job starting and ending and logging, that kind of thing, it does no work on it's own directly
|
|
- Start date time
|
|
- Is api locked and can it run when api is locked
|
|
- Is job exclusive, i.e. no other jobs while it's running and or api is locked
|
|
- Updates into a operationstatus table and endpoint that is open when api is locked
|
|
- Deletes status succeeded operations and their operationstatus entries after 24 hours automatically
|
|
- Deletes status FAILED operations and their logs after 2 weeks automatically
|
|
- New jobs cannot be submitted via the rest api when the REST interface is locked but it can be queried to see what is happening
|
|
- Hands off completed jobs back to submitter for resolution
|
|
- I.E. if a workorder was generated from a PM then it goes back to the PM and says "DONE THIS JOB" or "FAILED THIS JOB" and the PM code handles resubmitting a new job for next time
|
|
- This way generator does less and isn't responsible for hairy complex code that is best handled at the source of the job
|
|
|
|
- JOB is actually handed off back to the object that submitted it into the db in the first place to do the work
|
|
- i.e. generator sees a send notification job for a workorder status change, it is ready to go so it in turn passes the job ID or info back to the workorder-process-notification code to handle and takes back the result
|
|
- i.e. a workorder may submit a "notify users about status change" job, generator sees it and in turn calls notify users code in workorder which in turn creates new jobs to send each email
|
|
generator then sees send email jobs and in each case hands them off to the email processor to deal with
|
|
|
|
|
|
|
|
|
|
TODO GO THROUGH GENERATOR CASES AND v7 GENERATOR CODE, COMPILE A LIST OF WHAT GENERATOR NEEDS TO DO
|
|
- Need a list of everything RAVEN generator will need to do
|
|
- BREAK out into small separate concerns
|
|
- Make a spec doc for each separate concern (i.e. one for the process loop, one for the LRO stuff, one for the physical delivery etc)
|
|
|
|
|
|
JOBSWEEPER
|
|
- Need a maintenance job class that handles periodic routine internal maintenance CoreJobManager
|
|
- Submits and handles or hands off routine jobs
|
|
- Clean up database (look for orphaned records) CoreJobDBMaintenance
|
|
- Check for license maybe or check license validity? (had some plan to automatically pull license from rockfish, to accomodate monthly rentals) CoreJobLicenseCheck
|
|
- Clear out completed jobs CoreJobSweeper
|
|
- Probably dozens of other things
|
|
|
|
NOTIFICATION SWEEPER
|
|
- Maintains notifications tables: cleans out old ones, finds ones that are "stuck", notifies OPS about weirdness if found, removes undeliverable ones, counts retries etc
|
|
|
|
|
|
|
|
RAVEN JOB SEQUENCE OF OPERATIONS
|
|
|
|
Hypothetical Widget UPdated notification job
|
|
- Widget UPdated
|
|
- Calls into notification code in WidgetBiz or JobObject or maybe INotifyObject to see if it should create a notification
|
|
|
|
|
|
|
|
|
|
HOW AND WHAT v7 GENERATOR DOES
|
|
|
|
These functions are called every 5 minutes by Generate in Winform desktop standalone.
|
|
- GenProcessPM.GeneratePMWorkorders();
|
|
- GenProcessDeliveries.DeliverNotifications();
|
|
- GenProcessClientNotifications.DeliverNotifications();
|
|
|
|
|
|
GeneratePMWorkorders
|
|
- Calls for a list of pm id's of not expired and generate on date in future (for some reason it's just in future, not a specific time range, seems buggy)
|
|
- Taks the list of id's and passes them to workorder generate from pm which in turn...
|
|
- Workorder.cs Makes workorders from PM workorders copying pm wo data into service wo data
|
|
- Workorder.cs After making the service workorder the last bit of code calculates the next pm date and then adjusts the source pm to the next date
|
|
|
|
DeliverNotifications (techs)
|
|
- Get a list via notificationlist :
|
|
// List of notifications formatted for delivery
|
|
/// and screened to be deliverable
|
|
///
|
|
///
|
|
///
|
|
/// Loops through all NotifyEvenRecords
|
|
/// For pending type events, checks to see if within users selected notification window
|
|
/// foreach NotifyEventRecord it adds a NotificationListInfo
|
|
/// for each open delivery window for each subscriber to that event
|
|
/// As it Processes each deliverable notification it formats it to users
|
|
/// translation and preferences for size etc and keeps track of the address and
|
|
/// delivery type.
|
|
///
|
|
///
|
|
/// End result is a list ready to deliver.
|
|
/// As each one is delivered Ok it should be deleted from the NotifyEvent table by the
|
|
/// delivery Process that uses this list.
|
|
- Iterate the list and depending on deliver via method required:
|
|
- SMS (smtp)
|
|
- SMTP (email)
|
|
- POPUP
|
|
- AYANOVA MEMO
|
|
- Log delivery and remove event after each item is delivered individually
|
|
|
|
|
|
DeliverNotifications (clients)
|
|
- Gets a list of client notifications that are ready to deliver (they hold the entire message in EML format)
|
|
- Attempts smtp server connection, if a problem then logs it and optionally, based on global setting, will bail and retry again later, otherwise proceeds through code which in turn deletes each notification it can't deliver
|
|
- Delivers via smtp, if fail logs failure. Either way deletes the notification so it's gone forever
|
|
|
|
|