פוסט 1 - מבוא

טוב חברים, מתחילים את המסע, נקווה שלא נשבר באמצע..

אז מה בתכנון - בלוג טכני המתאר את שלבי הפיתוח של מוצר, החל משלב הרעיון דרך בחירת הארכיטקטורה ומימושה ועד למוצר של ממש שיושב בענן ומתקשר עם האפליקציות יעודיות (native) לאייפון ולאנדרואיד (End-To-End)

כל התהליך המתואר מעלה נפרס על תקופה של חצי שנה +/-, שבממוצע לשבוע הוקדשו 5-6 שעות לעניין.

רוב הפוסטים יעסקו בארכטיקטורה בת ימינו ושזירת מושגים טכניים (buzzwords) עכשויים הקשורים לענן ול-JAVA.

הפוסט הראשון יחולק בצורה הבאה:

מנות פתיחה:

• קצת על עצמי.
• על המוצר.
• קישורים רלוונטים.
• כובעים.

מנה עיקרית:

• ארכיטקטורה וטכנולוגיות.

קינוח:

• מה מחכה לנו בפוסטים הבאים.

מנות פתיחה

לפני שמתחילים מספר עובדות על עצמי:

• נשוי פלוס נסיכה קטנה.
• נכנסתי דיי מאוחר לעולם הפיתוח, לא הגעתי מיחידת מחשבים בצבא, דווקא הייתי לוחם ביחידה מיוחדת בחיל האוויר.
• עובד כשכיר - Software Engineer at EMC² - JAVA\J2EE developer
• כל הנעשה פה התבצע בזמני הפנוי, זמן שהייתי נוהג לבזבז על סרטים, טלוויזיה ומשחקי מחשב.
• במידה ויציצו שאלות, דברים לא ברורים, אתם יותר ממוזמנים לשלוח מייל ל- mike@cityeye.co.il.

אז מה יש לנו:

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

עקרונות מנחים במוצר:

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

קישורים:

• דף נחיתה - www.cityeye.co.il
• פאנל ניהול - hq.cityeye.co.il
• עמוד פייסבוק - www.facebook.com/Cityeye.co.il
• אפליקציות מובייל:

• iPhone
• Android  

כובעים שחבשתי בשלבים השונים

• הרעיון -> יזם (Founder) 
• אריכטקטורה -> ארכיטקט (CTO)
• מפתח Backend
• DBA
• מפתח Frontend
• Web Designer -> עיצוב עמודים, כפתורים, עיצוב אפליקציות המובייל, לוגו, דף נחיתה
• מפתח iOS
• מפתח Android
• Dev-Ops -> העלאת והרצת המערכת על שירותי ענן שונים, הקמת תשתית לדפי נחיתה (Google Compute, AWS)
• QA - בדיקות  Performance ,Sanity ואוטומטציה. 
• Security Advocate

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

נשמע מטורף ולא מציאותי שפרוייקט כזה על כל מרכיביו נבנה ע״י אדם בודד?

ובכן, מסכים.

עיקרית

טוב, הגיע הזמן לעבור לדברים המעניינים באמת,

אז מה יש לנו מאחורי הקלעים (נכון לגירסא הראשונה)

שפת פיתוח - JAVA - משתמשים ב-Spring Framework.

Micro Services Architecture - נכון לעכשיו קיימים 10 מיקרו סרביסס, לכל מיקרו סרביס אחריות על דבר אחד, רצים ב Spring Boot וחושפים מספר מטודות REST.

AMQP- המיקרו סרביסס מדברים אחד עם באמצעות שימוש בפרוטוקל AMQP להעברת הודעות, מנהול באמצעות שרת RabbitMQ.

Cloud Foundry - PaaS - כל המיקרו סרביסס יושבים על CF, פתרון לנושאים שאגע בהם בהמשך כמו CI, CD, Scalability  

PostgreSQL - Relational DB- ישנו דטה בייס אחד נכון לעכשיו, אולי ישתנה בעתיד.

ObjectDB - No-SQL - ישנם מיקרוסביסס שמשתמשים בדטה בייס קטן ומהיר.

Liquibase - Database refactor - יצירת הטבלאות מתבצעת באופן דינמי.

OAuth2 - Spring Security - Security אבטחת המערכת זיהוי וניהול המשתמשים מתבצעת ע״ב תקני האבטחה העדכניים ביותר.

Logback - Logging.

Swagger - API Framework

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

קינוח

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

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

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

זהו להפעם, יש למה לחכות,
 מייק.

