| Oracle® Fusion Middleware管理者ガイド 11g リリース1(11.1.1) B60984-03 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareをテスト環境から本番環境に移行する方法について説明します。テスト環境内でアプリケーションの開発とテストを行い、最終的にはテスト・アプリケーション、また、必要に応じてテスト・データを本番環境にロール・アウトできます。このアプローチは、アップグレードのテストおよびロール・アウトにも使用できます。
この章の項目は次のとおりです。
Oracle Fusion Middlewareコンポーネントは、別の環境に移行すること(テスト環境から本番環境への移行など)ができます。
Oracle Fusion Middlewareコンポーネントを移行しない場合、移行元の環境で行ったカスタマイズや構成変更は、移行先の環境にすべて再適用する必要がありますが、コンポーネントを移行することにより、このような作業が最小化されます。テスト環境では、Oracle Fusion Middlewareのインストール、構成、カスタマイズおよび検証を行います。システムが安定し、必要に応じて機能するようになったら、本番環境を作成します。このとき、テスト環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをテスト環境から移行することで本番環境を作成できます。
既存の本番環境がある場合は、カスタマイズなど、テスト環境のすべての変更内容を本番環境に移行できます。
|
注意:
|
この項では、インストールをテスト環境から本番環境に移行する一般的な手順について説明します。ここでは、第21.3.1項の説明に従って、テスト環境がすでに準備されていることを想定しています。
一般的な手順は次のとおりです。
環境でデータベースを使用している場合、新しいデータベースを作成するか、テスト環境から本番環境にデータベースをコピーします。第21.3.2項を参照してください。
本番環境のデータベースは、テスト環境のデータベースと同じ種類である必要があります。たとえば、テスト環境のデータベースがOracle Databaseである場合、本番環境のデータベースもOracle Databaseである必要があります。
Oracle Identity Managementを本番環境に移行します。第21.4.1項を参照してください。
第21.3.3項の説明に従って、copyBinaryおよびpasteBinaryコマンドを使用して、コンポーネントまたはスイートのMiddlewareホームのコピーをテスト環境から本番環境に移行します。
第21.3.4項または第21.3.5項の説明に従って、コンポーネントの構成のコピーを移行します。ほとんどの場合、copyConfig、extractMovePlanおよびpasteConfigスクリプトを使用します。
その他のデータ(UMSユーザー・メッセージング・プリファレンス、Oracle WebCenterアプリケーションのデータ、Oracle Web Cache構成ファイルなど)を移行します。新しい環境に固有の情報(ホスト名、ポートなど)を変更します。各コンポーネントに固有の情報については、第21.4項を参照してください。
Oracle Fusion Middlewareコンポーネントの多くで、テスト環境から本番環境に移行する際に、共通の手順を使用します。この項では、それらの手順について説明します。
この項で説明する項目は、次のとおりです。
この章のシナリオでは、Oracle Fusion Middlewareのインストールおよび構成がテスト環境で行われていることを想定しています。これには、次の一部またはすべてが含まれます。
Oracle Fusion Middlewareコンポーネント(アイデンティティ管理、Oracle SOA Suite、Oracle WebCenterなど)で使用される1つ以上のデータベースのインストール
RCUを使用した必要なスキーマの作成
アイデンティティ管理のインストールおよび構成
これには、目的のLDAPツリーおよびエントリ(特にユーザーおよびグループ)の作成(Oracle Internet Directoryの場合)、データソースに対するアダプタの作成(Oracle Virtual Directoryの場合)、ポリシーの作成(Oracle Web Services Managerの場合)が含まれます。また、SSL用の自己署名証明書の構成も含まれます。 (本番環境では、信頼できるCA署名付き証明書を使用します)。
Oracle WebLogic ServerのインストールおよびMiddlewareホームの作成
Oracle Fusion Middlewareコンポーネント(Oracle SOA SuiteやOracle WebCenterなど)のインストールおよび構成
セキュリティ・ポリシーの構成
1つ以上のアプリケーションまたはSOAコンポジット・アプリケーションのデプロイ。これらのアプリケーションには、内部参照および外部参照が含まれる場合があります。
様々なコンポーネント(Oracle Internet Directory、 Oracle SOA SuiteおよびOracle WebCenterなど)でデータベースが必要となります。新しいデータベースをインストールするか、またはテスト環境からデータベースをコピーすることができます。
新しいデータベースをインストールする手順は次のとおりです。
データベース・ソフトウェアをインストールして構成します。
RCUを使用して、本番データベースで必要なスキーマを作成します。『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
アプリケーションで使用するカスタム・スキーマを作成します。たとえば、アプリケーションがテスト環境でカスタム・スキーマを使用する場合、本番環境でそのスキーマを作成します。
Oracle Database RMANのduplicateコマンドを使用して、複製データベースを作成します。複製データベースは、完全に独立して動作するように、ソース・データベースと異なるDBIDを使用して作成する必要があります。
Oracle Databaseリリース11gの複製を本番環境に作成するには:
本番環境で、Oracle Databaseソフトウェアをインストールします。ただし、データベースは作成しません。これを行うには、「構成オプションの選択」画面で「データベース・ソフトウェアのみインストール」を選択します。
テスト環境で、tnsnames.oraファイルを編集し、本番環境上のデータベースのエントリを追加します。
tnsnames.oraファイルの例を次に示します。この例で、testDBはテスト環境上のデータベース、prodDBは本番環境上のデータベースです。
testDB =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.1.1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = testDB)
)
)
prodDB=
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.2.4)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = prodDB)
)
)
テスト環境で、listener.oraファイルを編集し、本番環境上のデータベースのエントリを追加します。
追加するエントリを次に示します。
LISTENER_mts =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = 192.168.2.4)
(PORT = 1521)(IP = FIRST))
)
)
SID_LIST_LISTENER_mts =
(SID_LIST =
(SID_DESC =
(SID_NAME = prodDB)
(ORACLE_HOME = /scratch/oracle/test)
)
)
本番環境で、ORACLE_HOME/dbsディレクトリにパスワード・ファイルを作成します。SYSパスワードは、テスト環境のデータベースにおけるSYSアカウント用のパスワードと同じである必要があります。次のコマンドを使用すると、パスワード・ファイルが作成されます。
orapwd password=password file=ORACLE_HOME/dbs/orapwproddb
本番環境で、ORACLE_HOME/dbsディレクトリにパラメータ・ファイル(pfile)を作成します。このファイルには、DB_NAMEパラメータのみが含まれている必要があります。例:
DB_NAME=prodDB
本番環境で、本番データベースを指すようにORACLE_SID環境変数を設定します(まだ設定されていない場合)。次に、NOMOUNTモードでデータベースを起動します。例:
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
データベースをテスト環境から本番環境に移行するには、本番環境でRMANを使用します。
RMANを使用してデータベースを複製する例を次に示します。
RMAN DUPLICATE TARGET DATABASE TO prodDB FROM ACTIVE DATABASE SPFILE NOFILENAMECHECK;
RMANは、サーバー・パラメータ・ファイルを接続先ホストに自動的にコピーし、サーバー・パラメータ・ファイルを使用して補助インスタンスを起動して、必要なすべてのデータベース・ファイルおよびアーカイブREDOログをネットワークを介して接続先ホストにコピーし、データベースをリカバリします。最後に、RMANは、RESETLOGSオプションを指定してデータベースを開き、オンラインREDOログを作成します。
詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次のリンクから入手可能です。
http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html
Middlewareホームのコピーを本番環境に移行するには、copyBinaryおよびpasteBinaryスクリプトを使用します。Middlewareホーム内のOracle WebLogic Serverホーム、Oracleホームおよびバイナリ・ファイルも移行されます。
Middlewareホームを移行する手順は次のとおりです。
Windowsの場合は、ソースMiddlewareホームで、管理サーバーおよびMiddlewareホームで実行されている管理対象サーバーをすべて停止します。
ソースMiddlewareホームで、copyBinaryスクリプトを実行します。これによって、WebLogic ServerホームおよびMiddlewareホーム内に含まれるOracleホームがコピーされます。ソースのMiddlewareホーム内にOracleホームがない場合、アーカイブにOracleホームは含まれなくなります。
たとえば、/scratch/Oracle /Middleware1のMiddlewareホームをコピーするには、次のコマンドを使用します。
copyBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-invPtrLoc /scratch/oracle/oraInst.loc
Middlewareホームを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
pasteBinaryスクリプトとcloningclient.jarファイルをターゲット・システムにコピーし、実行権限があることを確認します。ファイルの場所については、第20.3項を参照してください。
pasteConfigなど他のスクリプトをコピーしないでください。これらのスクリプトは、ステップ5で説明しているように、ファイルの抽出時に生成されます。
クローニング先で、pasteBinaryスクリプトを使用して、アーカイブからファイルを抽出します。
たとえば、/scratch/oracle/MW_Home_prodディレクトリにアーカイブを適用するには、次のコマンドを使用します。
pasteBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-targetMWHomeLoc /scratch/oracle/MW_Home_prod
Middlewareホームが/scratch/oracle/MW_Home_prodに抽出され、その下にWebLogic Serverホーム、およびソースOracleホーム名と同じ名前ですべてのOracleホームが抽出されます。
Javaコンポーネント(Oracle SOA Suiteなど)のドメイン構成のコピーを移行するには、copyConfig、extractMovePlanおよびpasteConfigスクリプトを使用します。この手順により、ドメイン、管理サーバーおよび管理対象サーバーを含む構成がコピーされます。続いて、管理サーバーが起動されます。ノード・マネージャ構成のコピーも移行できます。
|
注意:
|
ドメイン構成およびノード・マネージャ構成のコピーを移行する手順は次のとおりです。
ソースのMiddlewareホームで、管理サーバーおよびすべての管理対象サーバーが起動されていることを確認します。
ドメイン構成をコピーするには、ソースMiddlewareホームで、copyConfigスクリプトを実行します。
たとえば、Middlewareホーム/scratch/Oracle/Middleware1にあるSOA_domain1というOracle SOA Suiteドメインの構成をコピーするには、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-sourceDomainLoc /scratch/Oracle/Middleware1/user_projects/domains/SOA_domain1
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-domainHostName example.com
-domainPortNum 8001
-domainAdminUserName admin_username
-domainAdminPassword /scratch/admin/passwd.txt
-logDirLoc /tmp/logs
コンポーネントを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
extractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。例:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-planDirLoc /tmp/Oracle/t2p_plans/soa
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。移行するコンポーネント・タイプごとのプロパティのリストについては、表20-10を参照してください。
ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。たとえば、Middlewareホーム/scratch/Oracle/Middleware1にアーカイブを適用するには、次のコマンドを使用します。
pasteConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-movePlanLoc /tmp/Oracle/t2p_plans/soa/moveplan.xml
-targetDomainLoc /scratch/Oracle/Middleware1/user_projects/domains/SOA_domain1
-targetMWHomeLoc /scratch/Oracle/Middleware1/
-domainAdminPassword /scratch/pwd_dir/pass.txt
ノード・マネージャ構成をコピーするには、ソースMiddlewareホームで、copyConfigスクリプトを実行します。たとえば、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/nm.jar
-sourceNMHomeLoc //scratch/Oracle/Middleware/wlserver_10.3/common/nodemanager
-logDirLoc /tmp/logs
ノード・マネージャを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
extractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。例:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-planDirLoc /tmp/Oracle/t2p_plans/soa
ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ノード・マネージャのプロパティのリストについては、表20-17を参照してください。
ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。たとえば、次のコマンドを使用します。
pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
-archiveLoc /tmp/nm.jar
-targetNMHomeLoc /scratch/Oracle/Middleware1/wlserver_10.3/common/nodemanager
-targetMWHomeLoc /scratch/Oracle/Middleware1
-movePlanLoc /scratch/sunny/t2pplans/moveplan.xml
-silent true
pasteConfig操作では、SSLが無効化されます。さらに、本番環境でカスタム・キーストアは作成されません。次の手順を実行します。
この作業が完了したら、第21.4項の説明に従って、コンポーネントごとに追加手順を実行する必要があります。
システム・コンポーネント(Oracle HTTP Server、Oracle Internet DirectoryおよびOracle Virtual Directoryなど)では、copyConfig、extractMovePlanおよびpasteConfigスクリプトを使用します。
これらのコンポーネントでは、次の手順を実行します。
ソースMiddlewareホームで、copyConfigスクリプトを実行します。
たとえば、/scratch/Oracle/Middleware1/webtier_1に配置されているOracleインスタンス内のohs1というOracle HTTP Serverインスタンスをコピーするには、次のコマンドを使用します。
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-sourceInstanceHomeLoc /scratch/Oracle/Middleware1/webtier_1
-sourceComponentName ohs1
コンポーネントを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。
extractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。例:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-planDirLoc /tmp/Oracle/t2p_plans/ohs
移動計画を編集して、ターゲット環境の値を反映するように特定のコンポーネントのプロパティを変更します。
Oracle HTTP Serverについては、表20-14を参照してください。
Oracle Internet Directoryについては、表20-15を参照してください。
Oracle Virtual Directoryについては、表20-16を参照してください。
Oracleインスタンス名はドメインで一意である必要があり、コンポーネント名はOracleインスタンスで一意である必要があります。Oracleインスタンスのアーカイブを同一ドメインに適用する場合、移動計画で-targetInstanceNameおよび-targetComponentNameプロパティを使用してインスタンスおよびコンポーネントに別の名前を指定します。
ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。たとえば、Oracleインスタンスwebtier_2にアーカイブを適用し、ターゲットのOracle HTTP Serverインスタンスにohs_clという名前を付けるには、次のコマンドを使用します。
pasteConfig.sh -javaHome /scratch/Oracle/Middleware/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-movePlanLoc /tmp/Oracle/t2p_plans/ohs/moveplan.xml
-targetOracleHomeLoc /scratch/Oracle/Middleware/Oracle_WebTier
-targetInstanceHomeLoc /scratch/Oracle/Middleware/webtier_2
-targetInstanceName webtier_2
-targetComponentName ohs_cl
-domainHostName myhost
-domainPortNum 7001
-domainAdminUserName domain_admin_username
-domainAdminPassword domain_admin_password_file
この作業が完了したら、第21.4項の説明に従って、コンポーネントごとに追加手順を実行する必要があります。
新しい本番環境でセキュリティを構成する必要があります。手順は、環境およびアプリケーションの構成によって異なります。次の各手順は、Oracle Internet Directory、JKS証明書、Oracle Web Services ManagerおよびOracle Platform Securityを使用していることを想定しています。
本番環境のLDAPアイデンティティ・ストアでは、テスト環境と同じユーザーおよびグループを使用しない可能性や、すでにユーザーおよびグループが移入されている可能性があります。テスト環境からユーザー、グループおよびパスワードをエクスポートする必要がある場合のみ、次の手順を実行します。
必要に応じて、ユーザーおよびグループを本番環境に移行します。たとえば、Oracle Business Activity Monitoringまたはヒューマン・ワークフローのデモを使用している場合、これらのユーザーを移行します。
ldapsearchコマンドを使用して、テスト環境のLDAPアイデンティティ・ストアからユーザーおよびグループをエクスポートします。これにより、後で本番環境のLDAPアイデンティティ・ストアにインポートするldifファイルが作成されます。ldapsearchコマンドは、アイデンティティ管理コンポーネントのORACLE_HOME/binディレクトリにあります。例:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
次の例で示すように、ldapaddmtコマンドを使用して、テスト環境からエクスポートしたldifファイルを本番環境にインポートします(ORACLE_HOMEはアイデンティティ管理のOracleホームです)。
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
セキュリティ・ポリシーが外部LDAPまたはデータベース・ベース・ストアに格納されている場合は、第21.4.1.1項の作業12「Oracle Platform Securityの新しい本番環境への移行」の説明に従って、セキュリティ・ポリシー(ヒューマン・ワークフロー・アプリケーションのロールに関連するセキュリティ・ポリシーなど)をテスト環境から本番環境にインポートします。
資格証明ポリシーが外部LDAPまたはデータベース・ベース・ストアに格納されている場合は、第21.4.1.1項の作業12「Oracle Platform Securityの新しい本番環境への移行」の説明に従って、資格証明ストアの情報をテスト環境から本番環境にインポートします。
次の各項では、Oracle Fusion Middlewareコンポーネントを移行する場合に実行する必要のある手順について説明します。多くの場合、これらの手順では第21.3項で説明されている一般的な手順を使用します。すべてのコンポーネントで、次の各項で説明する追加手順を実行する必要があります。
Oracle Hyperion Enterprise Performance Management Systemの本番環境への移行
Oracle Portal、Oracle Forms Services、Oracle ReportsおよびOracle BI Discovererの本番環境への移行
次の各項目では、アイデンティティ管理をテスト環境から本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
アイデンティティ管理コンポーネント(Oracle Internet Directory、Oracle Directory Integration Platform (Oracle Internet Directoryに依存)、Oracle Identity Federationなど)に使用されるデータベースをインストールしました。
RCUを使用して必要なスキーマを作成しました。
アイデンティティ管理(Oracle Internet Directory、Oracle Virtual Directory、Oracle Web Services Manager、Oracle Adaptive Access Managerの一部またはすべてを含む)をインストールして構成しました。
Oracle Internet Directoryの場合、目的のLDAPツリーおよびエントリ(特にユーザーおよびグループ)を作成しました。
Oracle Virtual Directoryの場合、様々なデータソース(LDAP、データベースなど)に対するアダプタを作成し、場合によっては、ローカル・ストア・アダプタ(LSA)を構成してローカル・ファイルシステムにあるローカルのLDAPデータを作成しました。また、必要に応じて、その他の構成変更(ACLの追加、スキーマの変更、リスナー構成、サーバー構成、プラグイン、マッピング、監査、ロギング、キーストア)を行いました。
Oracle Directory Integration Platformの場合、様々なターゲットに対する同期プロファイルを作成しました。これらのプロファイルは、Oracle Internet DirectoryにあるLDAPエントリの形式です。
Oracle Identity Federationの場合、様々な信頼できるアイデンティティ・プロバイダおよびサービス・プロバイダを構成しました。
Oracle Access Manager 11gの場合、保護されたアプリケーションのWeb層で構成されている対応Webゲートによる認証を設定しました。Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドで説明されているように、Oracle Access Manager構成データはファイル内に存在し、ポリシーおよび構成データはデータベース内に存在します。
Oracle Platform Securityの場合、セキュリティ・ポリシーおよび格納済の資格証明を資格証明ストア・フレームワーク(CSF)に作成しました。Oracle Platform Securityは、ADF、WebCenter、SOAコンポジット・アプリケーションなどに役立ちます。
Oracle Web Services Managerの場合、Oracle Web Services Managerのポリシーを作成しました。これらのポリシーは、Webサービスおよびクライアントにも組み込まれます。
SSLの場合、自己署名証明書を構成しました (本番環境では、信頼できるCA署名付き証明書を使用します)。
このシナリオでは、アイデンティティ管理コンポーネント(Oracle Internet Directory、Oracle Virtual Directory、Oracle Directory Integration Platformなど)がテスト環境にインストール済で、これらを存在していない本番環境に移行する必要があると想定します。
最初に、次の作業を実行します。これは、すべてのコンポーネントに必要です。
作業1「データベース、Middlewareホームおよびドメイン構成の新しい本番環境への移行」
次に、使用するコンポーネントに応じて次の作業を実行します。
次の手順を使用して、データベース、すべてのアイデンティティ管理のMiddlewareホームのコピーおよびドメイン構成を本番環境に移行します。
第21.3.2項の説明に従って、データベースとスキーマを移行または作成します。
第21.3.3項の説明に従って、copyBinaryおよびpasteBinaryスクリプトを使用して、アイデンティティ管理コンポーネントを含むMiddlewareホームのコピーをテスト環境から本番環境に移行します。
第21.3.4項の説明に従って、アイデンティティ管理構成を含む各ドメインの構成のコピーを移行します。この手順により、ドメイン、管理サーバーおよび管理対象サーバーを含む構成が移行されます。構成の移行では、次のことも行われます。
移行計画で提供された値に基づく、LDAPまたはデータベース・ベース・ストアへのセキュリティ・ストアの再関連付け
Oracle Platform Securityの移行
Oracle Web Services Manager、MDSリポジトリまたはデプロイ・プランに格納されているすべてのポリシー、およびDOMAIN_HOME/libに格納されているすべてのカスタム・ポリシーの移行
データソースの構成
JMSリソースの構成
管理サーバーの起動
Oracle Internet Directoryを新しい本番環境に移行するには:
第21.3.5項の説明に従って、Oracle Internet Directory構成を移行します。
次の点に注意してください。
Oracle Internet Directoryコンポーネントを、ソース・コンポーネントと同じデータベース資格証明を使用してコピーする場合は、OIDスキーマでの競合を避けるために、ターゲットOIDコンポーネントの名前をソース・コンポーネントとは異なるものにする必要があります。
Oracle Internet Directoryコンポーネントを、ソース・コンポーネントとは異なるデータベース資格証明を使用してコピーする場合は、OIDスキーマでの競合を避けるために、ターゲットOracle Internet Directoryコンポーネントの名前をソース・コンポーネントと同じものにする必要があります。
特定の条件下で、copyConfigおよびpasteConfigスクリプトを実行すると、次のようなエラーが発生する場合があります。
OID Cloning: Error cleaning replication agreements OID Cloning: Error deleting replication dn OID Cloning: Error updating orclreplicaid
このようなエラーが表示された場合は、次の手順を実行します。
次のコマンドを実行します。
ORACLE_HOME/ldap/bin/remtool -pcleanup
プロンプトが表示されたら、Oracle Internet Directoryホスト、非SSLポートおよびODSスキーマ・パスワードを入力します。
ルートDNでldapsearchを実行し、orclreplicaid値を検索します。次のコマンドを使用します。
ORACLE_HOME/bin/ldapsearch -p port -h host -b "" -s base "(objectclass=*)" orclreplicaid
ステップbで取得した値を使用して、ldapdeleteを実行し、Oracle Internet Directoryから次のDNを削除します。
cn=replication dn, orclreplicaid=<replicaid>, cn=replication configuration orclreplicaid=<replicaid>, cn=replication configuration
例:
ldapdelete -p port -h host "cn=replication dn, orclreplicaid=replicaid, cn=replication configuration"
ルート・エントリのorclreplicaidの値を0に設定します。例:
ORACLE_HOME/bin/ldapmodify -p port -h host -f file.ldif
ldifファイルには次の内容が含まれます。
dn: changetype: modify replace: orclreplicaid orclreplicaid: 0
Oracle Internet Directoryを再起動します。
テスト環境でOracle Internet Directoryのレプリケーションを構成済の場合、移行後に本番環境で再構成する必要があります。レプリケーションの構成は、テスト環境から本番環境に移行されません。Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのレプリケーションの設定に関する項を参照してください。
Oracle Virtual Directoryを新しい本番環境に移行するには:
第21.3.5項の説明に従って、Oracle Virtual Directory構成を移行します。
pasteConfigの操作で、Oracle Virtual Directoryアダプタのパスワード・ファイルを指定しなかった場合や、移動計画のパスワード・ファイルの場所を間違えて指定した場合には、アダプタ構成は変更されず、スクリプトによって次のメッセージが返されます。
Password file is either not provided or invalid for adapter adapter_name. Nothing will be changed for this adapter configuration.
|
注意: テスト環境と本番環境の両方の管理サーバーを起動する必要があります。 |
ポリシー構成情報をテスト環境から本番環境にレプリケートするには:
新しいホスト名とポートにあわせて、Oracle Access Managerサーバー・インスタンスを更新します。Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドの個々のOAMサーバーおよびプロキシ設定の表示または編集に関する項を参照してください。
Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのパートナ(エージェントおよびアプリケーション)のリモートからの登録に関する項の説明に従って、クライアントを登録します。
登録プロセスによって、変更された新しいObAccessClient.xmlファイルが生成されます。このファイルを次の場所にコピーします。
WebGate_instance_dir/webgate/config
環境変数JAVA_HOMEを設定し、JAVA_HOMEをPATHに追加します。
次のWLSTコマンドを使用して、テスト環境からポリシーをエクスポートします。
exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
ポリシー・ファイルを本番環境にコピーします。
次のコマンドを使用して、本番システムにポリシーをインポートします。
importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
次のWLSTコマンドを使用して、テスト環境からパートナ情報をエクスポートします。
exportPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
パートナ・ファイルを本番環境にコピーします。
次のWLSTコマンドを使用して、本番環境にパートナ情報をインポートします。
importPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
管理対象サーバーを起動します。
Oracle Access Manager 10gを新しい本番環境に移行するには:
ディレクトリ・サーバーをテスト環境から本番環境に移行します。つまり、o=oblixノードを移行します。『Oracle Access Managerインストレーション・ガイド』の新しいディレクトリ・サーバー・インスタンスの準備に関する項を参照してください。
アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーと関連付けられているエンティティを削除します。該当のエンティティは、次のコマンドの下にあります。
obcontainerId=DBAgents,<Configuration DN>
コンテナ(obcontainerId=DBAgents)は削除しないでください。
Oracle Access Managerインストレーション・ガイドの説明に従って、Oracle Access Managerをインストールして構成し、本番環境用のLDAP情報を指定します。
Oracle Access Managerは、ポリシーおよび構成データをLDAPディレクトリに格納します。LDAPディレクトリが正しく構成されている場合(たとえば、Oracle Internet Directoryをテスト環境から本番環境に正しく移行済の場合)、Oracle Access Managerは、ポリシーおよび構成データをLDAPディレクトリから継承します。
本番環境で、新しい識別子を使用してアイデンティティ・サーバーおよびWebパスをインストールします。詳細は、次を参照してください。
『Oracle Access Managerインストレーション・ガイド』のアイデンティティ・サーバーのインストールに関する項
『Oracle Access Managerインストレーション・ガイド』のWebパスのインストールに関する項
インストール後、次の手順に従います。
サーバーを起動します。
アイデンティティ・システム・ブラウザの設定を完了します。『Oracle Access Managerインストレーション・ガイド』のアイデンティティ・システムの設定に関する項を参照してください。
Oracle Access Managerインストレーション・ガイドのポリシー・マネージャのインストールに関する項の説明に従って、ポリシー・マネージャをインストールします。ただし、ディレクトリ・サーバーを移行したときにすでにスキーマを更新しているので、スキーマは更新しないでください。認証スキームはすでにディレクトリ・サーバーに存在しているため、これを構成しないでください。
|
注意: 本番のポリシー・マネージャを設定した後、Oracle Access Managerの管理者としてログインすると、次のエラーが発生する場合があります。There was a problem obtaining the user ID. One possible reason for this is a time difference between the Identity System and Access Systems (Policy Manager and Access System Console). これを修正するには、LDAPからo=oblixノードの下のcookie暗号化鍵を削除し(CPResponseEncryptionKeyは変更しない)、アイデンティティ・サーバーを再起動します。削除する前に、cookie暗号化エントリのバックアップをldifファイルに作成する必要があることに注意してください。 |
アクセス・システム・コンソールからブラウザ設定を完了し、新しい識別子を使用してアクセス・サーバーを追加します。詳細は、『Oracle Access Managerインストレーション・ガイド』のシステム・コンソールでのアクセス・サーバー・インスタンスの作成に関する項を参照してください。
また、その他の情報は、『Oracle Access Managerインストレーション・ガイド』のアクセス・サーバーとインストールに関する項を参照してください。
このシナリオでは、本番のWebゲート用に既存のWebゲート識別子を再使用します。次の手順に従います。
アクセス・システム・コンソールに移動し、「アクセス・システム構成」タブを選択します。
「ホスト識別子」を選択します。「すべてのホスト識別子をリスト」ページで、テスト環境が使用するホスト識別子を選択します。
「変更」をクリックします。次に、本番のWebサーバー用のホスト名およびポートを「ホスト名のバリエーション」フィールドに追加します。
|
注意: 複数のホスト識別子に同じホストおよびポートがあると、リソースが保護されなくなる場合があります。ポリシー・ドメインで使用されるホスト識別子のみがその定義のhost:portを持つようにしてください。その他のホスト識別子からhost:portを削除します。 |
「保存」をクリックします。
「アクセス・システム構成」タブから「アクセス・ゲート構成」を選択します。次に、関連するアクセス・ゲートを選択します。
「アクセス・ゲートの詳細」ページで「変更します。」を選択します。
ホスト名およびポートを変更し、本番のWebサーバーのホスト名およびポートを指定します。
優先HTTPホストを変更し、ステップcで追加したホスト名のバリエーションを指定します。
Oracle Access Managerアクセス管理ガイドのアクセス・サーバーへのアクセス・ゲートとWebゲートの関連付けに関する項の説明に従って、Webゲートを新しく追加した本番のアクセス・サーバーに関連付けます。
Webゲートを一時的に無効にします。アクセス・システム・コンソールから「アクセス・システム構成」タブを選択し、「アクセス・ゲート構成」を選択します。「実行」をクリックして、検索します。検索結果から、「アクセス・ゲート」を選択します。次に、「変更します。」を選択します。「無効」をクリックします。次に、「保存」をクリックします。
アクセス・サーバーをインストールした後、それを有効にします。
Webゲート作成中に使用した新しい識別子を使用して、アクセス・サーバーをインストールします。『Oracle Access Managerインストレーション・ガイド』のアクセス・サーバーのインストールに関する項を参照してください。
新しいWebゲートをインストールします。『Oracle Access Managerインストレーション・ガイド』のWebゲートのインストールに関する項を参照してください。
エントリを確認し、テスト環境に関連するエントリを削除します。
アイデンティティ・システム・コンソールから「システム構成」タブを選択し、「ディレクトリ・プロファイル」を選択します。それぞれのディレクトリ・プロファイルが新しいアイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャに関連付けられていることを確認します。
アイデンティティ・システム・コンソールから「システム構成」タブを選択し、「Webパス」を選択して、テストのWebパスのエントリを削除します。
アイデンティティ・システム・コンソールから「システム構成」タブを選択し、「アイデンティティ・サーバー」を選択して、テストのアイデンティティ・サーバーのエントリを削除します。
アクセス・システム・コンソールから「アクセス・システム構成」タブを選択し、「アクセス・サーバー構成」を選択します。テスト環境のアクセス・サーバーのエントリを削除します。
アイデンティティ・システム・コンソールから「システム構成」タブを選択し、「パスワード・ポリシー」を選択します。ホストおよびポートが「パスワード変更のリダイレクトURL」に設定されている場合は、新しいアイデンティティ・サーバーを指すように変更します。
アクセス・システム・コンソールから「アクセス・システム構成」タブを選択し、「認証管理」を選択します。チャレンジ・リダイレクトが設定されている認証スキームを選択します。新しい認証Webゲートがインストールされている場合は、新しいWebサーバーのホストおよびポートを指定するように「チャレンジ・リダイレクト」を変更します。
アクセス・システム・コンソールから「アクセス・システム構成」タブを選択し、「認証管理」を選択します。パスワード・ポリシーが構成されている認証スキームを選択します。WebパスとWebゲートが異なるWebサーバーにある場合、Webパスがインストールされている本番のWebサーバーの新しいホストおよびポートに適応するようにobWebPassURLprefix(ある場合)を変更します。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のパスワード・ポリシーの構成に関する項を参照してください。
Oracle Identity Federationを新しい本番環境に移行するには:
Oracle Access ManagerとOracle Identity Federationを使用する場合は、本番環境のOracle Coherenceのホスト名とポートを更新します。
管理サーバーを停止し、テスト環境で管理対象サーバーが稼働している場合は、それらをすべて停止します。
次のファイルのCoherenceConfigurationセクションで、ターゲット・ホストにあわせてCoherenceホストを更新します。
DOMAIN_HOME/config/fmwconfig/oam-config.xml
本番環境の値にあわせてホスト名、ポートおよびSOAPポートを更新します。
Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。
OIFページのターゲット・メニューから、「管理」→「サーバー・プロパティ」を選択します。
「ホスト」、「ポート」および「SOAPポート」を、本番環境の値にあわせて変更します。
ロード・バランサまたはプロキシ・サーバーを使用している場合は、それらの値を使用します。そうでない場合は、リクエストを処理している管理対象サーバーの値を使用します。
「適用」をクリックします。
サービス・プロバイダIDのURLを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→サーバー・プロバイダを選択します。「共通」タブを選択します。
本番環境の値で「プロバイダID」を更新します。
本番環境とテスト環境で「デフォルトSSOアイデンティティ・プロバイダ」が異なる場合は、「Default SSO Identity Provider」を更新します。
プロバイダ・マッピングを識別するためのSSO認証メカニズムを更新する必要がある場合には、「構成」をクリックします。続いて、「追加」をクリックして、メカニズム名とアイデンティティ・プロバイダを選択します。「OK」をクリックします。
「適用」をクリックします。
アイデンティティ・プロバイダIDのURLを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→「アイデンティティ・プロバイダ」を選択します。「共通」タブを選択します。
本番環境の値で「プロバイダID」を更新します。
「適用」をクリックします。
データ・ストアを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→「データ・ストア」を選択します。
それぞれの「データ・ストア」セクションで「編集」をクリックします。
「LDAPディレクトリ」または「データベース」で、接続情報を本番環境の値で更新します。
「適用」をクリックします。
認証エンジンを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→「認証エンジン」を選択します。使用する認証エンジンによって変更する内容は異なります。
LDAPディレクトリを使用する場合は、「LDAPディレクトリ」タブを選択します。本番環境のLDAPバックエンドまたはデータベースの値で「接続URL」を更新します。
データベースを使用する場合は、「データベース・セキュリティ」タブを選択します。「JDBC URL」を更新します。
Oracle Single Sign-OnまたはOracle Access Managerを使用する場合は、Oracle Identity Federationの構成を変更する必要はありません。ただし、Oracle HTTP Server、Oracle Access ManagerまたはOracle Single Sign-Onの情報を変更する必要があります。Oracle Fusion Middleware Oracle Access Manager統合ガイドの認証エンジンの構成に関する項を参照してください。
カスタム認証エンジンを使用する場合は、Oracle Identity Federationの構成を変更する必要はありません。ただし、テスト環境に配置した.warファイルを本番環境に再デプロイする必要があります。
「適用」をクリックします。
サービス・プロバイダ統合モジュールを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→「サービス・プロバイダ統合モジュール」を選択します。使用する認証エンジンによって変更する内容は異なります。
Oracle Single Sign-Onを使用する場合は、「Oracleシングル・サインオン」タブを選択します。「ログインURL」および「ログアウトURL」を更新します。
Oracle Access Managerを使用する場合は、「Oracle Access Manager」タブを選択します。次のフィールドを更新します。
サーバーSDKディレクトリへのアクセス
「Oracle Access Managerプロパティ」セクションで、「管理ユーザー名」、「管理パスワード」、「管理者パスワードの確認」、「ホストID」、「ポリシー・ドメイン」および「無保護リソースに対する認可結果」を更新します。
続いて、「Oracle Access Managerの構成」をクリックします。
カスタムSPエンジンを使用する場合は、Oracle Identity Federationの構成を変更する必要はありません。ただし、テスト環境に配置した.warファイルを本番環境に再デプロイする必要があります。
詳細は、Oracle Fusion Middleware Oracle Access Manager統合ガイドのOracle Identity FederationのSPモードによる構成に関する項を参照してください。
「適用」をクリックします。
ほとんどの場合、「セキュリティおよび信頼」、「フェデレーション」または「認証メカニズム」を変更する必要はありません。次の点に注意してください。
パートナを変更または追加する必要がある場合は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドの信頼できるプロバイダの追加に関する項および信頼できるプロバイダの削除に関する項を参照してください。
HTTP Basic認証を変更する必要がある場合は、ユーザー名とパスワードを更新します。
Fusion Middleware Controlで、OIFページのターゲット・メニューから、「管理」→「フェデレーション」を選択します。任意の信頼できるプロバイダを選択して、「編集」をクリックします。HTTP認証ユーザー名およびHTTP認証パスワードを更新します。続いて、パスワードを確認します。「適用」をクリックします。
管理対象サーバーを起動します。
Oracle Adaptive Access Managerを新しい本番環境に移行するには:
テスト環境からスナップショットをエクスポートします。Oracle Adaptive Access Manager管理コンソールを使用して、構成をzipファイルにエクスポートします。詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのシステム・スナップショットのインポート/エクスポートに関する項を参照してください。
次のタイプの項目をエクスポートできます。
ポリシー
ルールの条件
パターン
構成可能アクション
トランザクション定義
エンティティ
KBAの質問
KBAの検証
ルールで使用されるすべてのグループ・タイプ(アラート・グループ、アクション・グループ、ブラック・リスト・グループ、ホワイト・リスト・グループなど)
本番環境にスナップショットをインポートします。Oracle Adaptive Access Manager管理コンソールを使用して、ステップ1で保存したzipファイルの内容をインポートします。詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのシステム・スナップショットのインポート/エクスポートに関する項を参照してください。
次の項目について、必要に応じて本番環境を手動で更新します。
スナップショットのエクスポートおよびインポートはアクション・グループおよびアラート・グループをコピーするだけなので、グループ・メンバーをテスト環境からエクスポートし、本番環境にインポートする必要があります。
グループをエクスポートするには、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのグループのエクスポートに関する項を参照してください。
グループを本番環境にインポートするには、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのグループのインポートに関する項を参照してください。
oaam_extensions共有ライブラリを使用して、構成可能アクションのjarをパッケージ化します。
ヘッダー、フッター、カスケード・スタイル・シート(CSS)、JavaScriptなどの、OAAMサーバーでカスタマイズされた項目を、テスト環境から本番環境に手動でコピーします。これらの項目は、oaam_extensions共有ライブラリにあります。
Oracle Adaptive Access Manager管理コンソールを使用して、KBAロジック、OTPロジックおよびポリシー・セットのオーバーライドを手動で再作成します。Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。
プロパティ・ファイル、リソース・バンドルおよびエンド・ユーザーJSP画面をテスト環境から本番環境にコピーします。これらの項目は、oaam_extensions共有ライブラリにあります。
VADイメージをテスト環境から本番環境にコピーします。これはカスタムjar内にあります。
次の手順を実行して、移行が正常に行われたかどうかを検証します。
Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのOAAM管理コンソールとコントロールに関する項の説明に従って、OAAM管理コンソールにログインします。
ポリシーに移動し、テスト環境のルールおよびグループが本番環境に存在することを確認します。
KBAモジュールに移動し、テスト環境のチャレンジ質問が本番環境に存在することを確認します。
Oracle Adaptive Access Manager用に構成されたWebアプリケーションをテストします。ユーザーは、登録およびチャレンジ・フローにリダイレクトされます。
Oracle Identity Navigatorを新しい本番環境に移行するには:
本番システムで、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドのニュース・フィードにアクセスするためのプロキシの構成に関する項の説明に従って、プロキシを構成します。
Oracle Identity Managerのデプロイメント・マネージャを使用して、ほとんどのメタデータをテスト環境から本番環境に移行できます。次の表に、デプロイメント・マネージャを使用して移行できるエンティティを示します。
| エンティティ | デプロイメント・マネージャのカテゴリ |
|---|---|
| ロール | ロール |
| 組織 | 組織 |
| アクセス・ポリシー | アクセス・ポリシー |
| 認証プロセス | 認証プロセス |
| 認可ポリシー | 認可ポリシー |
| ユーザー・メタデータ | ユーザー・メタデータ |
| ロールおよび組織のメタデータ | ロールおよび組織のメタデータ |
| スケジュール済タスク | スケジュール済タスク |
| スケジュール済ジョブ | ジョブ |
| ITリソース | ITリソース |
| リソース・オブジェクト | リソース |
| 参照定義 | 参照 |
| プロセスの形式 | プロセスの形式 |
| プロビジョニング・ワークフローとアダプタ | プロセス |
| リソースの形式 | リソースの形式 |
| データ・オブジェクトの定義 | データ・オブジェクトの定義 |
| ルール | ルール |
| 通知テンプレート | 通知テンプレート |
| GTCプロバイダ | GTCプロバイダ |
| エラー・コード | エラー・コード |
| システム・プロパティ | システム・プロパティ |
| EmailDef | 電子メール定義 |
| EventHandler | イベント・ハンドラ |
| PasswordPolicy | パスワード・ポリシー |
| GenericConnector | 汎用コネクタ |
| ITResourceDef | ITリソース定義 |
| リクエスト・テンプレート | リクエスト・テンプレート |
| リクエスト・データセット | リクエスト・データセット |
| 承認ポリシー | 承認ポリシー |
Oracle Identity Managerを新しい本番環境に移行するには:
テスト環境で、デプロイメント・マネージャを使用して、前述の表に示されているエンティティのメタデータをエクスポートします。ウィザードで、エンティティの子と依存関係を選択します。メタデータのエクスポート方法の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドのデプロイメントのエクスポートに関する項を参照してください。
データは、.xmlファイルとしてエクスポートされます。
本番環境で、デプロイメント・マネージャを使用して、前述の表に示されているエンティティのメタデータをインポートします。メタデータのインポート方法の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドのデプロイメントのインポートに関する項を参照してください。
デプロイメント・マネージャは、リソース・バンドル、jarとプラグイン、およびカスタムのリコンシリエーション・プロファイルを管理しません。
JDeveloperを使用して、SOAコンポジット・アプリケーションである承認ワークフローを移行します。
標準のファイル転送方法を使用して、JDeveloperプロジェクトにあるすべてのファイルをテスト環境から本番環境にコピーします。
アプリケーションで、外部システムへのコールを本番環境のシステムを指すように変更します。たとえば、ワークフローがテスト環境のLDAPサーバーを使用している場合、参照を本番環境のLDAPサーバーを指すように変更します。
JDeveloperを使用して、sca jarファイルをSOAコンポジットから構築します。
Fusion Middleware ControlのSOAデプロイメント・ウィザード(第10.5.1項参照)またはJDeveloperを使用して、SOAコンポジット・アプリケーションを本番環境にデプロイします。
テスト環境で、ローカライゼーション・リソース・バンドル、および次の一連のプラグイン・コードをテスト環境からエクスポートします。
スケジュール済タスクjar
アダプタJavaタスク
サード・パーティjar
その他のプラグイン・コードjar
次の手順に従います。
エンティティをzipファイルにエクスポートする次のスクリプトを編集します。
(UNIX) OIM_ORACLE_HOME/server/bin/exportMetadata.sh (Windows) OIM_ORACLE_HOME\server\bin\exportMetadata.bat
スクリプトを編集して次の値を指定します。
CONTEXT: アプリケーションのURL。たとえば、weblogic.jndi.WLInitialContextFactory。
EXPORT_LOCATION: zipファイルが作成されるディレクトリへの完全パス。
TEMP_LOCATION_TO_EXTRACT: ファイルがzipファイルにパッケージ化される前に一時的に格納されるディレクトリへの完全パス。
CONTROL_FILE: 何をエクスポートする必要があるかを制御するXMLファイル。ステップbの説明に従ってファイルを作成します。
制御ファイルを作成し、エクスポートするエンティティのタイプを指定します。次の例に、すべてのカスタムのリソース・バンドル、jarファイル、およびプラグインをエクスポートすることを指定する制御ファイルのサンプルを示します。
<?xml version='1.0' encoding='UTF-8'?>
<MigrationDetails Operation ="Export">
<entityDetails>
<EntityType>CustomResourceBundles</EntityType>
<FilteringCriteria>
<Attribute>
<Name>Resource_Type</Name>
<Filter>*</Filter>
</Attribute>
</FilteringCriteria>
</entityDetails>
<entityDetails>
<EntityType>Jars</EntityType>
<FilteringCriteria>
<Attribute>
<Name>Jar_Type</Name><Filter>*</Filter>
</Attribute>
</FilteringCriteria>
</entityDetails>
<entityDetails>
<EntityType>Plugins</EntityType>
<FilteringCriteria>
<Attribute>
<Name>Type</Name><Filter>*</Filter>
</Attribute>
</FilteringCriteria>
</entityDetails>
</MigrationDetails>
スクリプトを実行します。ユーザー名、パスワードおよびJNDI URLの入力を求められたら、それらを指定します。JNDI URLはアプリケーションに接続するためのURLです。たとえば、t3://hostname:port)。
このスクリプトは、exportPackage_timestamp.zipという名前のzipファイルを作成します。このファイルは、ディレクトリexportPackage_timestampに作成されます。
本番環境で、ローカライゼーション・リソース・バンドル、および一連のプラグイン・コードをテスト環境からインポートします。
これらのエンティティをインポートするには、importMetadataを使用して、エンティティをzipファイルにインポートします。次の手順を実行します。
次のスクリプトを編集します。
(UNIX) OIM_ORACLE_HOME/server/bin/importMetadata.sh (Windows) OIM_ORACLE_HOME\server\bin\importMetadata.bat
スクリプトを編集して次の値を指定します。
CONTEXT: アプリケーションのURL。たとえば、weblogic.jndi.WLInitialContextFactory。
IMPORT_LOCATION: エクスポート操作で作成したzipファイルがあるディレクトリへの完全パス。
TEMP_LOCATION_TO_EXTRACT: zipファイル内のファイルがインポートされる前に抽出されるディレクトリへの完全パス。
スクリプトを実行します。ユーザー名、パスワードおよびJNDI URLの入力を求められたら、それらを指定します。JNDI URLはアプリケーションに接続するためのURLです。たとえば、t3://hostname:port)。
このスクリプトは、データを本番環境にインポートします。
Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドの手動でのリコンシリエーション・ポリシーの更新に関する項の説明に従って、カスタムのリコンシリエーション・ポリシーを移行します。
WLSTコマンドexportMetadataを使用して、カスタムのリコンシリエーション・プロファイルをテスト環境からエクスポートします。
connect('username','password',JNDI-URL')
exportMetadata(application='OIM', server='server_name',
toLocation='directory', docs='path_to_reconciliation_profiles')
エクスポートしたファイルを本番環境にコピーします。
WLSTコマンドimportMetadataを使用して、カスタムのリコンシリエーション・プロファイルを本番環境にインポートします。
connect('username','password',JNDI-URL')
importMetadata(application='OIM', server='server_name',
fromLocation='directory', docs='/**')
コネクタでは、本番環境で新しい定義を使用してアップグレードされる以前のバージョンの形式を必要とする、形式の変更がある場合、コネクタを移行してからForm Version Control(FVC)ユーティリティを実行します。詳細は、Connector Patch Readmeファイルのコネクタのアップグレードに関する項を参照してください。このReadmeファイルは、コネクタ配布メディアの最上位ディレクトリにあります。
監査ポリシーを新しい本番環境に移行するには、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の次の項目を参照してください。
「監査ポリシーの移行」
「監査ポリシーの管理」
Oracle Platform Securityを新しい本番環境に移行するには、ポリシー・ストアおよび資格証明ストアを移行します。
テスト環境のポリシー・ストアがファイルベースではない場合、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の手動でのポリシーの移行に関する項の説明に従って、WLSTコマンドmigrateSecurityStoreを使用してポリシー・ストアを移行します。
テスト環境の資格証明ストアがファイルベースではない場合、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の手動での資格証明の移行に関する項の説明に従って、WLSTコマンドmigrateSecurityStoreを使用して資格証明ストアを移行します。
Oracle Web Services Managerを使用している場合は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査ポリシーの移行に関する項の説明に従って、監査ポリシーを移行します。
Oracle Web Services Managerを新しい本番環境に移行するには:
作業12「Oracle Platform Securityの新しい本番環境への移行」の説明に従って、Oracle Platform Securityを本番環境に移行します。
Oracle Web Services Managerは、Oracle Platform SecurityおよびOracle Fusion Middleware監査フレームワークに依存します。Oracle Web Services Managerは、次の目的でOracle Platform Securityを使用します。
資格証明ストア: Oracle Web Services Managerは、クライアント・ポリシー・ユーザー名とパスワード資格証明およびキーストア・パスワードを資格証明ストアに格納します。
ポリシー・ストア: Oracle Web Services Managerの権限をベースとした認証ポリシーは、Oracle Platform Securityのポリシー・ストアを使用して権限を参照します。
ログイン・モジュール: Oracle Web Services Managerは、その認証すべてにOracle Platform Securityログイン・モジュールを使用します。
キーストアの構成。ただし、テスト環境のキーストアと本番環境のキーストアは通常異なります。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査ポリシーの移行に関する項の説明に従って、監査ポリシーを移行します。
MDSリポジトリに格納されていないポリシーを移行します。
カスタムビルド・ポリシーがある場合は、jarファイルをテスト環境から本番環境にコピーすることで、それらのポリシーを移行します。jarファイルは、次のディレクトリにあります。
DOMAIN_HOME/lib
ADF BCおよびOracle WebCenterポリシー・アタッチメントの場合は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の環境間でのアプリケーション移行の管理に関する項の説明に従ってそれらを移行します。
その他のポリシー添付ファイルは、Oracle WebLogic Serverのクローニング機能を使用している場合、アプリケーションとともに移行されます。
Oracle WebLogic Server JAX-WSアプリケーションでは、MDSではなく、wsm-seed-policies.jarに格納されたポリシーが使用されます。次のファイルをテスト環境から本番環境にコピーすることで、それらのポリシーを移行します。
ORACLE_HOME/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar
キーストアをテスト環境から本番環境に移行します。
秘密鍵は、テスト環境と本番環境で異なるため、移行する必要はありません。
公開鍵、中間証明書およびルート証明書は移行できます。Sun Microsystemsのjava keytoolのexportコマンドおよびimportコマンドを使用して、これらを移行します。
移行後、証明書を確認し、サービスを呼び出すクライアントに基づいて、本番環境で適用可能かどうかを確認します。
本番のキーストアの暗号化鍵の別名がテスト環境のキーストアと異なる場合、ポリシー構成のメッセージ保護を実行するすべてのポリシーのrcpt-key-aliasを更新する必要があります。
Fusion Middleware Controlからドメインを選択します。次に、「WebLogicドメイン」メニューで、「Webサービス」→「ポリシー」を選択します。ポリシーを選択し、「編集」をクリックします。別名を更新します。
|
関連項目: 『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』のポリシーの水平移行の管理に関する項 |
このシナリオでは、アイデンティティ管理コンポーネント(Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Web Services Managerなど)がテスト環境にインストール済で、これらをすでに存在している本番環境に移行する必要があると想定します。
既存の本番環境では、コンポーネントをインストールおよび構成済です。アプリケーションを、セキュリティ関連の構成を保持したままテスト環境から本番環境に移行する必要があります。この作業では、アプリケーション固有のデータをテストのアイデンティティ管理環境から本番のアイデンティティ管理環境に移行する必要があります。
アイデンティティ管理を既存の本番環境に移行するには、次の作業を実行します。
Oracle Internet Directoryを既存の本番環境に移行するには:
テスト環境でユーザーおよびグループを使用するように、Oracle Platform Securityを構成済の場合があります。テスト環境からユーザーおよびグループを移行するには、次の手順に従います。
テストのOracleホームから次のコマンドを実行して、テストのOracle Internet Directoryインスタンスのデフォルト・サブスクライバを特定します。
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Common,cn=Products,cn=OracleContext" -s base "objectclass=*" orcldefaultsubscriber
この問合せを実行すると、属性orcldefaultSubscriberの値が返されます。この値は、次の手順でdefault_subscriberとして使用されます。
テストのOracleホームから次のコマンドを実行して、テストのOracle Internet Directoryインスタンスからユーザーを取得します。
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -L -b "cn=users, default_subscriber" -s sub "objectclass=*" * orclguid > ldif_filename
本番のOracleホームから次のコマンドを実行して、本番のOracle Internet Directoryインスタンスにユーザーを移行します。
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
-r引数を指定して、データを移行し、競合を解決します。ldif_filenameは、前の手順で取得したファイルです。
テスト環境がステージング環境に設定されていて本番環境を模倣している場合、本番のOracle Internet DirectoryからテストのOracle Internet Directoryへの一方向レプリケーションを設定して、本番環境に存在しているすべてのユーザーおよびグループが、アプリケーションのテストに使用できるファンアウト・レプリカで使用できるようにすることをお薦めします。ファンアウト・レプリケーションは、本番と同期するテストのOracle Internet Directoryを保持し、リアルタイムで本番に追加されるすべてのユーザーおよびグループをレプリケートする機能も提供します。
ファンアウト・レプリケーションの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。
Oracle Internet Directoryレプリケーションの概要に関する項
Fusion Middleware Controlのレプリケーション・ウィザードを使用した一方向、双方向、またはマルチマスターのLDAPベース・レプリケーション承諾の設定に関する項
Oracle Forms ServicesまたはOracle Reportsを使用している場合、リソース・アクセス記述子(RAD)を移行します。この手順は、ステップ1の説明に従って、デフォルト・サブスクライバをテスト環境から本番環境に移行済であることを想定しています。また、テストのOracle Internet DirectoryのユーザーのorclGUIDが本番のOracle Internet Directoryと同じであることも想定しています。
次の手順に従います。
次のコマンドを使用して、テストのOracle Internet DirectoryインスタンスからRADを取得します。
ORACLE_HOME/bin/ldapsearch -h test_oid_host -w test_orcladmin_passwd -p test_oid_port -D "cn=orcladmin" -L -b "cn=Extended Properties,cn=OracleContext, default_subscriber" -s sub "objectclass=*" * orclguid > ldif_filename
次のコマンドを使用して、本番のOracle Internet DirectoryインスタンスにRADを移行します。
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
-r引数を指定して、データを移行し、競合を解決します。ldif_filenameは、前の手順で取得したファイルです。
このコマンドを実行すると、ファイルadd.logが、このコマンドを実行したディレクトリに生成されることに注意してください。add.logファイルで、RADの移行中に発生したエラーを確認します。エラーがある場合、エラーを修正し、コマンドを再実行してください。
このシナリオでは、テスト環境で行った増分変更を本番環境に移行します。
|
注意: テスト環境と本番環境の両方の管理サーバーを起動する必要があります。 |
ポリシー構成情報をテスト環境から本番環境にレプリケートするには:
環境変数JAVA_HOMEを設定し、JAVA_HOMEをPATHに追加します。
次のWLSTコマンドを使用して、テスト環境からポリシーをエクスポートします。
exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
ポリシー・ファイルを本番環境にコピーします。
次のWLSTコマンドを使用して、本番システムにポリシーをインポートします。
importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
次のWLSTコマンドを使用して、テスト環境からパートナ情報をエクスポートします。
exportPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
パートナ・ファイルを本番環境にコピーします。
次のWLSTコマンドを使用して、本番環境にパートナ情報をインポートします。
importPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
|
関連項目: Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのデルタ・レプリケーションに関する項 |
Oracle Access Manager 10gを既存の本番環境に移行するには:
本番環境で、Oracle Access Manager OAMCfgToolを使用して、アプリケーション用に同じポリシー・ドメインを作成します。次のコマンドが本番環境の値を指定していることを確認します。
web_domain (The Host identifier is derived from this entry) protected_uris="uri1,uri2,uri3" app_agent_password=password to be provisioned for the WebGate ldap_host=hostname_of_LDAP_server ldap_port=port_of_LDAP_server ldap_userdn=DN_of_LDAP_Admin_User ldap_userpassword=password_of_LDAP_Admin_User oam_aaa_host=host_of_OAM_server oam_aaa_port=port_of_OAM_server
uris_fileを使用してファイルにある保護されたURIおよび公開URIを指定している場合、ファイルを確認して正しいURIがリストされていることを確認します。
テスト環境のOracle Access Managerのエンティティ(ポリシー・ドメインなど)に対してその他の変更を行った場合、本番環境で同じタイプの変更を行います。
Oracle Identity Federationを既存の本番環境に移行するには:
Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのWLST環境の設定に関する項の説明に従って、テスト環境と本番環境の両方にWLST環境を設定します。
テスト環境で、次のスクリプトを実行して、パートナ・メタデータと構成プロパティを抽出します。
java weblogic.WLST extractPartnerMetadataAndProperties.py providerID outputFilePrefix
2つのファイル、outputFilePrefix_metadata.xmlとoutputFilePrefix_properties.txtが作成されます。
これらのファイルを本番システムにコピーします。
本番環境で、次のスクリプトを実行して、パートナ・メタデータと構成プロパティをインポートします。
java weblogic.WLST setPartnerMetadataAndProperties.py outputFilePrefix_metadata.xml outputFilePrefix_properties.txt description
テスト環境からパートナを削除している場合は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドの信頼できるプロバイダの削除に関する項の説明に従って、そのパートナを本番環境から削除します。
この他にも、本番環境にレプリケートする構成のうち、テスト環境で変更しているものがあれば、その変更を行います。詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドを参照してください。
Oracle Adaptive Access Managerを既存の本番環境に移行するには:
必要なデルタ・データをテスト環境から1つ以上のzipファイルにエクスポートします。次のタイプの項目をエクスポートできます。ポリシー、ルール条件、パターン、構成可能アクション、トランザクション、エンティティ、KBAの質問、KBAの検証、ルールで使用されるすべてのグループ・タイプ(アラート・グループ、アクション・グループ、ブラック・リスト・グループ、ホワイト・リスト・グループなど)。第21.4.1.1項の作業8「Oracle Adaptive Access Managerの新しい本番環境への移行」のステップ1を参照してください。
ステップ1で作成したzipファイルを本番環境にインポートします。第21.4.1.1項の作業8「Oracle Adaptive Access Managerの新しい本番環境への移行」のステップ2を参照してください。
次の項目について、必要に応じて本番環境を手動で更新します。
スナップショットのエクスポートおよびインポートはアクション・グループおよびアラート・グループをコピーするだけなので、グループ・メンバーをテスト環境からエクスポートし、本番環境にインポートする必要があります。
グループをエクスポートするには、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのグループのエクスポートに関する項を参照してください。
グループを本番環境にインポートするには、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのグループのインポートに関する項を参照してください。
oaam_extensions共有ライブラリを使用して、構成可能アクションのjarをパッケージ化します。
ヘッダー、フッター、カスケード・スタイル・シート(CSS)、JavaScriptなどの、OAAMサーバーでカスタマイズされた項目を、テスト環境から本番環境に手動でコピーします。これらの項目は、oaam_extensions共有ライブラリにあります。
Oracle Adaptive Access Manager管理コンソールを使用して、KBAロジック、OTPロジックおよびポリシー・セットのオーバーライドを手動で再作成します。Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。
プロパティ・ファイル、リソース・バンドルおよびエンド・ユーザーJSP画面をテスト環境から本番環境にコピーします。これらの項目は、oaam_extensions共有ライブラリにあります。
VADイメージをテスト環境から本番環境にコピーします。これはカスタムjar内にあります。
プロパティ・ファイル、リソース・バンドル、VADイメージおよびエンド・ユーザーJSP画面をテスト環境から本番環境にコピーします。
次の手順を実行して、移行が正常に行われたかどうかを検証します。
Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのOAAM管理コンソールとコントロールに関する項の説明に従って、OAAM管理コンソールにログインします。
ポリシーに移動し、既存のグループ・リンクを確認して、テスト環境から新しく追加したルールおよびグループが本番環境に存在することを確認します。
KBAモジュールに移動し、テスト環境に新しく追加したチャレンジ質問が本番環境に存在することを確認します。
Oracle Adaptive Access Manager用に構成されたWebアプリケーションをテストします。ユーザーは、登録およびチャレンジ・フローにリダイレクトされます。この動作は、テスト環境での動作と同じである必要があります。
Oracle Identity Managerを既存の本番環境に移行するには、第21.4.1.1項、作業10「Oracle Identity Managerの新しい本番環境への移行」の各手順に従います。
Oracle Identity Navigatorを既存の本番環境に移行するには、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドのOracle Identity Navigatorの管理に関する項の説明に従って、作業を行ってください。アイデンティティ・ストアおよびポリシー・ストアをすでに構成している場合は、それらを構成する必要はありません。
Oracle Platform Securityのポリシー・ストアと資格証明ストアの情報すべてをテスト環境から既存の本番環境に移行する必要があります。
テスト環境のポリシー・ストアがファイルベースではない場合、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のコマンドmigrateSecurityStoreを使用したポリシーの移行に関する項の説明に従って、WLSTコマンドmigrateSecurityStoreを使用してポリシー・ストアを移行します。
テスト環境の資格証明ストアがファイルベースではない場合、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のコマンドmigrateSecurityStoreを使用した資格証明の移行に関する項の説明に従って、WLSTコマンドmigrateSecurityStoreを使用して資格証明ストアを移行します。
本番のLDAPにあるユーザーおよびグループは、LDAPにあるユーザーおよびグループと異なる場合があります。Oracle Platform SecurityアプリケーションのロールとLDAPのロールの間にマッピングがあります。アプリケーションのロールは同じままの場合がありますが、LDAPグループへのマッピングは、本番環境の対応するLDAPグループに対してマップするように変更される可能性があります。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のアプリケーション・ロールの管理に関する項を参照してください。
Oracle Web Services Managerを使用している場合は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査ポリシーの移行に関する項の説明に従って、監査ポリシーを移行します。
Oracle Web Services Managerを既存の本番環境に移行するには:
MDSリポジトリに格納されているSOAコンポジット・アプリケーション、WebCenterまたはADFアプリケーションのポリシーを移行します。
Fusion Middleware Controlを使用してこれを実行する手順は次のとおりです。
テスト環境で、ドメインを選択します。次に、「WebLogicドメイン」メニューで、「Webサービス」→「ポリシー」を選択します。
ポリシーを選択し、「ファイルにエクスポート」をクリックします。
ポリシーがテスト環境上のファイルにコピーされます。
「ファイルの保存」→「OK」をクリックします。
ファイルの保存先のローカル・ディレクトリの場所に移動し、必要に応じてファイル名を更新します。「保存」をクリックします。
ファイルを本番環境にコピーします。
本番環境で、ドメインを選択します。次に、「WebLogicドメイン」メニューで、「Webサービス」→「ポリシー」を選択します。
「ファイルからインポート」をクリックします。ファイルを参照して選択し、「OK」をクリックします。
テスト環境で、ドメインを選択します。次に、「WebLogicドメイン」メニューで、「Webサービス」→「ポリシー」を選択します。
ページの右上にある「Webサービス・アサーション・テンプレート」をクリックします。
「ファイルにエクスポート」をクリックします。
「ファイルの保存」→「OK」をクリックします。
ファイルの保存先のローカル・ディレクトリの場所に移動し、必要に応じてファイル名を更新します。「保存」をクリックします。
本番環境で、ドメインを選択します。次に、「WebLogicドメイン」メニューで、「Webサービス」→「ポリシー」を選択します。
「ファイルからインポート」をクリックします。ファイルを参照して選択し、「OK」をクリックします。
ページの右上にある「Webサービス・アサーション・テンプレート」をクリックします。
「ファイルからインポート」をクリックします。ファイルを参照して選択し、「OK」をクリックします。
WLSTを使用してポリシーを移行するには:
テスト環境から、次のWLSTコマンドを実行します。
exportMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/assert_template_name', toLocation='/tmp/owsmexport/') exportMetadata(application='wsm-pm',server='server_name', docs='/policies/policy_name',toLocation='/tmp/owsmexport/')
/tmp/owsmexportディレクトリをテスト環境から本番環境にコピーします。
本番環境で、次のWLSTコマンドを実行します。
importMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/assert_template_name'', fromLocation='/tmp/owsmexport/') importMetadata(application='wsm-pm',server='server_name', docs='/policies/policy_name',fromLocation='/tmp/owsmexport/')
カスタムビルド・ポリシーがある場合は、jarファイルをテスト環境から本番環境にコピーすることで、それらのポリシーを移行します。jarファイルは、次のディレクトリにあります。
DOMAIN_HOME/lib
|
関連項目: 『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』のポリシーの水平移行の管理に関する項 |
Oracle WebLogic Server JAX-WSアプリケーションでは、MDSではなく、wsm-seed-policies.jarに格納されたポリシーが使用されます。次のファイルをテスト環境から本番環境にコピーすることで、それらのポリシーを移行します。
ORACLE_HOME/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar
Oracle WebLogic Server管理コンソールを使用して、これらのポリシーを移行することもできます。
SOA、ADFまたはWebCenterのアプリケーションが最初に本番環境にデプロイされて以降、このアプリケーションのポリシー添付ファイルが変更されている場合は、これらの添付ファイルを移行します。たとえば、ポリシーAは当初、BASIC 128アルゴリズムを使用してテスト環境で構成され、HelloWorldアプリケーションに添付されたとします。このアプリケーションを本番環境にデプロイしました。続いて、テスト環境で、Basic 129アルゴリズムを使用するようにポリシーAを変更しました。
JAX-WSアプリケーションが最初にデプロイされて以降、このアプリケーションのポリシー添付ファイルが変更された場合、これらの添付ファイルを移行します。
次の各項目では、Oracle SOA Suiteをテスト環境から本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
Oracle WebLogic Serverをインストールし、Middlewareホームを作成しました。
RCUを使用して、テスト・データベースで必要なスキーマを作成しました。
Oracle SOA Suiteをインストールしました。
構成ウィザードを使用してOracle SOA Suiteを構成しました。
環境で必要な場合は、Oracle Internet Directory、Oracle Platform Security、Oracle Web Services Managerなどのアイデンティティ管理コンポーネントをインストールして構成しました。
セキュリティ・ポリシーを構成しました。
1つ以上のアプリケーションまたはSOAコンポジット・アプリケーションをデプロイしました。これらのアプリケーションには、内部参照および外部参照があります。
構成設定の一部を変更しました。たとえば、MDSの構成ディレクトリまたは別のデータソースのなんらかの設定を変更した可能性があります。
オプションで、Oracle Business Activity Monitoring用の、Oracle WebLogic Serverに依存する次のようなアーティファクトを構成しました。
BAMアダプタ
データベースまたはJMS用のデータソース
Oracle Business Activity Monitoringユーザー用のアイデンティティ・ストアを構成および移入しました。
テスト環境で、UMSおよび必要なすべてのサブコンポーネントを設定し、UMSドライバとユーザー・プリファレンスを構成しました。
|
注意: Oracle User Messaging Service (UMS)は、SOAシナリオおよびBAMシナリオで使用されます。この機能およびアクションは、両方のシナリオにおいて似ていますが、小さな相違点があります。特にBAMでは、電子メール・ドライバのみがサポートされます。したがって、UMSの再構成手順は電子メール・ドライバにのみ適用されます。また、このリリースでは、BAMはUMSユーザー・プリファレンスを使用しません。したがって、UMS移行でのuserpref移行は、BAMには適用されません。UMSをテスト環境から本番環境に移行する方法の詳細は、作業7を参照してください。 |
|
関連項目: Oracle SOA Suite用のエンタープライズ・デプロイメントの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』 |
Oracle SOA Suiteを新しい本番環境に移行するには、次の作業を実行します。
データベースおよびMiddlewareホームを移行して初期構成を実行するには:
第21.3.2項の説明に従って、データベースとスキーマを移行または作成します。
第21.4.項の説明に従って、アイデンティティ管理コンポーネントを移行します。
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
第21.3.4項の説明に従って、構成を移行します。
構成を移行すると、pasteConfigスクリプトによって、ドメイン、管理サーバーおよび管理対象サーバーを含むドメインの構成がコピーされます。また、その手順では次のことも行われます。
SOAコンポジット・アプリケーションの移行
Oracle Human Workflowの属性ラベル、フレックス・フィールド・マッピング、承認グループおよび標準ビューの移行
移行計画で提供された値に基づく、LDAPまたはデータベース・ベース・ストアへのセキュリティ・ストアの再関連付け
Oracle Platform Securityの移行
Oracle Web Services Manager、MDSリポジトリまたはデプロイ・プランに格納されているすべてのポリシー、およびDOMAIN_HOME/libに格納されているすべてのカスタム・ポリシーの移行
本番環境へのアプリケーションのデプロイ
アダプタ(データベース・アダプタ、AQアダプタ、JMSアダプタなど)の構成。ただし、pasteConfigスクリプトを使用する前に、アダプタのデプロイ・プランを編集する必要があることに注意してください。
データソースの構成
JMSリソースの構成
管理サーバーの起動
第21.3.項の説明に従って、ユーザー、グループ、セキュリティ・ポリシーおよび資格証明ストアを構成します。
|
関連項目: Oracle SOA Suite用のエンタープライズ・デプロイメントの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』 |
インバウンド・ファイルまたはアウトバウンド・ファイルのディレクトリ構造を作成します。たとえば、/tmp/inbound_msgディレクトリからインバウンド・ファイルを読み取り、/tmp/outbound_msgディレクトリにアウトバウンド・ファイルを書き込むファイル・アダプタを使用している場合、これらのディレクトリを本番環境に作成します。同様に、Oracle B2Bが/tmp/inboundディレクトリからインバウンド・メッセージを読み取り、/tmp/outboundディレクトリにアウトバウンド・メッセージを書き込むリスナー・チャネルを使用している場合、これらのディレクトリを作成します。
B2BエンドポイントのすべてのJKS証明書をテスト環境から本番環境にエクスポートします。次に、これらを本番環境にインポートします。JKS証明書のエクスポートおよびインポートの詳細は、第8.3.3項を参照してください。
テスト環境から本番環境にドメインのコピーを移行した場合は、スクリプトにより次のヒューマン・ワークフロー・エンティティが移行されています。
属性ラベル
フレックス・フィールド・マッピング
承認グループ
標準ビュー
スクリプトでは、次のものは移行されません。
ユーザー・ビュー
ルール
ヒューマン・ワークフローのユーザー・ビューとロールを新しい本番環境に移行するには:
Data Migratorを使用して、ヒューマン・ワークフローのユーザー・メタデータ(ユーザー・ビュー、休暇ルールなど)をテスト環境から本番環境に移行します。Data Migratorは、コマンドラインで実行できるantターゲットとして使用できます。これは、データの移行用の入力パラメータを指定して作成されるプロパティ・ファイル(migration.properties)をコールします。
migration.propertiesファイルには、次の入力パラメータが含まれています。
operationType = {EXPORT | IMPORT}
objectType = {VIEW | RULE | APPROVAL_GROUP | TASK_PAYLOAD_FLEX_FIELD_MAPPING}
name = name of VIEW or APPROVAL_GROUP or TASK_PAYLOAD_FLEX_FIELD_MAPPING
user = username of VIEW or RULE
group = groupname for RULE
grantPermission = {true | false}
migrateAttributeLabel = {true | false}
override = {true | false}
skip = {true | false}
migrateToActiveVersion = {true | false}
次のスクリプトを使用します。
ORACLE_HOME/bin/ant-t2p-worklist.xml
コマンドの形式は次のとおりです。
ant -f ant-t2p-worklist.xml
-Dbea.home=BEA_HOME
-Dsoa.home=SOA_HOME
-Dmigration.properties.file=MIGRATION_PROPERTY_FILE_PATH
-Dsoa.hostname=SOA_HOSTNAME
-Dsoa.rmi.port=SOA_RMI_PORT
-Dsoa.admin.user=SOA_ADMIN_USER
-Dsoa.admin.password=SOA_ADMIN_PASSWORD
-Drealm=REALM
-Dmigration.file=MIGRATION_FILE
-Dmap.file=MAP_FILE
移行ユーティリティの詳細は、『Oracle Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド』のユーザー・メタデータ移行ユーティリティの使用方法に関する項を参照してください。
次の手順に従います。
PATH環境変数に、必要なJAVA_HOMEおよびANT_HOME環境変数が含まれており、それらがOracle SOA Suiteインストール内の場所を指していることを確認してください。
migration.propertiesファイルを作成して、ワークリスト・アプリケーションのユーザー・メタデータ(ルール、ユーザー・ビュー、休暇ルールなど)をテスト環境からエクスポートします。migration.propertiesファイルは任意の場所に作成できます。次の点に注意してください。
一度に1タイプのデータのみエクスポートできます。
特定のユーザーまたはグループのデータをエクスポートしている場合、それらを別々の操作で移行する必要があります。
たとえば、特定のユーザーのすべてのルールをエクスポートするには、migration.propertiesファイルに次の値が含まれます。
operationType = EXPORT
objectType = RULE
name = ALL
user = username
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false
特定のユーザーのルールをエクスポートする場合は、パラメータgroupはブランクのままであることに注意してください。
特定のグループのすべてのルールをエクスポートするには、migration.propertiesファイルに次の値が含まれます。
operationType = EXPORT objectType = RULE name = ALL user = group = LoanAgentGroup grantPermission = true migrateAttributeLabel = false override = true skip = true migrateToActiveVersion = false
特定のグループのルールをエクスポートする場合は、パラメータuserはブランクのままであることに注意してください。
データをエクスポートします。次の例は、コマンドを呼び出し、パラメータを指定する方法を示しています。
ant -f ant-t2p-worklist.xml -Dbea.home=/scratch/oracle/MW_HOME -Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA -Dmigration.properties.file=migration.properties -Dsoa.hostname=hostname -Dsoa.rmi.port=7001 -Dsoa.admin.user=weblogic -Dsoa.admin.password=password -Drealm=jazn.com -Dmigration.file=/tmp/export_all_userRules.xml -Dmap.file=/tmp/export_all_userRules_mapper.xml
アプリケーションが本番環境にデプロイされたことを確認します。
migration.propertiesファイルを作成して、ワークリスト・アプリケーションのユーザー・メタデータを本番環境にインポートします。次の点に注意してください。
一度に1タイプのデータのみインポートできます。
特定のユーザーまたはグループのデータをインポートしている場合、それらを別々の操作でインポートする必要があります。
たとえば、特定のユーザーのすべてのルールをインポートするには、migration.propertiesファイルに次の値が含まれます。
operationType = IMPORT
objectType = RULE
name = ALL
user = username
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false
特定のユーザーのルールをインポートする場合は、パラメータgroupはブランクのままであることに注意してください。
特定のグループのすべてのルールをインポートするには、migration.propertiesファイルに次の値が含まれます。
operationType = IMPORT objectType = RULE name = ALL user = group = LoanAgentGroup grantPermission = true migrateAttributeLabel = false override = true skip = true migrateToActiveVersion = false
特定のグループのルールをインポートする場合は、パラメータuserはブランクのままであることに注意してください。
前の手順で作成したファイルexport_all_userRules.xmlから本番環境にデータをインポートします。次の例は、コマンドを呼び出し、パラメータを指定する方法を示しています。
ant -f ant-t2p-worklist.xml -Dbea.home=/scratch/oracle/MW_HOME -Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA -Dmigration.properties.file=migration.properties -Dsoa.hostname=hostname -Dsoa.rmi.port=7001 -Dsoa.admin.user=weblogic -Dsoa.admin.password=password -Drealm=jazn.com -Dmigration.file=/tmp/export_all_userRules.xml -Dmap.file=/tmp/export_all_userRules_mapper.xml
データ(ルール、ビューなど)がユーザーに添付されている場合、このユーザーは、本番のSOAサーバーで使用可能なユーザーである必要があることに注意してください。
任意の.earファイルをデプロイするように、Java EEヒューマン・タスク・フォームをデプロイします。詳細は、第10.3.1項を参照してください。
必要に応じて、本番メール・サーバーおよびインバウンド/アウトバウンド電子メール・アカウントで、ワークフロー通知の構成を更新します。『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する項を参照してください。
Oracle Business Activity Monitoringを新しい本番環境に移行するには:
テスト環境で、次のコマンドを使用してORACLEBAMデータベース・スキーマをエクスポートします(ORACLE_HOMEは、Oracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to oraclebam; exit; ORACLE_HOME/bin/expdp userid=oraclebam/bam@connect_id directory=directory dumpfile=orabam.dmp schemas=oraclebam logfile=oraclebam_date.log
|
関連項目: Oracle Databaseユーティリティ(次のサイトにあります)の「Oracleデータ・ポンプの概要」およびOracleデータ・ポンプに関するその他の章
|
テスト環境からOracle BAMオブジェクト(レポート、アラート、データ定義など)がエクスポートされます。
Oracle Internet Directoryの認証プロバイダがテスト環境で設定されていない場合は、設定を行います。(テスト環境で設定されている場合は、構成の移行によって本番環境にその構成が移行されます。)
Oracle WebLogic Server管理コンソールから、「セキュリティ・レルム」→「myrealm」→「プロバイダ」を選択します。
デフォルトの認証プロバイダは、レルム用に構成されています。
「新規」をクリックして、新しい認証プロバイダを追加します。
Oracle Internet Directoryに対してユーザーを認証するプロバイダのプロバイダ名(OIDAuthenticatorなど)を入力します。
「タイプ」でOracleInternetDirectoryAuthenticatorを選択します。
「OK」をクリックします。
「プロバイダ」タブで、新しく作成されたOIDAuthenticatorをクリックします。
「制御フラグ」で「十分」を選択し、この認証プロバイダによってユーザーを正常に認証できる場合、その認証を受け入れ、続いて追加の認証プロバイダの呼び出しを行う必要がないことを示します。
「プロバイダ固有」タブを選択します。
LDAPプロバイダの詳細を入力します。
「保存」をクリックします。
「プロバイダ」タブで、新しく作成した認証プロバイダが最初になるように認証プロバイダを並べ替えます。
管理サーバーおよび管理対象サーバーを再起動します。
BAMデータおよびアーティファクトを本番環境に移行します。
ldifファイルをインポートして、BAM JPSルート・コンテキストを作成します。次に、ldifファイルのサンプルを示します。
dn: cn=jpsroot_bam_test,dc=us,dc=oracle,dc=com cn: jpsroot_bam_test objectclass: top objectclass: orclcontainer
Fusion Middleware Controlを使用して、BAMアプリケーション・ポリシーおよびロールをLDAPに移行します。
ナビゲーション・ペインで、Oracle Business Activity Monitoringを含むドメインを右クリックし、「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したドメイン・ストアの再関連付けに関する項の手順に従います。
次のコマンドを使用して、テスト環境からエクスポートしたORACLEBAMデータベース・スキーマをインポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/impdp userid=system/password dumpfile=ORACLEBAM.DMP remap_schema=oraclebam:oraclebam TABLE_EXISTS_ACTION=replace ORACLE_HOME/bin/sqlplus "sys/password as sysdba" alter user oraclebam account unlock; alter user oraclebam identified by bam;
impdpが次のエラーをレポートする場合があることに注意してください。
ORA-00959: 表領域<source tablespace>は存在しません
このエラーは、インポートする前にインポート・データベースに表領域を作成するか、またはREMAP_TABLESPACESを使用して、表定義で参照される表領域をインポート・データベースの表領域に変更することにより修正できます。
11.2.0.2以前のバージョンのOracle Databaseを使用すると、索引統計のリストアで障害が発生する場合があります。この問題は、インポート後に索引統計を再作成することにより回避できます。
『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する項の説明に従って、本番環境で電子メール・サーバー構成を変更します。
Oracle Business Activity Monitoringの管理対象サーバーを再起動します。
Oracle Business Process Managementを新しい本番環境に移行するには、移行ツールを使用してOracle Business Process Managementのユーザー・メタデータ(組織、ダッシュボードなど)をテスト環境から本番環境に移行します。移行ツールは、コマンドラインで実行できるantターゲットとして使用できます。これは、データの移行用の入力パラメータを指定して作成される構成ファイルをコールします。
テスト環境内と本番環境内のユーザーは同じではないため、移行ツールでは、ユーザー固有の構成は移行されないことに注意してください。
次のスクリプトを使用します。
ORACLE_HOME/bin/ant-t2p-workspace.xml
コマンドの形式は次のとおりです。
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE
組織については、本番環境に移行されるオブジェクトは、組織単位、ロール、カレンダ、組織ロールおよび拡張ユーザー・プロパティです。
ダッシュボードについては、BPMUserApplicationData表内の、データ型がBAM_WIDGETであるデータが本番環境に移行されます。
次の手順に従います。
PATH環境変数に、必要なJAVA_HOMEおよびANT_HOME環境変数が含まれており、それらがOracle SOA Suiteインストール内の場所を指していることを確認してください。
組織およびダッシュボードをエクスポートします。
構成ファイルを作成して組織をエクスポートします(そのファイルをantコマンドに渡します)。
次に、組織をエクスポートする構成ファイルのサンプルを示します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
<sourceEndPoint>
<serverEndPoint>
<serverURL>t3://hostname:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</sourceEndPoint>
<targetEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_organization.xml</migrationFile>
</fileEndPoint>
</targetEndPoint>
<operation>EXPORT</operation>
<object>ORGANIZATION</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<organization/>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、次の要素でテスト環境用の値を指定する必要があります。
migrationFile: この要素は、エクスポート操作によって生成されたファイルを指定します。
serverURL: SOAサーバーのURL
adminUserLogin
adminUserPassword
objectDetails: ログインおよびパスワード要素を更新します。
次のコマンドを使用して、組織をエクスポートします。
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
構成ファイルを作成してダッシュボードをエクスポートします。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
<sourceEndPoint>
<serverEndPoint>
<serverURL>t3://hostname:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</sourceEndPoint>
<targetEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</targetEndPoint>
<operation>EXPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username</ownerId>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、次の要素でテスト環境用の値を指定する必要があります。
serverURL: SOAサーバーのURL
adminUserLogin
adminUserPassword
migrationFile: この要素は、エクスポート操作によって生成されたファイルを指定します。
objectDetails: ログインおよびパスワード要素を更新します。
userApplicationData: ownerID要素を更新します。
次のコマンドを使用して、ダッシュボードをエクスポートします。
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
組織およびダッシュボードをインポートします。
構成ファイルを作成して組織をインポートします(そのファイルをantコマンドに渡します)。
次に、組織をインポートする構成ファイルのサンプルを示します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
<sourceEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_organization.xml</migrationFile>
</fileEndPoint>
</sourceEndPoint>
<targetEndPoint>
<serverEndPoint>
<serverURL>t3://hostname:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</targetEndPoint>
<operation>IMPORT</operation>
<object>ORGANIZATION</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<organization/>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、本番環境用の値を使用して次の要素を更新する必要があります。
migrationFile: この要素は、エクスポート操作によって生成されたファイルを指定します。
serverURL: SOAサーバーのURL
adminUserLogin
adminUserPassword
objectDetails: ログインおよびパスワード要素を更新します。
次のコマンドを使用して、組織をインポートします。
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
構成ファイルを作成してダッシュボードをインポートします。形式は、次の行を置換する以外は組織用と同じです。
<sourceEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</sourceEndPoint>
<targetEndPoint>
<serverEndPoint>
<serverURL>t3://hostname:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</targetEndPoint>
<operation>IMPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username</ownerId>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
構成ファイルでは、本番環境用の値を使用して次の要素を更新する必要があります。
serverURL: SOAサーバーのURL
adminUserLogin
adminUserPassword
migrationFile: この要素は、エクスポート操作によって生成されたファイルを指定します。
objectDetails: ログインおよびパスワード要素を更新します。
userApplicationData: ownerID要素を更新します。
次のコマンドを使用して、ダッシュボードをインポートします。
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
UMSの詳細を新しい本番環境に移行するには:
本番環境で必要なUMSドライバを構成します。
Fusion Middleware Controlで、本番環境のドライバ情報を使用してUser Messaging Serviceを構成します。
WLSTコマンドdeployUserMessagingDriverを使用して、テスト環境と同様に複数のドライバをデプロイします。
|
注意: その他のドライバをデプロイする別のオプションを確認するには、wls:/offline>プロンプトでhelp('deployUserMessagingDriver')を実行してください。 |
本番環境で、カスタム作成済のビジネス条件を再作成します。この手順は、本番環境で一連の同じユーザー・プリファレンス・フィルタ設定が使用されるようにし、カスタムのビジネス条件が指定されているフィルタが確実に機能するようにするためには必須です。
本番環境を再起動して変更を適用します。
ユーザー・メッセージング・プリファレンスをテスト環境から本番環境に移行します。
テスト環境で、次のWLSTコマンドを実行して、ユーザー・メッセージング・プリファレンスをバックエンド・データベースから指定した.xmlファイルにダウンロードします。
wls:/offline> manageUserMessagingPrefs(operation='download',
filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001',
username='username', password='password')
この例では、8001が、UMSが実行されている管理対象サーバーのポートです。これを適切な値に置き換えてください。
/tmp/userprefs-dump.xmlファイルを本番環境にコピーします。
本番環境で、次のWLSTコマンドを実行して、ユーザー・メッセージング・プリファレンスをファイルからバックエンド・データベースにアップロードします。
wls:/offline> manageUserMessagingPrefs(operation='upload', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='username', password='password')
この例では、8001が、UMSが実行されている管理対象サーバーのポートです。これを適切な値に置き換えてください。
表示されるメッセージで正常にアップロードされたかどうかを確認します。WLSTコマンドライン・ツールを終了します。
|
注意: ダウンロード操作およびアップロード操作を実行する別のオプションを確認するには、wls:/offline>プロンプトでhelp('manageUserMessagingPrefs')を実行します。LDAPストアにプロビジョニングされるユーザー・デバイスは動的であることに注意してください。テスト環境と本番環境の両方が同じLDAPストアを指すこと、または同じ情報セットを使用するように再構成されたことを想定しています。 |
UMSドライバで、サポートされているドライバに対する送受信機能をテストします。
http://host:port/sdpmessaging/userprefs-ui URLを呼び出して、ユーザー・メッセージング・プリファレンスが正常にアップロードされるかどうかをテストします。目的のユーザーとしてログインし、メッセージング・チャネルとフィルタがテスト環境におけるものと同じであるかどうかを検証します。または、ユーザー・メッセージング・プリファレンスに基づいて配信されると予想されるメッセージの送受信を行います。
pasteConfig操作では、SSLが無効化されます。さらに、本番環境でカスタム・キーストアは作成されません。次の手順を実行します。
このシナリオでは、稼働中の本番環境があり、アプリケーションまたは構成の変更を、本番環境への適用前にテストする必要があると想定します。テスト環境に、第21.4.2項で説明した環境と同じ環境があるものとします。
Oracle SOA Suiteを既存の本番環境に移行するには:
Oracle SOA Suiteに加えたすべての変更を移行します。
テスト環境にユーザーおよびグループを追加したか、またはセキュリティ・ポリシーや資格証明を変更した場合は、第21.3.6項の各手順に従って、これらを本番環境に移行します。
コンポジット参照をサポートするテスト環境でEJBまたはPlain Old Java Object (POJO)を変更した場合、これらを本番環境に移行します。
EJBモジュールをデプロイするには、Oracle WebLogic Server管理コンソールのオンライン・ヘルプのEJBモジュールのデプロイに関する項を参照してください。
エンタープライズ・アプリケーションをデプロイするには、Oracle WebLogic Server管理コンソールのオンライン・ヘルプのエンタープライズ・アプリケーションの使用に関する項を参照してください。
テスト環境でヒューマン・ワークフローに変更を加えた場合は、それらの変更を本番環境に移行します。『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のヒューマン・ワークフロー・データのテスト環境から本番環境への移動に関する項を参照してください。
構成プランの情報を変更した場合は、それらの変更を本番環境にコピーします。構成プランの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の開発、テストおよび本番環境間のSOAコンポジット・アプリケーションの移動に関する項を参照してください。
テスト環境でOracle B2Bに変更を加えた場合は、それらの変更を本番環境に移行します。
tpanamesパラメータを使用して選択的にアグリーメントをエクスポートする場合、各zipファイルを個別にインポートする必要があることに注意してください。
Oracle B2Bインタフェースを使用してプロパティを構成することにより、Oracle B2Bシステム構成パラメータを移行します。詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のシステム・パラメータの構成に関する項を参照してください。
『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のB2B構成のプロパティの設定に関する項の説明に従って、B2Bコマンドラインを使用してその他の構成プロパティを移行します。
B2Bアグリーメントおよび取引パートナを本番環境に移行します。
データをテスト環境からエクスポートします。次の例では、デプロイされた複数のアクティブなアグリーメントがエクスポートされます。
ant -f ant-b2b-util.xml b2bexport -Dtpanames="Acme_GC_Agreement1,
GC_Acme_Agreement1" -Dactive=true -Dexportfile="/tmp/export.zip"
データを本番環境にインポートします。次の例では、ファイル/tmp/export.zip内の要素がインポートされます。
ant -f ant-b2b-util.xml b2bimport -Dlocalfile=true
-Dexportfile="/tmp/export.zip"
これらのコマンドの詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のB2Bコマンドライン・ツールに関する項を参照してください。
『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のチャネルの構成に関する項の説明に従って、本番のロケーションおよび資格証明を使用してB2Bアグリーメントの外部エンドポイントを構成します。
Oracle B2B環境がJavaコールアウトを使用して構成されている場合、コールアウト・ライブラリを手動で移行します。『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のコールアウトの管理に関する項を参照してください。
『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のアグリーメントのデプロイに関する項の説明に従って、B2Bアグリーメントをデプロイします。
テスト環境でOracle Business Process Managementに変更を加えた場合は、それらの変更を本番環境に移行します。
Oracle Business Process Managementを既存の本番環境に移行するには、第21.4.2.1項の作業6「Oracle Business Process Managementの新しい本番環境への移行」の説明に従って、移行ツールを使用してOracle Business Process Managementのユーザー・メタデータ(組織、ダッシュボードなど)をテスト環境から本番環境に移行します。
変更されたOracle BAMデータをすべて移行するには:
icommandを使用して、Oracle BAMアーティファクトをテスト環境からエクスポートします。このコマンドは、次のディレクトリにあります。
(UNIX) ORACLE_HOME\bam\bin\icommand.sh (Windows) ORACLE_HOME\bam\bin\icommand.bat
例:
icommand -cmd export -type dataobject -all 1 -PERMISSIONS 1 -OWNER 1 -file dataobject.xml icommand -cmd export -type folder -all 1 -PERMISSIONS 1 -OWNER 1 -file folder.xml icommand -cmd export -type report -all 1 -file reports.xml icommand -cmd export -type rule -all 1 -file rules.xml icommand -cmd export -type ems -all 1 -file ems.xml icommand -cmd export -type eds -all 1 -file eds.xml
特定のタイプのすべてのアーティファクトをエクスポートするほかに、個別のアーティファクトをエクスポートできます。icommandを使用してアーティファクトをエクスポートする方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のエクスポートに関する項を参照してください。
ldapsearchコマンドを使用して、テスト環境のLDAPアイデンティティ・ストアからBAMユーザーをエクスポートします。これにより、後で本番環境のLDAPアイデンティティ・ストアにインポートするldifファイルが作成されます。ldapsearchコマンドは、アイデンティティ管理コンポーネントのORACLE_HOME/binディレクトリにあります。例:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
BAMデータおよびアーティファクトを本番環境にインポートします。
Oracle BAM Architectを使用して、デフォルトで設定されているルールを非アクティブ化します。『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のアラート・ルールのアクティビティ・ステータスの変更方法に関する項を参照してください。
作業5「Oracle Business Activity Monitoringデータの新しい本番環境への移行」のステップ2の説明に従って、LDAPセキュリティ・プロバイダをデフォルトのプロバイダにします(まだ実行していない場合)。
本番環境で、テスト環境からOracle Internet DirectoryなどのLDAPプロバイダにエクスポートしたldifファイルから、BAMユーザーをインポートします(ORACLE_HOMEはアイデンティティ管理のOracleホームです)。
ORACLE_HOME/bin/ldapadd -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w production_orcladmin_passwd -vf ldif_filename
Fusion Middleware Controlを使用して、BAMアプリケーション・ポリシーおよびロールをLDAPに移行します。
ナビゲーション・ペインで、Oracle BAMを含むドメインを右クリックし、「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したドメイン・ストアの再関連付けに関する項の手順に従います。
icommandを使用して、Oracle BAMアーティファクトをインポートします。このコマンドは、次のディレクトリにあります。
(UNIX) ORACLE_HOME\bam\bin\icommand.sh (Windows) ORACLE_HOME\bam\bin\icommand.bat
例:
icommand -cmd import -file dataobject.xml -UPDATELAYOUT 1 -MODE UPDATE -CONTINUEONERROR icommand -cmd import -file folder.xml -MODE OVERWRITE -PRESERVEOWNER icommand -cmd import -file reports.xml -MODE OVERWRITE -PRESERVEOWNER icommand -cmd import -file ems.xml -MODE OVERWRITE icommand -cmd import -file eds.xml -MODE OVERWRITE
BAMサーバーを起動します。
Oracle User Messaging Serviceデータを移行します。
本番環境で必要なUMSドライバを構成します。
|
注意: Oracle User Messaging ServiceをLDAPストアに対して構成された既存の本番環境に移行する間、Userprefs-UIオプションのみを使用してユーザー・プリファレンスを変更してください。WLSTコマンド(manageUserMessagingPrefs)の使用は、テスト・インスタンスから削除されたアイデンティティ・ストアのデバイス・プリファレンスを正しく移行しない場合があるため、お薦めしません。 |
Fusion Middleware Controlで、本番環境のドライバ情報を使用してUser Messaging Serviceを構成します。
WLSTコマンドdeployUserMessagingDriverを使用して、テスト環境と同様に複数のドライバをデプロイします。
|
注意: その他のドライバをデプロイする別のオプションを確認するには、wls:/offline>プロンプトでhelp('deployUserMessagingDriver')を実行してください。 |
本番環境で、カスタム作成済の ビジネス条件 を再作成します。この手順は、本番環境で一連の同じ ユーザー・プリファレンス ・フィルタ設定が使用されるようにし、カスタムのビジネス条件が指定されているフィルタが確実に機能するようにするためには必須です。
本番環境を再起動して変更を適用します。
ユーザー・メッセージング・プリファレンスをテスト環境から本番環境に移行します。フィルタを更新したり、既存のフィルタ・セットに追加したりすることはできません。次のいずれかを実行する必要があります。
テスト環境でフィルタへの変更を行う場合、フィルタ・セット全体を削除し、新しいセットをアップロードします。
テスト環境で新しく作成されたか、または変更されたユーザー・デバイスおよびフィルタは、本番環境で次のURLを使用して作成または変更する必要があります。
http://host:port/sdpmessaging/userprefs-ui
UMSドライバで、サポートされているドライバに対する送受信機能をテストします。
http://host:port/sdpmessaging/userprefs-ui URLを呼び出して、ユーザー・メッセージング・プリファレンスが正常にアップロードされるかどうかをテストします。目的のユーザーとしてログインし、メッセージング・チャネルとフィルタがテスト環境におけるものと同じであるかどうかを検証します。または、ユーザー・メッセージング・プリファレンスに基づいて配信されると予想されるメッセージの送受信を行います。
次の各項目では、Oracle WebCenterをテスト環境から本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
Oracle WebLogicサーバーをインストールしました。
Oracle WebCenterをインストールしました。
RCUを使用して、テスト・データベースで必要なスキーマを作成しました。
Oracle SOA Suiteをインストールして構成しました。
構成ウィザードを使用してOracle WebCenterを構成しました。ドメインおよび管理対象サーバーを作成し、Oracle WebCenter Spaces、Oracle WebCenterポートレット、Oracleディスカッション、Oracle WebCenter Wikiおよびブログ・サーバーを構成しました。
Oracle Universal Content Managementをインストールして構成しました。
アイデンティティ管理コンポーネント(Oracle Internet Directory、Oracle Identity Federation、Oracle Access Managerなど)をインストールしました。
グループ・スペースを構成しました。
LDAPを使用するようにOracle WebCenterを構成し、組込みのLDAPまたはLDAPストアに一部のユーザーおよびグループを作成しました。
Oracle Platform Security Servicesの必須のポリシーをポリシー・ストアに作成しました。
必須のユーザー証明書を資格証明ストアに作成しました。
カスタムWebCenterアプリケーションを作成してデプロイしました。
インスタンス・データをWebCenter Spacesアプリケーションに作成し(対象コミュニティ・テンプレートに基づくグループ・スペースの作成を含む)、サービスのプロビジョニングを行いました。さらに、一部のロールを作成し、それらのロールに新しいメンバーを割り当てました。
Oracle WebCenterを新しい本番環境に移行するには、次の作業を実行します。
データベースおよびMiddlewareホームを移行して初期構成を実行するには:
第21.3.2項の説明に従って、データベースを移行または作成します。
第21.4.項の説明に従って、アイデンティティ管理コンポーネントを移行します。
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
Oracle Universal Content ManagementはWebサーバーを必要とするため、第21.4.6.1.1項の説明に従って、Oracle HTTP Serverを移行します。
第21.3.4項の説明に従って、構成を移行します。
構成を移行すると、pasteConfigスクリプトによって、ドメイン、管理サーバーおよび管理対象サーバーを含むドメインの構成がコピーされます。また、その手順では次のことも行われます。
WebCenter Spacesの外部アイデンティティ・ストアへの関連付け
WebCenter SpacesおよびWebCenter Frameworkの場合、Oracle WebLogic Serverにおけるアイデンティティ管理用の認証プロバイダの作成
WebCenter SpacesおよびWebCenter Frameworkの場合、ポリシー・ストアと資格証明ストアの再関連付け
WebCenter Spacesの場合、アプリケーション・プロデューサ・データの移行
WebCenter Spacesの場合、テスト環境から本番環境へのポートレットのカスタマイズ、パーソナライズおよびメタデータの移行
テスト環境から本番環境へのポリシー・ストアと資格証明ストアのデータの移行
テスト環境から本番環境へのカスタムOracle WebCenter Frameworkアプリケーション・メタデータの移行
管理サーバーの起動
第21.3.項の説明に従って、ユーザー、グループ、セキュリティ・ポリシーおよび資格証明ストアを構成します。
WebCenter Spacesアプリケーションおよびこのアプリケーションに必須のデータをテスト環境からエクスポートします。
必要に応じて、WebCenter Spacesアプリケーションの必須データ(コンテンツ・サーバー、ディスカッション・フォーラムなど)をエクスポートします。
次のコマンドを実行して、Oracle Content Serverをエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_OCSERVER directory=directory dumpfile=filename
|
関連項目: Oracle Databaseユーティリティ(次のサイトにあります)のOracleデータ・ポンプに関する章。
|
Oracle Databaseのエクスポート・ユーティリティを使用して、ディスカッション・フォーラムをエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" OWNER=prefix_DISCUSSIONS FILE=/tmp/df.dmp statistics=none
詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのデータ移行のためのWebCenter Spacesアプリケーションのエクスポートとインポートに関する項を参照してください。
第21.4.2項の説明に従って、Oracle SOA Suiteをテスト環境から本番環境に移行します。
次のコマンドを使用して、テスト環境からポートレットのカスタマイズ、パーソナライズおよびメタデータをエクスポートします。
exportPortletClientMetadata(appName='app_name', fileName='filename', exportPersonalizations=1)
構文の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのexportPortletClientMetadataに関する項を参照してください。
次のWLSTコマンドを使用して、WebCenter Spacesアプリケーションをエクスポートします。
connect('username','password','t3://hostname:port')
exportWebCenterApplication(appName,fileName,
exportCustomizations=true, exportSecurity=true, exportData=true)
詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのデータ移行のためのカスタムWebCenterアプリケーションのエクスポートとインポートに関する項を参照してください。
カスタムのWebCenter Frameworkアプリケーションをテスト環境からエクスポートするには:
次のコマンドを使用して、テスト環境からポートレットのカスタマイズ、パーソナライズおよびメタデータをエクスポートします。
exportPortletClientMetadata(appName='app_name',fileName='filename', exportPersonalizations=1)
構文の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのexportPortletClientMetadataに関する項を参照してください。
次のコマンドを使用して、テスト・データベースからWebCenter Frameworkアプリケーション・データをエクスポートします(ORACLE_HOMEは、Oracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_WEBCENTER directory=directory dumpfile=filename
CREATE OR REPLACE DIRECTORYコマンドの詳細は、『Oracle Database SQL言語リファレンス』のCREATE DIRECTORYに関する項を参照してください。
expdpコマンドの詳細は、Oracle Databaseユーティリティ(次のサイトにあります)のOracleデータ・ポンプに関する章を参照してください。
http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html
次のコマンドを実行して、Oracle Content Serverをエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_OCSERVER directory=directory dumpfile=filename
|
関連項目: Oracle Databaseユーティリティ(次のサイトにあります)のOracleデータ・ポンプに関する章。
|
Oracle Databaseのエクスポート・ユーティリティを使用して、ディスカッション・フォーラムをエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" OWNER=prefix_DISCUSSIONS FILE=/tmp/df.dmp statistics=none
WebCenter Spacesのデータおよびアプリケーションを本番環境にインポートするには:
コンテンツ・サーバーをインポートします。
作業2でエクスポートしたファイルを使用して、Oracle Content Serverのデータを本番データベースにインポートします。次のコマンドを実行します(ORACLE_HOMEは、Oracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to user; exit; ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" remap_schema=testprefix_OCSERVER:prod_prefix_OCSERVER DIRECTORY=directory dumpfile=filename TABLE_EXISTS_ACTION=REPLACE
次のディレクトリをテスト環境から本番環境にコピーします。tarを使用してテスト環境のファイルを圧縮し、それを本番環境でリストアできます。
WebCenter_ORACLE_HOME/ucm/vault WebCenter_ORACLE_HOME/ucm/weblayout
ディスカッション・フォーラムをインポートします。
SQLPlusを使用して、本番データベースに接続します(ORACLE_HOMEは本番データベースのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
ターゲット・ユーザーを削除します。
drop user prefix_DISCUSSIONS cascade;
ターゲット・ユーザーを作成します。
create user prefix_DISCUSSIONS identified by password default tablespace prefix_IAS_DISCUSSIONS temporary tablespace prefix_IAS_TEMP;
接続権限およびリソース権限をユーザーに付与し、SQLPlusを終了します。
grant connect,resource to prefix_DISCUSSIONS;
exit;
ディスカッション・フォーラムのデータを本番データベースにインポートします。作業2でテスト・データベースからエクスポートしたファイルをインポートします(ORACLE_HOMEは本番データベースのOracleホームです)。
ORACLE_HOME/bin/imp "sys/password@connect_id as sysdba" FROMUSER=testprefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS FILE=filename statistics=none
次のWLSTコマンドを使用して、WebCenter Spacesアプリケーションをインポートします。
connect('username','password','t3://hostname:port')
importWebCenterApplication(appName='appName', fileName='fileName')
詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのデータ移行のためのカスタムWebCenterアプリケーションのエクスポートとインポートに関する項を参照してください。
次のコマンドを使用して、本番環境にポートレットのカスタマイズ、パーソナライズおよびメタデータをインポートします。
importPortletClientMetadata(appName='app_name', fileName='filename')
構文の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのimportPortletClientMetadataに関する項を参照してください。
|
注意: 組込みのOracle WebLogic ServerのLDAPアイデンティティ・ストアを使用している場合、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのセキュリティの管理に関する項を参照してください。保護されているとしても、組込みのLDAPアイデンティティ・ストアは、本番クラスのストアではないため、エンタープライズの本番環境では、外部のLDAPベースのアイデンティティ・ストア(Oracle Internet Directoryなど)に置き換える必要があります。 |
|
関連項目: Oracle Fusion Middleware Oracle WebCenter管理者ガイドのデータ移行のためのWebCenter Portalアプリケーションのエクスポートとインポートに関する項 |
カスタムのWebCenter Frameworkアプリケーションを本番環境にインポートするには:
次のWLSTコマンドを使用して、作業3でエクスポートしたファイルからポートレットのカスタマイズおよびメタデータを本番環境にインポートします。
importPortletClientMetadata(appName='app_name',fileName='filename')
次のコマンドを使用して、データをデータベースにインポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to user; exit; ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" REMAP_SCHEMA=test_prefix_WEBCENTER:prod_prefix_WEBCENTER DIRECTORY=directory dumpfile=filename TABLE_EXISTS_ACTION=REPLACE
pasteConfig操作では、SSLが無効化されます。さらに、本番環境でカスタム・キーストアは作成されません。次の手順を実行します。
このシナリオでは、Oracle WebCenterがインストールされ構成されている稼働中の本番環境があり、アプリケーションまたは構成の変更を、本番環境への適用前にテストする必要があると想定します。たとえば、WebCenter Spacesアプリケーションを変更済である、新しいバージョンのWebCenter Frameworkアプリケーションをデプロイする必要がある、または既存のセキュリティ・ポリシーまたは構成を変更済であると想定します。
変更を既存の本番環境に移行するには、次の作業を実行します。
Oracle WebCenter Spacesデータをテスト環境からエクスポートするには:
Oracle Databaseのエクスポート・ユーティリティを使用して、Oracle WebCenter Spacesデータをディスカッション・フォーラムからエクスポートします。
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" $discussions_schema/$discussions_password file=discussions_forumid.dmp log=jive_forumid.log TABLES=jiveforum,jiveThread,jivemessage,jiveForumProp,jiveQuestion,jiveAnswer, jiveGateway rows=y STATISTICS=None QUERY=\"WHERE forumid \= $forumid\"
owc_wiki_export.sqlスクリプトを使用して、Oracle WebCenter SpacesデータをWikiからエクスポートします。このスクリプトは、次のディレクトリにあります。
ORACLE_HOME/wikiserver/owc-wiki/WEB-INF/classes
次のコマンドを使用します。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory WC_PUMP_DIR as 'path'; grant read,write on DIRECTORY WC_PUMP_DIR to user; @owc_wiki_export.sql
グループ・スペースをテスト環境からエクスポートします。
管理権限を使用してWebCenterスペースにログインします。
アプリケーションの上部にある「管理」リンクをクリックします。
「グループ・スペース」タブをクリックします。
「グループ・スペース」サブタブをクリックします。
表内の行を強調表示して、必要なグループ・スペースを選択します。
「状態の変更」ドロップダウンで、「オフライン」を選択します。
「保存」をクリックします。
ツールバーで「エクスポート」をクリックします。
グループ・スペース・データを本番環境にインポートするには:
ディスカッション・フォーラム・データのグループ・スペース・データを本番データベースにインポートします。作業1でテスト・データベースからエクスポートしたファイルをインポートします(ORACLE_HOMEは本番データベースのOracleホームです)。
ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" file=filename log=df_category.log ignore=y STATISTICS=None FROMUSER=test_prefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS
imp sys/passwd@dbhost file=T2PTEST_category.dmp log=df_category.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS imp sys/passwd@dbhost file=T2PTEST_forumid.dmp log=df_forumid.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS imp sys/passwd@dbhost file=T2PTEST_forumid_perm.dmp log=df_forumid_perm.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS
owc_wiki_import.sqlスクリプトを使用して、グループ・スペース・データをWikiにインポートします。スクリプトを編集して、行DBMS_DATAPUMP.start_job(dp_handle)の前に次の行を追加します。
DBMS_DATAPUMP.METADATA_REMAP(dp_handle,'REMAP_SCHEMA','source','target');
本番環境にディレクトリWC_PUMP_DIRを作成します。
作業1でデータベースからデータをエクスポートしたときに生成したファイルを、本番環境のWC_PUMP_DIRにコピーします。
次のスクリプトを実行します。
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" @owc_wiki_import.sql
グループ・スペースを本番環境にインポートします。
管理権限を使用してWebCenterスペースにログインします。
アプリケーションの上部にある「管理」リンクをクリックします。
「グループ・スペース」タブをクリックします。
「グループ・スペース」サブタブをクリックします。
表内の行を強調表示して、必要なグループ・スペースを選択します。
「状態の変更」ドロップダウンで、「オフライン」を選択します。
「保存」をクリックします。
ツールバーで「インポート」をクリックし、エクスポートされたアーカイブを選択します。
WebDAVを使用してテスト環境のグループ・スペースの下のフォルダをドラッグして、コンテンツ・サーバーのグループ・スペース・データを本番環境のグループ・スペースにインポートします。
グループ・スペース・テンプレートをテスト環境からエクスポートするには:
管理権限を使用してWebCenterスペースにログインします。
アプリケーションの上部にある「管理」リンクをクリックします。
「グループ・スペース」タブをクリックします。
「グループ・スペース」タブで、「テンプレート」を選択します。
ツールバーで「エクスポート」をクリックします。
グループ・スペース・テンプレートを本番環境にインポートするには:
管理権限を使用してWebCenterスペースにログインします。
アプリケーションの上部にある「管理」リンクをクリックします。
「グループ・スペース」タブをクリックします。
「グループ・スペース」タブで、「テンプレート」を選択します。
ツールバーで「インポート」をクリックし、エクスポートされたアーカイブを選択します。
この項では、Oracle Hyperion Enterprise Performance Management Systemコンポーネントを本番環境に移行する方法について説明します。
このシナリオでは、テスト環境で次の操作を実行済です。
必要なスキーマに使用するデータベースをインストールしました。
RCUを使用して、必要なスキーマを作成しました。『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle WebLogic Serverをインストールし、Middlewareホームを作成しました。
Oracle Hyperion Enterprise Performance Managementコンポーネントをインストールして構成しました。
Oracle Hyperion Enterprise Performance Managementを本番環境に移行するには、次の作業を実行します。
データベースおよびMiddlewareホームを移行して初期構成を実行するには:
Oracle Essbaseでは、テスト環境から本番環境に移行する必要があるのは構成設定のみです。たとえば、essbase.cfgをテスト環境から本番環境にコピーします。
ORACLE_INSTANCE/Essbase/essbaseserver1/bin/essbase.cfg
Oracle Hyperion Calculation Managerをテスト環境から本番環境に移行するには、次のいずれかを実行します。
リポジトリのバックアップ
Calculation Managerスキーマは変更されないため、新しいCalculation Manager環境で同じリポジトリを使用できます。事前に存在しているCalculation Managerのオブジェクトおよび関連する情報は、すべて新しい環境で使用できます。
割当てルールおよびルール・セットのエクスポート/インポート
Calculation Managerのルールおよびルール・セットをテスト環境からエクスポートして(Calculation Managerで、「File」→「Export」を選択)、それらを本番環境にインポートします(Calculation Managerで、「File」→「Import」を選択)。
|
注意:
|
Oracle Hyperion Financial Reportingのコンテンツをテスト環境からエクスポートして、本番環境にインポートできます。
Financial Reportingのレポート・コンテンツをテスト環境からエクスポートします。
テスト環境にログインします。
「File」→「Export」を選択します。
本番環境に移行するコンテンツまたはディレクトリに移動して、そのコンテンツまたはディレクトリを選択します。
選択したコンテンツまたはディレクトリをローカル・ファイル・システムにエクスポートします。
Financial Reportingのレポート・コンテンツを本番環境にインポートします。
本番環境にログインして、「File」→「Import」を選択し、「Financial Reporting」を選択します。
Financial Reportingのレポート・コンテンツをインポートするターゲットの場所を参照し、エクスポート・コンテンツが保存されているローカル・ファイルを選択します。
|
注意: Oracle Hyperion Financial Reportingのアノテーションおよびスケジューラの出力は、テスト環境から本番環境に移行できません。 |
Oracle Hyperion Provider Servicesのアーティファクトをテスト環境から本番環境にコピーする必要があります。
Provider ServicesをSmart Viewで使用する場合の移行方法:
Smart Viewクライアントを使用して、テスト環境で作成したEssbaseサーバーを本番サーバーに手動で追加します。
ORACLE_INSTANCE/products/Essbase/aps/bin/にあるessbase.propertiesを本番環境にコピーします。
Smart Viewから、テスト環境で作成したキューブ・ビューを本番環境で再作成します。
Provider ServicesをOracle Essbase Java APIで使用する場合の移行方法:
Java APIクライアント・プログラム構成のessbase.propertiesファイルで、デフォルトのJava APIプリファレンスが変更されている場合は、essbase.propertiesを本番環境にコピーします。
Oracle Hyperion Smart View for Officeは、クライアント・サイド・アプリケーションであるため、テスト・サーバーで作成したスプレッドシートなどのMicrosoft Officeドキュメントを本番サーバー接続に関連付ける必要があります。メタデータに変更がなければ、既存のレポートをテストから本番に指定できます。
共有接続を関連付けるには:
既存のレポートを開きます。
既存のレポートの場所は、そのレポートを最初に作成したときに保存した場所によって異なります。
Smart ViewがインストールされているExcelで、「Smart View」→「Options」→「Advanced」を選択します。
「Shared Connections URL」を新しい接続URLに変更します。例:
https://host.example.com/workspace/SmartViewProviders
「Smart View」→「Open」→「Smart View Panel」→「Shared Connections」を選択して、次のいずれかを実行します。
Essbase Serverが一覧に表示されていない場合は、「Create New Connection」をクリックします。
Essbase Serverが一覧に表示されている場合は、ユーザー名とパスワードを入力して、「Connect」をクリックします。
ドロップダウン・リストから、「Essbase Server」を選択します。
ドロップダウン・リストから、「Locate worksheet connection」を選択します。
接続がキューブの下に作成されます。
その接続を選択し、右クリックして接続します。
「Refresh」をクリックします。
アドホック分析の場合は、新しいサーバーに接続して、POVを保持するように選択する必要があります。この操作を行うには、プロンプトが表示されたら、「Reuse sheet contents and POV」を選択します。
プライベート接続を関連付けるには:
「Smart View」→「Open」→「Smart View Panel」を選択します。
「Private Connections」を選択します。
「Provider Services URL」を入力します。例:
https://host.example.com/aps/SmartView
Oracle Hyperion Provider Servicesにログインします。
Essbaseアプリケーションを選択してログインします。
Oracle Essbaseアプリケーションを選択して右クリックし、「Add to Private Connections」を選択します。
接続名を入力するか、デフォルトの名前を使用して、「OK」をクリックします。
接続を関連付けてから(「SVC」→「Open」→「Active Connection」)、その接続を選択します。「OK」をクリックして、メッセージを確認します。
「Refresh」をクリックします。
アドホック分析の場合は、新しいサーバーに接続して、POVを保持するように選択する必要があります。プロンプトが表示されたら、「Reuse sheet contents and POV」を選択します。
Oracle Enterprise Performance Management Workspaceの情報をテスト環境から本番環境に移行する場合は、システム設定とユーザー・プリファレンスを手動で移行する必要があります。サーバー設定およびユーザー・プリファレンスに行った変更はすべて、ターゲット・システムで行う必要があります。Oracle Enterprise Performance Management Workspace, Fusion Edition管理者ガイドのEPMワークスペースの管理に関する項を参照してください。
次の各項目では、Oracle Enterprise Content Management Suiteを本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
必要なスキーマに使用するデータベースをインストールしました。
RCUを使用して、必要なスキーマを作成しました。『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle WebLogic Serverをインストールし、Middlewareホームを作成しました。
Oracle Enterprise Content Management Suiteをインストールして構成しました。
Oracle Imaging and Process ManagementがワークフローまたはOracle Application Extension Framework (AXF)を使用する場合、Oracle SOA Suiteをインストールして構成しました。
Oracle Universal Content Managementを構成しました。
Oracle Imaging and Process Managementを構成しました。
Oracle I/PMがOracle Universal Content Management 10gリポジトリを使用する場合、このリポジトリをOracle I/PMに対して手動で構成しました。
Oracle Universal Records Managementを構成しました。
Oracle I/PMのいくつかの定義(接続、アプリケーション、検索、入力など)を定義しました。
アイデンティティ管理コンポーネント(Oracle Internet Directoryなど)をインストールして構成しました。
Oracle Enterprise Content Management Suiteを新しい本番環境に移行するには、次の作業を実行します。
本番環境では、Oracle Enterprise Content Management Suiteアプリケーションは、デフォルト構成の一部であるOracle WebLogic Server組込みのLDAPサーバーではなく、外部Lightweight Directory Application Protocol(LDAP)認証プロバイダを使用する必要があることに注意してください。ご使用のアプリケーションのアイデンティティ・ストアを次の外部LDAP認証プロバイダのいずれかと再度関連付けた後、管理対象サーバーの構成を完了し、それから管理対象サーバーをリポジトリに接続して、アプリケーションに最初にログインします。
Oracle Internet Directory
Oracle Virtual Directory
サード・パーティのLDAPサーバー
データベース、Middlewareホームを移行して初期構成を実行するには:
第21.3.2項の説明に従って、データベースを移行または作成します。
第21.4.項の説明に従って、アイデンティティ管理コンポーネントを移行します。
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
第21.3.4項の説明に従って、構成を移行します。
構成を移行すると、pasteConfigスクリプトによって、ドメイン、管理サーバーおよび管理対象サーバーを含むドメインの構成がコピーされます。また、その手順では次のことも行われます。
Oracle IRMメタデータを含むデータベースに関する情報の変更
Oracle I/PMサンプル入力ファイルのコピー(これらがドメイン・ディレクトリにある場合)
BPEL資格証明のコピー
Oracle Web Services Managerポリシーの移行
Oracle Application Extension Framework (AXF)を含む管理対象サーバーのリスニング・アドレスの設定
管理サーバーおよび管理対象サーバーの起動
第21.3.項の説明に従って、ユーザー、グループ、セキュリティ・ポリシーおよび資格証明ストアを構成します。
Oracle UCM 10gリポジトリを使用していて、テスト環境のOracle UCMシステムで構成されている場合、全文が本番環境のOracle UCM 10gシステムで正しく構成されていることを確認します。
Oracle UCM 10gサーバーを使用している場合、これはOracle Enterprise Content Management Suiteの移行時には構成されないことに注意してください。次のサイトにあるOracle Universal Content Managementページで説明されている手順を使用して、テスト環境にインストールしたときと同様の方法でこれをインストールする必要があります。
http://www.oracle.com/technetwork/middleware/content-management/overview/index.html
新しい本番環境で一部のOracle IRM設定を変更する必要があります。
SSLを設定します。Oracle IRMの場合、管理対象サーバーに接続したときに証明書の受入れを求めるプロンプトをOracle IRM Desktopが表示しないようにSSLを有効にする必要があります。使用される証明書は、Oracle IRM Desktopを実行しているコンピュータ上でMicrosoft Internet Explorerによって信頼される必要があります。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項の説明に従って、Oracle WebLogic Serverの標準のSSL設定手順を実行します。
Oracle IRMの各インストールでは、インストール固有の鍵を使用してキーストアにアクセスする必要があります。解凍されたドメインには、キーストアがある場合があります。キーストアがあり、かつContent Trackerコンポーネントが有効化されていてテスト環境で使用されている場合は、このキーストアを削除し、パスワードの詳細をクリアして、新しいキーストアを作成します。
キーストア・ファイルを削除します。デフォルトでは、キーストアは次のディレクトリにあります。
DOMAIN_HOME/config/fmwconfig
デフォルトのファイル名はirm.jksです。使用されるテンプレートによっては、別の名前が付けられている場合や、別のタイプが使用されている場合があります。
キーストアのパスワードは、資格証明ストアに格納されています。パスワードがテンプレート・ドメインに設定されている場合、次のWLSTコマンドを使用してパスワードをクリアします。
connect('username', 'password', 'localhost:7001')
deleteCred('IRM', 'keystore:keystore_filename')
deleteCred('IRM', 'key:irm.jks:oracle.irm.wrap')
この鍵に対して、テンプレートに保存されているキーストア・ファイル名を使用します。
Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドのOracle IRMのキーストアの構成に関する項の説明に従って、新しいキーストアを作成します。
本番環境でテスト環境と同じLDAPストアを使用していない場合、ユーザーをテスト環境から本番環境に移行します。Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドのアイデンティティ・ストアの外部LDAP認証プロバイダとの再関連付けに関する項を参照してください。
Oracle Universal Content Managementを新しい本番環境に移行するには:
次のコマンドを使用して、OCSデータベース・スキーマをテスト環境からエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/expdp \"sys/password as sysdba\" schemas=test_env_schema_name directory=directory dumpfile=ucm.dmp
ダンプ・ファイルが、本番データベースがアクセスできる場所にあることを確認します。
次のコマンドを使用して、テスト環境からエクスポートしたOCSデータベース・スキーマをインポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。
ORACLE_HOME/bin/impdp \"sys/password as sysdba\" remap_schema=test_env_schema_name:prod_env_schema_name directory=directory dumpfile=ucm.dmp TABLE_EXISTS_ACTION=REPLACE
外部データベースを使用した全文検索機能があるシステムでは、新しいデータベースを設定して新しい検索コレクションを保持します。
Oracle Secure Enterprise Searchインスタンスを設定し、本番システムでOracle UCMに対して構成するには:
Oracle Secure Enterprise Searchインストレーションおよびアップグレード・ガイドの説明に従って、Oracle Secure Enterprise Searchをインストールします。
新しいデータソースを作成して、Oracle Secure Enterprise Searchに接続します。『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』を参照してください。
テスト環境と同じデータソース名を使用することをお薦めします。
Oracle Universal Content Managementの構成後処理ページで、外部全文検索を選択し、データソース名を入力します。Oracle Fusion Middleware Content Serverシステム管理者ガイドのOracle SESとOracle UCMの構成に関する項を参照してください。
IntradocDir、WeblayoutDirおよびVaultDirディレクトリを、ドメイン構造の外部に存在するように構成した場合は、これらのディレクトリを本番環境にコピーします。
本番環境で、次のファイルを変更し、IntradocDir、WeblayoutDir、VaultDirおよびIdcHomeDirのエントリを更新します。
DOMAIN_HOME/bin/intradoc.cfg
本番環境のディレクトリ構造がテスト環境と同じ場合は、この手順は必要ありません。
本番システムで、次のファイルを削除します。
IntradocDir/data/contenttracker/config/sct.cfg
このファイルは、サーバーの再起動時に再生成されます。
次のファイルを変更し、HttpServerAddressを、正しいアドレスを反映するように更新します。
instance_dir/config/config.cfg
管理サーバーおよび管理対象サーバーを再起動します。
新しい本番環境をテンプレートとして使用し、複数の本番環境にレプリケートするには、作業2「Oracle Universal Content Managementの既存の本番環境への移行」の手順を実行します。この手順のほかに、次のファイルの各パラメータ(IDC_Name、InstanceMenuLabel、InstanceDescription、HttpServerAddressおよびAutoNumberPrefix)を変更する必要があります。
instance_dir/config/config.cfg
パラメータMailServerおよびSysAdminAddressを変更する必要がある場合もあります。
この手順ではOracle I/PMデータは移行されないことに注意してください。Oracle UCMで移行されるデータは、本番環境のOracle I/PMシステムからアクセスできません。
ワークフローの統合またはOracle Application Extension Framework(AXF)を使用している場合、この手順を始める前に、次の作業が実行されていることを確認してください。
第21.4.2.1項の説明に従って、Oracle SOA Suiteをインストールして構成し、このテスト環境を本番環境に移行しました。
Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドの既存のドメインの拡張に関する項の説明に従って、Oracle I/PMを構成し、SOAドメインを拡張しました。
Oracle I/PMを新しい本番環境に移行するには:
管理サーバーおよびOracle I/PM管理対象サーバーを起動します。
Oracle UCM 11g管理対象サーバーが起動していることを確認します。Oracle UCM 10gを使用している場合は、Oracle UCM 10gの各サービスが起動していることを確認します。
Oracle Internet Directoryを本番環境に移行した場合は、テスト環境からOracle I/PMユーザーとグループをエクスポートします。
Oracle I/PM管理対象サーバーに最初にログインしたユーザーが、サーバー全体のセキュリティとともにプロビジョニングされます。最初にユーザーがログインする前にOracle I/PMのアイデンティティ・ストアを外部LDAP認証プロバイダと再関連付けし、Oracle I/PM管理対象サーバーの構成を完了して、それをOracle UCMリポジトリに接続する方が簡単です。
ldapsearchコマンドを使用して、テスト環境のLDAPアイデンティティ・ストアからユーザーおよびグループをエクスポートします。これにより、後で本番環境のLDAPアイデンティティ・ストアにインポートするldifファイルが作成されます。ldapsearchコマンドは、アイデンティティ管理コンポーネントのORACLE_HOME/binディレクトリにあります。例:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
システム定義をテスト環境からエクスポートします。
次の点に注意してください。
この手順では、ドキュメントはテスト環境から本番環境に転送されません。この手順は、アプリケーション、入力および検索によって定義される構造を移行するのみです。
ドキュメントは、サポートするOracle UCMリポジトリ内にあります。Oracle I/PMは、Oracle UCMのテストから本番への手順またはデータベース・ユーティリティを使用して転送されたドキュメントを認識しません。これらのドキュメントは、Oracle I/PMからアクセスできません。Oracle I/PMを使用して、新しいドキュメントをOracle UCMリポジトリにアップロードします。
次のURLを使用して、テスト環境に管理者としてログインし、定義をエクスポートします。
http://hostname:16000/imaging
「ツール」を開き、「定義のエクスポート」を選択します。
「コメントのエクスポート」に任意のコメントを入力し、「次へ」をクリックします。
エクスポートするアプリケーションを選択し、「次へ」をクリックします。
エクスポートする検索を選択します。各検索のすべての依存アプリケーションがエクスポートに含まれます。「次へ」をクリックします。
エクスポートする入力を選択します。各入力のすべての依存アプリケーションがエクスポートに含まれます。「次へ」をクリックします。
選択した項目が正しいことを確認し、「次へ」をクリックします。
変更を行う必要がある場合、ページの上部で適切なタイプの定義(アプリケーションなど)を選択し、選択した項目を修正します。ページの上部で「サマリー」を選択します。
「エクスポート・ファイルの作成」を選択します。
ブラウザに応じて、ダイアログ・ボックスが表示され、ファイルを開くか保存することができます。このファイルは、指定した場所に保存されます。
サンプル・ファイルがドメイン・ディレクトリの外部にある場合は、これらのファイルをテスト環境から本番環境にコピーします。ファイルの場所は、Oracle I/PM MBean SampleDirectoryで指定されます。
Oracle I/PM MBeanの詳細は、Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドのOracle I/PM MBeansに関する項を参照してください。入力サンプル・ファイルを使用して入力の定義を作成する方法の詳細は、Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドの 入力の定義の作成に関する項を参照してください。
Oracle Internet Directoryを本番環境に移行している場合は、次の例で示すように、ldapaddmtコマンドを使用して、テスト環境からエクスポートしたldifファイルを本番環境にインポートすることにより、ユーザーおよびグループを本番環境のLDAPアイデンティティ・ストアにインポートします(ORACLE_HOMEはアイデンティティ管理のOracleホームです)。
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドのシステム・セキュリティに関する項の説明に従って、SSLを有効にします。
テスト環境でSSL対応のリスニング・アドレスまたはOSwalletに対してデフォルトでないウォレットが使用された場合、テスト環境からウォレットをエクスポートし、それらを本番環境にインポートします。ウォレットのエクスポートおよびインポートの詳細は、第8.4.4項を参照してください。
本番環境で接続を構成します。アプリケーションを本番環境にインポートするには、その前に本番環境でOracle UCMリポジトリおよびワークフロー・サーバーへのリンクを確立するOracle I/PMシステム接続オブジェクトを設定する必要があります。本番環境の接続の名前がテスト環境の接続と同じ名前である場合、インポートされる定義は、追加のアクションなしで正しくリンクされます。
名前が異なる場合、Oracle I/PMインポート・ツールを使用して、目的の接続名を選択できます。
構成設定を変更します。Fusion Middleware Controlを使用して、Oracle I/PMの実行を制御するシステムMBean値を変更します。MBean値を変更する必要がある場合、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドのAgentUserおよびGDFontPath MBeanの構成に関する項の手順に従います。
入力エージェントのワーク・マネージャ構成が本番環境の値をまだ指定していない場合、Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドのOracle WebLogic Serverワーク・マネージャ設定の変更に関する項の説明に従って、構成を更新します。
ワークフロー・エージェントのワーク・マネージャ構成が本番環境の値をまだ指定していない場合、Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドのWebLogic Serverワーク・マネージャ設定の変更に関する項の説明に従って、構成を更新します。
ユーザー・プリファレンスは移行されないことに注意してください。ユーザーは、本番環境のOracle I/PMシステムでプリファレンスを再構成する必要があります。
システム定義を本番環境にインポートします。
次のURLを使用して、本番環境システムに管理者としてログインし、定義をインポートします。
http://hostname:16000/imaging
「ツール」を開き、「定義のインポート」を選択します。
「ファイルの位置」で、「参照」をクリックし、ステップ4でテスト環境からエクスポートしたファイルの場所を参照します。
ファイルを選択すると、「ファイル日」および「ファイルのコメント」フィールドが移入されます。
「次へ」をクリックします。
各表から、インポートするアプリケーション、入力および検索を選択します。
プラス記号(+)を選択すると、定義の説明が表示されます。リポジトリのプルダウンを選択すると、各定義を定義済のリポジトリ接続のいずれかに配置できます。
「次へ」をクリックします。
検証フェーズでは、各定義のステータスを表示でき、「ドキュメント・セキュリティ」、「記憶域ポリシー」、「ワークフロー」および「全文オプション」を選択できます。Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドの定義のインポート(インポート・ページの検証)に関する項を参照してください。
赤のXマークが付いている定義はインポートできません。次の理由が考えられます。
検索定義および入力定義の場合、必要なアプリケーションがインポートされませんでした。
セキュリティ・チェックに失敗しました。
アプリケーションが指定する接続が存在しません。
ワークフロー検証に失敗しました。
問題を修正します。すべての定義が有効になったら、「送信」を選択します。
検証に成功すると、変更がコミットされます。エラーがある場合、ページに新しい例外が表示されます。エラーをすべて修正し、「送信」をクリックします。
Oracle Application Extension Framework(AXF)の構成データベースを移行します。
次の表をテスト・データベース・スキーマからエクスポートし、本番データベース・スキーマに挿入します。
AXF_ACTIONS
AXF_ACTION_MENU
AXF_ACTION_PARAMETERS
AXF_COMMANDS
AXF_ENUM_ITEMS
AXF_ENUM_TYPES
AXF_METADATA_ATTRIBUTES
AXF_METADATA_BLOCKS
AXF_SOLUTIONS
AXF_SOLUTION_ATTRIBUTES
AXF_SOLUTION_PARAMETERS
AXF_XPATH_NAMESPACES
AXF_XPATH_ATTRIBUTES
ワークフロー接続情報を、本番ワークフロー・システムへの接続を指すように変更します。
本番環境で異なるワークフロー接続名を使用している場合、PARAMETER_VALUE列を更新します。ステップ9で作成したワークフロー接続を使用し、適切なSQLユーティリティを使用して、AXF_SOLUTION_ATTRIBUTES表のBPEL_CONNECTION行のPARAMETER_VALUE列を更新します。
UPDATE AXF_SOLUTION_ATTRIBUTES SET PARAMETER_VALUE = '<ConnectionName>'
WHERE PARAMETER_KEY = 'BPEL_CONNECTION'
テスト環境でAXFソリューションのSOAコンポジットを作成済の場合、AXF11gソリューション・テンプレート・ガイドの説明に従って、本番環境でこのバージョンのコンポジットをデプロイします。
IPMビューアからドキュメントを取得できない場合は、次のファイルに対するアクセス権を変更する必要があります。
DOMAIN_HOME/oracle/imaging/imaging-server/ixTransformer
Oracle Universal Records Managementを新しい本番環境に移行するには:
テスト環境で、Oracle Fusion Middleware Universal Records Management管理者ガイドのアーカイブのエクスポートに関する項の説明に従って、構成設定(保存スケジュール、セキュリティ分類、トリガーなど)をエクスポートします。
アーカイブを本番環境にコピーします。
Oracle Fusion Middleware Universal Records Management管理者ガイドのアーカイブのインポートに関する項の説明に従って、アーカイブを本番環境にインポートします。
このシナリオでは、Oracle Enterprise Content Management Suiteコンポーネント(Oracle Information Rights Managementなど)をテスト環境にインストール済で、これらをすでに存在している本番環境に移行する必要があると想定します。
既存の本番環境では、コンポーネントをインストールおよび構成済です。アプリケーションをテスト環境から本番環境のOracle Enterprise Content Management Suiteに移行する必要があります。
Oracle Enterprise Content Management Suiteを既存の本番環境に移行するには、次の作業を実行します。
概念の証明またはパイロット(テスト)・デプロイメントを実行する組織は、運用サービスを本番環境にコピーし、既存のすべてのテスト・コンテンツ、コンテキストおよび権限を引き続き使用できます。
IRMサーバーURL(たとえば、protocol_schema:\\hostname:port\irm_desktop)は、テスト・コンテンツにシールされます。したがって、テストから本番への移行時にこの値を変更しないでください。このため、テスト・デプロイメントをインストールする際は、次の点を考慮してください。
テスト環境のHTTPプロトコルから本番環境のHTTPSプロトコルに切り替えると、テスト環境でシールされたコンテンツが本番環境で動作しなくなるため、テスト・デプロイメントでSSLを構成します。
マシン固有のホスト名(mytestdeploymachine.example.comなど)ではなく、汎用ホスト名(irm.example.comなど)をテスト・デプロイメント用に使用します。
テストから本番へのインストールが完了した後、ドメイン名のDNSエントリをテスト・サーバーから本番環境に切り替えられます。必要に応じて、ポート・リダイレクションを使用して、テスト・デプロイメントIRMサーバーURLが本番環境デプロイメントを指していることを確認できます。
テスト・デプロイメントを本番環境に移行するには:
本番データベースがテスト・データベースと異なる場合、Oracle IRMスキーマのバックアップを作成する必要があります。バックアップを本番データベースにリストアします。
テスト・インストール中にOracle IRMキーストア設定を本番環境にコピーします。これは通常、irm.jksと呼ばれます。このファイルは通常、次のディレクトリにあります。
DOMAIN_HOME/config/fmwconfig
Oracle IRM Java EEアプリケーションでは、前の手順でコピーしたキーストアのパスワードと、そのキーストアに格納されている各鍵が必要です。パスワードを指定しないと、Oracle IRM Java EEアプリケーションは鍵を取得できません。
テスト環境で使用したパスワードよりもセキュアなパスワードを使用するように切り替えるには、続行する前にkeytoolコマンドラインを使用してパスワードを変更します。構文については、keytoolヘルプを参照してください。
セキュアなパスワードを準備し、WLSTコマンドを使用してこのパスワードをOracle IRM Java EEアプリケーションに指定します。次の例では、管理サーバーに接続し、キーストア資格証明を設定します。
connect("username", "password", "t3://adminServerHost:adminServerPort")
createCred("IRM", "keystore:irm.jks", "dummy", "secureproductionpassword")
createCred("IRM", "key:irm.jks:oracle.irm.wrap", "dummy", "secureproductionpassword")
詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドのキーストアのパスワードの設定に関する項を参照してください。
通常次のディレクトリにあるOracle IRM構成ファイル(irm-config.xml)をテスト環境から本番環境にコピーします。
DOMAIN_HOME/config/fmwconfig
テスト環境の構成にはテスト固有の設定が含まれている場合があるため、ファイルの内容を確認する必要があります。Fusion Middleware ControlまたはWLSTを使用できます。または、構成ファイルirm-config.xmlを編集することもできます。Fusion Middleware Controlを使用するには、ナビゲーション・ツリーを開き、「IRM」をクリックします。「IRM」メニューで、「管理」→「一般設定」を選択します。次の設定を変更する必要がある場合があります。
プライバシURL: インストール用のOracle IRM使用状況プライバシ・ポリシーをホストするページへのURL。デフォルト値はありません。したがって、通常、ドメインの解凍後にこの設定を変更する必要はありません。デフォルトでは、組込みのプライバシ・ページが表示されます。
ステータス・ページのリダイレクト: 代替のOracle IRM Desktopステータス・ページをホストするページへのオプションのURL。デフォルト値はありません。したがって、通常、ドメインの解凍後にこの設定を変更する必要はありません。デフォルトでは、組込みのステータス・ページが使用されます。
キーストアの場所: パスは、リストアされたテスト環境のキーストアの場所を反映する必要があります。次にファイルの場所の例を示します。
DOMAIN_HOME/config/fmwconfig
本番環境でテスト環境と同じユーザー・ストアを使用していない場合、ユーザーをテスト環境から本番環境に移行します。Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドのアイデンティティ・ストアの外部LDAP認証プロバイダとの再関連付けに関する項を参照してください。
Oracle Universal Content Managementを既存の本番環境に移行するには:
移行オプションまたは移行画面の上部のメニューから「構成テンプレート」オプションを選択します。
「アクション」から「新規テンプレートの作成」を選択します。
「サーバーの構成」で、SearchIndexEngineNameを選択します。
「コンテンツ・メタデータ」で、エクスポートするテキスト・フィールドを選択します。
「コンテンツ・プロファイル・ルール」で、エクスポートするルールを選択します。
「個人情報データ」で、エクスポートするプロファイルを選択します。
「アクション」から「保存」を選択します。
「アクション」から「エクスポート」を選択します。
「構成のバンドル」をクリックします。
「構成のバンドル」ページで、データをエクスポートしたときに作成したバンドルを選択します。「アクション」から「ダウンロード」を選択します。
UCMにRecords Managerを使用していて、テスト環境から本番環境への増分移行を実行する場合、Oracle Fusion Middleware Universal Records Management管理者ガイドのインポートとエクスポートの管理に関する項の説明に従って、アーカイブをテスト環境からエクスポートし、これを本番環境にインポートします。
Oracle Imaging and Process Managementをテスト環境から既存の本番環境に移行するには、作業5「Oracle Imaging and Process Managementの新しい本番環境への移行」の説明と同じ手順を実行します。ただし、本番環境での定義の更新に関して、次の点に注意してください。
ある定義をテスト環境から既存の本番環境にインポートした場合、その定義が既存の定義と同じ名前であると、元の定義は上書きされます。インポートする既存の定義には、次のルールが適用されます。
アプリケーションであるフィールドが削除される場合、既存の検索定義または入力定義が、削除されたフィールドを参照していると、そのフィールドはインポートされません。
検索定義または入力定義が、アプリケーションで現在定義されていないフィールドを参照する場合、その定義はインポートされません。
エクスポート・プロセスおよびインポート・プロセスでは定義を削除できません。テスト環境で検索を削除した場合、検索管理機能を使用して、本番環境で手動でこの検索を削除する必要があります。
同じ名前の既存の入力定義があり、かつその入力定義がオンラインの場合、入力定義をインポートできません。その定義をインポートするには、まずそれをオフラインにする必要があります。
本番環境で、管理対象入力フォルダを開き、インポートする入力を選択します。
「オンラインで切替」を選択します。
Oracle URMを既存の本番環境に移行するには:
テスト環境で、Oracle Fusion Middleware Universal Records Management管理者ガイドのアーカイブのエクスポートに関する項の説明に従って、変更された構成設定をエクスポートします。
アーカイブを本番環境にコピーします。
Oracle Fusion Middleware Universal Records Management管理者ガイドのアーカイブのインポートに関する項の説明に従って、アーカイブを本番環境にインポートします。
このシナリオでは、Oracle HTTP ServerおよびOracle Web Cacheをテスト環境にインストール済で、これらを本番環境に移行する必要があると想定します。
次の各項目では、Web層をテスト環境から本番環境に移行する方法について説明します。
次の各項目では、Web層を新しい本番環境に移行する方法について説明します。
このシナリオでは、Oracle HTTP Serverをテスト環境にインストール済で、これをまだ存在していない本番環境に移行する必要があると想定します。テスト環境では、次の操作を実行済です。
Oracle HTTP Serverをインストールしました。
Oracleインスタンスおよび1つ以上のOracle HTTP Serverのコンポーネント・インスタンスを作成しました。
コンポーネントをFusion Middleware Controlを使用して管理する場合、既存のJRF対応のOracle WebLogic Server管理サーバーにOracleインスタンスおよびOracle HTTP Serverのコンポーネント・インスタンスを登録しました。
リクエストを1つ以上の仮想ホストにルーティングするように、mod_wl_ohsを構成しました。
SSLを1つ以上の仮想ホストに対して構成しました。
Oracle Single Sign-Onを構成しました。
mod_plsqlを構成しました。
mod_oradavを構成しました。
また、Oracle Access Managerを使用している場合があります。このシナリオでは、Oracle Access Managerのアクセス・サーバーは、テスト環境にはありません。これらのサーバーは、別の本番環境にあります。ただし、Webゲートはテスト環境で実行されています。
この環境を新しい本番環境に移行するには、次の作業を実行します。
WebゲートでOracle HTTP Serverが使用されている場合は、第21.4.1項の作業5または作業6(Oracle Access Managerのバージョンによって異なります)の説明に従って、まずOracle Access Managerを本番環境に移行する必要があります。
次の点に注意してください。
WebGateInstalldirプロパティとそのパスへの参照は、webgate.confファイルに更新されます。
WebGateディレクトリは、次のディレクトリに存在する必要があります。
Oracle_Instance/config/OHS/ohs_component_name
Middlewareホームを移行して初期構成を実行するには:
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
第21.3.5項の説明に従って、構成を移行します。
この手順により、Oracleインスタンスを含む構成が移行されます。さらに、次のことも行われます。
リスニング・アドレスおよび仮想ホストの名前の更新
テスト環境でSSLが構成されていた場合は、SSLの構成
環境およびトポロジ・ディレクティブ(ホスト名やIPアドレスなど)の新しい値を使用した、httpd.confファイルの更新
本番環境用のホスト名、IPアドレスおよびポート番号を使用した、mod_wl_ohs.confファイル内のWebLogicHost、WebLogicPortまたはWebLogicClusterディレクティブの更新
SSLがmod_wl_ohs用に構成されている場合は、mod_wl_ohs用のSSLの構成
テスト環境でmod_ossoが構成されていた場合は、mod_ossoの構成
テスト環境でPL/SQLが構成されていた場合は、PL/SQLの構成
テスト環境でmod_ossoが構成されていた場合は、mod_ossoの構成
テスト環境でaudit.config.xmlに変更が加えられていた場合は、audit.config.xmlの更新
テスト環境でcomponent-log.xmlに変更が加えられていた場合は、その更新
Oracle Access Managerを使用している場合は、Webゲートの構成
Oracleインスタンスのプロセスを起動します。
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
このシナリオでは、Oracle Web Cacheをテスト環境にインストール済で、これをまだ存在していない本番環境に移行する必要があると想定します。テスト環境では、次の操作を実行済です。
Oracle Web Cacheをインストールしました。
2つ以上のOracleインスタンス(それぞれがOracle Web Cacheインスタンスを含む)を構成しました。
コンポーネントをFusion Middleware Controlを使用して管理する場合、既存のJRF対応のOracle WebLogic Server管理サーバーにOracleインスタンスおよびOracle Web Cacheインスタンスを登録しました。
Oracle Web CacheインスタンスをOracle Web Cacheクラスタとして構成しました。
サイトを作成し、サイト・サーバー間マッピングを構成しました。
Oracle Web CacheをSSL対応リスニング・アドレスを持つように構成しました。
キャッシュ・ルールを構成し、リクエスト・フィルタリング用のフィルタを定義しました。
この環境を新しい本番環境に移行するには、次の作業を実行します。
本番環境で、バイナリ・ファイルを移行し、OracleインスタンスおよびOracle Web Cacheインスタンスを作成します。
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
OracleインスタンスおよびOracle Web Cacheインスタンスを作成します。
Oracle Universal Installerを使用してOracleインスタンスおよびOracle Web Cacheインスタンスを作成するには、次の手順に従います。
次のスクリプトを実行します。
(UNIX) ORACLE_HOME/common/bin/config.sh (Windows)ORACLE_HOME\common\bin\config.bat
『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』の手順に従います。
コマンドラインを使用してインスタンスおよびコンポーネントを作成するには、次の手順に従います。
コマンドラインから、次のディレクトリに移動します。
(UNIX) ORACLE_HOME/opmn/bin (Windows) ORACLE_HOME\opmn\bin
opmnctl createinstanceコマンドを使用して、Oracleインスタンスを作成します。例:
opmnctl createinstance -oracleInstance /scratch/Oracle/Middleware/inst1
-adminHost hostname -adminPort 7001
このコマンドは、Oracleインスタンスを作成し、デフォルトで、それらのインスタンスをOracle WebLogic Server管理サーバーに登録します。
opmnctl createcomponentコマンドを使用して、Oracle Web Cacheインスタンスを作成します。例:
opmnctl createcomponent -componentType WebCache
-oracleInstance /scratch/Oracle/Middleware/inst1
-componentName webcache1
opmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのコンポーネントすべてとともに、管理サーバーに登録します。例:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir -instanceName Instance_name -wlserverHome Middleware_Home
各Oracle Web Cacheインスタンスに対して、次の手順を実行します。
次のディレクトリにあるwebcache.xmlファイルをテスト環境から一時的な場所にコピーします。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
一時的な場所のwebcache.xmlに次の変更を行います。
本番環境のWeb Cache管理パスワードがテスト環境のパスワードと異なる場合は、次の手順を実行します。
本番環境のWeb Cacheインスタンスのwebcache.xmlファイルから<USER TYPE="INVALIDATION">要素のPASSWORDHASH属性の値をコピーし、この一時webcache.xmlの対応するPASSWORDHASH属性の現在の値を置き換えます。
本番環境のWeb Cacheインスタンスのwebcache.xmlファイルから<USER TYPE="MONITORING">要素のPASSWORDHASH属性の値をコピーし、この一時webcache.xmlの対応するPASSWORDHASH属性の現在の値を置き換えます。
本番環境において、元のサーバーの新しいホスト名またはIPアドレスとポート番号を使用して、各<HOST>要素および<VIRTUALHOSTMAP>要素のNAME属性およびPORT属性を更新します。
webcache.xmlの各<CACHE>要素に対して、次の項目を変更して本番環境のOracle Web Cacheインスタンスがあるホストに対応する値を置き換えます。
NAME、ORACLE_HOMEおよびHOSTNAME属性を更新します。
Oracleインスタンスのパスを検索し、置き換えます。
注意: この情報は一度に1つのOracle Web Cacheインスタンスについて更新してください。他のOracle Web Cacheインスタンスが別のパスで実行されている別のOracleインスタンスで構成されている場合があるため、グローバル検索および置換えは行わないでください。
各<LISTEN>要素に対して、IPADDR(ANY以外で構成されている場合)およびPORT(Oracle Web Cacheが本番環境で異なるポートを使用している場合)を更新します。
SSL対応のリスニング・アドレスのウォレット・ロケーションを更新します(異なる場合)。ウォレット・ロケーションは、各SSLリスニング・ポートの<WALLET>要素内で指定されます。
<IDENTITY>要素のUSERID属性およびGROUPID属性を更新します。
<OSWALLET>要素で、元のサーバーのウォレット・ロケーションを更新します(本番環境で異なる場合)。これは、Oracle Web Cacheによって使用され、SSL対応のオリジナル・サーバーと対話するウォレットです。
編集したwebcache.xmlを本番環境の次の場所にコピーします。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
auditconfig.xmlに変更が行われた場合、次のファイルをテスト環境から対応する本番環境にコピーします。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name/auditconfig.xml (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name\auditconfig.xml
component-log.xmlに変更が行われた場合、最初にこのファイルを編集してログ・パスを更新し、それからファイルをテスト環境から対応する本番環境にコピーします。
次のディレクトリにあるOracle Web Cacheエラー・ページへの変更を行った場合、エラー・ページをテスト環境から本番環境の場所にコピーします。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name/files (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name\files
テスト環境でSSL対応のリスニング・アドレスまたはOSwalletに対してデフォルトでないウォレットが使用された場合、テスト環境からウォレットをエクスポートし、それらを本番環境にインポートします。ウォレットのエクスポートおよびインポートの詳細は、第8.4.4項を参照してください。
このシナリオでは、稼働中の本番環境があり、アプリケーションまたは構成の変更を、本番環境への適用前にテストする必要があると想定します。
Oracle HTTP Serverの場合は、第21.4.6.2.1項を参照してください。
Oracle Web Cacheの場合は、第21.4.6.1.2項の作業2を実行します。
Oracle HTTP Serverを既存の本番環境に移行するには、構成を更新します。
任意のカスタム・コンテンツ(変更されたコンテンツ、htdocsディレクトリに追加されたコンテンツなど)を本番環境のOracle HTTP Serverにコピーします。
次のディレクトリにあるauditconfig.xmlへの変更を行った場合、本番環境でこのファイルのバックアップ・コピーを作成します。auditconfig.xmlファイルをテスト環境から対応する本番環境にコピーします。
ORACLE_INSTANCE/config/OHS/ohs_component_name/auditconfig.xml
component-log.xmlへの変更を行った場合、本番環境でこのファイルのバックアップ・コピーを作成します。次のディレクトリにあるファイルをテスト環境から本番環境にコピーします。
ORACLE_INSTANCE/diagnostics/logs/OHS/ohs_component_name
この項では、Oracle Business Intelligenceをテスト環境から本番環境に移行する手順について説明します。
|
関連項目: リポジトリをテスト環境から本番環境に移行する際の考慮事項など、Oracle Business Intelligenceリポジトリのライフサイクルの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ・ビルダーズ・ガイドのマルチユーザー開発環境でのリポジトリ・ライフサイクルの管理に関する項を参照してください。 |
次のシナリオでは、Oracle Business Intelligenceコンポーネントをテスト環境にすでにインストール済かつ構成済で、これらを新しい本番環境または既存の本番環境のいずれかに移行する必要があると想定します。
既存の本番環境にパッチを適用している場合、実行する手順は、適用する必要のあるパッチの数によって異なります。少数のパッチを適用する場合は、第21.4.7.2項の手順(環境内のマスター・ホストとすべてのクラスタ・ホストにパッチを適用します)に従います。適用するパッチが多数ある場合は、第21.4.7.3項の手順に従います。この手順では、パッチを1つのホストに適用し、新しいハードウェアが使用可能であるかどうかに応じて異なる方法を使用して、それらのパッチを他のホストに移入します。
この項では、Oracle Business Intelligenceをテスト環境から新しい本番環境に移行する手順について説明します。
このシナリオでは、Oracle Business Intelligenceコンポーネントをテスト環境にすでにインストール済かつ構成済で、これらを新しい本番環境に移行する必要があると想定します。新しい本番環境への移行手順は、移行プロセスと同じです。
Oracle Business Intelligenceコンポーネントを新しい本番環境に移行するには、次の作業を実行します。
準備完了になるまで、テスト環境にパッチを適用し、その環境をテストします。
詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。
新しい構成設定を試す場合、レプリケートできるように変更をメモします。
第21.3.3項の説明に従って、copyBinaryスクリプトを使用して、Oracle BI EEコンポーネントを含むMiddlewareホームをテスト環境からコピーします。
テスト環境で管理ツールおよびOracle BIサーバーXML APIを使用して、テスト・リポジトリ・ファイル(RPD)と本番ファイルのパッチ・マージを実行します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ・ビルダーズ・ガイドのパッチ・マージの実行に関する項を参照してください。
アーカイブ・ファイル(作業1「テスト環境のパッチ適用および移行」で作成したもの)をテスト環境から本番環境にコピーします。
本番環境にJDK 1.6.4以降またはJRockit (Oracle Business Intelligenceインストーラによってインストールされるもの)がインストールされていることを確認します。
第21.3.3項の説明に従って、pasteBinaryスクリプトを使用して、新しい本番環境にMiddlewareホームを再作成します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイドを参照してください。
デフォルトのOracle WebLogic Server LDAP以外のものを使用する場合は、セキュリティを構成します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドを参照してください。
セキュリティ・データ(ユーザー、グループ、ポリシー、ロールなど)の移行の詳細は、それぞれの認証プロバイダの該当ドキュメントを参照してください。次に、様々なコンポーネントに関する参照先を示します。
Oracle Internet Directory: 作業2「Oracle Internet Directoryの新しい本番環境への移行」を参照
Oracle WebLogic Server: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照
Oracle Platform Security Services: 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照
リポジトリ・ファイル(.rpd)を本番環境にコピーします。
テスト環境でOracle BI Presentation Catalogを圧縮します(zipを使用)。
新しい本番環境でカタログを解凍します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドを参照してください。
Fusion Middleware Controlを使用して、本番環境でのカタログの場所を設定します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用した、リポジトリのアップロードとOracle BI Presentation Catalogの場所の設定に関する項を参照してください。
新しい本番環境でFusion Middleware Controlを使用して、リポジトリ・ファイル(.rpd)をアップロードします。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用した、リポジトリのアップロードとOracle BI Presentation Catalogの場所の設定に関する項を参照してください。
必要に応じて、管理ツールまたはOracle BIサーバーXML APIを使用して、リポジトリ・ファイルの接続プールおよびデータベース設定を更新します。このファイルには、テスト環境のデータソース接続情報が含まれていることがあります。その場合、それらを本番環境の接続設定に変更する必要があります。
Oracle BIサーバーXML APIを使用してこの手順を実行する方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドのテスト環境から本番環境への移行に関する項を参照してください。
(オプション) Fusion Middleware Controlの「容量管理」ページで「パフォーマンス」タブの「オンラインRPD更新の無効化」を選択して、本番リポジトリ・ファイルを読取り専用にします。
アーカイブ・ファイル(作業1「テスト環境のパッチ適用および移行」で作成したもの)を新しいクラスタ・ホストにコピーします。
次のファイルを新しいクラスタ・ホストにコピーします。
UNIXの場合:
ORACLE_COMMON_HOME/bin/pasteBinary.sh ORACLE_HOME/jlib/cloningclient.jar
Windowsの場合:
ORACLE_COMMON_HOME\bin\pasteBinary.cmd
ORACLE_HOME\jlib\cloningclient.jar
第20.2.1項の説明に従って、pasteBinaryスクリプトを使用して、新しいクラスタ・ホストにMiddlewareホームをコピーします。
注意: マスター・ホストで使用したMiddlewareホーム名と正確に同じ名前を新しいクラスタ・ホストで使用する必要があります。
Fusion Middleware Controlを使用して、新しいクラスタ・ホストにスケール・アウトします。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用した、システム・コンポーネントのスケール・アウトに関する項を参照してください。
新しいクラスタ・ホストそれぞれに対して、前述の手順を繰り返します。
GUIDを含むLDAPディレクトリは、テスト環境と本番環境の両方でレプリカをファンアウトするため、通常、テスト環境と本番環境間で、LDAPディレクトリ内のGUID(アイデンティティ・ストア・ユーザー)をリフレッシュすることはありません。考えられるリフレッシュのシナリオには次のようなものがあります。
Oracle Business Intelligenceテスト・サーバーおよび本番サーバーが両方とも、企業LDAPディレクトリに対して構成されています。
LDAP GUIDをリフレッシュする必要はありません。
Oracle Business Intelligenceテスト・サーバーはテストLDAPに対して構成されていて、かつ本番サーバーは企業LDAPに対して構成されていますが、テストLDAPは企業LDAPのファンアウト・レプリカです。
LDAP GUIDをリフレッシュする必要はありません。
Oracle Business Intelligenceテスト・サーバーはテストLDAPに対して構成されていて、かつ本番サーバーは企業LDAPに対して構成されていますが、テストLDAPは企業LDAPのファンアウト・コピーではありません。
LDAP GUIDのリフレッシュが必要です。詳細は、第21.4.7.4項を参照してください。
新規エージェントがテスト環境で作成された場合、(本番環境の) Oracle BIプレゼンテーション・サービスのカタログ・マネージャで各エージェントをクリックして有効化します。
Oracle BI Publisherのレポートは、Oracle BI Presentation Catalogに格納されているため、既存のレポート、およびテスト環境で作成された新しいレポートを使用できるようにする必要があります。
本番環境で、Oracle WebLogic Server管理者は、テスト環境と同じ名前を使用して、(Oracle BI Publisherのレポートが使用する) JNDI接続を作成する必要があります。この接続は、テスト・データベースではなく本番データベースを指す必要があります。この方法により、すべてのレポートは自動的に、テスト環境のデータベースではなく本番環境のデータベースを指すようになります。設定を変更する必要はありません。
次の手順の説明に従って、外部システムに関連する静的コンテンツが本番環境に移行されるようにします。
Action Framework構成ファイルをソース・システムからターゲット・システムの同じ場所にコピーします。また、ActionFramework構成ファイルには、構成ファイルと同じディレクトリにあるファイルを参照するポリシー要素が含まれている場合があります。それらのファイルをターゲット・システムの同じ場所にコピーします。
Action Framework構成ファイルを編集して、エンドポイントがターゲット・システムの関連するリソースを参照するようにします。
様々なアクション・タイプ用の構成の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドのアクション・フレームワークの構成に関する項を参照してください。
Oracle Business Intelligence関連アプリケーション(Calculation Manager、Financial ReportingおよびOracle BI for Microsoft Officeなど)を新しい本番環境に移行します。詳細は、第21.4.4項を参照してください。
本番環境がテスト環境を正確に表していることを検証します。
この項では、適用するパッチが少数ある場合にOracle Business Intelligenceをテスト環境から既存の本番環境に移行する手順について説明します。(多数のパッチを適用する場合は、第21.4.7.3項を参照してください)。
次の各手順では、Oracle Business Intelligenceコンポーネントをテスト環境にすでにインストール済かつ構成済で、これらを既存の本番環境に移行する必要があると想定します。
適用するパッチが少数ある場合に、Oracle Business Intelligenceコンポーネントを既存の本番環境に移行するには、次の作業を実行します。
パッチは、一連のバグ修正を既存の本番環境に適用します。また、新しいバイナリ・ファイルおよびメタデータの更新も含まれます。
準備完了になるまで、必要に応じてテスト環境にパッチを適用し、テストします。
マスター・ホスト上およびすべてのクラスタ・ホスト上で既存の本番環境にパッチを適用し、テスト環境と同じレベルにします。
注意: パッチ適用には、Oracle Business Intelligence以外のパッチおよび個別パッチも含まれます。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。
テスト環境で管理ツールおよびOracle BIサーバーXML APIを使用して、テスト・リポジトリ・ファイル(RPD)と本番ファイルのパッチ・マージを実行します。
既存の本番環境に移行中で、テスト環境でRPDファイルの変更を行った場合のみ、この作業を完了する必要があります。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ・ビルダーズ・ガイドのパッチ・マージの実行に関する項を参照してください。
本番環境でFusion Middleware Controlを使用して、使用するRPDファイルをアップロードします。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用した、リポジトリのアップロードとOracle BI Presentation Catalogの場所の設定に関する項を参照してください。
必要に応じて、管理ツールまたはOracle BIサーバーXML APIを使用して、リポジトリの接続プールおよびデータベース設定を更新します。RPDファイルには、テスト環境のデータソース接続情報が含まれていることがあります。その場合、それらを本番環境の接続設定に変更する必要があります。
Oracle BIサーバーXML APIを使用してこの手順を実行する方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドのテスト環境から本番環境への移行に関する項を参照してください。
(オプション) Fusion Middleware Controlの「容量管理」ページで「パフォーマンス」タブの「オンラインRPD更新の無効化」を選択して、本番リポジトリ・ファイルを読取り専用にします。
次のように、新規または更新されたフォルダをテスト・カタログから本番カタログにドラッグ・アンド・ドロップします。
2つのカタログ・マネージャ・ウィンドウ(一方はテスト・カタログ、他方は本番カタログ)を開きます。
必要なフォルダをテスト・カタログから選択してコピーし、本番カタログに貼り付けます。
注意: 同じコンテンツがテスト環境または本番環境で変更されたフォルダをコピーして貼り付けると、テスト環境のコンテンツが本番環境のコンテンツを上書きします。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドを参照してください。
既存の本番環境でFusion Middleware Controlを使用して、新しいカタログの場所を指定します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用した、リポジトリのアップロードとOracle BI Presentation Catalogの場所の設定に関する項を参照してください。
GUIDを含むLDAPディレクトリは、テスト環境と本番環境の両方でレプリカをファンアウトするため、通常、テスト環境と本番環境間で、LDAPディレクトリ内のGUID(アイデンティティ・ストア・ユーザー)をリフレッシュすることはありません。考えられるリフレッシュのシナリオには次のようなものがあります。
Oracle Business Intelligenceテスト・サーバーおよび本番サーバーが両方とも、企業LDAPディレクトリに対して構成されています。
LDAP GUIDをリフレッシュする必要はありません。
Oracle Business Intelligenceテスト・サーバーはテストLDAPに対して構成されていて、かつ本番サーバーは企業LDAPに対して構成されていますが、テストLDAPは企業LDAPのファンアウト・レプリカです。
LDAP GUIDをリフレッシュする必要はありません。
Oracle Business Intelligenceテスト・サーバーはテストLDAPに対して構成されていて、かつ本番サーバーは企業LDAPに対して構成されていますが、テストLDAPは企業LDAPのファンアウト・コピーではありません。
LDAP GUIDのリフレッシュが必要です。詳細は、第21.4.7.4項を参照してください。
新規エージェントがテスト環境で作成された場合、(本番環境の) Oracle BIプレゼンテーション・サービスのカタログ・マネージャで各エージェントをクリックして有効化します。
Oracle BI Publisherのレポートは、Oracle BI Presentation Catalogに格納されているため、既存のレポート、およびテスト環境で作成された新しいレポートを使用できるようにする必要があります。
本番環境で、Oracle WebLogic Server管理者は、テスト環境と同じ名前を使用して、(Oracle BI Publisherのレポートが使用する) JNDI接続を作成する必要があります。この接続は、テスト・データベースではなく本番データベースを指す必要があります。この方法により、すべてのレポートは自動的に、テスト環境のデータベースではなく本番環境のデータベースを指すようになります。設定を変更する必要はありません。
次の手順の説明に従って、外部システムに関連する静的コンテンツが本番環境に移行されるようにします。
Action Framework構成ファイルをソース・システムからターゲット・システムの同じ場所にコピーします。また、ActionFramework構成ファイルには、構成ファイルと同じディレクトリにあるファイルを参照するポリシー要素が含まれている場合があります。それらのファイルをターゲット・システムの同じ場所にコピーします。
Action Framework構成ファイルを編集して、エンドポイントがターゲット・システムの関連するリソースを参照するようにします。
様々なアクション・タイプ用の構成の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドのアクション・フレームワークの構成に関する項を参照してください。
Oracle Business Intelligence関連アプリケーション(Calculation Manager、Financial ReportingおよびOracle BI for Microsoft Officeなど)を既存の本番環境に移行します。詳細は、第21.4.4項を参照してください。
本番環境がテスト環境を正確に表していることを検証します。
この項では、適用するパッチが多数ある場合にOracle Business Intelligenceをテスト環境から既存の本番環境に移行する手順について説明します。
次の各シナリオでは、Oracle Business Intelligenceコンポーネントをテスト環境にすでにインストール済かつ構成済で、これらを既存の本番環境に移行する必要があると想定します。
適用するパッチが多数ある場合にOracle Business Intelligenceコンポーネントを既存の本番環境に移行するには、次の方法のいずれかを実行します。
適用するパッチが多数あり、新しいハードウェアが使用可能な場合に、Oracle Business Intelligenceコンポーネントを既存の本番環境に移行するには、次の作業を実行します。
新しい本番環境への移行のため、第21.4.7.1項の手順を実行します。
これらの手順には、新しいテストRPDファイルおよびカタログと既存の本番環境のRPD/カタログのマージが含まれます。ユーザーが既存の環境を使用し続けながら、一度マージを実行して問題を解決することが理想的です。ファイルが正しい場合、本番環境をロックし、マージを繰り返して、最新の変更を取得します。
Oracle WebCacheなどのロード・バランサを使用して、ユーザーを標準URLから新しい本番環境にリダイレクトします。
既存の環境を停止し、すべてのソフトウェアをアンインストールします。必要に応じて、次のパッチ・セットをこのホストに適用し、手順を最初から再開できます。
適用するパッチが多数あり、新しいハードウェアが使用可能でない場合に、Oracle Business Intelligenceコンポーネントを既存の本番環境に移行するには、次の作業を実行します。
本番環境で、Fusion Middleware Controlの「スケーラビリティ」ページの「容量管理」タブを使用して、システム・コンポーネントをリストの最初のホストのみに適用するようにスケール・バックします。こうすることにより、既存の本番環境へのパッチ適用が非常に簡単になります。
詳細は、Fusion Middleware Controlのヘルプ・システムを参照してください。
本番環境のホストにパッチを適用します。こうすることで、複数のクラスタ・ホストにパッチを適用する場合よりも、ユーザーの停止時間を減らすことができます。
詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。
クラスタ・ホストのすべてのOracle Business Intelligenceソフトウェアをアンインストールします。詳細は、Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイドを参照してください。
第21.4.7.1項の作業8「本番環境の新しいクラスタ・ホストへのコピーおよびスケール・アウト」からの各作業を完了します。
認証プロバイダのデータソースとして使用されるディレクトリ・サーバーを変更した後にユーザーGUIDを更新することをお薦めします。両方のディレクトリ・サーバー(元のサーバーと新しいサーバー)に同じユーザー名が存在する場合、元のユーザーGUIDが、新しいディレクトリ・サーバーに含まれているユーザーGUIDと競合する場合があります。リフレッシュすると、システムは、新しいディレクトリ・サーバーに含まれているユーザーGUIDを参照するようになります。GUIDがリフレッシュされず、システムがユーザーGUIDの不一致を検出すると、認証エラーが発生する場合があります。
次の手順の説明に従って、Oracle BI Presentation CatalogまたはRPDファイルに格納されているGUIDを再同期およびリフレッシュすることができます。この手順を開始する前に、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドの通常はFusion Middleware Controlによって管理されないOracle Business Intelligence構成設定の手動での更新に関する項の情報をよく確認してください。
この手順では、Oracle BIサーバーおよびOracle BIプレゼンテーション・サービスに対して再起動時にGUIDをリフレッシュすることを指示するように、構成ファイルを手動で編集する必要があります。処理が完了したら、これらのファイルを編集して変更内容を削除します。Oracle Business Intelligence構成ファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドで、構成ファイルの場所について説明している項を参照してください。
|
注意: GUIDをリフレッシュするには、Fusion Middleware Controlではなく、コマンドラインからシステム・コンポーネントを停止して再起動する必要があります。これには、管理サーバーおよび管理対象サーバーが含まれます。管理サーバーが停止した後はFusion Middleware Controlを使用できないため、Fusion Middleware Controlから管理サーバーを起動することはできません。 |
ユーザーGUIDをリフレッシュするには:
編集するNQSConfig.INIファイルを開きます。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドの構成ファイルの場所に関する項を参照してください。
設定FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = NOを検索し、この値をYESに変更します。
プレゼンテーション・サービスが再起動時にGUIDをリフレッシュするように、instanceconfig.xmlファイルを変更します。このファイルを編集して、次の指示の最後の行を追加します。
<ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1"> <ps:UpgradeAndExit>false</ps:UpgradeAndExit> <ps:UpdateAccountGUIDs>UpdateAndExit</ps:UpdateAccountGUIDs>
ターミナル・ウィンドウで、opmnctlパラメータのstopallおよびstartallを使用して、管理対象プロセスを停止して再起動します。パラメータstatusを使用して、プロセス・ステータス全体を確認できます。
含まれるコンポーネントは、プレゼンテーション・サービス、Oracle BIサーバー、Oracle BIスケジューラ、Oracle BIクラスタ・コントローラおよびOracle BI JavaHostです。
opmnctlコマンドの使用方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのOPMNコマンドを使用した、Oracle Business Intelligenceシステム・コンポーネントの起動と停止に関する項を参照してください。
NQSConfig.INIファイルを編集して、FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YESをNOにリセットし、Oracle BIサーバーを再起動します。
instanceconfig.xmlファイルに追加された最後の行(ステップ3で指定した、プレゼンテーション・サービスに対して再起動時にGUIDのリフレッシュを指示する行)を削除するか、noneに設定するか、コメント・アウトします。
<ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1"> <ps:UpgradeAndExit>false</ps:UpgradeAndExit> <ps:UpdateAccountGUIDs>none</ps:UpdateAccountGUIDs>
更新したinstanceconfig.xmlファイルのためにプレゼンテーション・サービスを再起動します。
Oracle WebLogic Serverおよびシステム・コンポーネントも実行中であることを確認します。実行中でない場合、これらを再起動します。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのOracle Business Intelligenceコンポーネントの起動と停止に関する項を参照してください。
次の各項目では、Oracle Real-Time Decisions(Oracle RTD)をテスト環境から新しい本番環境に移行する方法について説明します。
この環境を本番環境に移行するには、次の作業を実行します。
データベース、MiddlewareホームおよびOracle RTDソフトウェアを移行して初期構成を実行するには:
第21.3.1項の説明に従って、データベースと必要なスキーマを移行または作成します。
第21.4.1項の説明に従って、Middlewareホームとバイナリ・ファイルのコピーを移行します。
環境にOracle BI EEが含まれており、第21.4.7.1項の説明に従ってOracle BI EEをすでに本番環境に移行済の場合、Oracle BI EEのバイナリ・ファイルだけでなく、Oracle RTDのバイナリ・ファイルも移行されているので、この手順を実行する必要はありません。
構成ウィザードを使用して、Oracle RTDを構成し、ドメインを作成します。Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドのインストール後のOracle RTDの構成に関する項を参照してください。この構成を行うには、ソフトウェアのみのインストール後にOracle RTDを構成するための手順に従います。
次の各項目は、本番環境の設定および構成において考慮する必要がある重要な要素です。
リポジトリ構成ユーティリティ(RCU)を使用している場合、接続プールは、本番環境に固有のデータベース接続を反映する必要があります。
カスタム・ロールおよびセキュリティ設定の構成を行う際、本番環境の設定を反映するように設定パラメータを変更する必要があります。
詳細は、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドのセキュリティに関する章を参照してください。
テスト環境で定義されたすべてのパフォーマンス調整パラメータを、本番環境でも再作成する必要があります。これには、アプリケーション・サーバー・レベルとデータベース・レベルの両方のパフォーマンス・パラメータが含まれます。
Oracle RTDクライアントを顧客のフロントエンド・アプリケーションとのOracle RTDの統合に使用する場合、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドで概説されている設定手順に従って、Oracle RTDクライアントを本番環境にインストールする必要があります。
クライアント・パラメータの構成は、本番アーキテクチャ固有の値を反映する必要があります。
テスト環境に存在するOracle RTD Inline Servicesを本番環境に移行します。
インライン・サービスの本番環境への移行は、次の2つの方法で実行できます。
コマンドライン・デプロイメント: 詳細は、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドの「インライン・サービスのコマンドライン・デプロイメント」を参照してください。
Decision Studioデプロイメント: Decision StudioでのOracle RTDデプロイメントの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「インライン・サービスのデプロイ、テストおよびデバッグ」を参照してください。
|
注意: インライン・サービスを移行する前に、Oracle RTDサーバーが使用するインライン・サービスに変更が行われた場合(たとえば、Decision Centerを介して)、まず、最新バージョンのインライン・サービスをDecision Studioにダウンロードし、それから本番環境に再デプロイする必要があります。 |
インライン・サービスをある環境から別の環境に移行する場合、インライン・サービス内でも編集する必要がある場合がある次の領域に注意してください。
サード・パーティAPIおよびサード・パーティJARファイルのコール
追加した新しいjarファイルは、新しい環境の対応する場所に配置する必要があります。
サード・パーティWebサービスのコール
ロケーション・パス、Webサービス・パラメータなどは、新しい環境で異なる場合、変更する必要があります。
インライン・サービス内のカスタム表への参照(場所、ユーザー名、パスワードなど)は、本番環境で異なる場合、編集してから再デプロイする必要があります。
データソースへの参照は、本番環境で異なる場合、編集してからデプロイする必要があります。これには、動的選択肢のデータソースの変更も含まれます(使用する場合)。
新しい環境では望ましくない可能性があるデバッグ・コード(logInfo文、logTrace文など)への参照は、コメント・アウトするかインライン・サービスから削除し、それから再デプロイする必要があります。
外部オブジェクト(動的選択肢、外部ルールなど)を含むインライン・サービスには、次の考慮事項が適用されます。
動的選択肢の場合:
インライン・サービス構成の一部に動的選択肢がある場合、テスト環境と本番環境が同じソースを共有しないときは、動的選択肢を格納しているデータと表の両方を再作成する必要があります。
インライン・サービスのデータソース要素も適切に変更する必要があります。
外部ルールの場合:
インライン・サービス構成の一部に外部ルールがある場合、テスト環境と本番環境が同じソースを共有しないときは、ルール・データを格納しているデータと表の両方を再作成する必要があります。
インライン・サービスのデータソース要素も適切に変更する必要があります。
また、本番環境で使用される外部ルール・エディタを、本番データベースを指すように構成する必要があります。
Oracle RTDで行う必要がある場合がある追加作業には、次の作業が含まれます。
モデル・スナップショット表の作成および構成。
Oracle RTDモデル・スナップショット表は、RCUとツールsdexec/SDDBTool(インストール時に提供される)の2つの方法で本番環境に作成できます。
RCUは、Oracle RTDプラットフォーム表と同じスキーマに必要なスナップショット表を作成します。一方、sdexec/SDDBToolを使用すると、別の場所に表を作成できます。
モデル・スナップショット表を作成した後、Enterprise Managerコンソールを使用して、表にデータを移入するために必要な設定を構成します。詳細は、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドの「モデル・スナップショットの設定と使用方法」を参照してください。
loadgenファイルの変更。
本番環境でも使用されるloadgenファイルを作成済の場合、新しい環境に応じて次のパラメータを変更する必要があります(それぞれを特定のloadgen構成ファイル内で変更する必要があります)。
ClientHttpEndpoints.propertiesファイル
インライン・サービス名(変更された場合)
loadgenスクリプトへの入力として使用する場合のデータファイルへのパス参照
loadgenログ・ファイルへのパス
バッチ・プロセス・ファイルの変更。
RTDバッチ・モジュールを使用する場合、環境固有のバッチ・ファイルで参照されるデータソースに注意を払い、必要に応じてファイルを変更する必要があります。
本番環境が作成された後、一般的なOracle RTDの増分変更には次の作業が含まれます。
特定のパッチそれぞれが一意の機能拡張および既知のバグに対処しているため、パッチの適用方法に関する固有の指示について、各パッチに付属のリリース・ノートを常に参照する必要があります。
インライン・サービスの増分変更に関して、インライン・サービスの本番環境への移行では、完全な製品テスト環境から本番環境への移行で説明されている手順と同じ手順を実行します。
追加のデータソースがインライン・サービスに増分追加される場合、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドの「データ・アクセスの構成」を参照してください。
このシナリオでは、Oracle Portal、Oracle Forms Services、Oracle ReportsおよびOracle Business Intelligence Discovererをテスト環境にインストール済で、それを本番環境に移行する必要があると想定します。
次の各項目では、これらのコンポーネントをテスト環境から本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
これらのコンポーネントに使用するデータベースをインストールしました。
RCUを使用して、これらのコンポーネントが必要とするスキーマを作成しました。
Oracle BI Discovererの場合、End User Layer(EUL)、DiscovererカタログおよびOLAPカタログに使用される追加のデータベースをインストールしました。
Oracle WebLogic Serverをインストールし、Middlewareホームを作成しました。
アイデンティティ管理(Oracle Internet Directory、Oracle Single Sign-Onおよびアイデンティティ管理データ用データベースを含む)をインストールして構成しました。
Oracle Portal、Oracle Forms Services、Oracle ReportsおよびOracle BI Discovererをインストールして構成しました。
Oracle Portalの場合:
ユーザーとグループを作成し、グループにページ・アクセス権限を割り当てました。
新しいページ・グループおよび新しいテンプレートを作成しました。
新しいページを作成し、項目、ポートレットなどのコンテンツをページに追加しました。
ページ、レイアウト、項目およびポートレットをカスタマイズしました。
プロデューサ(データベース、WebおよびWSRP)を登録し、プロデューサからポートレットをカスタマイズしました。
外部アプリケーションを登録しました。
Formsアプリケーションを設定しました。
Oracle Reportsインスタンスを構成し、データベースへの接続を作成しました。
Oracle BI Discovererの場合:
Discoverer Plusの場合、パラメータ、計算、条件および合計を使用して新しいワークブックを作成しました。ワークブックを保存しました。
Discoverer Viewerの場合、Discoverer Plusに作成されたワークブックを開き、フォーマット、並べ替え、エクスポートおよびドリルを実行しました。
Discoverer Plus OLAPの場合、カスタム・メンバー、カスタム式および保存済の選択を使用してDiscoverer Plus OLAPに新しいワークブックを作成し、ワークブックを保存しました。ワークブックを保存しました。
Viewer OLAPの場合、Discoverer Plus OLAPに作成されたワークブックを開き、エクスポート、レイアウトのリンクやリンク解除などの操作を実行しました。
このシナリオでは、Oracle Portal、Oracle Forms Services、Oracle ReportsおよびOracle Business Intelligence Discovererをテスト環境にインストール済で、これらのコンポーネントを存在しない本番環境に移行する必要があると想定します。
この項ではコンポーネントすべてを本番環境に移行する方法について説明しますが、コンポーネントの一部のみを移行することも選択できます。
この環境を新しい本番環境に移行するには、次の作業を実行します。
データベースおよびMiddlewareホームを移行して初期構成を実行するには:
第21.3.2項の説明に従って、データベースとスキーマを移行または作成します。
第21.3.3項の説明に従って、Middlewareホームとバイナリ・ファイルを移行します。
Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererインストレーション・ガイドの説明に従って、コンポーネントを構成します。Oracle Portalの場合、これには、Oracle Internet DirectoryおよびOracle Single Sign-Onリリース10.1.3.4のインストールが含まれます。
Oracle Portalの場合、「コンポーネントの構成」画面でOracle Internet Directoryへの接続の資格証明を指定します。
Oracle Portalの構成を新しい本番環境に移行するには:
移行するページ・グループのリストを含むテスト・インスタンス上でトランスポート・セットを作成します。トランスポート・セットの作成の詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』のトランスポート・セットの作成に関する項を参照してください。
『Oracle Fusion Middleware Oracle Portal管理者ガイド』のデータのエクスポートに関する項の説明に従って、テスト環境からデータをエクスポートします。
『Oracle Fusion Middleware Oracle Portal管理者ガイド』のデータベース・リンクの作成に関する項の説明に従って、本番環境で、テスト環境へのデータベース・リンクを作成します。
ソース・ポータルからデータを移行する前に、まずポータルを登録する必要があります。登録すると、ソース・ポータルを選択し、トランスポート・セット内でデータソースを指定するために使用できるようになります。『Oracle Fusion Middleware Oracle Portal管理者ガイド』のソース・ポータルの登録に関する項を参照してください。
オブジェクトをインポートする前に、まずトランスポート・セットのコンテンツをターゲット・システムのトランスポート・セット表に移行する必要があります。これは、ステップ1で説明した登録済のデータベース・リンクを使用して、テスト環境からトランスポート・セットを取得することで実行します。トランスポート・セットの取得の詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』のデータのターゲット・システムへの移行に関する項を参照してください。
『Oracle Fusion Middleware Oracle Portal管理者ガイド』のデータのインポートに関する項の説明に従って、データをインポートします。
『Oracle Fusion Middleware Oracle Portal管理者ガイド』のユーザーとグループの移行に関する項の説明に従って、テスト環境のLDAPディレクトリから本番環境のLDAPディレクトリにユーザーとグループを移行します。
SSOMigユーティリティを使用して外部アプリケーション・リストをインポートします。
テスト環境においてエクスポート・モードでssomigを実行します。このコマンドは、ダンプ・ファイルを作成します。例:
ssomig -export -s orasso -p orasso_schema_password -c tns_alias_for_sso_schema -log_d directory_where_dump_needs_to_be_created -log_f ssomig.log -d ssomig.dmp
前の手順で作成したダンプ・ファイルを指定して、本番環境においてインポート・モードでssomigを実行します。例:
ssomig -import -overwrite -s orasso -p orasso_schema_password -c tns_alias_for_sso_schema -d ssomig.dmp -log_d directory_where_dump_is_located -discoforce
次の各ファイルについて、保持する必要があるすべてのカスタマイズをテスト環境のファイルから本番環境のファイルにコピーします。
DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/portal_plsql.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/portal_dads.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/appConfig.xml
構成ファイルを変更した場合、管理対象サーバーWLS_PORTALを再起動します。
Oracle WebCenterまたはOracle Portalがエクスポートおよびインポートを使用してテスト環境から移行されると、ポートレットのカスタマイズがトランスポート・セットに含まれることに注意してください。追加の手順の必要はありません。
Oracle Forms Servicesを新しい本番環境に移行するには:
次のコマンドを使用して、Oracleインスタンスで実行されているプロセスを停止し、本番環境の管理対象サーバーを停止します。
ORACLE_INSTANCE/bin/opmnctl stopall DOMAIN_NAME/bin/stopManagedWebLogic.sh managed_server_name admin_url username password
Oracle Forms Servicesアプリケーション・ファイル(FMX、MMXおよびPLX)をテスト環境から本番環境にコピーします。これらのファイルの場所は、Formsの環境構成ファイルであるdefault.envに指定されている場合があります。
ファイルが共有のネットワークの場所にある場合は、それらを本番環境にコピーする必要はありません。かわりに、その場所をdefault.envファイルに追加します。
データベース移行ツールを使用して、アプリケーション関連データをテスト環境から本番環境のデータベースに移行します。
本番環境のデータベースを参照するように、SQL*Net構成ファイルにエントリを作成します。
Formsアプリケーションは、シングル・サインオン・ユーザー名およびパスワードをデータベース接続文字列にマップします。この情報は、Oracle Internet Directoryに格納されます。Forms RADデータをテスト環境のOracle Internet Directoryから本番環境のOracle Internet Directoryに移行します。第21.4.1項の作業1「Oracle Internet Directoryの既存の本番環境への移行」のステップ3を参照してください。
保持する必要がある次のファイルのすべてのカスタマイズをテスト環境のファイルから本番環境のファイルにコピーします。
| ファイルのタイプ | 場所 |
|---|---|
| Formsアプリケーション構成 |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/formsweb.cfg
|
| Formsサーバー構成 |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/default.env
|
| Forms HTMLテンプレート |
ORACLE_INSTANCE/config/FormsComponent/forms/server/base.htm ORACLE_INSTANCE/config/FormsComponent/forms/server/basejpi.htm |
| WebUtil構成 |
ORACLE_INSTANCE/config/FormsComponent/forms/server/webutil.cfg
|
| WebUtil HTMLテンプレート |
ORACLE_INSTANCE/config/FormsComponent/forms/server/webutiljpi.htm ORACLE_INSTANCE/config/FormsComponent/forms/server/webutilbase.htm |
| Forms OHSディレクティブ構成 |
ORACLE_INSTANCE/config/OHS/OHS_name/moduleconf/forms.conf |
Oracle HTTP Serverのforms.confファイルを変更した場合、Oracle HTTP Serverを再起動します。
ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs_name
次のファイルをテスト環境から本番環境にコピーします。
| ファイルのタイプ | 場所 |
|---|---|
| Formsアプリケーション構成のクライアント側のダウンロード可能なプラッガブル・コンテンツ | これらのファイルは、イメージなどのユーザー・カスタマイズであり、Webブラウザでアクセス可能な場所にあります。 |
| Formsトレース構成 |
ORACLE_INSTANCE/config/FormsComponent/forms/server/ftrace.cfg
|
| Formアプリケーションの.ear |
ORACLE_HOME/forms/j2ee/formsapp.ear
|
| JVMコントローラ構成 |
ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/jvmcontrollers.cfg
|
| FMA構成 |
ORACLE_INSTANCE/config/FormsComponent/forms/search_replace.properties ORACLE_INSTANCE/config/FormsComponent/forms/converter.properties |
| Formsユーティリティ固有構成ラッパー・シェル・スクリプト |
UNIX: ORACLE_INSTANCE/bin/frmbld.sh ORACLE_INSTANCE/bin/frmcmp.sh ORACLE_INSTANCE/bin/frmplsqlconv.sh ORACLE_INSTANCE/bin/frmxmlsg.sh ORACLE_INSTANCE/bin/frmcmp_batch.sh ORACLE_INSTANCE/bin/frmf2xml.sh ORACLE_INSTANCE/bin/frmxml2f.sh ORACLE_INSTANCE/bin/frmxmlv.sh Windows: ORACLE_HOME\bin\frmbld.bat ORACLE_HOME\bin\frmcmp.bat ORACLE_INSTANCE\bin\frmplsqlconv.bat ORACLE_INSTANCE\bin\frmxmlsg.bat ORACLE_INSTANCE\bin\frmcmp_batch.bat ORACLE_INSTANCE\bin\frmf2xml.bat ORACLE_INSTANCE\bin\frmxml2f.bat ORACLE_INSTANCE\bin\frmxmlv.bat |
Formsユーティリティ固有構成ラッパー・シェル・スクリプトの場合、OracleホームおよびOracleインスタンスをすべて本番環境用の詳細に置き換えます。
次のコマンドを使用して、インスタンス内のコンポーネントを起動し、管理対象サーバーを起動します。
ORACLE_INSTANCE/bin/opmnctl startall DOMAIN_NAME/bin/startManagedWebLogic.sh managed_server_name admin_url
Forms Java EEアプリケーションの.earファイルに対してカスタマイズ(デフォルトのFormsサーブレット・アクセスURLの上書きなど)を行った場合、Forms Java EEアプリケーションの.earファイルをカスタム・デプロイし、Forms Java EEアプリケーションのweb.xmlファイルにテスト環境と同様のサーブレットの別名を作成します。
Oracle Reportsを本番環境に移行するには:
次のOracle Reports Server構成ファイルで、テスト環境で行われた変更を本番環境のファイルにマージします。それらのファイルをテスト環境から本番環境に単純にコピーすることはできないことに注意してください。ファイルには、OracleホームとOracleインスタンスの名前や場所、ポート番号など、環境固有の情報が含まれている可能性があるからです。
| ファイルのタイプ | 場所 |
|---|---|
| Reportsスタンドアロン・サーバー構成 |
ORACLE_INSTANCE/config/ReportsServerComponent/server_name/rwserver.conf ORACLE_INSTANCE/config/ReportsServer/server_name/jdbcpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/xmlpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/textpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsServer/server_name/component-logs.xml ORACLE_INSTANCE/config/ReportsServer/server_name/logging.xml |
| Reportsインプロセス・サーバーおよびサーブレット構成 |
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/cgicmd.dat DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwservlet.properties DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwserver.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jdbcpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/xmlpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/textpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwnetwork.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logging.xml DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logmetadata.xml DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jazn-data.xml |
| Reportsツール構成 |
ORACLE_INSTANCE/config/ReportsTools/rwbuilder.conf ORACLE_INSTANCE/config/ReportsTools/rwnetwork.conf ORACLE_INSTANCE/config/ReportsTools/jdbcpds.conf ORACLE_INSTANCE/config/ReportsTools/xmlpds.conf ORACLE_INSTANCE/config/ReportsTools/textpds.conf ORACLE_INSTANCE/config/ReportsTools/component-logs.xml ORACLE_INSTANCE/config/ReportsTools/logging.xml |
| Reportsブリッジ構成 |
ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwbridge.conf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/component-logs.xml ORACLE_INSTANCE/config/ReportsBridge/bridge_name/loggin.xml |
| Reportsシェル・スクリプト |
(UNIX) ORACLE_INSTANCE/config/reports/bin/rw*.sh (Windows) ORACLE_INSTANCE\config\reports\bin\rw*.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/reports.sh (Windows) ORACLE_INSTANCE\config\reports\bin\reports.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/namingservice.sh (Windows) ORACLE_INSTANCE\config\reports\bin\namingservice.bat |
Oracle Reports Server構成ファイルに関連する次のOracle Fusion Middleware構成ファイルで、テスト環境で行われた変更を本番環境のファイルにマージします。それらのファイルをテスト環境から本番環境に単純にコピーすることはできないことに注意してください。ファイルには、OracleホームとOracleインスタンスの名前や場所、ポート番号など、環境固有の情報が含まれている可能性があるからです。
| ファイルのタイプ | 場所 |
|---|---|
| JPS構成 |
DOMAIN_HOME/config/fmwconfig/jps-config.xml DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml |
| Forms構成ファイルおよびReports構成ファイル |
Font setup, aliasing, subsetting, embedding: ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/Uifont.ali Printer configuration (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uiprint.txt Toolkit configuration, encoding (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uTk2Motif.rgb PPD files (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon//tk/admin/PPD/* AFM files (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/AFM/* |
テスト環境に追加のOracle Reports Serverコンポーネント・インスタンスを作成した場合、opmnctlを使用してそれらを本番環境に作成します。
Oracle Reports Serverに関連するリソースに対して、次のアクションを実行します。
テスト環境で使用するすべてのフォントを環境変数REPORTS_FONT_DIRECTORYで指定されたディレクトリから本番環境にコピーします。デフォルトでは、フォントはORACLE_INSTANCE/reports/fontsにあります。
Common UNIX Printing System(CUPS)印刷構成を本番環境に移行します(該当する場合)。
Oracle ReportsでのCUPSの使用方法の詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』のCUPSを使用したLinuxでの拡張印刷に関する項を参照してください。
Reports定義ファイルおよびデータ表に対して、次のアクションを実行します。
テスト環境で使用されるレポート・ファイル(RDFファイル、JSPファイル、REPファイル、XMLファイルなど)を本番環境にコピーします。
JSP Webレポートを本番環境の次の場所にデプロイします。
DOMAIN_HOME/servers/WLS_REPORTS/stage/reports/reports/web.war
データベース移行ツール(Oracle Databaseのエクスポート・ユーティリティやインポート・ユーティリティなど)を使用して、RDFファイル内で参照されるReports固有のデータ表を本番環境のデータベースに移行します。
Reportsのジョブ関連の構成ファイルに対して、次のアクションを実行します。
Reportsサーバーのキャッシュ・ファイルを本番環境の次の場所にコピーします。
ORACLE_INSTANCE/reports/cache
Reportsのスケジュール済ジョブ情報に関して、サーバー・データ(server_name.dat)ファイルを本番環境の次の場所にコピーします。
ORACLE_INSTANCE/reports/server
サーバー名は作成時に自動的に生成され、.datファイルにはサーバー名付きの名前を付けられるため、.datファイルの名前は、テスト環境と本番環境で異なることに注意してください。スタンドアロン・サーバーかインプロセス・サーバーかに応じて、ファイル名は次の形式のいずれかになります。
ReportsServer_hostname_instanceName rep_wls_reports_hostname_instanceName
本番環境のホスト名およびOracleインスタンス名を反映するようにファイル名を変更します。
ジョブ・リポジトリまたはジョブ・ステータス・リポジトリがデータベースで構成されている場合、本番環境のデータベースに同じスキーマを作成し、データを移行する必要があります。
次のスクリプトを使用します。
ORACLE_HOME/reports/admin/sql/rw_job_repos.sql
データベース移行ツール(Oracle Databaseのエクスポート・ユーティリティやインポート・ユーティリティなど)を使用して、スキーマRW_JOBS、RW_SERVER_JOB_QUEUEおよびRW_SERVER_QUEUEのテスト・データベースのデータを本番データベースに移行します。
ユーザーおよびレポート・サーバーのセキュリティ・ポリシー情報を移行します。『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』のOracle Reportsの保護に関する項を参照してください。
アイデンティティ・ストアおよびポリシー・ストアとしてOracle Internet Directoryを使用する場合は、Forms RADデータをテスト環境のOracle Internet Directoryから本番環境のOracle Internet Directoryに移行します。第21.4.1項の作業1「Oracle Internet Directoryの既存の本番環境への移行」のステップ3を参照してください。
テスト環境でJAZN-XMLベースのアイデンティティ・ストアおよびポリシー・ストアを使用していた場合は、それらを本番環境のLDAPに移行します。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のコマンドmigrateSecurityStoreを使用したポリシーの移行に関する項に説明されているとおり、WLSTコマンドmigrateSecurityStoreを使用することができます。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のコマンドmigrateSecurityStoreを使用した資格証明の移行に関する項の説明に従って、WLSTコマンドmigrateSecurityStoreを使用して資格証明ストアを移行します。
データベース・クローニング・ツールを使用して、すべてのデータベース・プロキシ・ユーザーを本番データベースに移行します。
Reportsプラグインが登録されている場合、対応する.jarファイルを本番環境にコピーし、これらのファイルへのパスを環境変数REPORTS_CLASSPATHに追加します。
Oracle BI Discovererを新しい本番環境に移行するには:
デフォルトのユーザー・プリファレンスを変更した場合、次のファイルをテスト環境から本番環境にコピーします。
ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/.reg_key.dc ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/pref.txt ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/defaults.txt
Oracle BI Discovererの設定を変更した場合、次のファイルをテスト環境から本番環境にコピーします。
DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration.xml DOMAIN_HOMEconfig/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration-preview.xml
configuration.xmlファイルで、次の要素の値を本番環境を反映するように変更します。
applicationURL
oracleInstance
discovererComponentName
サーバー構成ファイルを変更した場合、次のファイルをテスト環境から本番環境にコピーします。
ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
次のファイルをテスト環境から本番環境にコピーします。
ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/module_disco.conf
次の要素の値を本番環境を反映するように変更します。
WebLogicCluster。クラスタが存在する場合のみ有効です。
WebLogicHost
WebLogicPort
次のファイルをテスト環境から本番環境にコピーします。
DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/base-descktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/blstyles.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf-review.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf.xsd DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/minimal-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/minimal-pda.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/oracle-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/oracle-pda.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/pocketPC.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/simple-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/swan-desktop.xss
使用するファイルに応じて、次のディレクトリのファイルの一部またはすべてをコピーします。
DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/discoverer.war/custom_logos/
使用されるファイルは、configuration.xmlファイルにリストされます。
同じデータベース・サービスのエントリを使用するには、次のファイルをテスト環境から本番環境にコピーします。
ORACLE_HOME/network/admin/tnsnames.ora
DISCOVERERスキーマをテスト環境から本番環境に移行します。Oracle Databaseのエクスポート・ユーティリティおよびインポート・ユーティリティを使用してスキーマを移行できます。
テスト環境と本番環境で同じデータベースを使用する場合は、データを移行する必要はありません。
EULデータをテスト環境から本番環境に移行します。
本番データベースにEULユーザーおよび空のEULを作成します。Oracle Fusion Middleware Oracle Business Intelligence Discoverer管理者ガイドの新しいデータベース・ユーザーにおけるEnd User Layerの作成方法に関する項を参照してください。
Discoverer Administratorを使用してEULスキーマをテスト・データベースからエクスポートして本番環境のデータベースにインポートすることにより、EULスキーマをテスト・データベースから移行します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer管理者ガイドのDiscovererのエクスポート・ウィザードおよびインポート・ウィザードの使用に関する項を参照してください。
eul5_id.sqlスクリプトを実行して新しいEULに一意の参照番号を付けます。その後、Discovererのエンド・ユーザー・コミュニティ全体にEULへのアクセス権を付与します。このスクリプトは、次の場所にあります。
ORACLE_ HOME/discoverer/util/eul5_id.sql
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer管理者ガイドのEnd User Layerの作成と保守に関する項を参照してください。
カタログ・データをテスト環境から本番環境に移行します。
次のコマンドを使用して、カタログを本番のOLAPデータベースにインストールします。
java -classpath d4o.jar oracle.dss.d4o.administration.D4OCommand install -h hostname -po port -sid sid -su "sys as sysdba" -sp password -p d4osys-password -t users
次のコマンドを使用して、本番のOLAPデータベースのユーザーを承認します。
java -classpath d4o.jar oracle.dss.d4o.administration.D4OCommand authorize -h hostname -po port -sid sid -p d4osys-password -u user
OLAPコマンド・ユーティリティを使用して、テスト・データベースからDiscovererカタログをエクスポートし、それを本番環境のデータベースにインポートします。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscoverer Plus OLAPコマンドライン・ユーティリティを使用したDiscovererカタログの管理に関する項を参照してください。
ポートレット・データをテストのDiscovererメタデータ・リポジトリから本番のDiscovererメタデータ・リポジトリに移行します。
Oracle Databaseのエクスポート・ユーティリティおよびインポート・ユーティリティを使用します。
インポートを複数回実行して、親表が子表の前に移入されるようにする必要がある場合があります。SQLエラーを回避するには、PTM5_PARTITION、PTM5_PORTLET、PTM5_VERSION、PTM5_INSTANCE、PTM5_SCHEDULE、PTM5_CACHE、PTM5_CUSTOMINFOという順序で実行する必要があります。
新しい本番設定を指すようにPortalのポートレット・プロバイダURLを変更します。
PStoreデータを移行します。
デフォルトの暗号化鍵を表WWSSO_PS_CONFIGURATION_INFO_Tから削除します。
Oracle Databaseのエクスポート・ユーティリティおよびインポート・ユーティリティを使用して、Discovererメタデータ・リポジトリのPStoreデータを移行します。
ユーザー名とスキーマ名は、本番環境とテスト環境で同じである必要があります。
このシナリオでは、Oracle Portal、Oracle Forms Services、Oracle ReportsおよびOracle Business Intelligence Discovererをテスト環境にインストール済で、これらのコンポーネントをすでに存在している本番環境に移行する必要があると想定します。
既存の本番環境に移行するには、次の作業を実行します。
このシナリオでは、テスト環境でOracle Portalに対して変更(ページの追加、ページへのコンテンツの追加、新しいユーザーおよびグループの作成、新しいユーザーおよびグループへの新しく作成したページへのページ・アクセス権限の割当てなど)を行ったことを想定します。
Oracle Portalを既存の本番環境に移行するには、第21.4.9.1項の作業2「Oracle Portalの新しい本番環境への移行」の説明に従って、各手順を実行します。
Oracle Forms Servicesを既存の本番環境に移行するには:
Oracle Forms Servicesアプリケーション・ファイル(FMX、MMXおよびPLX)をテスト環境から本番環境にコピーします。これらのファイルの場所は、Formsの環境構成ファイルであるdefault.envに指定されている場合があります。
ファイルが共有のネットワークの場所にある場合は、それらを本番環境にコピーする必要はありません。かわりに、その場所をdefault.envファイルに追加します。
『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』のアプリケーションのデプロイに関する項の説明に従って、必要な構成変更を行います。
コンポーネントを再起動します。
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
Oracle Reportsを既存の本番環境に移行するには、第21.4.9.1項の作業4「Oracle Reportsの新しい本番環境への移行」の説明に従って、同様に手順を実行します。
このシナリオでは、本番環境のパフォーマンスを悪化させずに、最初にテスト環境を使用してビジネス領域を開発するためのEULを作成することを想定しています。
Oracle BI Discovererを既存の本番環境に移行するには:
第21.4.9.1項の作業5「Oracle Business Intelligence Discovererの新しい本番環境への移行」のステップ1および5に示されている構成ファイルを移行します。
DISCOVERERスキーマをテスト環境から本番環境に移行します。Oracle Databaseのエクスポート・ユーティリティおよびインポート・ユーティリティを使用してスキーマを移行できます。
テスト環境と本番環境で同じデータベースを使用する場合は、データを移行する必要はありません。
Oracleデータベースのエクスポート・ユーティリティおよびインポート・ユーティリティを使用して、スキーマをテスト・データベースからエクスポートして本番環境のデータベースにインポートすることにより、EULスキーマをテスト環境から本番環境に移行します。
ユーザー名とスキーマ名は、本番環境とテスト環境で同じである必要があります。
次の各項目では、Oracle Data Integratorをテスト環境から本番環境に移行する方法について説明します。
どちらのシナリオでも、テスト環境で次の操作を実行済です。
Oracle WebLogic Serverをインストールし、JavaコンポーネントのMiddlewareホームを作成しました。
RCUを使用して、テスト・データベースで必要なスキーマを作成しました。
Oracle Data Integratorをインストールしました。
構成ウィザードを使用して、Oracle Data Integrator Javaコンポーネントを構成してデプロイしました。Javaコンポーネントは、テスト・リポジトリに接続し、テスト・リポジトリを使用できます。
スタンドアロン・エージェントを構成しました。スタンドアロン・エージェントは、テスト・リポジトリに接続し、テスト・リポジトリを使用できます。
トポロジ内で論理アーキテクチャおよび物理アーキテクチャを構成しました。データ・サーバーの接続は、Studioから、および任意の物理エージェントからテストする必要があります。
ユーザーおよび権限を定義することで、セキュリティを構成しました。
シナリオで使用するオープン・ツールを宣言しました。
リポジトリに1つ以上の開発(パッケージ)またはランタイム(シナリオ)アーティファクトをデプロイしました。
一部の構成設定を変更しました。たとえば、データ・サーバーの構成を、テスト環境と一致するように変更したといったことが考えられます。
このシナリオでは、Oracle Data Integratorをテスト環境にインストール済で、これをまだ存在していない本番環境に移行する必要があると想定します。
Oracle Data Integratorを新しい本番環境に移行するには、次の作業を実行します。
本番環境にソフトウェアをインストールして初期構成を実行するには:
RCUを使用して、本番データベースで必要なマスター・リポジトリおよび作業リポジトリのスキーマを作成します。『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
本番環境の作業リポジトリとマスター・リポジトリの両方が、それぞれ組織全体で一意のIDで作成されていることを確認します。これには、開発リポジトリとテスト・リポジトリも含まれます。さらに、本番の作業リポジトリが、テスト・リポジトリと同じタイプで作成されていることを確認します(たとえば、テストの作業リポジトリが開発リポジトリとして作成されている場合、本番の作業リポジトリも開発リポジトリとして作成される必要があります)。
Oracle Data Integratorをインストールします。
Javaコンポーネントを使用している場合は、第21.3.3項の説明に従って、Middlewareホームのコピーをテスト環境から本番環境に移行します。Middlewareホーム内のOracle WebLogic ServerホームおよびOracleホームも移行されます。
Oracle Data Integratorのスタンドアロン・インストールを実行した(つまり、Javaコンポーネントをインストールしていない)場合は、同じコンポーネントとともにOracle Data Integratorを本番環境にインストールします。
Oracle Data Integratorを含むドメインを作成します。
Javaコンポーネントを使用している場合は、第21.3.4項の説明に従って、Oracle Data Integratorを含むドメインのコピーをテスト環境から本番環境に移行します。
Oracle Data Integratorのスタンドアロン・インストールを実行した場合は、『Oracle Fusion Middleware Oracle Data Integratorインストレーション・ガイド』のWebLogicドメインの構成に関する項の説明に従って、構成ウィザードを使用して、Oracle Data Integratorを構成し、ドメインを作成します。
本番環境で必要なOracle Data Integratorのスタンドアロン・エージェントを構成します。『Oracle Fusion Middleware Oracle Data Integratorインストレーション・ガイド』のスタンドアロン・エージェントの構成に関する項を参照してください。
トポロジを新しい本番環境に移行するには:
Oracle Data Integrator Studioを使用して、テストのマスター・リポジトリからトポロジをエクスポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のトポロジとセキュリティ設定のエクスポート/インポートに関する項を参照してください。
Oracle Data Integrator Studioを使用して、トポロジを本番のマスター・リポジトリにインポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のトポロジとセキュリティ設定のエクスポート/インポートに関する項を参照してください。このインポートには、シノニム・モードINSERT_UPDATEを使用します。
作業リポジトリの内容を新しい本番環境に移行するには:
Oracle Data Integrator Studioを使用して、テストの作業リポジトリから作業リポジトリの内容をエクスポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の作業リポジトリのエクスポートとインポートに関する項を参照してください。
Oracle Data Integrator Studioを使用して、作業リポジトリの内容を本番の作業リポジトリにインポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の作業リポジトリのエクスポートとインポートに関する項を参照してください。
本番環境で次の設定を変更します。
外部認証: テスト環境のOracle Data Integratorリポジトリを外部認証に使用する場合は、次の手順を実行します。
すべてのスタンドアロン・エージェントおよびODI Studioについて、jps-config.xmlファイルをテスト環境から本番環境にコピーします。
ODI Studioの場合は、次の場所にファイルをコピーします。
ODI_HOME/client/odi/bin
本番環境の値を使用してOracle Internet Directoryのプロパティを更新します。
スタンドアロン・エージェントの場合は、次の場所にファイルをコピーします。
ODI_HOME/agent/bin
本番環境の値を使用してOracle Internet Directoryのプロパティを更新します。
ODI Studioを使用して本番のマスター・リポジトリに接続します。RCUでOracle Data Integratorリポジトリを作成したときに指定したOracle Data Integratorのスーパーバイザ・ユーザーを使用してログインします。
『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の認証モードの切替えに関する項の説明に従って、認証モードを外部に変更し、GUIDを同期します。この手順の実行後は、テスト環境で作成したユーザーを使用してODI Studioにログインできます。
トポロジ設定: 通常、テスト環境と本番環境で異なるコンテキストを使用し、コンテキストを切り替えて、該当する環境でシナリオのスケジュールを指定したり、シナリオを実行したりすることをお薦めします。単一のコンテキストを使用すると、本番への移行時に、物理アーキテクチャ構成(データ・サーバーのホスト名など)を変更する必要が生じます。
テスト環境と本番環境で異なるOracle Data Integratorコンテキストを使用しており、物理アーキテクチャがすでに本番環境用に定義されている場合は、続行する前に、この物理アーキテクチャを確認します。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のトポロジの設定に関する項を参照してください。
両方の環境で同じコンテキストを使用している場合は、本番のマスター・リポジトリの物理アーキテクチャで次の項目を確認して変更する必要があります。
物理エージェント: ホスト、ポートおよびWebアプリケーション・コンテキスト(Java EE Agent用)を、本番環境の構成と一致するように変更します。
データ・サーバー: データ・サーバーの接続に関する情報(JDBC、JNDI、データソース名)を、本番環境の構成と一致するように変更します。
物理スキーマ: データ・サーバー用に定義されたスキーマ(ファイル・フォルダの場所を含みます)は、本番環境の構成と一致している必要があります。
スケジューリング: テスト環境と本番環境で異なるOracle Data Integratorコンテキストを使用しており、スケジュールがテスト・コンテキストで実行されるようにのみ定義されている場合、本番の作業リポジトリでこれらのスケジュールを、本番コンテキストで実行されるように変更する必要があります。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のシナリオのスケジューリングに関する項を参照してください。
両方の環境で同じコンテキストを使用している場合は、既存のスケジュールを変更する必要はありません。
テスト環境でシナリオのスケジュールが定義されていない場合、本番環境でスケジュールを作成できます。
本番環境でスタンドアロン・エージェントおよびJava EEエージェントを再起動します。これらのエージェントは、スケジュール済シナリオの処理を開始します。
このシナリオでは、テスト環境に多数の新しいシナリオまたは再生成されたシナリオがあり、これらをすでに存在している本番環境に移行する必要があると想定します。
|
注意: 本番環境にすでにデプロイされたシナリオは、本番環境に移行される前に再生成される必要があります。これらのシナリオを削除して生成しないでください。 |
既存の本番環境では、第21.4.10.1項の説明に従って、コンポーネントをインストールおよび構成済です。データ統合シナリオをテスト環境から本番環境のOracle Data Integratorに移行する必要があります。
Oracle Data Integratorシナリオを既存の本番環境に移行するには、次の作業を実行します。
テスト環境のトポロジが新しいシナリオに対して変更されたか追加された場合は、この作業を実行します。
トポロジの更新を既存の本番環境に移行するには:
Oracle Data Integration Studioを使用して、更新された物理/論理トポロジ項目または新しい物理/論理トポロジ項目(データ・サーバー、スキーマ、エージェント)をテストのマスター・リポジトリからエクスポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のオブジェクトのエクスポートとインポートに関する項を参照してください。
Oracle Data Integration Studioを使用して、更新された物理/論理トポロジ項目または新しい物理/論理トポロジ項目(データ・サーバー、スキーマ、エージェント)を本番のマスター・リポジトリにインポートします。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のオブジェクトのエクスポートとインポートに関する項を参照してください。
オープン・ツール定義を更新し、新しいものを宣言します。
Oracle Data Integratorシナリオを既存の本番環境に移行するには:
Oracle Data Integrator Studioを使用して、新しいシナリオまたは再生成されたシナリオをテストの作業リポジトリからエクスポートします。単一シナリオのエクスポートまたは複数シナリオのエクスポートを使用してこれらをエクスポートできます。または、指定のプロジェクトまたはフォルダ内のすべてのシナリオをエクスポートすることもできます。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のシナリオのエクスポートに関する項を参照してください。
Oracle Data Integrator Studioを使用して、新しいシナリオまたは再生成されたシナリオを本番の作業リポジトリにインポートします。このインポートには、シノニム・モードINSERT_UPDATEを使用します。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の本番へのシナリオのインポートに関する項を参照してください。
本番の作業リポジトリのスケジュールを、本番コンテキストで新しいシナリオを実行するように変更します。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のシナリオのスケジューリングに関する項を参照してください。
Oracle Real Application Cluster (Oracle RAC)環境に、またはOracle Real Application Cluster (Oracle RAC)環境から環境を移行している場合は、次の点に注意してください。
Oracle RAC環境ではないテスト環境から、Oracle RACを使用する本番環境に移行している場合、移行計画には、汎用データソースの1つのエントリ(mds-soaなど)があります。Oracle RACインスタンスの1つを指すように移行計画を更新し、テスト環境から本番環境への移行を完了します。
そして、『Oracle Fusion Middleware高可用性ガイド』(特に可用性の高いOracleデータベース・アクセスの考慮事項に関する項)の説明に従って、Oracle RAC用に本番環境を構成します。
Oracle RAC環境を使用するテスト環境から、Oracle RACを使用しない本番環境に移行している場合、移行計画には、汎用データソースの複数のエントリがあります。たとえば、4つのOracle RACインスタンスがある場合、mds-soa-rac1からmds-soa-rac4までの名前を持つ4つの汎用データソースがあります。すべての汎用データソースが本番環境のRAC以外の単一インスタンスを指すように、移行計画を更新します。
|
注意: 移行計画にリストされていない場合でも、複数のデータソースがターゲット環境に移行されます。 |
Oracle RACを使用するテスト環境から、Oracle RACを使用する本番環境に移行しているが、本番環境にそれ以外のOracle RACインスタンスがある場合、移行計画には、複数のデータソースの1つのエントリ(mds-soaなど)があります。加えて、汎用データソースの複数のエントリがあります。たとえば、テスト環境に3つのOracle RACインスタンスがある場合、mds-soa-rac1からmds-soa-rac3までの名前を持つ3つの汎用データソースがあります。本番環境には4つのOracle RACインスタンスがあります。汎用データソースが本番環境の最初の3つのデータソースを指すように、移行計画を更新します。
Oracle RACを使用するテスト環境から、Oracle RACを使用する本番環境に移行しているが、本番環境にそれより少ないOracle RACインスタンスがある場合、移行計画には、複数のデータソースの1つのエントリ(mds-soaなど)があります。加えて、汎用データソースの複数のエントリがあります。たとえば、テスト環境に4つのOracle RACインスタンスがある場合、mds-soa-rac1からmds-soa-rac4までの名前を持つ4つの汎用データソースがあります。本番環境には3つのOracle RACインスタンスがあります。最初の3つの汎用データソースが本番環境の3つのデータソースを指すように、移行計画を更新します。最後の汎用データソースは、3つ目の汎用データソースを指すようにします。(3つ目のOracle RACインスタンスにはmds-soa-rac3およびmds-soa-rac4が含まれます)。
第10.2.1.1項の説明に従って、データソースを追加できます。
次の制限事項に注意してください。
本番環境のオペレーティング・システムは、テスト環境と同じものである必要があります。また、オペレーティング・システム・アーキテクチャは、両方の環境で同じでなければなりません。たとえば、両方の環境で32ビットのオペレーティング・システムまたは64ビットのオペレーティング・システムを実行している必要があります。
ターゲット環境では、ソース環境のユーザーと同じスーパーユーザーまたは管理ユーザーが必要です。ユーザーのパスワードは、別々のものにできます。パスワードは、pasteConfigコマンドを使用してコマンド・ラインで指定できます。
インストールの移行が完了したら、ターゲット環境でユーザーを変更できます。
コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)
copyConfigおよびpasteConfigスクリプトを使用して新しいドメインを作成する場合は、そのドメインに追加のドメイン・テンプレートを適用して拡張することはできません。環境を移行する前に、必要なすべてのテンプレートをソース環境のドメインに適用していること確認してください。
リソース(デプロイメントやサービスなど)のデフォルト・ターゲットを、構成ウィザードによる初期構成時、またはその後の管理コンソールによる構成時に変更すると、これらの変更はcopyConfigおよびpasteConfigスクリプトによってレプリケートされません。スクリプトの使用後に、手動でそのリソースのターゲットを再設定する必要があります。
コンポーネントの構成を移行する際、スクリプトcopyConfigによって処理されるのは、各Oracle WebLogic Serverドメイン内で定義されているグローバル・データソースのみです。アプリケーション・レベルのデータソースについては、アプリケーション・レベルのデータソースで構成されているADFアプリケーションをターゲット・ドメイン内のサーバーにデプロイし、ターゲット・ドメインでデータソースを手動で構成する必要があります。
カスタム・アプリケーションで内部データソースを使用する場合(たとえば、JDeveloperを使用してアプリケーションが作成され、内部データソースとともにデプロイされている場合など)、pasteConfig操作では内部データソースは移行されません。
この問題を解決するには、ドメインに外部データソースを作成し、アプリケーションでそのデータソースを使用するように変更して、アプリケーションを再度デプロイします。
ソースのWebLogic ServerまたはOracleホームの外部にあるファイルまたはアプリケーションへのシンボリック・リンクを作成していた場合、アプリケーションを正しく機能させるには、ターゲット・ホームでそのシンボリック・リンクを手動で再作成する必要があります。
Oracle Fusion MiddlewareがインストールされていないホストにMiddlewareホームのクローンを適用する場合は、そのホストにJDK 1.6.04以降がインストールされている必要があります。さらに、PATH、CLASSPATHおよびJAVA_HOME環境変数がJDKを指している必要があります。
ソースMiddlewareホームで、Middlewareホームの外部にあるJDKを使用する場合、pasteBinary操作でも外部のJDKを使用する必要があります。
エンティティを移行する際に一時ディレクトリに十分な領域がない場合は、その旨を示すエラーが返されます。この問題が発生しないようにするには、第20.3項で説明しているように、T2P_JAVA_OPTIONS環境変数を使用して、一時ディレクトリとして別の場所を指定します。
Oracle SOA Suite管理対象サーバーを起動しようとしてエラーが発生した場合は、pasteConfigスクリプトの実行後に管理コンソールを使用して、システム・パラメータを変更する必要があります。(これらのシステム・パラメータには、pasteConfigスクリプトによって一時的な値が設定されます。)
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
サーバーを選択します。
「サーバーの起動」タブを選択します。
「引数」フィールドで、次のパラメータを入力します。
-Dtangosol.coherence.wkan=hostname -Dtangosol.coherence.localhost=hostname -Dtangosol.coherence.localport=localport_number -Dtangosol.coherence.wka1.port=port_number_for_Coherence
「保存」をクリックして、「変更のアクティブ化」をクリックします。
サーバーを起動します。
pasteBinaryまたはpasteConfigスクリプトを実行して移動計画に不正な情報を入力すると、スクリプトはエラーを返します。場合によっては、貼付け操作が部分的に実行されていることもあります。リカバリするには、エラーを返したスクリプトに応じて、次の処理を実行します。
ターゲットで、Middlewareホーム・ディレクトリの移行中に、pasteBinaryスクリプトでエラーが返された場合は、次の手順を実行します。
ターゲットのMiddlewareホームを削除します。
OracleインベントリにOracleホーム・エントリが存在する場合、それを削除します。
Windowsでは、MiddlewareホームおよびOracleホームのショートカットを削除します。
Javaコンポーネントの移行中に、pasteConfigスクリプトでエラーが返された場合は、次の手順を実行します。
ドメインに関連するすべてのプロセスを停止します。
次のディレクトリを削除します。
MW_HOME/user_projects/domains/domain_home MW_HOME/user_projects/applications/domain_name
スキーマを削除して、RCUを使用してそれらを再作成します。
また、Oracle Platform Securityの再割当てが失敗した場合、次の処理を実行します。
LDAPストアでは、ドメイン・ノードを削除するか移動計画で別の値を指定します。
データベースベース・ストアでは、スキーマを削除しRCUを使用してそれを再作成します。
システム・コンポーネントの移行中に、pasteConfigスクリプトでエラーが返された場合は、次の手順を実行します。
インスタンスを削除します。
インスタンスを削除できない場合、そのインスタンスに関連するすべてのプロセスを停止してOracleインスタンスを削除します。
config.xmlファイルで、マシンがunix-machineTypeとして指定されていると、pasteConfigスクリプトはエラーCLONE-20408で失敗します。この問題を回避するには、次のファイルでマシン・タイプを変更します。
DOMAIN_HOME/config/config.xml
ファイルの次の行で、「xsi:type="unix-machineType"」を削除します。
<machine xsi:type="unix-machineType">
<name>machine_name</name>
例:
<machine>
<name>machine_name</name>
pasteConfigスクリプトを使用しているときにメモリー不足エラーが発生した場合は、次のいずれかの方法でこのエラーを回避できます。
JVMヒープ・サイズを拡張します。最大ヒープ・サイズにオプション-Xmxを、初期ヒープ・サイズに-Xmsを使用します。例:
CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"
多くの場合、Oracle WebLogic Serverドメインのディレクトリ構造には、不要な大容量ファイル(大容量の古いログ・ファイルなど)が含まれています。これらのファイルを削除してから、copyConfigおよびpasteConfigスクリプトを再度実行します。
