About Triggers

Triggers enable you to execute jobs in a preplanned manner, at regular intervals (time triggers) or whenever new items are added to your queues (queue triggers). The Triggers page enables you to create new triggers, manage existing ones, as well as instantly launch a job for any existing trigger.

Important:

Trigger time zones:

The time zone set on a trigger is not restricted by the time zone of the tenant. However, if you use non-working days calendars, you cannot set different time zones.

Time triggers are launched according to the time zone defined on the trigger level. Queue triggers are launched based on queue items processing.

Both time and queue triggers are disabled based on the trigger time zone.

Important:

Trigger disabling:

By default, a trigger gets disabled automatically after 10 failed launches if it hadn’t been successfully launched in the last day.

This value can be customized using the Triggers.DisableWhenFailedCount parameter.

Time Triggers

Enable you to schedule a recurrent time to start a job.

Once you add a time trigger for a process, you can expect the following:

1. The trigger creates a job at the scheduled time, with the allocation, account, and machine options of your choosing. This does not equate to the actual execution of the job.
2. The job created at step 1 is executed once a robot becomes available. By default, if the trigger already has a pending job, then no new jobs are created until the first one is executed.
   • The number of pending jobs that the trigger can create is controlled by the Triggers.JobsCountStrategy parameter.

Input values for processes that support input and output parameters can be managed at this level as well.

Execution Target

You can configure several rules depending on which the associated processes get executed.

	Description
Dynamic Allocation	Allocate Dynamically Define how many times a process is to be executed according to the given trigger. This option enables you to utilize your resources to their greatest extent. As soon as a Robot becomes Available, it executes the indicated process according to the provided trigger.
	Account The process is executed under a specific account. Only specifying the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.
	Machine The process is executed on one of the host machines attached to the selected machine template. Only specifying the machine results in Orchestrator allocating the account dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair. Note: Make sure that runtimes matching the job type are allocated to the associated machine template. Only connected host machines associated with the active folder are displayed.
Select valid account-machine Mappings	The process can be executed on multiple specific account-machine pairs.

Note: If the connection to the SQL database is lost for any reason, the triggers that were supposed to be set off at that time are misfired, and an alert with the Error level is generated.

Queued Jobs Scenarios

1. If you set multiple triggers on the same Robot and their execution time overlaps at least one time, the jobs are queued, in a pending state. The Robot executes the queued jobs in chronological order.

2. If the same process is scheduled on the same Robot multiple times and their execution time overlaps, only one process is queued, in a pending state. For example, if process A on Robot X is scheduled to run at 11:20, 11:21, and 11:25, the behavior is as follows:

   • at 11:20 the first process is executed.

   • If the first execution finishes before the second trigger:

     • The second trigger is processed.

       • If this execution finishes before the 11:25 trigger, the latter is also executed.
       • If the execution of the 11:21 trigger does not finish before the 11:25 one, the latter is added to a queue, in a pending state.
   • If the first execution does NOT finish before the second trigger:

     • The 11:21 trigger is placed in a queue, in a pending state.

       • If the execution of the 11:21 trigger finishes before the 11:25 one, the latter is also executed.
       • If the execution of the 11:21 trigger starts but does not finish before the 11:25 one, the last trigger is placed in a queue, in a pending state.
       • If the 11:21 trigger is still in pending when the 11:25 one should start, the latter is no longer executed or added to a queue and the following message is displayed: The Robots already have pending jobs for this process.

3. If you want to execute a process multiple times on any Robots that are available, you have the possibility to do just that by using the Allocate Dynamically option on the Execute Target tab. The jobs are queued, in a pending state, in the corresponding environment and each time a Robot becomes available, the first job in line is executed. In this way, no Robot is ever available while there are jobs pending.

   Let's say you want to run a process 7 times. The moment your trigger is triggered, 7 pending jobs are added to the environment workload, without being assigned to specific Robots. There are a couple of scenarios possible:

   • There are at least 7 Robots available at trigger time - one Robot gets assigned one job such that all jobs are executed in one go.
   • There are less than 7 Robots available at trigger time, say 4 - each of the 4 Robots gets assigned one job, if a new Robot or one of the 4 becomes available, then it takes over another job of the remaining 3. This happens for each available Robot until no jobs are left.

4. If two or more triggers are running the same process, each for a different number of times, at the next trigger, the maximum number of jobs between them is added to the environment workload; they do not cumulate. Imagine the following situation: trigger A runs a process 13 times and trigger B runs it 20 times. The following scenarios may arise:

   • A and B trigger simultaneously - 20 jobs (the maximum between 13 and 20) are queued in the environment workload.

   • B triggers first - 20 jobs are queued.

     • If between B's trigger time and A's trigger time, 7 or more jobs have been executed, say 9 (11 remaining pending jobs), then 13 jobs (the maximum between the 11 and 13) are queued in the environment workload.
     • If between B's trigger time and A's trigger time, less than 7 jobs have been executed, say 5 (15 remaining pending jobs), then no more jobs are queued as there are already more than 13 jobs pending. Also, the following message is displayed: The Robots already have pending jobs for this process.

   • A triggers first - 13 jobs are queued

     • Whenever B triggers during A's execution, a number of up to 20 jobs are added to the environment, depending on how much jobs from A are in progress or have been executed. Say 6 jobs have been executed. When B triggers, 14 jobs are added, such that the maximum of 20 has been reached.

5. If a trigger runs the same process multiple times, the related queued jobs are limited to the number of executions specified when you defined the trigger, on the Execute Target tab. They do not cumulate with each launch of the trigger.

   Let's say that every 30 minutes you want to run the same process 10 times. The first time your trigger is launched 10 jobs are queued. If between triggers, less than 10 jobs have been executed (say 4), at the time of the next trigger only 6 new jobs are queued, as the number of pending jobs for that process can be a maximum of 10.

