SAP Fioriアップグレードとバージョン管理の基礎｜影響範囲と確認手順

SAP Fioriのアップグレードでは、画面の見た目だけでなく、SAPUI5のランタイム、バックエンドのアドオン、ODataサービス、ロール、カタログ、テーマ、認証設定まで確認します。変更対象を一覧化してから検証環境でアプリを起動すると、本番切り替え時の調査範囲を抑えられます。

この記事では、オンプレミス環境のSAP Fiori launchpadを対象に、バージョン情報の集め方、互換性の見方、管理者が実施するテスト、切り戻しに備えた記録方法を説明します。全体像はSAP Fioriの概要で確認できます。

01アップグレード対象を分けて把握する

SAP Fioriのバージョン管理では、次の層を個別に記録します。

• SAP S/4HANAまたは接続先バックエンドのリリース
• SAPUI5の実行ランタイムと適用済み更新
• SAP Fiori foundationや関連アドオンの状態
• SAP Fiori launchpadの設定、ページ、スペース、セクション
• ビジネスロール、カタログ、スペース、ページ、ターゲッピング
• ODataサービス、ICFノード、認証・SSO設定
• カスタムアプリ、拡張、テーマ、ブラウザ対応状況

SAP Fiori launchpadは、バックエンドの業務サービスとブラウザ側のUIランタイムを組み合わせて動作します。そのため、UI5だけを更新した場合でも、アプリの起動、データ取得、ナビゲーション、権限評価を一体で検証します。

アップグレード前には、現在の構成を基準スナップショットとして保存します。システムのリリース、UI5のバージョン、主要アプリのコンポーネント、カスタム拡張、ブラウザ、主要ロールを表形式にすると、変更後との差分を追跡しやすくなります。

02SAPUI5バージョンの互換性を確認する

SAPUI5の更新では、アプリが要求するUI5機能と、実行環境が提供する機能の組み合わせを確認します。特に次の項目をアプリ単位で記録します。

1. アプリのコンポーネント名とバージョン
2. manifest.jsonに記載された依存ライブラリ
3. 使用しているコントロール、ルーティング、モデル形式
4. カスタムコントロールと拡張ポイント
5. ブラウザの対応範囲
6. ODataメタデータとバックエンドサービスの応答

UI5の互換性は、単純な数字の大小だけで判断しません。アプリが利用するコントロール、非同期処理、ルーティング、テーマ、ブラウザAPIの組み合わせを確認します。標準アプリは対象リリースの対応情報と照合し、カスタムアプリはソースコードと実行ログを確認します。

ブラウザの開発者ツールでは、Console、Network、Applicationの各領域を使い分けます。ConsoleではJavaScriptエラーと非推奨API、Networkではリソースの404やOData応答、Applicationではキャッシュと保存済み設定を確認します。エラーの発生時刻、ユーザー、アプリ、URL、リクエストを記録すると、再現性を判断できます。

UI5バージョン変更後に古い静的リソースが残る場合は、キャッシュ管理の手順を決めてから検証します。利用者全員のブラウザキャッシュを一律に削除するのではなく、管理対象のURL、キャッシュ有効期間、必要な再読み込み方法を運用手順に記載します。

03SAP Fiori launchpadへの影響を確認する

SAP Fiori launchpadのアップグレードでは、アプリタイルが表示されることと、業務が完了することを別々に確認します。表示確認では、タイル、グループまたはページ、スペース、アイコン、説明、ターゲットマッピングを見ます。業務確認では、起動、検索、登録、変更、保存、戻る操作、ナビゲーションを実行します。

管理者は、SAP Fiori launchpad管理の初期設定を参照しながら、設定値と変更履歴を整理します。特に、サイト設定、ユーザー割り当て、デフォルトページ、通知、検索、テーマ、外部サービス連携を対象にします。

アップグレード前後で次の利用者シナリオを同じデータ条件で実行すると、影響を比較できます。

SAP GUIトランザクションとFioriアプリで同じ業務を実行する環境では、SAP FioriとGUIトランザクションの使い分けも確認対象にします。アップグレード後は、利用者が選択する入口、処理結果、権限、監査記録が業務要件に合うことを確認します。

