Cisco Service Portal インストレーション ガイド リリース 9.3.2
アップグレードについて
アップグレードについて
発行日;2012/07/18 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 3MB) | フィードバック

目次

アップグレードについて

概要

対象読者

Service Portal のアップグレード

概要

リリース アップグレード パス

制限事項と注意事項

アップグレードされるオブジェクト

アップグレードされないオブジェクト

前提条件とベスト プラクティス

前提条件

ハイレベルなアップグレード方法

Service Portal 9.3.2 へのアップグレード

I.概要

II.アップグレード前の作業の実行

III.アップグレード環境の準備

IV.検証および修復プログラムの実行

V.スキーマの検証

VI.[Validation Log Table] の確認

VII.データの検証

VIII.データベースの修復

IX.既存のインストールのアップグレード

X.アップグレード後の作業の実行

Advanced Reporting のアップグレード

概要

Advanced Reporting でのアップグレード前の作業の実行

データ マートおよびコンテンツ ストア アーティファクトのバックアップ

Cognos 8.4 のアンインストール コンポーネント

検証およびアップグレード プロセスの実行

Cognos インストール

Cognos 8.4.1 のインストール

Advanced Reporting コンポーネントの設定

Advanced Reporting でのアップグレード後の作業の実行

Reporting 環境設定の設定

Analytics User ロールの再設定

スケジュール済みジョブの設定

概要

この章では、Cisco Service Portal Release 2008.3 以上 から Release 9.3 .2 へのアプリケーション アップグレードを実行する方法について説明します。

対象読者

この章は、次のスキルを有する上級管理者を対象としています。

RDBMS の高度な知識と経験

環境のカスタマイズ分野の知識

Service Portal のアップグレード

概要

リリース アップグレード パス

このアップグレード プロセスでは、Service Portal Release 2008.3 SP9 以上 から Release 9.3.2 への直接データベース コンポーネント アップグレードをサポートします。次の 表 4-1 に示されている、最新のサービス パックのデータベース インストーラ プログラムは、データベース スキーマをサポートされているアップグレード レベルにするデータベースに対して実行する必要があります。

 

表 4-1 直接アップグレード パス

アップグレード前のリリース バージョン
アップグレード後のリリース バージョン

2008.3 SP9

9.3.2

9.1 SP3

9.3.2

9.2(限定リリース)

9.3.2

9.3 GA

9.3.2

9.3 R2

9.3.2

9.3.1

9.3.2

既存のインストールが 2008.3 SP9 よりも前のバージョンの場合、サポートされているバージョンにアップグレードする必要があります。場合によっては、複数のバックツーバック データベース コンポーネント アップグレードを実行する必要があります。

 

表 4-2 マルチステップのアップグレード パス

アップグレード前のリリース バージョン
ステップ 1:アップグレード後のリリース バージョン
ステップ 2:アップグレード後のリリース バージョン
ステップ 3:アップグレード後のリリース バージョン

2006.0.7、2006.0.8、2006.0.9

2008.3

2008.3 SP9

9.3.2

2007.1(任意の SP)

2008.3

2008.3 SP9

9.3.2

2008.1(任意の SP)

2008.3

2008.3 SP9

9.3.2

2008.3(SP9 よりも前の任意の SP)

2008.3 SP9

9.3.2

該当なし

9.1(SP3 よりも前の任意の SP)

9.1 SP3

9.3.2

該当なし

制限事項と注意事項

ここでは、製品の制限事項に関する通知や、このバージョンにアップグレードする際に考慮する必要がある重要な注意事項を記載しています。

新しいプラットフォーム サポート

このリリースでは、新しいプラットフォーム サポートがあります。 表 4-3 を参照して、サードパーティ ソフトウェアの新しいバージョンをインストールする必要があるか確認してください。

表 4-3 新しいプラットフォーム サポート

プラットフォーム
このリリースで新しくサポートされるバージョン
このリリースでサポートされないバージョン

IBM WebSphere Application Server

IBM WebSphere 7.0

IBM WebSphere 6.1

IBM Http Server

IBM Http Server 7.0

IBM Http Server 6.1

Microsoft IIS

IIS 7.5

IIS 6

Microsoft Windows
オペレーティング システム

Windows Server 2008 R2

