質問の歴史

SAP S/4HANAの実装は、従来のSAP GUIトランザクションをSAPUI5アプリケーションに置き換え、中心的なユーザーインターフェースとしてFioriランチパッドに大きく依存しています。これらのアプリケーションは、往々にしてレガシーRFC（リモートファンクションコール）ファンクションモジュールをラップするODataサービスを介してデータを取得します。デプロイメントアーキテクチャは、フロントエンドのBSP（ビジネスサーバーページ）アプリケーション、ODataを公開するSAP Gateway層、バックエンドのABAPスタック、およびPFCG（プロファイルジェネレーター）認証プロファイルの複数のレイヤーを含みます。

ランドスケーププロモーション（開発 → 品質保証 → 本番）中には、通常、コードの欠陥からではなく、構成のドリフトから不整合が発生します。ODataサービスは、IWBEPコンポーネント内でメタデータを積極的にキャッシュし、PFCGロールは新しい認可オブジェクトを伝播するために手動で再生成する必要があります（プロファイル → 生成）。この質問は、テスターがn層アーキテクチャをナビゲートし、フロントエンドキャッシュ、ゲートウェイメタデータ、トランスポートシーケンシング、または認証バッファの遅延によってタイルが欠落しているかどうかを体系的に特定する能力をテストします。

問題

核心的な課題は症状の曖昧性です：ユーザーがFioriランチパッドにログインすると、グレーアウトされたタイルが表示されるか、タイルが完全に欠落しているか、クリックすると「アプリを開くことができませんでした。後でもう一度お試しください。」というメッセージが表示されます。これらの症状は以下から引き起こされる可能性があります：

ODataメタデータの古さ：SAPUI5アプリがエンティティ構造を理解するために$metadataを取得します。ゲートウェイキャッシュ（/IWFND/CACHE）がトランスポート後に古いバージョンを保持している場合、アプリはバックエンドで変更されたRFCフィールドにバインドできないことがあります。
PFCGロールの伝播遅延：トランスポートリクエストがQASにロールを成功裏に移動させた場合でも、ユーザーマスタ（USR04）テーブルは、新しいプロファイルバージョンが比較を実行するまで（PFUD）またはユーザーが再度ログインするまで反映されないかもしれません。ロールがカタログをリストしているが特定のS_IWSG（インターネット通信フレームワーク）認可が欠如することがあります。
ターゲットマッピングの孤児：LPD_CUST（ランチパッドカスタマイジング）エントリまたはカタログの割り当てがセマンティックオブジェクト（例：ZPurchaseOrder）とアクション（create）を参照している場合でも、トランスポートがグループの割り当てを逃したり、manifest.json内のSAPUI5コンポーネントIDがBSPアプリケーション名と一致しない場合、タイルはレンダリングされますが、どこにも移動しません。

体系的なアプローチなしでは、テスターはSE80コードを確認するのに何時間も浪費することになるでしょうが、問題はSM59のシステムエイリアスの欠落や、フラッシュされていないSU56認証バッファにあるかもしれません。

解決策

静的構成から動的実行時にかけて作業を行うレイヤード排除プロトコルが必要です：

ステップ1：トランスポート整合性監査 機能テストを行う前に、SE01およびSE09を使用してトランスポートコピー（TOC）またはワークベンチリクエストの内容を確認します。相互依存性を確認します：BSPアプリケーション、ICFノード（トランザクションSICF）、ODataサービス（/IWFND/MAINT_SERVICE）、Fiori カタログ/グループの割り当て（/UI2/FLPD_CUST）、およびPFCGロールは同じトランスポート内にあるか、文書化されたシーケンシングを持つ必要があります。SCMP（ビュー/テーブル比較）を使用して、システム間のLPD_T（ランチパッドデータ）テーブルの差分をチェックします。

