מה זה Code by Zapier?

זו פעולה מובנית בזאפייר שמריצה קטע קצר של JavaScript או Python כשלב אחד בתוך Zap. היא מקבלת ערכים שממופים משלבים קודמים כקלטים ומחזירה ערכים שהשלבים הבאים יכולים להשתמש בהם. היא קיימת כפתח מילוט להמרות שה-Formatter המובנה ופעולות האפליקציות של זאפייר לא יכולים לבטא, והיא רצה בסביבת ארגז חול עם פסק זמן קצר.

אפשר להתקין חבילות npm או pip ב-Code by Zapier?

לא, לא באופן שרירותי. הסביבה היא ארגז חול ומספקת רק את תכונות השפה המובנות וסט מוגבל של יכולות זמינות, כולל דרכים סטנדרטיות לבצע בקשות HTTP. אם הלוגיקה שלכם באמת דורשת ספריית צד שלישי, זה אחד הסימנים הברורים ביותר להוציא אותה מה-Zap ולפונקציה קטנה שפרוסה וה-Zap קורא לה ב-webhook. בדקו את התיעוד העדכני של זאפייר למה בדיוק זמין, כי זה משתנה עם הזמן.

למה המספרים שלי מגיעים כטקסט?

כי זאפייר מעביר את כל ערכי הקלט הממופים לשלב ה-Code כמחרוזות, בלי קשר לסוג המקורי שלהם. זה אחד המקורות הנפוצים ביותר להתנהגות מבלבלת - אריתמטיקה משרשרת בשקט במקום לחבר, והשוואות מתנהגות בצורה לא צפויה. המירו כל קלט במפורש בראש הקטע לפני שימוש, ואל תסמכו על המרת טיפוסים משתמעת שתעשה את הדבר הנכון.

איך גורמים לשאר ה-Zap לרוץ פעם אחת לכל פריט ברשימה?

החזירו מערך של אובייקטים משלב ה-Code במקום אובייקט יחיד. זאפייר מפרש מערך כמספר פריטים ומריץ את השלבים הנותרים פעם אחת לכל אחד. התנהגות הפיצול הזו היא אחת הסיבות החזקות באמת להשתמש בשלב Code, כי קשה לבטא אותה אחרת בזאפייר. שימו לב לצריכת משימות - רשימה של מאתיים פריטים אומרת מאתיים הרצות של כל שלב שאחרי.

מתי להחליף שלב Code בשירות אמיתי?

כשאחד מאלה נכון: הקטע ארוך מבערך מסך אחד, אתם רוצים לכתוב לו בדיקה, שני Zaps או יותר צריכים את אותה לוגיקה, הוא צריך חבילה לא זמינה, הוא מתקרב לפסק הזמן, או שמישהו מלבד הכותב צריך לשנות אותו. ההגירה קטנה - פרסו את הלוגיקה כפונקציית HTTP והחליפו את שלב ה-Code ב-webhook מסוג POST. ה-Zap שומר על הטריגר, המסננים והפעולות; רק החשיבה עוברת החוצה.

Code by Zapier: מה זה, מתי להשתמש, ומתי להפסיק

Code by Zapier הוא פתח המילוט שהופך Zap ליכולתי בכל דבר - וגם השלב שהופך בשקט את האוטומציה שלכם לתוכנה לא מתועדת. מה הוא באמת יכול, אילו דפוסים שווים, ומה הסימן שגדלתם מעבר לו.

כל פלטפורמת נו-קוד צריכה בסופו של דבר פתח מילוט, ובזאפייר הוא נקרא Code by Zapier. זו פעולה מובנית שמריצה קטע קצר של JavaScript או Python כשלב אחד ב-Zap, מקבלת ערכים משלבים קודמים ומחזירה ערכים לשלבים הבאים.

הוא באמת שימושי והוא גם המקור הנפוץ ביותר לאוטומציות שאף אחד לא יכול לתחזק. שווה להבין את שניהם לפני שמושיטים אליו יד.

איך זה עובד

מוסיפים שלב Code, בוחרים JavaScript או Python, וממפים שדות משלבים קודמים לקלטים בעלי שם. בתוך הקטע הם מגיעים כמילון של ערכים - וחשוב, הם מגיעים כמחרוזות, ולכן מספר משלב קודם צריך המרה.

מחזירים נתונים על ידי השמה לאובייקט פלט. החזירו אובייקט אחד והשלבים הבאים רואים פריט אחד; החזירו מערך של אובייקטים וזאפייר מתייחס לזה כאל מספר פריטים, ומריצה את שאר ה-Zap פעם אחת לכל פריט.

הסביבה היא ארגז חול. יש פסק זמן קצר לביצוע, בקשות רשת אפשריות דרך מנגנוני fetch או HTTP הסטנדרטיים, ואי אפשר להתקין חבילות שרירותיות. התיעוד של זאפייר הוא הסמכות למגבלות הנוכחיות ולמה שזמין - בדקו אותו ואל תסמכו על מדריך כלשהו, כולל זה, למספרים מדויקים.

שלושת השימושים הטובים

1. עיצוב מחדש של נתונים