Windows Server 2003

Linux オペレーティング システム

Red Hat Enterprise Linux 5.6

Red Hat Linux AS/ES 4

AIX オペレーティング システム

IBM AIX 7.1

IBM AIX 5.3

Microsoft IIS

IIS 7.5

IIS 6

Microsoft Internet Explorer

IE 8

IE 6

Microsoft SQL Server

SQL Server 2008 R2

SQL Server 2005

Oracle RDBMS

Oracle 11g

Oracle 10g

Microsoft Active Directory Server

Active Directory Server 2008

Active Directory Server 2003

詳細については、「プラットフォーム サポート マトリクス」を参照してください。

デフォルト スタイルシートの変更

このリリースでは、Service Portal のデフォルト スタイルが変更され、異なるテーマ カラーおよびフォントを使用するようになりました。これらの変更を実装するかどうかは任意です。アプリケーションで現在使用しているスタイルを使用する場合、このリリースへのアップグレード後に既存の custom.css および common.css を再適用して、変更を上書きできます。common.css ファイルは、RequestCenter.war¥refactor¥common¥css フォルダにあります。

BusinessEngine.ear の削除

このリリースではアプリケーション アーキテクチャが変更され、Business Engine は Request Center から独立したアプリケーションではなくなりました。BusinessEngine.jar、be.properties、および bejms.properties ファイルは、現在 RequestCenter.ear 内にあります。インストールおよびアップグレード プロセス中に、インストール プログラムによって RequestCenter.ear および ISEE.war だけが生成されます。詳細については、「インストールおよび設定ガイド」を参照してください。

Enterprise JavaBeans(EJB)の削除

このリリースにおけるアプリケーション アーキテクチャの改善の一環として、Request enter および Business Engine の上にあった EJB レイヤが削除されています。これらの変更によるアプリケーション インストールおよび設定手順への影響はありません。

Service Link からの Business Engine インバウンド メッセージのための新しい JMS キュー

Service Link のスケーラビリティを改善するため、インバウンド Service Link メッセージによって呼び出されたすべての Business Engine API コールは、直接 Business Engine に渡されるのではなく、JMS キューにルーティングされるようになりました。詳細については、「インストールおよび設定ガイド」を参照してください。

Service Import/Export は下位互換なし

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 インストールの場合、アップグレードの前に、カスタム フルテキスト カタログをデータベースからドロップします。

Oracle catcio.sql パッケージ。

次の 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 9.3.2 へのアップグレード

I.概要

このリリースでの 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 のアップグレードの作業内容:

現在のバージョンのアプリケーションを立ち上げ実行しながら、アップグレード前の作業を実行します

Service Portal Release 9.3.2 インストールの新しくサポートされるプラットフォーム条件および前提条件を満たすサンドボックス環境を準備します

アップグレード前のデータベースの整合性を検証し、検出されたスキーマまたはデータ問題を修復します

Service Portal セットアップ プログラムをアップグレード モードで実行します

アップグレード後の作業を実行します

II.アップグレード前の作業の実行

実稼動環境で、次に示すアップグレード前の必須作業を実行します。


ステップ 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 ソフトウェアをインストールしたディレクトリをバックアップします。


 

III.アップグレード環境の準備

実稼動環境でのアップグレードの実行準備ができている場合、この項をスキップします。

この項では、アップグレード プロセスの予行練習を実行するときに使用するサンドボックス環境を作成します。 アップグレード プロセスに問題がなく、予行練習中に収集した技術注記を準備したら、実際の実稼動システムでアップグレード手順を開始できます。

サンドボックス環境を準備するには:


ステップ 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

GO

ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL=100

GO

c. SQL Server をマルチユーザ モードに戻します。

ステップ 4 リリース 9.3.2 のサポートされているプラットフォームおよび前提条件のリストを参照します(「プラットフォーム サポート マトリクス」および「インストールおよび設定ガイド」を参照)。プラットフォームがサポートされていない場合、サンドボックス環境で、正しいバージョンのアプリケーション サーバ、Web サーバおよび JDK をサポートされているオペレーティング システムにインストールします。