ステップ2：メタデータキャッシュの無効化 ゲートウェイシステムで/IWFND/CACHE_CLEANUPを実行し、モデルおよびメタデータキャッシュをクリアします。ブラウザでハードリロードを強制し（Ctrl+F5）、?sap-ui-xx-noCache=trueをSAPUI5ブートストラップURLに追加します。ネットワークタブで$metadataリクエストをチェックし、XMLレスポンスに現在のRFCシグネチャに一致する正しいEntitySetsが含まれていることを確認します。

ステップ3：認証バッファのフラッシュ トランザクションSU56を使用して現在のユーザーの認証バッファを削除します。PFUD（ユーザーマスタデータ調整）を「比較」オプションで実行し、PFCGロールのプロファイルが最新であることを確認します。失敗したタイルアクセスの直後にSU53を実行し、最後の失敗した認証チェックを表示します。特にS_START（一般的なスタート認可）、S_IWSGおよびS_SERVICEオブジェクトを確認します。

ステップ4：ターゲットマッピング解決確認 トランザクション/UI2/FLIA（Fioriランチパッドインテント分析）を使用して、セマンティックオブジェクトとアクションを入力します。これにより、どのSAPUI5アプリケーション（コンポーネントID経由）が解決されているか、ICFパスがどれか、LPD_CSTエントリが有効かどうかが明らかになります。FLIAがマッピングを示しているがユーザーがそれを見ることができない場合、問題はPFCG（カタログ割り当ての欠如）です。FLIAがマッピングを表示しない場合、問題はLPD_CUSTまたはトランスポート内にあります。

ステップ5：RFC接続トレース /IWFND/ERROR_LOG経由でゲートウェイエラーログを有効にします。SM59→接続テストでRFCの宛先のトレースを実行し、次にSM50（プロセス概要）を使用して、ODataサービスがバックエンドに到達しようとする際にRFCエラーを監視します。SM21（システムログ）でS_RFCまたはS_RFCACLの認証失敗がないか確認します。

実生活からの状況

問題の説明

S/4HANA 2022のアップグレードプロジェクト中に、SAP Fiori「購入 requisitionsを管理する」アプリケーションは開発環境では完全に動作していましたが、品質保証環境では「アプリケーションを開くことができませんでした。SAPUI5コンポーネントui.sscim.prereqが読み込むことができませんでした。」というエラーで起動しませんでした。Basisチームは、すべてのトランスポートがRC=0（リターンコードゼロ）で正常にインポートされたことを確認しました。SAPUI5 ABAPリポジトリ（SE80）には、ui.sscim.prereq BSPアプリケーションがQASに存在していることが示されていました。ODataサービスC_PURCHASEREQ_SRVは/IWFND/MAINT_SERVICEでアクティブでありました。しかし、タイルは管理者には表示されましたが、調達事務員には表示されず、認可の問題が示唆されましたが、管理者もタイルをクリックすると読み込みエラーが発生しました。

ソリューション1：ブラウザキャッシュのクリアおよびUI5バージョンのロールバック

初期の仮説は、QASに破損したSAPUI5キャッシュまたはABAPリポジトリにおけるバージョンの不一致があることでした。チームはすべてのユーザーのブラウザキャッシュをクリアし、/UI5/APP_INDEX_CALCULATEを使用してMIMEリポジトリキャッシュを手動で無効にしました。

長所： これは迅速で侵襲的でない修正方法であり、通常はSAPUI5リソースの読み込み問題（Component-preload.jsの404）を解決します。ABAPコードの変更は必要ありません。

短所： 問題は解決しませんでした。エラーはPersistし、より重要なことに、タイルが事務員に見えなかった理由を説明しませんでした。これは、症状（読み込みエラー）を処理したが、メタデータが読み込まれなくなっている理由を診断せず、潜在的には深刻なODataサービスの構成問題を隠していました。

ソリューション2：全PFCGロールの再生成とユーザー比較

チームは、Fiori カタログの割り当てがPFCGに欠けていると疑いました。彼らは調達ロールのすべてのプロファイルを再生成し、すべてのユーザーが更新された認可を受けられるように「完全な照合」オプションでPFUDを実行しました。

