この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
この章では、Cisco Service Portal Release 2008.3 以上 から Release 9.3 .2 へのアプリケーション アップグレードを実行する方法について説明します。
このアップグレード プロセスでは、Service Portal Release 2008.3 SP9 以上 から Release 9.3.2 への直接データベース コンポーネント アップグレードをサポートします。次の 表 4-1 に示されている、最新のサービス パックのデータベース インストーラ プログラムは、データベース スキーマをサポートされているアップグレード レベルにするデータベースに対して実行する必要があります。
|
|
既存のインストールが 2008.3 SP9 よりも前のバージョンの場合、サポートされているバージョンにアップグレードする必要があります。場合によっては、複数のバックツーバック データベース コンポーネント アップグレードを実行する必要があります。
|
|
|
|
ここでは、製品の制限事項に関する通知や、このバージョンにアップグレードする際に考慮する必要がある重要な注意事項を記載しています。
このリリースでは、新しいプラットフォーム サポートがあります。 表 4-3 を参照して、サードパーティ ソフトウェアの新しいバージョンをインストールする必要があるか確認してください。
|
|
|
詳細については、「プラットフォーム サポート マトリクス」を参照してください。
このリリースでは、Service Portal のデフォルト スタイルが変更され、異なるテーマ カラーおよびフォントを使用するようになりました。これらの変更を実装するかどうかは任意です。アプリケーションで現在使用しているスタイルを使用する場合、このリリースへのアップグレード後に既存の custom.css および common.css を再適用して、変更を上書きできます。common.css ファイルは、RequestCenter.war¥refactor¥common¥css フォルダにあります。
このリリースではアプリケーション アーキテクチャが変更され、Business Engine は Request Center から独立したアプリケーションではなくなりました。BusinessEngine.jar、be.properties、および bejms.properties ファイルは、現在 RequestCenter.ear 内にあります。インストールおよびアップグレード プロセス中に、インストール プログラムによって RequestCenter.ear および ISEE.war だけが生成されます。詳細については、「インストールおよび設定ガイド」を参照してください。
このリリースにおけるアプリケーション アーキテクチャの改善の一環として、Request enter および Business Engine の上にあった EJB レイヤが削除されています。これらの変更によるアプリケーション インストールおよび設定手順への影響はありません。
Service Link のスケーラビリティを改善するため、インバウンド Service Link メッセージによって呼び出されたすべての Business Engine API コールは、直接 Business Engine に渡されるのではなく、JMS キューにルーティングされるようになりました。詳細については、「インストールおよび設定ガイド」を参照してください。
Service Import/Export には、以前のリリースとの下位互換性はありません。以前のリリースでエクスポートしたサービスは、このリリースにインポートできません。アップグレードが完了したら、コード リポジトリに保持されているサービスを必ずエクスポートしてください。
このマニュアルで説明されているアップグレード プロセスでは、Service Portal ソフトウェアおよび Online Transactional Processing(OLTP)データベースがアップグレードされ、Service Portal で提供される新しい機能を使用できるようになります。これらの機能を使用することで、たとえば、データおよび参照整合性をさらに厳しく管理することで、Service Portal データベースのデータ品質を改善できます。アップグレード プロセスでは、Advanced Reporting モジュールのアップグレード方法について説明されます。
アップグレード プロセスでは、アプリケーション スキーマの一部として認識されない既存のデータベースのすべてのオブジェクトが示されます。
• 認識されないオブジェクトは、Service Portal テーブルと相互作用する場合、データベースから自動的に削除されます。たとえば、次のオブジェクト(存在する場合)はドロップされます。
– Service Portal テーブルの認識されないインデックス。
– Service Portal テーブルの認識されないトリガー。
– Service Portal テーブルの認識されない制約。
– Service Portal テーブルを示す認識されない外部キー制約。
• Service Portal テーブルと相互作用しない認識されないオブジェクトは報告されるだけで、ドロップはされません。たとえば、存在する場合、Service Portal テーブルを参照しないテーブル、列、シーケンス、ストアド プロシージャ、関数、インデックス、および Service Portal テーブルに影響しない制約はドロップされません。
• アップグレードする前に、データベース バックアップおよびファイル システム バックアップを作成および検証する必要があります。アップグレードのロールバックは、データベースおよびファイル システムを手動で復元することでのみ可能なので、バックアップを作成しておくことは重要です(ロールバック機能はアップグレード プログラムに組み込まれていません)。
• アップグレード プロセス中、実稼動サイトがダウンするので、アップグレードは、メンテナンス期間に計画してください。
• 2008.3 SP9 以上からアップグレードします。『「リリース アップグレード パス」』を参照してください。
• データベース バックアップおよび十分に計画された復元プロセス。
• すべてのカスタマイズの完全なリスト(カスタム スタイル シート、JavaScript ライブラリ、LDAP Java マッピング コードなど)。
• SQL Server インストールの場合、アップグレードの前に、カスタム フルテキスト カタログをデータベースからドロップします。
次の SQL コマンドを Oracle「sys」ユーザとして実行して、catcio.sql パッケージが Oracle データベースにインストールされているかどうか確認します。
SELECT COUNT(*) FROM ALL_TABLES WHERE OWNER='SYS' AND TABLE_NAME LIKE ‘IND_ONLINE$';
戻り値がゼロ(0)の場合、Oracle「sys」ユーザは、Oracle に sysdba としてログインして、「catcio.sql」パッケージを Oracle データベースにインストールする必要があります。このプロセスは、Service Portal インストールを開始する前に実行する必要があります。これは、Oracle データベースの場合、インストールおよびアップグレード スクリプトにより ONLINE パラメータでテーブル インデックスが作成されるためです。Catcio.sql パッケージは、通常、$ORACLE_HOME/rdbms/admin ディレクトリにあります。
通常、組織ですでに Service Portal ソリューションのアップグレード方法を開発してます。または、他の企業のソフトウェア アップグレードのベスト プラクティスを収集している場合もあります。本書で説明されている方法は、代替方法として実行したり、特定の新しいアップグレード要件に合わせて開発済みの方法を強化したりすうるときに役に立ちます。
既存の Service Portal システムのアップグレード手順の予行練習を行うサンドボックス環境を作ることを推奨します。この実行中に発生する技術的な問題や解決策を記録しておきます。このようにすることで、実稼動システムで実際のアップグレードするときに役に立ちます。予行練習をすることで、始まりから終わりまでアップグレード プロセスの全体的な時間がわかるので、実稼動システムのアップグレードに必要な適切なシステム ダウンタイムを計画するときにも役に立ちます。
サンドボックス環境でシステムを正常にアップグレードし、プロセスに問題がなければ、実稼動システムでのアップグレードを計画できます。アップグレードは、予行練習で準備した技術注記も参考にして、本書の指示に従い実行します。
ステップ 1 現在の実稼動システムのバックアップを作成し、データベースの別のセットに復元します。
(注) SQL Server 2005 データベースおよび Oracle 10g データベースはこのリリースではサポートされないので、データベース バックアップを新しい SQL Server 2008 R2 データベースまたは Oracle 11g データベースに復元する必要があります。
ステップ 2 リリース 9.3.2 のすべての前提条件を満たすサンドボックス環境を作成します。これは、リリース 9.3.2 パッケージからアップグレード プログラムを実行する環境で、実稼動データベースのコピーに接続するよう設定する必要があります。
ステップ 3 検証および修復プログラムを実稼動データベースのコピーに対して実行し、最初のオプション [Perform Schema Validation] を選択します。このプログラムは、既存のデータベースの検証および修復後のインストールのアップグレードに使用する Service Portal セットアップ プログラムとは異なります。
ステップ 4 検証および修復プログラムにより、データベースのスキーマ エラーが報告された場合、データベース管理者やアプリケーション プログラマとともにスキーマ エラーを修復します。スキーマ エラーによっては、エラーの修復に SQL コマンドが 推奨 されています。これがエラー状況に適しているかどうかは、DBA およびアプリケーション プログラマと相談してください。また、スキーマ エラーによっては、適切に修復するために Cisco Technical Assistance Center(TAC)に連絡する必要があります。発生するすべての検証エラーおよび解決策について説明します。
ステップ 5 検証エラーを修復したら、検証および修復プログラムによりスキーマ エラーが報告されなくなるまで、検証および修復プログラムを再実行して、[Perform Schema Validation] オプションを実行します。
ステップ 6 検証および修復プログラムを再実行して、2 つめのオプション [Perform Data Validation] を選択します。
ステップ 7 [Perform Data Validation] オプションにより、a) [Validation Errors] および b) [Auto-Repairable Errors] の 2 つのエラーを示すレポートが作成されます。[Validation Errors] の数が 0 より大きい場合、データベース管理者およびアプリケーション プログラマと協力して、データのエラーを修復します。検証エラーによっては、エラーの修復に SQL コマンドが 推奨 されています。これがエラー状況に適しているかどうかは、DBA およびアプリケーション プログラマと相談してください。また、スキーマ エラーによっては、適切に修復するために Cisco Technical Assistance Center(TAC)に連絡する必要があります。発生するすべての検証エラーおよび解決策について説明します。
ステップ 8 検証エラーを修復したら、検証および修復プログラムにより報告される [Validation Errors] の数がゼロになるまで、検証および修復プログラムを再実行して、[Perform Data Validation] オプションを実行します。[Auto-Repairable Errors] はいくつかあっても問題ありません。これらは、次のステップでプログラムにより修復されます。
ステップ 9 検証および修理プログラムを再実行して、3 つめのオプション [Repair Database] を実行します。このオプションは、最後のステップで報告されたすべての [Auto-Repairable Errors] をプログラムにより修復します。完了したら、プログラムにより、[Total Errors] の数がゼロと報告されます。
ステップ 10 Service Portal セットアップ プログラムを実行して、[Upgrade existing installation] オプションを選択します。
ステップ 11 セットアップ プログラムによりアップグレードが完了したら、必要なカスタマイズをサンドボックス環境に最適用します。
ステップ 12 サンドボックス環境のアップグレード システムに対してユーザ許容テストを実行します。
ステップ 13 プロセス中に作成した技術注記をすべて収集します。
ステップ 14 この時点で、アップグレード プロセスに問題があると感じた場合、サンドボックス環境をクリーンアップして、サンドボックス環境ですべてのステップをやり直すこともできます。この場合、これまで収集した技術注記を参照し、本書の指示に従います。
ステップ 15 準備ができたら、アップグレード プロセス全体を実稼動環境で繰り返します。
このリリースでの Service Portal では、いくつかのプラットフォームにサポートが終了しています。そのため、Cisco Service Portal をアップグレードする前に、表 4-3を参照して、アプリケーション サーバ、Web サーバまたはオペレーティング システムのバージョンをアップグレードする必要があるかどうか確認します。
既存の Service Portal が実行するプラットフォームのサポートが終了した場合、「インストールおよび設定ガイド」で説明されているように、新しくサポートされるいずれかのプラットフォームのための新しい環境を準備する必要があります。
たとえば、Service Portal システムが Windows Server 2003 オペレーティング システムの WebLogic 10.3 で実行しているとします。WebLogic 10.3 は Service Portal のリリース 9.3.2 でサポートされています。ただし、Windows Server 2003 のサポートは終了したため、Windows Server 2008 R2 オペレーティング システムを使用する新しいコンピュータに WebLogic 10.3 をインストールする必要があります。
また、Service Portal が AIX 5.3 オペレーティング システムの WebSphere 6.1 で実行しているとします。WebSphere 6.1 と AIX 5.3 は両方ともリリース 9.3.2 の Service Portal でサポートが終了したため、AIX 7.1 オペレーティング システムで WebSphere 7.0 を使用する別のコンピュータを準備する必要があります。
• 現在のバージョンのアプリケーションを立ち上げ実行しながら、アップグレード前の作業を実行します
• Service Portal Release 9.3.2 インストールの新しくサポートされるプラットフォーム条件および前提条件を満たすサンドボックス環境を準備します
• アップグレード前のデータベースの整合性を検証し、検出されたスキーマまたはデータ問題を修復します
実稼動環境で、次に示すアップグレード前の必須作業を実行します。
ステップ 1 Advanced Reporting モジュールがない場合、手順 2 に進みます。それ以外の場合、「Advanced Reporting でのアップグレード前の作業の実行」で説明されている、Advanced Reporting モジュールのためのいくつかのアップグレード前の作業を実行する必要があります。Advanced Reporting モジュールのアップグレード前の作業のみ実行したら、この項に戻り、ここで説明する手順を完了します。
ステップ 2 アプリケーション サーバ バージョンの変更により、Service Link および JMS アダプタの JMS キューのメッセージは、新しいアプリケーション サーバに自動的に移行されません。アップグレード前に、未処理のメッセージがキューにないかチェックし、メッセージがある場合は処理しておく必要があります。キューがクリアになったら、すべての Service Link エージェントを停止します。これにより、アップグレード後にエージェントが再起動する前に Service Link 通信を確認できます。
ステップ 3 Catalog Deployer では、異なるリリース レベルの Service Portal 間でのパッケージの展開はサポートされません。そのため、アップグレード前に、展開できるすべてのアセンブル パッケージを展開していることを確認します。確認しないと、データベースがリリース 9.3.2 にアップグレードされた後でこれらを展開できなくなります。また、アップグレードを実行する場合、現在のシステムでアセンブルする新しいパッケージに対して、説明されているリリース バージョンの Service Portal を含めることもできます。これにより、異なるリリース バージョンのパッケージを簡単に識別できます。
ステップ 4 アップグレード前の作業として、展開されるパッケージのリストを確認します。オンラインにしておく必要がないパッケージをエクスポートおよび削除できます。これらのパッケージは(アップグレードを実行すると)展開できなくなるので、これらをオンラインにしておくことは、展開履歴の照会のみに役に立ちます。これらのパッケージを削除することで、データベース容量が増加します。このようなクリーンアップ作業はすべてのシステム(開発、テスト/QA および実稼動)で実行できます。
ステップ 5 アプリケーション サーバのすべての Service Portal サービスを停止します。
ステップ 6 Service Portal データベースをバックアップします。複数ある場合、すべての Service Portal 関連データベースをバックアップします。たとえば、RequestCenter データベースの他に、個別の Datamart データベースまたは ContentStore データベース(Cognos により使用されます)があります。このような場合、すべてのデータベースをバックアップする必要があります。
ステップ 7 すべてのカスタマイズ スクリプトまたはファイルをバックアップします。アップグレード プログラムでは、既存のインストールのカスタマイズは保持されません。そのため、アップグレード後も適切な場合、これらのカスタマイズの一部またはすべてをシステムに再起動する必要があります。
ステップ 8 インストール ディレクトリをバックアップします。JBoss の場合、これは、全体の <ServicePortal_Install_Dir> ディレクトリ(たとえば、C:¥CiscoServicePortal または C:¥newScale)です。WebSphere または WebLogic の場合、WebSphere または WebLogic 展開ディレクトリではなく、Service Portal ソフトウェアをインストールしたディレクトリをバックアップします。
実稼動環境でのアップグレードの実行準備ができている場合、この項をスキップします。
この項では、アップグレード プロセスの予行練習を実行するときに使用するサンドボックス環境を作成します。 アップグレード プロセスに問題がなく、予行練習中に収集した技術注記を準備したら、実際の実稼動システムでアップグレード手順を開始できます。
ステップ 1 実稼動データベース バックアップを別のデータベース セットに復元します。
(注) SQL Server 2005 データベースおよび Oracle 10g データベースはこのリリースではサポートされないので、データベース バックアップを新しい SQL Server 2008 R2 データベースまたは Oracle 11g データベースに復元する必要があります。
ステップ 2 Oracle DBMS を使用する場合、復元後に各データベースで統計情報の再コンパイルを実行することを推奨します。 この手順は、大規模なデータベースでのアップグレード プロセスのパフォーマンスを改善するために不可欠です。
ステップ 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=100
c. SQL Server をマルチユーザ モードに戻します。
ステップ 4 リリース 9.3.2 のサポートされているプラットフォームおよび前提条件のリストを参照します(「プラットフォーム サポート マトリクス」および「インストールおよび設定ガイド」を参照)。プラットフォームがサポートされていない場合、サンドボックス環境で、正しいバージョンのアプリケーション サーバ、Web サーバおよび JDK をサポートされているオペレーティング システムにインストールします。
ステップ 5 セットアップ プログラムを実行する前に、「インストールおよび設定ガイド」のすべての手順を実行します。セットアップ プログラムを実行する前に、スキーマまたはデータ関連問題がないかデータベースを検証し、問題がある場合は修復しておく必要があります。
これは、アップグレード プロセスでの必須手順です。 検証および修復 プログラムを実行して、リリース 9.3.2 をアップグレードできるようにデータベースを準備する必要があります。 検証および修復が正常に完了するまで、インストーラで既存のデータベースをアップグレードすることはできません。
ステップ 1 Service Portal ソフトウェアを Cisco Web サイトからダウンロードします。
ステップ 2 コマンド プロンプトで、<ServicePortal_Software_Dir>/Installer ディレクトリに移動します。
ステップ 3 次の表から適切なコマンドを入力して、Enter を押します。
|
|
ステップ 4 プロンプトが表示されたら、Java ホーム ディレクトリの位置を入力します。たとえば、「C:¥JDK1.6.0_23」を入力します。
ステップ 5 次に、Service Portal をインストールするインストール ディレクトリの位置を入力します。たとえば、「C:¥CiscoServicePortal」(Windows の場合)または「/opt/CiscoServicePortal」(UNIX/Linux の場合)を入力します。
ステップ 6 プロンプトに従い、アプリケーション サーバを選択し、データベース情報を入力して、アップグレードに使用されるデータベースに接続します。
ステップ 7 [Service Portal Database Validation] 画面が表示されます(図 4-1 を参照)。このプログラムは、オプションが次の順に実行されるように設計されています。
オプション 1 を実行せずにオプション 2 を実行することはできません。オプション 2 を実行せずにオプション 3 を実行することはできません。
各オプションは複数回実行できます。ただし、オプション 1([Perform Schema Validation])を実行するたびに、検証プロセスが最初から実行されるかのようにプログラムが再開します。たとえば、オプション 2 まで完了しているとします。ここでオプション 3 を実行できます。オプション 1 を再び実行することもできます。ただし、オプション 1 を実行するとシステムが再開されるので、オプション 1 の完了直後に、オプション 3 を実行することはできません。この場合、オプション 2 を実行する必要があります。
ステップ 1 オプション 1 [Perform Schema Validation] を選択します。
このオプションは、既存のスキーマの整合性を検証します。欠落している、または変更されたスキーマ オブジェクトがあれば報告されます。また、アプリケーション スキーマの一部として認識されないオブジェクトも報告されます。
• 欠落している、または変更されたオブジェクトには、[Validation Log Table] に [inform: pending repair] フラグが付けられます。これらのオブジェクトは、アップグレード プログラムにより自動的に修復されます。
• Service Portal テーブルを示す認識されないオブジェクトは、[inform: pending removal] ステータス フラグが付けられます。たとえば、存在する場合、a) Service Portal テーブルの認識されないインデックス、b) Service Portal テーブルの認識されないトリガー、c) Service Portal テーブルの認識されない制約、d) Service Portal テーブルを示す認識されない外部キー制約には、削除フラグが付けられます。これらのオブジェクトは、アップグレード プログラムにより自動的に削除されます。
• その他のタイプの Service Portal テーブルを示さない認識されないオブジェクトには、[inform] ステータス フラグが付けられます。たとえば、存在する場合、Service Portal テーブルを示さないテーブル、列、シーケンス、ストアド プロシージャ、関数、インデックスおよび制約は報告のみされます。これらのオブジェクトは報告のみされ、アップグレード プログラムにより残されます。
ステップ 2 スキーマ検証テストが正常に完了すると、プログラムにより、「Validation completed successfully with no errors」(を参照)というメッセージが表示されます。
a. オプション 2 [Perform Data Validation] を選択して、2 つめの検証テストを実行します。本書の「VII.データの検証」に進みます。
b. オプション 4 [Exit] を選択して、検証および修復プログラムを終了して、[Validation Log Table] を確認します。次の項に進みます。
すべてのスキーマ検証エラーを確認および修復してから、すべてのデータ検証エラーを確認および修復することを強く推奨します。このようにすることで、スキーマ検証エラーの修復とデータ検証エラーの修復が混在することによりリグレッション エラーの可能性を軽減できます。
すべての検証スクリプトの結果は、検証エラーがあるかどうかに関係なく、データベースの SchValidationLog というテーブルに保存されます。
ステップ 1 データベースにスキーマ所有者(つまり、RCUser)として接続し、テーブル SchValidationLog を参照して検証結果を確認します。SQL Analyzer(図 4-3 を参照)や SQL*Plus などのユーティリティを使用してデータベースに接続できます。
図 4-3 SchValidationLog テーブルの参照
ステップ 2 SchValidationLog テーブルを開いて内容を確認します(図 4-4 を参照)。
ステップ 3 SchValidationLog テーブルの ErrorLevel 列で次の値をチェックして、推奨されている操作を実行します。
ステップ 4 [SchValidationLog] テーブルには、たくさんのエントリが示されます。そのため、次の SQL コマンドを使用して、内容をフィルタリングできます。
SELECT * FROM SchValidationLog WHERE ErrorLevel='error'
アップグレード プロセスを進める前に手動で修復する必要がある検証エラーを確認する場合、WHERE 句 ErrorLevel='error' を含めます。[SchValidationLog] テーブルの他のエントリを参照する場合、WHERE 句を削除するか、値「error」を別の値に変更します(たとえば、「inform: auto-repairable」です。詳細については、 表 4-5 を参照してください)。
[SchValidationLog] テーブルの [RunType] 列を参照します。
• オプション 1([Perform Schema Validation])は RunType="Check Schema" でエントリを挿入します。
• オプション 2([Perform Data Validation])は RunType="Check Data" でエントリを挿入します。
• オプション 3([Repair Database])は、ErrorLevel="inform: auto-repairable" のすべてのエントリを ErrorLevel="inform: auto-repaired" に変更し、同時に RunType を "Fix Data" に変更します。
ステップ 5 ErrorLevel="error" の検証エントリをすべて手動で修復したら、検証および修復プログラムを再実行し、同じオプションを再び使用して、プログラムによりエラーが報告されるかどうか確認します。手動修復の結果として、新しい検証エラーが表示されることもあります。この場合、検証および修復プログラムの実行と検証エラーの修復という同じプロセスを繰り返し実行する必要があります。
ステップ 1 検証および修復プログラムが実行されていない場合は起動します。
ステップ 2 [Service Portal Database Validation] 画面が表示されたら(図 4-1 を参照)、オプション 2 [Perform Data Validation] を選択します。
データ検証テストが検証エラーを報告せずに完了すると、システムにより「Total Errors: 0」というメッセージが表示されます(図 4-5 を参照)。検証エラーは、手動で修復する必要があるエラーです。Auto-Repairable エラーは、検証および修復プログラムの [Repair Database] オプションにより自動的に修復されるエラーです。
データ検証によりデータエラーが検出されると、データ検証プロセスの完了時に、検証および修復プログラムにより、検出されたエラーの数が報告されます。
ステップ 3 検証エラーが検出されたことを示すメッセージが表示されたら、アップグレード プロセスを続行する前にこれらのエラーを手動で修復する必要があります。「VI.[Validation Log Table] の確認」に戻ります。検証がエラーなく正常に完了したことを示すメッセージが表示されたら、「VIII.データベースの修復」に進みます。
オプション 1 および 2 でエラーが報告されなくなったら、オプション 3 [Repair Database] を実行する必要があります。それ以外の場合、オプション 3 が実行されないため、インストール プログラムはアップグレードを続行できません。
ステップ 1 検証および修復プログラムが実行されていない場合は起動します。
ステップ 2 [Service Portal Database Validation] 画面が表示されたら(図 4-1 を参照)、オプション 3 [Repair Database] を選択します。
検証および修復プログラムにより、データベースが修復され、[Database Repaired] 画面(図 4-6 を参照)が表示されます。
ステップ 3 既存のデータベースを検証および修復したので、「IX.既存のインストールのアップグレード」の項に進み、インストーラを開始してアップグレード プロセスを完了します。
データベースを検証および修復したので、アップグレード プログラムに進みます。
ステップ 1 オペレーティング システムに該当するコマンドを入力して、セットアップ プログラムを開始します。
|
|
ステップ 2 Java ホーム ディレクトリの位置を入力します。たとえば、「C:¥JDK1.6.0_23」を入力します。
ステップ 3 [Installation Type] 画面が表示されたら、オプション 2 [Upgrade Existing Installation] を選択します。
ステップ 4 セットアップ プログラムにより、検証および修復プログラムを実行したかどうかを確認するメッセージが表示されます。データベースの検証に成功している場合、[Yes] を入力し、[Enter] を押して、処理を続けます。
ステップ 5 一連のインストーラ画面に対応します(詳細については「インストールおよび設定ガイド」を参照してください)。
ステップ 6 データベース情報を [Database Component Installation Options] 画面および [Datamart Database Component Installation Options] 画面(「インストールおよび設定ガイド」を参照)に入力すると、セットアップ プログラムにより、データベースとの接続が行われ、データベースが正常に検証されたかどうかがチェックされます。セットアップ プログラムにより、データベースが正常に検証されていないことが検出された場合(たとえば、検証および修復プログラムが実行されていない場合や、[SchValidationLog] テーブルに errorLevel= "errors" の未解決検証エラーが残っている場合)、データベースが正常に検証されていないことが通知され、実行が中断されます。
ステップ 7 セットアップ プログラムにより、データベースが正常に検証されたことが確認されると、次の [Installation Options] 画面が表示されます。この画面のオプションの値を完了し(「インストールおよび設定ガイド」を参照)、 C を入力し、 Enter を押して、処理を続けます。
ステップ 8 Advanced Reporting モジュールの場合、[Module selection] 画面で [Yes] を [Advanced Reporting] モジュールで選択し、[Component selection] 画面で [Yes] を [Data Mart Database Component] で選択する必要があります。このようにしない場合、RequestCenter データベースと Datamart データベース間でデータ競合が発生します。
(注) Catalog Installer モジュールは、Catalog Deployer モジュールの新しい機能に置き換わりました。Catalog Installer は、インストーラの [Module selection] メニューに選択肢として表示されません。Catalog Deployer は、常に Request Center の一部としてインストールされます。
(注) Advanced Reporting モジュールは、Reporting ソリューションのインストールの一部となりました。システムに Advanced Reporting がインストールされていない場合、[Form Data Reporting] パラメータが、上書き可能なシステム デフォルト値に設定されます。詳細については、「Advanced Reporting のアップグレード」を参照してください。
ステップ 9 セットアップ プログラムにより、アップグレード スクリプトが実行され、データベース スキーマおよびコンテンツが変更されます。アップグレード スクリプトの実行には、データベースのサイズに応じて、時間がかかる場合があります。アップグレード スクリプトによりスキーマおよびコンテンツが変更されたら、セットアップ プログラムにより、EAR および WAR ファイルが作成されます。( Advanced Reporting モジュールをインストールしている場合、セットアップ プログラムにより、 Datamart データベースのスキーマとコンテンツをアップグレードするスクリプトが実行されます)。
• JBoss アプリケーション サーバを使用する場合、セットアップ プログラムにより、新しい EAR および WAR ファイルが <ServicePortal_Install_Dir>¥jboss-4.2.3¥server ¥RequestCenter および ServiceLink フォルダに自動的に展開されます。
• WebSphere または WebLogic アプリケーション サーバを使用する場合、セットアップ プログラムにより、新しい RequestCenter.ear および ISEE.war ファイルが <ServicePortal_Install_Dir>¥dist フォルダに作成されます。「インストールおよび設定ガイド」で説明されている手順を実行して、Service Portal 製品の EAR および WAR ファイルを展開する必要があります。
ステップ 10 EAR および WAR ファイルの展開が終了し、アプリケーション サーバを起動できるようになると、アップグレード プロセスは実質的に完了です。これで、Service Portal アプリケーションがリリース 9.3.2 になりました。この時点で、必要に応じて、データベースおよびインストール ディレクトリのバックアップを作成できます。Oracle DBMS を使用する場合、システムのランタイム パフォーマンスを改善するため、アップグレードしたデータベースで統計情報の再コンパイルを再実行することを推奨します。
ステップ 1 必要な場合、セットアップ プログラムによりデータベースから削除されたカスタム データベース オブジェクトを再作成します。
ステップ 2 カスタム コードは、新しいバージョンの JDK に対応できなければなりません。
• Service Link カスタム アダプタは、リリース 9.3.2 バージョンに置き換えなければなりません。
• カスタマー サイトで開発されたカスタム アダプタおよび任意の Java コードは、新しい JDK を使用して再構築する必要があります。
• Request Center ポートレットに展開するエンタープライズ ポータルは、JDK バージョン 1.6 でなければなりません。
ステップ 3 データベースが Oracle の場合、Custom Adapter をインストールしてから次の手順を実行します。
a. RequestCenter データベースに接続し、次の SQL コマンドを実行します:UPDATE XtrProperty SET DefaultValue = ‘ ' WHERE DefaultValue IS NULL;
ステップ 4 Requisition API(RAPI)は廃止され、Requisition Web サービスに置き換えられました。既存の RAPI 統合を使用する場合、新しい Web サービスを使用して、再実装できるか評価する必要があります。
ステップ 5 [Service Import/Export] および [Service Offering Import/Export] は、以前のリリースとの後方互換性がありません。以前のリリースでエクスポートされたサービスまたは提供サービスは、リリース 9.3.2 にインポートできません。アップグレード前のコード リポジトリのサービスまたは提供サービス エクスポート ファイルを保守する場合、再エクスポートして、リリース 9.3.2 用にします。
ステップ 6 以前組織で使用した手順に従い、アプリケーションのすべてのカスタマイズを再実装します。
ステップ 7 Catalog Installer にアクセスしていたユーザの RBAC ロールを確認して、必要に応じて、Catalog Deployer へのアクセス権を付与します。
ステップ 8 リリース 2008.1 から使用できる Demand Center Agreement Notifications 機能のカスタム電子メール テンプレートを使用する場合、対応する電子メール テンプレートを識別して、テンプレート タイプを Administration モジュールの「DemandCenter」に設定する必要があります。
ステップ 9 Service Portal アプリケーションに管理者ユーザとして接続します。「Administration」モジュールに移動し、[Settings] タブをクリックします。[Customizations Settings] で、[Browser Cache] を探します(図 4-8 を参照)。
[Browser Cache] 設定の [Enabled] オプション ボタンを選択します。[Version] テキスト ボックスの右にある [+] ボタンをクリックします。クリックすると、[Version] の数値が 1 ずつ増加します。[Update] ボタンをクリックします。この設定により、Service Portal システムのアップグレード後にユーザが初めて Service Portal URL に接続するときにブラウザのキャッシュをクリアするよう通知されます。
次の項では、Advanced Reporting モジュールの Cognos コンポーネントのアップグレード手順について説明します。アップグレードの前の Service Portal システムに Advanced Reporting モジュールがインストールされていた場合、次の項に進み、Advanced Reporting モジュールがリリース 9.3.2 で機能するように、Cognos コンポーネントのアップグレード プロセスを完了する必要があります。
Advanced Reporting はこのリリースで大幅に改善され、IBM Cognos 8.4.1 Business Intelligence(BI)コンポーネントを使用できるようになりました。
(注) Cognos PowerPlay Cubes(以前のリリースでは Analytics モジュールを介して使用可能)は、リリース 9.3.2 ではサポートされなくなりました。Analytics モジュールは、このリリースでは使用できません。
ハイレベルでは、Upgrading Advanced Reporting に関連する手順は次のとおりです。
• 現在のバージョンの Service Portal システムを立ち上げ稼動中に、Advanced Reporting のアップグレード前の作業を実行します。
• 「Service Portal のアップグレード」で説明されている Service Portal アップグレードを正常に完了した後で Advanced Reporting 設定スクリプトを実行します。
アップグレード前のシステムを立ち上げ実行中に、次に示す作業を実行します。また、「I.概要」に示されているアップグレード前に作業も実行します。これは、セットアップ プログラムを実行すると、RequestCenter データベースと Datamart データベースの両方がアップグレードされるので重要です。
データ マートおよびコンテンツ ストア アーティファクトをバックアップするには:
ステップ 1 Datamart データベース(カスタム Datamart テーブルがある場合、このバックアップから参照できます)および ContentStore データベースをバックアップします。
ステップ 2 RequestCenter から Advanced Reporting により使用されるすべてのカスタム定義ビューをバックアップします。
ステップ 3 C:¥¥CiscoServicePortal¥cognos¥config¥Datamart¥RequestCenter_windows.ctg にあるカタログ ファイル「RequestCenter_windows.ctg」をバックアップします。
ステップ 4 C:¥¥CiscoServicePortal¥cognos¥Reports¥Report Data Model にある標準レポーティング パッケージ フォルダをバックアップします。
(注) データベース バックアップは安全のためです。RequestCenter_windows.ctg および Report Data Model フォルダ バックアップは、以前のリリースで作成したカスタマイズを最適用するときに参照されます。
次の手順を実行して、すべての Cognos 8.4 コンポーネントをアンインストールします。
ステップ 1 オペレーティング システムの [Start] ボタンから、[Programs] > [IBM Cognos8] > [Uninstall IBM Cognos8] > [Uninstall IBM Cognos8] を選択します。
ステップ 2 表示言語を選択して、[Next] をクリックします。
ステップ 3 パッケージ リストからすべてのコンポーネントを選択して、[Finish] 画面に移動するまで、インストール ウィザードを進めます。
ステップ 4 すべてのコンポーネントが正常にアンインストールされたら、システムをリブートします。
Advanced Reporting でのアップグレード前の作業を完了したので、他のアップグレード前の作業を実行します。ここでは、「Service Portal のアップグレード」で説明されているように、Service Portal で検証、修復およびアップグレード プロセスを実行します。
Advanced Reporting に固有なアップグレード プロセス中に注意すべきことは 2 つあります。
ステップ 1 セットアップ プログラムを実行するとき、以前に Advanced Reporting をインストールしていない場合、または Data Mart Meta Data テーブルが Datamart データベースにない場合、デフォルト値が Meta Data テーブルで使用されるか確認するプロンプトが表示されます。
図 4-9 Meta Data テーブルでのデフォルト値の確認
メタ データがないためにデータベース問題の疑いがある場合、[No] を選択して、検証プログラムを終了し、Data Mart データベースをチェックします。それ以外の場合、[Yes] を選択します。デフォルトの Advanced Reporting インストール オプションが表示されます。
図 4-10 Advanced Reporting インストール オプション
ここで作成されるオブジェクトは、Advanced Reporting モジュールの [Form Data Reporting] 機能で使用されます。この機能の詳細については、「Advanced Reporting について」を参照してください。必要な場合、新しい値を入力してデフォルト値を上書きできます。 C を入力して、値を適用し、処理を続けます。
ステップ 2 セットアップ プログラムを使用して既存のインストールをアップグレードする場合、すべての Advanced Reporting 関連オブジェクトおよび Data Mart スキーマがリリース 9.3.2 にアップグレードされるように、[Upgrade Existing Installation] オプションを選択した後で、「Advanced Reporting」モジュールに対して [Yes] を選択する必要があります。セットアップ プログラムにより、新しい「cognosinstaller.zip」ファイルが生成されます。このファイルは次の手順を使用します。
「III.アップグレード環境の準備」に戻り、Service Portal アップグレードを実行します。
この項は、「Service Portal のアップグレード」で説明されている Service Portal アップグレードを完了している場合だけ行ってください。この章の残りの手順を実行すると、Cognos のインストールおよび設定が完了します。その後、使用したアップグレード パスに適切なアップグレード後の作業を実行します。
Cognos 8.4.1 のインストール方法の詳細については、「Cognos ソフトウェアのインストール」を参照してください。
Cognos を初めてインストールする場合、または Cognos のバージョンがあるリリースからアップグレードする場合、新しいインストールの場合に実行するように、Advanced Reporting を設定するすべての手順を実行する必要があります。
「Reporting および Advanced Reporting コンポーネントの設定」を参照して、そこで説明されているすべての手順を実行します。
Cognos 8.4.1 の Reports フォルダのデフォルト表示は、リスト形式で、ページに 3 項目ずつ表示されます。これは、詳細形式である ReportNet のデフォルト表示とは異なります。前のバージョンの Service Portal で個々の環境設定をユーザが設定している場合、これらの環境設定は保持されません。レポート ユーザは、最初に Reports モジュールを使用するときに基本設定を設定および保存します。
Analytics モジュールを削除すると、ロールが「Service Operations Analyst」または「Service Strategy and Design Analyst」のみのユーザは、Advanced Reporting モジュールにアクセスできなくなります。これらの RBAC ロールは、新しいロールを追加できるか評価される必要があります。
新しいリリースで導入された機能を使用して、以前設定したスケジュール済みジョブを確認し、必要に応じて、バッチ スクリプトおよび実行頻度を変更することを推奨します。Service Portal インストール ディレクトリの newscale.properties ファイルにある、Form Data Reporting でカスタマイズした ETL 設定は、アップグレード プロセスで保持されないので、復元する必要があります。