מבוא ל-SAP System Landscape:
כתב: גיא גבאי
תאריך: 05.12.2018
אז כשאנחנו אומרים SAP System Landscape למה אנחנו בדיוק מתכוונים? מה ההבדל בין ה-SAP System Landscape לבין ה-SAP System Architecture? במאמר זה אנסה להסביר את ההבדלים ביניהם, נתמקד ב-System Landscape של SAP.
לעיתים קרובות, משתמשי SAP, בעיקר כאלו שהם חדשים בתחום לא מבינים את 2 הקונספטים האלו. ארכיטקטורת SAP היא למעשה המסגרת הטכנולוגית של מערכת ה-SAP. ארכיטקטורת ה-SAP (לעומת ה-System Landscape השתנתה לאורך השנים, ובעיקר לאחרונה, עם ההתפתחות של ה-SAP ECC.
דוגמא לארכיטקטורת מערכת של SAP היא ה-SAP R/3). למעשה כאשר אנחנו מדברים על ה-System Landscape אנו בעצם מדברים על ה-Setup או למעשה
הסידור של שרתי ה-SAP שלנו. באופן אידיאלי, נרצה שסביבת ה-SAP שלנו תיהיה מורכבת מ-3 חלקי מערכת. דוגמא ל-Landscape טוב שכולל 3 מערכות הוא אחד כזה שמורכב משרת פיתוח - או בקיצור: DEV, שרת אבטחת איכות - או בקיצור: QAS ושרת ייצור - או בקיצור: PROD. המטרה של Setup כמו שהוצג לעיל איננה בעיקר לשמש כאשכולות שרתים במקרה של כשל מערכתי, אלא המטרה העיקרית היא לשפר את מה שאנחנו קוראים לו: Configuration Pipeline Management.
להלן דוגמא ל-Landscape טיפוסי שמורכב מ-3 מערכות SAP:
בנימה זו חשוב לציין שמערכת TEST מסוג SANDBOX יכולה להיות קיימת בנפרד מהסכמה שתוארה לעיל. המטרה של סביבת ה-SANDBOX הוא לבחון את הקונפיגורצות של התהליכים העיסקיים של החברה, בייחוד בשלב ה-Inception של הפרויקט (לפני שה-Blueprint העיסקי נחתם).
בנוסף ניתן להשתמש בסביבת ה-SANDBOX גם למטרות תרגול, אפילו לאחר שהסתיים שלב העלייה לאוויר. סביבת ה-Pipeline זה היכן שעוברת הקונפיגורציה שהתבצעה במערכת הפיתוח ולאחר מכן עברה למערכת בקרת האיכות (הבדיקות) ולבסוף למערכת הייצור. הרעיון הכולל הוא להבטיח שהקונפיגורציות של המערכות האלו נמצאות בסנכרון בכל נקודת זמן שנבדוק. מספיק להגיד גם שקונפיגורציות/שינויים נעשים לראשונה במערכת הפיתוח, לאחר מכן נבדקים בכללותם במערכת בקרת האיכות לפני שהם נטענים לתוך מערכת הייצור מערכת ה-LIVE). הגישה שצוינה לעיל מביאה אותנו לדבר על הקונספט שנקרא: מערכת לניהול טרנספורטים. מערכת לניהול טרנספורטים דואגת שיתבצע תיאום של תנועת האובייקטים והקונפיגורציות שכוללות שינויים שבוצעו במערכת ממערכת הפיתוח למערכת אבטחת האיכות ולבסוף למערכת הייצור. לעיתים, התנועה שצוינה לעיל (DEV>QAS>PROD) לא מתאפשרת, בייחוד במקרים שישנו SAP NOTE שמחייב ששינויים יתבצעו ישירות על מערכת הייצור. במקרים נדירים אלו, לא ניתן להעביר בקשות מסוג CHANGE TRANSPORT.
מה שניתן לעשות הוא באופן הבא: בד"כ (וזה המצב שנרצה לשאוף אליו) אמורה להיות מבוצעת על המערכת שלנו קונפיגורציה של NOT MODIFIABLE (זוהי אסטרטגיית נעילה של המערכת שמחייבת שהמערכת תעבוד בצורת THREE-SYSTEM LANDSCAPE ובעצם כל שינוי דורש CHANGE TRANSPORT RULE). מה שנבצע הוא שחרור של המערכת ע"י שינוי של ההגדרה הגלובאלית של המערכת לכדי MODIFIABLE, את זה נעשה דרך טרנזקציה SE03. לאחר שביצענו את זה, נשקף את השינויים במערכת, ומיד לאחר מכן ננעל את המערכת בחזרה ע"י שינוי של ההגדרה הגלובלית ל-NOT MODIFIABLE תוך שימוש, שוב פעם, בטרנזקציה SE03. נבצע שכפול של השינויים למערכת השניה. חשוב לציין גם שטרנזקציה SCC4 יכולה גם לשמש לצורך נעילה של המערכת כך ששינויים/קונפיגורציות שתלויים/לא תלויים אחד בשני לא מתבצעים ישירות על מערכת הייצור.
לסיכום: ה-SAP System Landscape מוודא ששלמות הנתונים במערכת נשמרת ע"י אכיפה מבוקרת של שינויי קונפיגורציות שמשפיעים על מערכת היעד - מערכת הייצור.
עוד קצת מידע על Landscape:
Landscape זה כמו מערכת שרתים או כמו Layout של השרתים, או אפילו חלק יקראו לזה הארכיטקטורה של השרתים. למעשה, SAP מחולקת לכדי שלוש Landscapes שונים: DEV, QAS ו-PROD.
סביבת ה-DEV:
ייתכן ויהיו לה כמה Clients, למשל:
190 - Sandbox
100 - Golden
180 - Unit Test
סביבת ה-QAS:
ייתכן ויהיו גם לה, כמה Clients, למשל:
300 - Integration Test
700-710 - Training
סביבת ה-PROD:
למשל יהיה לה Client ממוספר ל-200.
השמות והמספרים שצוינו לעיל הם החלוקה שהמיישם ביצע לגבי איך שהוא רוצה שיראו הסביבות או איך שהשתמשו בהם במימושים קודמים שלו (בפרויקטים אחרים) או לפי חלוקה של התרחיש העיסקי של הלקוח. כעת, מה שאנחנו מבצעים בסביבת ה-Sandbox לא משפיע על שאר השרתים\קליינטים האחרים.
כאשר אנחנו מרוצים מהתוצאה של הקונפיגורציות שביצענו במערכת ואנחנו חושבים שאנחנו יכולים "להמשיך איתן הלאה" אנחנו מבצעים אותן שוב בקליינט ה-GOLDEN (חשוב לזכור, שהקליינט של ה-GOLDEN הוא CLIENT מאוד "רזה" ונקי ואל לנו להשתמש בו לשימושים מסיביים "וללכלך" אותו). לאחר שביצענו את כל מה שאנחנו חושבים שחשוב ושימושי, אנחנו מקבלים חלונית שקופצת לנו ומבקשת לבצע Transport, זאת בכל פעם שאנחנו מבצעים פעולה של שמירה. אנחנו שומרים את ה-Transport תחת Transport Request לבחירתנו ונותנים לו תיאור מתאים. לאחר מכן הקונפיגורציה מועברת אוטומטית לקליינט של ה-Unit Test (במקרה שלנו זהו Client בעל מזהה 180).
אנחנו לא אמורים להריץ שום טרנזקציה או בכלל להשתמש במסך ה-SAP Easy Access בקליינט ה-100 (שמכונה גם GOLDEN). זהו CLIENT שאמור לשמש לקונפיגורציה בלבד! כעת, לאחר שבוצע Transport מוצלח (בתקווה) ע"י הגורם BASIS בארגון, אמור להיות לנו את כל הקונפיגורציה שביצענו ב-Client של הבדיקות, בדיוק כמו שהיא קיימת ב-Client של ה-GOLDEN. הקונפיגורציה נשארת מסונכרנת בין 2 ה-Clients האלו. אך לעומת זאת, ב-Client של הבדיקות, אנחנו לא אמורים בכלל שתיהיה לנו את האפשרות לגשת ל-SPRO (מסך ה-IMG). זהו Client שאמור לשמש להרצת טרנזקציות לצורכי בדיקות. במידה והקונפיגורציה הייתה שגויה או לא מספיק טובה, אנחנו מתקנים אותה ב-Client של ה-GOLDEN (מומלץ לבצע ניסוי וטעייה בסביבת ה-Sandbox לפני ביצוע בסביבת ה-GOLDEN), ובאותו אופן, לאחר שסיימנו לבצע העברה של השינוי לסביבה 180 (בדיקות יחידה) עד שהבדיקות יחידה הן מספקות עבור השינוי שביצענו. ה-Client של ה-GOLDEN נשאר למעשה בסיס הנתונים שלנו (ניתן לקרוא לו גם ככה), או בעצם ניתן לקרוא לסביבה זו גם סביבת הייחוס האולטימטיבית עבור כל הקונפיגורציות הסופיות, השלמות והטובות שביצענו כחלק ממימוש הפרויקט שלנו.
לסיכום:
Landscape: סידור השרתים שלנו.
IDES: משמש לצרכים לימודיים ואיננו נכלל ב-Landscape
Development -> Quality -> Production
Development: זוהי הסביבה שבה היועצים מבצעים את הקסטומיזציות בהתאם לדרישות החברה.
Quality: זוהי הסביבה שבה חברי הצוות ושאר האנשים בודקים את הקסטומיזציות שבוצעו במערכת.
Production: זוהי הסביבה שבה נשמרים כל הנתונים "החיים" של החברה.
בקשת שינוי תעבור באופן הבא: Dev > Quality > Prod ולא הפוך.
- שרת Sandbox: בשלבים ראשוניים של כל פרויקט יישום, ניתן לנו שרת Sandbox שבו אנחנו יכולים לבצע את כל הקונפיגורציות/קסטומיזציות בהתאם לתהליכים העיסקיים של החברה.
- שרת Development: לאחר שנחתם ה-Blueprint העיסקי, מתבצעות כל הקונפיגורציות בשרת הפיתוח, ונשמרות בצורה של Workbench Requests, שמוכנים להעברה לשרת הייצור.
- שרת Production: זהו השרת שהמשתמש יעבוד עליו אחרי שהפרויקט יעלה לאוויר, כל השינויים שבוצעו אמורים להופיע בו.
כל שינוי/פיתוח חדש מתבצע ב-Client של הפיתוח ובקשת השינוי מועברת בצינורות המקובלים עד לסביבת הייצור. כל השלושה שצוינו לעיל הם חלק מה-Landscape של כל חברה, המפתחים מבצעים את פעולות הפיתוח שלהם על גבי שרת הפיתוח, ולאחר מכן מעבירים אותו לשרת הבדיקות, לאחר מכן בשרת הפיתוח, הבודק מבצע בדיקות של התוכניות ולאחר מכן מעביר את הפיתוח לשרת הייצור (לאחר שהבדיקות הסתיימו בהצלחה). ולבסוף, לאחר שכל הבדיקות הסתיימו בהצלחה, יבוצע מהלך של Deploy לשרת הייצור.
שרת ה-Presentation: היכן שה-SAP GUI נמצא.
שרת ה-Application: היכן שה-SAP מותקן.
שרת ה-Database: היכן שבסיס הנתונים מותקן.