המקרה הנפוץ והלגיטימי ביותר. API מחזיר מבנה מקונן והשלב הבא צריך שלושה שדות שטוחים. תאריך מגיע בפורמט אחד וצריך אחר. מחרוזת מופרדת בפסיקים צריכה להפוך לערכים נפרדים. ה-Formatter המובנה של זאפייר מטפל בהרבה מאלה, אבל לא במסורבלים, ושלב Code של ארבע שורות ברור יותר משרשרת של שישה שלבי Formatter.

2. ניקוי ואימות קלט

חיתוך רווחים, נרמול מספרי טלפון לפורמט אחיד, המרת אימיילים לאותיות קטנות, הסרת התווים ששוברים מערכת במורד הזרם. זה לא זוהר וזה מונע חלק גדול מהכשלים שאחרת מופיעים כשגיאות מסתוריות שלושה שלבים אחר כך.

3. פיצול לרבים

טריגר אחד מייצר רשימה - שורות בהזמנה, רשומות ב-payload, נמענים בקבוצה - ואתם צריכים ששאר ה-Zap ירוץ פעם אחת לכל איבר. החזרת מערך משלב Code היא הדרך הנקייה לעשות את זה, וקשה לבטא את זה אחרת.

איפה זה משתבש

הלוגיקה העסקית חיה שם ולא בשום מקום אחר. חוק התמחור, בדיקת הזכאות, החלטת הניתוב - מקודדים בקטע בתוך Zap, בלתי נראים לכל מי שלא פותח את השלב הספציפי הזה, בלי היסטוריית גרסאות שהייתם מזהים ככזו ובלי דרך לבדוק חוץ מלהפעיל את ה-Zap.

שכפול. אותן עשרים שורות מודבקות בארבעה Zaps. אחר כך אחד מהם מתוקן והשלושה האחרים לא, ועכשיו ההתנהגות תלויה באיזה מסלול רשומה עברה.

עבודה ארוכה. שלב Code הוא לא המקום ללולאה על אלף רשומות או להמתנה ל-API איטי. הוא ייתקל בפסק הזמן, ומצב הכשל הוא פעולה שהושלמה חלקית.

סודות בתוך הקטע. מפתחות API מודבקים ישירות בקוד, גלויים לכל מי שיש לו גישה ל-Zap, ובלתי אפשריים להחלפה שיטתית.

הסימנים שגדלתם מעבר לו

כל אחד מאלה אומר שהגיע הזמן להוציא את הלוגיקה החוצה:

הקטע ארוך מבערך מסך אחד.
אתם רוצים לכתוב לו בדיקה.
שני Zaps או יותר צריכים את אותה לוגיקה.
הוא צריך חבילה שלא זמינה.
הוא מתקרב באופן קבוע לפסק הזמן.
מישהו מלבד הכותב צריך לשנות אותו.

מה לעשות במקום

הצעד הטבעי הבא הוא לא "לבנות הכל מחדש כקוד". הוא להוציא את החלק האחד הזה ולשמור את ה-Zap:

פרסו את הלוגיקה כפונקציית HTTP קטנה - פונקציה serverless או שירות זעיר, מה שכבר יש לכם איפה להריץ.
החליפו את שלב ה-Code ב-Webhooks by Zapier מסוג POST לנקודת הקצה הזו.
ה-Zap שומר על הטריגר, המסננים והפעולות שלו. רק החשיבה עוברת.

מיד מקבלים ניהול גרסאות, בדיקות, טיפול שגיאות אמיתי, ניהול סודות תקין, ושימוש חוזר בכל Zap שצריך את זה. ה-Zap נשאר קריא כי החלק המסובך נמצא עכשיו מאחורי נקודת קצה עם שם ולא בתוך תיבת טקסט.

המסלול החלופי הוא להעביר את כל התהליך לפלטפורמה שבה קוד הוא אזרח מדרגה ראשונה - n8n בפרט מאפשר לכתוב function nodes בתהליך שאפשר לארח בעצמכם ולנהל בגרסאות. זו החלטה גדולה יותר ושווה לקבל אותה במכוון ולא בהצטברות.

הרגלים מעשיים

תעדו את הכוונה בראש. שתי שורות שאומרות בשביל מה השלב הזה חוסכות לבא אחריכם עשרים דקות.
המירו קלטים במפורש. הכל מגיע כמחרוזת. אל תניחו כלום.
תיכשלו בקול. לזרוק שגיאה עדיף מלהחזיר פלט ריק - Zap שמייצר בשקט כלום קשה בהרבה לניפוי משגיאה גלויה.
לעולם אל תדביקו סוד. השתמשו באחסון של זאפייר או בנקודת קצה מאומתת במקום.
שמרו עותק מחוץ לזאפייר. אפילו קובץ בריפוזיטורי עדיף מעותק יחיד בתוך שלב שאף אחד לא מגבה.

בשימוש למה שהוא - שלב המרה בין שני שלבים אחרים - Code by Zapier מצוין. בשימוש כמקום שבו חיים חוקי העסק, הוא הופך לחלק השביר ביותר בתפעול שלכם.

אם יש לכם שלבי Code שגדלו למשהו שאף אחד לא רוצה לגעת בו, קבעו שיחה ללא עלות. קשור: זאפייר מול קוד מותאם, n8n מול Make מול זאפייר, וחלופות לזאפייר לעסקים קטנים.