שירותי פיתוח מנתחים עבור 1C-Bitrix

פיתוח פארסרים ל-1C-Bitrix: מאיפה מתחילים?

XMLReader, לא SimpleXML — בחירת הכלי קובעת את גורל הפרויקט. SimpleXML טוען את כל ה-XML לזיכרון, ועם קובץ ספק של 800 MB, PHP יקרוס עם שגיאה קטלנית במגבלת 512 MB. XMLReader מעבד בזרימה, צומת אחר צומת, וצורך 20–30 MB — יעיל פי 30. הפרט הזה מתחיל כל פיתוח פארסר ל-Bitrix. עם למעלה מ-10 שנות פיתוח Bitrix ויותר מ-50 פרויקטי פארסר שהושלמו, אנחנו מכירים את המלכודות. צרו קשר כדי להתחיל בפיתוח הפארסר שלכם היום.

אילו בעיות פארסינג פותר?

• מילוי קטלוג ראשוני — 15,000 כרטיסים עם תיאורים, מאפיינים, תמונות. ידנית, זה שלושה חודשים של עבודת מנהל תוכן; פארסר לוקח שבוע עם דיבוג.
• ניטור מחירי מתחרים — איסוף נתונים מ-Ozon, Wildberries, אתרי מתחרים. מתחרה מוריד מחיר על פריט חם — אתה מגלה תוך שעתיים, לא שבועיים.
• איגוד ספקים — חמישה מחירונים בפורמטים שונים (CSV עם CP1251, XML ב-CommerceML, Excel עם תאים ממוזגים) הופכים לקטלוג אחד עם מערכת מאפיינים אחידה.
• העשרת כרטיסים — משיכת מאפיינים, הוראות, מודלים תלת-ממדיים מאתרי יצרנים. בלי זה, כרטיס מוצר הוא קליפה ריקה ל-SEO.
• עדכון מבחר — מוצרים שחסרים בפיד הספק מושבתים דרך CIBlockElement::Update($ID, ['ACTIVE' => 'N']). חדשים נוצרים. הקטלוג נשאר מסונכרן.

באילו כלים אנו משתמשים בפיתוח פארסרים?

אתרים סטטיים — PHP (Goutte, Symfony DomCrawler) או Python (Scrapy, lxml). מהירות: 50–100 עמודים/שנייה. מספיק לקטלוגים ללא רינדור JS.

אתרי SPA ודינמיים — Puppeteer או Playwright. גלילה אינסופית, פילטרי AJAX, תמונות ב-lazy-load — דפדפן headless מתמודד עם הכל. המהירות יורדת ל-1–10 עמודים/שנייה, אבל אין אלטרנטיבה: הנתונים קיימים רק לאחר ביצוע JavaScript.

קבצי ספקים:

• Excel (XLS, XLSX) — PhpSpreadsheet. היזהרו מתאים ממוזגים ונוסחאות — הם שוברים מיפוי אוטומטי.
• CSV — fgetcsv() עם קידוד נכון. ספקים אוהבים CP1251, BOM ב-UTF-8, ונקודה-פסיק במקום פסיקים. את כל אלה צריך לזהות ולטפל בהם.
• XML/YML — XMLReader לקבצים גדולים, SimpleXML לפידים עד 50 MB.
• CommerceML — פורמט החלפה סטנדרטי עם 1C. אנו מפארסים את import.xml ו-offers.xml, וממפים למבנה בלוק המידע.

API — נקודות קצה REST של ספקים, APIs של שווקים (Ozon Seller API, Wildberries API). אנו עובדים במגבלות קצב, ומטפלים בעמודות.

כיצד בנוי הצינור של מילוי אוטומטי?

ארבעה שלבים. כל אחד יכול להישבר בדרך שלו.

1. איסוף. הפארסר סורק מקורות לפי לוח זמנים של cron. נתונים גולמיים נכנסים לטבלת ביניים — לא ישירות ל-b_iblock_element. תיעוד הכל: עמודים שביקרו, אלמנטים שפוענחו, איפה קיבלנו 403 או timeout. בלי לוגים, דיבוג פארסר הוא כמו ניחוש עתידות.

