פרסינג פידים חדשותיים למילוי אוטומטי של 1С-Битрикс

פרסור חדשות ב-Bitrix: היכן נשברת הזנה אוטומטית

הזנה אוטומטית של אינפובלוק נשברת לא בשלב של "לקחנו פיד ופרסנו אותו", אלא בתפעול השוטף: המקור משנה פורמט, סוכני Bitrix מצטברים לתהליכים תקועים, מסד הנתונים גדל מכפילויות.

אחרי חודש-חודשיים צינור עיבוד כזה מתחיל לדרוש התערבות ידנית לעתים קרובות יותר מאשר הוא חוסך זמן למערכת.

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

נקודת כשל שנייה היא קידוד המקור. חלק מהפידים מגיעים בקידוד חד-בייט, חלק ב-UTF-8; בערבוב מתקבלים "ג'יבריש" בכותרים ותווים שבורים בתקצירים. הבעיה אינה בפרסר עצמו, אלא בכך שהנרמול של הקידוד לא הוצא לשלב נפרד לפני הכתיבה לאינפובלוק.

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

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

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

מה משתנה לאחר הגדרת מילוי אוטומטי

לפני הגדרת המילוי האוטומטי, מדור החדשות מתנהל בפרצים: העורך מעביר חומרים ידנית מהפידים, הפרסום מפגר אחרי האירוע בשעות, וחצי מהכרטיסים עוברים לארכיון כלא-רלוונטיים. לאחר חיבור הקונ�вейер, המחזור משתנה — נפרט מה בדיוק ובאילו כמויות.

מהירות הפרסום והעדכניות

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

חלקה של העבודה הידנית

מודרציה ידנית נשמרת במקום שבו היא יוצרת ערך: העורך בודק את הכותרת, התגיות, השיוך לרובריקות ומחליט אם לפרסם או לדחות. ההעברה הגולמית, ניקוי הסימון, הסרת כפילויות וסידור לפי מדורים — אוטומטיות; עליהן מושקע לא זמן המערכת, אלא עבודת הקונ�вейер.

עמידות בפני תקלות במקורות

מקור יכול להחזיר פיד ריק, לשנות את הפריסה או להיות בלתי-זמין — הקונ�вейер לא מפרסם זבל ולא קורס. חומר עם שדות חסרים עובר להסגר, כפילויות נחתכות לפי טביעת אצבע, ובמקרה של אי-זמינות המקור התור ממתין לשחזור ומדביק את מה שהוחמץ.

מה נראה במספרים

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

את סכמת ניתוח הפידים וכללי הפרסום מרכיבים עבור המדור שלכם — על 1С-Битрикс זה נעשה בכלים סטנדרטיים ללא תוספות חיצוניות.

דרכים לאיסוף פידים: השוואת גישות

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

השוואת גישות

אופן העדכון ותדירות הסקירה

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

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

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

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

איך אנחנו מטמיעים פרסינג: שלבי העבודה

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

1. סקירת מקורות. אוספים רשימה של פידים ומדורים שבאמת נחוצים למערכת, בודקים זמינות, יציבות מסירה ומבנה החומרים. מתעדים אילו שדות מועברים — כותרת, תקציר, תאריך, מחבר, תמונות — ואילו מדורים מתאימים להם.
2. סכמת חילוף. מתכננים איך הנתונים נכנסים לאינפובלוקים: התאמת מדורים, כללי המרת טקסט, קישור תמונות, התנהגות בהיעדר שדות חובה. בשלב הזה מסכמים מה לעשות עם חומר שלא עבר בדיקה — לזרוק או לאסוף למדור נפרד לבדיקה ידנית.
3. הגדרת סוכנים. מטמיעים סריקה סדירה של המקורות במרווח נתון, עם טיפול בשגיאות וניסיונות חוזרים בעת תקלות רשת. מתעדים כל מעבר ביומן, כדי שיהיה אפשר לראות כמה חומרים הגיעו, כמה נדחו ומאיזו סיבה.
4. בדיקה לכפילויות. מגדירים התאמה לפי מזהה חיצוני וסימנים בקרה של הטקסט, כדי שסריקה חוזרת לא תיצור עותקים. בנפרד בודקים את ההתנהגות בעת עדכון חומר במקור — תיקון צריך לעדכן רשומה קיימת, ולא ליצור חדשה.
5. הרצת בדיקה. מריצים את המעגל על סט מוגבל של מקורות, משווים את התוצאה לדגימה ידנית, בודקים את העומס על האתר בזמן הסריקה. תיקונים מבצעים לפני הוצאה לכל הפידים.
6. מסירת נהלים. מוסרים תיאור מקורות, כללי התאמת מדורים, סדר הוספת פיד חדש והוראה לבדיקת חומרים שנדחו. המערכת מקבלת סט פעולות ברור בלי לפנות למפתח על כל תיקון.

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

