הסנכרון הייצורי הראשון של קטלוג מ-1C:Enterprise עם 50,000 מק"טים ל-1C-Bitrix גורם לעתים קרובות לפסקי זמן ולכפילויות.
נדמה שהפעלתם את מודול המסחר האלקטרוני וציינתם את כתובת 1c_exchange.php — אך בפועל, מחצית מהמוצרים לא נטענו, והשאר הועתקו שלוש פעמים. CommerceML הוא פרוטוקול החלפה תקני, אך הוא אינו מבטיח מזהים ייחודיים.
אנחנו אינטגרטורים עם 10 שנות ניסיון ולמעלה מ-500 פרויקטים. להלן סכמות אמיתיות שפותרות בעיות אלו ללא עלויות מיותרות. החיסכון השנתי בעיבוד ידני של כפילויות יכול להיות משמעותי (העלות מחושבת לאחר ביקורת), והחזר ההשקעה באינטגרציה הוא 2–3 חודשים.
שליטה ידנית בכל הזמנה ומוצר היא בזבוז זמן וכסף. החלפה אוטומטית מבטלת את הגורם האנושי ומאיצה את פעולות המחסן.
כיצד פועל החלף הסטנדרטי דרך CommerceML
הפרוטוקול CommerceML גרסה 2.08 קובע שני זרמים בלתי תלויים: קטלוג (מ-1C לאתר) והזמנות (מהאתר ל-1C).
העלאת קטלוג (1C → אתר)
- 1C מייצר קבצי XML
import*.xml(מבנה, מוצרים, מאפיינים) ו-offers*.xml(מחירים, מלאי). - הקבצים נשלחים באמצעות HTTP POST אל
/bitrix/admin/1c_exchange.php. - האתר מנתח את ה-XML ומעדכן את האינפובלוק.
החלף הזמנות (אתר → 1C)
- האתר מייצר XML עם הזמנות עבור התקופה.
- 1C מאחזר אותן ויוצר "הזמנות לקוח".
- 1C מחזיר סטטוסים.
נקודת כניסה — 1c_exchange.php, פקודות checkauth, init, file, import.
מדוע CommerceML סטנדרטי אינו מסוגל להתמודד עם קטלוגים גדולים?
המגבלה העיקרית היא XML מונוליטי. במהלך כל חילוף מלא, כל הקטלוג מעובד, מה שיוצר עומס שיא על השרת. עבור קטלוגים של יותר מ-10,000 SKU, חילוף מלא אורך 5–30 דקות וצורך את כל המשאבים. מסקנה: עבור פרויקטים גדולים, המנגנון הסטנדרטי מתאים רק כבסיס.
עדכוני דלתא מפחיתים את העומס פי 5
במקום העלאה מלאה כל שעה — העלאה מלאה פעם ביום (בלילה) + עדכון מחירים ומלאי כל שעה. זה מפחית את העומס בשעות העבודה ב-80%. אנו משתמשים בגישה זו בכל הפרויקטים עם תנודתיות מלאי גבוהה.
REST API מהיר פי 3 לעדכונים נקודתיים
אם יש צורך לעדכן מוצר בודד או סטטוס הזמנה, REST API מהיר בממוצע פי 3 מייצוא XML. הוא מתאים לאינטגרציות עם WMS או מערכות קשורות.
כיצד למנוע כפילות מוצרים במהלך החלפה?
כפילויות הן תוצאה של שינוי מזהים (IDs) לאחר ארגון מחדש של מסד הנתונים ב-1C. CommerceML הסטנדרטי אינו יכול להתאים בין מזהים ישנים לחדשים. המקרה שלנו: חנות חומרי בניין עם 80,000 פריטי SKU על UT 11.4.
עם כל עדכון, 3–5% מהמוצרים קיבלו מזהים חדשים ונוצרו מחדש, בעוד שהישנים הושבתו. מנהלים בילו שעות בשחזורם.
פתרון: סקריפט תווך (middleware) שלוכד את האירוע OnIBlockElementBeforeAdd. לפני יצירת אלמנט, הוא משווה את ה-ID מה-XML מול טבלת מיפוי {old_id => new_id}. אם ה-ID השתנה אך ה-SKU תואם, המוצר מתעדכן במקום להיווצר מחדש. הכפילויות נעלמו.
פרטי סקריפט התווך
הסקריפט כותב יומן (log) של כל החלפות ה-ID לטבלה נפרדת, מה שמאפשר לעקוב אחר היסטוריית השינויים. הוא גם בודק את העומס של שאילתות SQL דרך EXPLAIN ומוסיף אינדקסים במידת הצורך.בעיות אופייניות בהרצה ראשונה והפתרונות שלהן
פסק זמן עם קבצים גדולים. קובץ XML אחד עם 50,000 מוצרים שוקל 200–400 MB. בשרת, הפענוח אורך עד 30 דקות — PHP קורס. פתרון: ב-1C, יש להפעיל "העלאה בקבצים של N מוצרים" עם סף של 1000–5000.
קירילית בשמות קבצים. קבצים עם שמות בקירילית לא מגיעים לסקריפט — יש להשתמש בתעתיק בהגדרות ההחלפה. קידוד. CommerceML 2.08 דורש UTF-8. תצורות ישנות עשויות להפיק windows-1251. יש לבדוק את הכותרת <?xml version="1.0" encoding="UTF-8"?>.
הפרדת הרשאות גישה לחשבון ההחלפה
אל תשתמשו במנהל. צרו משתמש נפרד עם קבוצה בעלת הרשאות כתיבה עבור בלוק המידע של הקטלוג ועבור רכיב ההחלפה.
בקובץ 1c_exchange.php קיימת בדיקה: המשתמש חייב להשתייך לקבוצה בעלת הרשאת iblock_admin על בלוק המידע המיועד. הדבר מונע שינויים מקריים במקטעים אחרים.
תדירות החלפה ועומס
| מצב | עומס שרת | מקרה שימוש |
|---|---|---|
| ייצוא מלא פעם ביום | שיא, 5–30 דקות | קטלוגים עד 10,000 SKU |
| ייצוא מלא + עדכון דלתא | בינוני | 10,000–100,000 SKU |
| רק מלאי ומחירים כל שעה | נמוך | מחסנים בתנודתיות גבוהה |
| REST API + אירועי 1C | מינימלי | נתונים קריטיים בזמן אמת |
מה כוללת העבודה שלנו
- ניתוח של מבנה הקטלוג הנוכחי והגדרות ההחלפה
- הגדרה של החלפה סטנדרטית או מותאמת אישית (CommerceML / REST)
- פיתוח של תוכנת ביניים לסילוק כפילויות
- הטמעה של עדכוני דלתא ומתזמן
- בדיקות בסביבות בדיקה וייצור
- הדרכת מנהלים
- תיעוד ותמיכה באחריות
לוחות זמנים לאינטגרציה
| משימה | לוח זמנים |
|---|---|
| קטלוג סטנדרטי + החלפת הזמנות | 1–3 ימים |
| + מבנה מפרט לא סטנדרטי | 3–5 ימים |
| + פתרון בעיות מזהים בעת העברת מסד הנתונים | 1–2 ימים נוספים |
| החלפה מותאמת אישית דרך REST API | 1–3 שבועות |
הזמינו ביקורת של החלפת הנתונים הנוכחית שלכם — נזהה צווארי בקבוק ונבחר את הסכמה האופטימלית. קבלו ייעוץ בנושא הגדרת החלפת נתונים: מהנדס ינתח את הפרויקט שלכם ויציע פתרון.
חיסכון בזמן של מנהלים — עד 40 שעות בחודש, ועלות הטעויות בעיבוד ידני ניתנת לחישוב לאחר ביקורת.