Event Rule Order of Execution

Almost all of EFT’s Event Rule Actions are executed synchronously (execute 1, wait until it finishes, execute 2, wait until 2 finishes, execute 3 … etc.), as there may be more actions that follow that depend on the prior Action completing successfully. Each Action is completed before continuing to the next, with a few exceptions, which are described below (Timer Rules, Monitor Folder Rules, and Rules that use the Execute Command Action or AWE Action).

If you create more than one Event Rule for a single type of Event trigger (e.g., Monitor Folder), EFT prioritizes the Rules in the order they appear in the Rule list. You change the priority by moving a selected Rule up or down in the Rule list. The Rule list is grouped by Rule type. You can only prioritize the Rules within a Rule type. For example, you cannot move an On Folder Monitor Rule above an On Scheduler (Timer) Event Rule, but you can prioritize the Rules within the Rule type (e.g., place one Timer Event to occur before another Timer Event).

To change the priority of a Rule

In the administration interface, connect to EFT and click the Server tab.
On the Server tab, click the Site you want to configure, then click Event Rules. The Rule list appears in the right pane.
In the right pane, select the Event Rule you want to move.
To reorder the Event Rules, under Rule Priority, click Higher and Lower.

Event Rule Sequence for Matching Event Rules

One or more Event Rules may be triggered when Conditions are met. For Event Rules with duplicate Event trigger definitions and Conditions, but with different Actions, the order of execution is sequential according to the sort order defined in the interface.

Event Rule Sequence for Matching Timer or Folder Monitor Rules

This sequential firing of duplicate Event Rules applies to almost all of EFT’s supported Events. However, the Monitor Folder and Timer Event Rules are executed asynchronously (i.e., not at the same time). When you stop the Site or the Server service, EFT breaks all existing connections and waits until all socket threads die. The service can terminate when Timer Event processing is still in progress. The triggering of Monitor Folder and Timer Event Rules occurs almost simultaneously and is controlled by the operating system, not by EFT.

Event Rule Sequence for Matching Folder Monitor Rules

As mentioned above, matching Timer and Monitor Folder Events are not executed at the same time. However, Monitor Folder "threads" are limited to 3 concurrent threads by default. This means that if you have 5 Monitor Folder Event Rules monitoring the same folder and a file is added to the monitored folder, only 3 of the 5 Rules will fire, as determined by the operating system. The 4th and then 5th Rule execute only when one or more of those 3 threads are done firing and executing any actions.

Order in which Actions are Executed

EFT executes Event Rules according to whatever synchronicity applies to that Event Rule. For example:

Triggering an Execute Command Action is asynchronous, unless the "If Failed" sequence has an Action defined for that Command.
Move, copy, and download operations are synchronous.
PGP operations are synchronous and cause the Event dispatcher to wait until the operation is finished before moving on to the next Action/Condition.
E-mail notifications are synchronous up to the point of generating the contents of the e-mail and putting the data into a queue. However, EFT has a separate thread that manages the e-mail notification queue to pick up ready messages and send them to the destination server. Therefore, e-mail notifications are roughly asynchronous.

Execute Command Actions and Execute Advanced Workflow Actions execute asynchronously, which means that EFT does not wait for a reply before returning control to the Event Rule thread, unless an "if failed" Condition is specified, such as Stop Processing this Rule. If an "if failed" Condition is specified, regardless of whether the Command succeeded or failed, the Event Rule processor waits for a return message from the invoked process before moving on to the next Rule.

Example: Command Action Followed by OpenPGP Action

A common Event Rule scenario is downloading a file, running a script against that file (either with an Execute Command Action or an Execute Advanced Workflow Action), then encrypting or decrypting the file.

In the illustrations below, an Event Rule has three Actions: first an SFTP get (download a file from the Remote Server), followed by an Execute Command Action that runs a script (cscript.exe), followed by an OpenPGP Action.

In Example 1, an "If failed" Condition was not defined for the Command, so when the Command executes, the next Action (PGP) is called almost immediately after the script is called. If you are doing a transform on the file you just retrieved that must be completed PRIOR to the PGP operation, the potential risk is that there will be a race condition and likely PGP will lose; that is, the pre-transformed file will be PGPed or the Action will fail because the script has locked the file for some reason.

In Example 2 we've added the "If failed" Condition so that the OpenPGP Action does not start until after the Command has finished running the script.