מה הלקוח מקבל לידיו

אנחנו מוסרים לא "סקריפט שמסתובב איפשהו על השרת", אלא ערכה שלפיה ניתן להפעיל את החילוף, להרחיב אותו ולהעביר אותו לקבלן אחר בלי לחפור בקוד של אחרים.

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

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

מקרה בוחן: מילוי אוטומטי של פיד חדשות ללא כפילויות

הלקוח — פורטל ענפי אזורי על 1С-Битрикс עם מערכת עריכה של שני אנשים. החדשות נאספו ידנית: העורך עבר על עשרה מקורות, העתיק טקסט, ניקה את התגיות ופרסם. ביממה יצאו 8-12 חומרים, כאשר שליש מהזמן הוקדש לעבודה מכנית, והפיד בכל זאת פיגר אחרי האירועים בכמה שעות.

מה היה לפני

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

מה שינו

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

מה נהיה

הנפח היומי גדל ל-40-60 חומרים ללא הרחבת מערכת העריכה, וההשהיה מהאירוע עד הפרסום הצטמצמה לדקות. שיעור הכפילויות ירד כמעט לאפס, והעורך עבר לבדיקה ותיקון במקום להעתקה. יציבות הפרסומים הפסיקה להיות תלויה בשאלה אם האדם פנוי בשעה מסוימת.

1С-Битрикс במערך הזה נשאר מערכת הפרסום והאחסון — לוגיקת האיסוף והבדיקות חיה בנפרד ואינה מפריעה לעדכוני הפלטפורמה. אם הפיד שלכם מתמלא ידנית ואתם נתקלים באותה תקרה — תארו את המשימה, נחזור עם הערכה ותוכנית.

במה שונה איסוף חד-פעמי מעדכון מתמשך?

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

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

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

החלק המרכזי כאן אינו האיסוף עצמו, אלא ההגנה מכפילויות ומזבל: כל רשומה נבדקת לפי הקישור הקנוני ולפי hash של הטקסט, כניסות חוזרות נחתכות, חומרים מעודכנים נכתבים מחדש ולא נוצרים מחדש. בלי זה, כעבור חודש בבלוק המידע יימצאו שלושה עותקים של ידיעה אחת עם תאריכים שונים.

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

ארכיון החומרים נשאר שלם: רשומות ישנות אינן נכתבות מחדש, אלא מתווספות בחדשות, ולכן חזרה למצב קודם אפשרית בכל שלב.

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

ספקות טכניים נפוצים

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

האם זה תואם לתבנית הנוכחית ולעיצובי האתר?

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

מה יקרה בהרצה חוזרת של המשימה?

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

כיצד המערכת מתנהגת כאשר המקור אינו זמין?

כשל של המקור לא מפיל את החילוף: מופעלות חזרות עם השהיה הולכת וגדלה, ולאחר מספר כשלים המשימה מסומנת ונשלחת התראה לאחראי. החומרים שכבר נאספו נשארים בבסיס הנתונים, שום דבר לא הולך לאיבוד. כאשר המקור חוזר, היבוא מדביק את מה שהוחמץ לפי תאריכים.

נדון במשימת המילוי האוטומטי שלכם

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

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

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