Queue Triggers

Can instantly start a process upon the trigger creation or whenever you add a new item to a queue. The trigger runs in the environment associated with the selected process.

Important: The implementation of queue triggers is optimized for consuming processes that have an internal loop to process all the available queue items before exiting. If a process does not implement this strategy then the resulting experience will be suboptimal and might not meet the desired business requirements.

There are three options that help you configure the rules for process triggering:

Field	Description
Minimum number of items to trigger the first job	The item-processing job is only started after the targeted queue has at least this number of new items. Deferred queue items are not counted.
Maximum number of pending and running jobs allowed simultaneously	The maximum number of allowed pending and running jobs, counted together. For 2 or more jobs allowed simultaneously, the third option needs to be defined as described below.
Another job is triggered for each __ new item(s).	A new job is triggered for each number of new items added on top of the number of items defined for the first option. Only enabled if there are 2 or more jobs allowed simultaneously (defined using the option described above).

Orchestrator takes into account both New and In Progress queue items when computing the number of target jobs that must be reached for optimal resource allocation.

Example

1. Say you add 3 queue items to the queue. Orchestrator computes the number of target jobs based on the number of new and in-progress items => 3 target jobs are needed. Orchestrator launches 3 jobs to process the 3 queue items. The 3 items move to In Progress.
2. Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new and in-progress items => 5 (3+2) target jobs are needed. Orchestrator launches 2 new jobs to reach the target of 5.

To handle queue items that cannot be processed at the moment they are enqueued, including retried items, once every 30 minutes, a check for unprocessed items is performed by default, and if the triggering condition is met, the trigger is launched once again. This check ensures all items in the queue are processed in the following situations:

• Queue items are added to the queue much faster than they can be processed with the available resources.
• Queue items are added to a queue during non-working days, but they can only be processed during working hours.

• Queue items processing is postponed for a later time. After that time has elapsed, they are ready to be processed once they have been identified by the 30-minute check.

  Note: Due to the default 30-minute check, there's a risk of resource obstruction during non-business hours. To avoid this, make sure there are no unprocessed items at the end of the working day. If that is not a possibility, ensure the triggered process does not require human intervention.
  Note: Note that you can use the Queue.ProcessActivationSchedule parameter to adjust the default 30-minute check interval.

Example

I have two jobs:

• One that adds 3 items per second for 20 seconds to the targeted queue (60 items in total).
• One that processes 1 items per second from the targeted queue.

I have defined my trigger as follows:

• Minimum number of items to trigger the first job:31.
• Maximum number of pending and running jobs allowed simultaneously:3.
• Another job is triggered for each 10 new item(s).

I launch the job that adds items to my queue.

1. After 11 seconds (33 items) the first item-processing job is triggered.
2. After another 4 seconds (12 items) the second item-processing job is triggered.
3. After another 4 seconds (12 items) the third item-processing job is triggered.

By the time queue item addition ended, the first job had processed 9 items, the second one 5 items, the third one 1 item. That's 15 items in 20 seconds processed by three jobs.

That means a remainder of 45 items to be processed (60-15). Having 3 jobs, each processing 1 item per second, that means 15 second for the remainder to be processed.

A total of 35 seconds.

Execution Target

You can configure several rules depending on which the associated processes get executed.

Description
Account	The process is executed under a specific account. Only specifying the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.
Machine	The process is executed on one of the host machines attached to the selected machine template. Only specifying the machine results in Orchestrator allocating the account dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair. Note: Make sure that runtimes matching the job type are allocated to the associated machine template. Only connected host machines associated with the active folder are displayed.

Job Count Strategies

The Triggers.JobsCountStrategy parameter enables you to choose the strategy for launching jobs through triggers. The following options are available:

• PerProcess - A trigger launches the required number of jobs taking into account any pending jobs for the specified process. E.g., two triggers defined for the same process launch 3 and 5 jobs, respectively. If the first trigger launches 3 jobs at a given point in time, when the second trigger is set off, 2 jobs are launched so as to reach the 5 required jobs.
• PerTrigger - A trigger launches the required number of jobs taking into account any existing jobs previously launched by that same trigger. E.g., a trigger is defined to launch 9 jobs at a given point in time. If 2 jobs have been successfully completed by the time this trigger is set off again, Orchestrator launches another 2 jobs so as to reach the 9 required jobs.
• NoLimit- The trigger launches the required number of jobs irrespective of any existing, pending jobs. E.g., a trigger is defined to launch 5 jobs at a given point in time. The second time the trigger is set off, another 5 jobs are launched.

Non-Working Days

This enables you to define multiple lists of non-business days, per tenant, each with its own set of dates, on which you can configure your triggers to not run if needed. This means that, during public holidays, weekends, or any other day on which normal business activities are not being carried out, your long-run triggers can be configured such that they don't get launched. You can define or upload such calendars on the Non-Working Days tab, in the Settings page. A BankHoliday calendar is created by default, to help you define your first non-working days easier. Once the non-business days defined in the selected calendar are over, the trigger is launched as usual.

In order to apply any of these restrictions to your triggers, you need to select the desired calendar from the Non-working day restrictions drop-down when creating a new trigger or editing an existing one. You can select only one calendar for a trigger. Note that editing a calendar on the Non-Working Days tab also affects triggers that already have that calendar selected within the Non-working day restrictions drop-down.

Note: When you use non-working days, the trigger time zone must be the same as the tenant time zone (Tenant> Settings> General), because calendar restrictions cannot be applied in different time zones. A tenant without an explicitly defined time zone inherits it from the host.

Note:

Adding and removing non-working days is audited at the tenant level.