קובץ שהגיע במייל צריך לעבור בדרך כלל עוד שתי תחנות: תיקייה שבה אפשר למצוא אותו, ורשומה שאומרת מאיפה הגיע. במדריך הזה מתכננים תרחיש Make ששומר קבצים מצורפים מ־Gmail ב־Google Drive ומתעד אותם ב־Google Sheets. נוסיף מזהה קבוע ומצב טיפול כדי שהרצה חוזרת לא תעלה מחדש פריט שכבר הושלם.
זה מדריך מבוסס תיעוד, עם נתוני תרגול דמיוניים. התרחיש לא הורץ בחשבון Make. שמות המודולים נבדקו בתיעוד ב־4 באוקטובר 2026; צריך לאמת את המיפוי והתוצאה בחשבון ניסוי לפני שימוש אמיתי.
מה להכין לפני החיבור
הכינו חשבון Google לניסוי, תווית Gmail בשם MAKE_TEST, תיקיית Drive פרטית בשם Make attachment practice וגיליון בשם attachment_log. השתמשו רק בקבצים דמיוניים קטנים, ללא פרטי לקוחות. אל תשתפו את התיקייה דרך קישור ציבורי.
בשורה הראשונה בגיליון צרו את העמודות הבאות, בלי תאים ממוזגים:
dedup_key, message_id, attachment_id, original_name, drive_file_id, status, processed_at
המזהים נשמרים כטקסט. אין צורך לשמור את גוף המייל, מספר טלפון או רשימת נמענים. גם שם קובץ עשוי לכלול מידע פרטי, ולכן בדוגמה משתמשים בשמות ניטרליים.
חשבון Make צריך לאפשר את המודולים ואת האחסון הדרושים. החבילה החינמית מוגבלת גם בגודל קובץ; תקרת הקובץ המתועדת היא 5 MB. בתרגול השתמשו בקובצי טקסט קטנים בהרבה. נפח האחסון והמכסה של Google הם מגבלות נפרדות.
שלב 1 בודקים את ההרשאות ומשאירים תזמון כבוי
צרו תרחיש חדש והוסיפו Gmail בגרסה V4. בעת חיבור חשבון Google בדקו איזה חשבון נבחר ואילו הרשאות התבקשו. העבודה כאן דורשת קריאת הודעות וקבצים, כתיבה לתיקיית היעד וכתיבה לגיליון. החיבור עשוי לבקש הרשאות רחבות יותר; אם הן אינן מתאימות, עצרו ובדקו עם מנהל החשבון.
תווית MAKE_TEST מצמצמת מה שהתרחיש מעבד, אך אינה גבול הרשאה של החיבור. אל תוסיפו הרשאות API נוספות, חשבון שירות או מפתחות לצורך הדוגמה. השאירו את התזמון כבוי והתחילו בהרצה ידנית מוגבלת.
שלב 2 מאתרים הודעות ניסוי בלבד
ב־Watch emails בחרו את תווית הניסוי, הודעות עם קבצים מצורפים ומגבלה של הודעה אחת למחזור בניסוי הראשון. בחרו שלא לסמן הודעות כנקראו כדי לא לשנות את אופן הטיפול הידני במייל. כשיש אפשרות לבחור נקודת התחלה, התחילו מרגע הניסוי; לעיבוד דוגמאות קיימות בחרו נקודה שמכסה אותן בלבד.
אל תסתמכו על מצב לא נקרא כדי למנוע כפילויות. משתמש אחר יכול לפתוח הודעה, והרצה חוזרת יכולה לקרוא מידע שכבר הגיע ליעד. ההגנה שלנו תתבסס על זהות ההודעה והקובץ.
שלב 3 מוציאים כל קובץ עם התוכן שלו
הוסיפו List email attachments and media. מפו אליו את Message ID מהשלב הקודם, בחרו קבצים מצורפים והפעילו החזרת תוכן קובץ. בזרימה הזו אין צורך לשמור תמונות חתימה המוטמעות בגוף ההודעה.
אחרי בדיקת דוגמה אחת, הסתכלו בפלט המודול: צריך להיות שם קובץ ותוכן Data שאפשר להעביר להעלאה. בדקו אם המודול החזיר יחידה נפרדת לכל קובץ. אם כן, אין להוסיף Iterator נוסף. רק אם החשבון מחזיר מערך קבצים בתוך יחידה אחת, מוסיפים Iterator על אותו מערך ובודקים שוב את מספר הפריטים.
בחרו מזהה יציב של הקובץ בתוך ההודעה, למשל Attachment ID או Part ID כשהוא נחשף בפלט. אין לבחור את מספר הפעולה או את מיקום הפריט ברשימה. אם לא מוצג מזהה יציב, עצרו את הבנייה לפני העלאות ובדקו כיצד לקבל אותו בגרסת המודול שלכם. שינוי כזה דורש אימות חדש של החיבור; שם הקובץ לבדו אינו חלופה בטוחה.
לפני יצירת המפתח הוסיפו Filter: שם הקובץ, Message ID ומזהה הקובץ קיימים ואינם ריקים. בדקו גם ש־Data זמין להעלאה. קובץ תקין בגודל אפס אינו זהה לשדה Data חסר; אין לפסול אותו רק בגלל גודלו. פריט שנחסם נרשם ברשימת בדיקה ידנית; המסנן אינו יוצר רשומת שגיאה בעצמו.
שלב 4 בונים מפתח שאפשר לחשב שוב
הגדירו טקסט מקור למפתח במודול Tools אחד, ואת הגיבוב שלו במודול Tools נפרד שמגיע אחריו. טקסט המקור מורכב מכינוי קבוע לחשבון, Message ID ומזהה הקובץ, עם מפריד קבוע ביניהם. הכינוי לדוגמה הוא practice01, והוא אינו כתובת מייל. ייחדו אותו לחשבון מקור אחד והקצו כותב אחד למרחב המפתחות הזה. ודאו שהמפריד אינו מופיע באף רכיב; אחרת השתמשו בסריאליזציה חד־משמעית שנבדקה. גיבוב אינו מתקן חיבור טקסט דו־משמעי.
דוגמת מבנה בלבד: practice01|msg_demo_01|att_demo_A
הפעילו sha256 על הטקסט הזה בקידוד ברירת המחדל hex, ושמרו את התוצאה ב־dedup_key. במיפוי האמיתי בוחרים את שדות המודולים; שמות הדוגמה אינם מזהים אמיתיים. אל תחליפו את הכינוי או את המפריד באמצע חיי התרחיש, כי אז אותו קובץ יקבל מפתח אחר.
שתי הודעות שונות עם קובץ בשם report.txt יוצרות שני מפתחות שונים. שתי הרצות על אותו קובץ באותה הודעה אמורות ליצור אותו מפתח. גם שני קבצים באותה הודעה צריכים מזהי קובץ שונים. זו מניעת עיבוד חוזר של אותו מקור, לא זיהוי כל עותק זהה שנשלח במייל אחר.
שלב 5 שומרים מקום לפני העלאה
לפני יצירת המאגר, בדקו את ההקצאה הפנויה בחשבון: לפי תיעוד Make, מסלול Free כולל 1 MB לאחסון Data store, וגודל המאגר המזערי הוא 1 MB. לכן ההקצאה מספיקה למאגר אחד, ולא לכמה מאגרים נפרדים לתרגילי הסדרה במקביל. אם ההקצאה כבר בשימוש, עצרו לפני יצירת מאגר נוסף; אין למחוק נתונים קיימים או להפעיל שדרוג בתשלום רק כדי לבצע את התרגיל.
צרו Data Store לתרגול עם שדות טקסט status, message_id, attachment_id, original_name, drive_file_id ו־updated_at. המפתח של הרשומה הוא dedup_key. בהגדרות התרחיש הפעילו Process data in order כדי למנוע חפיפה בתוך התרחיש הזה.
הוסיפו Check the Existence of a Record על המפתח. אחרי הבדיקה הוסיפו Router עם שני מסלולים. כשלא קיימת רשומה, עוברים ל־Add/Replace a Record עם אותו מפתח, status=reserved ו־Overwrite an existing record כבוי. מלאו גם message_id, attachment_id, original_name ו־updated_at מתוך המיפוי. השאירו drive_file_id ריק בשלב הזה. רק לאחר שהשמירה הצליחה ממשיכים ל־Drive.
כשכבר קיימת רשומה, קוראים אותה עם Get a Record. מצב complete מסיים את מסלול הפריט בלי העלאה ובלי שורה חדשה. כל מצב אחר נשאר לטיפול ידני ואינו נשלח למסלול ההעלאה. אם יצירת הרשומה נכשלה משום שהמפתח כבר קיים, גם אז אין להמשיך ל־Drive.
כדי שסימון reserved לא יתבטל אחרי כשל מאוחר יותר, תכנון זה משתמש ב־Commit after each module. ההגדרה שומרת התקדמות של המודולים התומכים בטרנזקציות בכל שלב, ולכן אין לסמוך אחר כך על ביטול אוטומטי של כל התרחיש. יש לבדוק בניסוי שהרשומה נשארה אחרי כשל מכוון. זהו תנאי לפני הפעלת התזמון.
שלב 6 מעלים ל־Drive ומתעדים
במסלול החדש בלבד הוסיפו Google Drive — Upload a File ובחרו את תיקיית הניסוי במפורש. מפו את Data מהקובץ המצורף. בשם הקובץ השתמשו במפתח ובשם המקורי, למשל dedup_key ואחריו שני קווים תחתונים והשם. השאירו המרת קובץ כבויה כדי לשמר את תוכנו.
לאחר העלאה שהצליחה, עדכנו את רשומת ה־Data Store עם drive_file_id שחזר מהמודול ועם status=uploaded. כעת הוסיפו Google Sheets — Add a Row לגיליון הניסוי. מפו כל ערך לעמודה המתאימה, קבעו status=complete ורשמו זמן עיבוד בפורמט ISO עם אזור זמן. אל תמפו נוסחה או גוף מייל לעמודות הטקסט; כשיש בחירת אופן הכנסת ערכים, בחרו Raw.
בכל Update a Record מפו את אותו dedup_key והשאירו Insert missing record כבוי. רק אחרי שהשורה נוספה, עדכנו גם את הרשומה ב־Data Store ל־complete. אין להוסיף מודול שיתוף קובץ או שליחת מייל. בסוף המסלול צריך להיות קובץ אחד, שורת מעקב אחת ורשומה אחת עבור אותו מפתח.
שלב 7 בודקים הצלחות וחריגים
אלה תוצאות צפויות לתכנון, ולא פלט שנמדד ב־Make:
- הודעה אחת עם קובץ אחד: קובץ אחד ב־Drive ושורה אחת בגיליון.
- אותה הודעה בהרצה חוזרת: אין תוספת קובץ או שורה.
- הודעה אחת עם שני קבצים: שתי רשומות ושתי שורות, עם מפתחות שונים.
- הודעה אחרת עם אותו שם קובץ: קובץ ושורה חדשים, כי המקור שונה.
- הודעה בלי קובץ: סינון ההודעות מונע כניסה למסלול הקבצים.
- שם קובץ או מזהה יציב חסר: הפריט נעצר לבדיקה לפני כתיבה ליעד.
- כשל ב־Sheets אחרי העלאה: הקובץ נשאר, מצב uploaded נשמר, ואין להתחיל העלאה נוספת.
- העלאה הצליחה אך עדכון uploaded נכשל: בודקים את הקובץ בפועל ומשלימים את הרישום.
- השורה נוספה אך עדכון complete נכשל: מחפשים את המפתח בגיליון ומעדכנים רק את המצב.
- הקובץ הראשון נכשל ונשאר קובץ שני באותה הודעה: מאתרים ומטפלים גם בפריט שלא הגיע עדיין למסלול.
השוו ידנית בין המזהים בגיליון, ב־Data Store וב־Drive. בחנו גם מצב שבו כתיבה הסתיימה אבל האישור לא הגיע. מפתח קיים עוזר לעצור ניסיון נוסף; הוא אינו מוכיח לבדו מה קרה ביעד.
איך מתאוששים בלי ליצור עותק נוסף
אם יש מצב reserved, בדקו בהיסטוריה ובתיקיית היעד אם נוצר קובץ לפני שהעדכון נכשל. אם יש uploaded, בדקו קודם אם השורה כבר קיימת בגיליון לפי dedup_key. השלימו רק את החלק החסר ואחר כך תקנו את מצב הרשומה.
אל תמחקו את הרשומה כדי לאפשר הרצה מחדש בלי בדיקה. במצב של timeout, שגיאת הרשאה או מכסת שירות, עצרו את הפריט ופתרו את הסיבה. לא מוסיפים ניסיון חוזר אוטומטי לפעולת העלאה או הוספת שורה כשלא ברור אם כבר בוצעה.
בניסוי הזה השאירו Store incomplete executions כבוי. חברו מסלול שגיאה עם Commit להעלאה, להוספת השורה ולעדכוני המצב שאחריהן. הכוונה היא לשמור התקדמות תומכת־טרנזקציות ולעצור לבירור, בלי להוסיף מסלול Retry לכתיבה. בדקו בניסוי שהכשל אינו משאיר ניסיון חוזר אוטומטי ממתין. עצירת ריצה אינה בהכרח השבתת התזמון.
יומני ריצה עשויים להכיל את הקלט והפלט. עם מידע אמיתי צריך להחליט במפורש על הרשאות צפייה ושמירה. הגדרות סודיות עשויות לצמצם את יכולת האבחון. שמרו גם את מקור הניסוי כדי שאפשר יהיה לשחזר פריטים שלא עובדו אחרי עצירת ריצה.
Commit עוצר את הריצה כולה, כולל פריטים שעדיין לא עובדו. התחילו בדיקת כשל בהודעה עם קובץ אחד, ורק אחריה עברו לכמה קבצים. שמרו ברישום התקלה את מזהי ההודעות והקבצים שנקראו והשוו אותם לפריטים ביעד. Run once רגיל אינו מבטיח שהטריגר יקרא אותם שוב, כי נקודת הקריאה עשויה להתקדם.
כאשר נתוני ההפעלה עדיין זמינים בהיסטוריה, אפשר להשתמש ב־Replay run על אותה הפעלה לאחר התאמה ידנית של הפריטים שכבר נכתבו. הוא מפעיל את הגרסה הנוכחית מהקלט ההיסטורי ועובר שוב גם בצעדים שהצליחו. לכן שומרים את המפתחות, מוודאים שאין ניסיון אחר פעיל ובודקים כל פריט שלא הושלם. אם אין אפשרות שחזור מההיסטוריה, מחזירים רק את הודעות המקור המזוהות דרך תהליך התאוששות מוגבל ומאושר. לא מאפסים את כל היסטוריית התיבה.
מתי אפשר לשקול תזמון
עברו לתזמון רק אחרי שכל מקרי הבדיקה נבדקו, הוגדר אחראי לחריגים ונמדדה צריכת הקרדיטים. קבעו תדירות שמתאימה לצורך, ולא את הקצב המהיר ביותר. שמרו תיעוד קצר של הגרסה, שדות המיפוי ונוהל התאוששות.
התוצאה הרצויה היא תיקייה שאפשר למצוא בה את הקבצים וגיליון שמסביר מה טופל. ההגנה מפני כפילויות נשענת על מזהים קבועים, שמירת מצב ובדיקה של כשל חלקי. בלי שלושתם, תרחיש שנראה תקין בהרצה הראשונה עלול להסתבך דווקא כשצריך להפעיל אותו שוב.
קובצי תרגול להורדה
החבילה כוללת דוגמאות מקוריות שנכתבו ידנית, נתוני דמה ותוצאות צפויות לבדיקה. היא לא הורצה ב־Make, אינה Blueprint לייבוא ואינה מפעילה אוטומציה. השתמשו בה לצד המדריך ובסביבת בדיקה מורשית בלבד.
הורדת חבילת התרגול של Make (ZIP, 6 KB)
לרקע על התאמה לעסק, עלויות ותחזוקה, קראו את סקירת Make לעסקים קטנים.
מקורות
- מרכז העזרה של Make: Data stores
