SAP BW/4HANAのデータ抽出基礎：データソースからADSOまでの設計と運用

SAP BW/4HANAでデータ抽出を設計するときは、単にデータを取得するだけでなく、抽出元、抽出方式、変換、保存先、実行単位、再実行方法までを一つのデータフローとして整理します。特に本番運用では、初回ロードとデルタロードの違い、抽出失敗時の再処理範囲、データの重複や欠損を確認できる仕組みが重要です。

この記事では、SAP ERPやその他の業務システムからSAP BW/4HANAへデータを取り込む一般的な流れを、実装と運用の観点から説明します。抽出元の種類によって利用できる仕組みや確認項目は変わるため、対象システムの標準抽出機能、データ量、更新頻度、業務上の締め時刻を先に整理してください。

01SAP BW/4HANAのデータ抽出全体像

データ抽出の基本的な流れは、抽出元の準備、データ取得、必要な変換、保存、検証、後続処理です。SAP BW/4HANAでは、抽出元から直接レポートへ渡すのではなく、データを管理しやすい中間層や永続化層に格納してから、分析用途に合わせて利用する構成が一般的です。

業務システム
    ↓ 抽出元・接続・抽出設定
データ取得
    ↓ Transformation
ADSO
    ↓ CompositeProvider
分析・クエリ利用

抽出処理を設計する最初の単位は、業務上意味のあるデータセットです。たとえば売上明細、購買伝票、品目マスタ、得意先マスタを一つの抽出として扱うのではなく、更新タイミングとキー、デルタ方式が同じ単位で分けます。これにより、障害発生時に対象範囲を限定しやすくなります。

データフローの全体像や主要オブジェクトの関係を先に確認する場合は、SAP BW/4HANAの概要も参照してください。

02抽出元とデータソースを確認する

最初に確認するのは、抽出したいデータがどのシステムに存在し、どのインターフェースで取得できるかです。SAP ERP系の標準データを扱う場合は、標準のデータソースが提供する項目、選択条件、更新方式、デルタキューや変更履歴の仕組みを確認します。

確認項目は次のとおりです。

• データソースが対象業務の明細またはマスタを正しく表しているか
• キー項目が一意性を保っているか
• 初回フルロードに必要なデータ量と期間
• デルタ抽出で検知できる新規、変更、削除の範囲
• 抽出元のタイムゾーンと日付・時刻の扱い
• 抽出実行中に業務更新が行われた場合の整合性
• 接続ユーザーに必要な権限が付与されているか

標準データソースで不足する項目がある場合は、抽出元側で拡張するか、別の取得方法を検討します。抽出元のデータ構造を直接参照して取得する設計では、アプリケーションの業務ロジックや更新処理を十分に確認してください。データソースの項目定義は、SAP BW/4HANAのInfoObjectsで管理する特性やキー数値との対応も考慮して決めます。

抽出元の確認では、画面上の項目名だけでなく、技術項目名、データ型、長さ、通貨、単位、言語依存性を記録します。後工程で型変換や単位変換を行う場合、その責任範囲をデータフロー設計書に明記すると、運用時の調査が短縮されます。

03抽出方式を選択する

SAP BW/4HANAの抽出方式は、主にフルロードとデルタロードに分けて考えます。フルロードは対象範囲を毎回読み直す方式で、初回ロードや小規模マスタに適しています。デルタロードは前回取得以降の変更分を取得する方式で、日次や時間単位の更新に向いています。

フルロードを採用する場合は、選択条件を固定しすぎないことが重要です。期間条件を誤ると過去データが欠落し、抽出元の全件取得では処理時間や負荷が大きくなります。対象期間、除外条件、データ件数の見込みを実測してから実行時間帯を決めます。

デルタロードでは、抽出元が変更をどのように保持しているかを確認します。更新日時を使う方式では、境界時刻の重複や取りこぼしを防ぐため、前回終了時刻の扱いを決めます。変更ポインタやキューを使う方式では、正常終了後にポインタが進むタイミングと、失敗時に再処理できる範囲を確認します。

方式を選ぶ際は、次の基準を使うと判断しやすくなります。

04ADSOを中心にデータを保存する

取得したデータの保存先には、用途に合ったAdvanced DataStore Object（ADSO）を選びます。ADSOは、抽出データを保持し、変換や後続処理の起点として利用できる重要なオブジェクトです。データの粒度、キー、更新方式、履歴保持の要件を決めてから設計します。

ADSO設計では、まず一行が何を表すかを定義します。売上明細であれば、伝票番号、明細番号、品目、数量、金額、計上日などの粒度を明確にし、同じキーで複数行が到着した場合の扱いを決めます。マスタデータでは、有効期間や変更履歴を保持するかどうかも設計対象です。

ADSOのデータモデル、ステージング、更新処理を詳しく確認する場合は、SAP BW/4HANAのADSO設計を参照してください。

実装時には、抽出元項目とADSO項目の対応表を作成します。次の項目を含めると、ロード失敗や値の不整合を調査しやすくなります。

• 抽出元の技術項目名
• ADSO側の項目名とデータ型
• InfoObjectへの割り当て
• 変換ルールと単位・通貨変換
• NULL、空文字、初期値の扱い
• キー項目と重複時の処理
• エラー行の記録方法

05Transformationでデータを整形する

抽出元のデータをそのまま保存できない場合は、Transformationで項目マッピング、型変換、計算、コード変換、参照処理を定義します。Transformationは、データの意味を変える処理と、表記を統一する処理を分けて設計すると保守しやすくなります。

