פוסט 5 - מנגנונים עיקריים במערכת

אנחנו עומדים בפני אחד הפוסטים המעניינים לדעתי.

בפוסט הזה אנחנו הולכים לגעת בשני מנגנונים מעניינים. 

האחד -מנגנון שליחת הודעות הפוש לתושבים המדווחים הישר ממשק הניהול.

השני - המנגנון המאפשר למערכת להתמודד עם ריבוי לקוחות בענן (Multi Tenancy).

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

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

מה שלמעשה עושים זה לכתוב אפליקציה ב-HTML5 וב-AngularJS, ״מקמפלים״ והתוצר של הקימפול הוא שתי אפליקציות אחת לאנדרואיד והשניה לאייפון וזהו, לשלוח

ל-App Review ולחניות, זה עובד נהדר!

חוץ מה-Framework המדהים הזה יש אתר ,Ionic.io, המציע סל של שירותים למשתמשי ה-Framework, אחד מהם הוא Push Notification. 

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

אז מה יש לנו כאן:

התרשים הבא מתאר מצב שקורה בשני תרחישים שונים:

• שינוי סטטוס של אירוע ברשימה למצב ״בטיפול״, (In Progress) - במצב כזה אנו רוצים לעדכן את התושב שהאירוע שדיווח עליו כעת נמצא בטיפול ע״י הגורמים הרלוונטים, זה נראה ככה:

• שינוי סטטוס של אירוע ברשימה למצב ״טופל״, (Fixed) - במצב כזה אנו רוצים לעדכן את התושב שהגורמים הרלוונטים סיימו לטפל באירוע שדיווח, זה נראה ככה:

לפני שנציג את אשר מתאר התרשים אוסיף פרט חשוב:

כל תושב שמשתמש באפליקציה, בעת עלייתה בפעם הראשונה, מבצע רישום לשירותי Ionic.io ומקבל מספר מזהה יחודי (Token), הרישום מתבצע ע״י פניית REST ל-Notification Micro Service, 

שמעביר את הפניה לשרתים של Ionic.io ושומר את הטוקן שהמשתמש קיבל, התוצאה של התהליך הזה הוא מפה (Map), של משתמשים והמספר מזהה שקיבלו מ-Ionic.io, ניגע בזה בהמשך.

התרשים מתאר את המצב הבא:

א. מתקבלים דיווחים על ״מפגע רעש״

ב. נוסף ״אירוע אמת״ ברשימת האירועים.

ג. לאחר עשר דקות הפקח העירוני מדווח שהוא יוצא למקום.

ד. משנים בממשק הניהול את סטטוס האירוע ל״בטיפול״ .

ה. נשלחת הודעה ב-REST ל-Event Micro Service לעדכן את הסטטוס בדטה בייס.

ו. נשלחת הודעה ב-REST ל-Notification Micro Service לשלוח לכל המדווחים על האירוע הזה, הודעה בדבר שינוי הסטטוס.

ז. ה-Notification Micro Service שולף את המספרים המזהים של כל המדווחים ומעביר רשימה (REST) ל-Ionic.io ואת הנוסח של שההודעה.

ח. Ionic.io מקבלים את רשימת התושבים אליהם אנו רוצים להעביר עדכון, נוסח העדכון ומבצע לבד את ההפניות ל-Apns ו-GCM.

Apple push notification service, Apns - שרת שליחת הודעות הפוש של אפל. (מצריך חשבון מפתח בכדי להשתמש בשירות)

Google Cloud Messaging - GCM - שרת שליחת הודעות הפוש של גוגל. (לא מצריך חשבון מפתח בכדי להשתמש בשירות).

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

הפתרון למעשה הוא פתרון פשוט אבל חכם - עבור כל לקוח אני מספק "Promotion Code", לקוד הזה משויכיים הגבולות המוניצפליים של אותו לקוח: לדוגמא הלקוח הוא עיריית חיפה, ה-"Promotion Code" שהופק עבורו הוא - "Haifa", האובייקט הג'אווה שמייצג אותו נראה ככה, וככה גם נשמר ב-Database:

כחלק מתהליך רישום משתמש (user) במערכת, ישנו שדה חובה (mandatory), שמצפה לקבל Promotion Code, הקוד נשמר יחד עם המשתמש ולא מתאפשר רישום משמתש חדש מבלי שיסופק ע"י המשתמש Promotion Code שנמצא במערכת. לאחר תהליך הרישום ברגע שהמשתמש נכנס למערכת כל האירועים שמתקבלים מה-Event Micro Service מסוננים לפי אירועים שנמצאים בשטח הריבוע הדימיוני שמיצרים הגבולות המוגדרים ב-Promotion Code המשויך למשתמש.

עוד עניין חשוב שאנו מקבלים בחינם מהמנגון הזה הוא יכולת יצירת משתמשים (users) מרובה עבור לקוח (Tenant).

לדוגמא:

הלקוח (Tenant): עיריית רמת גן.
משתמשים (Users):
- מוקדן 106.
- איש השירות בצוות המזרקות. (שיכול לשנות את סטטוס האירוע בשטח).


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