דואר אלקטרוני הוא אמצעי השילוב היחיד שכבר קיים בכל ארגון. ספקים שולחים אליו חשבוניות, טפסים מעבירים אליו את הנתונים שהוזנו בהם ומכונות שולחות אליו התראות. קליטת דואר מתייחסת אליו כממשק ולא כמטלה: סקריפט מתחבר לתיבה, קורא את מה שהגיע ומבצע את הפעולה הנדרשת.
זו תבנית ותיקה שאינה זוכה להערכה מספקת, משום שהחלופה, לבקש מכל צד עסקי לאמץ את ה-API שלכם, בדרך כלל אינה אפשרית. בעמוד הזה נסביר לאילו שימושים השיטה מתאימה, איך לבנות אותה כך שלא תישבר ומתי webhook הוא באמת התשובה הטובה יותר.
למה מתאימה קליטת דואר דרך IMAP
קליטת דואר מצדיקה את מקומה בכל מצב שבו השולח אינו רוצה או אינו יכול להשתלב ישירות במערכת שלכם.
מסמכים מצדדים עסקיים. חשבוניות, הזמנות רכש, תעודות משלוח ודפי חשבון מגיעים כקבצים מצורפים מארגונים שלעולם לא יפתחו שילוב עם המערכת שלכם. לעיתים כל השילוב מסתכם בסקריפט שמתייק אותם לפי השולח ומספר האסמכתה.
התראות מציוד. התקני גיבוי, מערכות ניטור וציוד תעשייתי ישן הם דוגמאות לחומרה רבה שמסוגלת לשלוח דואר ותו לא. קליטת דואר דרך IMAP מספקת לכולם נקודת איסוף אחת.
נתונים מטפסים ותשובות. כל מערכת ששולחת אליכם הודעה מובנית, לרבות הודעות החזרה ותשובות אוטומטיות על היעדרות שברצונכם לפעול לפיהן.
אישור באמצעות תשובה. אדם שמשיב "כן" להודעה מבצע שלב בתהליך עבודה, ולעיתים קרובות קל יותר לקרוא את התשובה בתוכנה מאשר לבנות ממשק שאיש אינו רוצה להתחבר אליו.
הגדרה שתמשיך לעבוד
המנגנון של קליטת דואר אינו יוצא דופן. העמידות מגיעה מכמה החלטות חשובות.
הקצו לתהליך תיבה משלו. אל תשתמשו בתיקייה בתוך תיבה של אדם אחר ואל תשתפו את התיבה עם אדם שקורא את אותן הודעות. כתובת ייעודית מבטיחה שאדם שמסדר את הדואר לא ישבור את ההנחות שעליהן הסקריפט מסתמך. כאן היא גם אינה עולה דבר, משום שאין חיוב לפי משתמש.
השתמשו בפרטי גישה שמוגבלים למשימה. אל תשתמשו בפרטי ההתחברות של אדם. אם פרטי הגישה של הסקריפט דולפים או דורשים החלפה, הדבר צריך להשפיע על הסקריפט בלבד.
העבירו הודעות שטופלו ואל תמחקו אותן. תיקייה בשם "טופלו" מספקת יומן ביקורת ואפשרות לעבד הודעות מחדש לאחר תקלה. מחיקה הופכת כל טעות לקבועה, וטעויות אכן יקרו.
טפלו באפשרות שאותה הודעה תגיע פעמיים. ניסיונות חוזרים, חיבורים מחדש ועיבוד מחדש קורים בפועל. שימוש ב-Message-ID כמפתח ודילוג על הודעה שכבר נראתה הופכים עיבוד כפול מבעיית נתונים לפעולה שאינה משנה דבר.
ודאו שכשל אינו עובר בשקט. איש אינו מבחין בסקריפט שהפסיק לקרוא תיבה עד שמישהו שואל לאן נעלמו החשבוניות. עליו להתריע כאשר לא הופעל, ולא רק כאשר מתרחשת שגיאה.
למה IMAP מתאים לכך
קליטת דואר פועלת דרך IMAP משום ש-IMAP הוא מערכת קבצים מרוחקת אמיתית לדואר ולא פרוטוקול הורדה.
אפשר לחפש בצד השרת, למשוך רק את הכותרות לפני שמחליטים אם להביא את גוף ההודעה, להעביר הודעות בין תיקיות ולהגדיר דגלים, וכל זאת בלי להוריד תיבת דואר שלמה. כך הסקריפט יכול לפעול באופן בררני ובעלות נמוכה, וזה חשוב כאשר התיבה מכילה היסטוריה של שנים.
הוא גם נתמך בכל מקום, וזו הסיבה המכריעה. לכל שפת תכנות יש ספרייה, הפרוטוקול לא השתנה בדרכים ששוברות יישומים, וסקריפט שנכתב היום עדיין יעבוד בעוד עשור. זו הבטחה חזקה מזו שמציעים רוב ממשקי ה-API של ספקים.
כדאי לדעת: החבילה החינמית כוללת IMAP, ולכן תיבת קליטה שמשמשת לקבלה בלבד אינה עולה דבר. היא אינה יכולה לשלוח, ולכן כל מערכת שמשיבה באמצעות תוכנה זקוקה לחבילה בתשלום או לפרופיל SMTP משלה.
עלות ההפעלה
העלות בדרך כלל מפתיעה, משום שהיא נמוכה מכפי שאנשים מניחים.
תיבת קליטה היא תיבת דואר רגילה, ומספר התיבות מוגבל לפי דרגת החבילה במקום חיוב נפרד לכל תיבה. לכן העלות השולית של הוספת כתובת קליטה מספר שתים עשרה היא אפס, וזה מה שהופך תיבה נפרדת לכל מקור לאפשרות מעשית במקום לבזבוז. המשאבים שאתם צורכים בפועל הם נפח מהאחסון המשותף וזמן טיפול כשמשהו מתקלקל.
הדבר משנה את שיקולי התכנון לעומת פלטפורמות שגובות לפי משתמש. שם נוטים לדחוס את כל תהליכי קליטת הדואר לכתובת עמוסה אחת, משום שכל כתובת חדשה עולה כסף, והסקריפט נאלץ להפריד בין כמה זרמים שאינם קשורים זה לזה. כאן האפשרות הזולה היא גם הנקייה.
מתי webhook עדיף
בהירות בנקודה הזאת מונעת בנייה של הפתרון הלא נכון.
אם הצד העסקי מציע webhook, השתמשו בו. דחיפה עדיפה על תשאול מבחינת זמן תגובה, אמינות ובהירות. אתם מקבלים מטען מובנה ברגע שמשהו קורה, במקום לגלות אותו בתשאול הבא ולנתח טקסט חופשי. קליטת דואר היא פתרון חלופי למקרים שבהם אפשרות כזאת אינה קיימת.
גם לתשאול יש גבול תחתון. בדיקה בכל דקה היא סבירה, אך בדיקה בכל שנייה היא שימוש לרעה ותוגבל בקצב. אם הדרישה שלכם היא באמת זמן אמת, דואר אלקטרוני הוא אמצעי התעבורה הלא נכון בלי קשר לאופן הקריאה.
גם ניתוח דואר שנכתב בידי אדם הוא מאבק אבוד. אפשר לחלץ באופן אמין מספר הזמנת רכש מהודעה שנוצרה במכונה, אך אי אפשר לחלץ באותה אמינות כוונה מפסקה שאדם כתב. תהליך עבודה שתלוי בכך ייצור זרם קבוע של כשלים שאיש אינו יכול למנוע לחלוטין.
התרחבות מעבר לתיבה אחת
קליטת דואר מתרחבת היטב, והמבנה המתאים תלוי במספר הזרמים שלכם.
למספר קטן של מקורות, תיבה אחת לכל מקור היא הפתרון הברור ביותר. כל סקריפט קורא את הכתובת שלו, ושינוי באחד אינו יכול להשפיע על אחר. מאחר שמספר התיבות מוגבל לפי דרגת החבילה ולא מחויב בנפרד, עשרים כתובות קליטה עולות כמו כתובת אחת.
למקורות רבים מאותו סוג, תיבה אחת עם catch-all לפניה עובדת טוב יותר. הודעות אל invoice-acme@ ואל invoice-globex@ מגיעות לאותו מקום, והכתובת עצמה נושאת את פרטי הניתוב שהסקריפט צריך. זו אותה טכניקה כמו כינוי דואר לכל הרשמה, כשהיא משמשת למכונות במקום לספקים.
כשהנפח גדול באמת, זכרו שנפח האחסון משותף. תיבת קליטה שצוברת קבצים מצורפים תצרוך אותו, ולכן מכסה ומדיניות שמירה צריכות להיות חלק מהתכנון ולא דבר שמגלים בדיעבד. הנושא מוסבר במדריך מכסות אחסון לתיבות דואר.