ステップ 5 セットアップ プログラムを実行する前に、「インストールおよび設定ガイド」のすべての手順を実行します。セットアップ プログラムを実行する前に、スキーマまたはデータ関連問題がないかデータベースを検証し、問題がある場合は修復しておく必要があります。


 

IV.検証および修復プログラムの実行

これは、アップグレード プロセスでの必須手順です。  検証および修復 プログラムを実行して、リリース 9.3.2 をアップグレードできるようにデータベースを準備する必要があります。 検証および修復が正常に完了するまで、インストーラで既存のデータベースをアップグレードすることはできません。

検証および修復プログラムを実行するには:


ステップ 1 Service Portal ソフトウェアを Cisco Web サイトからダウンロードします。

ステップ 2 コマンド プロンプトで、<ServicePortal_Software_Dir>/Installer ディレクトリに移動します。

ステップ 3 次の表から適切なコマンドを入力して、Enter を押します。

 

表 4-4 検証および修復プログラムの実行

オペレーティング システム
コマンド

UNIX/ Linux

./validate.sh

Windows

validate.bat

ステップ 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. Perform Schema Validation

2. Perform Data Validation

3. Repair Database

オプション 1 を実行せずにオプション 2 を実行することはできません。オプション 2 を実行せずにオプション 3 を実行することはできません。

各オプションは複数回実行できます。ただし、オプション 1([Perform Schema Validation])を実行するたびに、検証プロセスが最初から実行されるかのようにプログラムが再開します。たとえば、オプション 2 まで完了しているとします。ここでオプション 3 を実行できます。オプション 1 を再び実行することもできます。ただし、オプション 1 を実行するとシステムが再開されるので、オプション 1 の完了直後に、オプション 3 を実行することはできません。この場合、オプション 2 を実行する必要があります。

図 4-1 検証および修復画面

 


 

V.スキーマの検証


ステップ 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」(を参照)というメッセージが表示されます。

図 4-2 スキーマ検証の完了

 

 

この時点で、次のいずれかを実行できます。

a. オプション 2 [Perform Data Validation] を選択して、2 つめの検証テストを実行します。本書の「VII.データの検証」に進みます。

または

b. オプション 4 [Exit] を選択して、検証および修復プログラムを終了して、[Validation Log Table] を確認します。次の項に進みます。


 

VI.[Validation Log Table] の確認

すべてのスキーマ検証エラーを確認および修復してから、すべてのデータ検証エラーを確認および修復することを強く推奨します。このようにすることで、スキーマ検証エラーの修復とデータ検証エラーの修復が混在することによりリグレッション エラーの可能性を軽減できます。

すべての検証スクリプトの結果は、検証エラーがあるかどうかに関係なく、データベースの SchValidationLog というテーブルに保存されます。


ステップ 1 データベースにスキーマ所有者(つまり、RCUser)として接続し、テーブル SchValidationLog を参照して検証結果を確認します。SQL Analyzer(図 4-3 を参照)や SQL*Plus などのユーティリティを使用してデータベースに接続できます。

図 4-3 SchValidationLog テーブルの参照

 

ステップ 2 SchValidationLog テーブルを開いて内容を確認します(図 4-4 を参照)。

図 4-4 SchValidationLog の内容

 

ステップ 3 SchValidationLog テーブルの ErrorLevel 列で次の値をチェックして、推奨されている操作を実行します。

 

表 4-5 検証エラー レベル

ErrorLevel
説明

inform

検証テストは、異常終了しました。これは、アップグレード プログラムおよびアプリケーションに悪影響を及ぼします。たとえば、アプリケーション プログラムにより、データベース スキーマに属さないテーブルが検出されました。このテーブルが存在することで、アップグレード プログラムは失敗するか、アプリケーションに悪影響を及ぼします。

ErrorLevel が [inform] のすべての検証エントリは、アップグレード プログラムで無視されます。これらのエントリに対処するためのユーザによる操作は不要です。

inform: auto-repairable

データ検証テストがデータ エラーにより終了しました。これは、アップグレード プログラムに悪影響を及ぼします。ただし、このタイプのエラーは、検証および修復プログラムの [Repair Database] オプションにより安全かつ自動的に修復できます。

このタイプのほとんどのエラーは、内部不一致が原因です。これは、以前のアップグレードまたはインポート ユーティリティにより発生したと考えられます。修復するには、通常、参照およびデータ整合性を復元します。

