8 テストから本番

テスト環境から本番環境に移動するには、Oracle Fusion Middleware Oracle Fusion Middlewareの管理ガイドにある「テストから本番環境への移動」の章に示された手順に従ってください。

次に2つの例を示します。

• テストから本番へ(完全)

• テストから本番へ(増分)

表8-1 テストから本番へのユースケース

ユースケースID	シノプシス	事前条件/ 説明	詳細手順	事後条件
テストから本番へ(完全)	管理者は、必要なREPORTSおよびバックエンド・コンポーネントを含んだ完全なREPORTSドメインをテスト環境に作成します。 アプリケーションをテストした後、設定全体を本番環境に複製する必要があります	テスト環境で、ユーザーは次を実行済です。 WLSをインストールしました Forms and Reportsインストールをインストールしました WLS構成ウィザードを実行してReportsドメインを作成しました Reportsコンポーネントのインスタンスを構成/チューニングし、異なるDBなどに接続しました。 Reportsにスキーマはありませんが、WLS 12cインストールにはRCUスキーマを作成する必要があります。 本番環境 T2Pスクリプトを使用してcopyBinary / pasteBinaryを複製します。 copyConfig / extractMovePlan / pasteConfigを使用してドメイン構成をコピーします。 https://docs.oracle.com/middleware/1213/core/ASADM/testprod.htm#ASADM339	後述の説明を参照してください	本番環境はテスト環境でのすべての変更を含み正常に動作しています
テストから本番へ(増分)	管理者は、有効な本番REPORTS設定を持っており、アプリケーション/構成を本番ネットワークにローリングする前にその変更内容をテストする必要があります	本番環境が存在します テスト環境には、本番環境へのローリングが必要ないくつかのパッチ / 構成変更があります。	後述の説明を参照してください	本番環境はすべての増分変更を含み正常に動作しています

前述のケースの場合、何が自動移行されるかと、必要な場合の手動手順を次の表で検索してください。

一部の手順にはマークが付けられ[オプション]、関連する機能、たとえばReportsプラグインが使用される場合にのみ適用できます。.本番環境で、次を実行します。

ドメイン・ホーム内のアーティファクトはpasteConfigスクリプトにより自動的に移行されることに注意してください。しかし、ユーザーがドメイン・ホーム外にアーティファクトを持っている場合(たとえばファイル・システムのどこかで使用されているフォント)、手動で移行する必要があります

表8-2 テストから本番へ(完全)

順序番号	テスト- 本番移行領域	自動/ 手動	コメント/ 手順
1	作成されたReportsコンポーネント・インスタンス	自動	自動移行済。Reports Server/Tools/Bridgeコンポーネント・インスタンス
2	Reports構成	自動	自動移行済。Reports Server/Tools/Bridge / J2EEアプリケーション構成。レポートWeb公開ガイドの章Oracle Reports Servicesの構成を参照してください
3	Reports関連リソースの設定	自動	自動移行済。フォント / プリンタ構成 /CUPSプリンタ構成 フォント: DomainHome外にある場合、テスト環境で使用するすべてのフォントを環境変数REPORTS_FONT_DIRECTORYで指定されたディレクトリ(デフォルトは${DOMAIN_HOME}/reports/fonts)から本番環境にコピーします。
4	レポート定義ファイルおよびデータ表	手動	- テスト環境で使用されるレポート・ファイル(RDF、JSP、REP、XMLなど)を本番環境にコピーします。 - JSP Webレポートの場合、JSPレポートを次の場所にある本番環境レポート管理対象サーバーにデプロイします ${DOMAIN_HOME}/servers/WLS_REPORTS/tmp/_WL_user/reports_<version>/<dirName>/war/ - RDFファイル内で参照されているReports固有のデータ表を、DBデータ移行ツールを使用して本番環境のDBに移行します
5	ファイル・システム内のReportsジョブ関連構成	自動	自動移行済 - ファイル・システム内のReportサーバー・キャッシュ済ジョブ・ファイル、Reportsスケジュール済ジョブ情報 注意: レポートのスケジュール時にレポート名、出力名などに絶対パス名が使用されている場合、本番環境でパス名が有効でない可能性があります。このような場合、ユーザーは本番環境でReports ServletまたはReportsコマンドライン(rwclientユーティリティ)を使用してレポートを再スケジュールする必要があります。
6	データベース内のReportsジョブ関連構成[オプション]	手動	ジョブ・リポジトリまたはジョブ・ステータス・リポジトリ構成(あるいはその両方)がReports Serverのデータベース内に構成されている場合 同じスキーマをスクリプトORACLE_HOME/reports/admin/sql/rw_job_repos.sqlを使用してDB内に作成する必要があります スキーマRW_JOBS、RW_SERVER_JOB_QUEUEおよびRW_SERVER_QUEUEの元のDB内にデータがある場合、DBデータ移行ツールを使用して新しいDBに移行します。
7	Reports OPSSセキュリティ関連構成	自動	自動移行済 ユーザーおよびレポート・サーバーのセキュリティ・ポリシー情報、ロール / メンバーシップ / ポリシー 資格証明ストア機能(CSF)のエントリ
8	OIDの再関連付け	手動	OIDがSSOCONN RADエントリに関して使用されている場合、OIDデータ移行ツールを使用してテストOIDから本番OIDに移行する必要があります。 ReportsはWLSTコマンドを使用して新しいOIDに再関連付けする必要があります
9	DBプロキシ・ユーザー	手動	DBクローニング・ツールを使用してすべてのDBプロキシ・ユーザーを本番DBに移行します
10	Reportsプラグインの宛先、データ・ソース[オプション]	手動	Reportsプラグインが登録されている場合、対応するjarファイルを本番環境にコピーする必要もあります。 これらのファイルへのパスを本番環境のREPORTS_CLASSPATH環境変数に追加する必要もあります

