Mail Listener: multiple inboxes Follow

This article describes how to listen for mail in multiple email accounts - it assumes you're already familiar with setting up and working with one listener.

For instructions on setting up an IMAP listener, please see the following articles:
Gmail accounts: https://auraplayer.zendesk.com/hc/en-us/articles/8377976678295
Office 365 accounts: https://auraplayer.zendesk.com/hc/en-us/articles/10990322241559

Configuring multiple listeners

Open the mail settings dialog by opening your ServiceManager -> Admin -> Mail:

The left side of the dialog will always display the mail sender (SMTP) on top, and a list of listeners (IMAP) below it. Click on a listener to edit it, or on the + button to add a new listener.

The ServiceManager supports 1 mail sender, and up to 40 mail listeners (you are encouraged to keep the amount of listeners to a minimum).

After clicking on the 'Save' button, ALL listeners will reconnect.

Connection status

Next to each listener name, an icon will indicate the live connection status:
(the status is refreshed every 2 seconds when the dialog is open)

Green - Connected, Yellow - Connecting/reconnecting, Red - Disconnected/exhausted. 

If a connection is lost, the status will remain Connecting/reconnecting until all reconnection attempts have failed - and then turn Disconnected/exhausted (exhausted = all reconnection attempts have failed).

Email Trigger: mapping to a listener (and refering to the listener)

In the Automation->Triggers screen, you may limit your triggers to a specific mail listener.
Open a trigger, and in the "To/Listener" filter, type in (or select from the dropdown) your listener:

In the "Input" section, you can pass the listener to the RPA by using ${listener}.

•  ${to} refers to the whole To/Recipients line of the email (which could be multiple addresses separated via comma), ${listener} refers to the email address in which the ServiceManager received the email.

After saving the trigger, you will see the listener filter in the triggers table as well:

Throttling RPA execution

Some RPAs might be resource-heavy or time consuming, and therefore you might want to limit the rate of RPA execution:

1. Any RPA triggered by an Email will be added to an execution queue.
2. A worker thread will grab a RPA from the queue and execute it.

In other words, 10 worker threads = up to 10 RPA can be executed in parallel.

You may control the amount of worker threads in Admin->System Properties:

• RPA_MAIL_EXECUTOR_CORE_POOL_SIZE - Amount of workers that will always be running and ready.
• RPA_MAIL_EXECUTOR_MAX_POOL_SIZE - Max amout of workers.
• RPA_MAIL_EXECUTOR_IDLE_TIMEOUT_SECONDS - Any amount of idle workers above core-size will be terminated after this amount of seconds.

All Email RPAs go through the same queue - there is no separation/queueing per RPA.

These settings will NOT affect Scheduled RPAs, RPA apps, nor the RPA tester - they are never queued.

Logging: monitoring receival of emails 

In the Log Viewer (Admin->View Log), select the "Mail Listener" log (leftmost dropdown marked in red).

This will open a dedicated log, with an extra 'Listener' column (highlighted in yellow).
You may filter the log by the listener column by using the dropdown marked in blue:

The Mail Listener log show when the listener connects/reconnects and when a new message is received:

Once a message has been queued, the logging will continue in the Main log.

Debugging: Threads screen

In Admin->Threads, select the "Mail Threads" filter in order to focus on mail-related information.
Each listener should have 2 threads (3 threads when actively reading messages).

In this screen you'll also find an indicator of how many RPAs are waiting in the queue for execution:

Notes

• A delay of a few seconds up to a couple of minutes is reasonable before an email is received by the ServiceManager.
• If you experience significantly longer delays or no new emails appear until the next reconnect, consider decreasing IMAP_MAIL_LISTENER_NOOP_FREQUENCY_MIN - making the reconnections more frequent.
• Avoid sending one email to mutiple listeners - this will result in the email being processed multiple times.