שימוש ב- MSMQ לביצוע Decoupling מקסימלי, או איך לקבוע ארכיטקטורה מתאימה לאתגרי אינטגרציה בפיתוח מערכות בסביבת מיקרוסופט .Net - חלק ג'
מאמר זה הנו מאמר שלישי בסדרה של מאמרים אשר נושאם בכותרת. בחלק א' תיארתי את הארכיטקטורה של האינטגרציה ובחלק ב' דנו בעיצוב המערכת תוך התייחסות לאילוצים אשר תיארתי. בחלק זה של המאמר (חלק ג') אתאר את תהליך שליחת ההודעות בין המערכות.
נניח כי קיימים שני תהליכים - ממערכת א' למערכת ב', וממערכת ב' למערכת א'.
תזכורת: מערכת א' היא מערכת הקולטת הזמנות מהאינטרנט ה"יושבת" על שרתים ייעודיים באינטרנט. ההזמנות מגיעות מלקוחות שונים לספקים שונים. לכל ספק, יכולה להיות מותקנת מערכת הנהלת חשבונות (בד"כ - על מחשב עבודה - workstation) - היא מערכת ב'. האינטגרציה נעשית בין מערכת א' למספר רב של מערכות ב'.
תיאור זרימת ההודעות
תחילתו של התהליך בהזמנות אשר יכולות להגיע למערכת א' ממספר מקורות:
• 1. לקוח קימעונאי/סיטונאי.
• 2. מערכת ניהול.
• 3. מערכת ב' של לקוח.
• 4. מערכת ב' של הספק (דרך אינטגרציה מכיוון מערכת ב').
נתחיל בהתייחסות למקרים 1, 2 ו-3. למקרה 4 נתיחס בחלקו הבא של המאמר.
כשמתקבלת הזמנה חדשה במערכת א', נשלחת הודעה על הזמנה ל-General Queue אשר נמצא ב-Queue Server. שירות האינטגרציה אשר רץ על שרת זה כ-Windows Service, מקבל את ההודעה ומנתח אותה. במידה וקיימת שגיאה כל שהיא, ההודעה תועבר כפי שהיא לתור שגיאות (Error Queue) לבדיקות ועיבוד ידני. במידה וההודעה תקינה, נשלחת הודעה לשרת הדחיפה עם ייעוד למערכת ב' הספציפית.
כמה מילים על שרת הדחיפה (Push Server). כל לקוח של שרת זה מזדהה בעת החיבור עם שם משתמש+סיסמא. לאחר מכן, ניתן לשלוח הודעות לכל אחד מהלקוחות ע"י שימוש בשם המשתמש. הודעות יכולות להשלח מלקוח ללקוח (במידה וקיים קשר ביניהם, ז"א, כל אחד מהלקוחות האמורים אישר את משנהו), מהמערת ללקוח ומלקוח למערכת. ישנם סוגי הודעות שונים בעלי עדיפויות שונות, אשר ניתן לשלוח אותן עם הרשאות מתאימות.
כששרת הדחיפה מקבל הודעה, הוא בודק האם הלקוח כרגע נמצא במצב מכוון (Online). במידה וכן, ההודעה נשלחת ללקוח. תיעוד של ההודעה נשמר במסד הנתונים. במידה והלקוח קיבל ועיבד את ההודעה, תשלח הודעת אישור (Acknowledgement) וההודעה המקורית תמחק ממסד הנתונים. במידה ולא מתקבלת הודעת אישור, ההודעה המקורית תשלח מספר פעמים נוסף (לפי הגדרות) לפני שתעבור לסטטוס של "הודעות אבודות".
במידה ומערכת ב' כרגע איננה במצב מכוון (Offline), ההודעה נשמרת במסד הנתונים. כשמערכת ב' מתחברת, נעשית בדיקה אם מחכות לה הודעות. במידה וכן, הן נשלחות אליה על-פי סדר ההגעה המקורי.
כשהודעה מתקבלת בצד מערכת ב', היא נכנסת לתור (Queue). לקוח הדחיפה (Push Client) ישלח אישור על קבלת ההודעה. לאחר מכן, הליך ה-CIS (Client Integration Services) מוציא את ההודעה מהתור ובודק האם מערכת ב' נגישה. אם לא, ההודעה מועברת לתור אחר (Offline Queue). כשמערכת ב' תשוב לפעול, דבר ראשון ייקראו ההודעות מתור זה. במידה ומערכת ב' נגישה, ה-CIS יעבד על ידי מתאם (Adapter) מיוחד את ההודעה, והזמנה חדשה תתווסף למערכת ב'.
לסיכום, כשהזמנה נוצרת במערכת א', נשלחת הודעה ל-General Queue. לאחר מכן, ההודעה נשלחת לשרת הדחיפה ומשם ל-CIS אשר מותקן בצד הלקוח (Client). שם ההודעה מעובדת ומתורגמת למערכת ב', שם מתווספת הזמנה חדשה.
בחלק הבא של המאמר (חלק ד') אסביר את הליך זרימת הודעות ממערכת ב' למערכת א'.
עמית פאר מנהל פיתוח בחברת Because חברה המתמחה בסביבת פיתוח של מיקרוסופט - המספקת שירותי יעוץ ופיתוח כוללים לחברות גדולות ובינוניות. www.because.co.il