長所： 認可プロファイル（UST04のPROF_NAME）がロール定義と同期されることを保証します。これにより、QASロールバージョンにカタロググループの割り当てが不足していたため、事務員の「目に見えないタイル」問題が解決されました。

短所： タイルが表示されるようになったが、クリックしても未だに「コンポーネントを読み込むことができませんでした」というエラーが発生しました。このアプローチは認可レイヤー（PFCG）のみに焦点を当て、ODataサービスからRFCへのマッピングレイヤーを無視しました。タイルが表示される管理者も、それを開けないことが証明されたため、問題は認可に留まるものではありませんでした。

ソリューション3：体系的なゲートウェイおよびICFノードの検証（選択したアプローチ）

選択した方法論は、SAPUI5アプリとは独立してODataサービスのアクティベーション状態をチェックすることを含んでいました。トランザクション/IWFND/GW_CLIENTを使用して、C_PURCHASEREQ_SRV?sap-client=100へのGETリクエストを実行しました。リクエストはHTTP 200を返しましたが、XMLペイロードは、メタデータが最近のRFCインターフェース変更の前のキャッシュされたバージョンからのものであることを示しました。その後、トランザクションSICF（サービスの維持）をチェックすると、ICFノード/sap/bc/ui5_ui5/sap/ui_sscim_prereqはDEVでアクティブでしたが、QASでは非アクティブでした（インポートはロックされたオブジェクトのために静かに失敗していました）。最後に**/IWFND/ERROR_LOGをチェックすると、アプリが$metadataを取得しようとしたときに、更新を受け取っていないシステムエイリアスのマッピングにおける認可エラーが表示され、移行後に廃止された古いSM59**宛先を指していることがわかりました。

選択理由： このアプローチは、次の三重の同時失敗を孤立させました：（1）DEVとQAS間のODataキャッシュの非同期によりメタデータの不一致が発生、（2）非アクティブなICFノードがSAPUI5リソースをHTTP経由で提供できなくなります、（3）QASのシステムエイリアスの誤設定が、存在しないRFC宛先を指しています。これにより、一般的なユーザー向けメッセージとは異なる特定のエラーコード（ICF 403s対OData 404s）が提供されました。

結果

/IWFND/CACHE_CLEANUPを実行すると、ODataメタデータが新しいRFCシグネチャに一致するように更新されました。SICFを通じてICFノードをアクティブ化することで、「コンポーネントを開くことができませんでした」というエラーが解決され、BSPアプリケーションのHTMLおよびJSファイルがアクセス可能になりました。/IWFND/MAINT_SERVICE→SAPシステムエイリアスのシステムエイリアスの訂正により、ゲートウェイがバックエンドに到達できるようになりました。調達事務員は、PFCGロール（ソリューション2で修正されました）が今機能しているタイルへのアクセスを許可しているため、アプリケーションを確認し開くことができるようになりました。この体系的アプローチにより、コードが欠陥であるという仮定のもとで浪費される約8時間のABAPデバッグを節約できました。

候補者が見落としがちなこと

見えないFioriタイルが、欠落したターゲットマッピング（LPD_CUST）によるものか、PFCGにおけるカタログ割り当ての欠落によるものかをどのように確実に判断しますか？両者はタイルが表示されない結果をもたらしますが。

回答：

欠落したターゲットマッピング（LPD_CUSTまたはFiori カタログデザイナーで構成）は、セマンティックオブジェクトとアクションの組み合わせに関連するSAPUI5アプリケーションがないことを意味しますが、タイル自体はPFCGにカタログ割り当てが存在する場合、でもまだ表示される可能性があります。クリックすると「ナビゲーションターゲットが見つかりませんでした」というエラーが発生します。確認するためにトランザクション/UI2/FLIA（Fioriランチパッドインテント分析）を使用します。セマンティックオブジェクトとアクションを入力します。FLIAが「このインテント用のアプリケーションが見つかりません」と返す場合、ターゲットマッピングが欠落しているか、マッピング内のBSPアプリケーション名が間違っています。

