חיבור כל דבר
HTTP נכנס, HTTP יוצא, החלקים המסורבלים מטופלים
כל כלי אוטומציה מתהדר במספר אינטגרציות. המספר תמיד גדול ותמיד השאלה הלא נכונה, כי המערכת שאתה באמת צריך היא זו שנבנתה בבית ב-2014 על ידי מישהו שכבר עזב. מה שחשוב הוא עד כמה הכלי מדבר את הפרוטוקול שמתחת לכולם.
החיבורים המוכנים
לאפליקציות שרוב העסקים מתנהלים עליהן יש שלבים מוכנים: חנויות ושווקים, הנהלת חשבונות וחיוב, גיליונות ומסדי נתונים, יומנים ודואר, אחסון והעברת הודעות, CRM ומוקדי תמיכה, ספקי תשלום וחברות משלוח. אתה מאשר את החשבון פעם אחת, והשדות נקראים בשפה שהאפליקציה עצמה משתמשת בה, לא בשפת ה-JSON שלה.
כשלאפליקציה יש ייחודיות של השוק הפולני — מערכת חיוב שחייבת להיות מוכנה ל-KSeF, חברת משלוח שהתוויות שלה הן תקן לאומי — השלב המוכן יודע על כך, כי המשפחה מוכרת לשוק הזה ונאלצה ללמוד.
ואז המקרה הכללי
כל השאר הוא שלב HTTP, ושלב HTTP כאן אינו פרס ניחומים. זו אותה מכונה שעליה בנויים החיבורים המוכנים, עם אותו טיפול בחלקים שמייגעים לכתוב בעצמך.
החלקים המייגעים
מטופלים, כדי שלא תצטרך לכתוב אותם שוב
אימות
מפתחות API, אסימוני bearer, אימות בסיסי, OAuth 2 עם רענון, חתימת בקשות HMAC, TLS הדדי. פרטי גישה נשמרים פעם אחת, מוזכרים בשם, ולעולם לא מודפסים ליומן או לרשומת ריצה.
עימוד
סמני המשך (cursors), מספרי עמודים, היסטים (offsets), כותרות Link, וה-API שמאותת על הסוף על ידי החזרת מערך ריק. ציין איזה צורה זו, והשלב יעבור על כל הקבוצה.
מגבלות קצב
תקרה לכל חיבור, שנשמרת בכל תהליך עבודה שמשתמש בו. כשספק מחזיר 429 עם Retry-After, השלב ממתין את משך הזמן הזה במקום להציק.
ניסיונות חוזרים והשהיה הדרגתית
כשלים חולפים מנוסים שוב במרווחים הולכים וגדלים ועם תקרה. שלב הוא פונקציה טהורה של הקלטים שלו, ולכן ניסיון חוזר מריץ את השלב מחדש ולא את כל ההרצה.
מטענים לא נוחים
JSON, קידוד טפסים, XML, טקסט פשוט, העלאות multipart. תגובות מפורקות לשדות שאפשר להתייחס אליהם בשם, כולל אלה המקוננים ארבע רמות למטה.
פסקי זמן
מגבלה לכל שלב, כך שתלות איטית אחת לא תעכב עובד בזמן שהכול מאחוריו ממתין בתור. מה קורה כשהמגבלה מושגת — זו ההחלטה שלך, לכל שלב.
אם הוא מדבר HTTP, השיחה כבר התחילה.
Webhooks נכנסים, ברצינות
לכל תהליך עבודה יכול להיות כתובת URL שמתחילה אותו. כתובת זו מאמתת חתימות — HMAC בצורות שהספקים הנפוצים משתמשים בהן, וסוד משותף כשזה כל מה שהשולח מסוגל לו. בקשה ללא חתימה לתהליך שמצפה לחתימה נדחית ונרשמת, ולא מעובדת בשקט.
מנגנון הדה-דופליקציה פועל על מזהה המטען עצמו, כך ששולח שמנסה שוב כי לא ראה את ה-200 שלך בזמן מקבל הרצה אחת ולא שלוש. מטענים פגומים נשמרים, יחד עם הסיבה לדחייתם, כי הגורם הנפוץ ביותר לפער מסתורי באוטומציה הוא שולח ששינה את דעתו לגבי שדה.
המערכות שמדברות רק CSV
הן קיימות. קובץ מופיע בשרת SFTP בארבע בבוקר, או מגיע כקובץ מצורף, או מושלך בתיקייה משותפת. תהליך עבודה יכול להמתין לו, לקרוא אותו ולהתייחס לכל שורה כרשומה — כולל הקובץ עם סימן סדר בתים, מפרידים של נקודה-פסיק ושורת כותרות בפולנית, כי כך נראה הייצוא בפועל.
גם בכיוון השני זה עובד: תהליך עבודה יכול להרכיב קובץ ולהציב אותו במקום שבו המערכת השנייה מצפה למצוא אותו, שהוא לעיתים קרובות הממשק היחיד שיש לתוכנה מ־2006.
- ⚡טריגרקובץ חדש ב-SFTP של הספק:
stock-2026-09-09.csv. - 2ניתוחנקודות-פסיק, סימן סדר בתים, כותרות בפולנית. 4,118 שורות.
- 3נרמולקודי מטבע נבדקו מול נתוני ייחוס; שניים נדחו כפסולים.
- 4דחוףHTTP
PATCHבאצוות של 200, תוך התחשבות במגבלת הקצב. - !חריגיםשתי שורות הועברו לטיפול ידני, עם מספר השורה והסיבה. שאר 4,116 השורות עברו.
שלבים שקראו למודל: 0עלות ההרצה הזו: אפס
איפה נשמרים פרטי הגישה
מוצפנים, מוזכרים בשם, מוגבלים לסביבת העבודה שבבעלותה הם, ולעולם לא מוצגים ביומן הרצה, בהודעת שגיאה או בשיחה עם התמיכה. רשומת הרצה מציגה ששלב אומת כ-supplier-sftp; היא לא מציגה מהו supplier-sftp.
סוכנות שמריצה תהליך עבודה אחד לשלושים לקוחות נותנת לכל לקוח ערכת פרטי גישה משלו, ותהליך העבודה מתייחס לערכה ולא לסוד עצמו. החלפת מפתח היא עריכה אחת במקום אחד — וזו רוב הסיבה שסוכנויות מגיעות לכאן.
המגבלה שכדאי להכיר: מערכת ללא ממשק כלשהו — בלי API, בלי webhook, בלי העברת קבצים, אלא רק אדם שלוחץ בדפדפן — לא ניתנת לאוטומציה על ידי המערכת הזו ולא על ידי שום דבר אחר שפוי. אין כאן דפדפן חסר-ראש שמתחזה למשתמש, כי זה נשבר בפעם הראשונה שהצד השני מזיז כפתור, ונשבר בשקט.