SAPHCMから非SAPデータウェアハウスへのデータの抽出

ご存知のように、SAPは、トランザクションデータの保守と、分析およびレポートシステムでのこのデータの処理の両方のために、あらゆる種類のソフトウェアを提供しています。特に、SAP Business Warehouse（SAP BW）プラットフォームは、幅広い技術的機能を備えたデータを保存および分析するためのツールキットです。 SAP BWシステムには、そのすべての客観的な利点に対して、1つの重大な欠点があります。これは、特にHanaでクラウドベースのSAP BWを使用する場合、データの保存と処理に高いコストがかかります。



しかし、SAP以外の、できればOpenSource製品をストレージとして使用し始めたらどうなるでしょうか。X5 RetailGroupではGreenPlumを選択しました。もちろん、これでコストの問題は解決しますが、同時に、SAP BWを使用すると、ほぼデフォルトで解決されるという疑問がすぐに発生します。







特に、ほとんどがSAPソリューションであるソースシステムからデータを取得する方法は？



HR Metricsは、この問題に対処した最初のプロジェクトでした。私たちの目標は、HRデータ用のウェアハウスを作成し、従業員との作業の分野で分析レポートを作成することでした。この場合、データの主なソースはSAP HCMトランザクションシステムであり、すべての人員、組織、および給与の活動が実行されます。

データ抽出

SAPシステム用のSAPBWには標準のデータ抽出機能があります。これらのエクストラクタは、必要なデータを自動的に収集し、それらの整合性を追跡し、変更のデルタを決定できます。たとえば、従業員属性の標準データソースは次のとおりです。0EMPLOYEE_ATTR：







一度に1人の従業員からのデータ抽出の結果：







必要に応じて、このような抽出機能を独自の要件に合わせて変更したり、独自の抽出機能を作成したりできます。



最初のアイデアは、それらの再利用の可能性について生まれました。残念ながら、これは不可能な作業であることが判明しました。ほとんどのロジックはSAPBW側で実装されており、ソースのエクストラクタをSAPBWから簡単に分離することはできませんでした。



SAPシステムからデータを抽出するためのカスタムメカニズムを開発する必要があることが明らかになりました。

SAPHCMのデータストレージ構造

このようなメカニズムの要件を理解するには、最初に必要なデータの種類を決定する必要があります。



SAP HCMのほとんどのデータは、フラットなSQLテーブルに格納されます。このデータに基づいて、SAPアプリケーションは、組織構造、従業員、およびその他のHR情報をユーザーに視覚化します。たとえば、これはSAP HCMでの組織構造の外観です。







物理的には、このようなツリーは2つのテーブル（hrp1000オブジェクトとhrp1001）にこれらのオブジェクト間のリンクで格納されます。



オブジェクト「Department1」と「Office1」：







オブジェクト間の関係：







オブジェクトのタイプとオブジェクト間の通信のタイプの両方が膨大な数になる可能性があります。オブジェクト間には標準のリンクがあり、特定のニーズに合わせてカスタマイズされています。たとえば、組織単位と常勤職の間の標準的なB012関係は、部門の責任者を示します。



SAPでのマネージャーマッピング：







DBテーブルのストレージ：







従業員データはpa *テーブルに保存されます。たとえば、従業員の人員配置に関するデータはpa0000テーブルに保存されます







。GreenPlumは「生の」データを取得することを決定しました。SAPテーブルからそれらをコピーするだけです。そして、すでにGreenPlumで直接処理され、物理オブジェクト（DepartmentやEmployeeなど）とメトリック（平均人数など）に変換されます。



約70のテーブルが定義されており、そこからデータをGreenPlumに転送する必要があります。その後、このデータを転送する方法を考え始めました。



SAPは、かなりの数の統合メカニズムを提供しています。ただし、最も簡単な方法は、ライセンスの制限により、データベースへの直接アクセスが禁止されていることです。したがって、すべての統合フローは、アプリケーションサーバーレベルで実装する必要があります。

次の問題は、SAPデータベースで削除されたレコードに関するデータが不足していることでした。データベース内の行が削除されると、その行は物理的に削除されます。それら。変化の時間にわたる変化のデルタの形成は不可能でした。



もちろん、SAPHCMにはデータ変更をコミットするためのメカニズムがあります。たとえば、その後のシステムへの送信のために、受信者は変更を記録し、それに基づいてIdoc（外部システムへの送信のオブジェクト）が形成される変更ポインターを持っています。



担当者番号1251445の従業員のインフォタイプ0302を変更するためのIDocの例：







またはテーブルDBTABLOGのデータ変更ログを維持します。



hrp1000テーブルからQK53216375キーを使用してエントリを削除するためのログの例：







ただし、これらのメカニズムは必要なすべてのデータに使用できるわけではなく、アプリケーションサーバーレベルでの処理は多くのリソースを消費する可能性があります。したがって、必要なすべてのテーブルにログを大量に含めると、システムパフォーマンスが著しく低下する可能性があります。



クラスター化されたテーブルが次の大きな問題でした。 SAP HCMのRDBMSバージョンの時間見積もりと給与データは、給与ごとの従業員ごとの論理テーブルのセットとして保存されます。これらの論理テーブルは、バイナリデータとしてpcl2テーブルに格納されます。