SchValidationLog テーブルの RepairScript 列には、エラー修復に使用される SQL ステートメントが示されます。ユーザによる操作は不要です。

inform: auto-repaired

検証および修復プログラムの [Repair Database] オプションは、上記の inform: auto-repairable として報告されたエラーを修復するために、 RepairScript 列で説明されている SQL ステートメントを実行します。

ユーザによる操作は不要です。

inform: pending-repair

検証テストは、異常終了しました。これは、アプリケーションに悪影響を及ぼしますが、アップグレード プログラムにより後で自動的に修復されます。

このタイプの異常終了の例には、インデックスの混在またはプライマリ キー制約の欠落があります。アップグレード プログラムを後で実行すると、欠落しているインデックスまたはプライマリ キー制約は正しく作成されます(存在しない場合)。

ユーザによる操作は不要です。

inform: pending removal

検証テストは、Service Portal テーブルを示す認識されないデータベース オブジェクトを検出しました。このオブジェクトが存在すると、アップグレード プログラムが正常に完了しないことがあります。そのため、アップグレード プログラムは、実行すると、検証および修復プログラムにより「pending removal」フラグが付けられたすべてのオブジェクトを削除しようとします。

ユーザによる操作は不要です。

error

検証テストは、ハード「エラー」で終了しました。これは、アップグレード プログラムにより自動的に修復できません。通常、このタイプのエラーは、欠落行や重複エントリなど、不正なデータ関係に関連します。

[TestType] 列は、エラーのタイプを示し、[TestDetail] 列は、検証テストに使用された SQL ステートメントを示します。この SQL ステートメントは、エラーに関するいくつかのヒントを示します。このエラーにより、後でアップグレード プログラムが失敗します。そのため、このようなエラーが検証および修復プログラムで検出されると、セットアップ プログラムでは、アップグレード プログラムを続行できなくなります。

アプリケーション管理者またはデータベース管理者は、このタイプのすべてのエラーを手動で修復し、エラーが報告されなくなるまで、検証および修復プログラムを実行する必要があります。

検証エラーの修復方法については、Cisco Technical Assistance Center(TAC)にお問い合わせください。場合によっては、[RepairScript] 列に、エラー修復に使用できる推奨 SQL ステートメントが示されます。アプリケーション管理者または DBA と協力して、このような修復スクリプトが実際のエラー修復に使用できるか確認してください。

各検証エラーがどのように修復されるかを簡潔に説明します。別の環境でアップグレード手順を繰り返す必要がある場合、メモを取っておく必要があります。

ステップ 4 [SchValidationLog] テーブルには、たくさんのエントリが示されます。そのため、次の SQL コマンドを使用して、内容をフィルタリングできます。

SELECT * FROM SchValidationLog WHERE ErrorLevel='error'

AND RunType='Check Data';

アップグレード プロセスを進める前に手動で修復する必要がある検証エラーを確認する場合、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" の検証エントリをすべて手動で修復したら、検証および修復プログラムを再実行し、同じオプションを再び使用して、プログラムによりエラーが報告されるかどうか確認します。手動修復の結果として、新しい検証エラーが表示されることもあります。この場合、検証および修復プログラムの実行と検証エラーの修復という同じプロセスを繰り返し実行する必要があります。


 

VII.データの検証


ステップ 1 検証および修復プログラムが実行されていない場合は起動します。

ステップ 2 [Service Portal Database Validation] 画面が表示されたら(図 4-1 を参照)、オプション 2 [Perform Data Validation] を選択します。

データ検証テストが検証エラーを報告せずに完了すると、システムにより「Total Errors: 0」というメッセージが表示されます(図 4-5 を参照)。検証エラーは、手動で修復する必要があるエラーです。Auto-Repairable エラーは、検証および修復プログラムの [Repair Database] オプションにより自動的に修復されるエラーです。

データ検証によりデータエラーが検出されると、データ検証プロセスの完了時に、検証および修復プログラムにより、検出されたエラーの数が報告されます。

図 4-5 データ検証の完了

 