2. נורמליזציה. העבודה העיקרית כאן:

   • ניקוי תגי HTML, רווחים מיותרים, זבל Unicode
   • יחידות: "mm" → "mm", "millimeters" → "mm", "миллиметр" → "mm"
   • מיפוי קטגוריות ספק למקטעי בלוק מידע של Bitrix. ספק אחד קורא לזה "Notebooks", אחר "Notebooks and tablets", שלישי "Laptops" — כולם למקטע אחד
   • הסרת כפילויות לפי SKU, EAN/GTIN. מוצר אחד משלושה ספקים לא צריך להופיע שלוש פעמים

   טעינה ל-Bitrix. דרך CIBlockElement::Add() לאלמנטים חדשים, CIBlockElement::Update() לקיימים. תמונות: הורדה, שינוי גודל דרך CFile::ResizeImageGet(), המרה ל-WebP. מאפיינים דרך CIBlockElement::SetPropertyValuesEx(). מטא SEO דרך \Bitrix\Iblock\InheritedProperty\ElementValues. כתובות SEF נוצרות מתעתיק השם.

   עדכון. נקודה מרכזית — לא לדרוס עריכות ידניות של מנהל התוכן. עדכון רק מחיר, מלאי, פעילות. תיאור ותמונות שנערכו ידנית מסומנים במאפיין UF_MANUAL_EDIT ומדולגים במהלך הייבוא. מוצרים שחסרים בפיד מושבתים, לא נמחקים.

   למה נחוץ ניטור מחירי מתחרים?

   תת-מערכת נפרדת עם המאפיינים שלה:

   פרמטר	איך זה עובד
   תדירות	מפעם ביום ועד כל שעתיים — תלוי בתנודתיות השוק
   התאמה	לפי SKU, EAN, השוואת שמות מטושטשת באמצעות מרחק לוונשטיין
   אחסון	טבלת vendor_price_monitor נפרדת עם היסטוריה, לא בלוקי מידע
   התראות	טלגרם/אימייל כשחריגת מחיר מתחרה עולה על X%
   חוקים אוטומטיים	"שמור מחיר 3% מתחת למינימום המתחרה, אבל לא מתחת לעלות + 15%"

   תוצאה — דשבורד: המוצר שלך מול מתחרים, היסטוריית מחירים, מגמות. המנהל רואה איפה להעלות מחיר בלי לאבד מיקום, ואיפה להגיב.

   מודול ייבוא CSV/XML: התאמה אישית לפורמט שלך

   לקבצי ספקים — מודול מותאם אישית עם פאנל ניהול:

   • מיפוי ניתן להגדרה: "עמודה B בקובץ → מאפיין BRAND של בלוק המידע"
   • זיהוי קידוד אוטומטי (CP1251, UTF-8, UTF-16) דרך mb_detect_encoding() עם ולידציה
   • הורדת תמונות מ-URL עם תור — כדי למנוע רוויה של הערוץ
   • עדכון מצטבר לפי hash של שורה: שורה השתנתה — עדכון, לא — דילוג
   • לוח זמנים של cron, דוח: נוצרו 145, עודכנו 892, שגיאות 3 (עם פרטים)

   קבצים גדולים: CSV מעובד בקבוצות של 1000 שורות דרך fgetcsv() (מהיר פי 10 מעיבוד שורה-אחר-שורה), XML מוזרם דרך XMLReader, ביצוע ברקע דרך תור הסוכנים של Bitrix — ללא timeouts של PHP.

   היבטים משפטיים שיש לקחת בחשבון

   • robots.txt — כבדו אותו. Crawl-delay — צייתו לו.
   • תדירות בקשות — 1–2 בשנייה, לא יותר. אל תעשו DDoS לאתר של מישהו אחר.
   • תוכן יצרן — השתמשו בו. טקסטים מקוריים של מחברים — אל תעתיקו.
   • מידע אישי — אל תאספו.

   מה כלול בפיתוח פארסר סוהר?

   רכיב	תיאור
   אב-טיפוס	פארסר ל-1–2 מקורות תוך 2–3 ימים להערכת איכות הנתונים
   פארסר ראשי	איסוף נתונים מלא ממקור אחד (סטטי/דינמי)
   מודול ייבוא Bitrix	נורמליזציה, טעינה, עדכון, פאנל ניהול מיפוי
   ניטור מחירים	אם נדרש — מערכת איסוף והתראות (עד 10 מתחרים)
   תיעוד	תיאור ארכיטקטורה, הוראות עדכון סלקטורים
   תמיכה	אחריות ל-3 חודשים לפעולה רציפה, תיקון לשינויי פריסה של התורם

   איך אנחנו עובדים ולוחות זמנים

   1. אב-טיפוס — פארסר ל-1–2 מקורות תוך 2–3 ימים. הערכת איכות נתונים, מלכודות (הגנת Cloudflare, קפטצ'ה, טעינה דינמית).
   2. פיתוח — צינור מלא: פארסר → נורמליזציה → ייבוא ל-Bitrix → פאנל ניהול לניהול.
   3. בדיקות — הרצה על נפח קטלוג מלא, בדיקת מקרי קצה (שדות ריקים, HTML פגום, תמונות שבורות).
   4. השקה — הגדרת cron, ניטור שגיאות דרך בוט טלגרם.
   5. תמיכה — מתחרה שינה פריסה? עדכון סלקטורי CSS בפארסר.

   משימה	לוחות זמנים
   פארסר לאתר יחיד (HTML סטטי)	3–5 ימים
   פארסר לאתר SPA (Puppeteer/Playwright, עקיפת הגנות)	1–2 שבועות
   מודול ייבוא CSV/XML ל-Bitrix	1–2 שבועות
   מערכת ניטור מחירים (5–10 מתחרים)	2–4 שבועות
   מערכת מילוי אוטומטי מקיפה	4–8 שבועות
   תמיכה והתאמת פארסר	במנוי

   צרו קשר לייעוץ — ננתח את מקורות הנתונים שלכם ונציע ארכיטקטורת פארסר אופטימלית. בקשו הערכת פרויקט היום וקבלו לוח זמנים קבוע. אנו מבטיחים פעילות פארסר יציבה ותמיכה מלאה לאורך כל תקופת השימוש.