Developer Toolsを使用したデータの同期および交換の詳細は、次の項を参照してください。
同期はWebCenter Sitesインスタンスとその関連ワークスペース間のリソースの双方向フローです。Developer Toolsを使用して、次の同期操作を実行できます。
組込み依存性解決とIDマッピングを持つアセットをエクスポートおよびインポートします。
フレックス・ファミリやAssetMakerアセット・タイプなどの、アセット・タイプをエクスポートおよびインポートします。
サイト定義、ロール、スタート・メニュー・アイテムおよびツリー・タブをエクスポートおよびインポートします。
SiteCatalogエントリおよびElementCatalogエントリをエクスポートおよびインポートします。
サイトの再マッピングを実行します。たとえば、WebCenter Sites CMサイトにインポート可能な再使用可能なモジュールを作成します(コマンドライン・ツールの操作)
指定されたサイトのすべてのリソースをエクスポートまたはインポートすると、バージョン・コントロール・システムでサイト全体を追跡できます。上級開発者はコマンドライン・ツールを使用して、再使用可能なモジュール(カスタム・ワークスペース)を作成することにより、あるサイトのリソースを別のサイトに再マッピングできます。
シナリオによって、リソースは自動または手動のいずれかで同期されます。
WebCenter Sitesを実行している場合、WebCenter SitesとEclipse間のリソースは、次のアクションがEclipseで実行されるときに自動的に同期されます。
コード・ベースのリソース(テンプレート、CSElement、SiteEntry、ElementCatalogエントリおよびSiteCatalogエントリ)が、EclipseでDeveloper Toolsのウィザードを使用して作成されます。
Developer Toolsワークスペースに格納されたコード・ベースのリソース(テンプレート、CSElementおよびElementCatalogエントリ)が、Eclipseで編集されます。これには、JSPファイル、XMLファイル、メタデータおよびリソースに関連付けられている他のファイルの編集が含まれます。
たとえば、リソースの関連付けられたJSPファイルをEclipseエディタで編集する場合、Developer Toolsキットでは、変更内容がWebCenter Sitesインスタンスに自動的に同期されます。また、上級開発者はEclipseエディタを使用して、フレックス定義のメタデータ・ファイル(.main.xml
)を編集でき、その変更内容はWebCenter Sitesに自動的に同期されます。ただし、フレックス定義を変更するには、Adminインタフェースを使用することをお薦めします。
場合によっては、Eclipse IDEの同期ツールまたはコマンドライン・ツール(上級開発者の場合)のいずれかを使用して、リソースを手動で同期する必要があります。手動同期は次の場合に必要です。
Eclipseエディタは、Developer Toolsワークスペースに格納されているリソースの編集には使用されません。たとえば、リソースが共有ネットワーク・ファイル・システムまたはバージョン・コントロール・システムからDeveloper Toolsワークスペースにコピーされる場合などです。
WebCenter Sitesのリソースが、WebCenter Sitesインタフェースで変更される場合。
注意:
Eclipse IDEは埋込みのAdminインタフェースを提供します。ただし、Eclipseはこのインタフェースを使用して行われる変更を検出しません。したがって、埋込みのAdminインタフェースでの作業は、Adminインタフェースを実行しているスタンドアロン・ブラウザでの作業と同じになります。
WebCenter Sitesは、Eclipse IDEでリソースを作成または編集している間は実行されません。WebCenter Sitesが再起動したら、作成または編集したリソースを手動で同期する必要があります。
リソースの同期にコマンドライン・ツールを使用するのは、サーバーをテストするためにデプロイされるナイトリー・ビルドなど、主にデプロイメントのためです。たとえば、上級開発者は、自動化されたデプロイメント手順用のスクリプトに同期コマンドを埋め込むことができます。コマンドライン・ツールの実行および使用方法の詳細は、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。
WebCenter Sitesのリソースは、多くの場合、他のリソースに依存します。たとえばフレックス・アセットは、そのアセットが作成される前に、関連付けられたフレックス定義が存在している必要があります。また、フレックス定義は属性セットに依存したり、他のリソースに依存する可能性もあります。したがって、すべてのフレックス構造では、システム上にフレックス・ファミリが存在している必要があります。フレックス・アセットを空のWebCenter Sitesシステムにインポートするには、まずフレックス・アセットが関連付けられるフレックス・ファミリを作成する必要があります。その後、次の手順を実行します。
名前、住所および年齢などのフレックス属性を作成します。
フレックス親定義を作成します。
フレックス定義を作成します。
フレックス親を作成します。
フレックス・アセットを作成します。
フレックス・アセットをエクスポートすると、Developer Toolsキットによって、そのアセットのすべての依存性が解決され、その依存性がすべて自動的にエクスポートされます。したがって、リソース(フレックス・アセットなど)を選択するだけで、Developer Toolsキットによって、アセットの依存性がすべて計算されます。
注意:
Developer Toolsキットは、サイト定義上でリソースの依存性を解決しません。これにより、サイト全体またはサイトのサブセットをエクスポートまたはインポートするか、あるいはサイト定義を完全に無視するかどうか(たとえば、コマンドライン・ツールを使用して、任意のサイトにインポートできる再使用可能なモジュールを作成している場合)を選択できます。再使用可能なモジュールの作成の詳細な例は、「Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。
WebCenter Sitesで作成された各リソースには、一意のローカルIDが割り当てられます。リソースのローカルIDは、作成されたWebCenter Sitesインスタンスに対してのみ一意です。リソースの作成には複数のWebCenter Sitesインスタンスが使用されるため、別個のWebCenter Sitesインスタンス上の2つの異なるリソースが同じローカルIDを持つことができます。
この項には次のトピックが含まれます:
リソースを一意に識別するために、Developer Toolsキットは、すべてのWebCenter Sitesインスタンス間で一意のグローバル一意識別子(fw_uid
)を各リソースに割り当てます。さらに、リソースをWebCenter Sitesインスタンスにインポートすると、そのインスタンス上のそのリソースに新しいローカル識別子が割り当てられます。リソースが他のアセット(アソシエーション、アセット・ポインタ、フレックス定義など)を参照している場合は、それらのアセットごとに新しいローカル識別子が生成されます。そのWebCenter Sitesインスタンスに対するそれ以降のインポートでは、同じローカル識別子がリソースに割り当てられます。Developer Toolsキットでは、すべてのWebCenter Sitesインスタンス間でリソースのfw_uid
値が保持されます。リソースとその参照されたアセットが元のWebCenter Sitesインスタンスに再度インポートされると、Developer Toolsキットはローカル識別子をその元の値に再度マッピングします。
注意:
テンプレート・アセット、フレックス属性およびツリー・タブなど、特定のWebCenter Sitesのリソースには、一意の名前の制約があります。名前が競合しないように、各リソースがすべてのWebCenter Sitesインスタンス間で、一意の名前が付けられていることを確認してください。
たとえば、開発者AはCS1という名前のWebCenter Sitesインスタンスを使用し、開発者BはCS2という名前のWebCenter Sitesインスタンスを使用しているとします。両方の開発者は完全に異なるテンプレート・アセットを作成しました。開発者AはテンプレートAを作成し、開発者BはテンプレートBを作成しました。2つのテンプレート・アセットは、fw_uid
値も名前も異なります。ただし、ローカルIDがランダムに割り当てられているため、両方のテンプレート・アセットに、偶然同じローカルID (12345
)が割り当てられています。開発者AとBは、お互いのWebCenter Sitesインスタンス間で、テンプレート・アセットを交換しようと考えています。開発者AはテンプレートBをCS1インスタンスに、開発者BはテンプレートAをCS2インスタンスにインポートしようと考えています。
図32-1は、両方の開発者がWebCenter Sitesインスタンス間でテンプレート・アセットを交換するために行う手順を説明しています。両方のテンプレート・アセットのローカルIDは、別の開発者のWebCenter Sitesインスタンスにインポートされるときに再マップされます。テンプレートAがCS2インスタンスにインポートされるときに、システムによってローカルID 52563
が割り当てられます。テンプレートBがCS1インスタンスにインポートされるときに、システムによってローカルID 22342
が割り当てられます。いずれの場合にも、両方のテンプレート・アセットのfw_uid
値は同じままです。
注意:
この例の開発者は、WebCenter Sitesインスタンス間でのリソース交換にVCSまたは共有ファイル・システムを使用します。VCSの使用方法の詳細は、「Developer Toolのワークスペースとバージョン・コントロール・システムとの統合」を参照してください。
図32-1 同じローカルIDを持つ2つの異なるアセットの2つのWebCenter Sitesインスタンス間での交換
図32-2では、開発者AはテンプレートAをDeployment WebCenter Sitesインスタンス(システム管理者によって管理される)にデプロイしようと考えており、開発者BはテンプレートBを同じインスタンスにデプロイしようと考えています。両方のテンプレート・アセットには、同じローカルID (12345
)があります。
開発者AとBは、各自のテンプレートを、WebCenter Sitesインスタンスの、メインのDeveloper Toolsワークスペースにエクスポートします。その後、各自のテンプレートをVCSまたは共有ファイル・システムにコピーします。ここから、システム管理者は両方のテンプレート・アセットを、Deployment WebCenter Sitesの、メインのDeveloper Toolsワークスペースにコピーします。次にシステム管理者は、2つのテンプレート・アセットを、ワークスペースからDeployment WebCenter Sitesにインポートします。インポート時に、システムによって両方のテンプレートに新しいローカルIDが割り当てられます。テンプレートAにはローカルID 45678
,が割り当てられ、テンプレートBにはローカルID 98765
が割り当てられます。アセットのfw_uid
値は変わりません。
図32-2 同じローカルIDを持つ2つの異なるアセットの、3番目のWebCenter Sitesインスタンスへのデプロイ
リソースがワークスペースにエクスポートされた場合は、fw_uid
によって識別されます。ElementCatalogエントリとSiteCatalogエントリはエレメント名によって一意に識別されているため、fw_uid
は割り当てられません。
リソースが作成されると、グローバルな一意識別子としてUUID値が自動的に生成され、fw_uid
という名前のアセット属性に格納されます。上級開発者はアセットAPIを使用してfw_uid
属性を変更することにより、デフォルトのfw_uid
スキームを独自のスキームでオーバーライドできます。アセットAPIの使用の詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。
注意:
デフォルトのWebCenter Sites fw_uid
スキームの使用をお薦めします。リソースのデフォルトfw_uid
値をオーバーライドする場合は、値がWebCenter Sitesインスタンス全体で一意であることを確認してください。リソースのfw_uid
属性を設定したら、その後は値を変更しないでください。
使用するOracle WebCenter SitesシステムがFatWire Content Serverのアップグレードの場合は、既存のリソースの一部でfw_uid
値がCSSystem:[type]:id
に設定されている場合があります。ただし、Content Serverのバージョン7.6以降では、リソースのfw_uid
はUUID値として生成されます。Developer Toolsは、リソースのfw_uid
値がグローバルで一意であるかぎり、fw_uid
値のいずれかのタイプでリソースをマップできます。したがって、既存のリソースの現在のfw_uid
値を(CSSystem:[type]:id
の形式で)引き続き使用できます。
Developer Toolsを既存のリソースと併用する場合は、次のいずれか(または両方)を実行してください。
既存のリソースの、CSSystem:[type]:id
のfw_uid
値を引き続き使用することをお薦めします。ただし、他のWebCenter Sitesインスタンスが、異なるリソースに同じfw_uid
値を生成していないことを確認する必要があります。たとえば、WebCenter Sitesの開発インスタンスがあり、管理インスタンスにリソースをパブリッシュしている場合、パブリッシュされたリソースのfw_uid
値は両方のインスタンスに対して同じままになります。したがって、Developer Toolsを使用した、これらの2つのインスタンス間のリソースの同期によって、ID競合が発生することはありません。
異なるFatWire Content Serverインスタンス上で作成されたがfw_uid
値が同じである既存のリソースが存在する場合は、これらの各リソースに新しい一意のfw_uid
値を割り当てる必要があります。ID競合を避けるために、現在のfw_uid
値を削除して、WebCenter Sitesインスタンスからリソースをエクスポートする際にDeveloper Toolsが新しいUUID値を生成できるようにするか、または独自の一意IDをリソースに割り当てることができます。手順については、「リソースのfw_uidのオーバーライド」を参照してください。
注意:
リソースに新しいfw_uid
を割り当てる場合は、そのリソースのすべてのインスタンスに新しいfw_uid
値を割り当てる必要があります。たとえば、リソースを別のWebCenter Sitesインスタンスにパブリッシュした後でfw_uid
値を変更する場合は、必ずそのリソースの両方のコピーに、同じfw_uid
を割り当ててください。
アセットなどの大半のWebCenter Sitesリソースは、少なくとも1つのサイトに関連付けられています。リソースがWebCenter Sitesインスタンスからワークスペースへエクスポートされると、関連付けられているサイトの完全な(正規の)リストが.main.xml
ファイル内に格納されます。新しいサイト・アフィリエーションの追加、現在のサイト・アフィリエーションの削除、または(上級開発者の場合)コマンドライン・ツールを使用したリソースのナチュラル・サイト・マッピングのオーバーライドを実行しないかぎり、リソースの正規リストはすべてのWebCenter Sitesインスタンス間で同じです。
この項には次のトピックが含まれます:
デフォルトでは、Developer Toolsは、リソースの.main.xml
ファイルに格納された正規リストを参照することによって、関連サイトにリソースをマップします。リソースがインポートされるWebCenter Sitesインスタンス上に、このリストで参照されるサイトが存在する場合、Developer Toolsはそれらのサイトにリソースをマップします。WebCenter Sitesインスタンス上に、リソースの正規リストで参照されるサイトが存在しない場合、インポートは失敗します。
たとえば、開発者Aが2つのサイト(NewsとSports)をインストールします。別のWebCenter Sitesインスタンス上で、開発者Bも2つのサイト(NewsとWeather)をインストールします。両方の開発者は同じテンプレート・アセットを、それぞれのWebCenter Sitesインスタンスにインポートします。このテンプレート・アセットは、SportsとWeatherの両方のサイトに関連付けられます(両方のサイトがアセットの正規リストで参照されます)。インポート時に、Developer Toolsはテンプレート・アセットの正規リストを参照し、そのアセットを開発者Aの環境のSportsサイトと、開発者Bの環境のWeatherサイトにマップします。
開発者AとBがテンプレート・アセットに加えられた変更を互いに共有している場合、Developer Toolsは、両方のWebCenter Sitesインスタンスの適切なサイトにアセットをマッピングします。Developer Toolsは正規リストを使用して、テンプレート・アセットが関連付けられたサイトを認識します。これらのサイトの一部がインストールされていないインスタンスに、アセットをエクスポートした場合でも認識できます。
上級開発者はコマンドライン・ツールを使用して、正規リストで参照されていないサイトにリソースをインポートできます。コマンドライン・ツールを使用すると、再利用可能なモジュールを作成できます。このモジュールは、任意のサイトにインポート可能なリソースを含むワークスペースです。
たとえば、開発者がFirstSiteIIサンプル・サイト内にブログ・ソリューションを作成するとします。このソリューションには、フレックス・ファミリ、アセット、テンプレートなどのリソースが含まれます。開発者は、まだ存在しないサイトも含め、様々なサイトにリソースをインポートすることを望んでいます。上級開発者であるため、コマンドライン・ツールを使用してリソースを空のワークスペースにエクスポートしてから、このワークスペースのコンテンツを(.zip
または.tar
形式を使用して)アーカイブします。その後、他の開発者はコマンドライン・ツールを使用して、このモジュールに含まれるリソースのサイト・マッピングをカスタマイズし、モジュールのインポート先サイトを手動で指定します。
コマンドライン・ツールの使用方法の詳細は、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。再使用可能なモジュールの作成の詳細なシナリオは、「Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。