עדכון אפליקציות Bitrix24 Marketplace: סוגים, OAuth, מיגרציה

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

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

סוגי עדכונים ומורכבותם

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

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

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

עדכון מרכזי — היקפי OAuth חדשים, שינויי מונטיזציה, נקודות הטמעה חדשות. מחזור מודרציה מלא 7–14 ימים. חשוב: התקנות קיימות לא מקבלות אוטומטית היקפים חדשים; המשתמשים חייבים לאשר הרחבת היקפים.

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

תמיכה מקצועית בעדכונים עולה בממוצע 40% פחות מאשר פיתוח מאפס באופן עצמאי. עבור עדכון מרכזי טיפוסי בעלות של $5,000–$15,000, זה מתורגם לחיסכון של $2,000–$6,000 לכל שחרור.

פתרון בעיית הרחבת היקפי OAuth

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

1. התקנה מחדש כפויה — בעת פתיחת האפליקציה, בדקו את ההיקפים בטוקן והציגו כפתור "התקן מחדש".
2. הרחבה הדרגתית — תהליך OAuth נפרד המבקש רק את ההיקף החדש.
3. תכנון מראש — בקשת כל ההיקפים בהתחלה, מה שמפשט עדכונים עתידיים. הרחבה הדרגתית ידידותית למשתמש פי שלושה מהתקנה מחדש כפויה.

התיעוד הרשמי REST API ממליץ על האפשרות השנייה כידידותית ביותר למשתמש.

שיקולים להעברת נתונים

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

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

for migration in get_pending_migrations():
    try:
        migration.up()
        mark_as_applied(migration)
    except Exception as e:
        rollback()
        log_error(e)

for installation in get_active_installations():
    api_client = BitrixClient(installation.member_id)
    api_client.call('placement.bind', {
        'PLACEMENT': 'NEW_PLACEMENT_POINT',
        'HANDLER': 'https://app.example.com/iframe/new-feature',
        'TITLE': 'Новая функция'
    })
    time.sleep(0.5)