תפריט נגישות

ניטור שירותים ו-Error Handling ב-OSB

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


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

קבוצת הכלים הראשונה מאפשרת לדווח ( Reporting ) ישירות ל- DB במבנה של key מסוים וערך מתאים, כחלק מתהליך עסקי כלשהו, ע"פ כל תנאי אפליקטיבי / עסקי שנבחר להגדיר ( KPI – Key Performance Indicator ). היתרון כאן הוא הפשטות שבעניין, אנו לא נדרשים להגדיר גישה למשאב חיצוני שמכיל את הדיווחים שלנו, אלא משתמשים ב יכולת הניתנת לנו out-of-the-box ו DB ייחודי שמגיע עם התקנת המוצר.

כלי דיווח נוסף הוא מנגנון ה- Alerts . באמצעותו נוכל להגדיר התראות, אותן נוכל לשלב היכן שנרצה, התראות אלה מבוססות גם הן על key-value כשה- Value פה יכול להיות כל ביטוי XQuery-Expression שקיים לנו ב- Flow העסקי בתהליך. המיוחד בהתראות אלה הוא שניתן לצפות בהן בתוך ה- Console של OSB עצמו, והן יעילות ונוחות מאוד לשימוש בזמן הפיתוח. ניתן להשתמש גם בכתיבה ללוג ברמות דיווח שונות, כפעולה אטומית בתהליך OSB .

הניטור קבוצת הכלים השניה הינה הכלים האוטומטיים:

ב- Oracle Service Bus אנו יכולים להגדיר לכל שירות ושירות SLA ייחודי משלו. לדוגמא, בארגון מסוים, OSB מפעיל שירות במערכת ה- CRM ואנו לא מוכנים לעכב את התהליך העסקי יותר מ-3 שניות עד להגעת תשובה מהשירות. נגדיר מראש פעולות אוטומטיות ש- OSB יבצע במקרה של חריגה מה- SLA . אנו יכולים להגדיר שליחת מייל התראה, כתיבה ל- DB , JMS , שליחת הודעת SNMP למערכת ניטור ועוד..

האחרון קבוצת הכלים האחרונה הינה כלי ה- Monitoring הנותן לנו מבט פנימה לתוך ביצועי השירותים. OSB אוסף כל העת מידע אודות פעילותם של השירותים ונותן לנו תמונת מצב עדכנית אודות פעילותם. לדוגמא, ניתן לראות, כמה הודעות עברו בשירות בפרק זמן מסוים, כמה מתוכן נכשלו, בדיקת זמינות נקודות הקצה אליהן פונה ה- OSB מתוך תהליך עסקי שבנינו בו וצפייה בזמן פעילות ממוצע של שירות. החלק המרכזי הוא היכולת לעשות drill down לרמת פעולה אטומית בתוך flow עסקי מורכב, ולזהות בשניות נקודות המעכבות או מכשילות את התהליך ( Root Cause Anlysis ). כלי זה יעיל מאוד לשימוש במערכות Production .

כעת, הגיע הזמן ללכלך קצת את הידיים!

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

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

בקצה השני מצויים השירותים בעלי flow עסקי שמבצעים קריאות לשירותים פנימיים בארגון. בכל שירות כזה יש לנו service error handler שתופס שגיאות וקורא לשירות הטיפול בשגיאות. במידה והתרחשה תקלה תשתיתית כלשהי (למשל, שירות פנימי לא היה זמין) ייזרק fault אוטומטית ב- OSB (עם קוד BEA ). השירות יזהה זאת ויכניס בשדה ה- XML י שמתאר את השגיאה את תוכן ה- fault . לעומת זאת, אם מדובר ב- fault שאנחנו זרקנו עקב שגיאה אפליקטיבית שזיהינו בריצת ה- flow , השדה ה- XML י שמתאר את השגיאה יקבל ערך מתוך שדה מסוים ב- flow המכיל את תוכן השגיאה האפליקטיבית. כך אנו מבטיחים שהשירות שלנו יתמוך באופן זהה בכל סוג של שגיאה.

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

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

כותבת המאמר: קובי שעיו - יועץ בכיר בחברת ליעם וואן1

 

ליצירת קשר: kobys@one1.co.il