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
  • Hello 

    We updated MS Graph Email Poller to the latest version v4.0.0.  On some occasions, the node returns the error "Error writing mail to database". Checking the logs, we can see the following:

    "java.sql.SQLIntegrityConstraintViolationException: (conn=102596) Duplicate entry '<!&!YYYYYYY+...' for key 'UNIQUE_MESSAGE_ID'"

    So, we assume that the plugin read an email that was previously inserted in DB.
    The question is, is the email that it tries to insert, really identical to the one that already exists in DB (body, subject, attachments, recipients, etc...)?

    We have the doubt because we do not know how the 'UNIQUE_MESSAGE_ID' field is formed.

    Thank you very much,

    Belén

  • Hi Belén,

    The UNIQUE_MESSAGE_ID KEY refers to the MESSAGE_ID being unique. The MESSAGE_ID comes from the '

    internetMessageId' part of the message. According the MSGraph specs, this is 'The message ID in the format specified by RFC2822'
  • This is not a poller specific thing, this is the general specification for the internet message id: it is globally unique. There is (and will not) be any additional checking in the plugin if there is already a message in the database with similar content, other than this unique key on insert. For testing purposes I usually remove this key, as I test with a specific subset of messages to cover a number of use cases.

  • In my case, whether or not to remove the unique key property, depends on what I was asking above.

    Could you make sure that when the node returns the error "java.sql.SQLIntegrityConstraintViolationException: (conn=102596) Duplicate entry '<!&!YYYYYYYYYYY+...' for key 'UNIQUE_MESSAGE_ID'", it is because the message that the node is trying to insert in the database is identical (message body, subject, attachments etc...) to another one that already exists in the database?

    If the answer is yes, then there is no need to remove the unique key property.

    Regards,

    Belén

Comment
  • In my case, whether or not to remove the unique key property, depends on what I was asking above.

    Could you make sure that when the node returns the error "java.sql.SQLIntegrityConstraintViolationException: (conn=102596) Duplicate entry '<!&!YYYYYYYYYYY+...' for key 'UNIQUE_MESSAGE_ID'", it is because the message that the node is trying to insert in the database is identical (message body, subject, attachments etc...) to another one that already exists in the database?

    If the answer is yes, then there is no need to remove the unique key property.

    Regards,

    Belén

Children
  • This is not a poller specific thing, this is the general specification for the internet message id: it is globally unique. There is (and will not) be any additional checking in the plugin if there is already a message in the database with similar content, other than this unique key on insert. For testing purposes I usually remove this key, as I test with a specific subset of messages to cover a number of use cases.