כפי שציינתי בפוסט קודם, ה- API's המומלצים לפיתוח מול Ex2007 ו- Ex2010 הם:
- EWS - Exchange Web Services
- EWS Managed API
- Transport API's
בפוסט זה אסביר על API's אלו.
EWS
API זה הוא Web Services ששרת ה- Exchange חושף (ולייתר דיוק ה- CAS - Client Access Server חושף). דרך WS זה ניתן לבצע פעולות על אובייקטים בתיבות דואר. לדוגמא: ניתן לחפש מיילים, פגישות, אנשי קשר וכיו"ב, ניתן לייצר/לעדכן/למחוק אובייקטים וניתן לאחזר נתונים של אובייקטים בתיבת דואר.
הבהרה – במונח "אובייקטים" של תיבת דואר, הכוונה למיילים, פגישות, אנשי קשר וכיו"ב.
WS זה נחשף לראשונה בגרסת Ex2007 ובכל גרסא מתווספות יכולות חדשות. הרכיב חושף מבנה אובייקטים די מורכב (ולא תמיד אינטואיטיבי) המתאר באופן מלא את כל האובייקטים הקיימים בתיבת דואר.
אופן השימוש
מאחר והרכיב הוא WS, ניתן לצרוך אותו הן, ע"י שליחת soap message והן ע"י יצירת client proxy כאשר עובדים בסביבת dotnet.
ניתן לעבוד עם הרכיב הן מאפליקציות server והן מאפליקציות client. למשל, אם יש לי אתר אינטראנט שאני רוצה להציג בדף הפתיחה את 5 ההודעות האחרונות הקיימות בתיבת הדואר של המשתמש. ניתן לבצע זאת ע"י פנייה משכבת ה- BL, ע"י client proxy, אל ה – EWS (לשים לב למצב של double hoop). אפשרות נוספת, היא לייצר פניית soap מהדפדפן, ע"י Java script.
מאחר ורכיב זה חושף WS, ניתן לפנות אליו מכל סביבה. כך ניתן לפתח מול Exchange הן מ- Java, PHP וכיו"ב.
יכולות מעניינות
Notifications
API זה מאפשר "להאזין" לתיבת דואר ולקבל התראות (notifications) על שינויים של אובייקטים בתיבת הדואר. למשל, על דואר חדש שהגיע שזה בעצם אובייקט חדש בתיקיית Inbox בתיבת הדואר.
את ההתראות ניתן לקבל ב-3 שיטות:
Pull – מתבצע ע"י polling של ה- client.
Push – במהלך ה"רישום", ה- client מספק לשרת WS. כך, כאשר השרת מזהה שינוי שה- client נרשם אליו, הוא מבצע קריאה ל- WS זה.
Streaming – השרת מחזיק connection פתוח מול ה –client ודרכו מעביר התראות. זהו מימוש עתידי – "ישוחרר" ככל הנראה בגרסה הבאה של Exchange.
Auto Discover
מזהה באופן אוטומטי את כתובת ה – WS ע"י כתובת המייל. דבר זה מונע את התלות של אפליקציה בשינויים תחזוקתיים שמבצעים בשרת ה – Exchange.
OOF
מאפשר לעדכן סטטוס Out Of Office.
EWS Managed API
רכיב זה הוא dotnet assembly. הוא בעצם "מעטפת" (wrapper) על ה- EWS. מכאן 2 מאפיינים עיקריים:
1. כל היכולות הקיימות ב – EWS נחשפות גם ב – EWS Managed API.
2. ניתן לשימוש רק מסביבת dotnet.
נקודה חשובה!
אם ניתן, עדיף לעבוד עם רכיב זה על פני ה – EWS. רכיב זה חושף מבנה אובייקטים נוח ואינטואיטיבי. להערכתי, מקצר את זמן הפיתוח (לעומת EWS) בכ-50%.
Transport API's
מוכרים יותר בשם Transport Agents. רכיבים אלו הם Dotnet assemblies המאפשרים "להתערב" בתהליך של "תנועת" הודעות אל שרת ה – exchange וממנו החוצה.
מימושים עיקרים ע"י רכיב זה:
1. Exchange server rules - חוקים המגדירים מה לעשות עם הודעה שמגיעה ממען מסוים/עם תוכן מסוים וכו'.
2. המרת תוכן - מאפשר "לתפוס" כל הודעה יוצאת מהשרת ולהוסיף בה תוכן. לדוגמא: פרסומת, disclaimer וכו'.
3. Routing – מאפשר "לתפוס" הודעה שנכנסת לשרת, ולפני שמגיעה לתיבת הדואר אליה היא ממוענת, לשנות לה את תיבת הדואר היעד.
אופן השימוש
רכיב זה ניתן לשימוש רק בצד השרת. בצמוד לשרת ה – Exchange (וליתר דיוק ל- Transport Hub).
נשאלת השאלה: מה ההבדל בין רכיב זה לבין EWS Notifications?
ההבדל הוא שב – EWS Notifications, מקבלים את ה"התראה" לאחר שהודעה הגיעה לתיבת הדואר ואילו ב – Transport Agents ניתן לקבל "התראה" כאשר ההודעה הגיעה לשרת אך לפני ש"הועברה" לתיבת דואר מסויימת.
נקודה שיש לקחת בחשבון היא "ביצועים". מכיוון ש – Transport Agents "יושב" על ה – pipeline של הודעה נכנסת, כל עיבוד שמתבצע על הודעה, מעכב את הגעת ההודעה לתיבת הדואר לפחות כמשך זמן העיבוד.
לסיכום
אם יש צורך לאחזר מידע מתיבת דואר ו/או לבצע מניפולציה על אובייקטים בתיבת הדואר, נשתמש ב – EWS. אם אנחנו עובדים מסביבת dotnet, נעדיף שימוש ב – EWS Managed API.
אם אנחנו מעוניינים לבצע פעולות על הודעות עוד בטרם הגיעו לתיבת הדואר, נשתמש ב – Transport Agents.
וכרגיל, אם יש שאלות, אנא העבירו בתגובות של פוסט זה.
בהצלחה,
טל
תכנים נוספים:
Guide to Exchange Server 2010 Development Technologies
The Microsoft Exchange Team Blog
שירותי MCS בתחום: