Report Scheduler

Let's say your web app allows users to schedule reports to email off. These items are configurable and the user can add or remove them at any time.

• The front-end web app saves a database record back with all the information needed to run the specific report and it's parameters.

• Then the Scheduler reads the table for those database records every few minutes and updates, removes, reschedules any changed items.

• You get a simple callback when it's time to execute the event task

Demo Scheduler

The demo below hooks up everything but actually generating reports, and emailing them off.

• The RunType argument could easily contain what reports to generate.

• The RunArgs could easily contain additional user information like who it's being sent to, a database ID of the job to lookup, etc.

PerigeeApplication.ApplicationNoInit("Demo Scheduler", (c) =>
{
   
    //Declare a new memory source, remember to use a single instance of memory/file based sources or locking can occur
    using var MemSource = new MemoryScheduledSource("memSource.json", c.CTS.Token);

    //Add scheduled items.
    //If this was something like a DatabaseScheduledSource, we obviously would control these records from the database, not here.
    MemSource.AddIfNotExists(GenericScheduledItem<ushort>.MemoryItem(0, "A scheduler, 15sec", "A", "a;b;c", "*/15 * * * * *", TimeZoneInfo.Local));
    MemSource.AddIfNotExists(GenericScheduledItem<ushort>.MemoryItem(1, "B scheduler, 45sec", "B", "b;c;d", "45 * * * * *", TimeZoneInfo.Local));

    //Add a scheduler with the MemorySource, a single callback is given for anything required to run (multi-threaded)
    c.AddScheduler("Main", MemSource, (ct, l, item) => { 
        if (item.GetRunType() == "A")
        {
            l.LogInformation("Running A with {args}", item.GetRunArgs());
        }
        else if (item.GetRunType() == "B")
        {
            l.LogInformation("Running B with {args}", item.GetRunArgs());
        }

    });

});

The demo code uses the Memory Scheduler as it does not require a remote source. Typically speaking you would tie the event task descriptions back to a database record (like the MSSQL Scheduler Source).

• Line 5 - Declare a new event source. This demo uses the memory scheduler.

• Line 9-10 - Add the two scheduled items, A, and B, to schedule and execute

• Line 13 - Add a scheduler using the source we defined, and declare the callback.

  • You're given a CancellationToken for respecting graceful shutdown event.

  • An ILogger for logging to the system and defined sink sources.

  • And the GenericScheduledItem<ushort> Which is the interfaced item that allows you to access it's definition values.

• Line 14 - You can execute or perform any tasks you need. Like generating a report with parameters.

  • You can see the call to GetRunType(). There's also GetRunArgs(), GetLastRunDate(), GetName(), etc.