In the web UI, you can schedule actions to run based on a time and date or based on an event.
Note: This section applies to the Cleo Harmony and Cleo VLTrader applications only.
You use the Scheduler to run actions automatically at specific times, when files are present, or when certain events occur.
Note: You can modify an existing schedule by simply changing, adding, or removing the scheduling parameters for a selected action. To remove an action from the schedule, select Unschedule in the Schedule Action dialog box.
By default, the schedule will automatically start when the application is started. You can, however, override this behavior by turning off Run Scheduler Automatically at Startup. See Other system options.
For the Cleo LexiCom application, the schedule will only run one action at a time. If more than one action is scheduled for the same time, the actions are run sequentially. If a scheduled action is still running when another action's scheduled time arrives, the action is not started until the running action ends.
For the Cleo Harmony and Cleo VLTrader applications, you control concurrently running scheduled actions using the property Allow Scheduled Actions to Run Concurrently. See Other system options.
Scheduling actions to run automatically by polling for files
You can configure your system to poll folders for files and then run actions automatically when files are present.
Note: This option is available only for Commands actions.
Requirements when polling for files
When you set up an action to run by polling for files, the action will potentially be run according to the period you've configured. However, it will only actually run if one of these conditions are true:
- A PUT, PUT+GET, or LCOPY command within the action has a file to send or copy.
- The CHECK command is present in the action and specific conditions for that command are met.
Note that if an action contains both PUT/LCOPY and CHECK commands, it is the first command encountered that determines whether autosend properties (for PUT and LCOPY) or autocheck properties (for CHECK) are used. Since this could make it difficult to determine the actual schedule, actions designated for autocheck should contain only the CHECK command.
The frequency at which the scheduler checks to see if there are files to send or copy is controlled by the Autosend Check Every property. This indicates that even schedules set up for continuous polling are not actually continuous. Rather, their minimum frequency of polling is determined by Autosend Check Every.
PUT, PUT+GET, and LCOPY command rules
The following rules apply to actions containing PUT, PUT+GET, or LCOPY commands scheduled by polling for files.
- For an action to be scheduled this way, at least one of its PUT, PUT+GET, or LCOPY commands must use the delete after transfer (-DEL) option.
- If an action contains both PUT (or PUT+GET) and LCOPY commands, whichever type is found first in the action drives its scheduling. Even though this is allowed, it is highly recommended that autosend actions contain only one autosend-type command (for example, PUT/LCOPY -DEL). This ensures all autosends process only stable files. Furthermore, if multiple scheduler threads are in use, separating autosend commands should increase the throughput of the scheduler loop.
- When autosend is activated, files are checked for stability before they are sent or copied. This is an important feature to prevent to an unstable or incomplete file from being sent or copied. For this reason, all PUT and LCOPY commands should use autosend.
CHECK command rules
Note: The CHECK command is available only in the Cleo Harmony and Cleo VLTrader applications.
The following rules apply to actions containing CHECK commands scheduled by polling for files.
- The CHECK command must have a CHECK -FIL or CHECK -DIR command in the action.
- The CHECK command must specify an Age value of >nn[D|H|M|S] (where nn is a value of 0-99).
- The CHECK command may not specify the Count parameter. Therefore, by default, the count will be only one (1).
- If a file is reported on a particular CHECK run, and it is not subsequently handled (for example, moved somewhere else or processed in some way), it will be reported again on future executions of the command. For this reason, it is recommended that the Execute On Check Conditions Met property is specified, and that it contains the proper system commands needed to clean up the file.
- For details of the CHECK command, see CHECK command.
- The frequency of autochecks is based on the setting of the Age parameter and the age of the files found. It is easiest to understand this by example:
- Example 1 -- Age is >1D
Given the command
CHECK -FIL * Age=>1D
- When the first check is run, File1 and File2 are reported. Their file paths are available to any %file% macro present within the Execute On Check Conditions Met property. When the command is run again, if the same files are present, they are counted and reported again. Therefore, if you do not want to be notified multiple times regarding the same file, it is imperative that the files are dealt with (that is, removed) in the Execute On Check Conditions Met command.
- Example 2 -- Age is >0D
Given the command:
CHECK -FIL * Age=>0D
Note: The option to only run Action if files are found to send or check is not available for JavaScript actions.
Scheduling actions to run at specific dates and times
You can schedule actions to run automatically based on a weekly, monthly, or one-time period. For weekly and monthly scheduling, it is possible to set up multiple day and time ranges.
Scheduling actions to run weekly
You can schedule actions to run automatically on a weekly schedule. You can set up multiple day and time ranges.
Scheduling actions to run monthly
You can schedule actions to run automatically on a monthly schedule. You can set up multiple day and time ranges.
Scheduling actions to run one time
You can schedule actions to run automatically one time at a specific date and time.
Scheduling actions to run based on events
You can configure your system to run actions based on a trigger created when certain events occur. When the trigger is created, the action runs immediately. Note that, by default, actions configured to be triggered for an FTP server (under a Users host or a Local FTP Users host) are not triggered immediately. They are triggered when the connected FTP client issues another command or the session is closed. See Trigger At Upload Completion in Local FTP users mailbox advanced properties.
Triggers are generated when:
- a new file arrives in a folder
- a new file fails to arrive in a folder
- a user session ends successfully
- a user session fails to end.
Important: Only actions that are in scope of the triggering event are actually run. The trigger event's scope is limited to actions whose host is in the same host folder as the trigger's mailbox or in a parent host folder of the trigger's mailbox.
When you schedule an action to be run based on a trigger, the Scheduler window displays the triggering event in the Scheduled column. If there are multiple events, they are displayed in the Scheduled column as a comma-separated list.
- New file arrives
Runs the action when a new file arrives in the folder. You can choose successful or failed file transfers or both to trigger the action.
- User session ends
Runs the action when an FTP or SFTP user session ends. Choose successful or failed session end or both to be the trigger event.
Comments
0 comments
Please sign in to leave a comment.