この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、 以前のリリースの Cisco Prime Service Catalog からこのリリースにアップグレード する方法について説明します。
このアップグレード プロセスでは、サービス カタログ(Service Catalog)リリース 10.1 以上 からリリース 12.0.1 へのデータベース コンポーネントの直接アップグレードがサポートされています。データベース スキーマをサポートされているアップグレード レベルにするため、 表 6-1 に示す最新サービス パックのデータベース インストーラ プログラムをデータベースに対して実行する必要があります。
|
|
11.0 より前のリリースからアップグレードする場合は、まず 11.0 インストーラを使用してリリース 11.0 にアップグレードします。その後、Prime Service Catalog のインスタンスを起動せずに 12.0.1 インストーラを実行し、インスタンスをリリース 12.0.1 にアップグレードします。
このリリースでのプラットフォーム サポートの変更については、『 Cisco Prime Service Catalog Compatibility Matrix 』を参照してください。
アップグレードが完了したら、変更データ キャプチャ機能を無効にします(詳細については「アップグレード後の作業の実行」の手順 8 を参照)。
Rating という表示名のファセットがある場合は、アップグレード前にこのファセット名を必ず変更してください。これは、Cisco Prime Service Catalog 12.0.1 で使用可能な新しい Rating ファセットとの競合を回避するためです。
Oracle と SQL Server 向けの新しい JDBC ドライバは、このリリースの Prime Service Catalog に付属しています。WebLogic アプリケーション サーバを使用している場合は、既存の REQUESTCENTERDS データソース(newscale_drivers.jar の DataDirect ドライバを使用していたデータソース)を削除し、新しい JDBC ドライバ(Oracle では ojdbc7.jar、SQL Server では sqljdbc4.jar)を使用して REQUESTCENTERDS データソースを再作成する必要があります。詳細については、アップグレード環境の準備の項で説明します。
(注) newScale 統合型ドライバを使用するカスタマイズがある場合、データベース タイプに基づいて適切な JDBC ドライバに置き換える必要があります。
Service Import/Export には、以前のリリースとの下位互換性はありません。以前のリリースでエクスポートしたサービスは、このリリースにインポートできません。アップグレードが完了したら、コード リポジトリに保持されているサービスを必ずエクスポートしてください。
リリース 12.0.1 では Catalog Deployer における XML の書式が変更されたのに伴って、「Deployed」および「Received for Deployment」というステータスは使用できなくなりました。またコンテンツも表示できません。このため、リリース 12.0.1 へのアップグレードを実行する前に、展開が保留されているすべてのパッケージを処理する必要があります。
この章で説明するアップグレード プロセスでは、サービス カタログ(Service Catalog)の新機能をサポートするため、サービス カタログ(Service Catalog)ソフトウェアと Service Catalog データベースがアップグレードされます。これらの機能を使用することで、たとえば、データおよび参照整合性をさらに厳しく管理することで、サービス カタログ(Service Catalog)データベースのデータ品質を改善できます。
アップグレード プロセスでは、アプリケーション スキーマの一部として認識されない既存のデータベースのすべてのオブジェクトが特定されます。
– サービス カタログ(Service Catalog)テーブルの認識されないインデックス。
– サービス カタログ(Service Catalog)テーブルの認識されないトリガー。
通常、組織ですでに サービス カタログ(Service Catalog)ソリューションのアップグレード方法を開発しています。または、他の企業のソフトウェア アップグレードのベスト プラクティスを収集している場合もあります。本書で説明されている方法は、代替方法として実行したり、特定の新しいアップグレード要件に合わせて開発済みの方法を強化したりするときに役に立ちます。
既存の サービス カタログ(Service Catalog)システムのアップグレード手順の予行練習を行うサンドボックス環境を作ることを推奨します。この実行中に発生する技術的な問題や解決策を記録しておきます。このようにすることで、実稼働システムで実際のアップグレードするときに役に立ちます。予行練習をすることで、アップグレード プロセスの始まりから終わりまで全体的な時間がわかるので、実稼働システムのアップグレードに必要な適切なシステム ダウンタイムを計画するときにも役に立ちます。
サンドボックス環境でシステムを正常にアップグレードし、プロセスに問題がなければ、実稼働システムでのアップグレードを計画できます。アップグレードは、予行練習で準備した技術注記も参考にして、本書の指示に従い実行します。
手順 1 現在の実稼働システムのバックアップを作成し、データベースの別のセットに復元します。
(注) 新しい SQL Server 2012 SP23 データベースまたは Oracle 12c データベースにデータベース バックアップを復元します。
手順 2 リリース 12.0.1 のすべての前提条件(新しいバージョンのアプリケーション サーバ、Java、および JDBC ドライバを含む)に対応したサンドボックス環境を作成します。これは、リリース 12.0.1 パッケージからアップグレード プログラムを実行する環境で、実稼働データベースのコピーに接続するよう設定する必要があります。
手順 3 「WildFly アプリケーション サーバでの Prime Service Catalog のインストール」または「WebLogic アプリケーション サーバでの Prime Service Catalog のインストール」の説明に従い、Service Catalog セットアップ プログラムを実行します。インストール ウィザードの [Service Catalog データベース(Service Catalog Database)] パネルで、実稼働データベースのコピーの接続情報を入力します。
手順 5 [既存のデータベースをアップグレード(Upgrade Existing Database)] をクリックします。
手順 6 [スキーマの検証(Validate Schema)] をクリックします。
手順 7 [エラーを表示(View Errors)] をクリックします。データベースのスキーマ エラーが報告された場合は、データベース管理者やアプリケーション プログラマと連携して、そのスキーマ エラーを修復してください。スキーマ エラーによっては、エラーの修復に SQL コマンドが 推奨 されています。これがエラー状況に適しているかどうかは、データベース管理者およびアプリケーション プログラマと相談してください。また、スキーマ エラーによっては、適切に修復するために Cisco Technical Assistance Center(TAC)に連絡する必要があります。発生したすべての検証エラーとその解決策をすべて文書化します。
手順 8 検証エラーを修復したら、そのたびに [スキーマの検証(Validate Schema)] をクリックします。この作業を エラーがレポート されなくなるまで繰り返します。
手順 9 [データの検証(Validate Data)] をクリックします。
手順 10 [エラーを表示(View Errors)] をクリックします。データベースのデータ エラーが報告された場合は、データベース管理者やアプリケーション プログラマと連携して、そのデータ エラーを修復してください。データ エラーには、検証エラーと自動修復可能エラーの 2 種類があります。検証エラーによっては、エラーの修復に SQL コマンドが 推奨 されています。これがエラー状況に適しているかどうかは、データベース管理者およびアプリケーション プログラマと相談してください。また、スキーマ エラーによっては、適切に修復するために Cisco Technical Assistance Center(TAC)に連絡する必要があります。発生したすべての検証エラーとそれに対応する解決策をすべて文書化します。
手順 11 検証エラーを修復したら、そのたびに [データの検証(Validate Data)] をクリックします。この作業を検証エラーがレポートされなくなるまで繰り返します。[自動修復可能なエラー(Auto-Repairable Errors)] はいくつかあっても問題ありません。これらは、次のステップでプログラムにより修復されます。
手順 12 [データベースの修復(Repair Database)] をクリックします。この機能を使用すると、直前の手順で報告されたすべての自動修復可能エラーがプログラムによって修復されます。
手順 13 データベース修復機能が完了したら、[次へ(Next)] をクリックし、サービス カタログ(Service Catalog)インストール ウィザードの残りのページで必要な処理をすべて行います。
手順 14 インストール ウィザードによるアップグレード インストールが完了したら、必要なカスタマイズをサンドボックス環境に再適用します。
手順 15 サンドボックス環境のアップグレード システムに対してユーザ受け入れテストを実行します。
手順 16 プロセスにおいてこれまでに作成した技術注記をすべて収集します。
手順 17 この時点で、アップグレード プロセスに問題があると感じた場合、サンドボックス環境をクリーンアップして、サンドボックス環境ですべてのステップをやり直すこともできます。この場合、これまで収集した技術注記を参照し、本書の指示に従います。
手順 18 準備ができたら、アップグレード プロセス全体を実稼働環境で繰り返します。
プラットフォームの中には一部、リリース 12.0 以降にサポートが終了したものがあります。したがって、Prime Service Catalog をアップグレードする前に、「リリース アップグレード パス」を参照し、データベース、アプリケーション サーバ、Java、Web サーバ、またはオペレーティング システムのバージョンをアップグレードする必要があるかどうかを確認してください。
既存の サービス カタログ(Service Catalog)が稼働するプラットフォームがサポートされなくなっている場合、Chapter 2, “インストール要件”で説明されているように、新しくサポートされるいずれかのプラットフォームのための新しい環境を準備する必要があります。
サービス カタログ(Service Catalog)のアップグレードでは次の操作を行います。
実稼働環境で、次に示すアップグレード前の必須作業を行います。
手順 1 Advanced Reporting モジュールを使用しない場合、手順 2 に進みます。Advanced Reporting モジュールを使用する場合、Reporting のアップグレード前の作業の実行で説明されている、そのためのいくつかのアップグレード前の作業を実行する必要があります。Advanced Reporting モジュールのアップグレード前の作業だけを実行したら、この項に戻り、ここで説明する手順を完了します。
手順 2 アプリケーション サーバのバージョンが変更された場合、Service Link の JMS キューに残っている未処理のメッセージが、新しいアプリケーション サーバへ自動的に移行されることはありません。アップグレード前に、未処理のメッセージがキューにないかチェックし、メッセージがある場合は処理しておく必要があります。キューがクリアになったら、すべての Service Link エージェントを停止します。これにより、アップグレード後にエージェントが再起動する前に Service Link 通信を確認できます。
手順 3 Catalog Deployer では、異なるリリース レベルの サービス カタログ(Service Catalog)間でのパッケージの展開はサポートされません。そのため、アップグレード前に、展開できるすべてのアセンブル パッケージを展開したことを確認します。データベースがリリース 12.0.1 にアップグレードされた後でこれらを展開することはできません。また、アップグレードを実行する場合、現在のシステムでアセンブルする新しいパッケージに対して、説明されているリリース バージョンの サービス カタログ(Service Catalog)を含めることもできます。これにより、異なるリリース バージョンのパッケージを簡単に識別できます。
手順 4 アップグレード前の作業として、展開されるパッケージのリストを確認します。オンラインにしておく必要がないパッケージをエクスポートおよび削除できます。これらのパッケージは(アップグレードを実行すると)展開できなくなるので、これらをオンラインにしておくことは、展開履歴の照会のみに役に立ちます。これらのパッケージを削除することで、データベース容量が増加します。このようなクリーンアップ作業はすべてのシステム(開発、テスト/QA および実稼働)で実行できます。
手順 5 アプリケーション サーバのすべての サービス カタログ(Service Catalog)サービスを停止します。
手順 6 すべての サービス カタログ(Service Catalog)データベースをバックアップします。複数ある場合、すべての サービス カタログ(Service Catalog)関連データベースをバックアップします。たとえば、Service Catalog データベースの他に、別個の Data Mart データベースまたは Content Store データベース(Cognos により使用される)がある場合があります。この場合は、すべてのデータベースをバックアップする必要があります。
手順 7 すべてのカスタマイズ スクリプトまたはファイルをバックアップします。アップグレード プロセスでは、既存のインストールに対するカスタマイズの内容は維持されません。そのため、アップグレード後も適切な場合、これらのカスタマイズの一部またはすべてをシステムに再適用する必要があります。
手順 8 インストール ディレクトリをバックアップします。元々 サービス カタログ(Service Catalog)ソフトウェアがインストールされていたディレクトリをバックアップします。
手順 9 監査ログ データを移行します。監査ログ データの移行を参照してください。
手順 10 次のアップグレード環境の準備に進みます。
古いリリース(Oracle 11g の 10.1 など)から現在のリリース(Oracle 12c の 12.0.1)に監査ログ データを移行するには、CDCADMIN スキーマを現在のリリースにインポートする必要があります。
アップグレード プロセスを実行する前に、次のコマンドを実行して、現在のリリースに適切なテーブル スペースを作成します。
1. create table space cdc_tbsp
上記のコマンドを実行したら、前に使用していた名前で RCUser スキーマが準備されていることを確認し、作成された CDCADMIN スキーマに監査ログ データをインポートします。
実稼働環境でのアップグレードの実行準備ができている場合、この項をスキップします。
この項では、アップグレード プロセスの予行練習を実行するときに使用するサンドボックス環境を作成します。アップグレード プロセスに問題がなく、予行練習中に収集した技術注記を準備したら、実際の実稼働システムでアップグレード手順を開始できます。
アップグレード前の作業の実行に記載されている必須のアップグレード前作業を実行します。
手順 1 実稼働データベース バックアップを別のデータベース セットに復元します。SQL Server 環境の Service Catalog バージョン 10.1 で監査ログ を有効にしている場合は、Service Catalog バージョン 10.1 から 12.0.1 へのアップグレード時にデータベースを復元するときに、次のコマンドを実行して監査ログ レコードを表示します。
(注) デフォルトでは、Service Catalog 10.1 から Service Catalog 12.0 への直接アップグレードでデータベース バックアップ操作の監査ログが表示されます。
手順 2 Oracle DBMS を使用する場合、復元後に各データベースで統計情報の再コンパイルを実行することを推奨します。この手順は、大規模なデータベースでのアップグレード プロセスのパフォーマンスを改善するために不可欠です。第 3 章の Oracle の設定に関する項に説明されているすべての要件を満たしていることを確認します。
手順 3 データベースが SQL Server の場合、次の手順を実行して、READ_COMMITTED_SNAPSHOT をアクティブにする必要があります。
a. SQL Server に「sa」ユーザとして接続し、SQL Server をシングルユーザ モードで設定します。
b. 次のコマンドを実行します。<database_name> は、RequestCenter データベースの名前に置き換えます。
ALTER DATABASE < database_name > SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL=110
c. SQL Server をマルチユーザ モードに戻します。
手順 4 第 1 章の データベースの設定 に関する項の説明に従い、データベース ユーザ「CPSCUser」に追加の権限を付与します。このリリースに必要な権限が「CPSCUser」に付与されているかどうかが確実ではない場合は、データベースの設定に関する項で説明するコマンドを再度実行できます。これらのコマンドを複数回実行しても、問題は発生しません。
手順 5 『 Cisco Prime Service Catalog Compatibility Matrix 』で説明するサポートされるプラットフォームと前提要件情報を参照してください。プラットフォームのサポートが終了している場合は、サンドボックス環境で、サポートされているオペレーティング システムに、正しいバージョンのアプリケーション サーバ、Web サーバおよび JDK をインストールします。
手順 6 「インストール前の作業:WildFly」または「インストール前の設定:WebLogic」の手順をすべて読み、既存のアプリケーション サーバ環境で設定を再設定または調整する必要があるかどうかを確認します。新しい jar ファイルをコピーする必要がある場合や、このリリースの Prime Server Catalog で新しい設定を追加する必要がある場合があります。
手順 7 Prime Service Catalog のこのリリースには新しい JDBC ドライバが付属しているため、WebLogic 環境の既存の REQUESTCENTERDS データソースと、DATAMARTDS データソースが存在する場合は DATAMARTDS データソースも削除する必要があります。WildFly 環境ではこの作業を行う必要はありません。新しい JDBC ドライバを使用するには、REQUESTCENTERDS データソースを再作成する必要があります。WebLogic でのデータソースの作成手順については、JDBC データ ソースの設定を参照してください。DATAMARTDS データソースは不要になったことに注意してください。
手順 8 次のインストール ウィザードの実行(検証のページまで)に進みます。
インストール ウィザードを実行してアップグレードを行うには、次の手順を実行します。
手順 1 「WildFly アプリケーション サーバでの Prime Service Catalog のインストール」または「WebLogic アプリケーション サーバでの Prime Service Catalog のインストール」の説明に従って、サービス カタログ(Service Catalog)インストール ウィザードで標準(Typical)およびカスタム(Custom)インストールを実行します。
手順 2 インストール ウィザードの [Service Catalog データベース(Service Catalog Database)] パネルで、データベースの値を入力します。
手順 3 [次へ(Next)] をクリックして、ウィザードの次のページに進みます。
図 6-1 に示す [既存のインストールが検出されました(Existing Installation Detected)] ダイアログ ボックスが表示されます
図 6-1 既存のインストールが検出されました(Existing Installation Detected)
手順 4 [既存のデータベースをアップグレード(Upgrade Existing Database)] をクリックします。
インストール ウィザードの [検証(Validation)] ページが表示されます。
既存のデータベースは、検証および修復が正常に完了するまで、サービス カタログ(Service Catalog)インストール ウィザードでアップグレードすることはできません。[検証(Validation)] ページでは、次の各機能を上から順に実行する必要があります。
3. [データベースの修復(Repair Database)]
[スキーマの検証(Validate Schema)] をまだ一度も実行していない段階で、[データの検証(Validate Data)] を実行することはできません。また、[データの検証(Validate Data)] をまだ一度も実行していない段階で、[データベースの修復(Repair Database)] を実行することはできません。
各機能は複数回実行できます。ただし、[スキーマの検証(Validate Schema)] を実行するたびに、プログラムは再初期化されるため、検証プロセスは実質的に最初から実行されます。たとえば、[データの検証(Validate Data)] まで完了している場合は、[データベースの修復(Repair Database)] を開始することができますが、代わりに [スキーマの検証(Validate Schema)] を再度実行することも可能です。ただしこの場合には、[スキーマの検証(Validate Schema)] を実行したことによりシステムが再初期化されるため、[スキーマの検証(Validate Schema)] が完了した後は、ただちに [データベースの修復(Repair Database)] を実行することはできず、次に [スキーマの検証(Validate Schema)] を実行する必要があります。
手順 5 次のデータベースの検証に進みます。
Prime Service Catalog のアップグレード作業におけるデータベースの検証プロセスについて十分な知識がある場合は、この項をスキップしてスキーマの検証に進んでください。[スキーマの検証(Validate Schema)] および [データの検証(Validate Data)] の実行時にエラーが発生したときは、この項に戻ればいつでもその内容を確認することができます。
[検証(Validation)] ページの各機能は、既存のスキーマおよびデータベースの整合性を検証するためのものです。いずれの検証スクリプトも、その結果はデータベース内の SchValidationLog というテーブルに格納されます。このログ ファイルの表示方法については、SchValidationLog テーブルを参照してください。次の 表 6-2 に、検証エントリの全エラー レベル(ErrorLevel)とその内容に関する説明を示します。
上記の 表 6-2 に記載されているように、[スキーマの検証(Validate Schema)] または [データの検証(Validate Data)] の実行時に [エラーを表示(View Errors)] をクリックして表示した Validation Errors テーブルで、ErrorLevel が「error」となっている検証エントリのみ、手動で修復する必要があります。 SchValidationLog テーブル で報告されているその他の検証エラーはすべて、自動的に処理されます。
ErrorLevel が「error」である検証エントリをすべて修復したら、同じ検証機能を再度実行して、これ以上エラーがレポートされないことを確認します。手動修復の結果として、新しい検証エラーが表示されることもあります。この場合には、再び検証機能を繰り返し実行して、検証エラーをすべて修復する必要があります。
すべてのスキーマ検証エラーを確認および修復してから、すべてのデータ検証エラーを確認および修復することを強く推奨します。このようにすることで、スキーマ検証エラーの修復とデータ検証エラーの修復が混在することによる回帰エラーの可能性を軽減できます。
すべての検証スクリプトの結果は、検証エラーがあるかどうかに関係なく、データベースの SchValidationLog というテーブルに保存されます。
SchValidationLog テーブルを表示するには、次の手順を実行します。
手順 1 データベースにスキーマ所有者(つまり、CPSCUser)として接続し、テーブル SchValidationLog を参照して検証結果を確認します。SQL Analyzer(図 6-2 を参照)や SQL*Plus などのユーティリティを使用してデータベースに接続できます。
図 6-2 SchValidationLog テーブルの参照
手順 2 SchValidationLog テーブルを開いて内容を確認します(図 6-3 を参照)。
手順 3 SchValidationLog テーブルの ErrorLevel 列で次の値をチェックして、推奨されている操作を実行します。
手順 4 SchValidationLog テーブルには、多数のエントリが示されます。そのため、次の SQL コマンドを使用して、内容をフィルタリングできます。
SELECT * FROM SchValidationLog WHERE ErrorLevel= "error"
アップグレード プロセスを開始する前に手動で修復する必要がある検証エラーを確認する場合は、WHERE 句「 ErrorLevel= 'error' 」を指定します。SchValidationLog テーブルの他のエントリを参照する場合、WHERE 句を削除するか、値「error」を別の値に変更します(たとえば、「inform: auto-repairable」です。詳細については、 表 6-2 を参照してください)。
SchValidationLog テーブルの RunType 列を参照します。
手順 1 [スキーマの検証(Validate Schema)] をクリックします。
スキーマの検証テストが完了した時点で検証エラーが検出されなかった場合は、「完了(Completed)」というメッセージが表示されます。
エラーがレポートされない場合は、データの検証に進みます。
スキーマの検証テストが完了した時点で検証エラーが検出された場合は、次のように「完了しましたがエラーが発生しました(Completed with errors)」というメッセージが表示されます。
手順 2 [エラーを表示(View Errors)] をクリックします。
[検証エラー(Validation Errors)] ウィンドウが表示されます。ウィンドウのサイズを変更すれば、次の例のようにテーブル全体を表示することができます(図 6-4)。
手順 3 Validation Errors テーブルに示されるエラーは、アップグレード プロセスを続行する前に手動で修復する必要があります。詳細については、データベースの検証を参照してください。
手順 4 すべての検証エラーが修復されたら、次のデータの検証に進みます。
手順 1 [データの検証(Validate Data)] をクリックします。
データの検証テストが完了した時点で検証エラーが検出されなかった場合は、次のように「完了(Completed)」というメッセージが表示されます。
エラーがレポートされない場合は、データベースの修復に進みます。
データの検証テストが完了した時点で検証エラーが検出された場合は、「完了しましたがエラーが発生しました(Completed with errors)」というメッセージが表示されます。
手順 2 [エラーを表示(View Errors)] をクリックします。
[検証エラー(Validation Errors)] ウィンドウが表示されます。
手順 3 Validation Errors テーブルに示されるエラーは、アップグレード プロセスを続行する前に手動で修復する必要があります。詳細については、データベースの検証を参照してください。
手順 4 すべての検証エラーが修復されたら、次のデータベースの修復に進みます。
手順 1 [データベースの修復(Repair Database)] をクリックします。
データベースの修復が完了すると、「完了(Completed)」というメッセージが表示されます。
手順 2 (オプション)[エラーの表示(View Errors)] をクリックします。
[検証エラー(Validation Errors)] ウィンドウが表示されます。テーブル全体が表示されるようにウィンドウのサイズを変更します。
表示されている検証エラーは、ErrorLevel が「inform:auto-repaired」となっているもの、つまり [データベースの修復(Repair Database)] を使用してプログラム的に修復された検証エラーのみです。
手順 3 次のインストールの完了に進みます。
データベースの検証および修復が完了すれば、いつでもアップグレード プログラムを開始することができます。
手順 1 [次へ(Next)] をクリックして、サービス カタログ(Service Catalog)インストール ウィザードの次のページに進みます。
手順 2 「WildFly アプリケーション サーバでの Prime Service Catalog のインストール」または「WebLogic アプリケーション サーバでの Prime Service Catalog のインストール」の手順に従って、インストール ウィザードを続行します。
インストール ウィザードの [インストール前の要約(Pre-Installation Summary)] ページで [インストール(Install)] をクリックすると、インストーラによりアップグレード スクリプトが実行され、データベースのスキーマおよびコンテンツが変更されます。データベースのサイズによっては、アップグレード スクリプトの実行に時間がかかることがあります。アップグレード スクリプトによりデータベース スキーマおよびコンテンツが変更されたら、インストーラは WAR ファイルの作成を開始します。「WildFly のインストール後の作業」の項または「インストール後の設定:WebLogic」の項に記載されている同じ手順に従って、サービス カタログ(Service Catalog)製品の WAR ファイルを展開します。
手順 3 WAR ファイルの展開が終了し、アプリケーション サーバを起動できるようになると、アップグレード プロセスは実質的に完了です。これで、サービス カタログ(Service Catalog)アプリケーションがリリース 12.0 になりました。この時点で、必要に応じて、データベースおよびインストール ディレクトリのバックアップを作成できます。Oracle DBMS を使用する場合、システムのランタイム パフォーマンスを改善するため、アップグレードしたデータベースで統計情報の再コンパイルを再実行することを推奨します。
手順 1 必要に応じて、インストーラによりデータベースから削除されたカスタム データベース オブジェクトを再作成します。
手順 2 カスタム コードは、新しいバージョンの JDK に対応している必要があります。
手順 3 Service Import/Export には、以前のリリースとの下位互換性はありません。以前のリリースでエクスポートしたサービスをリリース 12.0 にインポートすることはできません。アップグレード前のコード リポジトリにあるサービス エクスポート ファイルを保守する場合は、そのファイルを再エクスポートしてリリース 12.0 用にマークします。
(注) 異なるデータベースから(たとえば Catalog Deployer を使用して)インポートされたユーザは、アプリケーションにログインするためのパスワードをリセットする必要があります。これはデータベースごとにキー暗号キーが異なるためです。
手順 4 以前に組織で使用した手順に従い、アプリケーションのすべてのカスタマイズを再実装します。
手順 5 サービス カタログ(Service Catalog)アプリケーションに管理者ユーザとして接続します。「Administration」モジュールに移動し、[設定(Settings)] タブをクリックします。[カスタマイズ設定(Customizations Settings)] で、[ブラウザキャッシュ(Browser Cache)] を探します(図 6-5 を参照)。
手順 6 [ブラウザキャッシュ(Browser Cache)] 設定の [有効(Enabled)] オプション ボタンを選択します。[バージョン(Version)] テキスト ボックスの右にある [+] ボタンをクリックします。クリックすると、[バージョン(Version)] の数値が 1 つずつ増加します。次に [更新(Update)] をクリックします。この設定により、サービス カタログ(Service Catalog)システムのアップグレード後にユーザが初めて サービス カタログ(Service Catalog)URL に接続するときにブラウザのキャッシュをクリアするよう通知されます。
手順 7 <ServiceCatalog_Install_Dir>/dist ディレクトリにあるマスター キー パスワード ファイル kek_new.txt と kek_old.txt のバックアップを安全な場所に作成する必要があります。
手順 8 監査ログ データを移行したら、データベース ベンダー提供の変更データ キャプチャ機能を無効にします(これ以降、Prime Service Catalog 12.0 がこの機能を使用しないため)。
次の章では、 Reporting モジュールの Cognos コンポーネントのアップグレード手順について説明します。アップグレード前の サービス カタログ(Service Catalog)システムに Reporting モジュールがインストールされていた場合は、次の章に進み、Reporting モジュールがリリース 12.0 で機能するように、Cognos コンポーネントのアップグレード プロセスを完了する必要があります。