A File Trigger is a trigger that causes a job to be executed whenever specified files are created, modified, or deleted.
When you create a File Trigger, you specify the files or directories that adTempus should watch for, and under which conditions the job should be triggered.
The File Trigger works by periodically (approximately every 10 seconds) scanning the directories being watched by the trigger and comparing the current state to the previous state.
Each time the File Trigger scans the directories, it produces a list of all the files that meet the trigger criteria. Because adTempus makes this evaluation at intervals of several seconds, it is possible for more than one file to meet the trigger criteria. For example, suppose you have a trigger configured to fire any time files are added to a particular directory. In between evaluations of the directory, five new files are copied into the directory. On the next evaluation, adTempus will find those five files, and the trigger's Start a separate instance for each file setting determines how it will handle the scenario.
If the Start a separate instance for each file option is checked, adTempus will start a separate instance of the job for each of the matching files it has found, and each instance will have the FileName job variable set to the name of the file for which it is being executed.
Typically you would use this option if your program is being called to process files individually. For example, you need to run a data processing utility on each file that is uploaded into a directory. When you configure the Program Execution Task to run your program, you can include the token "%FileName%" in the command-line parameters, and adTempus will replace "%FileName%" with the name of the triggering file.
If the Start a separate instance for each file option is not checked, adTempus will start a single instance of the job, even if more than one file has been found. The FileName job variable will contain the names of all the files found on the current evaluation pass.
Typically you would use this option if your program is being called to process an entire directory. For example, your program already has logic to scan an entire folder and process all the files in it; you only need adTempus to start it when there are files there to process.
In this scenario, you need to make sure you have configured the job so that it will not be triggered too often. For example, set the job's Multiple Instances rule to prevent duplicate instances of the job from being started at the same time. Otherwise, adTempus may trigger your program again while it is still processing files from the first trigger.
adTempus saves the current state of the directories it is monitoring each time it makes an evaluation pass. This state information is stored in the adTempus database, and so is not lost if the adTempus service is shut down. Therefore when adTempus starts, it compares the current file state to the state information it saved before it shut down, and triggers jobs based on the differences. That is, adTempus will respond to files that were added, changed, or deleted while adTempus was not running.
If your file trigger is watching files on a network drive, you may encounter problems if the network connection is broken. Because of the way adTempus scans for files, if the network connection is broken, any files on the network drive will not be visible to adTempus, and it will respond as if they had been deleted, triggering the job if your trigger is set to fire on deletions. Similarly, when the connection is restored and the files suddenly reappear, adTempus will see them as new files (because they were not there on its previous evaluation pass). adTempus will therefore trigger the job if the trigger is set to fire when new files are created.
See Also