אינטגרציה של 1С-Битрикс עם Flocktory: היכן נשברת החלפת ההזמנות
אינטגרציה של 1С-Битрикс עם Flocktory כמעט תמיד נתקלת לא בחיבור הטראקר, אלא בהחלפת ההזמנות. טראקר האירועים מותקן תוך כמה שעות, אבל העברת סטטוסי ההזמנה, הסכומים והרכב הסל לתוכנית ההפניות — זה המקום שבו זה נשבר לרוב.
הסיבות טיפוסיות: ההזמנה מתבצעת במקום אחד, התשלום מאושר במקום אחר, והסטטוס משתנה במקום שלישי — ו-Flocktory נודע על כך אחרון.
הכשל הראשון — סטטוסים שאבדו. Битрикс משנה את סטטוס ההזמנה דרך סוכנים ומטפלי אירועים, ואם הקריאה לשירות חיצוני נופלת בגלל timeout, האירוע פשוט הולך לאיבוד: אין מנגנון חזרה.
בסופו של דבר ההזמנה בחנות סגורה, אבל בתוכנית ההפניות היא תלויה כ"בתהליך" — השותף לא מקבל תגמול, וזה מתגלה אחרי שבועות.
הכשל השני — כפילויות. בשליחה חוזרת של אירוע (למשל אחרי retry או שמירה מחדש ידנית של ההזמנה באדמין) Flocktory מקבל את אותה הזמנה פעמיים. בלי אידמפוטנטיות לפי מספר ההזמנה זה הופך לזיכוי כפול ולבדיקה ידנית.
הכשל השלישי והכי לא נעים — חוסר סנכרון בנתונים בין טראקר האירועים לתוכנית ההפניות. הטראקר מתעד קליק וסל, ההפניות מחשבות תגמול לפי המקור שלהן — וכשהסכומים או הסטטוסים לא תואמים, ההבטחות לשותפים לא מתיישבות עם המצב בפועל. מפרקים איך זה נסגר: העברת הזמנות אידמפוטנטית, תור עם חזרות, מקור סטטוס אחיד והשוואה.
מה נותן חיבור תקין: האפקט במספרים
חיבור תקין משנה לא את "הנוחות", אלא פרמטרים מדידים של החלפת נתונים. מהירות העברת ההזמנות והסטטוסים מ-1С-Битрикс לטרקר מפסיקה להיות תלויה בהפעלה ידנית: אירועים נשלחים עם שינוי הישות, ולא במקבץ אחת ליום.
בפועל, המרווח בין ביצוע ההזמנה להופעתה באנליטיקה מצטמצם משעות לדקות, וזה משפיע ישירות על האם מכניקת ההפניה מספיקה לזקוף את המעבר לפני פקיעת חלון הייחוס.
שיעור האירועים האבודים — הפרמטר השני שנראה מיד. כאשר סטטוסי הזמנה, הרשמה ומעברים בקישורי שותפים נכתבים לתור עם אישור מסירה, ולא נשלחים "לאין לאן" מתבנית הדף, האבדות יורדות לאפס בתרחישים שגרתיים.
בנפרד נסגר סוג הכשלים שבדרך כלל גם אוכל את התקציב: כפילויות בשליחה חוזרת, אובדן אירועים בעת ניתוק הקשר עם שירות חיצוני, אי-סנכרון בין סטטוס התשלום לסטטוס בטרקר. כל אחד מהם דרש בעבר טיפול ידני — כעת מטופל ברמת ההחלפה.
זמן התגובה לתקלה גם הוא הופך לניהולי. אם הטרקר אינו זמין, האירועים אינם אובדים, אלא מצטברים ונמסרים לאחר השחזור; המהנדס רואה זאת ביומן ההחלפה, ולא מגלה משותף כעבור שבוע.
יציבות הטרקר אינה תלויה בעומס על האתר: ההחלפה מוצאת מחוץ לבקשת המשתמש, ולכן זינוק בתעבורה במבצע לא הופך לתור של הזמנות אבודות.
סיכום במספרים: מרווח ההחלפה — דקות במקום שעות, אבדות אירועים בתרחישים שגרתיים — קרוב לאפס, זמן גילוי ותגובה לתקלה — דקות לפי היומן, ולא ימים לפי תלונות. בדיוק את ארבעת הפרמטרים האלה אנחנו בודקים בקבלה, ולא את העובדה ש"האינטגרציה מחוברת".
דרכים לחיבור Flocktory ל-1С-Битрикс
אינטגרציה של 1С-Битрикс עם Flocktory נפתרת בשלוש דרכים שונות מהותית, והבחירה ביניהן קובעת לא רק את מהירות ההשקה, אלא את יציבות חילופי ההזמנות ונתוני הטראקר תחת עומס. המודול הסטנדרטי הוא הכניסה המהירה ביותר, אך הוא קשיח לגרסת הליבה ולמערכת האירועים הנתמכת.
שכבת ביניים מעניקה גמישות במחיר חוליה נוספת בשרשרת. אינטגרציית אירועים ישירה — שליטה מקסימלית, אך דורשת משמעת בטיפול בתורים ובחזרות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול סטנדרטי | חנות טיפוסית, אירועי סל והזמנה סטנדרטיים, השקה מהירה | תלוי בגרסת הליבה, אינו מכסה תרחישים לא סטנדרטיים, עדכונים עלולים לשבור ווים מותאמים אישית |
| חילופין דרך שכבת ביניים | מספר אתרים או מערכות חשבונאות, נדרשת חציצה ושליחה חוזרת | נוצר שירות נפרד שיש לנטר ולתחזק |
| אינטגרציית אירועים ישירה | לוגיקת סטטוסים מורכבת, עומס גבוה, ישויות לא סטנדרטיות | דורשת טיפול עצמאי בשגיאות, אידמפוטנטיות ותור בעת כשל של השירות החיצוני |
מה לבדוק לפני הבחירה
הסתכלו על שלושה דברים: באיזו תדירות משתנים סטטוסי ההזמנה, כמה אתרים שולחים נתונים לטראקר אחד והאם יש לכם ישויות לא סטנדרטיות כמו מארזי מתנה או משלוחים חלקיים. אם הסטטוסים משתנים לעתים רחוקות והחנות אחת — המודול הסטנדרטי מספיק.
אם הזמנות מגיעות ממספר חלונות ראווה או ממערכת חשבונאות — שכבת ביניים מסירה את התלות ומאפשרת לשרוד אי-זמינות של השירות החיצוני ללא אובדן אירועים.
מגבלות שצפות מאוחר יותר
הסיכון העיקרי — כפילויות ואירועים שאבדו בעת ניתוק הקשר: ללא אידמפוטנטיות, שליחה חוזרת של הזמנה יוצרת רשומה שנייה בטראקר. הנקודה השנייה — חוסר סנכרון של סטטוסים, כאשר ההזמנה ב-Битрикс כבר סגורה, וב-Flocktory תלויה בעיבוד.
שתיהן מטופלות באמצעות יומן אירועים ושליחה חוזרת לפי לוח זמנים, אך יש להטמיע זאת בסכמה מיד, ולא לאחר אי-ההתאמות הראשונות בדוחות.
שלבי היישום: מביקורת ועד מסירה
היישום אינו מתחיל בהתקנת קוד, אלא בניתוח האופן שבו הזמנות, סטטוסים ומשתמשים כבר נעים בין האתר, 1С והאזור האישי.
בשלב זה אנו מזהים את הנקודות שבהן נוצרים כפילויות, הולכים לאיבוד סטטוסים ומתפצלים יתרות — אחרת הטראקר יתחיל לספור אירועים על בסיס נתונים עקומים, ותצטרכו לבדוק את הדוחות ידנית.
- ביקורת התממשקות. אנו בוחנים את המשימות המתוזמנות, התורים ומטפלי האירועים הנוכחיים: אילו ישויות מסונכרנות, באיזו תדירות, היכן ההתממשקות נופלת וכיצד היא משוחזרת. התוצר — מפת צווארי בקבוק ורשימת השדות החסרים להעברת אירועים תקינה.
- תרשים הזרימות. אנו מתכננים איזה תרחיש של קונה הופך לאיזה אירוע: צפייה, הוספה לסל, ביצוע הזמנה, תשלום, הזמנה חוזרת, הזמנה באמצעות קישור הפניה. עבור כל אירוע אנו מגדירים את מקור הנתונים ואת רגע השליחה, כדי לא לכפול פעולות בעת רענון העמוד.
- הגדרת הטראקר. אנו מחברים את המונה לכל נקודות הכניסה, כולל הגרסה לנייד ותבניות ביצוע הזמנה נפרדות. אנו מקשרים את מזהה המשתמש לפרופיל ב-1С, כך שהיסטוריית הרכישות והפעילות באתר יתאחדו לכרטיס אחד.
- מנגנון ההפניות. אנו מגדירים את הקישור בין המוזמן למזמין, את כללי הזיכוי ואת העברת סטטוס התגמול חזרה למערכת החשבונאית. בנפרד אנו בודקים תרחישים עם מספר מכשירים ועוגיות מחוקות.
- בדיקת תרחישים. אנו מריצים את המסלול המלא של הקונה בסביבת בדיקה: הזמנה, תשלום, ביטול, החזרה, רכישה חוזרת, מעבר בקישור הפניה. אנו מוודאים שהאירועים בטראקר תואמים לרישומים ב-1С עד לפעולה האחרונה.
- עומס ועמידות לתקלות. אנו בודקים את ההתנהגות כאשר שירות חיצוני אינו זמין: האירועים לא צריכים ללכת לאיבוד או לחסום את ביצוע ההזמנה, והתור צריך להתפנות לאחר חידוש הקשר.
- מסירה. אנו מוסרים את נוהל ההתממשקות, תרשים הזרימות, הוראות לבדיקת אירועים ואת סדר הפעולות במקרה של אי-התאמות. אנו מראים כיצד לוודא בעצמכם שהנתונים תואמים — בלי לפנות אלינו על כל פרט קטן.
רצף כזה מסיר את הסיכון העיקרי של האינטגרציה: כשהטראקר ומערכת החשבונאית סופרים דברים שונים, ואין את מי להאשים.
מה הלקוח מקבל לידיו
האינטגרציה אינה מסתיימת בעובדה ש"הנתונים עוברים בין המערכות", אלא בחבילה שלפיה הצוות שלכם יוכל להפעיל ולפתח את החיבור בלעדינו. לכן במסירה נכלל לא רק קוד עובד, אלא גם כל התשתית סביבו.
- קונפיגורציות האינטגרציה — פרמטרים של חיבור ל-Flocktory ול-1С-Битрикс, קישור נקודות איסוף למדורי הקטלוג, הגדרות העברת אירועי הזמנה ורישום, פרופילים נפרדים לסביבת הבדיקות ולסביבת העבודה.
- תרשימי זרימות נתונים — מהיכן מגיע האירוע, דרך אילו שירותים הוא עובר, היכן הוא מועשר בנתוני ההזמנה ובאיזה אופן הוא מוחזר לחשבון האישי ול-CRM. התרשים מסיר שאלות של "למה זה כך כאן" בעת פיתוחים עתידיים.
- מדיניות גישה — אילו שירותים ותפקידים רואים נתונים אישיים, היכן מאוחסנים טוקנים ומפתחות, כיצד מופרדות ההרשאות לייצוא ולהפעלה מחדש ידנית של ההחלפה.
- נהלי הפעלה — מה לעשות בעת אי-התאמה בסטטוסים של הזמנה, כיצד לשלוח מחדש אירוע שנתקע, כיצד להצליב צבירות של תוכנית ההפניות, אילו פעולות בטוחות ללא עצירת מכירות.
- הוראות לעבודה עם ממשק הניהול — כיצד מנהל יכול לראות היסטוריית צבירות של לקוח, כיצד להפעיל סנכרון חוזר, כיצד לבדוק שהאירוע הגיע ל-טרקר.
- תיעוד ו-ניטור — אילו אירועים נכתבים ללוג, לפי אילו סימנים ניכרת תקלה בהחלפה, לאן מגיעה התראה אם זרימת ההזמנות נעצרת.
- מסמך תמיכה — מפת תלויות, אנשי קשר אחראיים בצד השירותים, סדר עדכון בעת החלפת גרסאות של הפלטפורמה או המודול.
כל חפץ נמסר בצורה המתאימה להעברה למהנדס אחר: ללא "הסכמות בעל פה" וללא שלבים ידניים נסתרים. אם כבר יש לכם צוות תמיכה משלכם — הוא משתלט על המערכת לפי המסמכים הללו; אם אין, את התמיכה אנחנו לוקחים על עצמנו.
מקרה בוחן: כיצד סילקנו את חוסר הסנכרון בהזמנות
הלקוח — חנות מקוונת קמעונאית על 1С-Битрикс עם אזור אישי ותוכנית בונוסים — הגיע עם סימפטום שקשה לתפוס בניטור: פער בין ההזמנות במערכת לבין האירועים בטרקר. חלק מההזמנות כלל לא הגיעו לאנליטיקה, חלקן שוכפלו, וזיכויי ההפניות לא תאמו את הרכישות בפועל. הבעיה הצטברה במשך חודשים: דוחות הערוצים נראו אמינים, אך החלטות על פיהם התקבלו על בסיס תמונה מעוותת.
מה מצאנו בבדיקה
השורש התברר כשיטת העברת האירועים. ההזמנות נשלחו לטרקר באופן סינכרוני מתוך מטפל ביצוע ההזמנה — בעת פסק זמן של השירות החיצוני ההזמנה ב-Битрикс נוצרה, אך האירוע אבד ללא אפשרות שחזור.
ניסיונות חוזרים שנוספו "במהירות" הניבו אפקט הפוך: בעת תקלת רשת אותה הזמנה בדיוק נשלחה פעמיים, ובדוחות הופיעו כפילויות עם מזהים שונים. סיפור נפרד — זיכויי ההפניות: הם חושבו לפי עצם הלחיצה, ולא לפי הזמנה ששולמה בפועל, ולכן בונוסים זוכו עבור עגלות נטושות.
מה שינינו
הפרדנו בין רישום ההזמנה לבין שליחת האירוע: ההזמנה נרשמת ב-Битрикс, והאירוע מוכנס לתור עם מפתח ייחודי לאידמפוטנטיות. מטפל התור שולח אותו אל Flocktory עם ניסיונות חוזרים והשהיה מעריכית, והמפתח חוסם כפילויות בצד הטרקר.
לוגיקת ההפניות הועברה לסטטוס "שולם" — הזיכוי מופעל רק עבור הזמנה סגורה. הוספנו התאמה: אחת ליום אנו משווים את מספר ההזמנות ב-Битрикс לאירועים בטרקר, ופער נשלח ללוג.
תוצאה
שיעור האירועים שאבדו ירד מדו-ספרתי לאפס בגבולות ההתאמה היומית, הכפילויות נעלמו לחלוטין. זיכויי ההפניות תאמו את התשלומים בפועל, ודוחות הערוצים חדלו לסתור את נתוני מערכת החשבונאות. אפקט נפרד — צפיות: תקלה בשירות החיצוני אינה משפיעה עוד על ביצוע ההזמנה, והאירוע יגיע לאחר שחזור הקשר.
במה שונה החלפה דרך מודול מאינטגרציה מבוססת אירועים?
החלפה מודולרית היא מצב שבו מודול מוכן מהמרקטפלייס יוצר בעצמו טבלאות, את המטפלים שלו, ולפי לוח זמנים שולף נתונים. הוא אינו מכיר את סכימת ההזמנות שלכם: כדי לשלוף את הרכב הסל, סטטוס התשלום או את השיוך למשתמש, הוא זקוק либо לשדות תקניים, либо להתאמות ידניות.
מכאן התמונה האופיינית: סוכן מופעל פעם בשעה, מייצא חבילה, והפער בין ההזמנה האמיתית לבין מה שהטריקר רואה ממשיך להתקיים עד להרצה הבאה. לדיווח זה נסבל, לתרחישים של "סל נטוש" ו"רכישה חוזרת" — לא, מפני שהתגובה מתעכבת בעשרות דקות.
אינטגרציה מבוססת אירועים בנויה להיפך: נקודת הכניסה אינה לוח הזמנים אלא האירוע עצמו. ביצוע הזמנה, שינוי סטטוס, הרשמה, ביטול — כל פעולה מפעילה מטפל, אשר מעביר מיד את הנתונים למערכת חיצונית.
התגובה נמדדת בשניות, ולא במרווח שבין הרצות הסוכן, והודעה טריגרית נשלחת בעוד העניין של הלקוח חי. המחיר לכך הוא עבודה ארכיטקטונית: יש לתלות מטפלים על אירועים ספציפיים, לתכנן אידמפוטנטיות כך שקראה חוזרת לא תיצור כפילות, ולהגדיר תור למקרה שהשירות החיצוני אינו זמין.
ההבדל בתמיכה מתגלה בשינויים. המודול מתעדכן על ידי הספק, אך בעת עדכון הליבה או שינוי הלוגיקה של ביצוע ההזמנה ההחלפה שלו נשברת בשקט — הזמנות יוצאות, והנתונים מפסיקים להגיע.
סכימת האירועים חיה בקוד שלכם: אותה רואים, ניתן לכסות בבדיקות ולתעד כל קריאה, ולכן התקלה נתפסת מיד, ולא כעבור שבוע בהשוואת דוחות. מנגד, היא דורשת שלצידה יהיה מהנדס שמבין גם את אירועי הפלטפורמה וגם את החוזה של המערכת החיצונית.
בפועל, הבחירה לעתים רחוקות בינארית. ייצוא היסטורי המוני — קטלוג, הזמנות ישנות — זול ואמין יותר להעביר בחבילות לפי לוח זמנים, ואילו כל מה שנוגע להתנהגות הלקוח ברגע נתון — לתלות על אירועים.
סכימה היברידית כזו מספקת גם שלמות נתונים וגם מהירות תגובה, והתמיכה מצטמצמת למערכת מובנת של מטפלים במקום קופסה שחורה של מודול.
ספקות טכניים נפוצים
לפני הפעלת האינטגרציה של 1С-Битрикс עם Flocktory כמעט תמיד עולות אותן שאלות: מה לעשות אם המודול כבר הותקן בעבר, איך לא לקבל הזמנות כפולות ואיך לוודא שהנתונים לא התפצלו. להלן תשובות קצרות לכל אחת.
המודול כבר הותקן בעבר — להתחיל מחדש?
לא. תחילה מבצעים סקר מלאי: אילו מטפלי אירועים כבר רשומים, אילו טבלאות נוצרו, אילו סקריפטים של הטראקר מחוברים בתבנית. לאחר מכן או משלימים את התצורה הקיימת, או מעבירים אותה בזהירות לחדשה — בלי לכתוב מחדש באופן עיוור.
אם המודול הותקן "על חי" וחלק מהאירועים משוכפלים, מנקים את מרשם המטפלים ומשאירים סט עבודה יחיד.
איך להימנע מהזמנות ואירועים כפולים?
כפילויות מופיעות במקום שבו הטראקר והמודול שולחים בו-זמנית את אותו אירוע. אנו מבצעים שליחה אידמפוטנטית: כל הזמנה וכל סל מקבלים מזהה ייחודי, שליחה חוזרת עם אותו מזהה נדחית בצד האינטגרציה. בנוסף מפרידים תחומי אחריות — הטראקר אחראי לאירועים התנהגותיים, המודול לאירועים עסקיים, ואין חפיפות.
איך לבדוק את שלמות הנתונים לאחר החיבור?
משווים שלושה חתכים: הזמנות בממשק הניהול של Битрикс, אירועים בחשבון Flocktory ורשומות בלוגים של האינטגרציה. פערים בכמות ובסכומים — סימן שמשהו מאבד אירוע או משכפל סטטוס. את הבדיקה מבצעים על הזמנת בדיקה, לאחר מכן על תעבורה חיה במשך יממה, ורק לאחר מכן מחשיבים את האינטגרציה כעובדת.
מה יקרה בעת עדכון של Битрикс או של המודול עצמו?
עדכונים של הליבה והמודול עלולים להשפיע על מטפלי האירועים ועל מבנה הטבלאות. אנו מתעדים את נקודות האינטגרציה כדי שהעדכון לא ישבור את החיבור, ומחזיקים תוכנית נסיגה: אם לאחר העדכון האירועים מפסיקים להישלח, מחזירים את התצורה הקודמת בלי לאבד את הנתונים שנצברו.
בואו נדון במשימה שלכם
כדי לחזור עם הערכה ולא עם מילים כלליות, אנחנו צריכים להבין את הסכימה הנוכחית שלכם: היכן נמצאות ההזמנות, כיצד בנוי החילוף עם 1С, אילו אירועים כבר נשלחים למערכות חיצוניות.
תארו זאת בצורה חופשית — לאחר מכן המהנדסים שלנו ינתחו את זרימת הנתונים ויציעו כיצד לשלב את הטרקר והמכניקה של ההפניות מבלי לבנות מחדש את המעגל הקיים.
- כיצד בנוי כיום חילוף ההזמנות בין האתר, 1С ומערכת החשבונאות: ייצוא לפי לוח זמנים, חילוף בזמן אמת או פעולות ידניות.
- אילו אירועים כבר נרשמים באתר — ביצוע הזמנה, הרשמה, רכישה חוזרת — ולאן הם מועברים.
- האם קיימת תוכנית הפניות פעילה וכיצד מחושבת כיום התגמול للم�תתפים.
- אילו נתונים על הלקוח זמינים להעברה: מזהה, איש קשר, הרכב ההזמנה, סטטוס תשלום.
- דרישות להפרדת גישות ולאחסון נתונים אישיים, אם הן מעוגנות אצלכם בכללים פנימיים.
- מגבלות בזמנים: האם יש תלות בעונה, במבצע או בהשקת כיוון חדש.
- מי מצד המזמין מקבל את התוצאה ויוכל לבדוק את תקינות האירועים לאחר ההטמעה.
לפי תיאור זה נחזור עם הערכה ותוכנית עבודה: אילו מודולים נוגעים, באיזה סדר נפרס את השינויים, כיצד נבדוק שהאירועים מגיעים ללא אובדן וכפילויות. אם באתר כבר קיימות התאמות לא סטנדרטיות, אמרו זאת מיד — זה משפיע על ההיקף. נדון במשימה בשיחת ועידה או בהתכתבות, לפי הנוח לכם.