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


