Adding triggers

A Trigger is a feature where MFT Server listens for events and responds with one or more Trigger Actions. This is true providing Trigger Conditions (if any) are met.

To view a list of Triggers, navigate to [Domain] AUTOMATION > Triggers > Triggers.

Adding a Trigger

To add a Trigger, click Add. The Trigger Template dialog displays. See Using trigger templates.

To create a Trigger without using a template, click OK. The Add Trigger dialog displays. Alternatively, you can create a Trigger using a template by selecting a template from the dropdown list. If a template is selected, the Add Trigger dialog displays with field values taken from the template. You may change any setting as you see fit.

Below is an image of the Add Trigger dialog. The Parameters tab is enabled by default.

Parameters Tab

General

Name — Identifies a unique Trigger name. See Trigger Name for a tip if you are using the same Trading Partner in multiple Triggers.

Event Type — Identifies the type of event to listen for. When the event occurs, the Trigger Actions execute, providing Conditions (if any) have been met. See Event types.

Description — Describes the Trigger.

Tags — If selected, the Trigger is only visible to system administrators, or to administrators assigned a role that includes the specified tag. See Administrators for more information.

Enabled — If selected, the Trigger is enabled. When disabled (not selected) the Trigger will not execute.

Advanced

Ignore Trigger events while Domain is [stopped, paused, stopped or paused] - If selected, events will not be processed when the Domain is in the state selected from the dropdown list.

 

If Domain1 is paused and a Trigger configured in Domain1 occurs when Ignore trigger events while domain is paused is selected, the Trigger will not fire, and there is no evidence of the event occurring in the Trigger history.

 

Run trigger in single instance mode and [queue or skip] execution — If selected, only one instance of the Trigger will run at a time. If an instance of this Trigger is already running and another event occurs, the new instance can either be queued or skipped.

In the image below, the AUTOMATION > Triggers > History depicts queued Triggers when the configured Trigger has Run trigger in single instance mode and queue execution selected. Observe that in this scenario, only one execution of the Trigger event occurs at a time.

 

 

Alternatively, if skip is selected (instead of queued), you will see a status of skipped if a Trigger occurs when the execution of a prior Trigger is not yet complete.

 

Run trigger asynchronous — If selected, the Trigger is processed asynchronously. For more details on the difference between asynchronous and synchronous (the default behavior) processing, click on this topic: 4.  Prepare for execution

 

Fire Trigger Error event if error occurs — If selected and an error occurs while executing any of the Actions associated with the Trigger, a Trigger Error event is raised. You may capture this event using a Trigger that listens for the Trigger Error event and respond appropriately (with one or more Trigger Actions).

 

For example, with this option checked, you can create another Trigger to handle the error, as depicted in the image below. The Event type is Trigger Error.

 

 

What type of Action you would like to perform is up to you (e.g. send out an email). In the example below, the use of event variables is depicted in the Action selected. The Trigger Error is configured with an Action that appends details about the failed Trigger into a file. That information is obtained from system-generated event variables. When configuring the Message portion of the target file, you can select a variable by clicking on the Add Variable button. The variables available for use are displayed in a dropdown list. The variables are referenced with a preceding and following % sign. The text preceding the variable name (in the image below) was entered by the user.

 

 

When the Trigger Error event runs, the resultant text file contains the information depicted in the image below.

 

 

The Event ID of the failed Trigger can be used to look up the Trigger that failed.  See the image below.

 

 

If you view the history of any Trigger in [Domain] AUTOMATION > Triggers > History, a list of associated event variables and their values are displayed.

If you would like the MFT Server log file (e.g. server0) to capture verbose Trigger information, navigate to Settings > MANAGER SERVICE > Logs > Debug and enable this line: com.jscape.inet.mftserver.operation.trigger.level=FINEST. See Debug for more details.

Conditions Tab

The Conditions tab lets you optionally specify one or more Conditions that must be met for the Actions to execute. Trigger Conditions can be entered manually (select "Override") or by using the GUI-based Expression Builder. If you develop an expression using the Expression Builder, the expression is automatically written in the Expression box. This box is read-only if the Override checkbox is not selected. Should you wish to enter the expression manually, select Override to disable the Expression Builder.

Expression — Identifies the Trigger Condition (if any) in this text field. (See Writing conditions)

Override — If selected, you must enter the Trigger Condition in the Expression box manually.

Test Expression — Tests the Trigger condition. (See Testing conditions)

Variables — Displays a list of supported variables. This list varies depending on the Event type selected in the Parameters tab.

Functions — Displays a list of functions. (See Function types).

Operators — Displays a list of supported Operators (e.g. =, !=, <, >, etc.). Hover your mouse over an operator to view context-sensitive help.

Constants — Displays a list of supported constants.

AND — Inserts the AND logical operator.

OR — Inserts the OR logical operator.

Time Expression — Provides a more convenient way of specifying time expression parameters. (See Using time based triggers).

