העברת תהליכי עבודה מ-⁠Base44: איך אוטומציות מרובות שלבים עוברות

תהליכי עבודה לעומת אוטומציות

ל-⁠Base44 היו שני מנועים לעבודת צד שרת שקורית מעצמה.

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

תהליכי עבודה (workflows) מחליפים אותן. לפי המדריך של Base44 לתהליכי עבודה, אפליקציות שנוצרו מ-6 ביולי 2026 משתמשות בתהליכי עבודה, אפליקציות ותיקות יותר עשויות עדיין להשתמש באוטומציות, ולכל אפליקציה יש את האחד או את השני, אף פעם לא את שניהם. אפליקציות ותיקות יכולות לעבור בצעד אחד מהדף "Automations" (אוטומציות), שיוצר מחדש כל אוטומציה כתהליך עבודה עם אותו טריגר ואותו תזמון. תהליכי עבודה דורשים מסלול Builder ומעלה.

מה תהליכי העבודה מוסיפים:

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

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

טריגרים

תהליך עבודה מתחיל מטריגר אחד. המדריך של Base44 מפרט שישה טריגרים בעורך:

ה-⁠API למפתחים מוסיף עוד כמה סוגי טריגרים: הרשמה או התחברות של משתמש באפליקציה, webhooks נכנסים, וטריגרים שמשמשים את ה-⁠Superagents של Base44 (Apps API: תהליכי עבודה).

מה זה תהליך עבודה, מתחת למכסה המנוע

מאחורי התרשים בלוח הבקרה, כל תהליך עבודה הוא שני דברים:

1. הגדרה שכתובה בפורמט CNCF Serverless Workflow 1.0, תקן פתוח. רשימת ה-do שלה מחזיקה את השלבים, וכל שלב הוא אחד משלושה סוגים: call שמריץ פעולה (כמו הרצה של אחת מפונקציות השרת שלכם), switch שמתפצל לפי תנאי, או wait שעוצר לפרק זמן מסוים או עד מועד מסוים.
2. הגדרת טריגר, ששמורה בנפרד, עם תנאי אופציונלי שכתוב כביטוי jq על המטען (payload) של הטריגר. תהליך העבודה רץ רק כשהביטוי מתקיים.

כל שינוי בהגדרה נשמר כגרסה שאי אפשר לשנות, שהמזהה שלה הוא ה-⁠hash מסוג SHA-256 של ההגדרה, וכל הרצה רושמת את הגרסה שהיא הריצה.

הנה דוגמת המעקב אחרי לידים, בגרסה מפושטת להמחשה; שמות השדות בהגדרה אמיתית של Base44 שונים בפרטים:

document:
  dsl: '1.0.0'
  name: lead-follow-up
do:
  - sendWelcome:
      call: run_backend_function      # e.g. sendWelcomeEmail
  - waitTwoDays:
      wait:
        days: 2
  - checkReply:
      switch:
        - noReplyYet:
            when: ${ .lead.replied != true }
            then: sendFollowUp
        - replied:
            then: end
  - sendFollowUp:
      call: run_backend_function      # e.g. sendFollowUpEmail

ההגדרה ניידת, כי היא בפורמט סטנדרטי. מה שלא נייד הוא כל מה שגורם לה לרוץ.

מה נדרש כדי להריץ תהליך עבודה מחוץ ל-⁠Base44

כדי להעביר תהליך עבודה, ארבעה דברים צריכים להתקיים בצד השני:

1. ההגדרות והטריגרים, מיוצאים מ-⁠Base44 ושמורים לצד הקוד שלכם.
2. מתזמן שמכבד תזמוני cron באזור הזמן הנכון, מרווחים והרצות חד-פעמיות.
3. מקור אירועים שמזהה מתי רשומות נוצרות, מתעדכנות או נמחקות, מחשב את תנאי ה-jq של כל טריגר, ומפעיל את תהליכי העבודה הנכונים.
4. מריץ שלבים שקורא לפונקציות השרת שלכם עם הזהות והארגומנטים הנכונים, הולך לפי ההסתעפויות, ושומר על המקום של כל הרצה לאורך wait ארוך, גם כשהשרת מופעל מחדש.

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

