מקור נתונים של SAP ERP

‫Google Cloud Cortex Framework data foundation layer for SAP ERP מחייב קישוריות לנתונים הגולמיים של מערכת המקור. יש תמיכה גם ב-SAP ECC וגם ב-SAP S/4HANA.

לפני שמפעילים תוכן של Cortex Framework, צריך לשכפל טבלאות רלוונטיות של SAP ERP ל-BigQuery. כדי לעשות את זה, אפשר להנחית נתונים במערך נתונים ייעודי של שכבת נתונים גולמיים לעיבוד של סימון נתונים שהשתנו (CDC), או להשתמש בצינורות CDC מבוססים כדי להזין את שכבת בסיס הנתונים ישירות. מידע נוסף זמין במאמר בנושא דרישות טכניות לשכפול נתונים של SAP ERP.

אתם יכולים להשתמש בכל כלי שכפול שתבחרו, בתנאי שהוא יכול לשכפל נתונים בפורמט של טבלה לא מעובדת ל-BigQuery. לדוגמה,Google Cloud פתרונות כוללים את BigQuery Connector for SAP (נדרש SAP SLT) ואת BigQuery Toolkit for SAP.

כדי להבטיח תאימות בין מערכי הנתונים הגולמיים המשוכפלים מ-SAP ERP לבין שכבת בסיס הנתונים של Cortex Framework, צריך לוודא שאתם עומדים בדרישות הבאות.

דרישות טכניות לשכפול נתונים מ-SAP ERP

חשוב לעיין בדרישות הטכניות הבאות ולהשלים אותן כדי לשכפל נתוני SAP ל-Cortex Framework ב-BigQuery.

  1. מבנה הנתונים הגולמיים: הנתונים מ-ECC או מ-S/4HANA צריכים להגיע ל-BigQuery עם אותו מבנה כמו של טבלאות הבסיס ב-SAP, בלי שינויים עסקיים. צריך לשכפל את הטבלאות עם שמות השדות, הסוגים והגרנולריות הנדרשים, כמו שהם מופיעים ב-SAP.

  2. הגדרת הטבלה: רשימת הטבלאות שצריך להמיר מוגדרת בקובץ table_settings.yaml (שנמצא בתיקייה config/cortex/data_foundation/sap). אם חסרה טבלה נדרשת במהלך הפריסה, מוצרי הנתונים הספציפיים שתלויים בה ייכשלו.

  3. דרישות לגבי מטא-נתונים: צריך לשכפל את הטבלה DD03L ממקור ה-SAP. הטבלה הזו קריטית לפתרון התלות, כי היא מכילה מטא-נתונים ומפתחות של שדות.

  4. שימוש באותיות קטנות: כדי להבטיח תאימות למודל הנתונים של Cortex Framework, השמות של טבלאות SAP שהועתקו ב-BigQuery צריכים להיות באותיות קטנות (לדוגמה, טבלת SAP‏ MARA הופכת ל-mara ב-BigQuery).

  5. שמות של אובייקטים (עמודות) ותווים מיוחדים: כששמות של אובייקטים (עמודות) מכילים תווים מיוחדים (כמו /, - או קו תחתון מוביל _), מערכת Cortex מצפה לתבנית כללית של ניקוי:

    • כל התווים שאינם אלפאנומריים מוחלפים בקו תחתון _.
    • אסור להשתמש בקווים תחתונים או בספרות בתחילת השם. לדוגמה, /GOOG/TEST הופך ל-goog_test, ו-_DATAAGING הופך ל-dataaging. אם כלי השכפול שומר על קו תחתון מוביל בנתונים, נדרש שלב נירמול (כינוי) בשכבת Data Foundation.

  6. שדות להפצת נתונים: כדי לתמוך ב-CDC (סימון נתונים שהשתנו) ובהפצת נתונים, בטבלאות SAP שנוצרו מהן רפליקות צריכים להיות:

    • דגל פעולה בשם operation_flag (L = טעינה ראשונית, I = הוספה, U = עדכון, D = מחיקה).
    • חותמת זמן בשם recordstamp (מאוכלסת בחותמת הזמן הנוכחית בזמן הטעינה).
    • אופציונלי: שדה נוסף is_deleted (BOOLEAN) נבחר בטבלאות _DS_RAW משוכפלות (ברירת המחדל היא false בטעינה הראשונית). תצוגות בזמן ריצה שנוצרות על ידי Cortex מפנות לעמודה הזו, אבל אפשר להסיר אותה מתבניות של CDC ותצוגות לפני ההפעלה אם כלי השכפול לא יוצר אותה.

  7. סוגי נתונים: מיפוי נדרש של סוגי נתונים ב-SAP עם סוגי נתונים ב-BigQuery לצורך תאימות:

    הכרחיות לפעולות רגילות:

    סוג הנתונים SAP סוג הנתונים BigQuery תיאור
    DATS DATE סוג הנתונים: תאריך
    TIMS TIME סוג נתונים של זמן

  8. מומלץ מאוד לדיוק ולתאימות:

    • ‫CURR (מטבע) ו-QUAN (כמות) ממופים ל-NUMERIC או ל-BIGNUMERIC (כדי למנוע שגיאות עיגול בחישובים פיננסיים, מומלץ להימנע משימוש ב-FLOAT64).
    • ‫NUMC (תווים מספריים) ממופים ל-STRING (כדי לשמור על אפסים מובילים למספרי מסמכים ומספרי פריטים, וכך להבטיח צירופים מוצלחים).
    CAST

  9. דחיסת מטען ייעודי (payload): כדי למנוע מצבים שבהם עמודות ריקות ב-SAP (ערכים ראשוניים כמו רווחים או אפסים) ימולאו ב-NULL ב-BigQuery, צריך לוודא שדחיסת המטען הייעודי מושבתת בהגדרות של המחבר (או שהאפשרות 'שליחה לא דחוסה' מופעלת). כך אפשר לוודא שמחרוזות ריקות או אפסים נשמרים כמו שהם ביעד, במקום להשתנות ל-NULL.