SAP BW/4HANA

SAP BW/4HANAの権限管理:分析権限の設計とトラブルシューティング

SAP BW/4HANAで分析権限を設計・割り当て・検証する実務手順を解説します。InfoObject、ADSO、CompositeProvider、クエリをまたぐ権限設計、RSECADMINとPFCGの使い分け、権限エラーの切り分けを整理します。

SAP BW/4HANA権限管理の全体フローロール、分析権限、データモデル、クエリ検証の関係を示すSAP BW/4HANA権限管理の全体フローロール、分析権限、データモデル、クエリ検証の関係を示す範囲を権限へ反映値を定義組み合わせて割り当てデータへ適用クエリを実行調整して再検証業務上のデータ境界誰がどの組織・分析値を参照…PFCGロール技術的なアクセス権とBW…RSECADMIN分析権限許可する特性値と組み合わ…Providerとクエリモデル権限対象特性がモデル内で…ユーザー検証代表ユーザーで許可、拒否…CertPas オリジナル図解
業務上のデータ境界からPFCGロール、RSECADMIN分析権限、Providerとクエリモデル、ユーザー検証へ進む権限管理フロー
目次
  1. 権限管理の全体像
  2. 分析権限を設計する
  3. PFCGとRSECADMINの役割を分ける
  4. データモデルと権限の接点
  5. クエリ実行時の検証
  6. 権限エラーを切り分ける
  7. 変更を安全に運用する
  8. 運用チェックリスト

SAP BW/4HANAの権限管理では、ユーザーがレポートを実行できるかだけでなく、どのデータを参照できるかを分けて設計します。特に、クエリの実行権限とデータの絞り込みを同じものとして扱うと、開発環境では動くのに本番ユーザーでは結果が空になる、または広すぎるデータが表示されるといった問題が起きます。

実務では、組織や地域などの分析軸を基準に対象範囲を定義し、PFCGでロールを割り当て、RSECADMINで分析権限を保守します。変更後は対象ユーザーでクエリを実行し、権限値とデータ結果の両方を確認してください。

権限管理の全体像

BW/4HANAのアクセス制御は、複数の層に分けて確認すると整理しやすくなります。

  1. ユーザーとロール:ユーザーにPFCGロールを割り当てます。
  2. BWオブジェクトへのアクセス:クエリ、CompositeProvider、ADSOなどを操作・実行する権限を管理します。
  3. 分析権限:特定の特性値や組み合わせに対して、参照可能なデータ範囲を制限します。
  4. フロントエンド接続:使用する分析クライアントや接続ユーザーが、バックエンドの権限を正しく利用できる状態にします。

SAP BW/4HANAの概要を先に確認すると、データウェアハウスの各オブジェクトと権限の関係を把握しやすくなります。

権限設計では、まず「誰が」「どのレポートを」「どの条件のデータまで」参照するかを表にします。部門、販売組織、会社コード、地域、製品など、利用者の業務責任に対応する項目を候補にし、不要な項目まで権限条件へ含めないことが重要です。

BW/4HANA権限エラーの切り分けクエリで発生する代表的な症状と最初に確認する場所を対応付けるBW/4HANA権限エラーの切り分けクエリで発生する代表的な症状と最初に確認する場所を対応付ける起動できない場合結果が空または広い場合特定値が欠落する場合アクセス変更後権限変更後モデル確認後発生した症状起動不可、結果が空、範囲…PFCGアクセスを確認ユーザー、ロール割り当て、…分析権限を確特性値、組み合わせ、重複…Providerマッピングを…CompositeProvider、ADSO…代表ユーザーで再検証許可値と未許可値で同じク…CertPas オリジナル図解
BW/4HANAのクエリ症状をPFCG、分析権限、Providerマッピング、再検証へ結び付けるトラブルシューティングフロー

分析権限を設計する

分析権限は、レポート利用者に見せるデータ範囲を定義するための仕組みです。設計時には、クエリで使われる特性だけでなく、データがどのProviderから供給されるかも確認します。

権限項目を決める

最初に、業務上の責任範囲を表す特性を選びます。たとえば、営業担当者には販売組織と地域、経理担当者には会社コード、購買担当者には購買組織を割り当てるというように、組織構造とレポート要件を対応させます。

InfoObjectがマスターデータや特性値の基盤になる場合は、InfoObjectの設計と利用方法を参照し、権限で使う特性の意味、値の粒度、マスターデータの状態を確認します。

権限の粒度を決める

権限値は、できるだけ業務ロールに対応する粒度で管理します。個人ごとに値を直接登録すると、異動や組織変更のたびに保守量が増えます。部門や地域などのグループ単位でロールを分け、同じ権限範囲を共有できる構造にすると運用が安定します。

複数の特性を組み合わせる場合は、意図した組み合わせだけが許可されるかを確認します。会社コードAと地域Xを許可したつもりが、会社コードAの全地域を許可する構造になっていないかを、代表的なデータで検証してください。

PFCGとRSECADMINの役割を分ける

PFCGはユーザー、ロール、権限オブジェクトを管理するために使用します。一方、RSECADMINは分析権限の作成、変更、割り当て、検証を行う中心的な画面です。両者を混同せず、技術的なアクセスとデータ範囲を分けて管理します。

PFCGで確認する項目

PFCGでは、対象ユーザーに適切なロールが割り当てられているかを確認します。次のような観点で確認すると、アクセスエラーの切り分けが速くなります。

  • ユーザーが有効期間内である
  • ロールがユーザーへ割り当てられている
  • 生成済みのユーザーマスタが最新である
  • BWオブジェクトへの実行・表示権限が含まれている
  • 接続方式に応じたフロントエンド関連の権限がある

