חילוץ נתונים מ-SAP HCM למחסני נתונים שאינם SAP

כידוע, SAP מציעה מגוון שלם של תוכנות, הן לשמירה על נתוני עסקאות והן לעיבוד נתונים אלו במערכות ניתוח ודיווח. בפרט, פלטפורמת SAP Business Warehouse (SAP BW) היא ערכת כלים לאחסון וניתוח נתונים עם יכולות טכניות רחבות. עם כל היתרונות האובייקטיביים שלה, למערכת SAP BW יש חיסרון אחד משמעותי. זוהי עלות גבוהה של אחסון ועיבוד נתונים, בולטת במיוחד בעת שימוש ב-SAP BW מבוסס ענן על Hana.

אבל מה אם תתחיל להשתמש באיזה שהוא לא SAP ורצוי במוצר OpenSource כמאגר? אנחנו ב-X5 Retail Group בחרנו ב- GreenPlum. זה כמובן פותר את סוגיית העלות, אך יחד עם זאת צצות מיד שאלות שבשימוש ב-SAP BW נפתרו כמעט כברירת מחדל.

בפרט, איך לקחת נתונים ממערכות מקור, שהן לרוב פתרונות SAP?

"מדדי HR" היה הפרויקט הראשון בו היה צורך לפתור בעיה זו. המטרה שלנו הייתה ליצור מאגר של נתוני משאבי אנוש ולבנות דיווח אנליטי בכיוון העבודה עם העובדים. יחד עם זאת, מקור הנתונים העיקרי הוא מערכת הטרנזקציות SAP HCM, בה מתקיימת כל פעילויות כוח האדם, הארגוניות והשכר.

חילוץ מידע

ל-SAP BW למערכות SAP יש מחלצי נתונים סטנדרטיים. מחלצים אלה יכולים לאסוף אוטומטית את הנתונים הדרושים, לעקוב אחר שלמותם ולקבוע דלתות שינויים. הנה, למשל, מקור הנתונים הסטנדרטי עבור תכונות עובד 0EMPLOYEE_ATTR:

התוצאה של חילוץ נתונים ממנו עבור עובד אחד:

במידת הצורך, ניתן לשנות חולץ כזה כדי שיתאים לדרישות שלך, או שאתה יכול ליצור חולץ משלך.

הרעיון הראשון היה לעשות בהם שימוש חוזר. למרבה הצער, זו התבררה כמשימה בלתי אפשרית. רוב ההיגיון מיושם בצד של SAP BW, ולא ניתן היה להפריד ללא כאב את המחלץ במקור מ-SAP BW.

התברר כי יהיה צורך לפתח מנגנון משלנו לחילוץ נתונים ממערכות SAP.

מבנה אחסון נתונים ב-SAP HCM

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

רוב הנתונים ב-SAP HCM מאוחסנים בטבלאות SQL שטוחות. בהתבסס על נתונים אלה, יישומי SAP מדגים למשתמש מבנים ארגוניים, עובדים ומידע אחר על משאבי אנוש. לדוגמה, כך נראה המבנה הארגוני ב-SAP HCM:

מבחינה פיזית, עץ כזה מאוחסן בשתי טבלאות - ב-hrp1000 אובייקטים וב-hrp1001 הקישורים בין אובייקטים אלו.

אובייקטים "מחלקה 1" ו"מחלקה 1":

תקשורת בין אובייקטים:

יכול להיות מספר עצום של סוגי חפצים, כמו גם סוגי קשרים ביניהם. ישנם גם חיבורים סטנדרטיים בין אובייקטים, וגם חיבורים מותאמים לצרכים הספציפיים שלך. לדוגמה, הקשר הסטנדרטי B012 בין יחידה ארגונית לתפקיד מטה מציין ראש מחלקה.

מציג מנהל ב-SAP:

אחסון בטבלת DB:

נתוני העובדים מאוחסנים בטבלאות pa*. לדוגמה, נתונים על פעילויות כוח אדם עבור עובד מאוחסנים בטבלה pa0000

