Flow: Subroutine Action

(Requires EAM) The Flow: Subroutine Action allows you to call an Event Rule Subroutine event trigger from within another event rule. The primary purpose of the Flow: Subroutine action is to help you break up larger rules into smaller, reusable ones. Obviously, you would have already created other rules to call. These sub tasks would be rules that you commonly use, such as sending email notifications, moving files, encrypt/decrypt, and so on.

To create an event with the Subroutine action

  1. First use the Event Rule Subroutine event trigger to create a subroutine that contains frequently used actions.

  2. Then Create a new event rule and add the Flow: Subroutine action to the Event Rule.

  3. Click the link in the action to open the Event Rule Subroutine dialog box.

  4. Click the Choose a rule to trigger drop-down list to specify which event rule to trigger, and then specify parameters (variables) to pass to the rule (optional).

  5. (Optional) The Wait until this step completes before running the next step check box is selected by default. When the check box is selected, you can select the "If failed" action, and populate it with actions to run in case the rule fails. To allow the next step to run before this action completes, clear the check box. If check box is not selected, a prompt appears to confirm: "This step will be executed asynchronously (non-blocking), which means EFT won't wait for this step to be completed before running the next step. This could yield undesirable results if the next step depends on the output or outcome of this one. Are you sure you want to make this action asynchronous?" (All actions in the IF FAILED section are lost if the parent action is switched from async to sync mode.)

  6. Click OK to close the Event Rule dialog box and accept the changes.

Notes:

  • If there is no FAILED action set, then the call to the subroutine is asynchronous, and the subroutine is placed into a queue.

  • The number of threads serving the queue, which applies to all Sites on a server, (that is, executing async subroutines) is defined by the RunningAsyncSubroutinesLimit advanced property. The default is 10; 0 equals no limit

  • The per-Site limit on queue size is defined by the QueuedAsyncSubroutinesLimit advanced property. The default is 0, which equals no limit.

  • The Events logger should be used for troubleshooting.

Related COM API objects:

  • EventRuleSubroutine value is added to EventType enum

  • RunEventRuleAction value is added to EventActionType enum

  • ICIRunEventRuleActionParams interface is added to allow new action handling with two read/write properties:

    • [string] RuleName - the name of the subroutine to invoke [array of strings]

    • Variables - the variables to pass to the subroutine

  • ICIRunEventRuleActionParams class is added implementing ICIRunEventRuleActionParams interface

  • Create and configure action set action:

Params = CreateObject("SFTPCOMInterface.CIRunEventRuleActionParams") 
 actionParams.RuleName = "Event Rule Subroutine" actionParams.Variables 
 = Array("VAR1", "VAR2", "VAR3") rule.AddActionStatement 
 0, actionParams

  • Read action:

set params = action.GetParams() 
 MsgBox "Rule name: " & params.RuleName for each var in params.Variables 
 MsgBox "Variables: " & var next

EFT Subroutine Action Behavior

While the primary purpose of the Subroutine action is to help you break up larger rules into smaller, reusable ones, there is an additional benefit. Without the Subroutine action, rules triggered by file uploads do not return a positive completion reply to the remote client until after all actions in the rule have completed, which results in an increased risk of a client time out:

By adding a subroutine action, you can instruct the rule triggered by the upload to call a subroutine in a non-blocking (asynchronous) manner, which allows the upload rule to return the positive completion reply much sooner, mitigating the risk of timeouts:

If desired, subroutines can be called in a blocking (synchronous) fashion which, while increasing the chance of client timeouts, is useful when the parent action needs a result from the subroutine to properly complete its task: