מילוי אוטומטי של תיאורים ב-1С-Битрикс: היכן נשברת שרשרת הנתונים
השרשרת «ספק — מחירון או ייצוא — קטלוג — כרטיס מוצר» מורכבת מארבעה מעברים, ובכל אחד מהם הולך לאיבוד חלק מהנתונים. כלפי חוץ זה נראה אותו דבר: תיאורי מוצרים ריקים בחצי מהקטלוג, המחיר התעדכן, והטקסט נשאר מהאספקה הקודמת. להלן היכן בדיוק נשברת השרשרת ולמה ייבוא בלבד לא סוגר את הבעיה.
השבר הראשון — בצד המקור. אצל הספק התיאור חי בהערה חופשית, בקובץ נפרד או לא חי בכלל: במחירון מוקדש לו עמודה אחת, שאליה נכנס קטע של כמה עשרות תווים. ייבוא תיאורים מהמחירון יעביר את הקטע הזה בצורה תקינה — כלל הסינון יעבוד, אבל באתר יופיע טקסט שאין במה לאנדקס אותו. כאן עוזר לא ייבוא, אלא הרכבה של תיאור מתוך מאפיינים מובנים: מותג, דגם, ייעוד, הרכב.
השבר השני — חילופי קטלוג עם 1С. הייצוא מוסר מוצרים וחבילת הצעות נפרדת; אם מוגדר רק החלק של המחירים, כרטיס המוצר מקבל מחיר ומלאי, אבל מאפייני טקסט מגיעים ריקים. סיבה נפוצה — המאפיינים משויכים לבלוק ההצעות ולא למוצר, או שמיפוי השדות לא מכסה מאפיינים מותאמים אישית.
השבר השלישי — מילוי ידני של כרטיסים. מנהל מעביר טקסט ממכתב או ממפרט, כל עוד הפריטים ספורים; במאות פריטים התהליך מפגר אחרי האספקות, ואחרי העדכון הראשון של המחירון התיאורים כבר לא תואמים את המחיר והמלאי. לאחר מכן הדפים נכנסים ל«תוכן דל», הפריטים מאבדים נראות, והתיקונים נערמים בתור.
מילוי אוטומטי של תיאורים ב-1С-Битрикс הגיוני לבנות כמעין מסוע עם בדיקות בכל מעבר: מיפוי שדות, כללים להרכבת טקסט, ולידציה לפני כתיבה וטיפול ידני בחריגים. נסביר איך זה בנוי ומה מכסה כל חלק.
מה נותן זרימת נתונים מנוהלת ממקורות חיצוניים
זרימת נתונים ממקורות חיצוניים נבנית כמסוע עם כללים מפורשים בכל שלב. מחירון של ספק, ייצוא מהיצרן או טבלת מאפיינים מובאים למבנה אחיד, הפריטים מותאמים לפי מק"ט וברקוד, ולאחר מכן תבנית התיאור לפי קטגוריה מתמלאת בערכי המאפיינים ונכתבת לאינפובלוק 1С-Битрикс. אם ההתאמה לא הצליחה או שדה הגיע ריק, המוצר לא מתפרסם בשקט — הוא עובר לתור חריגים עם ציון הסיבה.
האפקט של אוטומציית הקטלוג נמדד בשלושה מספרים. זמן ההופעה של תיאור לפריט חדש מתקצר מיומיים-שלושה של עבודה ידנית לדקות — המוצר נכנס לקטלוג באותה הרצה שבה נכנס למקור. שיעור הכרטיסים שמתפרסמים בלי תיקונים של צוות התוכן מגיע ל-80-90%; השאר הם חריגים מודעים, לא פגם שהוחמץ.
שלמות הכרטיסים נשענת לא על המשמעת של העורך, אלא על מאפיינים חובה ובדיקות לפני כתיבה: מאפיינים ריקים, אי-התאמה של יחידות מידה ומק"טים כפולים נחסמים לפני הפרסום. היקף העבודה הידנית של צוות התוכן מצטמצם לטיפול בחריגים ותיקון תבניות במקום הקלדת טקסט לכל פריט.
מהירות הוצאת הפריטים נקבעת לפי לוח הזמנים של החילופים: ייצוא אינקרמנטלי נוגע רק ברשומות שהשתנו, ולכן עדכון קטלוג של עשרות אלפי פריטים לא דורש כתיבה מחדש של הכול.
המהנדסים שלנו מגדירים כללי התאמה, תבניות תיאור ויומן הרצות — כשפורמט הייצוא אצל הספק משתנה, הזרימה לא מתפרקת בשקט, אלא מראה מה בדיוק לא התאים.
שיטות למילוי אוטומטי: חילוף חד-פעמי, לוח זמנים, אירועים
בחירת מצב היא בחירה בין רעננות הנתונים לבין עומס צפוי על הקטלוג. ייבוא חד-פעמי של מחירון מכסה התחלה או הרכבה מחדש של המבחר, חילוף באצוות — סנכרון קבוע במנות גדולות, אירועים — תיקונים נקודתיים. להלן השוואה לפי תנאי היישום ולפי המגבלות שכל מצב מטיל.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| ייבוא חד-פעמי של מחירון | מילוי ראשוני של הקטלוג, החלפת ספק, הרכבה מחדש חד-פעמית של המבחר | תיקונים ידניים אחרי הטעינה הולכים לאיבוד אם המקור לא מסומן; הרצה חוזרת לא אמורה לשכפל כרטיסים |
| חילוף קטלוג באצוות | עדכון המוני של תיאורים ומאפיינים במנות | טרנזקציות ארוכות וחסימות בזמן כתיבה — נדרש גודל מנה והשהיה בין אצוות |
| חילוף לפי לוח זמנים | מחירים, מלאי, תיאורים ממקורות חיצוניים — פעם בשעה או ביום | הנתונים תמיד באיחור; במקרה של כשל בחלון נדרש השלמה של חילוף שהוחמץ |
| חילוף לפי אירועים | תגובה לשינוי בכרטיס, במלאי או בהזמנה | תלוי בזמינות של שירות חיצוני; תור וניסיון חוזר במקרה של כשל הם חובה |
מגבלות משותפות לכל המצבים
המילוי לא אמור למחוק טקסט שנערך על ידי מנהל התוכן, לכן מסמנים גם את המקור וגם את השדה הספציפי בכרטיס. כתיבה המונית מתבצעת במנות עם תיעוד — אחרת כשל באמצע משאיר את הקטלוג במצב ביניים.
בנפרד מתכננים את בנייתו מחדש של אינדקס החיפוש: העומס שלו מצטבר לחילוף, ובשרת חלש דוחה את תגובת הקטלוג.
סדר היישום: מניתוח מקורות ועד מסירה
היישום של מילוי אוטומטי מתחיל לא בקוד, אלא במלאי: אילו מקורות באמת מספקים טקסטים — ייצוא ממערכת הנהלת החשבונות, כרטיסי ספקים, טבלאות של צוות התוכן — באיזו צורה הם מגיעים ובאיזו תדירות משתנים.
לאחר מכן מתכננים כללי התאמה ומעגל בדיקה, כדי שהייבוא הראשון לא ידרוס תיאורים שנבדקו ידנית ולא יצור כפילויות.
- ביקורת מקורות נתונים. מרכזים רשימת מקורות, מעריכים שלמות ועדכניות של שדות, מסמנים חפיפות וסתירות ביניהם. קובעים בעלים לכל מקור ותדירות עדכונים.
- כללי התאמה של מוצרים. בוחרים מפתח — מק"ט, ברקוד או שילוב של מאפיינים — ומתארים התנהגות עבור מוצרים חדשים בלי מפתח, כפילויות ופריטים שהוסרו מהמכירה. הכלל לא אמור לאפשר מיזוג של שני כרטיסים שונים לאחד.
- סכימת חילוף וסדרי עדיפויות של מקורות. מתאימים שדות של המקור לתיאור ולמאפיינים של הכרטיס, קובעים סדר עדיפויות אם המוצר מתואר בכמה מקומות, וכללים לנרמול טקסט: סימון, קיצורים, יחידות מידה.
- הגדרת חילוף. החילוף מתבצע לפי לוח זמנים ובמנות, עם יומן פעולות והרצה חוזרת בלי כפילויות; אחרי ניתוק בקשר העיבוד ממשיך מהמקום שבו נעצר, ולא מהתחלה.
- מעגל בדיקה לקטלוג. פורסים עותק של הקטלוג עם מבנה ומאפיינים אמיתיים ומריצים את כל ההיקף: מודדים זמן עיבוד, בודקים מדגם כרטיסים, מחפשים קשרים שבורים ושדות ריקים.
- קבלת החילוף ומסירה. משווים מדגם ביקורת לפני ואחרי, בודקים חזרה לתיאורים קודמים, מאשרים נוהל ניטור ומוסרים תיעוד עם הוראות לצוות התוכן.
מה מוסרים לידיים: קונפיגורציות, סכימות, נהלים
היישום סגור לא כשהחילוף עבד פעם אחת, אלא כשהלקוח יכול להפעיל מחדש, לבדוק ולתקן אותו בלעדינו. לכן בעת הקבלה מוסרים ערכת ארטיפקטים: קונפיגורציה עובדת, סכימות והוראות למנהל תורן. כל מסמך משויך לרכיב מסוים — היכן נמצא המקור, במה מפעילים את החילוף, איך מחזירים תיקון שלא צלח.
- סכימת חילוף נתונים — המסלול מהמקור החיצוני דרך שכבת ביניים ועד אינפובלוקים והצעות מסחריות, עם נקודות בקרה בכל שלב.
- מפת התאמת שדות — טבלה «מקור → מאפיין → כלל המרה»: סוגים, חובה, התנהגות בערך ריק.
- קונפיגורציות והגדרות חילופים — ייצוא של סוכנים, מטפלים, הרשאות גישה ולוח זמנים, כדי לפרוס עמדה מאפס.
- נוהל טיפול בשגיאות — אילו תגובות מהמקור קריטיות, למי נשלחת התראה, איך להפעיל מחדש רק את החלק שנכשל בלי לחזור על כל הייצוא.
- תיעוד החילוף — פורמטים של קבצים, מגבלות נפח וזמן תגובה, דרישות לקידוד ומפרידים.
- גיבויים של הגדרות — גרסאות של קונפיגורציה וכללי התאמה עם תאריכים, כדי להחזיר תיקון שנוי במחלוקת בצעד אחד.
- הוראות למנהל תורן — איך לבדוק שלמות תיאורים לפי מדגם מוצרים, לאן להסתכל במקרה של אי-התאמה ומתי לקרוא לנו.
מקרה בוחן: קטלוג עם עשרות אלפי פריטים בלי תיקון ידני
קטלוג של 40,000+ פריטים הורכב מייצוא של ספקים: חלק הגיע עם תיאורים מוכנים, חלק — רק עם שם, מק"ט ומאפיינים. כרטיס בלי תיאור לא עובר מודרציה אצל פלטפורמות ומאונדקס רע, לכן מנהלים השלימו טקסט ביד — 8-10 דקות לפריט, ואספקה טרייה נשארה לא מכורה עד שטיפלו בה.
בנינו מסוע למילוי אוטומטי בצד האינפובלוקים 1С-Битрикс: מודול ניתוח מביא את הייצואים למבנה אחיד, כללים משייכים תבנית טקסט למדור ולקבוצת מאפיינים, תיאור מוכן נבדק לכפילויות, אורך מינימלי ותקינות מאפיינים.
מפתח דה-דופליקציה לפי קבוצת מאפיינים משמעותיים — חילוף חוזר כותב מחדש רק כרטיסים שהשתנו, ולא את כל הקטלוג.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור כרטיסים בלי תיאור | 38% | 2% |
| זמן מהייצוא ועד פריט במכירה | 3-5 ימים | מחזור החילוף הקרוב, בתוך יממה |
| פניות לתמיכה על תיאורים ריקים | עד 60 בחודש | בודדות |
| עומס על הקטלוג בזמן חילוף | ירידה בתפקוד החנות | כתיבה במנות, החנות לא נחסמת |
היתרה של 2% — פריטים שלגביהם פשוט אין נתונים אצל הספק: אותם אנו מסמנים בדוח, כדי שהמנהל יראה מה בדיוק דורש הזנה ידנית, ולא יחפש בכל הקטלוג.
במה שונה חילוף לפי לוח זמנים מחילוף לפי אירועים?
תשובה קצרה: אלה שתי פשרות שונות בין השהיה בהופעת התיאור לבין עומס צפוי. חילוף באצוות לפי לוח זמנים נותן לוח זמנים אחיד וקל יותר לניפוי, חילוף מבוסס אירועים — השהיה מינימלית, אבל דורש מסירה אמינה של התראות.
בחילוף לפי לוח זמנים, המתזמן — סוכנים ב-1С-Битрикс — מפעיל במרווח מוגדר משימה שבוחרת מוצרים שהשתנו לפי חותם זמן או סכום בקרה של התיאור ומעבדת אותם במנות.
ההשהיה שווה לתקופה ועוד זמן המעבר: בעשרות אלפי פריטים ומנה של כמה מאות רשומות מחזור אחד אורך דקות, ולכן העדכון בפועל מגיע באיחור של עשרות דקות. לעומת זאת העומס על הקטלוג צפוי, ומעבר כבד מועבר לחלון לילה.
מצב מבוסס אירועים עובד הפוך: המקור בעת עריכת כרטיס מפרסם התראה, המטפל לוקח אותה מהתור ומעדכן את התיאור כמעט מיד — ההשהיה נמדדת בשניות. המחיר — תשתית: תור, ניסיונות חוזרים, בדיקת אידמפוטנטיות ויומן, אחרת התראה שאבדה תשאיר מוצר בלי תיאור. בנוסף, שיאים: ייבוא המוני יוצר הצפה של אירועים, והקטלוג מוגן בהגבלת כתיבות במקביל.
בפועל בוחרים היברידי: אירועים מכסים תיקונים שוטפים, והשוואה נדירה לפי לוח זמנים משלימה את מה שאבד בתור. ההחלטה על המצב מצטמצמת לשתי שאלות — באיזו תדירות הנתונים משתנים וכמה כתיבות במקביל מסד הנתונים מחזיק.
אם התיאורים מתעדכנים פעם ביום, לוח זמנים מספיק, וקל יותר לתחזק אותו: השבתת המשימה עוצרת את הזרימה בפעולה אחת.
ספקות טכניים: מה שואלים לפני ההרצה
לפני הרצת המילוי האוטומטי שואלים את אותה קבוצת שאלות: מה יקרה לטקסטים שנכתבו ביד, איך יתנהגו כרטיסים עם נתוני מקור חסרים ומה יקרה לקטלוג בעת כשל בחילוף. אנחנו עונים לפי סעיפים.
האם תיאורים ידניים יידרסו?
לא, אם מגדירים עדיפות: שדה עם טקסט ידני מסומן בסימן חסימה, והטעינה לא נוגעת בו — מתעדכנים רק ערכים ריקים או אוטומטיים. יומן השינויים בכרטיס מראה מה ומתי נדרס, ומאפשר להחזיר את הגרסה הקודמת.
המקור מוסר נתונים חסרים — מה ייכנס לאתר?
התיאור מורכב לפי תבנית מהמאפיינים ועובר בדיקה לשדות חובה, כפילויות וסתירות. אם אין מספיק נתונים, הכרטיס לא מתפרסם, אלא עובר לתור לעבודה ידנית עם ציון מה בדיוק חסר.
אפשר לכסות רק חלק מהקטלוג?
כן. המדגם נקבע לפי כלל — מדור, ספק, ערך של מאפיין. חריגים גם מתוארים בכלל ונשמרים בין הרצות: בחילוף הבא אותה קבוצה תישאר מחוץ לאוטומציה.
איך החילוף מוגן מכשלים ומזכויות מיותרות?
הכתיבה מתבצעת במנות ובטרנזקציה: בעת ניתוק בקשר מה שנטען נשמר, ניסיון חוזר משלים את היתרה, וערך ריק מהמקור לא מוחק טקסט קיים. חשבון המשתמש לחילוף מקבל רק את ההרשאות הנדרשות, והשינויים נרשמים ביומן.
נדון במשימה ונחזור עם תוכנית עבודה
אי אפשר לתת הערכה מדויקת ליישום חילוף על סמך משפט אחד «צריך למלא תיאורי מוצרים» — הכול נקבע לפי המבנה של הקטלוג שלכם.
אותו ייצוא של ספק בשתי חנויות מתנהג אחרת: במקום אחד המאפיינים נמצאים במאפייני האינפובלוק, במקום אחר בהצעות מסחריות, ובמקום נוסף חלק מהטקסטים נכתבו ביד ואסור לאבד אותם. לכן ניתוח המשימה על ידי המהנדסים מתחיל מהנתונים שלכם, ולא מתבנית ממוצעת.
מה כדאי לשלוח לפני השיחה:
- דוגמה לייצוא ממקור חיצוני — קובץ אמיתי, ולו של יום אחד;
- מפת שדות: אילו מאפייני מוצר מתמלאים אוטומטית ואילו נשארים ידניים;
- כללי העשרה: מה לוקחים מהמקור כמו שזה, ומה מרכיבים לפי תבנית מהמאפיינים;
- תדירות ונפח עדכון צפויים — כמה פריטים בהרצה ובאיזו תדירות היא מתבצעת;
- גישות למעגל בדיקה או לעותק של הקטלוג, כדי לבדוק את החילוף בלי סיכון לאתר הפעיל.
בשיחה נבהיר אי-התאמות בנתונים, כללי התאמה להצעות מסחריות, מה לעשות כששדות אצל הספק ריקים, איך לתעד דריסה ועל איזה מדגם נריץ את החילוף לפני ההרצה. בתגובה נשלח הערכה ליישום ותוכנית עבודה לקטלוג: שלבים, מה עושים בכל שלב, מה יידרש מצדכם ובאיזה סדר מתקבלת התוצאה.
תארו את משימת המילוי האוטומטי — נחזור עם הערכה, תוכנית וחלוקה לשלבים.