Event Rule Order of Execution

If you create more than one Event Rule for a single type of event, for example, Monitor Folder, EFT Server prioritizes the Rules in the order they appear on the Event Rules list.

To change the priority of a Rule

In the administration interface, connect to EFT Server and click the Server tab.
In the left pane, click the Site you want to configure, then click Event Rules. The Rules 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.

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).

Event Rule Sequence for Matching Event Rules

One or more Event Rules may be triggered when Conditions are met. For matching Event Rules, meaning those 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 Server’s supported Events; however, the Monitor Folder and Timer Event Rules are executed asynchronously. When you stop the Site or the Server service, EFT Server 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 Server.

Event Rule Sequence for Matching Folder Monitor Rules

As mentioned above, matching Timer and Monitor Folder Events are executed asynchronously; however, Monitor Folder "threads" are limited to three concurrent threads by default. This means that if you have 5 Folder Monitor 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 three threads are done firing and executing any actions.

Order in which Actions are Executed

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

Triggering a 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, but EFT Server 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

Almost all of EFT Server’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.

This is not always the case for Command Actions and AWE Actions. These Actions execute asynchronously, which means that EFT Server 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 PGP Action

A common Event Rule scenario is downloading a file, running a script against that file (either with a Command or an AWE 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 a Command Action that runs a script (Cscript.exe), followed by a PGP 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. The potential risk is if you are doing a transform on the file you just retrieved that must be completed PRIOR to the PGP operation, 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 "if failed" Condition so that the PGP Action does not start until after the Command has finished running the script.