| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
前 |
次 |
この章では、Oracle JDeveloperで作成したEnterprise Archive、つまりEARファイルからのPortal Frameworkアプリケーションのデプロイ、アンデプロイおよび再デプロイについて説明します。
EARファイルの作成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter PortalおよびOracle Jdeveloperでのポータルの開発』のWebLogic管理対象サーバーへのPortal Frameworkアプリケーションのデプロイに関する項を参照してください。
この章には、Oracle WebCenter Portalの初期設定のポータル・アプリケーション「WebCenter Portal」のデプロイおよびインストールに関する手順は含まれていません。WebCenter Portalおよびその関連コンポーネントのインストールの詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の「Oracle WebCenter Portalのインストール」を参照してください。WSRPおよびPDK-Javaのポートレット・プロデューサ・アプリケーションのデプロイの詳細は、第21.11項「ポートレット・プロデューサ・アプリケーションのデプロイ」を参照してください。
|
権限: この章のタスクを実行するには、次のロールが付与されている必要があります。
第1.8項「管理操作、ロールおよびツールの理解」も参照してください。 |
この項では、JDeveloperで作成されたPortal Frameworkアプリケーションを本番ドメインにデプロイするために必要な手順について説明します。この項のデプロイ手順では、EARファイルをデプロイすること、その場所が判明していること、およびデプロイ先のドメインが存在することを前提としています。
WebLogic Serverドメインの作成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の新しいドメインの作成に関する項を参照してください。アプリケーションのデプロイの詳細は、Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイを参照してください。
この項には次のトピックが含まれます:
この項のフロー・チャートと表は、Portal FrameworkアプリケーションをOracle WebLogic管理対象サーバーにデプロイするための前提条件と必要なタスクの概要を示しています。図42-1に、Portal Frameworkアプリケーションのデプロイ手順およびそれらを実行するロールを示します。
表42-1に、JDeveloperからPortal Frameworkアプリケーションをデプロイするためのタスク、サブタスクおよびそれらの実行担当者を示します。
表42-1 管理対象サーバーへのPortal Frameworkアプリケーションのデプロイ
| 担当者 | タスク | サブタスク | ノート |
|---|---|---|---|
|
開発者 |
1. アプリケーションのパッケージ化 |
1.a データ・ソース・タイプの選択(データベース接続のパッケージ化) |
グローバル・データ・ソースまたはアプリケーションレベルのデータ・ソースのどちらかを使用できます。 グローバル・データ・ソースを使用する場合、デプロイする前にWLS管理コンソールでデータ・ソースを作成する必要があります。 アプリケーションレベルのデータ・ソースを使用する場合、デプロイした後にWLS管理コンソールで資格証明のマッピングを追加する必要があります。 |
|
1.b アプリケーション・セキュリティ・データのパッケージ化 |
このサブタスクには、資格証明、アイデンティティ・データおよびアプリケーション・ポリシーのパッケージ化が含まれます。 |
||
|
1.c デプロイメント・プロファイルの作成 |
このサブタスクには、WARおよびEARのファイルの作成が含まれます。 |
||
|
管理者 |
2. ターゲット環境の準備 |
2.a 管理対象サーバーの作成およびプロビジョニング |
|
|
2.b MDSリポジトリの作成および登録 |
|||
|
2.c ターゲット環境の構成 |
|||
|
2.d サーバー接続の作成 |
|||
|
管理者 |
3. 管理対象サーバーへのアプリケーションのデプロイ |
最終手順として、Fusion Middleware Control、WLSTまたはWLS管理コンソールのいずれかを使用して、アプリケーションを管理対象サーバーにデプロイします。 |
Portal Frameworkアプリケーションは、Oracle WebCenter PortalライブラリでプロビジョニングされるWebLogic管理対象サーバー・インスタンスにデプロイできます。
|
注意: インストール中に作成した事前構成済管理対象サーバーのいずれかや管理サーバーにPortal Frameworkアプリケーションをデプロイすることはお薦めしません。Portal Frameworkアプリケーションの場合、アプリケーションをデプロイする前に新しいWLS管理対象サーバーを作成してプロビジョニングするには、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の既存ドメインの拡張に関する項の手順を実行してください。ポートレット・プロデューサ・アプリケーションの場合、オプションで新しいWebLogic管理対象サーバーを作成するか、 |
デプロイする前に必要な作業は次のとおりです。
第42.1.3項「アプリケーションEARファイルの準備」で説明されているように、アプリケーションEARファイルを準備します。
第42.1.4項「管理対象サーバーの作成」で説明されているように、WebLogic管理対象サーバーを作成します。
第42.1.5項「メタデータ・サービス・リポジトリの作成および登録」で説明されているように、Metadata Service (MDS)リポジトリを作成して登録します。
|
注意: ページ、接続またはタスク・フローなどのアーティファクトに大規模な変更が加えられた更新アプリケーションをデプロイする前に、ランタイム・カスタマイズ(JDeveloperを使用しないカスタマイズ)を削除する必要があります。 |
これらの手順を完了したら、第42.1.6項「WebLogic管理対象サーバーへのアプリケーションのデプロイ」の説明に従ってアプリケーションをデプロイすることで続行してください。
アプリケーションをデプロイする前に、まずデプロイメント・プロファイルを作成する必要があります。アプリケーションがEARファイルとしてOracle WebLogic管理対象サーバーにデプロイできるように、デプロイメント・プロファイルによって、Portal Frameworkアプリケーションおよびその関連ファイルをパッケージ化します。
アプリケーション用デプロイメント・プロファイル(およびその結果のEARファイル)の作成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter PortalおよびOracle Jdeveloperでのポータルの開発』のFrameworkアプリケーションのパッケージ化に関する項を参照してください。
EARファイルは、複数の情報アーティファクトをパッケージ化します。次のものが含まれます。
アプリケーション自体: .jspx、.jarおよび.classファイルなどの各種のアプリケーションです。
アプリケーション構成: このアプリケーション用に構成されたツール、サービスおよびプロデューサとの接続プロパティ、およびURLエンドポイントが含まれます。
アプリケーション・メタデータ: アプリケーションのデザイン時に作成されたアプリケーション・メタデータのエクスポートです。
ポートレット・カスタマイズ: ポートレット用のカスタマイズ設定とデータが含まれます。この情報はプロデューサ内に保持されますが、登録されたプロデューサのあるアプリケーションがパッケージ化されるときにエクスポートされます。カスタマイズ・データは、Portal Frameworkアプリケーションの残りのメタデータでパッケージ化されます。
Portal Frameworkアプリケーションをデプロイする前に、必要な共有ライブラリおよびMDSリポジトリが含まれているOracle WebCenter Portal Frameworkテンプレートに基づいて、WebLogic管理対象サーバーを作成する必要があります。Portal Frameworkアプリケーションがポートレット化されている場合、Oracle WebCenter Portal Custom Services Producerサーバー(WC_CustomServicesProducer)にデプロイしてください。ポートレット化されたアプリケーションは、Oracle WebCenter Portal Custom Portalサーバーにはデプロイできません。必要なポートレット・ライブラリが不足しているからです。MDSスキーマだけでなく、WebCenter PortalおよびアクティビティもOracle WebCenter Portal Custom Services ProducerサーバーおよびOracle WebCenter Portal Custom Portalサーバーがターゲットです。
新しい管理対象サーバーの作成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の既存ドメインの拡張に関する項を参照してください。新しいドメインの作成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の新しいドメインの作成に関する項を参照してください。
アプリケーションを管理対象サーバーにデプロイする前に、そのアプリケーション用のMetadata Service (MDS)リポジトリ・スキーマをWebLogicドメインの管理サーバー・インスタンスに作成して登録する必要がある場合があります。ターゲット・サーバー(Oracle WebCenter Portal Custom PortalサーバーまたはOracle WebCenter Portal Custom Services Producerサーバー)にはすでにMDSデータ・ソースが構成されているため、事前に構成されたサーバーMDSデータ・ソースを使用しない場合のみ、この手順が必要です。ただし、他のアプリケーションで共有している場合、新しいMDSスキーマは作成しないでください。
|
注意: この項で説明しているカスタム・スキーマを使用するかわりに、WebCenter Portalのインストール時に作成されたMDSスキーマを使用してデプロイすると、これらのスキーマのデータを壊す危険性があります。 |
デプロイ時には、本番環境で使用できるように、EARファイルにエクスポートされた一部の構成情報およびアプリケーション・メタデータをMDSスキーマにインポートする必要があります。ターゲット・メタデータ・スキーマを選択したら、メタデータのインポートはデプロイ時に自動的に実行されます(第42.1.6項「WebLogic管理対象サーバーへのアプリケーションのデプロイ」を参照)。
MDSスキーマは、リポジトリ作成ユーティリティ(RCU)を使用して作成します。MDSスキーマを作成したら、Fusion Middleware Controlを使用するか、WLSTを使用したコマンド行から登録する必要があります。
この項には次のサブセクションが含まれます:
アプリケーションをデプロイする前に、まずリポジトリ作成ユーティリティ(RCU)を使用してMDSスキーマをデータベース・サーバーのインスタンスに作成し、デプロイ先ドメインの管理サーバーに登録して、アプリケーションのメタデータもデプロイできるようにする必要があります。
次の手順を実行するときは、MDSスキーマ名と、アクセスするためのログイン資格証明を必ずメモに記録してください。この情報は、デプロイメント処理の続きの手順で必要になります。
MDSスキーマの作成するには:
RCU_HOME/binに移動し、次のコマンドを実行してRCUを起動します。
rcu
RCUの「ようこそ」ページが表示されます(図42-2を参照)。
「次へ」をクリックします。
「リポジトリの作成」ページで、「作成」を選択し、「次へ」をクリックします。
「データベース接続の詳細」ページが表示されます(図42-3を参照)。
「データベース・タイプ」を選択し、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」および「パスワード」に入力して、スキーマを追加するデータベースの接続詳細を指定したら、「次へ」をクリックします。
「前提条件」ポップアップが表示されたら、「OK」をクリックします。
「コンポーネントの選択」ページが表示されます(図42-4を参照)。
「接頭辞の新規作成」を選択して、スキーマ名に付加する接頭辞を入力します。
「AS共通スキーマ」の下の「Metadata Services」コンポーネントを選択します。他のコンポーネントが選択されていないことを確認してください。
「次へ」をクリックし、「前提条件」ポップアップが表示されたら、「OK」をクリックします。
「スキーマ・パスワード」ページが表示されます。
スキーマ・パスワードの適用方法を選択し、パスワードを入力して確認します。
「次へ」をクリックします。
「表領域のマップ」ページで、「次へ」をクリックします。
表領域作成のプロンプトが表示されたら、「OK」をクリックし、操作が完了したら再度「OK」をクリックします。
「サマリー」ページで「作成」をクリックして、スキーマを作成します。
「完了サマリー」ページでスキーマの作成が正常に完了したことが確認できたら、「閉じる」をクリックします。
アプリケーションをデプロイする前に、ドメインに新しいMDSスキーマを登録して、管理対象サーバーで実行しているアプリケーションがアクセスできるようにする必要があります。
Fusion Middleware Controlを使用してMDSリポジトリを登録する手順は、次のとおりです。
Fusion Middleware Controlを開き、ターゲット・ドメインにログインします。
Fusion Middleware Controlへのログインの詳細は、第6項「Enterprise Manager Fusion Middleware Controlの起動」を参照してください。
「ナビゲーション・ペイン」で、「ファーム」を開き、次に「WebLogicドメイン」を開きます。
デプロイ先のドメインを選択します。
「WebLogicドメイン」メニューから「メタデータ・リポジトリ」を選択します。
「メタデータ・リポジトリ」ページが表示されます(図42-5を参照)。
「データベース・ベース・リポジトリ」セクションで、「登録」をクリックします。
「データベース・ベースのメタデータ・リポジトリの登録」ページが表示されます(図42-6を参照)。
「データベース接続」セクションで、次の情報を入力します。
データベース: データベースのタイプを選択します。
ホスト名: ホストの名前を入力します。
ポート: データベースのポート番号を入力します(例: 1521)。
サービス名: データベースのサービス名を入力します。データベースのデフォルトのサービス名は、orclなどのデータベース名、およびexample.comなどのドメイン名で構成されるグローバル・データベース名です。この場合、orcl.example.comがサービス名になります。
ユーザー名: SYSDBAロールが割り当てられた、データベースのユーザー名を入力します(例: SYS)。
パスワード: ユーザーのパスワードを入力します。
ロール: データベースのロールを選択します(例: SYSDBA)。
「問合せ」をクリックします。
データベースで使用可能なスキーマおよびそれらのメタデータ・リポジトリのリストがある表が表示されます。
リポジトリを選択し、次の情報を入力します。
リポジトリ名: MDSスキーマの名前を入力します。
スキーマ・パスワード: スキーマを作成したときに指定したスキーマ・パスワードを入力します。
「OK」をクリックします。
リポジトリが、Oracle WebLogic Serverドメインに登録されます。
データベース・ベースのMDSリポジトリは、WLSTを使用して、コマンド行からregisterMetadataDBRepositoryコマンドを実行することによっても登録できます。
WLSTを使用してMDSスキーマを登録する手順は、次のとおりです。
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」の説明に従って、WLSTを起動します。
次のコマンドを使用して、MDSスキーマを登録します。
registerMetadataDBRepository(name='mds_name', dbVendor='db_vendor', host='host_name', port='port_number', dbName='db_name', user='username', password='password', targetServers='target_server')
ここで:
mds_nameは、登録するMDSスキーマの名前です。
db_vendorは、使用されるデータベースのベンダーです。
host_nameは、データベース・サーバーの完全修飾サーバー名です。
port_numberは、データベース・サーバーのポート番号です。
db_nameは、MDSの格納に使用されるデータベースの名前です。
usernameは、データベース・スキーマのユーザー名です。
passwordは、データベース・スキーマのパスワードです。
target_serverは、ターゲット・サーバーの名前です。複数のターゲットの場合、ターゲット・サーバーの名前をカンマで区切ってください。必ずターゲットのリストにWLS管理サーバーを含めて、アプリケーションをデプロイするときにMDSデータベース・リポジトリ名が「デプロイ・プラン」ダイアログに表示されるようにします。
たとえば、example.comというホスト名のターゲット・サーバーserver1上のOracleデータベースorclにMDSスキーマmds1を登録するには、次のコマンドを実行してください。
registerMetadataDBRepository(name='mds1', dbVendor='ORACLE', host='example.com', port='1521',dbName='orc1', user='username', password='password', targetServers='server1','AdminServer')
表42-2に、様々なアプリケーションのデプロイ先の管理対象サーバーをリストします。
JDeveloperで作成されたPortal Frameworkアプリケーションの場合、デプロイする前に、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の既存ドメインの拡張に関する項の説明に従って、新しいOracle WebCenter Portal Custom Portalサーバー、あるいはポートレット化されている場合はOracle WebCenter Portal Custom Services Producerサーバーを作成してプロビジョニングします。
表42-2 デプロイ・ターゲット
| アプリケーション・タイプ | 管理対象サーバー名 |
|---|---|
|
Portal Frameworkアプリケーション |
|
|
WebCenter Portal Portlet Producerアプリケーション |
|
|
WebCenter Portal Portlet Producerアプリケーション以外 |
ポートレット・プロデューサ・アプリケーションの場合、管理対象サーバー・インスタンスを作成するか、 |
|
注意: インストール中に作成した事前構成済管理対象サーバーのいずれかや管理サーバーにPortal Frameworkアプリケーションをデプロイすることはお薦めしません。 |
Portal Frameworkアプリケーションをデプロイできる方法は複数あります。それらの方法について次の項で説明します。
第42.1.3項「アプリケーションEARファイルの準備」で説明したように、パッケージ化されたEARファイルは、アプリケーション・バイナリ、アプリケーション構成、アプリケーション・メタデータおよびポートレット・カスタマイズを含めて、複数の情報アーティファクトで構成されます。
デプロイメント中に、これらの情報アーティファクトは、アプリケーションがデプロイされるインスタンスで正しい情報ストアに移動される必要があります。これらのアーティファクトのターゲット情報ストアを表42-3に示します。
表42-3 情報アーティファクトのターゲット・ストア
| 情報アーティファクト | ターゲット情報ストア |
|---|---|
|
アプリケーション・バイナリ |
ターゲット・サーバー・インスタンス |
|
アプリケーション構成 |
MDS |
|
アプリケーション・メタデータ |
MDS |
|
ポートレット・カスタマイズ |
ターゲット・プロデューサ |
デプロイ用に選択したツールにかかわらず、正しくデプロイするには、ターゲット情報ストアの場所を指定する必要があります。アプリケーションのデプロイは、MDSの場所が間違っていたり指定されないと失敗します。ただし、ターゲット・プロデューサが間違って指定されていてもアプリケーションはデプロイされます。ターゲット・プロデューサを間違って指定したら、ポートレットは自動的にはインポートされないため使用できません。その場合、次のいずれかを実行してください。
Fusion Middleware Control (第21.2.1項「Fusion Middleware Controlを使用したWSRPプロデューサの登録」および第21.4.1項「Fusion Middleware Controlを使用したOracle PDK-Javaプロデューサの登録」を参照)、またはWLSTコマンド(第21.2.2項「WLSTを使用したWSRPプロデューサの登録」または第21.4.2項「WLSTを使用したOracle PDK-Javaプロデューサの登録」を参照)を使用して、デプロイ後のポートレット・プロデューサ接続を編集し、アプリケーションを再デプロイします。
WLSTコマンドを使用して、ポートレット・カスタマイズをエクスポートおよびインポートします(第44.1項「データ移行のためのFrameworkアプリケーションのエクスポートおよびインポート」を参照)。
|
注意: アプリケーションのデプロイ時に、すでに存在するターゲット・プロデューサが間違って指定された場合、間違ったプロデューサにポートレットはインポートされるため、それらのポートレットは使用できません。 |
データ・ソースには次の3つの基本オプションがあります。
すでに存在するデータ・ソースを使用して、Oracle WebCenter Portalのカスタム・ポータル管理対象サーバーにデプロイします
WebCenterDSやActivitiesDSの名前でないグローバル・データ・ソースを使用して、管理対象サーバーにデプロイします
ローカル・アプリケーション・コンテキストの任意の名前のデータ・ソースを使用して、管理対象サーバーにデプロイします
この項では、これらのオプションのメリットとデメリットについて説明します。
すでに存在するデータ・ソースを使用して、Oracle WebCenter Portalのカスタム・ポータル管理対象サーバーにデプロイします
このオプションは、必要なデータ・ソースにアクセスするためのPortal Frameworkアプリケーションの有効化を最も簡単にでき、推奨デプロイメント・パスです。
すでに存在するデータ・ソースを使用してデプロイするには、JDeveloperの「アプリケーション・プロパティ・デプロイメント」画面で、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」チェック・ボックスの選択を解除してください。
アプリケーションに、WebCenterDSまたはActivitiesDS (あるいはその両方)用に構成された既存データベース接続があり、それらの名前がそれぞれwebcenter/CustomPortalおよびactivities/CustomPortalではない場合、デプロイ前にデータベース接続をアプリケーションから削除するか、データベース接続を作成して命名規則に沿って名前を付ける必要があります。
WebCenterDSやActivitiesDSの名前でないグローバル・データ・ソースを使用して、管理対象サーバーにデプロイします
Oracle WebCenter Custom Portalテンプレートを使用して作成された管理対象サーバーでアプリケーションを実行しない場合、あるいはWebCenterDSまたはActivitiesDS以外の名前のカスタム・データ・ソースに対してアプリケーションを実行する場合、このデプロイメント・パスを使用します。
このオプションの場合、Portal Frameworkアプリケーションにデータベース接続があり、WEBCENTERまたはACTIVITIESのスキーマと関連付けられている必要があります。JDeveloperの「アプリケーション・プロパティ・デプロイメント」画面の「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」チェック・ボックスの選択は解除してください。WLSサーバーでグローバル・データ・ソースを使用する場合、JDeveloperプロジェクトでアプリケーション用に作成されたデータベース接続の名前に一致するJNDI名で作成されている必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のJDBCデータ・ソースの作成に関する項を参照してください。
ローカル・アプリケーション・コンテキストの任意の名前のデータ・ソースを使用して、管理対象サーバーにデプロイします
ローカル・アプリケーション・コンテキストのデータ・ソースで十分な場合、このデプロイメント・パスを使用してください。
このオプションを使用するには、WebCenterDSまたはActivitiesDS(あるいはその両方)用にデータベース接続がPortal Frameworkアプリケーションに作成されており関連付けられている必要があります。どのデータ・ソースかは、アプリケーションで使用されているツールおよびサービスに依存します。JDeveloperの「アプリケーション・プロパティ・デプロイメント」画面では、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」チェック・ボックスを選択してください。
WebLogic Serverにアクセスするために必要な資格証明があれば、Oracle JDeveloperを使用して、Portal Frameworkアプリケーションを開発環境からWebLogic Serverインスタンスに直接デプロイできます。詳細は、『Oracle Fusion Middleware Oracle WebCenter PortalおよびOracle Jdeveloperでのポータルの開発』のWebLogic管理対象サーバー接続の作成に関する項および管理対象サーバーへのPortal Frameworkアプリケーションのデプロイに関する項を参照してください。
Fusion Middleware Controlを使用してPortal Frameworkアプリケーションをデプロイするには、アプリケーション・アーカイブの場所と、アプリケーションのデプロイ・プランが存在するかどうかを確認する必要があります。デプロイ・プランの詳細は、第42.1.6.7項「デプロイ・プランの保存と再利用」を参照してください。
|
注意: デプロイするときに指定したメタデータ・リポジトリおよびADF接続の詳細は、デプロイ・プランの一部として格納されません。これらのデプロイ・プロパティは、アプリケーションをデプロイするたびに指定する必要があります。 更新する予定があり、アプリケーションを頻繁にデプロイするためにこれらの構成変更を保存する場合、WLSTまたはFusion Middleware Controlを使用して、デプロイ後にこれらの構成変更を行うことをお薦めします。こうした構成変更は、デプロイ・プランに保存されてMDSリポジトリに保持されるため、アプリケーションを再デプロイするときに再設定する必要はありません。 |
Fusion Middleware Controlを使用してPortal Frameworkアプリケーションをデプロイする手順は、次のとおりです。
Fusion Middleware Controlにログインします。
第6.1項「Fusion Middleware Controlコンソールの表示」を参照してください。
ナビゲーション・ペインで「WebLogicドメイン」を開き、ターゲットの管理対象サーバーが作成されたドメインをクリックします。
「WebLogicドメイン」メニューから、「アプリケーション・デプロイメント」→「デプロイ」を選択します。
「アーカイブの選択」ページが表示されます(図42-7を参照)。
「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを実行します。
「アーカイブはこのWebブラウザが稼働しているマシンに存在します。」を選択して、アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを探します。
「アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。」を選択して、アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを探します。
「デプロイ・プラン」セクションで、次のいずれかを実行します。
「デプロイ構成が行われるとき、新規デプロイ・プランを作成します。」を選択し、再デプロイ処理の後に、新しいデプロイ・プランを自動的に作成します。
「デプロイ・プランはこのWebブラウザが稼働しているマシンに存在します。」を選択して、プランへのパスを入力するか、「参照」をクリックしてプランを探します。
「デプロイ・プランはEnterprise Managerが稼働しているサーバーに存在します。」を選択して、プランへのパスを入力するか、「参照」をクリックしてプランを探します。
「次へ」をクリックします。
「ターゲットの選択」ページが表示されます(図42-8を参照)。
アプリケーションをデプロイするターゲット・サーバーを選択し、「次へ」をクリックします。
「アプリケーション属性」ページが表示されます(図42-9を参照)。
「ターゲット・メタデータ・リポジトリ」で、「メタデータ・リポジトリ」ウィンドウを表示するためのアイコンをクリックします。図42-10に示すように、このウィンドウからアプリケーションのリポジトリを選択できます。「リポジトリ」ドロップダウン・リストを使用して必要なリポジトリを選択し、「OK」をクリックします。
|
注意: 「ターゲット・メタデータ・リポジトリ」オプションは、MDSリポジトリにインポートされるメタデータがアプリケーションに含まれている場合にのみ表示されます。このオプションは、ポートレット・プロデューサ・アプリケーションの場合は表示されません。 |
リポジトリで使用するパーティションの名前を入力します(通常はアプリケーションの名前)。各アプリケーションには、リポジトリで一意のパーティションが設定されている必要があります。
「次へ」をクリックします。
「デプロイ設定」ページが表示されます(図42-11を参照)。
これで、ターゲットMDSの場所の指定は完了です(第42.1.6項「WebLogic管理対象サーバーへのアプリケーションのデプロイ」を参照)。
「ADF接続の構成」の「編集」アイコンをクリックして、Portal Frameworkアプリケーションに関連付けられた接続設定をチェックします。
「ADF接続の構成」ページが表示されます(図42-12を参照)。
接続ごとに「編集」アイコンをクリックして、接続設定がターゲット環境に対して正しいことを確認します(本番やステージングなど)。
たとえば、ディスカッション・フォーラム接続の場合(図42-13を参照)、ディスカッション・サーバーへのURL、およびサーバーとの接続に使用されるユーザー・アカウントが、ターゲット環境に対して正しいことを確認してください。
WSRPプロデューサの場合、WSRPプロデューサ接続およびWebサービス接続がプロデューサごとに表示されます。通常、Webサービス接続のみターゲット・プロデューサに合せて変更する必要があります。これには4つのURLエンドポイントが含まれていますが、これらをすべて変更する必要があります。WSRPプロデューサ接続では、アプリケーション・サーバー用に、デフォルトのプロキシ設定とは個別に設定できるプロキシ設定のみ必要に応じて構成します。
EARファイルのポートレット・プロデューサへの接続を、ターゲット・デプロイ環境のプロデューサを指すように変更する必要がある場合、必ずここで変更してください。これで、アプリケーションが起動したときに、ポートレット・カスタマイズがターゲット・プロデューサにインポートされます。詳細は、第42.1.6項「WebLogic管理対象サーバーへのアプリケーションのデプロイ」を参照してください。
|
注意: アプリケーションが初めて起動したときに、接続できるターゲット・プロデューサがなかった場合、インポートは失敗します。ポートレット・プロデューサに接続できるようになったら、アプリケーションを再起動してインポートを再実行してください。 「ADF接続の構成」ページを使用してプロデューサ接続を修正しないまま間違ったプロデューサの場所(例: 開発環境のプロデューサ)を指しており、そのプロデューサが接続可能な場合、ポートレットは間違ったプロデューサにインポートされます。 デプロイ後にこれを修正するには、Fusion Middleware Control (第21.2.1項「Fusion Middleware Controlを使用したWSRPプロデューサの登録」および第21.4.1項「Fusion Middleware Controlを使用したOracle PDK-Javaプロデューサの登録」を参照)、またはWLSTコマンド(第21.2.2項「WLSTを使用したWSRPプロデューサの登録」または第21.4.2項「WLSTを使用したOracle PDK-Javaプロデューサの登録」を参照)を使用してプロデューサのURLエンドポイントを編集してから、アプリケーションを再デプロイしてください(第42.3.2項「Fusion Middleware Controlを使用したPortal Frameworkアプリケーションの再デプロイ」を参照)。 |
必要に応じて、Webモジュールなどの追加デプロイ・オプションを指定して、アプリケーションやセキュリティ移行設定に含めます。
オプションで、「デプロイ・プラン」セクションの「デプロイ・プランの編集」をクリックし、現在選択しているデプロイ・プランを編集します。
オプションで、「デプロイ・プラン」セクションの「デプロイ・プランの保存」をクリックし、アプリケーションを再デプロイするときに再利用できるように、現在選択しているデプロイ・プランを保存します。
デプロイ・プロセスを開始するには、「デプロイ」をクリックします。
Fusion Middleware Controlに処理メッセージが表示されます。
「正常にデプロイされました」ページで「閉じる」をクリックします。
これで、Portal Frameworkアプリケーション(およびそのデプロイ・プラン)が、WebLogic管理対象サーバー・インスタンスでデプロイされました。
Fusion Middleware Controlセッション中にアプリケーションをデプロイしたWebLogic管理対象サーバーを再起動する場合、「ファーム」メニューから「ファーム」をリフレッシュして、アプリケーションのステータスを更新します。
|
注意: デプロイ時に接続を構成した場合、それらはデプロイ・プランの一部として格納されません。次回デプロイするときは、これらの接続詳細を再度指定する必要があります。 |
WLSTコマンド行を使用してPortal Frameworkアプリケーションをデプロイするには、WLSTが管理サーバーと接続している必要があります。管理サーバーをホストしているコンピュータで、deployコマンドを起動する必要があります。
WLSTを使用してPortal Frameworkアプリケーションをデプロイする手順は、次のとおりです。
WLSTシェルを起動します。
WLSTシェルの起動の詳細は、第1.13.3項「Oracle WebLogic Scripting Tool (WLST)」を参照してください。
Oracle WebCenter Portalインストールの管理サーバーに接続します。
connect("user_name","password","host_name:port")
ここで:
user_nameは、管理サーバーにアクセスするユーザーの名前です(例: weblogic)。
passwordは、管理サーバーにアクセスするためのパスワードです(例: weblogic)。
host_nameは、管理サーバーのホスト名です(例: myserver.example.com)。
portは、管理サーバーのポート番号です(デフォルトは7001)。
次のメッセージが表示されます。
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
次のコマンドを実行して、MDS構成を取得します。
archive = getMDSArchiveConfig(fromLocation='ear_file_path')
ear_file_pathは、デプロイするEARファイルのパスとファイル名です(例: /tmp/myEarFile.ear)。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のgetMDSArchiveConfigコマンドに関する項を参照してください。
MDS構成情報をEARファイルから取得した後、Oracle WebCenter Portalの設定に応じて、適切なMDSスキーマ情報を設定する必要があります(たとえば、アプリケーションは、特定のスキーマに基づいたデータベース接続を使用している場合があります)。MDSスキーマ情報を設定するには、次のコマンドを実行してください。
archive.setAppMetadataRepository(repository='respository',partition='partition',type='DB',jndi='jndi')
ここで:
repositoryは、データベース・スキーマの名前です(例: mds-Feb23demo)。
partitionは、リポジトリ内の個々のエンティティです。これによって、各アプリケーションが独自のネームスペースを持つことができます(例: webcenter)。
jndiは、アプリケーション・サーバーの他のコンポーネントによるアクセスを可能にするために使用するパスおよび名前です(例: jdbc/mds/Feb23demo)。
MDSリポジトリ情報を設定した後、次のコマンドを使用してMDS構成情報を保存します。
archive.save()
WLSTのdeployコマンドを使用して、Portal Frameworkアプリケーションをデプロイします。
deploy(app_name, path, [targets] [stageMode], [planPath], [options])
ここで:
appNameは、デプロイするPortal Frameworkアプリケーションの名前です(例: コンポーザWLSTApp)。
pathは、デプロイするEARファイルへのパスです(例: /tmp/customApp.ear)。
targetsには、アプリケーションのデプロイ先管理対象サーバーを指定します(例: CustomAppServer)。オプションで、カンマで区切れば複数のターゲットを指定できます。異なるサーバー上にアプリケーション・アーカイブの異なるモジュールをデプロイできるようにするには、たとえばmodule1@server1のように、各ターゲットをモジュール名で修飾します。この引数は、WLSTが現在接続されているサーバーにデフォルト設定されます。
[stageMode]には、オプションで、デプロイするアプリケーションのステージング・モードを定義します。有効な値は、stage、nostageおよびexternal_stageです。
[planPath]には、オプションで、デプロイ・プラン・ファイルの名前を定義します。ファイル名は、絶対名にすることも、アプリケーション・ディレクトリに対する相対名にすることもできます。この引数は、アプリケーション・ディレクトリ内のplan/plan.xmlファイル(存在する場合)にデフォルト設定されます。
[options]は、オプションで、名前と値のペアとして指定したデプロイメント・オプションのカンマ区切りリストです。有効なオプションの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTのdeployコマンドに関する項を参照してください。
次のメッセージが表示されたら、アプリケーションが正常にデプロイされて、アクセスの準備ができたことを意味します。
Completed the deployment of Application with status completed
|
注意: WLSTはデプロイ時に接続変更のプロンプトを表示しないため、EARファイルの接続情報を使用して、前回の起動時のターゲット・プロデューサの場所を特定します。その場所に到達できない場合、ターゲット・プロデューサの起動およびアプリケーションの再起動を行ってアプリケーションをデプロイした後に、場所を修正してください。ポートレット・カスタマイズの移行は自動的に開始されます。 プロデューサ接続が、接続可能な間違ったプロデューサを指している場合(たとえば、開発プロデューサ)、ポートレット・カスタマイズの移行はそれらのプロデューサを使用して開始されます。間違っていても移行は完了しているため、アプリケーションを再起動しても移行処理は自動的には起動されません。 デプロイ後にこれを修正するには、Fusion Middleware Control (第21.2.1項「Fusion Middleware Controlを使用したWSRPプロデューサの登録」および第21.4.1項「Fusion Middleware Controlを使用したOracle PDK-Javaプロデューサの登録」を参照)、またはWLSTコマンド(第21.2.2項「WLSTを使用したWSRPプロデューサの登録」または第21.4.2項「WLSTを使用したOracle PDK-Javaプロデューサの登録」を参照)を使用してプロデューサのURLエンドポイントを編集してから、アプリケーションを再デプロイしてください(第42.3.2項「Fusion Middleware Controlを使用したPortal Frameworkアプリケーションの再デプロイ」を参照)。 |
WLS管理コンソールを使用すると、Portal Frameworkアプリケーションまたはポートレット・プロデューサ・アプリケーションをデプロイできます。しかし、コンソールでは、基本的なMDS接続も含め、ADF接続を変更できません。このコンソールを使用してPortal Frameworkアプリケーションをデプロイするには、EARファイルのMDS接続をターゲット・デプロイメント・リポジトリに合せて構成する必要があります。第42.1.6.5項「WLSTを使用したアプリケーションのデプロイ」の手順1-5を実行したら、次の手順を実行して、WLS管理コンソールからPortal Frameworkアプリケーションまたはポートレット・プロデューサ・アプリケーションをデプロイしてください。
|
注意: インストール中に作成した事前構成済管理対象サーバーのいずれかや管理サーバーにPortal Frameworkアプリケーションをデプロイすることはお薦めしません。JDeveloperで作成されたPortal Frameworkアプリケーションの場合、デプロイする前に新しい管理対象サーバーを作成してプロビジョニングするには、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の既存ドメインの拡張に関する項の手順を実行してください。ポートレット・プロデューサ・アプリケーションの場合、管理対象サーバー・インスタンスを作成するか、オプションで |
WLS管理コンソールを使用してPortal Frameworkアプリケーションまたはポートレット・プロデューサ・アプリケーションをデプロイする手順は、次のとおりです。
WLS管理コンソールにログインします。
WLS管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「デプロイメント」をクリックします。
「デプロイメントのサマリー」ページが表示されます(図42-14を参照)。
「デプロイメント・サマリー」ペインで、「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページが表示されます(図42-15を参照)。
「アプリケーション・インストール・アシスタント」の「パス」フィールドを使用して、インストールするWebアプリケーションまたはポートレット・プロデューサ・アプリケーションに対応するEARファイルを検索します。EARファイルを選択して、「次へ」をクリックします。
「アプリケーション・インストール・アシスタント」ページの2ページ目が表示されます(図42-16を参照)。
「このデプロイメントをアプリケーションとしてインストールする」(Portal Frameworkアプリケーションとポートレット・プロデューサの両方用)を選択して、「次へ」をクリックします。
「アプリケーション・インストール・アシスタント」の3ページ目が表示されます(図42-17を参照)。
Webアプリケーションのデプロイ先デプロイ・ターゲットを選択し、「次へ」をクリックします。
指定した構成設定を確認し、「終了」をクリックしてインストールを完了します。
デプロイ後にプロデューサのURLを変更するには、Fusion Middleware Control (第21.2.1項「Fusion Middleware Controlを使用したWSRPプロデューサの登録」および第21.4.1項「Fusion Middleware Controlを使用したOracle PDK-Javaプロデューサの登録」を参照)、またはWLSTコマンド(第21.2.2項「WLSTを使用したWSRPプロデューサの登録」または第21.4.2項「WLSTを使用したOracle PDK-Javaプロデューサの登録」を参照)を使用してプロデューサのURLエンドポイントを編集してから、アプリケーションを再デプロイしてください(第42.3.2項「Fusion Middleware Controlを使用したPortal Frameworkアプリケーションの再デプロイ」を参照)。
デプロイメント・プランには、アーカイブを管理対象サーバーにデプロイするために必要な構成データが含まれています。アプリケーションの構築およびテスト時、または第42.1.6.4項「Fusion Middleware Controlを使用したアプリケーションのデプロイ」の説明に従い、Fusion Middleware Controlを使用してEARファイルをデプロイする際に、デプロイメント・プランを作成できます。EARファイル内にパッケージ化されたデプロイメント・ディスクリプタが存在する場合は、デプロイメントでこれらのファイル内のデータが使用されます。web.xmlファイルに変更を加える必要がある場合は、デプロイメント・プランを作成することをお薦めします。
作成したら、デプロイ・プランを、アプリケーション・プロパティの一部としてターゲットの管理対象サーバーに保存しておけば、アプリケーションを再デプロイするときに再利用できます。再デプロイは、第42.3.2項「Fusion Middleware Controlを使用したPortal Frameworkアプリケーションの再デプロイ」の説明に従ってFusion Middleware Controlを使用するか、第42.3.3項「WLSTを使用したPortal Frameworkアプリケーションの再デプロイ」の説明に従ってWLSTを使用して行います。
デプロイされたアプリケーションのページ、ツールとサービス、およびポートレット(PDK-JavaおよびWSRPバージョン2のプロデューサ)に対して行われたカスタマイズは、エクスポートおよびインポートできます。詳細は、第44章「データ移行のためのPortal Frameworkアプリケーションのエクスポートおよびインポート」を参照してください。
分散環境で実行するためのPortal Frameworkアプリケーションの構成の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド』、および『Oracle Fusion Middleware高可用性ガイド』の「Oracle ADFおよびOracle WebCenter Portalのための高可用性の構成」を参照してください。
この項では、Fusion Middleware Controlを使用するか、WLSTを使用したコマンド行から、Portal Frameworkアプリケーションまたはポートレット・プロデューサ・アプリケーションをアンデプロイする方法について説明します。
|
注意: Portal Frameworkアプリケーションをアンデプロイしても、アプリケーションを同じドメインに再デプロイするときのために、そのアプリケーションの資格証明およびMDSカスタマイズは保持されます。アプリケーションをこのドメインに再デプロイしない場合、または次のデプロイまでに初期状態にリセットする必要がある場合は、第42.2.3項「アプリケーションの資格証明マップの削除」で説明されているように、アプリケーションをアンデプロイした後に、資格証明ストアからアプリケーションの資格証明マップを削除できます。また、『Oracle Fusion Middleware管理者ガイド』のリポジトリからのメタデータ・パーティションの削除に関する項で説明されているように、MDSリポジトリ・パーティションも削除できます。 |
この項には次のサブセクションが含まれます:
この項では、Fusion Middleware Controlを使用してPortal Frameworkアプリケーションをアンデプロイする方法について説明します。
Fusion Middleware Controlを使用してPortal Frameworkアプリケーションをアンデプロイする手順は、次のとおりです。
Fusion Middleware Controlにログインします。
第6.1項「Fusion Middleware Controlコンソールの表示」を参照してください。
ナビゲーション・ペインで「アプリケーション・デプロイメント」を開き、アンデプロイするアプリケーションをクリックします。
「アプリケーション・デプロイメント」メニューから、「アプリケーション・デプロイメント」→「アンデプロイ」を選択します。
確認ページで「アンデプロイ」をクリックします。
操作が完了したら、「閉じる」をクリックします。
この項では、WLSTを使用してPortal Frameworkアプリケーションをアンデプロイする方法について説明します。
WLSTを使用してPortal Frameworkアプリケーションをアンデプロイする手順は、次のとおりです。
WLSTシェルを起動します。
WLSTシェルの起動の詳細は、第1.13.3項「Oracle WebLogic Scripting Tool (WLST)」を参照してください。
WebCenter Portalインストールの管理サーバーに接続します。
connect("user_name","password","host_name:port")
ここで:
user_nameは、管理サーバーにアクセスするユーザーの名前です(例: weblogic)。
passwordは、管理サーバーにアクセスするためのパスワードです(例: weblogic)。
host_nameは、管理サーバーのホスト名です(例: myserver.example.com)。
portは、管理サーバーのポート番号です(デフォルトは7001)。
次のメッセージが表示されます。
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
undeployコマンドを使用して、アプリケーションをアンデプロイします。
undeploy(app_name,[targets],[options])
ここで:
app_nameは、デプロイされたアプリケーションのデプロイ名です。
[targets]は、アプリケーションが削除されるターゲット・サーバーのリストです。オプション。これを指定しない場合は、現在のすべてのターゲットにデフォルト値が設定されます。
[options]は、名前と値のペアとして指定したデプロイメント・オプションのカンマ区切りリストです。オプション。オプションの完全なリストは、deployコマンドを参照してください。
Portal Frameworkアプリケーションをアンデプロイしても、そのアプリケーションの資格証明は削除されません。そのため、アンデプロイ後に、Fusion Middleware Controlを使用して、アプリケーションで使用された資格証明マップを手動で削除する必要があります。
Fusion Middleware Controlを使用してアプリケーションの資格証明マップを削除するには:
アプリケーションのadf-config.xmlのコンテンツを参照し、adfAppUIDの値を確認して、そのアプリケーションによって使用された資格証明マップ名を特定します。例:
<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="adfAppUID" value="Veeva-7209"/>
</adf:adf-properties-child>
この場合、アプリケーションによって使用された資格証明マップ名は、Veeva-7209です。
Fusion Middleware Controlにログインします。
Fusion Middleware Controlへのログインの詳細は、第6項「Enterprise Manager Fusion Middleware Controlの起動」を参照してください。
ナビゲーション・ペインで、「WebLogicドメイン」ノードを開き、ターゲット・ドメイン(wc_domainなど)を選択します。
「WebLogicドメイン」ドロップダウン・メニューの「セキュリティ」→「資格証明」を選択します。
「資格証明」ペインが表示されます(図42-18を参照)。
資格証明マップを選択し、「削除」をクリックします。
「はい」をクリックして資格証明マップの削除を確定します。
この項では、Fusion Middleware Controlを使用するか、WLSTを使用したコマンド行から、Portal Frameworkアプリケーションを再デプロイする方法について説明します。新しいバージョンのアプリケーションを再デプロイすると、次を変更できません。
アプリケーションのデプロイ・ターゲット
アプリケーションのセキュリティ・モデル
デプロイ・ターゲットまたはアプリケーションのセキュリティ設定を変更するには、アクティブなバージョンのアプリケーションを最初にアンデプロイする必要があります。アプリケーションをアンデプロイする方法の詳細は、第42.2項「Portal Frameworkアプリケーションのアンデプロイ」を参照してください。
|
注意:
|
この項には次のサブセクションが含まれます:
アプリケーションを再デプロイするとき、アプリケーション・データへの変更は保持しようと考える場合がほとんどです。デプロイ後の実行時に、アプリケーションに関する3つの重要な情報が変更することがあります。
アプリケーション構成: 接続情報が含まれます。
アプリケーション・メタデータ: アプリケーション自体に対するカスタマイズおよびパーソナライズが含まれます。これらは、ユーザーがページを編集してコンテンツを追加するなどしたときに作成されます。
ポートレット・プリファレンス: ポートレット・インスタンスのカスタマイズおよびパーソナライズが含まれます。
|
注意: ページ、接続またはタスク・フローなどのアーティファクトに大規模な変更が加えられた更新アプリケーションを再デプロイする前に、ランタイム・カスタマイズ(JDeveloperを使用しないカスタマイズ)を削除する必要があります。 |
次の項では、アプリケーションに関するこれら3種類の情報を保持する方法について説明します。
|
注意: アプリケーション情報を保持するには、初期デプロイを使用して作成または使用された同じMDSパーティションを使用して再デプロイする必要があります。 |
ほとんどの場合、ツールとサービスのエンドポイントおよびポートレット・プロデューサは、本番環境よりもテスト環境またはステージング環境で異なります。そのため、アプリケーションを本番環境に再デプロイするとき、アプリケーションを再構成して、本番環境のサービスおよびプロデューサで稼働できるようにするか、以前使用された構成を再利用できるようにする必要があります。Fusion Middlewareは、MDSリポジトリに構成情報を格納することによってこれを容易にします。
アプリケーションを初めてデプロイしたとき、アプリケーション構成のベース・ドキュメントがMDSリポジトリに作成されます。この構成は、EARファイルにパッケージ化されている、アプリケーションの接続およびそれらのプロパティのすべてが含まれたセットです。デプロイ後は、本番環境の仕様に合せて、Fusion Middleware ControlまたはWLSTを使用して接続を編集する必要がある場合があります。この再構成によって、構成変更のためのカスタマイズのレイヤーがMDSリポジトリに作成されます。
アプリケーションを再デプロイすると、アプリケーションでパッケージ化された構成がベース・ドキュメントとして使用されますが、構成へのカスタマイズは保持されます。したがって、アプリケーションの再デプロイ設定は最新の構成と一致します。
ただし、カスタマイズが完全に保持されるのは、ベース・ドキュメントに変更がない場合のみです。パッケージ化された接続情報が変更されたアプリケーションを再デプロイすると、次の結果が予想されます。
パッケージ化された構成に新しい接続が追加されます。
新しい接続は問題なく表示されます。
パッケージ化された構成から接続が削除されます。
前回のデプロイ後にこの接続を構成した場合、デプロイ後にこの接続は表示されないため再作成する必要があります。
パッケージ化された構成で接続プロパティが変更されます。
カスタマイズされたプロパティが使用されます。接続のカスタマイズは、プロパティ・レベルではなく、個々の接続レベルで管理されます。
アプリケーション・メタデータは、デプロイ後の実行時にユーザーが行ったカスタマイズによって変更されます。ほとんどの場合、アプリケーションを再デプロイするとき、以前にユーザーに表示されていた環境を正確に再現できるようにカスタマイズ情報を保持する必要があります。
アプリケーションおよびユーザー・カスタマイズはMDSリポジトリに格納され、構成設定の保持に関するルールがアプリケーション・メタデータの保持にも適用します。
アプリケーションが再デプロイされると、すべてのアプリケーション・アーティファクトのベース・ドキュメントは、EARファイルにパッケージ化されているもので置換されます。ただし、カスタマイズは保持されます。ベース・アーティファクトが変更されないかぎり、この情報への影響はありません。その場合、構成設定と同じルールが適用されます。これらを次に説明します。
新しい要素がパッケージに追加された場合、そのまま表示されます。
作成されたカスタマイズの要素がパッケージから削除された場合、それらのカスタマイズは無視されます。
要素が変更された場合、その影響は変更内容によって異なるため、検証する必要があります。
|
ベスト・プラクティスに関する注意: 状況に応じて、本番アプリケーションのインスタンスにあるすべてのアプリケーションおよびユーザー・カスタマイズをエクスポートして、テストまたはステージングのインスタンスにインポートしてください。その後、それらのカスタマイズに対してアプリケーションをテストすれば、新しい変更によって意図しない影響が発生するかどうかを確認できます。 |
「アセット」ページを使用すれば、ユーザーは実行時に新しいアセットを作成できます。アプリケーションを再デプロイするとき、実行時に作成されたアセットを保持するには、再デプロイ前に、まず実行中のアプリケーションからアセットをダウンロードして、そのアーカイブ・ファイルをデザインタイム環境にインポートする必要があります。
実行時に作成されたアセットのダウンロードとインポートを実行しなかった場合、アプリケーションを再デプロイすると失われます。「アセット」ページではそれらは使用できませんが、失われたアセットを使用し実行時に作成された新しいページは使用できます。これは、新しいアセットが作成されると実行時に更新されるgeneric-site-resources.xmlファイルが、デザインタイム・バージョンのファイルによって、再デプロイ時に上書きされるためです。
ポートレット・カスタマイズは、メタデータでEARファイルにパッケージ化されます。デプロイ後にアプリケーションを起動すると、ターゲット・プロデューサへのポートレット・カスタマイズの移行が開始します。ターゲット・プロデューサは、接続カスタマイズの解決によって特定されます。再デプロイ前にプロデューサ接続を編集した場合、編集された接続がターゲット・プロデューサの特定に使用されます。事前に存在するファイルと同じチェックサム(つまり同じファイル)のEARファイルを再デプロイすると、ポートレット・カスタマイズおよびパーソナライズは上書きされません。
この項では、Fusion Middleware Controlを使用してPortal Frameworkアプリケーションを再デプロイする方法について説明します。
Fusion Middleware Controlを使用してPortal Frameworkアプリケーションを再デプロイする手順は、次のとおりです。
Fusion Middleware Controlにログインします。詳細は、第6.1項「Fusion Middleware Controlの表示」を参照してください。
ナビゲーション・ペインから、ファーム、「WebLogicドメイン」、続いてドメインを開きます。
アプリケーションの再デプロイ先サーバーを選択し、右クリックしてメニューから「アプリケーション・デプロイメント - 再デプロイ」を選択します。
「アプリケーションの選択」ページが表示されます(図42-19を参照)。
再デプロイするアプリケーションを選択します。
「次へ」をクリックし、「アーカイブの選択」ページを表示します(図42-20を参照)。
「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを実行します。
「アーカイブはこのWebブラウザが稼働しているマシンに存在します。」を選択して、アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを探します。
「アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。」を選択して、アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを探します。
「デプロイ・プラン」セクションで、次のいずれかを実行します。
「デプロイ構成が行われるとき、新規デプロイ・プランを作成します。」を選択し、再デプロイ処理の後にデプロイ・プランを自動的に作成します。
「デプロイ・プランはこのWebブラウザが稼働しているマシンに存在します。」を選択して、プランへのパスを入力するか、「参照」をクリックしてプランを探します。
「デプロイ・プランはEnterprise Managerが稼働しているサーバーに存在します。」を選択して、プランへのパスを入力するか、「参照」をクリックしてプランを探します。
「次へ」をクリックします。
「アプリケーション属性」ページが表示されます(図42-21を参照)。
application.xmlにアプリケーションのコンテキスト・ルートを指定しなかった場合、「Webモジュールのコンテキスト・ルート」セクションで指定します。コンテキスト・ルートはWebモジュールのURIです。Webサービスを含む各WebモジュールまたはEJBモジュールには、コンテキスト・ルートが存在する場合があります。
「ターゲット・メタデータ・リポジトリ」セクションで、MDSリポジトリを選択し、「パーティション」に入力します。
|
注意: 最初にアプリケーションをデプロイしたときに使用したリポジトリ接続およびパーティション名を使用してください。そうしなければ、すべてのカスタマイズは失われます。 |
「次へ」をクリックします。
「デプロイ設定」ページが表示されます(図42-22を参照)。
このページでは、アプリケーションをデプロイする前に、接続を構成するなどの共通タスクを実行したり、デプロイ・プランを編集したり、ディスクに保存できます。次を実行できます。
Webモジュールの構成
アプリケーション・ロールおよびポリシー用のアプリケーション・セキュリティを構成します。
ADF接続設定の構成
「ADF接続の構成」の「編集」アイコンをクリックして、Portal Frameworkアプリケーションに関連付けられた接続設定をチェックします。
|
注意: ADF接続の編集は、前回デプロイした後に設定されていない接続に対してのみ必要です。前回デプロイした後に構成された接続は、この手順で指定された設定をオーバーライドします。 |
「ADF接続の構成」ページが表示されます(図42-23を参照)。
接続ごとに「編集」アイコンをクリックして、接続設定がターゲット環境に対して正しいことを確認します(本番やステージングなど)。
たとえば、ディスカッション・フォーラム接続の場合(図42-24を参照)、ディスカッション・サーバーへのURL、およびサーバーとの接続に使用されるユーザー・アカウントが、ターゲット環境に対して正しいことを確認してください。
必要に応じて、Webモジュールなどの追加デプロイ・オプションを指定して、アプリケーションやセキュリティ移行設定に含めます。
「デプロイ・プラン」を開きます。
「デプロイ・プラン」設定が表示されます(図42-25を参照)。
必要に応じて、デプロイ・プランを編集してローカル・ハード・ドライブに保存しておけば、後でアプリケーションを再デプロイするときにこれらの設定を再利用できます。デプロイ・プランの詳細は、第42.1.6.7項「デプロイ・プランの保存と再利用」を参照してください。
「再デプロイ」をクリックします。
再デプロイが完了したら、「閉じる」をクリックします。
|
注意: Fusion Middleware Controlセッション中にアプリケーションをデプロイしたWebLogic管理対象サーバーを再起動する場合、「ファーム」メニューから「ファーム」をリフレッシュして、アプリケーションのステータスを更新します。 |
WLSTコマンド行を使用してPortal Frameworkアプリケーションを再デプロイするには、WLSTが管理サーバーと接続している必要があります。管理サーバーをホストしているコンピュータで、redeployコマンドを起動する必要があります。
WLSTを使用してPortal Frameworkアプリケーションを再デプロイする手順は、次のとおりです。
WLSTシェルを起動します。
WLSTシェルの起動の詳細は、第1.13.3項「Oracle WebLogic Scripting Tool (WLST)」を参照してください。
Oracle WebCenter Portalインストールの管理サーバーに接続します。
connect("user_name","password","host_name:port")
ここで:
user_nameは、管理サーバーにアクセスするユーザーの名前です(例: weblogic)。
passwordは、管理サーバーにアクセスするためのパスワードです(例: weblogic)。
host_nameは、管理サーバーのホスト名です(例: myserver.example.com)。
portは、管理サーバーのポート番号です(デフォルトは7001)。
次のメッセージが表示されます。
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
redeployコマンドを使用して、アプリケーションを再デプロイします。
redeploy(app_name,[planPath],[options])
ここで:
app_nameは、再デプロイするアプリケーションのデプロイ名です。
[planPath]は、デプロイ・プラン・ファイルの名前です。このファイル名は、アプリケーション・ディレクトリの絶対名または相対名のいずれかにできます。オプション。この引数は、アプリケーション・ディレクトリ内のplan/plan.xmlファイル(存在する場合)にデフォルト設定されます。
[options]は、名前と値のペアとして指定したデプロイメント・オプションのカンマ区切りリストです。オプション。オプションの完全なリストは、deployコマンドを参照してください。
Portal Frameworkアプリケーションがデプロイされたら、デプロイされた設定が、ターゲットの管理対象サーバーに対して有効かどうかを確認する必要があります。確認の対象設定は、セキュリティ、接続およびデータ・ソースの設定です。
この項には次のサブセクションが含まれます:
アプリケーションをデプロイする前に、ターゲットの管理対象サーバーで、アイデンティティ・ストア、ポリシーおよび資格情報ストアを設定する必要があります。デプロイ後は、アプリケーション構成がターゲット・サーバーの構成に一致することを確認してください。また、第30.2.5項「デプロイ後のセキュリティ構成タスク」で説明されているように、SSLおよびシングル・サインオンなど、デプロイ後に適用可能な他のすべてのセキュリティ構成が適切に構成されていることも確認してください。
Portal Frameworkアプリケーションをデプロイした後、アプリケーションによって使用されるすべての接続が適切に設定されていることを確認してください。構成または再構成する必要があると考えられる接続は、次のとおりです。
BPELワークリスト
外部アプリケーション
ディスカッション・サーバー
メール・サーバー
インスタント・メッセージおよびプレゼンス(IMP)サーバー
検索
WSRPプロデューサ
PDK-Javaポートレット・プロデューサ
Webサービス
コンテンツ・リポジトリ
個人イベント・サーバー
分析コレクタ
Portal Frameworkアプリケーションをカスタム管理対象サーバーにデプロイした後、テスト時に構成したデータ・ソースが、デプロイしたアプリケーションに対して有効かどうかを確認してください。Portal FrameworkアプリケーションでMetadata Service (MDS)リポジトリ用のデータ・ソースを構成する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の「JDBCデータ・ソースの構成」を参照してください。データ・ソースを設定するとき、パスワードを指定する必要があります。指定しないと、アプリケーションをデプロイするときに接続が作成されない可能性があります。
Portal Frameworkアプリケーションをデプロイして適切に構成した後、第27.5項「Oracle WebCenter Portalのパフォーマンスのチューニング」で説明されているように、システム・ファイルの制限、データ・ソース設定およびJRockit仮想マシン(JVM)の引数を確認してください。また、パフォーマンス問題の診断方法の詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle WebCenter Portalのパフォーマンスのチューニング」、および第27項「Oracle WebCenter Portalのパフォーマンスのモニタリング」も参照してください。
