יוני 2007
מבוא
האם אי פעם רציתם לשמור הרבה מידע על פגישות, אירועים או כנסים בגיליון אלקטרוני של Google ולשתף את המידע הזה בקלות או לחפש בו? ב-Google, אנחנו עושים בדיוק את זה עם היומן של אירועים למפתחים. הנתונים שמוזנים ליומן מגיעים ממגוון רחב של עובדי Google בכל החברה – לרבים מהם יש הרשאת עריכה בגיליון אלקטרוני של Google שבו הנתונים מאוחסנים. בגיליון האלקטרוני, אירועים שלא אושרו מופיעים לצד אירועים שזכו לפרסום רב. לפעמים אנשים אפילו מזינים אירועים פוטנציאליים – עוד לפני שהוגשה הצעה או שנבדקה אפשרות של חסות. התפקיד של 'עורך' הוא לפרסם אירועים ולרשום את האירועים שפורסמו בעמודה בגיליון האלקטרוני.
למה אנחנו לא מתחזקים את האירועים האלה ישירות ביומן Google? יומן Google מתאים לזיהוי התאריכים והמיקומים של אירועים, אבל כשמדובר בניהול של הרבה נתונים מובנים – כמו רשימות של דוברים, מועדים אחרונים לשליחת הצעות וכו' – גיליון אלקטרוני מתאים יותר.
גיליון Google Sheets המקורי עם רשימת האירועים
אחד מהקולגות שלי ב-Google הציע שנמשיך לתחזק את האירועים בגיליונות אלקטרוניים, אבל נסיר את התהליך הידני של פרסום שלהם ביומן הציבורי החיצוני שלנו. רציתי גם להציג בפני המשתתפים ב-Mashup Camp פרויקט מעניין שמבוסס על כמה ממשקי Google Data API (או GData בקיצור), וכך נולד Event Publisher.
Event Publisher היא אפליקציה מהירה לפיתוח, שמשמשת כהוכחת היתכנות. האפליקציה שומרת רשימה של אירועים בגיליונות אלקטרוניים ומפרסמת אותם ביומן וב-Google Base. יומן Google הוא דרך מצוינת לשתף אירועים ולאפשר לאנשים להוסיף אותם בקלות לתצוגת היומן שלהם. אמנם אפשר לחפש אירועים ביומן, אבל Google Base מספקת עוד פלטפורמה לפרסום אירועים, והיא מצטיינת באחסון נתונים מובְנים בצורה שקל לחפש אותם.
כל אחד מהשירותים – Spreadsheets, Calendar ו-Base – מספק API שתומך בפעולות קריאה/כתיבה מלאות. ועוד יותר טוב, כל אחד מהשירותים האלה מאפשר גישה לנתונים שלו באמצעות פרוטוקול Google Data API.
עיצוב והטמעה
שלב התכנון של הפרויקט הזה היה פשוט למדי: ידעתי שאני רוצה ליצור אפליקציית אינטרנט לפרסום נתונים מגיליון אלקטרוני ביומן. המטרה לטווח הארוך הייתה ליצור אפליקציה שאפשר להשתמש בה ביומן האירועים של המפתחים, אבל המטרה לטווח הקצר הייתה ליצור הוכחת קונספט של מאשאפ שפועל, שאפשר להציג במהלך Mashup Camp. מתוך מחשבה על המטרות האלה, בחרתי בספריית הלקוח GData Java כי היא אחת מספריות הלקוח המפותחות יותר, ואני מכיר את הכתיבה של אפליקציות אינטרנט ב-Java. השימוש באחת מספריות הלקוח שסופקו חסך ממני את הצורך לדאוג לגבי פרוטוקול GData הגולמי ומודל נתוני ה-XML, ובמקום זאת יכולתי להתרכז בהטמעה של לוגיקת האפליקציה הפשוטה יחסית שנדרשת לפרסום אירועים.
הורדתי את ספריית הלקוח של Java והתחלתי לתכנן את מודל המחלקה של מפרסם האירועים. יצרתי סרוולט בשם EventPublisherServlet, שמשמש כבקר לכל הבקשות שנכנסות לאפליקציית האינטרנט. יצרתי גם מחלקה בשם EventPublisher כדי לטפל בלוגיקה העסקית של האינטראקציה עם Calendar, Base ו-Spreadsheets. לבסוף, כתבתי מחלקה של Bean לאחסון נתוני אירועים. ממשק המשתמש של האפליקציה פותח באמצעות כמה קובצי JSP.
היתרון בעבודה עם כמה שירותי GData הוא שהם עקביים בממשקים שלהם, וספריות לקוח רבות כוללות מחלקות עזר ספציפיות לשירותים המועדפים של Google. בגלל שספריית הלקוח כללה את אותם מחלקות Service, Entry ו-Feed עבור שלושת השירותים שבהם השתמשתי, יכולתי להשתמש בקוד דומה מאוד כדי לאחזר אירועים מ-Spreadsheets ולפרסם אותם ב-Base וב-Calendar. השימוש ב-API הזה קיצר משמעותית את זמן הפיתוח לעומת הזמן שהיה נדרש אם הייתי משתמש בשלושה ממשקי API שונים. כדאי לבדוק את השיטות publishEventToCalendar() ו-publishEventToBase() ב-EventPublisher כדי לראות את הדמיון בין השיטות השונות.
קבלת הכלי Event Publisher ופריסתו
אפליקציית Event Publisher מופצת כחלק מההורדה של ספריית הלקוח של Google Data Java. אחרי שמורידים את ספריית הלקוח של Java, מחפשים את הספרייה java/mashups/eventpub. מידע נוסף על המשמעות של כל קובץ בדוגמה מופיע בקטע מבנה הפרויקט בנספח.
לאפליקציה יש מספר ספריות תלויות שצריך להוריד לפני שיוצרים את הכלי לפרסום אירועים. אחרי שמגדירים את אפשרויות ה-build וה-runtime המתאימות (ראו את הקובץ README.TXT), אפשר להשתמש ב-Ant כדי לקמפל את מחלקות Java וליצור קובץ WAR. אחר כך אפשר לפרוס את קובץ ה-WAR במנוע סרוולטים מועדף, כמו Tomcat 5.5 שבו השתמשתי כדי לבדוק את האפליקציה הזו. ב-Tomcat, שפועל עם תצורת ברירת מחדל, צריך רק להעתיק את הקובץ deploy/EventPublisher.war שנוצר לתיקיית webapps. לאחר מכן הוא ייפרס אוטומטית ויהיה נגיש דרך http://hostname:8080/EventPublisher.
הפעלת האפליקציה – תהליך
אימות לחשבון Google Spreadsheets באמצעות AuthSub.
- האפליקציה נטענת כשנכנסים לכתובת /EventPublisher במארח שבו האפליקציה פועלת. במקרה שלי, אני מריץ את האפליקציה בכתובת http://localhost:8080/EventPublisher
- אימות ל-Google Sheets
- המשתמש לוחץ על הקישור 'אימות' שנוצר על ידי הפונקציה הסטטית: AuthSubUtil.getRequestUrl().
- המשתמש מועבר לשירותים של חשבון Google, ואם הוא עדיין לא מחובר ל-Google, הוא מתבקש להזין את פרטי הכניסה שלו.
- המשתמש מעניק לאפליקציה Event Publisher הרשאה לגשת לנתונים שלו ב-Spreadsheets.
- המערכת מפנה את המשתמש חזרה ל-Event Publisher עם טוקן AuthSub חד-פעמי בכתובת ה-URL. האירוע Publisher מחליף את האסימון לשימוש חד-פעמי באסימון סשן AuthSub באמצעות השירות AuthSubSessionToken.
- קוד: ראו
EventPublisherServlet.processAcceptAuthSubToken() - תיעוד: אפשר לעיין בתיעוד של AuthSub
- בחירת גיליון אלקטרוני או גליון עבודה
- מפרסם האירועים מפנה את המשתמש לרשימה של גיליונות אלקטרוניים שהמשתמש המורשה יכול לגשת אליהם.
- אחרי שבוחרים גיליון אלקטרוני שממנו יאוחזרו נתוני האירועים, המשתמש מתבקש גם לבחור את גליון העבודה המתאים בגיליון האלקטרוני שנבחר.
- קוד: ראו
EventPublisher.getSsList()ו-EventPublisher.getWsList()
- אחזור ומיפוי של כותרות עמודות
- לאחר מכן, האפליקציה משתמשת בפיד של התאים בגיליון האלקטרוני כדי לאחזר את השורה הראשונה של הנתונים מהגיליון האלקטרוני – השורה הראשונה הזו מייצגת את כותרות העמודות. כל נתון שנדרש מופיע למשתמש, והוא מתבקש לבחור את כותרת העמודה שהכי מתאימה לנתון. בצילום המסך משמאל, לכל סוג נתונים נדרש יש תיבת בחירה שלצידה צריך לבחור את כותרת העמודה המתאימה. המיפוי הזה מאוחסן בסשן של המשתמש באמצעות מנגנון הטיפול בסשנים של מאגר ה-servlet.
- קוד: ראו
EventPublisherServlet.processListEvents()
- שליפת רשומות ואחסון שלהן ב-Beans
- אחרי מיפוי העמודות, הכלי Event Publisher מאחזר את פיד רשימת הגיליונות האלקטרוניים שמכיל רשומה אחת לכל שורה בגליון העבודה. כל שורה מייצגת אירוע יחיד, והנתונים מהשורה מאוכלסים במופעים של Event Bean. אוסף ה-Beans נשמר בסשן ומוצג גם במסך לאישור – באמצעות הדף outputEventList.jsp.
- פרסום הרשומות ביומן או ב-Base
- המשתמש בוחר את יעד הפרסום המתאים (יומן, בסיס או שניהם) ולוחץ על הלחצן 'פרסום'. האירועים נדחפים מאוסף אובייקטים של אירועים שמאוחסנים בסשן של המשתמש לשירותים המתאימים באמצעות השיטות
publishEventsToBase()ו-publishEventsToCalendarב-EventPublisher. ה-methods האלה יוצרות אובייקטים של רשומות מהסוגים המתאימים לשירותים:CalendarEventEntryו-GoogleBaseEntry. הערכים האלה נשלחים באמצעותHTTP POSTשמתבצע על ידי מחלקות השירותCalendarServiceו-GoogleBaseService - כשמפרסמים אירועים, כתובות ה-URL לעריכה שמוחזרות מכל שירות יעד מאוחסנות בגיליון האלקטרוני ב-Google באמצעות השיטה
EventPublisher.updateSsEventEditUrl(). באיטרציות עתידיות של תהליך הפרסום, המערכת עורכת אירועים שמכילים כתובת URL לעריכה של כל שירות רלוונטי בגיליון האלקטרוני, במקום ליצור אותם. כך נמנעת כפילות בנתוני האירועים.
- המשתמש בוחר את יעד הפרסום המתאים (יומן, בסיס או שניהם) ולוחץ על הלחצן 'פרסום'. האירועים נדחפים מאוסף אובייקטים של אירועים שמאוחסנים בסשן של המשתמש לשירותים המתאימים באמצעות השיטות
מיפוי הנתונים הנדרשים לעמודות בגיליון האלקטרוני ותצוגה מקדימה של האירועים שיפורסמו.
השלבים הבאים ושיפורים אפשריים
כפי שצוין קודם במאמר הזה, האפליקציה הזו היא כרגע רק אב-טיפוס. הקוד לא מיועד להיות מוכן לייצור. כדי להכין את Event Publisher לשימוש בסביבת ייצור, צריך לכלול בו טיפול בשגיאות. בשלב הזה, השגיאות נשלחות רק ל-stderr. במקום זאת, שגיאות שמתרחשות במהלך האחזור, הפרסום או פעולות אחרות צריכות להופיע בדפדפן של המשתמש.
בנוסף, חשוב לציין שב-Google Base, כדי לשמור על תקינות מערך הנתונים, תוקף הפריטים פג אחרי פרק זמן מסוים אם הם לא מעודכנים. אם אירוע כבר נוסף ל-Google Base, הכלי Event Publisher מנסה לעדכן את האירוע באמצעות כתובת ה-URL לעריכה שמאוחסנת בגיליון האלקטרוני של Google. אם תוקף הפריט של האירוע ב-Base פג, כתובת ה-URL לעריכה כבר לא תקפה ותוחזר שגיאת 404 בזמן הפרסום. פתרון עקיף אפשרי הוא לנסות להוסיף את האירוע עם קבלת תגובה 404.
תכונה נוספת שאפשר להוסיף לאפליקציה Event Publisher היא היכולת לאחסן ולפרסם את השעות המדויקות של האירועים, ולא רק את התאריך. מכיוון ש-Google Base דורש צירוף של שעות לאירועים, אחסון השעה של כל אירוע ימנע שיוך של שעות שרירותיות לאירועים ברשומות של Base. היומן יכול גם להציג את האירועים בזמנים המתאימים.
אולי תרצו גם מנגנון אחסון נתונים קבוע כדי לאחסן הגדרות של גיליונות אלקטרוניים מסוימים – כולל מיפוי עמודות. הנתונים יכולים להישמר בגיליון אלקטרוני נפרד ב-Google, במסד נתונים או באחסון בדיסק מקומי.
אני מקווה שהמאמר הזה עורר את הדמיון שלכם ויעזור לכם להעלות רעיונות חדשים ומעולים לאפליקציות שמנצלות את Google Data APIs. אם אתם רוצים לראות את המקור של האפליקציה הזו, לבנות אותה ולשנות אותה בהתאם לצרכים שלכם, תוכלו למצוא אותה ב-Java Client Library של Google Data APIs בספרייה mashups/eventpub. בנוסף, נשמח לקבל משוב על המאמר הזה בפורום המפתחים של Google Data APIs. לשאלות שקשורות לשירות ספציפי, אפשר לפרסם אותן בקבוצות הדיון הספציפיות לשירות.