מדריך לארכיטקטורה של Sap R/3:
מה זה SAP R/3?
SAP R/3 זוהי ארכיטקטורה מסוג 3 tier שמורכבת מ-3 שכבות:
תצוגה
אפליקציה
בסיס נתונים
במילים פשוטות, זוהי ארכיטקטורה מסוג שרת-לקוח.
R מציין: Real-time system
3 מציין: 3-tier architecture
User's PC: המשתמשים יכולים לגשת למערכת ה-SAP ב-2 דרכים:
1. תוך שימוש ב-SAP GUI
2. תוך שימוש בדפדפן אינטרנט
זה נקרא גם: front-end. רק ה-front-end מותקן במחשבי ה-PC של המשתמשים, לא שרתי האפליקציה/בסיס הנתונים.
ה-Front-end לוקח את בקשות המשתמשים לשרת בסיס הנתונים ולשרתי האפליקציה.
Application Servers: שרת האפליקציה נבנה על מנת לעבד לוגיקה עסקית. ה-workload הזה מבוזק בין כמה וכמה שרתי אפליקציה. כאשר אנחנו משתמשים בכמה שרתי אפליקציה, המשתמש יכול לקבל את הפלט הרבה יותר במהירות.
שרת האפליקציה קיים במיקום מרוחק בהשוואה למיקום של מחשב ה-PC של המשתמש.
Database Server: שרת בסיס הנתונים מאחסן ומאחזר נתונים בהתאם לשאילתות SQL שנוצרות ע"י קוד ABAP ואפליקציות Java.
ה-Database וה-Application יכולים להיות קיימים באותו מיקום פיזי או במיקום פיזי שונה.
כעת נבין את כל אחת מהשכבות השונות של SAP:
שכבת התצוגה:
שכבת התצוגה מכילה את רכיבי התוכנה שיוצרים את ה-SAPgui (ממשק משתמש גראפי). שכבה זו היא הממשק בין מערכת ה-R/3 לבין המשתמשים. מערכת ה-R/3 משתמשת ב-SAPgui על מנת לספק ממשק משתמש גראפי אינטואיטיבי שבו המשתמש יכול להזין או לצפות בנתונים.
שכבת התצוגה שולחת את הקלט של המשתמש לשרת האפליקציה, ומקבלת נתונים לצורך הצגה למשתמש. כאשר רכיב SAPgui נמצא במצב ריצה, הוא נותר מקושר ל-user's terminal session במערכת ה-R/3.
שכבת האפליקציה:
שכבת האפליקציה מורכבת מאחד או יותר שרתי אפליקציה וכן משרת הודעות. כל אחד משרתי האפליקציה מכיל קבוצה של שירותים שמשמשים על מנת להריץ את מערכת ה-R/3. באופן תאורטי, אנחנו זקוקים רק לשרת אפליקציה אחד על מנת להריץ את מערכת ה-R/3. בפועל, השירותים מבוזרים בין יותר משרת אפליקציה אחד. שרת ההודעות אחראי לתקשורת בין שרתי האפליקציה. הוא מעביר הודעות בין שרת אפליקציה אחד לאחר בתוך המערכת. בנוסף, הוא מכיל מידע לגבי קבוצות של שרתי אפליקציה וחוקת העומסים ביניהם.
הוא משתמש במידע זה על מנת להקצות שרת מתאים כאשר משתמש מתחבר לתוך המערכת.
שכבת בסיס הנתונים:
שכבת בסיס הנתונים מורכבת מבסיס נתונים מרכזי שמכיל את כל הנתונים במערכת ה-R/3. למערכת בסיס הנתונים יש 2 מרכיבים - מערכת ניהול בסיס הנתונים (DMBS), ובסיס הנתונים בעצמו. SAP פיתחה בעצמה את בסיס הנתונים שלה וקראה לו Hana, אך הוא עדיין בתאימות עם כל בסיסי הנתונים האחרים העיקריים כגון: Oracle. כל הנתונים של ה-R/3 נשמרים בבסיס הנתונים. לדוגמא, בסיס הנתונים מכיל את נתוני ה-control and customizing שקובעים כמובן איך מערכת ה-R/3 שלנו תרוץ.
אפליקציות מורכבות מקוד התוכנית, הגדרות של מסכים, תפריטים, מודולים של פונקציות ועוד.
כל אלו נשמרים במיקום ייחודי של בסיס הנתונים שנקרא R/3 Repository והם נקראים בהתאמה repository objects.
באובייקטים משתמשים ב-ABAP Workbench.
הסבר על המרכיבים של ארכיטקטורת ה-SAP R/3 3-tier:
1. שרת הודעות: מטפל בכל נושא התקשורת בין ה-Dispatchers המבוזרים במערכת ה-ABAP.
2. Dispatcher Queue: מגוון סוגים של תהליכי עבודה מאוחסנים בתור הזה.
3. Dispatcher: מבזר בקשות לתהליכי העבודה.
4. Gateway: מאפשר תקשורת בין מערכת ה-SAP ובין מערכת ה-SAP ומערכות חיצוניות.
5. ABAP-Work processes: מריץ בנפרד שלבי dialog באפליקציות R/3.
להלן הסוגים של תהליכי עבודה שקיימים במערכת:
6. Memory-pipes: מאפשר תקשורת בין ICM לבין תהליכי עבודה של ABAP.
7. Message Server: מטפל ב-java dispatchers ותהליכי השרת. מאפשר תקשורת בתוך ה-java runtime environment.
8. Enqueue Server: מטפל בנעילות לוגיות שנקבעות ע"י תוכניות Java בזמן ריצה בתהליכי שרת.
9. Central Services: אשכול java שדורש מופע מיוחד של שירותי ה-central על מנת לנהל את הנעילות ולשדר הודעות ונתונים. אשכול Java זהו סט של תהליכים שעובדים ביחד על מנת לבנות מערכת אמינה יותר. מופע זהו אוסף של משאבים כגון: זכרון, תהליך עבודה וכן הלאה...
10. Java Dispatcher: מקבל את בקשות הלקוח ומעביר הלאה לתהליך בשרת.
11. SDM: קיצור של: Software Deployment Manager, משמש על מנת להתקין רכיבי J2EE.
12. Java Server Processes: יכול לעבד מספר רב של בקשות בו זמנית.
13. Threading: מספר רב של תהליכים שרצים בנפרד ברקע, קונספט זה נקרא: threading.
14. ICM: מאפשר תקשורת בין מערכת ה-SAP לבין HTTP, HTTPS ופרוטוקול SMTP. משמע שכאשר אנחנו מזינים את כתובת המערכת (URL) בדפדפן אנחנו יכולים לגשת ל-SAP גם מהדפדפן.
עוד רכיב זהו ה-JCO, JCO משמש על מנת לטפל בתקשורת בין ה-java dispatcher ובין ה-ABAP dispatcher כאשר המערכת מוגדרת להיות: ABAP+Java.
איך עובד תהליך ה-SAP Logon?
שלב 1:
כאשר המשתמש לוחץ על מערכת ה-SAP מה-GUI, בקשת המשתמש מועברת ל-Dispatcher.
שלב 2:
הבקשה נשמרת ב-Request queues first. ה-Dispatcher עובד בשיטת: First in First out. הוא מחפש אחר תהליך עבודה פנוי וכאשר הוא ימצא אחד כזה הוא יקצה אותו אליו.
שלב 3:
בהתאם לבקשת המשתמש, תהליך עבודה ספציפי מוקצה למשתמש. לדוגמא, כאשר המשתמש מבצע התחברות למערכת, אז מוקצה לו Dialog work process. אם המשתמש מריץ דו"ח ברקע אז מוקצה לו: background work process. כאשר מתבצעים כמה שינויים ברמת בסיס הנתונים אז מוקצה לו update work process. לכן, בהתאם לפעולה של המשתמש, מוקצה לו ה-work process המתאים.
שלב 4:
ברגע שמוקצה למשתמש dialog work process, אזי הרשאות המשתמש, וההגדרות הנוכחיות שלו מועברות ל-work process ע"י הזיכרון המשותף על מנת שהתהליך יוכל לגשת לנתונים של המשתמש. כאשר מתבצע dialog step זאת אומרת תנועות כלשהן של המשתמש על גבי המסך, אז הנתונים בזיכרון המשותף מוחלפים בנתונים רלוונטיים אחרים של המשתמש. בטרנזקציה, כאשר המשתמש קופץ ממסך אחד לאחר התהליך נקרא dialog step.
שלב 5:
תהליך העבודה הראשון ימצא את הנתונים בחוצץ. אם הוא מוצא את הנתונים בחוצץ משמע שאין צורך לאחזר נתונים מבסיס הנתונים. במצב כזה זמן התגובה משתפר וזה נקרא hit. אם הוא לא מוצא את הנתונים הדרושים לו בחוצץ אז זה נקרא miss ובמצב כזה הוא ילך להביא את הנתונים מבסיס הנתונים. יחס ה-hit תמיד צריך להיות גבוה מיחס ה-miss. זה משפר את הביצועים של המערכת.
שלב 6:
נתונים אחרים שמבוקשים ע"י המשתמש מוצאים מבסיס הנתונים, ולאחר שהתהליך מסתיים, התוצאה נשלחת חזרה למשתמש (יותר נכון דרך ה-GUI) ע"י ה-dispatcher.
שלב 7:
בסוף, נתוני המשתמש נמחקים מהזכרון המשותף על מנת שהוא יהיה זמין למשתמשים אחרים. תהליך זה נקרא: roll-out.