קיבלנו את ההחלטה ש-GreenPlum תאסוף נתונים "גולמיים", כלומר. פשוט העתק אותם מטבלאות SAP. וכבר ישירות ב-GreenPlum הם יעובדו ויומרו לאובייקטים פיזיים (לדוגמה, מחלקה או עובד) ומדדים (לדוגמה, מספר עובדים ממוצע).

הוגדרו כ-70 טבלאות, מהן יש להעביר את הנתונים ל-GreenPlum. לאחר מכן, התחלנו למצוא דרך להעביר את הנתונים הללו.

SAP מציעה מספר גדול למדי של מנגנוני אינטגרציה. אבל הדרך הקלה ביותר היא שגישה ישירה למסד הנתונים אסורה עקב מגבלות רישוי. לפיכך, יש ליישם את כל זרימות האינטגרציה ברמת שרת היישומים.
הבעיה הבאה הייתה המחסור בנתונים על רשומות שנמחקו במסד הנתונים של SAP. כאשר אתה מוחק שורה במסד הנתונים, היא נמחקת פיזית. הָהֵן. היווצרות דלתא של שינויים לאורך זמן השינוי לא הייתה אפשרית.

כמובן של-SAP HCM יש מנגנונים לתיקון שינויים בנתונים. למשל, להעברה לאחר מכן למערכות נמענות, ישנם מצביעי שינוי המתקנים כל שינוי ועל בסיסם נוצר Idoc (אובייקט להעברה למערכות חיצוניות).

דוגמה ל-IDoc לשינוי טיפוס מידע 0302 עבור עובד עם מספר כוח אדם 1251445:

או רישום שינויים בנתונים בטבלת DBTABLOG.

דוגמה ליומן למחיקת ערך עם המפתח QK53216375 מטבלת hrp1000:

אבל מנגנונים אלה אינם זמינים עבור כל הנתונים הדרושים, ועיבודם ברמת שרת היישומים יכול לצרוך משאבים רבים למדי. לכן, הכללה המונית של רישום על כל הטבלאות הדרושות יכולה להוביל לירידה ניכרת בביצועי המערכת.

הבעיה הגדולה הבאה הייתה טבלאות מקובצות. הערכת זמן ונתוני שכר בגרסת RDBMS של SAP HCM מאוחסנים כקבוצה של טבלאות לוגיות לכל עובד לכל שכר. טבלאות לוגיות אלו מאוחסנות כנתונים בינאריים בטבלת pcl2.

אשכול שכר:

לא ניתן לקרוא נתונים מטבלאות מקובצות כפקודה SQL, אך נדרש שימוש בפקודות מאקרו של SAP HCM או מודולי פונקציות מיוחדות. בהתאם לכך, מהירות הקריאה של טבלאות כאלה תהיה נמוכה למדי. מאידך, אשכולות כאלה מאחסנים נתונים הדרושים רק פעם בחודש - השכר הסופי והערכות זמן. אז המהירות במקרה זה לא כל כך קריטית.

בהערכת האפשרויות עם היווצרות דלתא לשינוי נתונים, החלטנו גם לשקול את האפשרות עם העלאה מלאה. האפשרות של העברת גיגה-בייט של נתונים ללא שינוי בין מערכות בכל יום לא יכולה להיראות יפה. עם זאת, יש לה גם מספר יתרונות – אין צורך גם ליישם את הדלתא בצד המקור וגם להטמיע את ההטמעה של הדלתא הזו בצד המקלט. בהתאם לכך, העלות וזמן היישום מצטמצמים, ואמינות האינטגרציה גדלה. יחד עם זאת, נקבע כי כמעט כל השינויים ב-SAP HR מתרחשים באופק של שלושה חודשים לפני התאריך הנוכחי. לפיכך, הוחלט לעצור בהעלאה מלאה יומית של נתונים מ-SAP HR N חודשים לפני התאריך הנוכחי והעלאה מלאה חודשית. הפרמטר N תלוי בטבלה הספציפית
ונע בין 1 ל-15.