ステップ 3 検証エラーが検出されたことを示すメッセージが表示されたら、アップグレード プロセスを続行する前にこれらのエラーを手動で修復する必要があります。「VI.[Validation Log Table] の確認」に戻ります。検証がエラーなく正常に完了したことを示すメッセージが表示されたら、「VIII.データベースの修復」に進みます。


 

VIII.データベースの修復

オプション 1 および 2 でエラーが報告されなくなったら、オプション 3 [Repair Database] を実行する必要があります。それ以外の場合、オプション 3 が実行されないため、インストール プログラムはアップグレードを続行できません。

データベースを修復するには:


ステップ 1 検証および修復プログラムが実行されていない場合は起動します。

ステップ 2 [Service Portal Database Validation] 画面が表示されたら(図 4-1 を参照)、オプション 3 [Repair Database] を選択します。

検証および修復プログラムにより、データベースが修復され、[Database Repaired] 画面(図 4-6 を参照)が表示されます。

図 4-6 データベース修復の完了

 

ステップ 3 既存のデータベースを検証および修復したので、「IX.既存のインストールのアップグレード」の項に進み、インストーラを開始してアップグレード プロセスを完了します。


 

IX.既存のインストールのアップグレード

データベースを検証および修復したので、アップグレード プログラムに進みます。


ステップ 1 オペレーティング システムに該当するコマンドを入力して、セットアップ プログラムを開始します。

 

表 4-6 アップグレード プログラムの実行

オペレーティング システム
コマンド

UNIX/ Linux

./setup.sh

Windows

Setup.bat

ステップ 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 を使用する場合、システムのランタイム パフォーマンスを改善するため、アップグレードしたデータベースで統計情報の再コンパイルを再実行することを推奨します。


 

X.アップグレード後の作業の実行


ステップ 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」に設定する必要があります。

図 4-7 電子メール テンプレートの設定

 

ステップ 9 Service Portal アプリケーションに管理者ユーザとして接続します。「Administration」モジュールに移動し、[Settings] タブをクリックします。[Customizations Settings] で、[Browser Cache] を探します(図 4-8 を参照)。

図 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 のアップグレード

概要

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 設定スクリプトを実行します。

Advanced Reporting でのアップグレード後の作業を実行します。

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 のアンインストール コンポーネント

次の手順を実行して、すべての 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 アップグレードを実行します。

Cognos インストール

この項は、「Service Portal のアップグレード」で説明されている Service Portal アップグレードを完了している場合だけ行ってください。この章の残りの手順を実行すると、Cognos のインストールおよび設定が完了します。その後、使用したアップグレード パスに適切なアップグレード後の作業を実行します。

Cognos 8.4.1 のインストール

Cognos 8.4.1 のインストール方法の詳細については、「Cognos ソフトウェアのインストール」を参照してください。

Advanced Reporting コンポーネントの設定

Cognos を初めてインストールする場合、または Cognos のバージョンがあるリリースからアップグレードする場合、新しいインストールの場合に実行するように、Advanced Reporting を設定するすべての手順を実行する必要があります。

「Reporting および Advanced Reporting コンポーネントの設定」を参照して、そこで説明されているすべての手順を実行します。

Advanced Reporting でのアップグレード後の作業の実行

Reporting 環境設定の設定

Cognos 8.4.1 の Reports フォルダのデフォルト表示は、リスト形式で、ページに 3 項目ずつ表示されます。これは、詳細形式である ReportNet のデフォルト表示とは異なります。前のバージョンの Service Portal で個々の環境設定をユーザが設定している場合、これらの環境設定は保持されません。レポート ユーザは、最初に Reports モジュールを使用するときに基本設定を設定および保存します。

Analytics User ロールの再設定

Analytics モジュールを削除すると、ロールが「Service Operations Analyst」または「Service Strategy and Design Analyst」のみのユーザは、Advanced Reporting モジュールにアクセスできなくなります。これらの RBAC ロールは、新しいロールを追加できるか評価される必要があります。

スケジュール済みジョブの設定

新しいリリースで導入された機能を使用して、以前設定したスケジュール済みジョブを確認し、必要に応じて、バッチ スクリプトおよび実行頻度を変更することを推奨します。Service Portal インストール ディレクトリの newscale.properties ファイルにある、Form Data Reporting でカスタマイズした ETL 設定は、アップグレード プロセスで保持されないので、復元する必要があります。