Processing responses from an EmailInput node

The EmailInput node can return different response messages that indicate the success or failure of receiving an email, with or without attachments, from an email server that supports Post Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP).

Before you begin

Ensure that you have developed a message flow with an EmailInput node, as described in Receiving an email.

About this task

The EmailInput node has three output terminals:
  • Failure: The output terminal to which the message is routed if an EmailInput node failure is detected when a message is propagated, or an EmailInput node fails to access the email server. Connect the Failure terminal of this node to another node in the message flow to process errors.
  • Out: The output terminal to which the message is routed if it has been propagated successfully. Connect the Out terminal of this node to another node in the message flow to process the message further, or send the message to an additional destination.
  • Catch: The output terminal to which a message is routed if an exception is thrown downstream and caught by this node. Exceptions are caught only if this terminal is attached.

Procedure

  • Processing successful returns

    When an EmailInput node successfully receives an email, the resulting message is propagated to the Out terminal.

  • Processing downstream message flow exceptions

    If a message flow exception occurs downstream of the Failure terminal in the message flow, a message is routed to the Catch terminal. If you do not have the Retry mechanism property value set to Short and Long Retry on the EmailInput node Retry tab, the current transaction is rolled back.

  • Handling failures in the node
    Any other failures are propagated to the Failure terminal. Possible failures include:
    • A problem retrieving an email message. For example, an inability to communicate with the target email server because of a connection or authentication error. If this occurs, the connection is re attempted when the polling interval expires. Each connection failure occurrence causes an appropriate message in user trace.
    • A problem parsing an email.
    • An internal EmailInput node exception or error is detected before the message is propagated to the Out terminal. For example, a malformed email is received, causing the EmailInput to propagate the message and an exception list to the Failure terminal.
    • The Retry mechanism property value is set to Failure, causing an immediate message to be sent to the Failure terminal.
    • The Retry threshold is not set to 0 and the Short retry interval property value has been exhausted, causing a message to be routed to the failure terminal, and the email being deleted from the email server.
    If the failure terminal is not connected, or an exception occurs down the Failure terminal, or the email message fails and you have not set the Retry mechanism property value to Short and Long Retry, the email is deleted from the email server.

Results

You can use the EmailServer configurable service to change connection details for the EmailInput node. See Changing connection information for the EmailInput node for details about creating, changing, reporting, and deleting an EmailServer configurable service.