Announcement Announcement Module
Collapse
No announcement yet.
Icomming mail adapter: best-practice advice for guaranteed delivery needed Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Icomming mail adapter: best-practice advice for guaranteed delivery needed

    Hi there,

    maybe someone of you has an idea or ideally a best-practice advice for the following problem.

    The short version: How to receive emails with Spring Integration and further process them without loosing any email?

    The long version:

    The emails are machine-to-machine emails, e.g. they contain machine readable information which trigger a downstream process. To simplify things let's say that we need to receive the emails and store them in a database. The problem is that it is not allowed to loose any email, e.g. guaranteed delivery is required. The easiest way to implement this would be the "idempotent receiver" pattern. If we would implement this by hand without SI we would do it in the following way:
    1. Receive email (IMAP or POP3 polling - doesn't matter) - do not mark them as seen or delete them at this point
    2. Store E-Mail in database - ensure with the help of the message id that there are no duplicates (idempotent)
    3. Commit Database
    4. After a successfull DB commit mark message as seen or delete them from mail server

    This will ensure that no message get lost. Either the message will be stored in the DB or it will be received again with the next poll request.

    But as far as I can see this strategy is not supported by the SI implementation of the mail adapters. Both mail adapters (IMAP and POP3) are based on the AbstractMailReceiver class. And this class does the receiving and "mark-as-as-seen"/"delete message" in one step before the message will be processed further downstream.

    Does anyone have an advice for this?
    Would it be feasible to extend the AbstractMailReceiver to support a pseudo-transaction support and enlist with the PlatformTransactionManager?
    Or would it be easier to implement our own "MailReceive & Store in DB" Adapter?

    Any idea or advice is highly appreciated.

    Thanks
    Olli

  • #2
    If you need to delete mail messages conditionally than I guess the best was to do this would be to move them into a separate folder (e.g., PROCESSING) that would signify that the Messages are in process and once the processing on such Message ends the Message could be deleted by another adapter. Unfortunately this functionality is not yet in place but we already have a JIRA request for it https://jira.springsource.org/browse/INT-1819 I am also going t link this post to the JIRA as it describes an interesting use case

    Comment

    Working...
    X