如您所知，SAP 提供了一整套軟體，用於維護交易資料以及在分析和報告系統中處理這些資料。 特別是SAP Business Warehouse（SAP BW）平台是一個具有廣泛技術能力的儲存和分析資料的工具包。 儘管 SAP BW 系統具有所有客觀優勢，但它有一個顯著的缺點。 這是儲存和處理資料的高昂成本，在 Hana 上使用基於雲端的 SAP BW 時尤其明顯。
如果您開始使用一些非 SAP 並且最好是開源產品作為儲存怎麼辦？ 我們 X5 Retail Group 選擇了 GreenPlum。 當然，這解決了成本問題，但同時，使用 SAP BW 時幾乎預設解決的問題立即出現。
特別是，如何從來源系統（主要是 SAP 解決方案）檢索資料？
HR Metrics 是第一個需要解決這個問題的專案。 我們的目標是建立人力資源資料儲存庫，並在與員工合作的領域建立分析報告。 在本例中，主要資料來源是 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中的經理顯示：
儲存在資料庫表中：
員工資料儲存在 pa* 表中。 例如，員工的人事事件資料儲存在表 pa0000 中
我們決定 GreenPlum 將獲取「原始」數據，即只需從 SAP 表中複製它們即可。 它們將直接在 GreenPlum 中進行處理並轉換為實體物件（例如部門或員工）和指標（例如平均人數）。
定義了大約 70 個表，其中的資料必須傳輸到 GreenPlum。 之後我們開始研究傳輸這些數據的方法。
SAP 提供了大量的整合機制。 但最簡單的方法是由於許可限製而禁止直接存取資料庫。 因此，所有整合流程必須在應用程式伺服器層級實現。
下一個問題是 SAP 資料庫中缺少有關已刪除記錄的資料。 當您刪除資料庫中的一行時，它會被物理刪除。 那些。 基於變化時間形成變化增量是不可能的。
當然，SAP HCM 具有記錄資料變更的機制。 例如，對於隨後傳輸到接收方系統，存在記錄任何更改的更改指針，並在此基礎上形成 Idoc（用於傳輸到外部系統的物件）。
用於更改人員編號為 0302 的員工的資訊類型 1251445 的 IDoc 範例：
或在 DBTABLOG 表中儲存資料變更日誌。
從hrp53216375表中刪除鍵為QK1000的記錄的日誌範例：
但這些機制並不適用於所有必要的數據，而且它們在應用程式伺服器層級的處理可能會消耗相當多的資源。 因此，在所有必要的表上大量啟用日誌記錄可能會導致系統效能明顯下降。
下一個主要問題是聚集表。 SAP HCM RDBMS 版本中的時間估算和薪資資料儲存為每位員工每次計算的一組邏輯表。 這些邏輯表作為二進位資料儲存在表 pcl2 中。
薪資集群：
來自叢集表的資料不能被視為SQL指令，而是需要使用SAP HCM巨集或特殊功能模組。 因此，此類表的讀取速度會相當低。 另一方面，此類叢集儲存每月僅需要一次的資料 - 最終工資單和時間估算。 所以在這種情況下速度就沒那麼重要。
在評估形成資料變更增量的選項時，我們決定也考慮完全卸載的選項。 每天在系統之間傳輸千兆位元組的未更改資料的選擇可能看起來不太好。 然而，它也有許多優點——不需要在來源端實現增量並在接收器端實現該增量的嵌入。 因此，降低了成本和實施時間，並提高了整合的可靠性。 同時，我們確定 SAP HR 中的幾乎所有變更都發生在當前日期之前的三個月內。 因此，決定選擇在當前日期前 N 個月從 SAP HR 每日完整下載數據，以及每月完整下載。 N參數取決於具體表格
範圍從 1 到 15。
提出了以下資料擷取方案：
外部系統產生請求並將其傳送至 SAP HCM，在 SAP HCM 中檢查該要求的資料完整性和存取表的權限。 如果檢查成功，SAP HCM 會執行一個程式來收集必要的資料並將其傳輸到 Fuse 整合解決方案。 Fuse 確定 Kafka 中所需的主題並將資料傳輸到那裡。 接下來，來自Kafka的資料被傳送到Stage Area GP。
在這個鏈條中，我們感興趣的是從 SAP HCM 中提取資料的問題。 讓我們更詳細地看看它。
SAP HCM-FUSE 交互圖。
外部系統決定最後一次成功向 SAP 發出請求的時間。
該流程可以透過計時器或其他事件啟動，包括設定逾時以等待 SAP 的資料回應並啟動重複請求。 然後它產生一個增量請求並將其發送到 SAP。
請求資料以json格式傳送到body。
方法http：POST。
請求範例：
SAP 服務監視請求的完整性、是否符合目前 SAP 結構以及所請求表的存取權限的可用性。
如果發生錯誤，服務將傳回帶有適當代碼和描述的回應。 如果控製成功，它會建立一個後台程序來產生樣本，產生並同步傳回唯一的會話id。
如果發生錯誤，外部系統會將其記錄在日誌中。 如果回應成功，它將傳輸會話 ID 和發出請求的表的名稱。
外部系統將目前會話註冊為開啟。 如果該表還有其他會話，它們將關閉並記錄警告。
SAP後台作業會根據指定的參數和指定大小的資料包產生遊標。 批次大小是進程從資料庫讀取的最大記錄數。 預設情況下，假定等於2000。如果資料庫樣本中的記錄多於所使用的資料包大小，則在傳輸第一個資料包後，將使用對應的偏移量和遞增的資料包編號來形成下一個區塊。 數字加 1 並嚴格依序發送。
接下來，SAP 將封包作為輸入傳遞到外部系統的 Web 服務。 系統對傳入的資料包進行控制。 具有接收到的 ID 的會話必須在系統中註冊，並且必須處於開啟狀態。 若包裹編號> 1，系統應記錄成功接收前一個包裹（package_id-1）。
如果控製成功，外部系統解析並保存表格資料。
此外，如果套件中存在最終標誌且序列化成功，則會通知整合模組會話處理已成功完成，並且該模組會更新會話狀態。
如果出現控制/解析錯誤，則會記錄該錯誤，並且該會話的資料包將被外部系統拒絕。
同樣，在相反的情況下，當外部系統傳回錯誤時，會記錄該錯誤並停止資料包傳輸。
為了請求 SAP HСM 端的數據，實施了整合服務。 該服務是在 ICF 框架（SAP Internet Communication Framework - ）。 它允許您使用特定表從 SAP HCM 系統查詢資料。 建立資料請求時，可以指定特定欄位的清單和篩選參數，以獲得必要的資料。 同時，服務的實作並不隱含任何業務邏輯。 計算delta、查詢參數、完整性監控等演算法也在外部系統側實現。
這種機制可讓您在幾個小時內收集和傳輸所有必要的數據。 這個速度已經可以接受了，所以我們認為這個解決方案是一個臨時的解決方案，它可以滿足專案上對提取工具的需求。
在目標圖中，為了解決資料擷取問題，正在探索使用Oracle Golden Gate等CDC系統或SAP DS等ETL工具的選項。
來源： www.habr.com