逆に、FLIAがターゲットSAPUI5アプリケーションとコンポーネントIDを正常に表示するが、タイルがユーザーのランチパッドに欠けている場合、問題はPFCGに関連しています。タイルを含むカタログがユーザーのロールにPFCGで割り当てられているかを確認（メニュータブをチェック）し、また、タイルをホームページで整理するグループも割り当てられていることを確認します。さらに、ユーザーのSU53トレースに必要な認可オブジェクトS_STARTの値がWEBGUIであることを確認します。これは、任意のFioriアプリを起動するために必要であり、しばしばSAP GUIのみのシステムからのロールのアップグレードで見逃されることが多いです。

なぜ、ODataサービスがゲートウェイクライアント（/IWFND/GW_CLIENT）では正常にテストされるのに、ブラウザで呼び出すと403 Forbiddenエラーになりますか？

回答：

ゲートウェイクライアント（/IWFND/GW_CLIENT）はSAP GUIセッションコンテキスト内で実行され、SAPログオン認証を利用してHTTP インターネット通信フレームワーク（ICF）ノードのセキュリティチェックをバイパスします。しかし、SAPUI5アプリケーションはICFノード構造（/sap/bc/ui5_ui5/...または/sap/opu/odata/...）を介してリクエストをルーティングします。

したがって、ブラウザでの403は通常次のことを示します：

ICFノードの非アクティブ状態：特定のサービスノードがターゲットクライアント内でSICFで非アクティブであり、ODataサービス自体は/IWFND/MAINT_SERVICEに登録されています。
S_ICF認可：ユーザーが特定のHTTPパスにアクセスするための正しいICFフィールド値（サービス名、ホストなど）を持つS_ICF認可オブジェクトを欠いています。失敗の直後にトランザクションSU53をチェックします。
CSRFトークンバリデーション：SAPUI5アプリケーションは、HEADリクエストを介して取得された有効なCSRF（クロスサイトリクエストフォージェリ）トークンを必要とします。フロントエンドとバックエンドシステムが誤って設定されている場合（例：Fioriフロントエンドサーバーシナリオで異なるシステムID）、トークンの検証が失敗し、403が発生しますが、GW_CLIENT（ステートレスでCSRF非依存）は成功します。

複数のトランスポートリクエストを同時にインポート中に、PFCGロールの更新でレースコンディションをテストする方法は？

回答：

複数のトランスポートリクエストが同時にPFCGロールを含む場合、プロファイル生成（PFCG → プロファイル生成）は、USR10またはUSR12上のテーブルロック競合を引き起こし、一部のユーザーが部分的なロール更新を受け取る不完全な認証バッファを作成する可能性があります。これをテストする方法は以下の通りです：

段階的インポートシミュレーション：QAS環境で、ロールトランスポートを同時にインポートするのではなく、順次インポートします。リターンコード（ターゲットRC=0またはRC=4警告）を記録します。その後、システムをリセットし、同時にこれらをインポートします。UST04のユーザーマスタレコードの違いを比較します。
認証トレース比較：同じユーザーに対して、同時インポートの前後でST01（認証トレース）を使用します。認証チェックバッファをキャプチャします。順次インポートでZ_CUSTOM_AUTH_OBJECTの成功したチェックが表示されますが、同時インポートで失敗が表示される場合は、プロファイル生成のレースコンディションが発生している可能性があります。
PFUDレイテンシテスト：同時インポートの直後に、SUIM→ユーザー→複雑な選択基準によるを実行し、プロファイルバージョン（USR10のPROFN）がPFCGのロールバージョンと一致するかどうかを確認します。一致しない場合、ユーザーマスタの調整（PFUD）がスキップされたか、静かに失敗した可能性があります。解決策は、サインオフ前にRSUSR200（ユーザー-ロール割り当ての分析）検証を含む必須のPFUD実行を強制することです。