Actions Tab

A Trigger Action (i.e. the payload) is what executes when the Trigger event occurs. One or more Trigger Actions are supported. Trigger Actions are added as nodes in a flowchart. When creating a new Trigger, the Actions tab consists of a canvas area with a single node named Workflow, as shown below.

The Workflow node has four outputs, Start,Finish, Success and Failure. Each of the four Workflow outputs support the creation of multiple Trigger Actions, meaning you can have one or more Actions linked to the Start output and one or more Actions linked to the Finish output, etc. You can also have one or more Actions linked to the output of a prior Action's Success and one or more Actions linked to a prior Action's Failure. When there is more than one Action linked to the same output (e.g. two Actions linked to the Start of the Workflow, or three Actions linked to the Success of a prior Action), the multiple Actions are executed asynchronously (concurrently).

Note that for most Trigger Actions the input name is Execute, and the output names are Success and Failure. There are some Actions where the input and output names are different.  For example, the If Action input name depends on the Condition field entered by the user. The output names are Then and Else.  For all Actions, the input name is on the left-hand side of the node, and the output names are on the right-hand side.

Workflow outputs

Start — Identifies one or more Trigger Actions to execute when the Trigger execution begins.

Finish — Identifies one or more Trigger Actions to execute when the Trigger execution ends.

Success — Identifies one or more Trigger Actions to execute if all Actions complete successfully in the Start or Finish workflows.

Failure — Identifies one or more Trigger Actions to execute if any Action fails execution in the Start or Finish workflows.

Add, Edit, Delete, Copy, Copy ID to clipboard, Reset Zoom Level

Add — This button lets you add a Trigger Action. When clicked, an Add Action dialog displays.

Edit — This button lets you edit an existing Trigger Action. Select the desired Trigger Action, then click Edit. The Edit Action dialog displays. You can also right-click on a Trigger Action, then select Edit from the list. Double-clicking on an Action node is another way to pull up the Edit Action dialog.

Delete — This button lets you delete a Trigger Action. Select the desired Action, then click Delete. You can also mouse over the Action node you wish to delete, which results in a red "x" appearing in the node's right-hand corner. Click the x to delete the Trigger Action. Another way to delete a Trigger Action is by right-clicking on the Action, then selecting Delete from the list. When you delete an Action, you are prompted to confirm the deletion.

Copy — This button lets you copy a Trigger Action. You can also mouse over an Action you wish to copy. Doing so displays a copy icon to the right of the Trigger Action's name. Click the copy icon to copy the Trigger Action. Another way to copy a Trigger Action is to right-click on the Action, then select Copy from the list.

Copy ID to clipboard — This option displays when you right-click on any node in the Actions canvas area. When selected, the system-assigned Action ID is copied to the clipboard. The Action ID can be used in the GetActionResult function as its input parameter.  In more recent versions of MFT Server, you can also use the Action's Name as the GetActionResult function's input parameter. The Name field allows you to enter a value that is more user-friendly than the system assigned Action ID.

Reset Zoom Level — This option displays when you right-click in the white-space of the Actions canvas area, or you right-click on any node or link.  If you previously increased or decreased the zoom level, selecting this option displays the nodes and links in the canvas area at 100%.

To add a Trigger Action, click the Add button, or use any other method previously described. Expand the Action dropdown list to view all available Trigger Actions. To view a description for an Action, select the Action from the dropdown list, then click the adjacent information icon (see the image below).

After selecting the desired Action, Click OK.

The Add Action dialog displays, which varies depending on the selected Trigger Action. Common to all Trigger Actions are the Name and Notes fields, shown in the image below. The Name field initially consists of a default, system-generated value which includes the name of the Action followed by a series of letters and numbers. The Name field value must be unique within the Trigger you are defining. You can change the Name's default value to something easy to remember, which is helpful when using it as the input parameter for the GetActionResult function.

Next, the Notes field lets you describe what the Action is doing. Both the Name and Notes fields are displayed as a tooltip in the Action canvas area when you mouse over an Action node.

After entering the remaining Action details, click OK.

A new Trigger Action node bearing the Action type chosen (e.g. Trading Partner File Upload) is added to the Actions canvas area. Most Trigger Actions have one input, Execute, and two outputs, Success and Failure (as mentioned earlier, there are a couple of Actions where the input/output names are different). You may link the Trading Partner File Upload Action to either the Start or Finish outputs of the Workflow node. If you link this Action to the Start output, this Action is executed as soon as the Trigger begins execution. If you link it to the Finish output, it executes once the Trigger execution completes.

As you create new Action nodes, they are placed in a default location on the canvas area. You can move the Workflow node or any Action node around by clicking on the title bar of the node, then moving (dragging) it to your desired location. There is a feature that when enabled (it is disabled by default) organizes your Actions by snapping them to the canvas area grid. This means that the Action nodes are placed at the closest intersection on the grid (grid lines are not visible on the canvas area and cannot be made visible). If you wish to use this feature, right-click anywhere in the canvas area (including on the nodes and links) which displays a list where the Align actions to grid option can be selected. When selected:

