אתר מועדון ספורט על 1C-Bitrix: מלוח זמנים למערכת כרטוס

אתר מועדון ספורט: מלוח זמנים ועד מרצ'נדייז על 1C-Bitrix

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

איך לתכנן מבנה נתונים למועדון ספורט?

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

• קבוצות — אינפובלוק ראשי המקושר לסוג ספורט, ליגה, עונה. מאפיינים: סגל (קישור לאינפובלוק "שחקנים"), צוות אימון, לוגו, צבעי מדים.
• שחקנים — אינפובלוק עם פרופילים מפורטים: שם מלא, עמדה, מספר, אנתרופומטריה, תמונת מדים, סטטיסטיקת עונה (שערים/נקודות/אסיסטים המאוחסנים ב-Highload בלוק נפרד לשליפה מהירה).
• משחקים ואימונים — Highload בלוק (b_hlblock_schedule), כי במשך מספר עונות יש אלפי רשומות. שדות: תאריך/שעה, סוג (אימון/משחק/ידידות), קבוצה ביתית, קבוצה אורחת, אצטדיון, סטטוס (מתוכנן/בתהליך/הסתיים/נדחה), תוצאה.
• טורנירים — אינפובלוק המקושר לעונה. טבלת הטורניר נוצרת על ידי רכיב מותאם אישית המבוסס על תוצאות משחקים מה-Highload בלוק.

קישורים בין אינפובלוקים מיושמים באמצעות מאפיין מסוג "קישור לאלמנטים" (E) או דרך ספריות Highload אם יש צורך בביצועים בסלקציות.

למה להשתמש ב-Highload בלוקים לתזמון?

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

Highload בלוק נבחר מסיבה טובה: עם 300+ משחקים בעונה ו-5-6 קבוצות במועדון, אינפובלוק רגיל מתחיל לפגר בפילטרים מורכבים. Highload בלוק מאחסן נתונים בטבלת MySQL נפרדת, שאילתות עוברות ישירות ללא תקורה של ה-API של אינפובלוק. השוואה: Highload בלוקים מעבדים שאילתות פי 5 מהר יותר מאינפובלוקים בסלקציות של 10,000 רשומות.

סינון בצד הלקוח: לפי קבוצה, לפי סוג אירוע, לפי חודש. הרכיב מציג רשת לוח שנה עם אינדיקטורים צבעוניים — אפור לאימונים, ירוק למשחקי בית, כחול למשחקי חוץ. לקידום אורגני (SEO), לכל משחק יש דף פרטים משלו עם כתובת URL קריאה כמו /matches/2024-25/spartak-vs-dinamo-12-10/.

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

איך עובדת מערכת הכרטוס עם בחירת מושבים

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

פתרון ארכיטקטוני: כל אצטדיון (אולם, זירה) מתואר בקובץ SVG, שבו כל מושב הוא אלמנט <rect> או <circle> נפרד עם מאפיינים data-sector, data-row, data-seat. ה-SVG נטען לדפדפן, מטפל JavaScript אחראי על אינטראקטיביות: הדגשה בריחוף, בחירת מושב בלחיצה, הצגת מושבים תפוסים באפור.

אחסון מושבים ומצבים: נוצר Highload בלוק hl_stadium_seats עם שדות:

עבור כל משחק, נוצרת טבלת הזמנות — Highload בלוק נוסף hl_ticket_bookings:

תהליך רכישה שלב אחר שלב:

1. המשתמש פותח את דף המשחק, תוכנית ה-SVG נטענת.
2. בקשת AJAX לבקר REST מקבלת את מערך המושבים התפוסים למשחק זה. JavaScript צובע אותם באפור ומסיר את מטפל הלחיצה.
3. המשתמש לוחץ על מושב פנוי — הוא מסומן כ-reserved ב-hl_ticket_bookings עם חותמת זמן. ההזמנה חיה 15 דקות, ואז סוכן cron (CTicketReserveAgent) מנקה הזמנות שפגו.
4. המושבים הנבחרים מתווספים לעגלה של מודול sale כפריטי מוצר. לשם כך, כל אזור מחיר מיוצג על ידי הצעת סחר בקטלוג. מאפיין העגלה SEAT_INFO מאחסן נתונים מסודרים על המושב הספציפי.
5. התשלום הוא סטנדרטי — sale.order.ajax עם תבנית מותאמת אישית. בתשלום מוצלח, הסטטוס משתנה ל-sold, ונוצר כרטיס PDF עם קוד QR באמצעות ספריית TCPDF.
6. ה-QR מכיל טוקן חתום (HMAC-SHA256), המאומת בכניסה על ידי סורק.

גישה מקבילה היא קריטית. שני אוהדים לא יכולים להזמין את אותו מושב. פתרון: UPDATE ... WHERE UF_STATUS = 'free' עם בדיקת שורות מושפעות. אם הוחזר 0 — המושב כבר תפוס, הפרונטאנד מציג הודעה ומצייר מחדש את ה-SVG.

למה לחבר טבלאות טורנירים דרך רכיב מותאם אישית?

הרכיב המותאם אישית custom:tournament.table מאגד נתונים מה-Highload בלוק של משחקים: מחשב נקודות (3 לניצחון, 1 לתיקו), הפרש שערים, וממיין. התוצאה נשמרת במטמון עם התג tournament_{ID}, שנמחק כאשר התוצאה של כל משחק בטורניר זה מתעדכנת.

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

פרופילי שחקנים

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

לקידום אורגני (SEO) — מיקרו-סימון schema.org/Person עם athlete בשדה jobTitle, מקושר ל-schema.org/SportsTeam.

אזור אוהדים וחנות מרצ'נדייז

מדור החדשות מיושם עם הרכיב הסטנדרטי news.list / news.detail עם תבנית מותאמת אישית. גלריית תמונות ווידאו — אינפובלוק המקושר למשחקים ושחקנים.

חנות המרצ'נדייז היא חנות מקוונת מלאה על המודול catalog + sale: חולצות, צעיפים, מרצ'נדייז. הצעות סחר לפי מידה וצבע, אינטגרציה עם 1C לניהול מלאי. היא פועלת במקביל למערכת הכרטוס אך בסוג אינפובלוק נפרד כך שקטלוג המוצרים אינו מתנגש עם כרטיסים.

אינטגרציה עם מפעילי כרטוס

אם המועדון מוכר כרטיסים לא רק דרך האתר שלו אלא גם דרך Ticketland, Kassir.ru או מערכות דומות, יש צורך בסנכרון. זה מיושם דרך ה-REST API של מפעיל הכרטוס: כאשר מתרחשת הזמנה/מכירה בצד המפעיל, webhook מעדכן את הסטטוס ב-hl_ticket_bookings. ולהיפך — מכירה באתר שולחת נתונים למפעיל.

סוכן סנכרון cron פועל כל 2 דקות כדי לשלוף שינויים שאולי לא הגיעו דרך ה-webhook (כשלי רשת, פסקי זמן).

שלבי פיתוח

מה כלול

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

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