פרויקט שירותים - muni-services
מטרת הפרויקט
חיבור של מערכות הרשות המקומית לאיזור האישי הממשלתי והטפסים. וככה לאפשר הצגה של נתונים מהרשות המקומית באזור האישי וכן הנגשה של בקשות לשירות.
שירותים בשלב זה
- הצגת נתוני ארנונה
- הנחות בארנונה
- חילופי מחזיקים על נכס (ארנונה)
- בקשה לתו חניה
- אישור תושבות
- ממשק סטאטוס בקשות
- אישור טאבו
תהליכי עבודה
כאשר אזרח נכנס לאזור האישי (gov.il), הוא יוכל להיכנס ללשונית של השלטון המקומי שלו, שם יוכל לראות נתונים מתוך מערכות המועצה המקומית. (בשלב הראשון - רק של מועצה בה הוא גר)
צוות האזור האישי אחראי רק על שכבת התצוגה - אף מידע לא נשמר שם. כאשר אזרח נכנס האזור האישי עושה קריאות לכל המשרדים כדי לקבל מידע. ולכן פותח הפרויקט שמטרתו להיות המתווך בין האזור הממשלתי לרשויות.
רכיבים בפרויקט
API
תפקידה של שכבה זו היא לקבל את הקריאות מכיוון הממשלה (אזור אישי, טפסים ובעתיד אולי גם משרדי ממשלה) ולנווט אותה לשירות המתאים.
שירותים
לכל שירות עסקי קיים שירות טכני אשר מטרתו היא לבצע את הפעילות העסקית הנדרשת.
הפרוייקט מתלבש על האזור האישי של gov.il, אין עיצובים רק איפיונים.
סביבות
- סביבת dev: https://ui-dev-muni-services.linnovate.net
- סביבת stage: https://ui-stage-muni-services.linnovate.net
- סביבת pre-prod: נמצא במערך ב-gov.il, מערכת ניהול לרשויות
- סביבת prod: נמצא במערך ב-gov.il, מערכת ניהול לרשויות
- סיסמא: U1, p1
שירותים מפורטים
הצגת נתוני ארנונה
מטרת השירות היא להציג את הנכסים של התושב ברשות ואת תשלומי הארנונה עבורם. ברמה הטכנית השירות יודע לפנות למערכת הרשות של התושב לפי התושב לקבל את הנתונים לסדר לשליחה ולהחזיר לאזור האישי.
המשימה: One city צריכים להחזיר את המידע בצורה תקינה עפ"י המבנה שבנינו (JSON) ולאחר מכן לבצע בדיקה זהה מול הספקיות הנוספות (מטרופולינט ו-EPR).
הנחה בארנונה
- חיבור ל-DataBase של ביטוח לאומי - יוסי צריך לברר מול ביטוח לאומי את הבאת הנתונים מהאיפיון - לאחר מכן, שרה תפתח תהליך קליטת נתונים מהמסד.
- אפליקציית ניהול - יש כמה תיקונים סמנטיים - לתאם פגישה בין יוסף לשרה כדי לעשות תיקונים - בוצע (לקבוע תאריך החזרה של התיקונים, לכל המאוחר שבוע הבא)
- סוואגר נתונים הנחות - 2 פיתוחים מול וואן סיטי: ממשק הנחות (POST) וממשק בדיקות (GET)
מקבלים את הנתונים מביטוח לאומי, מתרגמים להנחות ומעבירים לחברות מכרזים.
חילופי מחזיקים
ממתינים לתשובה לגבי מבנה המידע מהטפסים (JSON) ובהתאם לפתח את אופן קבלת המידע ואופן שליחת המידע לספקים. Onecity ממתינים שנשלח להם את מבנה הנתונים בהתאם לטופס JSON של מיכל.
תו תושב
פותח, ונמצא בהקפאה. נדרש לוודא תקינות. (עופר פיתח. שרה רוט צריכה לעבור על זה)
תו חנייה
מתחלק לשני חלקים:
- תצוגת נתונים באזור האישי - אפשר להתחיל פיתוח בהתאם לאיפיון של מיכל
- הגשת בקשה - ממתין לישיבות מול ספקים ובניית הטופס - ע"ב מערכת הטפסים של הממשלה
צוות
- שרה וובר - ר"צ
- שרה רוט - פיתוח
- ייטב גלעד - פיתוח
- טל חלייס - דבאופס
מערך הדיגיטל
- ערן ארנון - מנהל פרויקט, מערך הדיגיטל
- רועי קדם - נתוני ארנונה, חילופי מחזיקים
- מיכל - מנהלת מוצר ההנחות בארנונה, תו חניה
הסבר כללי - ארכיטקטורת השירותים
תיאור
המערכת מיועדת לשמש כפרוקסי בין מערך הדיגיטל של הרשויות המקומיות לבין ספקיות חיצוניות.
באמצעות המערכת, מערך הדיגיטל שולח קריאות בפורמט JSON הכוללות פרמטרים רלוונטיים.
המערכת מנתבת את הקריאה לספקית המתאימה, מקבלת ממנה תשובה, ומחזירה אותה חזרה למערך הדיגיטל.
מטרות עיקריות
- יצירת שכבת תיווך אחידה בין מערך הדיגיטל לספקיות.
- הפחתת התלות ב־API שונים של ספקיות.
- ניהול וסטנדרטיזציה של מבני נתונים (JSON אחיד).
- שקיפות ובקרה על בקשות ותשובות.
תרשים ארכיטקטורה
להלן תרשים ארכיטקטורת המערכת:
שירותי ה-API
שירותים זמינים
בתוך ה-API המרכזי קיימים מספר שירותים ייעודיים:
- שירות נתוני ארנונה - מעבד בקשות הקשורות לנתוני ארנונה מרשויות מקומיות
- שירות תווי חניה - מטפל בבקשות הקשורות לתווי חניה וניהול חניות
- שירות אישור תושב - מטפל בבקשות לאישורי תושבות
- שירות הנחות בארנונה - מטפל בבקשות להנחות ארנונה
- שירות חילופי מחזיקים - מטפל בבקשות לחילופי מחזיקים
- שירות סטטוס בקשות - מטפל בבקשות לסטטוס בקשות
- שירותים נוספים - שירותים נוספים לפי דרישות המערכת
אופן הפעולה
- ניתוב אוטומטי: לפי סוג הבקשה שהגיעה ממערך הדיגיטל, המערכת מפנה לשירות המתאים
- שליפת נתונים: כל שירות שולף מידע נוסף מה-MongoDB (כגון הגדרות, פרמטרים, מיפוי ספקיות)
- עיבוד ושליחה: הנתונים מעובדים ונשלחים לספקית המתאימה
מערכת UI Front
תיאור כללי
UI Front היא מערכת ניהול תוכן שנכתבה ב-Next.js, המאפשרת לעורכי תוכן לנהל ולהגדיר את השירותים השונים במערכת.
יכולות המערכת
- עריכת תוכן: עורכי תוכן יכולים להגדיר פרמטרים לכל שירות
- ניהול הגדרות: הגדרת מיפוי בין בקשות לספקיות המתאימות
- שמירת מידע: כל המידע נשמר ב-MongoDB לצורך עיבוד הבקשות
דוגמה לזרימת עבודה
כאשר מגיעה בקשה הקשורה לנתוני ארנונה:
- המערכת בודקת ב-MongoDB איזה ספקית מטפלת בבקשה זו
- המידע נשלף מה-MongoDB (לאחר שעורך תוכן הזין אותו)
- הבקשה מועברת לספקית המתאימה עם כל הפרמטרים הנדרשים
הסבר הארכיטקטורה – זרימת מידע
-
שליחת בקשה ע״י יוזר
המשתמש שולח בקשה דרך מערך הדיגיטל ל־API המרכזי.- הבקשה כוללת: JSON ראשוני, פרמטרים ו־Swagger.
-
קליטת בקשה ב־API
- ה־API מקבל את ה־JSON וה־Swagger.
- ממיר את ה־JSON ואת ה־Swagger לפורמט חדש.
- מאתר את הספקית הרלוונטית לפי ההגדרה במאגר הנתונים (MongoDB).
- שולח לספקית JSON חדש + Swagger חדש + פרמטרים.
-
עיבוד אצל הספקית החיצונית
- הספקית מקבלת JSON ו־Swagger מה־API.
- מבצעת עיבוד ומחזירה JSON חדש + Swagger חדש + פרמטרים בחזרה ל־API.
-
קליטת תשובה ב־API
- ה־API מקבל JSON ו־Swagger מהספקית.
- ממיר שוב ל־JSON חדש ו־Swagger אחיד בפורמט סטנדרטי.
- מחזיר את התשובה למערך הדיגיטל.
-
קבלת תשובה במערך הדיגיטל
- מערך הדיגיטל מקבל את ה־JSON וה־Swagger לאחר ההמרה הסופית.
- תמיד מתקבל JSON אחיד + Swagger אחד ללא תלות במבנה המקורי של הספקית.
תרשים זרימה לוגי
תיעוד מפורט
טאבים נוספים
בטאבים הנוספים של המערכת ניתן למצוא הסבר מפורט על כל שירות:
- מה נשמר ב-MongoDB עבור כל שירות
- פרמטרים נדרשים לכל בקשה
- מיפוי ספקיות לכל סוג שירות
תיעוד מלא של השירותים
לתיעוד מפורט של כל שירות, כולל 4 הגיסונים ו ה-Swagger, ניתן להיכנס ל: תיעוד השירותים המלא