התוכנית הבאה הוצעה להפקת נתונים:

המערכת החיצונית מייצרת בקשה ושולחת אותה ל-SAP HCM, שם הבקשה הזו נבדקת לגבי שלמות הנתונים והרשאות הגישה לטבלאות. במקרה של בדיקה מוצלחת, SAP HCM מפעילה תוכנית שאוספת את הנתונים הדרושים ומעבירה אותם לפתרון האינטגרציה של Fuse. פיוז קובע את הנושא הנדרש בקפקא ומעביר את הנתונים לשם. יתר על כן, הנתונים מקפקא מועברים ל-Stage Area GP.

בשרשרת זו אנו מתעניינים בנושא חילוץ הנתונים מ-SAP HCM. בואו נתעכב על זה ביתר פירוט.

דיאגרמת אינטראקציה של SAP HCM-FUSE.

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

נתוני הבקשה מועברים לגוף בפורמט json.
שיטת http: POST.
דוגמה לבקש:

שירות SAP שולט בבקשה לשלמות, תאימות למבנה SAP הנוכחי וזמינות ההרשאה לגשת לטבלה המבוקשת.

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

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

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

עבודת הרקע של SAP יוצרת סמן עם הפרמטרים שצוינו וחבילת נתונים בגודל שצוין. גודל אצווה - המספר המרבי של רשומות שהתהליך קורא ממסד הנתונים. ערך ברירת המחדל הוא 2000. אם יש יותר רשומות בבחירת מסד הנתונים מאשר גודל החבילה בשימוש, לאחר שידור החבילה הראשונה, הבלוק הבא נוצר עם ההיסט המקביל ומספר החבילה המוגדל. המספרים מוגדלים ב-1 ונשלחים ברצף.

לאחר מכן, SAP מעבירה את החבילה לקלט של שירות האינטרנט של המערכת החיצונית. והמערכת היא זו שמבצעת בקרה על החבילה הנכנסת. יש לרשום הפעלה עם המזהה שהתקבל במערכת ועליה להיות במצב פתוח. אם מספר החבילה > 1, המערכת צריכה לרשום את הקבלה המוצלחת של החבילה הקודמת (package_id-1).

במקרה של שליטה מוצלחת, המערכת החיצונית מנתחת ושומרת את נתוני הטבלה.

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

במקרה של שגיאת שליטה/ניתוח, השגיאה נרשמת ומנות עבור הפעלה זו יידחו על ידי המערכת החיצונית.

באופן דומה, במקרה ההפוך, כאשר המערכת החיצונית מחזירה שגיאה, היא נרשמת והעברת המנות נעצרת.

כדי לבקש נתונים בצד SAP HCM, הופעל שירות אינטגרציה. השירות מיושם במסגרת ICF (SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). זה מאפשר לך לבצע שאילתות בנתונים ממערכת SAP HCM עבור טבלאות ספציפיות. בעת יצירת בקשת נתונים, ניתן לציין רשימה של שדות ספציפיים ופרמטרי סינון על מנת לקבל את הנתונים הדרושים. יחד עם זאת, יישום השירות אינו מרמז על היגיון עסקי כלשהו. אלגוריתמים לחישוב דלתא, פרמטרי שאילתה, בקרת תקינות וכו' מיושמים גם בצד המערכת החיצונית.

מנגנון זה מאפשר לך לאסוף ולשדר את כל הנתונים הדרושים תוך מספר שעות. מהירות זו היא על סף מקובל, ולכן החלטה זו נחשבת בעינינו כהחלטה זמנית, מה שאפשרה לנו לסגור את הצורך בכלי מיצוי בפרויקט.
בתמונת היעד, כדי לפתור את בעיית חילוץ הנתונים, מפתחים אפשרויות לשימוש במערכות CDC כגון Oracle Golden Gate או כלי ETL כגון SAP DS.

מקור: www.habr.com