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

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

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

特に、ソース システム (主に SAP ソリューション) からデータを取得するにはどうすればよいでしょうか?

HR Metrics は、この問題を解決する必要があった最初のプロジェクトでした。 私たちの目標は、人事データのリポジトリを作成し、従業員との連携の分野で分析レポートを構築することでした。 この場合、データの主なソースは SAP HCM トランザクション システムであり、人事、組織、給与のすべての活動がこのシステムで実行されます。

データ抽出

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

そこから XNUMX 人の従業員のデータを抽出した結果:

必要に応じて、このようなエクストラクターを独自の要件に合わせて変更したり、独自のエクストラクターを作成したりできます。

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

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

SAP HCM のデータ ストレージ構造

このようなメカニズムの要件を理解するには、まずどのようなデータが必要かを判断する必要があります。

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

物理的には、このようなツリーは 1000 つのテーブル (hrp1001 オブジェクトと hrpXNUMX オブジェクト間の接続) に格納されます。

オブジェクト「部門 1」と「オフィス 1」:

オブジェクト間の関係:

オブジェクトのタイプとそれらの間の接続のタイプの両方が膨大な数存在する可能性があります。 オブジェクト間の標準接続と、独自のニーズに合わせてカスタマイズされた接続の両方があります。 たとえば、組織単位とフルタイム職の間の標準的な B012 関係は、部門の責任者を示します。

SAP でのマネージャーの表示:

データベーステーブル内のストレージ:

従業員データは pa* テーブルに保存されます。 たとえば、従業員の人事イベントに関するデータはテーブル pa0000 に格納されます。

私たちは、GreenPlum が「生の」データを取得することを決定しました。 SAP テーブルからコピーするだけです。 そして、GreenPlum で直接処理され、物理的なオブジェクト (たとえば、部門や従業員) や指標 (たとえば、平均人数) に変換されます。

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

SAP は、かなり多くの統合メカニズムを提供しています。 ただし、最も簡単な方法は、ライセンス制限によりデータベースへの直接アクセスが禁止されていることです。 したがって、すべての統合フローはアプリケーション サーバー レベルで実装する必要があります。
次の問題は、SAP データベース内の削除されたレコードに関するデータの欠如でした。 データベース内の行を削除すると、その行は物理的に削除されます。 それらの。 変化の時間に基づいて変化デルタを形成することはできませんでした。

もちろん、SAP HCM にはデータの変更を記録するメカニズムがあります。 たとえば、その後の受信側システムへの転送のために、変更を記録する変更ポインタがあり、それに基づいて Idoc (外部システムへの転送用のオブジェクト) が形成されます。

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

または、データ変更のログを DBTABLOG テーブルに保存します。

hrp53216375 テーブルからキー QK1000 のレコードを削除するログの例:

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

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

給与クラスタ:

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

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

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

外部システムはリクエストを生成して 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 - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html）。 これにより、特定のテーブルを使用して SAP HCM システムからデータをクエリできます。 データリクエストを作成するとき、必要なデータを取得するために、特定のフィールドのリストとフィルタリングパラメータを指定できます。 同時に、サービスの実装にはビジネス ロジックは含まれません。 デルタ計算、クエリパラメータ、整合性監視などのアルゴリズムも外部システム側に実装されています。

このメカニズムにより、必要なデータをすべて数時間で収集して送信できます。 この速度は許容範囲内にあるため、このソリューションはプロジェクトでの抽出ツールの必要性を満たすことができる一時的なソリューションであると考えられます。
目標とする状況では、データ抽出の問題を解決するために、Oracle Golden Gate などの CDC システムや SAP DS などの ETL ツールを使用するオプションが検討されています。

出所： habr.com