MSGraph Email Poller

Overview

Need to poll emails from your Exchange server? This smart service can be used in a poller process and extract the data from the Microsoft Exchange server. Messages are stored in the Appian Document System, as well as the attachments. Meta data is stored in a database table for further processing.

This plug-in provides an alternative to sending emails to an Appian process model when inbound email integration is requested. Instead of the email being forwarded to Appian, this plug-in reads the emails directly from the Exchange mailbox using the MS Graph API as described below:

  • Reads the mailbox using the MS Graph API
  • Convert the email to an EML file stored as an Appian document; Item attachments (calendar invites, messages) are kept in the eml file, File attachments removed from it and stored separately in the document management system.
  • Store all email file attachments as separate Appian documents
  • Store all email metadata (subject, author, recipients, etc...) into a set of tables in the database

Key Features & Functionality

All information how to deploy, configure and use the smart service is in the 'MS Graph Mail Poller.pdf' document in the downloaded zip. Extract the files in the ZIP and follow the instructions in the document.

Anonymous
Parents
  • We have been using this plug-in for many months for one app and have just added it to another application to process emails from a different email account.  Both apps are using the same APP_MAIL_POLLER and APP_MAIL_POLLER_DOC tables. Because of the amount of body text and body html stored, are there any concerns around these tables growing too large and eventually causing performance issues and if so, is there a recommendation for archiving or purging the data?

Comment
  • We have been using this plug-in for many months for one app and have just added it to another application to process emails from a different email account.  Both apps are using the same APP_MAIL_POLLER and APP_MAIL_POLLER_DOC tables. Because of the amount of body text and body html stored, are there any concerns around these tables growing too large and eventually causing performance issues and if so, is there a recommendation for archiving or purging the data?

Children
No Data