• The existing nodes and any future nodes you create in the current session will automatically align in the canvas area.

• A green check will appear to the left of the Align actions to grid option (it serves as a visual aid for you to know this feature is enabled).

When Align actions to grid is enabled, existing and new nodes are snapped to the grid, which means you do not have granular control of where the nodes are placed on the canvas area. The system aligns them in the grid for you. You can still manually move the nodes around as previously described, however, they are snapped into the nearest grid location as determined by the system. Check the Align actions to grid option to disable this feature (the green check next to the option name is removed when the feature is disabled). Once disabled, you can manually move the nodes in a precise desired location, and they remain where you place them.

When you save the Trigger, the system saves the node layout. This means when you edit the Trigger in the future, the nodes are in the position they were in when you last saved them. This is true regardless of whether Align actions to grid is enabled or disabled when the Trigger is saved.

To link an Action node to the Workflow's Start output, you can use the original method, or the new (enhanced) method.

Original method

1. Click on the Workflow's Start label or click on the output connector symbol (a "half diamond") to the right of the Start label.

2. Release your mouse (do not hold down any mouse button).

3. Move the mouse to the desired Action's input that you wish to link up to. As you move your mouse, a dashed line will appear. The Action's input is always on the left-hand side of the Action node, and is most frequently named Execute, but there are a few exceptions (e.g. If Action).

4. Click the mouse when you see the target Action node's input connector symbol (a "half diamond") turn a different shade of color, indicating it is active. A link is generated. You will know the link is successful when you see a green arrow pointing from Start on the Workflow to the input connector symbol on the target Action node. This is depicted in the image below.

    

New method

1. Click on the Workflow's Start label or click on the output connector symbol (a "half diamond") to the right of the Start label. Do not release the mouse.

2. Drag the mouse to the desired Action's input that you wish to link up to. As you move your mouse, a dashed line will appear. The Action's input is always on the left-hand side of the Action node, and is most frequently named Execute, but there are a few exceptions (e.g. If Action).

3. Release the mouse when you see the target Action node's input connector symbol (a "half diamond") turn a different shade of color, indicating it is active. A link is generated. You will know the link is successful when you see a green arrow pointing from Start on the Workflow to the input connector symbol on the target Action node. This is depicted in the image below.

Adding more Action nodes

Should you wish to execute another Trigger Action after an existing Action, add another Action node and link it to the previous node by clicking on either the Success or Failure outputs of the first node, and dragging an dropping the link (dashed line) to the Execute input of the second node. You may add more nodes as you wish and then link them in a daisy-chain fashion.

To change the order of execution of existing Action nodes, delete all affected links (by selecting the link then clicking the Delete button, or by selecting the link then right-clicking and selecting Delete from the list) and then reattach new links that reflect the desired order of execution. You may also rearrange the nodes if you wish, as previously described. In the image shown below, when the Trigger event occurs, the workflow will start by running the Trading Partner File Upload Action. If that Action is successful, the Move File Action executes next.

In addition to linking subsequent Actions to the Success of a prior Action, nodes can also be linked using the Failure output. Typically this is done for error handling purposes. For example, if an Action fails, you may want MFT Server to send an email to a specified server admin (using the Send Email Action) or log the failure to a file (using the Append File Action), or perhaps do both. Performing both Failure Actions, Append File and Send Email, is what is depicted in the image below. Whenever you have two or more Actions linked to an output (in this case Failure), the Actions (should a failure occur) run asynchronously. As discussed in the Trigger lifecycle section, you can assign more than one Action to any single output, which also includes the Workflow outputs.

Finishing a Trigger

You may link one or more Action nodes the Workflow node's Finish output. This Action is executed regardless of whether all Actions linked to Start execute successfully.

Trigger Success and Failure

The Success and Failure outputs of the Workflow node lets you specify global success/failure workflows for the entire Trigger. For example, if any Trigger Action fails, Action(s) in the Workflow node's Failure output will execute. On the other hand, if all Actions execute successfully, Action(s) in the Workflow node's Success output will execute.

If an Action in the Workflow node's Failure or Success output fails execution, then the Trigger Error event is raised as normal. If this happens, the Action(s) in the Workflow node's Failure output will not be executed again. This is to prevent an infinite loop.

When rerunning a Trigger via the Rerun button in the AUTOMATION > Triggers > History tab, it is possible for there to be multiple points of failure; e.g. a failure in one of the Workflow > Start Actions, plus a failure in one of the Workflow > Finish Actions. When rerunning a Trigger using the Rerun from point of failure option, make sure that you always run from the first point of failure.

See also

Event types

Action types
Function types

Defining custom action types