בדיקת מקרי השימוש הזמינים לקמפיינים של מותג

בחרו מותג קיים בחשבונכם

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

בנו את אפשרויות מקרי השימוש על סמך תוצאה זו

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

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

טענו את הדרישות למקרה השימוש שנבחר

לאחר שהלקוח בוחר ערך של מקרה שימוש שהוחזר, שלחו בקשה אל /tcr/v2/campaignBuilder/brand/{brand_id}/usecase/{usecase} עבור אותו מותג. התגובה הזו מספקת את הגבולות החלים על מקרי שימוש משניים ואת הדרישות הייחודיות למפעילים. השתמשו בה כדי לאסוף דוגמאות להודעות, הסכמה והצהרות נדרשות נוספות. רשימת הזכאות לבדה אינה מספיקה לבניית בקשה מלאה לרישום קמפיין.

בדקו בנפרד את התמחור בחשבון

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

רעננו כאשר המותג או מקרה השימוש משתנים

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

בקשה

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

שלחו בקשת GET עם מזהה המותג בנתיב כתובת האינטרנט. אין צורך בגוף בקשה.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID"

תגובה

נתיב TCR הנוכחי מחזיר ישירות את גוף ה־JSON של המרשם ושומר על קוד המצב שלו בפרוטוקול HTTP. הוא אינו מוסיף את מעטפת status/response הישנה של v3. הדוגמה הבדיונית המקוצרת אינה תוצאת זכאות שהתקבלה בזמן אמת. בדקו את קוד המצב של HTTP ואת מבנה ה־JSON הצפוי לפני השימוש בתגובה. הפורטל הנוכחי מצפה לרשימה של רשומות זכאות, שכל אחת מהן מזהה usecase. הוא משלב את הרשומות האלה עם קטלוג usecase לקבלת תוויות תצוגה וקורא בנפרד את המחירים ללקוח. ייתכן שיופיעו שדות נוספים של הספק.

מבנה תגובה להמחשה; אין אלה נתוני חשבון בזמן אמת או הצעת מחיר עדכנית.

[
  {
    "usecase": "2FA"
  }
]

שגיאות

• 401: אימות החשבון נכשל. בדקו את פרטי ההזדהות ל־API, את מצב ההפעלה ואת ההגבלות החלות על כתובת רשת המקור.
• 404: המותג אינו משויך לחשבון שעבר אימות, או שהספק אינו מצליח למצוא את המותג או את הבחירה המבוקשים. אם בדיקת הבעלות המקומית נכשלת, מוחזר סירוב לפני שליחת בקשה לספק.
• שגיאות אחרות של המרשם: קוד המצב של HTTP וגוף התגובה שהתקבלו מהשירות שבמעלה הזרם נשמרים. מקרה שימוש שאינו תקין או אינו זמין אינו תוצאה מוצלחת עם קבוצת דרישות ריקה.
• 429: הושגה מגבלת הבקשות של החשבון או המגבלה המשותפת של הספק. פעלו לפי Retry-After.
• 502/503: כשל בזמינות התעבורה, הספק או מגביל קצב הבקשות. שמרו את הטופס ונסו שוב תוך הגדלת ההשהיה בין ניסיונות.

זמינות והשפעות נלוות

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