たとえば、抽出元の商品コードをInfoObjectへ割り当てる処理と、数量に単位換算を適用する処理は別のルールとして記録します。複雑な条件を一つのルーチンに集約すると、データ不整合の原因を特定しにくくなるため、業務ルール単位で分割します。

Transformationのマッピング、ルーチン、エラー処理を確認する場合は、SAP BW/4HANAのTransformationを参照してください。

変換後の検証では、件数だけでなく金額、数量、キーの分布を確認します。件数が一致していても、通貨や符号、日付の変換に誤りがあれば分析結果は正しくなりません。代表的な伝票や境界日、空値を含むデータをテストケースとして用意します。

06初回ロードとデルタロードを実行する

本番ロードの前に、少量のテストデータで接続、権限、マッピング、変換、保存結果を確認します。テストが完了したら、初回ロードの対象期間を決め、抽出元の業務更新と重ならない時間帯に実行します。

初回ロードでは、次の順序で進めると原因を切り分けやすくなります。

1. 抽出元と接続の疎通を確認する
2. 少量の選択条件でデータを取得する
3. Transformationの結果を確認する
4. ADSOへロードして件数と代表値を検証する
5. 対象期間を広げて本ロードを実行する
6. 初回ロード完了後のデルタ開始位置を確認する

デルタロードへ切り替えるときは、初回ロードの終了時点とデルタの開始時点を明確にします。切り替えの境界が曖昧だと、同じレコードの重複や、初回ロード後に発生した変更の欠落が起こります。切り替え直後は、抽出元とADSOの件数や集計値を比較し、複数回のデルタ実行で安定することを確認します。

ロード処理は、データ取得、変換、ADSO更新、後続処理に分けて監視します。全体が失敗したという表示だけで判断せず、どの段階で停止したか、エラー行があるか、抽出元のポインタが進んだかを確認してください。

07CompositeProviderで利用モデルを組み立てる

ADSOに保存したデータを複数の領域やデータソースと組み合わせる場合は、CompositeProviderで利用モデルを設計します。抽出処理と分析用の結合処理を分けることで、取得処理の再実行と分析モデルの変更を独立して管理できます。

CompositeProviderでは、結合キー、共通の特性、重複するキー数値、参照元の粒度を確認します。異なる粒度のデータを結合すると、金額や数量が重複して集計されることがあるため、明細とヘッダ、実績と計画、トランザクションとマスタを同じ粒度として扱わないようにします。

複数のADSOやプロバイダーを組み合わせる方法は、SAP BW/4HANAのCompositeProviderで整理しています。データ抽出側のキー設計と、CompositeProvider側の結合条件を同じ設計書で管理すると、後工程の集計誤りを見つけやすくなります。

08抽出処理を監視する

運用では、ロードの成功・失敗だけでなく、処理時間、件数、エラー件数、デルタの遅延、抽出元の負荷を継続的に確認します。通常値を把握しておけば、処理が成功していても件数が急減したケースを検知できます。

最低限、次の監視項目を記録します。

• 実行開始時刻と終了時刻
• 抽出対象期間またはデルタ位置
• 取得件数、更新件数、エラー件数
• ADSOへの書き込み件数
• 前回実行との差分
• 後続処理の開始・終了状態
• 抽出元とBW/4HANA側の業務日付

処理チェーンを利用する場合は、依存関係を明確にします。前段のロードが完了する前に後段の集計や公開処理を開始すると、未完成のデータが利用者へ公開されます。失敗時には自動再実行の回数と、再実行前に確認する条件を定義します。

09よくある障害を切り分ける

データが取得できない場合は、最初に接続先、接続ユーザー、権限、抽出元の稼働状態を確認します。接続が正常でもデータが0件の場合は、選択条件、対象期間、組織条件、デルタ位置を確認します。

ロード件数が想定より少ない場合は、抽出元の件数、取得結果、Transformation後の件数、ADSO書き込み件数を段階的に比較します。抽出元の時点で少なければ抽出条件やデルタ管理を調べ、Transformation後に減っていればフィルタやルーチンを調べます。ADSOだけが少なければ、キー重複や更新方式を確認します。

重複が発生した場合は、同じデータをフルロードとデルタロードで重ねていないか、デルタの境界時刻が重複していないか、ADSOのキーが業務上の一意キーを表しているかを確認します。金額が過大になる場合は、CompositeProviderで異なる粒度のデータを結合していないかも調べます。

エラー行が発生した場合は、エラー内容、元データ、変換前後の値、対象キーを記録します。エラー行だけを修正して再処理できる設計にすると、全件ロードを繰り返す必要がなくなります。修正後は件数だけでなく、業務上の合計値とサンプル明細を確認します。

10本番運用前のチェックリスト

本番切り替え前には、技術設定と業務検証を分けて確認します。次の項目を完了条件として記録してください。

• 抽出元、接続、権限の確認が完了している
• 初回ロードの対象期間と実行時間帯が決まっている
• デルタ開始位置と再実行手順が記録されている
• InfoObject、ADSO、Transformationの対応表が承認されている
• エラー行と重複データの扱いが決まっている
• 件数、金額、数量、日付の検証結果が保存されている
• CompositeProviderの結合条件と粒度が確認されている
• 処理チェーンの依存関係と通知先が決まっている
• 障害時の停止、修正、再処理、業務確認の担当者が決まっている

本番稼働後は、初回数回の実行を重点監視し、通常の処理時間と件数を基準値として記録します。基準値から外れた場合に調査を開始できるよう、許容範囲と連絡手順も運用文書に追加します。