After reading this question Reasons NOT to use email for system integration
I want to ask the opposite question.
- What is email ingestion?
- When it is OK to use it for process or system integration?
asked Sep 1 '16 at 18:17
-
2Rather than opposite I prefer to think of this question as better. :) – candied_orange Sep 1 '16 at 18:33
Email ingestion is reading emails from an inbox and processing them.
It is used to achieve a degree of automation between two companies, where neither company wants to go through the time and expense of publishing and consuming a first-class API like a REST service.
It is suitable:
When the communication is not critical, or can be retried (since email is not guaranteed delivery).
When the communication is of a "document-centric" nature.
When the chunk of data being sent is relatively large and the number of messages over time is relatively small.
There's lots of things you can do with emails.
You can put a chunk of JSON or XML in them for a machine to uptake.
You can put a GUID in the email address that steers the email to a particular record in a database.
You can extract the attachments and put them in a document system, etc.
A simple example of such intake is used by Trello. You can send an email to Trello with a specifically-crafted email address, and it will create a new Trello card in the Trello Board you specify, containing the email body as the content of the Trello card.
answered Sep 1 '16 at 18:33
-
I don't know how to tell Trello to show me an english language version of its site (it detects my OS is in spanish and decides to give me a site in spanish with no way to change to the english version), but it states that "all data is sent thru a SSL/HTTPS conection, the same encryption technology used by banks". So it seems to be a way to communicate securely over email? – Tulains Córdova Sep 1 '16 at 18:45
-
I've known of systems for playing chess where everything is via email thru a central computer. It validates moves, send notifications including a picture of the positions of the pieces on the board after the move. You send your move as commands thru email. – Tulains Córdova Sep 1 '16 at 18:51
What is it ?
The common sense of ingestion is the act to take in something for or as if for digestion. If extended to systems, it means take into the system to process it.
This article explains more precisely that data-ingestion is to bring data into the system and prepare it for processing. It is the step after data discovery and before effective processing. Hence email-ingestion is data ingestion from an email source.
When to use it ?
There are certainly plenty of cases where email-ingestion is a sine-qua-non need, such as for example: CRM systems, text mining, email bots, document filing systems, email filtering, etc...
I'd also add established email exchange formats such as iCalendar and vCard, as most PIM/calendar applications nowadays use routinely email to send these automatically
I think email source is only a questionable idea if used for processing structured data:
- that is sensitive to input quality (e.g. expected from a web form, or expected to be controlled by a front-end), because the inbox might receive invalid data and even forged data;
- with high volume, when the mailbox is misused as a substitute for a message queue (that could scale much better and balance work effectively between multiple readers).
I see no reason not to use email in the other cases.
-
I've known of systems for playing chess where everything is via email thru a central computer. It validates moves, send notifications including a picture of the positions of the pieces on the board after the move. You send your move as commands thru email. – Tulains Córdova Sep 1 '16 at 18:51
-
You say "You send your move as commands thru email." but aren't CRM systems and ex mining text oriented? – Tulains Córdova Sep 1 '16 at 18:54
-
@TulainsCórdova i'd put this chess example in the email-bot category: you receive emails you know are of human origin. So it's ok: You expect a commonly used algebraic notation, but you're aware that user could make typos. You can check consistency of commands. May be you could even provide for advanced parsing (e.g.recognize "knight","white" as known departure position). This is very different from receiving something expected from an automated system. JSON or XML commands would not be good candidates. – Christophe Sep 1 '16 at 19:09
-
@TulainsCórdova I've edited to try to better express the limited exclusions. – Christophe Sep 1 '16 at 19:38