ロール変更後は、ユーザーセッションを再ログオンして新しい権限を読み込ませます。長時間保持されたセッションでは、変更前の状態が残ることがあります。

RSECADMINで確認する項目

RSECADMINでは、分析権限の特性値、許可範囲、割り当て対象を確認します。権限を変更した後は、対象ユーザーが実際に参照するクエリで、許可された値と許可されていない値の両方を試します。

分析権限が複数存在する場合は、どの権限がユーザーに適用されるかを追跡します。広い範囲を許可する権限が別に割り当てられていると、狭い権限を追加しても期待した制限になりません。

データモデルと権限の接点

権限の動作は、データモデルの構造に依存します。クエリに表示される特性が、基礎となるProviderでどのようにマッピングされているかを確認してください。

ADSOを利用する場合は、ADSOのデータ構造と運用を確認し、権限判定に使う特性が必要なデータ層まで保持されているかを調べます。変換処理で値が置換される場合、権限に登録した値と実データの値が一致しないことがあります。

複数のProviderを統合する場合は、CompositeProviderの設計を確認します。Providerごとに特性の意味や値の保持状況が異なると、同じ名前の項目でも権限判定の結果が一致しないことがあります。

権限に使う特性の確認手順

  1. クエリのフィルター、行、列に使われる特性を一覧化する。
  2. CompositeProviderで、その特性がどのProviderから供給されるかを確認する。
  3. ADSOや基礎Providerに、権限判定対象の値が存在するかを確認する。
  4. 変換やマスターデータ処理で値の形式が変わっていないかを確認する。
  5. 代表ユーザーで、許可値と未許可値の結果を比較する。

特性がクエリに表示されていても、権限判定に適切な粒度で利用できるとは限りません。技術名、業務上の意味、値の生成元を記録しておくと、モデル変更後の影響を追跡できます。

クエリ実行時の検証

権限変更後の検証では、単にクエリが起動するかだけを見ません。クエリの起動、データ取得、許可範囲、集計結果を順番に確認します。

クエリの基本的な実行と確認方法を使い、まず管理者またはテスト用の広い権限を持つユーザーで基準結果を取得します。その後、制限対象のユーザーで同じ選択条件を実行し、結果が期待した範囲に絞られているかを比較します。

検証用ユーザーを分ける

検証では、次のようなユーザーを用意すると原因を切り分けやすくなります。

  • 基準結果を取得する管理用ユーザー
  • すべての対象値の一部を許可する業務ユーザー
  • 対象値を持たない業務ユーザー
  • クエリ実行権限を持たないテストユーザー

同じユーザーでロールと分析権限を何度も変更すると、どの変更が結果に影響したか分かりにくくなります。テストごとに変更内容、実行時刻、選択条件、期待結果、実結果を記録してください。

権限エラーを切り分ける

エラーの症状を、起動不可、実行不可、結果が空、結果が広すぎる、特定の値だけ欠落するという単位に分けます。症状ごとに確認対象が異なります。

クエリを起動できない

クエリを開けない場合は、ユーザーのロール割り当てとBWオブジェクトへのアクセス権を確認します。分析権限だけを調べても、クエリやProviderの実行権限が不足していれば起動できません。

クエリは起動するが結果が空になる

結果が空の場合は、分析権限の特性値と選択条件を比較します。ユーザーが選択した値が許可範囲に含まれているか、Providerにその値のデータがあるか、変換後の値が権限登録値と一致しているかを順番に確認します。

結果が広すぎる

想定より多くのデータが表示される場合は、ユーザーに割り当てられた分析権限を一覧化し、広い範囲を許可する権限が重複していないかを確認します。ロール継承や複数ロールの組み合わせも確認対象に含めます。

一部の特性値だけ欠落する

特定の値だけ表示されない場合は、値の表記、キー、マスターデータの状態、Provider間のマッピングを比較します。表示テキストが同じでも、内部的な値やキーが異なると権限判定で別の値として扱われます。

変更を安全に運用する

権限変更は、データモデル変更や組織変更と同じ変更管理の流れで扱います。申請内容には、対象ユーザーまたはロール、追加・削除する値、適用期間、影響するクエリ、検証担当者を記載します。

本番変更の前に、代表的な利用者の業務シナリオをテストします。特に、月次締め、組織異動、担当替え、マスターデータ追加のタイミングでは、通常と異なる値の組み合わせが発生します。

権限の棚卸しでは、ユーザー単位だけでなくロール単位でも確認します。不要になったロール、退職者や異動者に残った割り当て、暫定的に追加した広い権限を定期的に整理してください。

変更後の記録には、変更前後の権限値、承認者、実施者、検証結果を残します。これにより、後日データ表示の差異が発生した際に、権限変更とモデル変更を分離して調査できます。

運用チェックリスト

  • 権限対象の業務範囲と組織構造が一致している
  • 権限に使う特性がProvider上で正しくマッピングされている
  • PFCGロールとユーザー割り当てが最新である
  • RSECADMINの分析権限に不要な広い値がない
  • 許可値と未許可値を使ったクエリ検証を実施している
  • 変更後にユーザーを再ログオンしている
  • テスト結果と承認記録を保存している

SAP BW/4HANAの権限管理は、PFCGによるアクセス制御、RSECADMINによる分析権限、Providerとクエリのデータ構造を一体で扱うと安定します。最初に業務上のデータ境界を定義し、その境界がモデル上の特性と一致していることを確認してから、ロール割り当てと検証へ進めてください。

ブログ一覧へ戻る