למה אפליקציה מ-Bitrix24 Marketplace מתנגשת עם הפורטל
הפורטל עובד ביציבות חודשים — ואז מפסיק אחרי שהתקינו אפליקציה מהקטלוג. הסנכרון עם מערכת הנהלת החשבונות מתבצע עם פערים, חלק מהעובדים מאבדים גישה לאזורים שלהם, וביומן במקום שגיאה מובנת מופיעות הודעות ממטפל זר. פורמלית הכול עבר בהצלחה: עדכון הפורטל הוחל, האפליקציה הותקנה בלי שגיאות.
הסיבה היא שהתקנת אפליקציות ב-Bitrix24 Marketplace כמעט לעולם אינה מבודדת. האפליקציה רושמת מטפלי אירועים משלה, מוסיפה שדות לישויות, ונרשמת לשינויים בעסקאות, במשימות ובמשתמשים.
אם לאותו אירוע כבר רשום הסנכרון שלכם עם מערכת הנהלת החשבונות, סדר ההפעלה אינו מובן מאליו: הפעולה מתבצעת פעמיים או לא מתבצעת כלל — זהו בדיוק קונפליקט אינטגרציות.
קו נפרד — הרשאות הגישה של האפליקציות. כדי לפעול, האפליקציה מבקשת גישה לישויות ולעיתים קרובות מקבלת אותה רחבה יותר מהפונקציה המוצהרת. הפרדת התפקידים אחרי זה מתפרקת: העובד רואה אזורים מיותרים, והבדיקות המובנות מפסיקות להיות נקודת הבקרה היחידה.
בהמשך פועל אפקט מושהה: עדכון הפורטל משנה את התנהגות המתודות, האפליקציה אינה מוכנה לכך, ומה שעבד שנים מתנתק. לא ניתן למצוא את הטריגר בלי יומן אירועים והשבתה מדורגת של הרשמות — לכן אנחנו מתחילים ממפת המטפלים וההרשאות, ולא מהתקנה מחדש.
נסביר כיצד מתגלה וממוקד תקלה כזו ומה לבדוק לפני ההתקנה כדי לא לתפוס אותה על פורטל חי.
מה משתנה אחרי סדר באפליקציות
סדר באפליקציות הוא לא ניקיון חד-פעמי, אלא מעגל: רשימת הפתרונות המאושרים, נוהל עדכונים ויומן התקנות. ב-Bitrix24 Marketplace קיימים לכך מנגנונים מובנים, אבל האפקט מופיע כשהם מעוגנים בכללים ולא נשענים על הזיכרון של המנהל.
עדכונים מפסיקים לשבור את הפורטל
העדכון עובר קודם בסביבת בדיקות, ואחר כך מותקן בחלון עבודה של עומס נמוך, עם נקודת שחזור לגרסה הקודמת. שיעור התקלות אחרי ההתקנה יורד מ«כל שני» לבדיקת מקרים בודדים, והסיבה לכל אחד מהם נראית ביומן ההתקנות — באופן משוחזר, ולא לפי ניחושים.
לוחות הזמנים להתקנה ולהוצאה משימוש של פתרון נעשים צפויים
ברור אילו הרשאות האפליקציה צריכה, עם אילו ישויות היא עובדת ומה יישאר אחרי הסרה. ההתקנה וההוצאה משימוש של הפתרון נכנסות לחלון שהוגדר מראש, ולא נמשכות לתקופה בלתי מוגבלת בגלל תלויות נסתרות.
העומס על התמיכה יורד
פניות טיפוסיות — «נשבר אחרי העדכון», «מי התקין את האפליקציה הזו», «למה גדלו ההרשאות» — נסגרות בהפניה לנוהל וליומן. סוג תקלות שטופל מפנה לצוות זמן למשימות פיתוח, ולא לניתוח ההשלכות.
היציבות של הפורטל מפסיקה להיות תלויה באדם אחד
הכללים, התפקידים וסדר אישור העדכונים מעוגנים, ולכן החלפה של מנהל או של קבלן לא עוצרת את העבודה. הרכב האפליקציות והגרסאות שלהן תמיד ידועים — וזהו ניהול אפליקציות כתהליך.
פורמטים של חיבור: אפליקציה מ-Bitrix24 Marketplace ופיתוח עצמאי
ההתלבטות עולה כבר בהתחלה: לסגור את הצורך בפתרון מוכן מהקטלוג או לכתוב אחד משלנו. התשובה תלויה לא בגודל המשימה, אלא בחלק של הלוגיקה הייחודית שבה ובתדירות שבה הלוגיקה הזו תשתנה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אפליקציה מוכנה מ-Bitrix24 Marketplace | צורך טיפוסי: ערוץ תקשורת, דיווח, סנכרון עם שירות חיצוני | הלוגיקה, השדות וההרשאות מוגבלים להגדרות של מפתח האפליקציה — כלל לא-סטנדרטי לא ניתן להוסיף כאן |
| פיתוח עצמאי | נהלים משלנו, חיבור למערכת הנהלת החשבונות, תפקידים שאינם במודל הטיפוסי | תכנון, בדיקות וקבלה ארוכים יותר; עדכוני הפלטפורמה מלווים על ידינו |
| היברידי | ליבה מוכנה מכסה את רוב המשימה, וצוואר הבקבוק דורש התאמה | שינויים בקוד של אחרים: עדכון האפליקציה עלול לדרוס אותם |
בנפרד אנחנו בודקים כיצד האפשרות הנבחרת תשרוד עדכון פלטפורמה. אפליקציות מוכנות מעודכן המפתח שלהן, אבל לא תמיד בלוחות זמנים נוחים לנו, וקוד עצמאי דורש הרצה חוזרת של התרחישים בכל מהדורה.
בפועל הבחירה לעיתים רחוקות בינארית. אנחנו מפרקים את הדרישות לסעיפים, מסמנים מה מכסה אפליקציה מוכנה, ומשאירים קוד עצמאי רק במקום שבו הוא נותן אפקט מדיד: מהירות עיבוד, צמצום פעולות ידניות, כללי גישה משלנו. כך נפח התמיכה נשאר צפוי, והמערכת לא מתכסה במודולים כפולים.
סדר ההטמעה: מאודיט של פתרונות מותקנים ועד למסירה
לפני שמשנים פורטל עובד, אנחנו מתעדים את המצב הקיים: אילו אפליקציות מותקנות, מי המפתח שלהן, אילו הרשאות הן ביקשו ומה באמת בשימוש. בלי מיפוי, ההתקנה הופכת להגרלה — קונפליקט גרסאות או גישה מיותרת צפים כבר אחרי ההשקה.
- אודיט הפורטל — מייצאים רשימה של אפליקציות, Webhooks, תהליכים עסקיים ורובוטים. מסמנים כפילויות, פתרונות שאינם בשימוש והרשאות גישה מיותרות: מקבלים מפת סיכונים.
- תרשים קשרים — מציגים כיצד הפתרונות מחליפים נתונים עם ה-CRM, המשימות והדיסק: היכן מקור האמת, והיכן כפילות. את התרשים מאשרים לפני תחילת העבודות.
- תוכנית הטמעה — שלבים בסדר התקנה נכון: קודם תלויות, אחר כך תוספים. מתעדים מה מעבירים ומה מכבים.
- סביבת בדיקות — פורסים העתק של מבנה הפורטל ומריצים עליו הרשאות, תפקידים ותרחישים. שגיאות לא מגיעות לבסיס הנתונים העובד.
- בדיקת אינטגרציות — עוברים על תרחישי קצה-לקצה במלואם: פנייה, עסקה, חשבונית; משימה, התראה, דוח. משווים את הסנכרון עם 1C ואת הייצוא לאנליטיקה.
- מסירת תיעוד — מוסרים נהלים: הרכב האפליקציות, הבעלים, סדר העדכון, פעולות בעת תקלה. בנוסף הדרכת עובדים.
מכאן הפורטל חי לפי הנהלים האלה: אפליקציות חדשות מותקנות לפי הסדר המתואר, ולא «על החי».
מה נשאר במעגל של הלקוח: ארטיפקטים ונהלים
הגדרת Bitrix24 Marketplace היא לא רק האפליקציות המותקנות, אלא גם שכבת הניהול שלהן, שנשארת אצלכם. אחרי המסירה יש ללקוח סט ארטיפקטים שלפיהם הצוות הפנימי מתקין, מעדכן ומסיר אפליקציות בלי לפנות אלינו.
- תרשים אינטגרציות: אילו אפליקציות מקושרות לפורטל, דרך אילו חשבונות והרשאות, היכן נמצאים מפתחות הגישה ומי אחראי על החלפתם.
- מטריצת הרשאות גישה: תפקידי מנהל, אינטגרטור ועובד עם סט הרשאות מינימלי מספיק — התקנת אפליקציות מופרדת מהגישה לנתונים.
- נוהל עדכון: היכן נבדקות גרסאות חדשות, באיזה חלון מותקן העדכון, מי מקבל את ההחלטה ובאילו תנאים המהדורה נדחית.
- נוהל חזרה לאחור: צילום של הקונפיגורציה לפני השינויים, תקופת שמירה, אחראי וקריטריון להפעלת החזרה — עדכון כושל הופך לפעולה מתוכננת ולא לתקלה.
- הוראות לצוות: תזכירים שלב-אחר-שלב «להתקין אפליקציה», «לתת גישה», «לכבות אינטגרציה» עם התוצאה הצפויה בכל שלב.
- יומן שינויים: מה ומתי השתנה ב-Marketplace, מי ביצע את השינוי, אילו נתונים נשארים בפורטל אחרי הסרת האפליקציה.
- מפת אחראים: מי בצד הלקוח מקבל החלטות בנוגע לאפליקציות, למי לפנות בעת תקלה ומי מחזיק את הגישות.
המסמכים האלה חיים יחד עם הפורטל: בהחלפת מנהל, באודיט או בחיבור מהנדס משלכם ההקשר משוחזר לפי רישומים, ולא לפי הזיכרון.
מקרה בוחן: פורטל עם עשרות אפליקציות הועבר לעדכונים מנוהלים
הפורטל של הלקוח — מערכת ארגונית שאליה מחוברות כמה עשרות אפליקציות מ-Bitrix24 Marketplace: משימות, ניהול מסמכים, דיווח, החלפת נתונים עם שירותים חיצוניים. הן הותקנו ועודכנו ידנית: המנהל העלה גרסה חדשה ישירות לפורטל העובד ונודע לו על קונפליקטים מפניות של עובדים. כל עדכון הפך לעבודת ערב עם סיכון לחזרה לאחור מגיבוי.
מה הראו המדדים לפני
מתוך עשרים עדכונים ברבעון, כל שלישי הסתיים בחזרה לאחור: פער בין גרסת הליבה לגרסת האפליקציה שבר תהליכים עסקיים. זמן ההשבתה של הפורטל ברגעים כאלה הגיע לכמה שעות, והתמיכה השקיעה יותר ממחצית הזמן בניתוח ההשלכות במקום בפיתוח המערכת. לא הייתה תמונה אחת של מה ומתי עודכן — הרשימות נוהלו בטבלה וסטו מהמצב בפועל.
מה שינו ומה יצא מזה
הרכבנו מעגל מנוהל: פורטל בדיקות עם העתק של הנתונים, שבו העדכון נבדק לפני היציאה לפורטל העובד, סדר התקנה קבוע, נקודת שחזור לפני כל שינוי ויומן לכל אפליקציה. העדכונים הפכו מתוכננים — עם חלון שמסוכם עם העסק.
שיעור החזרות לאחור ירד משליש למקרים בודדים, והחזרה לגרסה קודמת אורכת דקות במקום שחזור מגיבוי. הפניות לתמיכה בנושא «המודול נפל» הצטמצמו בערך פי שלושה — והזמן שהתפנה עבר להתאמות. האחריות מעוגנת: לכל אפליקציה יש בעלים, גרסה עדכנית ורישום ביומן השינויים.
מה לעשות אם הפורטל כבר עמוס באפליקציות צד שלישי?
פורטל שעובד כמה שנים כמעט תמיד התכסה באפליקציות מ-Marketplace ובהתאמות: חלק מהמשימות כבר נסגרו בכלים אחרים, חלק מחזיק הרשאות גישה מיושנות, והמנהל לא זוכר מי התקין אותן.
המורשת של האינטגרציות מסוכנת לא בכמות, אלא בכך שהקשרים בין אפליקציות, רובוטים ותהליכים עסקיים לא מתועדים בשום מקום.
מתחילים במיפוי האפליקציות: אוספים רשימה של המותקן, אזורי הגישה שהתבקשו, הבעלים, ובעיקר — מי קורא לכל אפליקציה. המקור הוא יומני הפניות ואירועי הפורטל, ולא הזיכרון של הצוות: כך רואים גם אפליקציות בלי קריאות במשך חודשים, וגם כאלה שעובדות בשקט ברקע.
בהמשך — ניהול סיכוני הכיבוי. אפליקציה מועברת למצב תצפית: מכבים תרחישים פעילים, משאירים את הנתונים, ובמשך שניים-ארבעה שבועות בודקים את היומנים לשגיאות ולפניות.
תאימות גרסאות נבדקת בנפרד: חלק מהאפליקציות כרוכות בגרסת הליבה ואחרי עדכון הפורטל מתחילות להחזיר שגיאות, ולכן מריצים אותן קודם על העתק.
הוצאה מדורגת משימוש נבנית לפי העיקרון «קודם החלפה, אחר כך כיבוי»: כפילויות ואפליקציות בלי קריאות, אחר כך אלה שלוגיקתן נסגרת על ידי רובוטים ותהליכים עסקיים מובנים, ורק לבסוף אלה שדורשות העברת נתונים. בכל שלב — נקודת חזרה לאחור: העתק של הפורטל, הגדרות ומפתחות שמורים.
הסדר מושג בלי לעצור תהליכים עסקיים: הפורטל נשאר עובד, העומס מאפליקציות מיותרות יורד, והתמיכה מקבלת מפת אינטגרציות מעודכנת.
התנגדויות טכניות נפוצות להתקנת אפליקציות
רוב הספקות עולים לא סביב ההתקנה עצמה, אלא אחריה: מה יקרה לפורטל העובד, מי אחראי על העדכונים, האם ייפגע הסנכרון עם 1C. להלן תשובות למה שנשאל הכי הרבה לפני חיבור אפליקציה מ-Marketplace.
ההתקנה תעצור את הפורטל?
לא. האפליקציה מותקנת על פורטל עובד ואינה דורשת העברתו למצב תחזוקה. סיכון מופיע רק במקום שבו האפליקציה מחליפה מטפלים מובנים או פונה לליבה — מקרים כאלה אנחנו בודקים בנפרד ומכניסים לחלון עבודה מסוכם.
האפליקציה תפסיק להתעדכן?
לפני ההתקנה אנחנו בודקים את תאריך הבנייה האחרונה, את היסטוריית השינויים ואת פעילות התמיכה. אם האפליקציה נטושה, אנחנו פורסים אותה במעגל שלנו ולוקחים על עצמנו את העדכונים — ואת התאימות לענף הפלטפורמה העדכני עוקבים בעצמנו.
האם זה ישפיע על החלפת נתונים עם 1C?
אפליקציות מובנות עובדות דרך אותם מטפלים כמו שאר המודולים ואינן נוגעות בכללי ההחלפה. אנחנו מתעדים את תרשים ההחלפה לפני ההתקנה, ואחריה מריצים החלפה לבדיקה ומשווים את הרכב השדות בשני הצדדים.
איך בודקים את אבטחת האפליקציה?
אנחנו בודקים את ההרשאות המבוקשות, את הכתובות החיצוניות שאליהן עוברים הנתונים ואת קיום ההצפנה בהעברה. אפליקציה שזקוקה לגישה לכל הפורטל בשביל כפתור אחד — סיבה לוותר עליה או לצמצם את הרשאותיה למינימום.
מה עם רישיונות ומי אחראי אחרי המסירה?
הרישיון נרשם על הפורטל שלכם, ולא על חשבון שלנו — בהחלפת קבלן הגישה נשארת אצלכם. אחרי המסירה אתם מקבלים את תרשים ההתקנה, רשימת אפליקציות עם הרשאות וסדר עדכונים; את הליווי אנחנו מבצעים לפי נוהל, ולא לפי פנייה נקודתית.
נדון במשימה: נכין תוכנית והערכה לפורטל שלכם
כדי שתוכנית העבודה תישען על עובדות ולא על שיקולים כלליים, אנחנו מתחילים בניתוח הפורטל: בודקים אילו אפליקציות מ-Bitrix24 Marketplace כבר מותקנות, מי המפתח שלהן וכיצד הן מתעדכנות.
אחרי הניתוח אתם רואים את התמונה המלאה — מה עומד כעת, מה מכפיל אחד את השני, והיכן האפליקציה גוררת אחריה הרשאות מיותרות. משם אנחנו קובעים את הגבולות: מה סוגרים בפרויקט הזה ומה מוציאים לשלב נפרד, כדי שהנפח לא יתפשט במהלך העבודות.
- מה אנחנו בודקים בכניסה: הרשאות מנהל, מבנה הפורטל, רשימת האפליקציות המותקנות ומקורותיהן, הפרדת ההרשאות לפי תפקידים.
- איך מתארים את היקף העבודות: התקנה, עדכון, החלפה או הסרה של אפליקציות, הגדרת תפקידים, חיבור למערכת הנהלת החשבונות.
- סדר ההערכה: לפי שלבים, עם התלויות ביניהם והפרדה מפורשת — מה אנחנו עושים ומה נשאר בצד שלכם.
- שלבי הפרויקט: ניתוח הפורטל, אישור ההיקף, עבודות בסביבת בדיקות, העברה לפורטל העובד, בדיקות קבלה, מסירת נהלים.
- קריטריוני קבלה: מה נחשב לתוצאה של כל שלב ואיך בודקים שאפליקציה חדשה לא שוברת תרחישים קיימים.
- באיזו צורה מוסרים את התוצאה: תוכנית עבודה, מרשם אפליקציות עם אחראים וסדר עדכון, כללי מתן הרשאות, הוראות למנהל הפורטל.
תארו את המשימה בצורה חופשית — מהו הפורטל, אילו אפליקציות דרושות ומה לא מתאים כרגע. נחזור עם תוכנית עבודה, היקף, סדר הערכה ולוחות זמנים לפי שלבים, עם נקודות אישור בכל שלב.