במסמך הזה מתוארים השלבים שמפעילי תחבורה ציבורית (PTO) ומשלב המערכת שלהם צריכים לבצע, שמכונה בהמשך 'מנפיק', כדי לספק הטמעה של Motics ב-Google Wallet.
1. השלמת הדרישות המוקדמות
- חותמים על הסכם סודיות (NDA) עם Google. טופס 'קליק לאישור' זה משותף על ידי צוות הפיתוח העסקי (BD) של Google.
- שילוב עם Google Wallet API הרגיל עבור קודי QR:
- המנפיק משתמש ב-Google Wallet API כדי להקצות כרטיסים ולהוסיף אותם לאפליקציית Google Wallet של המשתמש. מומלץ לעיין במסמכי התיעוד בנושא קודי QR לתחבורה ציבורית ולהשלים את הדרישות המוקדמות לשילוב עם ה-API.
- עליכם להירשם לשירות VDV eTicket כדי לקבל מזהה בעלים (orgId) ואת פרטי ה-PKI הרלוונטיים שנדרשים ל-Motics.
2. הטמעה טכנית
בשלב 2 מפורטים הפרטים העיקריים של ההטמעה הטכנית, שצריך לפתח במקביל.
שדרוג היישום של Google Wallet API
בדף Technical Details (פרטים טכניים) מפורטים השיטות והפרמטרים שהמנפיק צריך להשתמש בו ולעדכן אותו כדי לבצע את השילוב של Motics. באופן ספציפי, המנפיק צריך לקרוא לשיטות הבאות של Google Wallet API עם פרמטרים נוספים הקשורים ל-Motics:
הטמעה של נקודת הקצה להפעלה
שרת Google מבצע קריאה לנקודת הקצה להפעלה באירוח של המנפיק. כך מפעילים את היצירה של נתוני ההרשאות הסטטיים (sigSTB) בשרת של המנפיק. פרטים נוספים זמינים בקטע נקודת קצה להפעלה.
הטמעת התהליך של העברה וביטול קישור
כדי לספק חוויית משתמש טובה, למשתמש צריכה להיות אפשרות להעביר את הכרטיס שלו ב-Motics ממכשיר אחד לאחר, במסגרת מגבלות מסוימות שהוגדרו על ידי המנפיק. לשם כך, המנפיק צריך ליישם את תהליך ההעברה וביטול הקישור.
שליחת הודעת אישור באימייל לגבי שמירת הכרטיס
Google דורשת שהמנפיק ישלח למשתמשים הודעת אישור באימייל כשהם שומרים כרטיס Motics ב-Google Wallet. הודעת האישור באימייל צריכה להכיל (לכל הפחות):
- קישורים שימושיים למשתמשים לניהול הפנייה שלהם (מינוי).
- הוראות ליצירת קשר עם תמיכת הלקוחות של המנפיק.
3. ביצוע בדיקות שילוב מקצה לקצה ב-STAGING
כדאי ליצור בדיקת transitClass של Google Wallet לשימוש בפיתוח, ובסיום עבודת השילוב, יהיה צורך לאמת את הפתרון ולבדוק אותו מקצה לקצה באמצעות transitClass. ב-transitObject:Insert, מגדירים את cert_environment ל-STAGING. כל תרחישי השימוש צריכים להיבדק במלואם, וכל מקרי הבדיקה צריכים לקבל תוצאה מוצלחת.
4. ביצוע בדיקות מקצה לקצה ב-PRODUCTION
אחרי שהפתרון נבדק בהצלחה באמצעות הסביבה STAGING, יוצרים סביבת ייצור חדשה transitClass. הפעם, cert_environment צריך להגדיר את הערך PRODUCTION כשמוסיפים את transitObject. פועלים לפי כל תרחישי הבדיקה וההוראות בקטע Testing ומשלימים אותם.
5. מעקב אחר תהליך ההשקה והשגת אישורים
לפני שמפעילים או מתחילים פיילוט ציבורי, Google צריכה לקבל אישור מלא להשקה. האישור תלוי בתוצאה של שלבי הבדיקה השונים וכן בגורמים אחרים, כמו (בין היתר) הדברים הבאים שצריך לבדוק ולאשר על ידי Google:
- תוכנית והיקף השקה כולל
- במקרה של פיילוט, תוכנית ההשקה צריכה לכלול קריטריונים ברורים ליציאה ולוחות זמנים כדי להמשיך להשקה מלאה.
- פעילויות שיווקיות מתוכננות
- שליחת הודעות
- תאריך ההשקה
- לוחות הזמנים של ימי ההשקה, אנשי קשר ותהליך ההעברה לטיפול ברמה גבוהה יותר
- תהליכי תמיכה למשתמשי קצה