פוסט 2 - בחירת הרעיון והכרות ראשונית עם המערכת

אז איך הכל התחיל?

ובכן, שנתיים וחצי בהן הייתי שכיר והועסקתי כמפתח צד שרת בג׳אווה, עובדה זו בשילוב עם החיבה שלי לטכנולוגיות צד לקוח, היו לקרקע מוצקה עבור הדחף שנוצר בי לפתח מוצר מאפס על כל מרכיביו (END-TO-END).

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

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

א. יודע לאמוד את היכולות שלי.
ב. יכול הלכה למעשה לפתח מוצר מ-0.
ג. יכול להתמודד עם כל קושי שיצוץ בדרך.

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

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

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

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

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

מלפני שניגשתי ממש לכתוב קוד (Day One) היה עיקרון שסביבו ביססתי את כל ה-Design של הארכיטקטורה והוא:

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

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

1. Scalability - יכולת התמודדות עם כמות משתמשים משתנה בצורה פשוטה וזולה.
2. Continues Integration - CI, Continues Delivery - CD - תהליכים אוטומטיים המתבצעים מהרגע שהמפתח מסיים לכתוב פיצ'ר ועד שמגיעים למשתמש הקצה.


(אפשר להרחיב רבות על כל מושג מבין אלה)

אודות כל עקרונות אלה בחירת הארכיטקטורה הייתה טרוויאלית למדי וכפי שכבר ציינתי אנחנו מדברים על Micro Services.

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

• Web Micro Service - אחראי על הצגת פאנל הניהול והצגת המידע המתקבל מהמיקרו סרביסס האחרים.

• Tenant Micro Service - אחראי על ניהול המשתמשים, יצירה וזיהוי (ערים ורשויות מקומיות), משתמשי האפליקציה הם אנונימיים לחלוטין.

• Listener Micro Service - אחראי על קבלת הדיווחים מהתושבים, מכיל את האלגוריתם לזיהוי אירועי אמת.

• Event Micro Service - אחראי על שליפת אירועי האמת שנוצרו וניהולם (אירוע פתוח, בטיפול, טופל).

• Photo Micro Service - אחראי על קבלת התמונות המתקבלות מהתושבים לאחר דיווח ושליפתם בעת הצורך.

• Comment Micro Service - אחראי על קבלת התיאור המילולי המתקבל מהתושבים ושליפתו בעת הצורך.

• Archive Micro Service - אחראי על ארכיון האירועים, מנהל אירועים ישנים וכאלה שטופלו או נסגרו (יש מערך תיעוד שלם של האירועים)

• Notification Micro Service - אחראי על שליחת ההודעות (Push Notifications) לתושבים המדווחים אודות התקדמות הטיפול באירוע שדיווחו עליו.

• Score Micro Service - אחראי על מנגון הניקוד, כל תושב המדווח על אירוע שמתברר שהוא אירוע אמת מקבל ניקוד.

• Geo Micro Service - אחראי על הפקת כתובת מהקורדינטות המתקבלות מהתושבים ע״י פניה לשרתים של גוגל.

• Report Micro Service - אחראי על הצגת וניהול הדוחות שהמערכת מייצרת.

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


מה שאנחנו רואים כאן זאת התצוגה שמספק ה-Web Micro Service הסבר קצר על מה שאנחנו לא רואים כאן:

המסך שאנחנו רואים הוא המסך לאחר תהליך ההזדהות בפאנל הניהול, בתהליך כמובן משתתף מיקרו סרביס נוסף שאנחנו לא רואים כאן והוא ה-Tenant Micro Service.

עוד מיקרו סרביס שאנחנו לא רואים כאן הוא ה-Report Micro Service, אליו ניתן להגיע דרך התפריט, בעתיד נראה אותו ונעסוק בו ובתפקידו

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

זהו לבינתיים,

מייק.

פוסט 3 - תיאור התהליך המרכזי במערכת

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

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

1. לדעת לסנן דיווחי סרק, הרי אין לי דרך לדעת מי המדווח.

2. לדעת מתי שני דיווחים או יותר מדברים על אותו אירוע ולא על אירועים שונים.

את הפתרון שמצאתי הטמעתי בהגדרת האירוע. כל אירוע מוגדר על ידי שלושה פרמטרים:

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

