Understand scenario scheduling

Transcript

Up to this point in our training, we’ve been building and testing scenarios using the run once option in the scenario designer. As you activate scenarios in real life, they can be executed on some sort of schedule or initiated automatically via a web hook. More to come in future classes. Scenarios can be run as often as once per minute or can be set up on a certain type of schedule based on defined criteria in the advanced scheduling. When we’re talking about scheduling a scenario, we’re essentially setting up the cadence for how often that schedule will run. Runs are often referred to as a single execution. Each run or execution is going to be represented by a single row in the execution history. Each run may execute one or multiple cycles. Up to this point, we’ve been clicking the run once and that will only ever execute a single cycle. And by default, once we do set up a schedule, a new scenario will always have a default of one cycle per run. A cycle is an execution of all the modules. What’s really great about cycles in the fusion system is it will start by validating all the connections within all the modules of your scenario.

This will prevent a scenario from running halfway and partially processing some information and then canceling out once it reaches a module that has a broken connection. In the execution history, we can review a single run in the details of each cycle independently. The last piece of the puzzle when talking about scheduling our scenarios is setting the maximum number of records. Most polling triggers or the modules that we’ve been working with so far have a maximum records or limit property. The maximum records or limit field will determine how many records will be processed and executed on in a single cycle. And every record or bundle that is output by a single module will be processed individually by all subsequent modules unless aggregated. Let’s take a look at how runs, cycles, and bundles behave in a regular schedule interval. In this example, we have a scenario running every five minutes with three cycles happening per run and a total 10 maximum records per cycle. At 10:00 AM, the scenario runs or executes, but no records are found in the first cycle, so no other cycles are executed. At 10:01, someone adds 40 records to a third party. At 10:05, for the next scheduled run, cycle one returns and processes 10 records, cycle two returns and processes the second 10 records, cycle three runs and processes an additional 10 records. At this point, we have only processed 30 of the 40 available records. But based on the schedule, this can only run three cycles and 10 maximum records per cycle. We need to wait for the next scheduled run. At 10:06, however, five additional records are added, a total of 45. At 10:10, the scenario runs and cycle one returns and processes the last 10 records from the original 40. Cycle two will run and execute on the additional five records added. Cycle three, however, does not need to run because we have no additional records to process. -