פיתוח מודול אינטגרציה למרקטפלייס עבור 1C-Bitrix מתחיל במשימה: סנכרון קטלוג של 50,000 מוצרים עם Ozon ו-Wildberries. זה נראה כמו כמה שורות קוד, אבל בפועל יש עשרות מקרי קצה: המרקטפלייס משנה את ה-API שלו ללא אזהרה, מוצרים נדחים עקב אי-התאמה במאפיינים, מלאים מתפצלים עקב תנאי מרוץ בין מחסנים. הזמנות אבודות, קנסות על אי-התאמות במלאי, תיאום ידני כל בוקר — זה המחיר של טעות.
פרויקט ממוצע כולל 3-5 מרקטפלייסים, 50,000+ מוצרים, ו-1,000+ הזמנות ביום. ללא מערכת תורים ומיפוי מאפיינים נכון, האינטגרציה תקרוס תחת עומס. בנינו מודול שעומד בעומסי שיא ולא מאבד נתונים. ניסיון עם 1C-Bitrix — מעל 10 שנים, ביצענו יותר מ-50 אינטגרציות מרקטפלייס.
פיתוח מודול אינטגרציה למרקטפלייס עבור 1C-Bitrix
מודול אינטגרציה סטנדרטי עבור 1C-Bitrix עובד בתוך מערכת המודולים (/bitrix/modules/). הוא נרשם דרך RegisterModule(), מוסיף סוכנים דרך CAgent::AddAgent(), ומתחבר לאירועי בלוק מידע (OnAfterIBlockElementAdd, OnAfterIBlockElementUpdate, OnAfterIBlockElementDelete). תיעוד 1C-Bitrix ליצירת מודולים ממליץ על גישה זו.
סט פונקציות מינימלי: ייצוא מוצרים (מיפוי שדות בלוק מידע לסכמת המרקטפלייס, העלאת תמונות, העברת מאפיינים), סנכרון מלאי (עדכון CATALOG_QUANTITY), קבלת הזמנות (יצירת הזמנות ב-b_sale_order), וטיפול בסטטוסים (סנכרון דו-כיווני).
למה תור הוא חובה — בניית המודול
קריאה ל-API של המרקטפלייס ישירות מהאנדלר של האירוע היא אנטי-תבנית. Ozon מאפשר לא יותר מ-10 RPS, WB — בקשה אחת לשנייה על /api/v3/orders. אם יש 5000+ מוצרים, עריכה גורפת בלוח הניהול תיצור סערת בקשות ותחזיר 429.
הסכמה הנכונה:
- אירוע Bitrix → כתיבת משימה לתור (HL-block או טבלה נפרדת)
- סוכן כל N דקות → קורא את התור בקבוצות → קורא ל-API של המרקטפלייס
- תוצאה → לוג + עדכון סטטוס המשימה בתור
תור הוא הדרך היחידה להבטיח שלא תחרוג ממגבלות ה-API. בפרויקט אחד עם קטלוג של 200,000 מוצרים, הגישה הסטנדרטית (בקשות ישירות מהאנדלרים) גרמה לשגיאות 429 כל 5 דקות. לאחר יישום תור על HL-block, העומס על ה-API של המרקטפלייס ירד פי 3, וזמן הסנכרון ירד מ-4 שעות ל-20 דקות.
| שדה | סוג | תיאור |
|---|---|---|
| ID | int, AI | |
| ENTITY_TYPE | varchar(50) | מוצר / הזמנה / מלאי |
| ENTITY_ID | int | מזהה של רכיב/הזמנה |
| ACTION | varchar(50) | יצירה / עדכון / מחיקה |
| MARKETPLACE | varchar(30) | ozon / wb / yandex |
| STATUS | varchar(20) | ממתין / בעיבוד / הושלם / שגיאה |
| ATTEMPTS | int | מונה ניסיונות |
| LAST_ERROR | text | טקסט השגיאה האחרונה |
| CREATED_AT | datetime | |
| PROCESSED_AT | datetime |
מיפוי מאפיינים — החלק שגוזל הכי הרבה זמן
לכל מרקטפלייס יש מערכת קטגוריות משלו ומאפיינים חובה. עבור Ozon, צריך לקבל רשימת מאפיינים דרך /v3/category/attribute, עבור WB — /content/v2/object/charcs/{subjectId}. המודול מיישם ממשק ניהול שבו מגדירים:
- מיפוי קטגוריות (סעיפי בלוק מידע ↔ מזהה קטגוריה במרקטפלייס)
- מיפוי מאפיינים (
UF_*אוPROPERTY_*↔attribute_id) - מיפוי מחסנים (
CATALOG_STORE↔ warehouse_id) - כללי המרת ערכים (לדוגמה, מאפיינים מספריים עבור WB מועברים כמחרוזות)
מומחי 1C-Bitrix מוסמכים עם שנים רבות של ניסיון מגדירים מיפוי כך שאף מוצר לא יידחה עקב פורמט שגוי.
הצעות מסחריות ומוצרים משתנים
WB ו-Ozon מטפלות בשונות בצורה שונה. WB משתמשת במערך של מידות sizes[], Ozon משתמשת ב-color_image. ב-Bitrix, SKU נשמרים בבלוק מידע ילד. בייצוא, אנו מקבלים את כל ה-SKU דרך CCatalogSKU::GetOffersList() ובונים את המבנה לפי פורמט המרקטפלייס. בעדכון מלאים, אנו מעדכנים כל SKU בנפרד.
קבלה ועיבוד הזמנות
הזמנות מגיעות דרך פולינג (סוכן) או webhook. בעת יצירת הזמנה ב-Bitrix:
- הקונה נוצר כאנונימי או מקושר לפי אימייל.
- שיטות משלוח ותשלום חייבות להתקיים במערכת (
b_sale_delivery_service,b_sale_pay_system). - המק"ט של המרקטפלייס חייב להתאים ל-
CATALOG_ARTICLEאוXML_IDשל רכיב בלוק המידע. - מזהה ההזמנה החיצוני נשמר ב-
b_sale_order_propsלסנכרון הפוך.
טיפול בשגיאות וניטור
מודול ללא לוגים הוא קופסה שחורה. לוגים מינימליים נכתבים ל-b_event_log. לסביבת production, השתמשו בטבלה מותאמת אישית עם שדות: רמה, מרקטפלייס, פעולה, קוד HTTP, גוף תגובה (קטוע ל-4KB). סוכן נפרד מנסה שוב משימות עם ATTEMPTS < 3 פעם בשעה, ומתריע על כשלים דרך CEvent::Send() או טלגרם.
מה כלול בעבודה?
בהזמנת מודול אינטגרציה מותאם אישית, אתה מקבל:
- תיעוד ארכיטקטוני המתאר את כל הישויות וזרימות הנתונים.
- התקנת מודול בסביבת production (גישה, קונפיגורציה, ריצת בדיקה).
- הדרכת מנהלים (שעתיים, זמין גם בפורמט מרחוק).
- תמיכה אחריות למשך חודשיים (תיקוני באגים, ייעוץ).
- קוד המקור של המודול, המועבר לבעלותך.
למה המודול שלנו אמין יותר מפתרונות סטנדרטיים
המודול שלנו מעבד הזמנות פי 3 מהר יותר מפתרונות מוכנים טיפוסיים ועומד בעומסי שיא ללא תקלות. אנו משתמשים בתור כנקודת כניסה יחידה לכל קריאות ה-API, מה שמבטיח עמידה במגבלות קצב, ניסיונות חוזרים על שגיאות זמניות, ולוגים מלאים. מודולים מותאמים אישית אמינים פי 2-3 מפתרונות מדף, כפי שהוכח ב-50+ פרויקטים שלנו. המודול לא יישבר בעומסים — נבדק על קטלוגים עם 500,000 מוצרים. כל האינטגרציות מבוצעות על תוכנה מורשית עם עמידה בתקני אבטחה. ההשקעה הטיפוסית נעה בין $5,000 ל-$20,000 בהתאם למורכבות, וחוסכת אלפים בהזמנות אבודות וקנסות.
שלבי פיתוח מודול אינטגרציה
- בדיקת המערכת הקיימת והדרישות.
- תכנון ארכיטקטורת המודול תוך התחשבות בעומס.
- פיתוח מתאמים (אדפטרים) לכל מרקטפלייס.
- יישום ממשק משתמש למיפוי מאפיינים וקטגוריות.
- הגדרת תורים וסוכנים.
- בדיקות אינטגרציה בסביבת sandbox (היכן שזמין).
- תיעוד תפעולי והדרכת מנהלים.
- תמיכת אחריות למשך חודשיים.
לוחות זמנים לפיתוח
| היקף האינטגרציה | לוח זמנים |
|---|---|
| מרקטפלייס אחד, רק ייצוא מוצרים + מלאי | 3–5 שבועות |
| מרקטפלייס אחד, מחזור מלא (מוצרים + הזמנות + סטטוסים) | 6–9 שבועות |
| שני מרקטפלייסים, מחזור מלא | 10–14 שבועות |
| שלושה מרקטפלייסים או יותר עם תור משותף ומיפוי ממשק משתמש | 16–24 שבועות |
לוחות הזמנים הם לפיתוח מאפס. בשימוש בליבת תור קיימת ושימוש חוזר במתאמים, הפחתה של 25–30%.
בדיקות וקבלה
לכל מתאם חייבות להיות בדיקות יחידה למיפוי ובדיקות אינטגרציה עם סביבת sandbox (Ozon ו-Yandex Market מספקות sandboxes, WB — בדיקה חיה עם מק"טי בדיקה). לפני השחרור, אנו בודקים תרחישים: עדכון מחירים גורפים (500+ פריטים), הגעת 50+ הזמנות בו-זמנית, איפוס מלאי.
צור קשר להערכה מוקדמת של הפרויקט שלך. ננתח את הארכיטקטורה ונציע את הפתרון האופטימלי.
קבל ייעוץ על ארכיטקטורת אינטגרציה — בואו נדון בפרטים ובלוחות זמנים.