E-mail is de enige integratie waarover elke organisatie al beschikt. Leveranciers sturen er facturen naartoe, formulieren leveren er inzendingen af en machines versturen er meldingen heen. Bij e-mailingest behandel je dat als een interface in plaats van als handwerk: een script maakt verbinding met een postvak, leest wat er is binnengekomen en voert daar een actie op uit.
Het is een oud en onderschat patroon, want het alternatief, elke wederpartij vragen om jouw API te gebruiken, is doorgaans niet haalbaar. In dit artikel lees je waar deze methode geschikt voor is, hoe je haar zo bouwt dat ze betrouwbaar blijft en wanneer een webhook echt de betere keuze is.
Waar e-mailingest via IMAP voor dient
E-mailingest is nuttig wanneer de afzender niet rechtstreeks met je systeem wil of kan integreren.
Documenten van wederpartijen. Facturen, inkooporders, pakbonnen en rekeningoverzichten komen als bijlage binnen van organisaties die nooit een koppeling met jouw systeem zullen bouwen. Vaak bestaat de hele integratie uit een script dat ze op afzender en kenmerk archiveert.
Meldingen van apparatuur. Veel hardware kan alleen e-mail versturen, zoals back-upapparaten, bewakingssystemen en oudere industriële machines. E-mailingest via IMAP biedt ze allemaal één centraal verzamelpunt.
Formulierinzendingen en antwoorden. Hieronder valt elk systeem dat een gestructureerd bericht per e-mail verstuurt, waaronder bouncemeldingen en automatische afwezigheidsberichten waarop je een actie wilt uitvoeren.
Goedkeuring via een antwoord. Wanneer iemand "ja" op een bericht antwoordt, vormt dat een stap in een werkproces. Dat antwoord automatisch lezen is vaak eenvoudiger dan een interface bouwen waarop niemand wil inloggen.
Zo richt je het betrouwbaar in
De technische werking van e-mailingest is niet bijzonder. De betrouwbaarheid komt voort uit een paar belangrijke keuzes.
Geef het proces een eigen postvak. Gebruik geen map in het postvak van iemand anders en deel het postvak niet met een persoon die dezelfde berichten leest. Met een afzonderlijk adres kan niemand de aannames van het script door opruimwerk verbreken. Hier kost dat niets extra, omdat postvakken niet per gebruiker worden afgerekend.
Gebruik inloggegevens die tot deze taak zijn beperkt. Gebruik niet het account van een medewerker. Als de inloggegevens van het script uitlekken of moeten worden vervangen, hoort dat alleen het script te raken.
Verplaats verwerkte berichten en verwijder ze niet. Een map "verwerkt" biedt een controlespoor en maakt het mogelijk om berichten na het herstellen van een fout opnieuw te verwerken. Verwijderen maakt elke vergissing definitief, en vergissingen zullen voorkomen.
Houd rekening met hetzelfde bericht dat twee keer binnenkomt. Nieuwe pogingen, verbroken verbindingen en herverwerking komen allemaal voor. Gebruik het Message-ID als sleutel en sla alles over wat al is gezien. Zo verandert dubbele verwerking van een gegevensprobleem in een bewerking zonder gevolgen.
Maak storingen duidelijk zichtbaar. Een script dat een postvak niet meer leest, blijft onopgemerkt totdat iemand vraagt waar de facturen zijn gebleven. Het moet een melding geven wanneer het niet is uitgevoerd, niet alleen wanneer er een fout optreedt.
Waarom IMAP hiervoor geschikt is
E-mailingest werkt via IMAP, omdat IMAP een echt extern bestandssysteem voor e-mail is en geen eenvoudig downloadprotocol.
Je kunt op de server zoeken, eerst alleen de berichtkoppen ophalen en daarna beslissen of je de inhoud downloadt, berichten tussen mappen verplaatsen en vlaggen instellen, allemaal zonder een volledig postvak binnen te halen. Een script kan daardoor selectief en efficiënt werken. Dat is belangrijk wanneer het postvak een geschiedenis van vele jaren bevat.
Bovendien wordt IMAP overal ondersteund, en dat is het echte voordeel. Elke programmeertaal heeft er een bibliotheek voor, het protocol is niet veranderd op manieren die bestaande implementaties breken en een script dat je vandaag schrijft, werkt over tien jaar nog steeds. Dat is een sterkere garantie dan de meeste leveranciers-API's bieden.
Goed om te weten: het gratis abonnement bevat IMAP, dus een ingestpostvak dat alleen ontvangt, kost helemaal niets. Het kan niet verzenden. Elk proces dat automatisch antwoordt, heeft daarom een betaald abonnement of een eigen SMTP-profiel nodig.
De gebruikskosten
De kosten zijn meestal de verrassing, omdat ze lager zijn dan mensen verwachten.
Een ingestpostvak is een gewoon postvak. Het aantal postvakken wordt door je abonnementsniveau begrensd en ze worden niet afzonderlijk afgerekend. De marginale kosten van een twaalfde ingestadres zijn dus nul. Daardoor is één postvak per bron praktisch in plaats van buitensporig. Wat je werkelijk verbruikt, is ruimte uit de gedeelde opslag en tijd wanneer er iets misgaat.
Vergeleken met platforms die per gebruiker rekenen, verandert dit de architectuurkeuze. Daar wordt e-mailingest vaak in één overbelast adres gepropt, omdat elk nieuw adres geld kost. Het resulterende script moet vervolgens meerdere stromen zonder onderlinge samenhang uit elkaar halen. Hier is de goedkoopste keuze ook de overzichtelijkste.
Wanneer een webhook beter is
Duidelijkheid hierover voorkomt dat je de verkeerde oplossing bouwt.
Biedt de wederpartij een webhook aan, gebruik die dan. Push is beter dan polling voor snelheid, betrouwbaarheid en duidelijkheid: je ontvangt gestructureerde gegevens zodra er iets gebeurt, in plaats van het bij de volgende controle te ontdekken en tekst te moeten ontleden. E-mailingest is het alternatief wanneer zo'n mogelijkheid niet bestaat.
Ook polling heeft een redelijke ondergrens. Elke minuut controleren is prima; elke seconde controleren is misbruik en zal tot snelheidsbeperking leiden. Als je echt realtime verwerking nodig hebt, is e-mail het verkeerde transportmiddel, ongeacht hoe je het leest.
Het ontleden van door mensen geschreven e-mail is bovendien een verloren strijd. Een inkoopordernummer uit een automatisch gegenereerd bericht halen is betrouwbaar. De bedoeling afleiden uit een alinea die iemand zelf heeft geschreven is dat niet. Een werkproces dat daarvan afhankelijk is, levert een constante stroom fouten op die niemand structureel kan oplossen.
Opschalen naar meer dan één postvak
E-mailingest is goed op te schalen. Welke vorm de architectuur krijgt, hangt af van het aantal berichtenstromen.
Voor een klein aantal bronnen is één postvak per bron het duidelijkst. Elk script leest zijn eigen adres en een wijziging aan de ene stroom kan de andere niet beïnvloeden. Omdat het aantal postvakken per abonnementsniveau is begrensd en postvakken niet afzonderlijk worden afgerekend, kosten twintig ingestadressen evenveel als één.
Voor veel bronnen van hetzelfde type werkt één postvak met een catch-all ervoor beter: invoice-acme@ en invoice-globex@ komen op dezelfde plek terecht, terwijl het adres zelf de routeringsinformatie bevat die het script nodig heeft. Dat is dezelfde techniek als een alias per registratie, maar dan voor machines in plaats van leveranciers.
Is het volume werkelijk groot, vergeet dan niet dat de opslagruimte wordt gedeeld. Een ingestpostvak waarin bijlagen zich opstapelen, zal die ruimte verbruiken. Een quotum en een bewaarbeleid horen daarom vanaf het begin bij het ontwerp en mogen geen latere ontdekking zijn. Meer hierover lees je in opslagquota voor postvakken.
