פיתוח מחלקות ב-D7 API עבור 1С-ביטריקס — גישה מודרנית

מדוע מטפלים ישנים ב-1C-Bitrix שוברים עדכונים

מטפלים מיושנים ב-1C-Bitrix נשענים על אירועים של הליבה הישנה ועל שאילתות ישירות למסד הנתונים בעקיפת המנגנונים התקניים. כל עוד הפלטפורמה אינה נגעת, הסכמה עובדת שנים.

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

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

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

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

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

מה נותן המעבר ל-D7 API: תוצאות מדידות

המעבר ל-D7 API משנה לא את "סגנון הקוד", אלא את התנהגות המערכת תחת עומס. הגישה הישנה מבוססת הליבה עם CIBlockElement::GetList ומשתנים גלובליים גוררת אחריה שאילתות מיותרות לבסיס הנתונים ולמטמון שאי אפשר לבטל באופן ממוקד.

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

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

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

האצת הפיתוח כאן היא תוצאה, ולא מטרה בפני עצמה. כאשר שאילתות, הרשאות ומטמון מתוארים באופן אחיד, פונקציונליות חדשה משתלבת בתבניות קיימות בלי להעתיק בלוקים של לגאסי. התמיכה מצטמצמת לתיקון של מחלקה ספציפית, ולא לארכיאולוגיה ב-component.php עם שברי ליבה ישנה. עבור פרויקטים על 1C-Bitrix זה אומר שהתאמות ל-1С ול-Bitrix24 לא שוברות מדורים שכבר עובדים.

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

ORM, אירועים וקאשינג: מצבי עבודה עם נתונים

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

היכן איזה מצב מתאים

ORM ב-1C-Bitrix — זה לא עטיפה מעל SQL, אלא שכבה עם טעינה דחויה של קשרים. אם מושכים ישויות מקושרות בלולאה, מתקבלת הבעיה הקלאסית N+1: במקום שאילתה אחת יוצאות מאה. הפתרון הוא שליפת השדות הדרושים וטעינה חמדנית של קשרים מראש.

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

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

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

כיצד אנו מיישמים D7 API: שלבי העבודה

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

אבחון ומפת תלויות

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

מיגרציה ופיתוח

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

מדוע בשלבים ולא בשחרור אחד

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

מה אתם מקבלים: מחלקות, סכמות, תיעוד

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

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

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

מקרה בוחן: האצת טעינת הקטלוג פי 3 לאחר מעבר ל-D7 API

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

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

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

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

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

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

במה D7 API שונה מהליבה הישנה ומה לעשות בעת מיגרציה

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

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים בעבודה עם D7 API

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

מה יקרה עם המטמון והביצועים?

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

כיצד מתבצעת ההגירה ללא השבתה?

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

מי יתחזק את הקוד לאחר המסירה?

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

עד כמה זה מסוכן לפרויקט הנוכחי?

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

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

בואו נדון במשימה שלכם בפיתוח על D7 API

פיתוח על D7 API מתחיל לא בקוד, אלא בפירוק המשימה: אילו ישויות כבר קיימות בפרויקט, מה חי בקוד legacy, והיכן עוברים הגבולות עם 1С ומערכות חיצוניות.

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

כדי שהדיון במשימה יהיה ענייני, שלחו את מה שכבר קיים: תיאור תהליך העסקי, תרשים החלפת נתונים עם 1С, גישות למאגר הקוד או לסביבת הבדיקות. אם אין תיעוד — לא проблема, המהנדסים שלנו ישחזרו את התמונה לפי הקוד והלוגים. ככל שיהיה יותר הקשר בהתחלה, כך ההערכה תהיה מדויקת יותר והפתעות בשלב ההטמעה יהיו פחותות.

לאחר מכן העבודה מתנהלת לפי שלבים ברורים:

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

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