איך Unbase44 מעביר תהליכי עבודה

Unbase44 קורא את ההגדרה ואת הטריגר של כל תהליך עבודה מ-⁠Base44, וכותב אותם למאגר (repository) שלכם, לצד הפונקציות והטבלאות. צד השרת שמריץ את האפליקציה כולל מנוע תהליכי עבודה לאותן הגדרות: טריגרים מתוזמנים (cron עם אזורי זמן, מרווחים והרצות חד-פעמיות), טריגרים של שינויים בנתונים עם תנאי ה-jq שלהם, שלבים שמריצים את פונקציות השרת שלכם, הסתעפויות והמתנות.

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

חלק מהטריגרים שייכים ל-⁠Base44 עצמה. "App publish" מופעל כשמפרסמים מהבונה של Base44, שבו כבר לא תשתמשו אחרי ההעברה; התחליף הטבעי שלו הוא תהליך הפריסה (deploy pipeline) שלכם. "App payment" תלוי באינטגרציית התשלומים של Base44. הניתוח מפרט כל אחד מתהליכי העבודה שלכם, עם הטריגר שלו, לפני שאתם משלמים, ומסמן כל מה שדורש החלטה.

אחרי ההעברה, שלבים בתהליכי עבודה כבר לא צורכים קרדיטים של אינטגרציות. Base44 גובה בערך קרדיט אחד לכל עשרה שלבים, ועוד העלות של מה שכל שלב עושה (קרדיטים). בשרת שלכם, שלבים לא עולים שום דבר נוסף, ואימייל או קריאות ל-⁠AI בתוכם מחויבים על ידי הספקים שלכם.

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

לפני המעבר:

• הכינו רשימה מלוח הבקרה "Workflows" (תהליכי עבודה) ב-⁠Base44: כל תהליך עבודה, הטריגר שלו, אם הוא פעיל, ואיך ההרצה האחרונה שלו הסתיימה.
• בדקו את אזורי הזמן של התזמונים. סיכום יומי שזז בשעה הוא הבאג הקלאסי בהעברות.
• בדקו באפליקציה החדשה עם נתונים מציאותיים. עם Unbase44 העותק מתחיל במצב בדיקה: הוא לא מריץ אוטומציות או תהליכי עבודה, ומעכב כל מה שהוא היה שולח, ורושם אותו ביומן במקום זה. אחרי שמכבים את מצב הבדיקה, הרצה ידנית של תהליך עבודה מבצעת פעולות אמיתיות, כמו מיילים אמיתיים ושינויים אמיתיים ברשומות, ולכן השתמשו ברשומות בדיקה ובכתובת המייל שלכם.
• היזהרו מלולאות. תהליך עבודה עם טריגר ישות שמעדכן את הרשומה שמפעילה אותו יכול לרוץ לנצח. המדריך של Base44 מזהיר מזה; אותה זהירות נדרשת בכל מקום.

ברגע המעבר:

• השביתו את תהליכי העבודה ב-⁠Base44 ברגע שהאפליקציה החדשה באוויר. אחרת משימות מתוזמנות ירוצו פעמיים, והלקוחות שלכם יקבלו כל מייל פעמיים. השאירו את אפליקציית ה-⁠Base44 עצמה מפורסמת בזמן שהמשתמשים מתחברים לאפליקציה החדשה בפעם הראשונה.
• תנו להרצות שכבר בדרך להסתיים. הרצה שממתינה ב-⁠Base44 מסתיימת שם; הרצות חדשות מתחילות בשרת שלכם.
• עדכנו שולחים חיצוניים. אם שירות אחר שולח אירועים לאפליקציה, כמו webhook של Stripe שקורא לאחת מפונקציות השרת שלכם, הפנו אותו לכתובת החדשה.