04ロールとカタログの差分を管理する

アプリが起動しない事象では、UI5の問題と権限・ターゲット設定の問題を切り分けます。ビジネスロール、カタログ、スペース、ページ、ターゲットマッピング、ODataサービスの有効化状態を同じ変更単位で記録します。

ロール設計を更新する場合は、SAP Fioriのロールとカタログ割り当てを参照し、次の差分を確認します。

• ロールに割り当てたカタログ
• スペースとページの割り当て
• ターゲットマッピングのセマンティックオブジェクトとアクション
• サービスや権限オブジェクトの変更
• テストユーザーの組織値と利用者属性

テストユーザーは、管理者権限を持つユーザーだけで構成しません。一般利用者、承認者、参照専用ユーザー、外部接続を使うユーザーなど、実際の業務ロールを代表する組み合わせを準備します。これにより、過剰権限によって隠れる問題を見つけやすくなります。

05アップグレード前後のテストを標準化する

テストは、技術テスト、機能テスト、権限テスト、性能確認に分けて実施します。各ケースには、前提条件、操作手順、期待結果、実測結果、証跡、判定者、実施日時を記録します。

技術テストでは、ログイン、初期ページ、静的リソース、OData通信、ブラウザコンソール、バックエンドログを確認します。機能テストでは、業務の主要な登録・変更・承認・検索フローを確認します。権限テストでは、ロールごとの表示範囲と更新範囲を比較します。性能確認では、初期表示、一覧取得、検索、保存にかかった時間を同じ条件で測定します。

性能問題を調べる場合は、SAP Fioriアプリのパフォーマンス基礎を参照し、ブラウザ、ネットワーク、UI5処理、OData、バックエンド処理のどこで時間が発生したかを分離します。平均値だけでなく、初回アクセス、再アクセス、ピーク時間帯の結果を残します。

本番切り替えの判定基準には、重大エラーゼロ、主要業務シナリオの完了、ロール別の権限確認、監視項目の正常化、切り戻し手順の確認を含めます。未解決の軽微な問題は、利用者影響、回避策、担当者、期限を記録してから稼働判定を行います。

06切り戻しと運用監視を準備する

アップグレード作業では、変更前の構成、適用したソフトウェア、設定変更、テスト結果、承認記録を一つの変更チケットに関連付けます。切り戻し判断は、エラー率、業務停止、権限不整合、データ更新失敗などの具体的な条件で定義します。

切り戻し手順には、アプリケーション、UI5リソース、launchpad設定、ロール、カタログ、テーマ、SSO連携の各項目を含めます。バックアップやエクスポートを取得する場合は、保存場所、取得時刻、復元担当者、復元テストの結果を記録します。

稼働後は、SAP Fiori launchpadのログイン数、アプリ起動エラー、ODataエラー、ブラウザエラー、応答時間、認証失敗を監視します。問い合わせは、ユーザー、ロール、アプリ、操作、時刻、ブラウザ、エラー内容をそろえて受け付けると、アップグレード起因の事象を早く分類できます。

07実務で使えるバージョン管理表

最低限、次の列を持つ管理表を作成します。

この表を変更管理、テスト管理、運用監視に共通利用すると、同じ情報を複数の台帳へ転記する負担を減らせます。バージョン番号だけでなく、依存関係と検証結果を残すことが、長期運用での再現性につながります。

08まとめ

SAP Fioriのアップグレードは、UI5ランタイムの更新作業ではなく、launchpad、バックエンドサービス、ロール、カタログ、認証、カスタムアプリを含む変更管理として実施します。対象を層別に記録し、同じ利用者シナリオをアップグレード前後で実行すると、互換性と影響範囲を判断しやすくなります。

本番切り替え後は、エラーと性能を監視し、切り戻し条件と証跡を維持します。次回の更新に向けて、発生した問題、対応時間、テスト漏れ、利用者からの問い合わせをバージョン管理表へ反映すると、アップグレード手順を継続的に改善できます。