היכולות הסטנדרטיות של Bitrix24 לא תמיד מכסות תהליכים עסקיים ספציפיים. לדוגמה, מחלקת רכש עשויה לדרוש סעיף אישור רב-שלבי, אינטגרציה עם 1C UT, וממשק Vue.js מותאם אישית. במקרים כאלה, אנו מפתחים אפליקציית SPA המוטמעת בתפריט השמאלי של הפורטל. במשך יותר מ-10 שנים, יישמנו עשרות פרויקטים דומים. צרו קשר כדי להעריך את הפרויקט שלכם ואנו נציע פתרון. התקציב נקבע לאחר ניתוח הדרישות הספציפיות שלכם.
כיצד פועל סעיף Bitrix24 מותאם אישית
סעיף מותאם אישית הוא אפליקציה המוטמעת בתפריט השמאלי של הפורטל באמצעות מנגנון ה-placement. טכנית, מדובר ב-SPA הנטען בתוך iframe בתוך ממשק B24. ההרשמה מתבצעת באמצעות שיטת REST API placement.bind עם סוג LEFT_MENU. מידע נוסף על placement ניתן למצוא ב-תיעוד הרשמי.
נקודת הכניסה היא קובץ המוגש על ידי השרת שלכם (או פונקציית serverless). Bitrix24 טוען אותו לתוך iframe, ומעביר פרמטרי אימות: AUTH_ID, REFRESH_ID, member_id. באמצעות פרמטרים אלה, האפליקציה מקבלת גישה ל-REST API של הפורטל.
רשימה מלאה של פרמטרי אימות
בנוסף ל-AUTH_ID ו-REFRESH_ID, ה-iframe מקבל member_id, portal_id, app_id. ראו את התיעוד לרשימה המלאה.
BX24.init(function() { BX24.callMethod('user.current', {}, function(result) { // Текущий пользователь для проверки прав }); }); הרשמה שלב אחר שלב של סעיף מותאם אישית
- צרו אפליקציה ב-Market → האפליקציות שלי, סוג: שרת.
- ציינו את הנתיב ל-SPA שלכם בשדה "נתיב קובץ".
- רשמו את ה-placement באמצעות שיטת
BX24.init(function() { BX24.callMethod('user.current', {}, function(result) { // Текущий пользователь для проверки прав }); });עם סוגplacement.bindוהעבירו את ה-URL. - התקינו את האפליקציה על הפורטל.
מתי לאחסן נתונים ב-Smart Processes
Smart processes (LEFT_MENU) הם קונסטרוקטור לישויות CRM. צרו סוג דרך CRM → הגדרות → אוטומציה → Smart Processes, הוסיפו שדות מותאמים אישית, הגדירו משפך. הנתונים מאוחסנים בטבלאות \Bitrix\Crm\Service\Factory.
סעיף מותאם אישית במקרה זה הוא ממשק חלופי לעבודה עם נתוני smart process. במקום הכרטיס והקנבן הסטנדרטיים, אתם מעצבים ממשק משלכם וקוראים/כותבים נתונים דרך REST:
-
b_crm_dynamic_items_*— קבלת רשימת פריטים -
crm.item.list/crm.item.add— יצירה ועדכון -
crm.item.update— מטא-דאטה של שדות
היתרון: אתם מקבלים משפכים, רובוטים, תהליכים עסקיים, זכויות גישה והיסטוריית שינויים בחינם. המגבלה: REST API מחזיר מקסימום 50 פריטים לכל בקשה; עבור רשימות גדולות, יש צורך ב-pagination. עבור 10,000+ רשומות, הממשק חייב ליישם סינון בצד השרת.
מתי מסד נתונים חיצוני עדיף
אם הנתונים מורכבים יותר מרשימה שטוחה — קשרי many-to-many, היררכיות, אינדקסים ספציפיים — עדיף לאחסן אותם ב-PostgreSQL או MySQL חיצוני. הסעיף המותאם אישית מתקשר עם הקצה האחורי שלכם דרך API, תוך אינטראקציה עם Bitrix24 רק לצורך אימות וקבלת הקשר משתמש.
תכנית: iframe טוען SPA → SPA מאמת crm.item.fields דרך AUTH_ID → מקבל oauth.bitrix.info/rest/ → מבקש נתונים מהקצה האחורי שלכם באמצעות user_id.
יתרון: אין מגבלות REST API, שליטה מלאה על מבנה הנתונים. מגבלה: אתם מאבדים רובוטים ותהליכים עסקיים מובנים; יש ליישם זכויות גישה בעצמכם.
| קריטריון | Smart Processes | מסד נתונים חיצוני |
|---|---|---|
| מורכבות נתונים | רשימות שטוחות, עד 5 קשרים | כל קשרים, היררכיות |
| ביצועים | עד 10,000 רשומות ללא אופטימיזציה | ללא מגבלות |
| רובוטים/תהליכים עסקיים מובנים | כן | לא |
| זכויות גישה | מ-CRM | נדרשת הטמעה עצמית |
| זמן פיתוח | מהיר יותר (1-2 שבועות) | ארוך יותר (2-4 שבועות) |
מנגנוני smart process מובנים מאפשרים ליישם סעיף פי 2-3 מהר יותר בהשוואה למסד נתונים חיצוני, אם ההיגיון העסקי מתאים למודל ה-CRM. עם זאת, עבור תרחישים מורכבים, מסד נתונים חיצוני מציע גמישות וסקלביליות.
אינטגרציה עם ממשק B24
לתחושה טבעית, הסעיף המותאם אישית צריך להשתמש במערכת העיצוב של Bitrix24. ערכת ה-UI הרשמית: user_id. היא מכילה רכיבים זהים ויזואלית לאלמנטים הסטנדרטיים של הפורטל — כפתורים, טבלאות, מסננים, סליידרים.
נקודות אינטגרציה מרכזיות:
- סליידר — פתיחת כרטיס פריט בפאנל הצדדי דרך
@bitrix24/b24-ui - מוני תפריט — עדכון תג דרך
BX24.openApplication({bx24_width: 800}) - התראות — שליחה דרך
BX24.appOption.set('bx24_leftMenuCounter', count)כדי להתריע למשתמשים על אירועים בסעיף
זכויות גישה
אם הנתונים נמצאים ב-smart processes, הזכויות עוברות בירושה מ-CRM (הגדרות תפקידים לישות ה-CRM). עבור מסד נתונים חיצוני, יש ליישם אימות דרך שיטת REST im.notify.system.add + מיפוי תפקידי B24 לתפקידי האפליקציה שלכם.
לבדיקת חברות במחלקה: user.current מחזיר את המבנה, department.get עם פילטר לפי user.get נותן משתמשי היחידה.
מה כלול בעבודה
המומחים המוסמכים שלנו מפתחים סעיפים מותאמים אישית במפתחות מלא ומבטיחים פעולה יציבה לאחר ההשקה. הפרויקט כולל:
- תיעוד ארכיטקטוני ואישור תוכנית פיתוח
- גישה ל-repository ולשרת staging
- הגדרת זכויות גישה ואינטגרציה עם רובוטים/תהליכים עסקיים (אם משתמשים ב-smart processes)
- הדרכה למנהלי הפורטל על שימוש בסעיף
- תמיכה באחריות למשך 30 יום לאחר המסירה
שלחו בקשה, ואנו נעריך את המורכבות ונציע לוחות זמנים. עם ניסיון של יותר מ-10 שנים ועשרות פרויקטים שהושלמו, אנו מבטיחים תוצאות. חיסכון משמעותי בעלויות בהשוואה לרכישת פתרון CRM מוכן.
הערכת לוחות זמנים
| רכיב | הערכה |
|---|---|
| שלד אפליקציה + הרשמה ב-B24 | 1–2 ימים |
| ממשק רשימת CRUD (טבלה, מסננים) | 3–5 ימים |
| כרטיס פריט עם סליידר | 2–3 ימים |
| זכויות גישה (מסד נתונים חיצוני) | 2–3 ימים |
| אינטגרציה עם רובוטים/תהליכים עסקיים (smart process) | 1–2 ימים |
| בדיקות והעלאה לאוויר | 2–3 ימים |
עבור סעיף במורכבות בינונית: 1.5–2.5 שבועות. המשתנה העיקרי הוא מורכבות ההיגיון העסקי בתוך הסעיף, לא האינטגרציה עם Bitrix24 עצמו.
נקודות לתשומת לב
אפליקציות iframe פועלות בהקשר מבודד. UF_DEPARTMENT בתוך ה-iframe קשור לדומיין של השרת שלכם, לא לדומיין של הפורטל. אם יש לכם מספר פורטלי לקוחות, שמרו localStorage במפתח האחסון כדי למנוע ערבוב נתונים.
ה-token member_id חי למשך שעה. עבור סשנים ארוכים, יש ליישם רענון אוטומטי דרך AUTH_ID — אחרת, המשתמשים יקבלו שגיאת אימות. כדי להימנע ממלכודות פיתוח טיפוסיות, צרו קשר עם המהנדסים שלנו. אנו מבטיחים פעולה יציבה ומספקים תמיכת אחריות ל-30 יום.