ファイル内での構成変更の複製の場合、OracleHome、DomainHome、Port番号およびその他の変数に対する参照を含んでいるためファイルをテストから本番にコピーするのみで済まない可能性があることに注意してください。このため、ユーザーは、変更の複製のためにEM/ EM MBeanブラウザ /JConsoleまたは手動編集を使用する必要があります。

• 新しいレポートが設定内の新しいフォントを使用して作成されている場合、フォントとプリンタの設定の手順に従って、新しいフォントとレポートを順次本番環境にコピーできます

• 新しいCSFキーがDBパスワード用に作成されている場合、「Reportsセキュリティ関連の変更」の手順に従って順次新しいCSFキーを追加できます

表8-3 テストから本番へ(増分)

順序番号	テスト- 本番移行領域	自動/ 手動	コメント/ 手順
1	作成されたReportsコンポーネント・インスタンス	手動	WLSTコマンドを使用してReports Server/Tools/Bridgeコンポーネント・インスタンスを作成します
2	Reports構成	手動	Reports Server/Tools/Bridge / J2EEアプリケーション構成をマージします。構成ファイルの一覧は、Oracle Reports Servicesの構成のレポートWeb公開ガイドの章を参照してください
3	Reports関連リソースの設定	手動	フォント / プリンタ構成 /CUPSプリンタ構成をマージします フォント: テスト環境で使用するすべてのフォントを環境変数REPORTS_FONT_DIRECTORYで指定されたディレクトリ(デフォルトは${DOMAIN_HOME}/reports/fonts)から本番環境にコピーします。
4	レポート定義ファイルおよびデータ表	手動	テスト環境で使用されるレポート・ファイル(RDF、JSP、REP、XMLなど)を本番環境にコピーします。 JSP Webレポートの場合、JSPレポートを次の場所にある本番環境レポート管理対象サーバーにデプロイします ${DOMAIN_HOME}/servers/WLS_REPORTS/tmp/_WL_user/reports_<version>/<dirName>/war/ RDFファイル内で参照されているReports固有のデータ表を、DBデータ移行ツールを使用して本番環境のDBに移行します。
5	ファイル・システム内のReportsジョブ関連構成	手動	コピー ファイル・システム内のReportサーバー・キャッシュ済ジョブ・ファイル、Reportsスケジュール済ジョブ情報 注意: レポートのスケジュール時にレポート名、出力名などに絶対パス名が使用されている場合、本番環境でパス名が有効でない可能性があります。このような場合、ユーザーは本番環境でReports ServletまたはReportsコマンドライン(rwclientユーティリティ)を使用してレポートを再スケジュールする必要があります。
6	データベース内のReportsジョブ関連構成[オプション]	手動	ジョブ・リポジトリまたはジョブ・ステータス・リポジトリ構成(あるいはその両方)がReports Serverのデータベース内に構成されている場合 同じスキーマをスクリプトORACLE_HOME/reports/admin/sql/rw_job_repos.sqlを使用してDB内に作成する必要があります スキーマRW_JOBS、RW_SERVER_JOB_QUEUEおよびRW_SERVER_QUEUEの元のDB内にデータがある場合、DBデータ移行ツールを使用して新しいDBに移行します。
7	Reports OPSSセキュリティ関連構成	手動	OPSSコマンドmigrateSecurityStoreを使用して移行します ユーザーおよびレポート・サーバーのセキュリティ・ポリシー情報、ロール / メンバーシップ / ポリシー 資格証明ストア機能(CSF)のエントリ
8	OIDの再関連付け	手動	OIDがSSOCONN RADエントリに関して使用されている場合、OIDデータ移行ツールを使用してテストOIDから本番OIDに移行する必要があります。 ReportsはWLSTコマンドを使用して新しいOIDに再関連付けする必要があります
9	DBプロキシ・ユーザー	手動	DBクローニング・ツールを使用してすべてのDBプロキシ・ユーザーを本番DBに移行します
10	Reportsプラグインの宛先、データ・ソース[オプション]	手動	Reportsプラグインが登録されている場合、対応するjarファイルを本番環境にコピーする必要もあります。 これらのファイルへのパスを本番環境のREPORTS_CLASSPATH環境変数に追加する必要もあります