SAP Fioriアプリのパフォーマンス基礎：表示が遅いときの切り分けと対処

SAP Fioriアプリの表示速度は、ブラウザだけでなく、Fiori Launchpad、SAPUI5、ODataサービス、SAP Gateway、ABAPバックエンド、データベースまでの処理時間で決まります。画面が遅いときは、最初からキャッシュ削除やサーバー再起動を行うのではなく、どの区間で時間が発生しているかを測定します。

この記事では、利用者から「タイルを押しても画面が開かない」「一覧表示に時間がかかる」「検索結果が返るまで待たされる」と報告された場合の、現場向けの確認手順を整理します。対象はSAP FioriとSAPUI5で構成されたオンプレミス環境です。

01最初に確認する症状と測定範囲

まず、遅延の発生条件を記録します。対象アプリ、ユーザー、ブラウザ、発生時刻、操作手順、対象データ、初回表示だけ遅いのか、同じ操作を繰り返しても遅いのかをまとめます。ネットワークやバックエンドの調査では、この情報が再現性の判断材料になります。

同じアプリでも、初回起動、明細への遷移、フィルター実行、テーブルの追加読み込みでは通過する処理が異なります。画面全体の体感時間だけでなく、操作単位に分けて記録してください。

02ブラウザでリクエストを特定する

ブラウザの開発者ツールを開き、Networkでページを再読み込みします。Preserve logを有効にすると、Launchpadからアプリを起動するまでの通信を継続して確認できます。Name、Status、Type、Size、Time、Waterfallを使い、時間の長いリクエストを特定します。

確認対象は、HTML、JavaScript、CSS、画像、OData通信です。静的リソースの取得に時間がかかる場合は、ネットワークやキャッシュ、配信設定を調べます。ODataリクエストのWaitingが長い場合は、サーバー側の処理時間が主な調査対象になります。

リクエストを選択して、Request URL、Query String Parameters、Request Headers、Response、Timingを保存します。特に、$filter、$select、$expand、$orderby、$topの内容は、取得件数やバックエンド処理量を判断する材料です。個人情報や認証情報は記録から除外します。

ブラウザのConsoleには、JavaScript例外、UI5モジュールの読み込み失敗、ODataエラーが出ることがあります。画面が表示されても、非同期処理のエラーによってテーブルやチャートだけが遅れている場合があるため、NetworkとConsoleを同じ時刻で確認します。

03OData通信の量と応答時間を確認する

Fioriアプリの一覧表示では、ODataサービスが一度に大量のデータを返していないかを確認します。必要な項目だけを取得する$select、条件を絞る$filter、取得件数を制限する$top、ページングを利用する設計にすると、転送量とバックエンド処理を抑えられます。

$expandは関連エンティティをまとめて取得できる一方、結果件数とレスポンスサイズを大きくすることがあります。明細を開く操作で必要なデータだけを取得する構成にし、一覧表示の初期リクエストに不要な関連データを含めないようにします。

ページングを実装するときは、利用者が必要とする表示件数と、サーバーが返すページサイズを分けて考えます。ページサイズが大きすぎると初回応答が重くなり、小さすぎると追加リクエストが増えます。実際の検索条件とデータ件数で測定して値を決めます。

ODataの応答時間が長い場合、ブラウザ側で待ち時間を短く見せるためのBusy表示を追加しても、処理そのものは改善しません。まずリクエスト数、レスポンスサイズ、サーバー処理時間を測定し、その後にUIの操作性を改善します。

04UI5アプリの初期化処理を整理する

SAPUI5アプリの起動時には、コンポーネント、モデル、ルーティング、i18n、画面コントロールなどが初期化されます。起動直後に不要なデータ取得や複数のODataリクエストを実行すると、最初の画面が表示されるまでの時間が伸びます。

初期画面に必要な処理と、利用者が操作した後でよい処理を分けます。表示に不要なマスターデータは遅延取得し、タブやダイアログの内容は開いた時点で読み込みます。画面生成時に大量のコントロールを作成する構成では、表示対象を絞り、再利用できるフラグメントやモデルの設計を確認します。

リストやテーブルでは、すべての行に対して個別のリクエストを発行する実装を避けます。行ごとの追加取得が発生すると、データ量が増えた時点で通信回数が急増します。まとめて取得できるデータと、選択後に取得すべきデータを区別します。

アプリ固有の実装を変更した後は、同じ端末・同じ検索条件で変更前後を比較します。Networkのリクエスト数、最初の画面までの時間、操作後の応答時間を記録すると、改善効果を数値で確認できます。

05キャッシュを正しく扱う

Fioriでは、ブラウザキャッシュ、UI5ライブラリのキャッシュ、アプリケーションリソースのキャッシュ、ODataレスポンスの扱いを分けて考えます。キャッシュは表示を速くしますが、古いJavaScriptやメタデータが残ると、更新後に不整合が発生します。

