Child pages
  • Mail Trigger Example Workflow
Skip to end of metadata
Go to start of metadata

This example demonstrates how to configure the Mail Trigger to watch a mail server for incoming messages, and how to use the data retrieved by the Mail Trigger later on in the workflow.

This example uses the Web-based Designer to create a configure a workflow. If you are not familiar with using the Web-based Designer, see the quick start guide before proceeding with the example.

Configuring the Mail Trigger

To use the Mail Trigger in the workflow, we'll first need to create and configure the Mail Trigger to watch a server for emails. To get started:

  1. Create a new workflow by opening the Designer in the Operations Console.

  2. Add a Mail Trigger to your workflow by dragging it onto the canvas from the "Notification" section of the "Actions & Triggers" menu.
  3. Double-click the Mail Trigger to display its properties. The properties dialog allows you to configure the Mail Trigger with the information it will need to locate your mail server and pick up mail. Set the following properties, which are required for the Mail Trigger to operate:
    1. Password: The password Flux should use to log in to your mail server.
    2. Server: The network location of the mail server. This can be set to either the host name or the IP address of your server.
    3. Username: The username Flux should use to log in to your mail server.
    4. Protocol: This property is not configurable (although you will notice it marked as required in the Designer). Flux automatically sets the protocol to IMAP.
    5. IMAP Folder: The IMAP folder on the server where Flux should watch for messages. Can be any folder the user has available on the server, including "Inbox".
  4. In addition to the required properties listed above, you will notice some other (optional) properties available to allow additional configuration of the trigger. Although these properties are not required, you can set them to further configure the trigger:
    1. Polling Delay: This is a time expression that specifies how often the trigger should check for new messages on the server. This allows you to conserve resources and improve performance by ensuring that the mail server (and Flux itself) is not accessed too frequently.
    2. Port: The port number Flux should use when accessing the mail server.
    3. Delete Processed Message: if this property is enabled, Flux will automatically delete every email it finds after processing the email. Emails are not immediately deleted when the trigger runs – to delete the email, you must have a flow in the workflow loop back to this trigger (to indicate that processing has completed and we are ready for the next message).
    4. IMAP Folder Copy Destination: If this is set and delete processed message is not enabled, then Flux will automatically move processed emails to this folder location once they are finished processing (that is, once a flow loops back to this trigger).

Mail Trigger Performance in a Looping Workflow

If neither the delete processed message or the IMAP folder copy destination is set, the Mail Trigger will repeatedly pick up the first message in the specified folder (as the trigger has no mechanism to distinguish between mails it has not already picked up and mails that it has). This can cause high CPU / memory usage or performance problems if your workflow contains a loop back to the Mail Trigger, as the trigger will repeatedly fire (very quickly) on the same message over and over. For this reason, we strongly suggest setting one of those two properties.

Configure these settings as necessary to locate your mail server and, optionally, folder. Once you are finished, your trigger properties should look something like:

That's it! Your Mail Trigger is now configured and ready to use.

Viewing the Mail Trigger's Results

If you've already tried to run the Mail Trigger created above, you'll notice that you have no easy way of viewing what message (if any) was picked up. We'll need to configure the workflow to print more information about the message.

To do that, we'll use a Console Action to display all of the information to the engine's standard output. Follow these steps to set that up:

  1. Add a Console Action to your workflow.
  2. Add a flow from the Mail Trigger to the Console Action.
  3. Right-click the newly created flow. Select "Flow Properties" from the list of options, then locate the "Runtime Data Map" option. Click "Add" next to this option to add a new runtime data map. We'll use the data map to pass information from the mail trigger to the Console Action where it can be printed.
  4. In the "Runtime Data Map Editor" that appears, click "Add Data Mapping". Make sure both select boxes have "Flow Context" selected, then enter RESULT.subject in the text field on the top and subject in the field on the bottom. This will map the "subject" result property of the Mail Trigger to a new flow context variable called "subject". For a complete list of result properties available for mapping, see Mail Trigger.

  5. Click "Save" in the "Runtime Data Map Editor" to save your changes, then "OK" in the "Flow Properties" box.
  6. Open the Console Action's properties and set the "Message" field to ${subject}. This Variable Substitution syntax allows the Console Action to print the value of the "subject" flow context variable that was mapped in step 4.

That's it! Now just run the workflow by clicking "Export to Engine" in the lower right-hand corner of the Designer. If you look at the engine's standard output now, you'll see a subject line printed from the first email Flux located in your IMAP folder.

Once you're confident that the Mail Trigger is configured correctly, you can add a flow back to the Mail Trigger from the Console Action as well – this loop will allow the Mail Trigger to finish processing the previous email (assuming one of the delete processed message or IMAP folder copy destination properties was set), then pick up the next message and process that as well.

  • No labels