It seems like in order to use MS Graph Email Poller for different inboxes, I would want to set up different schemas in the MySQL Appian Cloud database (so the tables APP_MAIL_POLLER and APP_MAIL_POLLER_DOC that the plug in uses would have a unique table per inbox). Are there any drawbacks to this approach that someone might be aware of?
We have the SCS and everything set up correctly (except for a permissions error on the secret element which is out of date).
The documentation of that plug in mentions that the jndi should be set up as a datasource in admin console. Does that mean that it treats the connection as 'accessing it from external code'? Or, can we reference it in a different way?
Thanks for any insight!
Discussion posts and replies are publicly visible
Creating separate schemas/tables per inbox is not recommended. It adds maintenance overhead and can complicate upgrades. Instead, use a single schema and differentiate inboxes using identifiers (e.g., mailbox ID) in the same tables.
Regarding JNDI — yes, it means the plugin accesses the database as an external datasource configured in the Admin Console. You generally don’t reference it directly in Appian objects; it’s handled internally by the plugin via that datasource.
Thanks,
If I had access to the source for the Appian written plug in (MS Graph Email Poller), then I could differentiate that. But the tables that will be presumably filled upon extraction do not seem to have a field to pass through the inbox being monitored (see below). Parsing the 'To' addresses might work, but would be problematic if an addressee was in > 1 inbox that was monitored, right?
Documentation for MS Graph Email Poller (and required inputs for the plugin) need the JNDI definition. My question on that is, can I point back to the cloud instance MariaDB or must I have some external source like an AWS RDS instance or a database external to our Appian cloud instance?
As in the another response explains, the best practice is keep the message info in APP_MAIL_POLLER and APP_MAIL_POLLER_DOC. You won't need all the columns, so you can follow this approach:
1. Parametrize a table where you have for every mailbox their configuration (generate email flag, exception/processed folder name, etc)
2. In that table, you can also define another mailbox in case a error happens when Appian runs the msgraph mail poller smart service and the constant name you want to trigger once you receive a new mail in that specific mailbox
3. Create a batch process that runs every 5 mins, for example, that get all the mailbox parametrized in database and run a process (you must trigger this process one by one, not all at the same time). This process will contain the smart service and if returns an error, you'll send an email to the mailbox parametrized in step3. If not, you'll trigger the process parametrized in also step3:
4. The idMails are easily obtained because the smart service only returns the number of mail received, so you can query in APP_MAIL_POLLER the last N mails received in Appian. Once you get the idMails, you can get all the columns you need and "copy and paste" in your business table. Finally, remove the record in the original tables (APP_MAIL_POLLER and APP_MAIL_POLLER_DOC)