更新直後だけ発生するエラーでは、まず対象リソースのURL、HTTPステータス、レスポンス内容を確認します。開発者ツールのDisable cacheは、開発者ツールを開いている間の検証に使えます。利用者全体のキャッシュを一律に削除する前に、対象ユーザー、対象ブラウザ、更新時刻を確認します。

ODataメタデータやアプリ設定をキャッシュする場合は、アプリの更新単位とキャッシュ無効化の手順を運用に組み込みます。デプロイ後に古いリソースが残る場合は、リソースのバージョン管理、キャッシュ制御、Launchpad側の設定を確認します。

認証情報や業務データをブラウザに長期間保持する設計は、性能だけでなくセキュリティにも影響します。キャッシュ対象、保存期間、無効化条件を明確にし、利用者の端末環境に依存した回避策を恒久対策にしないことが重要です。

06Launchpadと管理設定を切り分ける

Launchpad自体の起動が遅い場合は、タイルやターゲットマッピングの数、カタログ、ロール、テーマ、静的リソースの取得を確認します。アプリ起動後のOData遅延とは調査対象が異なるため、Launchpad表示とアプリ画面の時間を分けて測定します。

ロールやカタログの割り当てを変更した後に表示が遅くなった場合は、対象ユーザーで再現し、変更前後のネットワーク通信と表示内容を比較します。管理設定の確認手順は、SAP Fiori Launchpad管理設定ガイドにまとめています。

タイルを選択した後に誤ったアプリが起動する、ターゲットマッピングの解決に時間がかかる、またはアプリが見つからない場合は、アプリケーション起動設定を確認します。Launchpadの基本構成を確認する場合は、SAP Fioriの概要も参照できます。

07バックエンドとSAP GUI処理を比較する

同じ業務処理にSAP GUIのトランザクションとFioriアプリがある場合、処理の違いを比較すると切り分けが進みます。Fioriだけが遅い場合は、UI5初期化、OData、Gateway、ブラウザ通信を優先します。SAP GUI側でも遅い場合は、ABAP処理、データ量、データベース、ロック、権限など共通バックエンドを調査します。

比較では、同じユーザー権限、同じ会社コードやプラントなどの条件、同じ検索範囲を使います。画面の見た目や操作手順が似ていても、呼び出しているサービスや取得項目が同一とは限りません。用途に応じたFioriとGUIの選択基準は、SAP FioriとGUIトランザクションの選び方で整理しています。

バックエンド処理が原因と判断した場合は、ABAP処理時間、SQL処理、権限チェック、ロック待ち、RFCや外部連携の待ち時間を担当チームへ渡します。ブラウザの測定結果にリクエストURL、発生時刻、HTTPステータス、応答時間を添えると、担当範囲を特定しやすくなります。

08監視と再現テストを運用に組み込む

性能問題は、障害が発生した時だけ測るのではなく、リリース前後と定期運用で比較できる状態にします。代表的なアプリを選び、ログイン後の初期表示、検索、一覧表示、明細遷移、保存の時間を測定します。

測定条件には、ユーザー、ブラウザ、端末、ネットワーク、データ件数、検索条件、実行時刻を含めます。キャッシュが有効な状態と初回アクセスを分け、同じ条件で複数回実行します。平均値だけでなく、極端に遅い実行も記録します。

リリース時には、UI5アプリ、ODataサービス、バックエンドロジック、ロール、カタログ、テーマ、キャッシュ設定の変更を一覧化します。変更項目と性能指標を関連付けると、遅延が発生した時点で調査範囲を狭められます。

09症状別の初動チェックリスト

1. 対象アプリ、ユーザー、端末、ブラウザ、発生時刻、操作手順を記録する
2. ブラウザのNetworkで時間の長いリクエストを特定する
3. ConsoleのエラーとHTTPステータスを確認する
4. ODataのリクエスト数、応答時間、レスポンスサイズを確認する
5. $filter、$select、$expand、$topの内容を確認する
6. Launchpad起動時間とアプリ画面の表示時間を分ける
7. 同じ条件で別ユーザー、別ブラウザ、SAP GUIを比較する
8. バックエンド担当へ時刻とリクエスト情報を渡す
9. 改修後に同じ条件で再測定する

キャッシュ削除、ロール変更、サービス再起動は、測定結果と変更影響を確認してから実施します。特に本番環境では、利用者影響、戻し方、実施時間を記録します。

まとめ

SAP Fioriアプリの性能改善では、画面の体感だけで判断せず、ブラウザ、UI5、OData、Launchpad、バックエンドを区間ごとに測定します。最初に遅いリクエストを特定し、取得データ量と初期化処理を整理したうえで、キャッシュと管理設定を確認する流れが実務的です。測定条件を固定し、変更前後を比較することで、再発防止につながる改善を進められます。