פיתוח מערכת מילוי אוטומטי לקטלוג 1C-Bitrix

כאשר קטלוג המוצרים גדל, עדכונים ידניים מפסיקים לעבוד

אוטומציה של מערכת המילוי האוטומטי של קטלוג 1C-Bitrix עם אינטגרציה חלקה של קטלוג 1C, מנתח מחירים של Bitrix, מנתח מלאי, ותורים של Bitrix. המערכת שלנו מציעה אוטומציה מקיפה של קטלוג, ניטור קטלוג, ופיתוח Bitrix חזק. בהתבסס על למעלה מ-20 פרויקטים, אנו מבטיחים פעולה יציבה עם בלוקי מידע וקטלוג מסחרי באמצעות CommerceML. עלות פרויקט טיפוסית: $12,000–$20,000, עם חיסכון שנתי בפעולות ידניות העולה על $80,000. צרו קשר לייעוץ והערכת פרויקט.

ארכיטקטורת המערכת

מערכת מילוי אוטומטי תקינה מורכבת ממספר שכבות:

שכבת איסוף נתונים (Collectors) כל מקור הוא collector נפרד המיישם CollectorInterface::collect(). ה-Collectors לא יודעים דבר על Bitrix — הם רק אוספים ומחזירים מבני נתונים מנורמלים. זה מאפשר בדיקה והחלפה עצמאית של מקורות. ה-Collectors מנתחים מחירים, מלאים ותיאורים מכל פורמט.

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

שכבת כתיבה (Writers) עוטפת את העבודה עם Bitrix API: CIBlockElement::Add/Update, CCatalogProduct::Update, CFile::SaveFile. Writer יודע על מבנה בלוק המידע אך לא מאיפה הגיעו הנתונים.

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

למה טבלת עדיפויות חשובה?

המשימה המרכזית היא לקבוע איזה שדה מאיזה מקור הוא בעל עדיפות. יש צורך בטבלת עדיפויות ברורה:

יישום: לכל שדה יש מטא-דאטה של מקור (מאפייני SOURCE_*). בעת עדכון עם נתונים בעדיפות נמוכה, אנו בודקים אם השדה כבר מלא על ידי מקור בעדיפות גבוהה יותר.

כיצד המערכת מתמודדת עם עומס?

עבור קטלוג עם 50,000+ פריטים, עיבוד סינכרוני הוא בלתי אפשרי. אנו משתמשים בתורים: אפשרות 1: טבלת תורים במסד נתונים

CREATE TABLE parser_queue (
    id SERIAL PRIMARY KEY,
    task_type VARCHAR(50), -- 'price', 'stock', 'description', 'image'
    element_id INT,
    payload JSONB,
    status VARCHAR(20) DEFAULT 'pending', -- pending/processing/done/error
    attempts INT DEFAULT 0,
    created_at TIMESTAMP DEFAULT NOW(),
    processed_at TIMESTAMP
);

עובדים (Workers) בוחרים משימות בקבוצות של 100, מעבדים, ומעדכנים סטטוס.

אפשרות 2: Redis Queues — לעדכונים בתדירות גבוהה (מחירים, מלאים). מהיר יותר ממסד נתונים, אך ללא AOF אין התמדה.

מה קורה במקרה של כשל?

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

• מספר הרשומות שעובדו במחזור האחרון
• מספר וסוגי השגיאות
• זמן הריצה המוצלח האחרון עבור כל collector
• גודל התור (אם הוא גדל, העובדים לא עומדים בקצב)

ריפוי עצמי: משימות עם סטטוס CREATE TABLE parser_queue ( id SERIAL PRIMARY KEY, task_type VARCHAR(50), -- 'price', 'stock', 'description', 'image' element_id INT, payload JSONB, status VARCHAR(20) DEFAULT 'pending', -- pending/processing/done/error attempts INT DEFAULT 0, created_at TIMESTAMP DEFAULT NOW(), processed_at TIMESTAMP ); ו-error מוחזרות אוטומטית ל-attempts < 3 לאחר שעה — לוגיקת ניסיון חוזר ללא התערבות ידנית.

מקרה מהפרקטיקה שלנו: חנות סיטונאית

משימה: 35,000 SKU, 4 ספקים עם פורמטי נתונים שונים (API, הזנת FTP, גרידת אתרים, אימייל עם Excel), עדכוני מחיר ומלאי כל שעתיים.

ארכיטקטורה:

• 4 collectors (REST API, הזנת XML דרך FTP, מנתח HTTP, קורא Excel)
• טרנספורמר יחיד עם טבלת מיפוי שדות (ניתן להגדרה בפאנל הניהול)
• Writer דרך pending (D7 ORM) — תיעוד
• טבלת תורים ב-PostgreSQL עם 3 עובדים מקבילים
• מדדי Prometheus + לוח מחוונים של Grafana לניטור

תוצאה: המערכת פועלת כבר 14 חודשים, זמן עיבוד מחזור מלא ממוצע — שעה ו-40 דקות. התערבויות ידניות בתקופה זו — 3 פעמים (פעמיים עקב שינויי API של ספק, פעם אחת עקב שינוי במבנה האתר שנגרד). חיסכון בפעולות ידניות עלה על $80,000 בשנה.

מה כלול בעבודה

1. תכנון ארכיטקטורה למילוי אוטומטי בהתחשב במקורות ובקטלוג שלך
2. פיתוח והגדרה של collectors, טרנספורמרים ו-writers
3. יצירת מערכת תורים ועובדים (Redis או מסד נתונים)
4. שילוב ניטור (Grafana + התראות)
5. ממשק ניהול לצפייה בתורים ולוגים
6. תיעוד ארכיטקטורה והוראות למפעילים
7. הכשרה לשני מומחים על המערכת
8. חודש אחד של תמיכה לאחר ההשקה
9. עלות פרויקט: $12,000–$20,000

לוח זמנים

סה"כ: 3–5 שבועות — זהו פרויקט, לא משימה. הפחתת פעולות ידניות ב-90% חוסכת משמעותית במשכורות מפעילים.

המהנדסים שלנו מוסמכים ב-1C-Bitrix, מה שמבטיח אינטגרציה נכונה עם ליבת הפלטפורמה. "תורים הם הדרך היחידה לקטלוגים מעל 50,000 פריטים" — מומחה Bitrix בפורום community.1c-bitrix.ru.

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