התרשים מטה מתאר את המתרחש כאשר נוצר אירוע אמת במערכת ועד ההופעה של האירוע בפאנל הניהול. (במקרה זה מס' המדווחים הוא 2):

מספר נקודות אודות התרשים:

א. תקשורת בין המיקרו סרביסס במערכת - התקשורת בין המיקרו סרביסס במערכת מבוססת על הודעות שמנוהלת על ידי שרת AMQP מסוג RabbitMQ.

ב. שני אופנים להפצת הודעות:

• כאשר התקשורת היא ישירה בין מיקרו סרביס שולח (Producer), למיקרו סרביס מקבל (Consumer), ההודעה נכנסת ל-Queue, 
• כאשר התקשורת היא בין מיקרו סרביס שולח (Producer), למספר מיקרו סרביסס מקבלים (Consumers), ההודעה נשלחת ל-Topic.

ג. התקשורת בין ה-Web Micro Service למיקרו סרביסס האחרים היא שונה והיא מתבצעת באמצעות פניות REST, כל מיקרו סרביס חושף REST API שנגיש ע״י ה-Web Micro Service בלבד.

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

ה-FLOW הסנדרטי הוא כדלהלן:

1. המיקרו סרביס שמקבל את ההודעות מהתושבים הוא Listener Micro Service.

2. Listener Micro Service אוגר הודעות ועדיין לא מדווח על ״אירוע אמת״ עד שלא מגיעים למספר הדיווחים המינימלי שהוגדר.

3. כאשר מתקיימים שלושת התנאים - מספיק דיווחים מאותו איזור ובטווח הזמן שהוגדר, ה-Listener Micro Service מיצר ״אירוע אמת״.

4. שתי פעולות מתבצעות כאשר זוהה ״אירוע אמת״:

• הכנסה לדטה בייס הראשי.
• שליחת הודעה ל-Topic שרשומים אליו שלושה מיקרו סרביסס, כפי שמתואר בתרשים:

5. ברגע שההודעה מגיעה ל-Topic, נכנסים לפעולה שלושת המיקרו סרביסס הבאים: 

• Geo Micro Service - פונה לשרתים של גוגל עם הקורדינטות של ה״אירוע אמת״, מקבל חזרה כתובת מלאה ומכניס אותה לדטה בייס.
• Notification Micro Service - שומר את המספר מזהה היחודי של התושבים שדיווחו על ה״אירוע אמת״. שימוש במידע זה יבוא לידי ביטוי במנגון לניהול האירועים ועדכון התושב, באמצעות הודעות פוש (Push Notifications), בהתקדמות הטיפול באירוע שהוא דיווח עליו.
• Score Micro Service - מוסיף נקודה לתושבים שהדיווח שלהם התגלה כדיווח אמת וזאת ע״ב המספר מזהה היחודי שלהם בלבד. 

6. Event Micro Service הוא מיקרו סרביס סינגלטוני (Singleton), הוא מחזיק כל העת רשימה עדכנית של אירועי האמת שנמצאים בדטה בייס. (מתבצע באמצעות תהליך שבכל כמה שניות ניגש לדטה בייס ובודק אם יש אירוע חדש).

7. גם ל-Web Micro Service יש תהליך פנימי שרץ כל כמה שניות (Schedule Task) ופונה באמצעות פניית REST ל-Event Micro Service ובודק האם נכנסו אירועים חדשים.

8. נחזור רגע לאפליקציה שהתושבים מדווחים באמצעותה - לאחר שמועבר הדיווח (וגם כל התהליכים שתוארו מעלה אך התושב לא חשוף אליהם) נפתח פופ-אפ (Pop-up Dialog), השואל את התושב האם הוא מעוניין לצרף תמונה ממקום האירוע.

9. במידה והתושב מצרף תמונה ממקום האירוע התמונה נשלחת למיקרו סרביס אחר והוא ,Photo Micro Service. המיקרו סרביס הזה שומר את התמונה ותפקידו הוא ניהול התמונות שהתקבלו מהתושבים.

10. לאחר המתואר ב-9 בין אם התושב שלח תמונה ובין אם לאו, נפתח פופ-אפ, (Pop-up Dialog), השואל את התושב האם מעוניין לצרף תיאור/הערה בנוגע למתרחש באירוע, גם מידע הזה מגיע ישירות למיקרוסרביס אחר מבין אלה שהוזכרו והוא, Comment Micro Service. תפקידו הוא לנהל את המלל המתקבל מהתושבים.

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

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

זהו לבינתיים, 

מייק.

פוסט 4 - ממשק הניהול ואבטחה

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

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

Authentication, (זיהוי) - מנגון זיהוי המשתמשים, ישנם דרכים רבות לזהות משתמשים (טביעת אצבע, צורת הקלדה, קול וכו'..) אבל הדרך הסטנדרטית והמקובל היום היא עדיין ע"י שם משתמש וסיסמא.

Authorization, (הרשאות) - מנגון ניהול המשתמשים, לאחר ביצוע תהליך ההזדהות לכל יוזר מוגדר מרחב הרשאות (ROLE), לצורך העניין רשות מקומית\עיר מוגדרת כ-Tenant, המתשמשים במערכת שרשומים תחתיה מוגדרים כ-Users  מי שמוסיף רשויות וערים לשירות מוגדר כ-Admin וכן הלאה.

למוצרים היושבים בענן, אחד הקשיים הגדולים ביותר הוא היכולת להתמודד עם מספר רב של משתמשים, (Tenants), ולהציג רק את המידע הרלוונטי למשתמש (Tenant), העניין אף מסתבך כאשר המערכת מציעה יכולות רבות וצריך גם לחייב את המשתמש עבור השימוש (Chargeback), בגירסא הנוכחית עדיין לא הגעתי לשם אבל אין ספק שזה אתגר לא קטן.

הגיע הזמן לדבר על קיצור הדרך הראשון והעיקרי שעזר לי המון וקידם אותי חודשים קדימה עם המוצר והוא JHipster.

JHipster - פרויקט מדהים! שעזר לי רבות בהקמת ה Web Micro Service וחסך לי המון התעסקות בדברים תשתיתיים שלא קשורים ל-Business Logic. הפרוייקט הזה מבוסס ספרינג (Spring Boot) בשילוב עם AngularJS, (השכבה שמטפלת בתצוגה), הוא משתמש בפרויקט ומדהים לכשעצמו שנקרא Yeoman, (מאפשר לך באמצעות Wizard לקנפג את המערכת שלך בצורה פשוטה וקלה).

JHipster פתר לי בצורה חלקית את כל כאב הראש של זיהוי וניהול המשתמשים והוא משלב שימוש בפרוטוקול OAuth2 ו-Spring Security, כיוון שהמוצר יושב (Deployed) על Cloud Foundry, בכדי להשלים את סידורי האבטחה ולקבל עוד שכבת הגנה גם מ-Cloud Foundry, היה עלי לשלב שימוש גם ב-UAA.

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

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

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

מספר דגשים לגבי התרשים:

- המסך שאנחנו רואים הוא המסך שמופיע לאחר תהליך ההזדהות (Login).
- התצוגה הראשית מורכבת ממידע המגיע ב-REST ממספר מיקרו סרביסס שונים - את הפניות יוזם ה-Web Micro Service לאחר שמלאכת הזיהוי הושלמה.
- במידה ואין אירועים אז המידע היחיד שיכיל פאנל הניהול נכון גירסא זו הוא מידע אודות המדווחים המובילים.
- במידה ויש אירועים במערכת ה-Web Micro Service יקח את הנתונים מהאירוע העדכני ביותר ויפנה ב-REST לשלושת המיקרו סרביסס הבאים:

• Photo Micro Service - יבקש את התמונות שהתקבלו מהתושבים המדווחים.
• Comment Micro Service - יבקש את התיאורים והתגובות שהתקבלו מהתושבים המדווחים.
• Geo Micro Service - יבקש את הכתובת המדוייקת של מקום האירוע.

- ה- Web Micro Service פונה למיקרו סרביסס האחרים באמצעות פניית Ajax, פניה אסינכרונית, המידע שמגיע מהמיקרו סרביסס נטען באופן דינאמי בעמוד.
- פעולה נוספת שניתן לבצע דרך פאנל הניהול היא שליחת לכלל התשובים, בין אם פרסומית ובין אם אינפורמטיבית.

- מנגנון ניהול האירועים שארחיב עליו בתחילת הפוסט הבא גם הוא מוטמע במסך שאנו רואים בתרשים - לכל אירוע שמופיע ברשימה מצורפים ארבעה כפתורים:

 - האירוע טופל.

 - החזק אירוע ברשימת הדיווחים.

- הסר אירוע מרשימת הדיווחים והעבר לארכיון.

- סמן אירוע במצב ״מטופל כעת״ (In Progress).

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

זהו לבינתיים, שבוע טוב.

מייק.

פוסט 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.
- איש השירות בצוות המזרקות. (שיכול לשנות את סטטוס האירוע בשטח).


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

פוסט 6 - אפליקציית המשתמשים (תושבים)

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

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

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

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

כעת נשאלת השאלה, כיצד המערכת יודעת לאיזה תושבים לשלוח את ההודעה?

הבה נצפה בתרשים ולאחר מכן אסביר אותו.

פתרון:

אז כפי שניתן להבחין, הפתרון מורכב משני תהליכים:

תהליך 1 - מתאר מה קורה מצד משתמשי האפליקציה.
תהליך 2 - מתאר מה קורה ברגע שמשתמש ממשק הניהול שולח הודעה.

** UUID - מספר מזהה יחודי שהאפליקציה מקבלת לאחר התקנה, והוא קבוע.

וכעת נסביר כל אחד מהם:

התהליך הראשון מתאר את אשר קורה ברגע שנכנסים לאפליקציה, בכל פעם מחדש, נשלחת פייה ל-Notification Micro Service, עם ה-UUID והמיקום הנוכחי של המשתמש. הרישום של המכשיר בשירות ה-Push notification, (השירות שמסופק ע"י  Ionic.io), הוא חד פעמי, ונשמר במערכת כלומר היחס הוא 1:1, UUID:tokenID. תהליך זה לא מצויין בתרשים אבל מתבצעת בדיקה האם כבר קיבלנו את ה-token בעבור ה-UUID שנשלח, במידה וכן לוקחים את ה-token שהתקבל בעבר עובר ה-UUID, (המשמעות היא שהמשתמש כבר רשום בשירות שליחת ההודעות של ionic.io), ושומרים אותו יחד עם פרטי המיקום הנוכחים של המשמתש.

התהליך השני מתאר מה קורה ברגע שמשתמש ממשק הניהול שולח הודעה ממש הניהול.

למעשה ברגע שלוחצים על Send  נשלחת פניית REST ל-Notification Micro Service שמכילה שני פרטים:
* נוסח ההודעה.
* הריבוע הדימיוני שדיברנו עליו בפוסט הקודם שמוגדר ב-Promotion code והמשוייך למשתמש.

ברגע שמתקבלת הפניה ב-Notification Micro Service אנו בודקים איזה מבין המשתמשים הרשומים במערכת נמצאים כעת בריבוע הדימוני שקיבלנו, ושומרים את ה-token שלהם, ברגע שסיימנו לאסוף את כל ה-tokens, אנו שולחים פניה לשירות הודעות הפוש שמסופק ע"י ionic.io עם רשימת ה-tokens ונוסח ההודעה ומכן השירות כבר דואג להעביר את ההודעה למשתמשים ע"י זיהוי סוג המכשיר ע"ב ה-token ופניה בהתאם ל-GCM ו-APNS.

כעת נדבר על ממשק המשתמש באפליקציה:

אירועים

קיימים 14 אירועים מוגדרים מראש שהצלחתי לחשוב עליהם וקיים אירוע נוסף שנקרא "אירוע אחר" המאפשר שליחת אירוע שלא קיים במערכת.

התרשים הבא מדגים את השתלשות האירועים בעת שליחת דיווח:

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

כאשר לוחצים על סוג הדיווח נשלחת פניה ל-Listener Micro Service, המכילה שני פרמטרים:

1. סוג האירוע.

2. מיקום נוכחי.

זאת למעשה הנקודה שבה התרשים מתחיל, כאשר נשלח הדיווח אנו מחכים לתשובה מ-Listener Micro Service.

תשובה שלילית מסיבה כל שהיא -> שליחת האירוע נכשלה, חוזרים למסך הבית

תשובה חיובית  -> קופץ חלון המעדכן האם האירוע זוהה כבר כאירוע אמת או שמא טרם נאספו מספיק דיווחים,

בחלון הקופץ מתבקש התושב המדווח להוסיף תמונה ממקום האירוע. 

במידה ומעוניין יכול לבחור בין שתי אופציות:

1. לעבור למסך המצלמה והצילום שיצלם יעבור אלינו.

2. לבחור תמונה מספריית התמונות.

בין אם בחר לשלוח אלינו תמונה או לאו אנו מקפיצים חלון נוסף שבו מתבקש התושב להוסיף תיאור מילולי על המתחרש.

עקרון חשוב:

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

ניקוד

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

בפוסט הבא אתמקד בנושא מעט אחר והוא שלבי Deployment של המוצר, איך עובד מנגנון ה-Pipe Line בפיתוח, קשור למושגים שדיברנו עליהם CD ו CI, אזכיר טכנולוגיות ומושגים חדשים מעולם ה-DevOps ואגע קצת בעיצוב האפליקציה, דף הנחיתה וממשק הניהול. 

זהו לעת עתה,

מייק.