ペイロールクラスター：







クラスター化されたテーブルのデータはSQLコマンドで読み取ることができず、SAPHCMマクロまたは特別な汎用モジュールを使用する必要があります。したがって、そのようなテーブルを読み取る速度は非常に遅くなります。一方、このようなクラスターには、月に1回だけ必要なデータ（最終的な給与と時間の見積もり）が格納されます。したがって、この場合の速度はそれほど重要ではありません。



データ変更のデルタの形成を伴うオプションを評価するために、完全なアンロードを伴うオプションも検討することにしました。ギガバイトの変更されていないデータをシステム間で毎日転送するオプションは、見栄えがよくありません。ただし、これにはいくつかの利点もあります。ソース側でのデルタの実装と、レシーバー側でのこのデルタの埋め込みの実装の両方を実装する必要はありません。したがって、コストと実装時間が削減され、統合の信頼性が向上します。同時に、SAP HRのほとんどすべての変更は、現在の日付の3か月前の期間に発生することが判明しました。したがって、現在の日付のNか月前にSAP HRからのデータの毎日の完全ダウンロードと、毎月の完全ダウンロードで停止することが決定されました。パラメータNは特定のテーブルに依存し、

範囲は1〜15です。



データ抽出のために、次のスキームが提案されました。







外部システムが要求を生成してSAP HCMに送信し、そこでこの要求がデータの完全性とテーブルへのアクセス許可についてチェックされます。チェックが成功すると、SAP HCMは、必要なデータを収集してFuse統合ソリューションに転送するプログラムを実行します。 Fuseは、Kafkaで必要なトピックを定義し、そこにデータを渡します。次に、カフカからのデータがステージエリアGPに転送されます。



このチェーンの私たちは、SAPHCMからデータを抽出する問題に関心を持っています。もっと詳しく見ていきましょう。



SAPHCM-FUSE相互作用図。







外部システムは、SAPへの最後の成功した要求の時刻を決定します。

このプロセスは、タイマーまたはその他のイベントによって開始できます。これには、SAPからのデータによる応答を待機するためのタイムアウトや、繰り返される要求の開始が含まれます。次に、デルタリクエストを生成し、SAPに送信します。



リクエストデータは、json形式で本文として渡されます。

http：POSTメソッド。

サンプルリクエスト：







SAPサービスは、リクエストの完全性、現在のSAP構造への準拠、およびリクエストされたテーブルにアクセスするためのアクセス許可の可用性をチェックします。



エラーが発生した場合、サービスは適切なコードと説明を含む応答を返します。コントロールが成功すると、選択を生成するためのバックグラウンドプロセスが作成され、一意のセッションIDが生成されて同期的に返されます。



エラーが発生した場合、外部システムがログに記録します。応答が成功した場合は、セッションIDと要求が行われたテーブルの名前が送信されます。



外部システムは、現在のセッションをオープンとして登録します。このテーブルに他のセッションがある場合は、警告がログに記録されて閉じられます。



SAPバックグラウンドジョブは、指定されたパラメータと指定されたサイズのデータ​​パケットに従ってカーソルを生成します。パケットサイズ-プロセスがデータベースから読み取るレコードの最大数。デフォルトでは、2000と想定されます。使用されたパケットサイズよりも多くのレコードがデータベースサンプルにある場合、最初のパケットが送信された後、対応するオフセットと増分パケット番号で次のブロックが形成されます。番号は1ずつ増加し、厳密に順番に送信されます。



次に、SAPはパケットを入力として外部システムWebサービスに渡します。そして、それは着信パケットを制御するシステムです。受信したIDのセッションはシステムに登録されており、オープン状態である必要があります。パッケージ番号が1より大きい場合、システムは前のパッケージ（package_id-1）の正常な受信を記録する必要があります。



制御が成功した場合、外部システムはテーブルデータを解析して保存します。



さらに、最終フラグがパッケージに存在し、シリアル化が成功した場合、統合モジュールはセッション処理が正常に完了したことを通知され、モジュールはセッションステータスを更新します。



制御/解析エラーが発生した場合、エラーはログに記録され、このセッションのパケットは外部システムによって拒否されます。



同様に、逆の場合、外部システムがエラーを返すと、ログに記録され、パケットの送信が停止されます。



SAPHM側でデータを要求するための統合サービスが実装されました。このサービスは、ICFフレームワーク（SAPインターネット通信フレームワーク-help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html）に実装されています。これにより、特定のテーブルでSAPHCMシステムからデータを照会できます。データ要求を作成するときに、必要なデータを取得するために、特定のフィールドとフィルタリングパラメータのリストを指定することができます。同時に、サービスの実装はビジネスロジックを意味するものではありません。デルタ、要求パラメータ、整合性制御などを計算するためのアルゴリズムも、外部システム側に実装されています。



このメカニズムにより、必要なすべてのデータを数時間で収集して転送できます。この速度は許容範囲内であるため、このソリューションは一時的なものと見なされ、プロジェクトでの抽出ツールの必要性をカバーすることができました。

データ抽出の問題を解決するためのターゲット画像では、Oracle GoldenGateなどのCDCシステムまたはSAPDSなどのETLツールを使用するためのオプションが検討されています。