この項の内容は次のとおりです。
7.5より前のリリースのSite Studioからアップグレードする場合、Site Studio 11gR1で使用するにはWebサイトをアップグレードする必要があります。これは、Site Studioバージョン7.5と10gR3で次のような重要なアーキテクチャ上の変更があるからです。
サイト階層はプロジェクト・ファイルに格納され、フォルダに依存しなくなりました。その結果、Oracle Content Serverのフォルダ機能は必要なくなりました。
WebサイトURLは、SS_GET_PAGEサービス(11.7.38項「SS_GET_PAGE」を参照)を表示するCGIベースのアドレスではなく、論理パスと接尾辞として表示されます。その結果、よりフレンドリなパスベースのURLが表示されます。
レイアウト・ページで<base>タグが使用されなくなりました。したがって、baseタグに依存するハイパーリンクおよび参照は変更される必要があります。
siteIdとルートIDは同義ではなくなりました。
アップグレード後、Site Studio 11gR1ではアップグレードされたプロジェクトはレガシー・プロジェクトとして機能します。つまり、10gR4より前のアーキテクチャを使用し、Site Studio 10gR4および11gR1の新規アーキテクチャと機能は使用されません。Site Studio 7.5または10gR3を使用して作成されたプロジェクトも同様です。それ自体はアップグレードする必要はなく、Site Studio 11gR1で使用できますが、レガシー(10gR4より前)モードで機能し続けます。
7.5より前のリリースのSite Studioをアップグレードする場合、次のタスクが自動的に実行されます。
アクション | 説明 |
---|---|
フォルダベースのサイトのプロジェクトベースのサイトへのアップグレード | フォルダ構造の既存の階層がプロジェクト・ファイルで再生成されます。ルートdCollectionNameがsiteLabelとして使用され、ルートdCollectionIDがsiteIdとして使用されます。originalCollectionIDプロジェクト属性が設定され、サイト・タイプがルート・セクションからプロジェクトに転送されます。 |
新規サイトでのカスタム・セクション・プロパティの更新 | タイプsiteidおよびurlのカスタム・セクション・プロパティが更新されます(必要に応じてフレンドリURLが追加されます)。 |
レイアウト・ページでのフラグメント・インスタンス・パラメータの更新 | タイプmanagedurlおよびurlのパラメータが更新されます。 |
メタデータの移入 | 「プロジェクト・ファイルの作成」オプションが有効な場合、xWebsiteSection値が移入されます(xCollectionIDから導出)。 |
レイアウト・ページのリンクおよびデータ・ファイルの更新 | 「レイアウトのアップグレード」および「データファイルのアップグレード」オプションが有効な場合、レイアウト・ページのweblayoutリンクおよびコントリビュータ・データ・ファイルがアップグレードされてHttpRelativeWebRootトークンが含まれます。オプションでjavascriptリンクも更新されます。 |
ナビゲーションの更新 | Webサイトのナビゲーション・ファイルが生成されます。 |
サイトのアップグレード・タスクは、使用している各コンテンツ・サーバーのSite Studioコンポーネントのアップグレードから始め、その後コンテンツ・サーバーに格納されているWebサイトをアップグレードします。
フォルダ・コンポーネントはSite Studioバージョン7.5以降使用されていませんが、各サイトをフォルダベースの階層からプロジェクトベースの階層に移行するために、Webサイトのアップグレード中フォルダを保持する必要があります。
その後、フォルダ・コンポーネントを無効にできます。フォルダの使用を続ける場合、適切なメタデータで構成する必要があります(B.4.5項「フォルダへのWebサイト・セクションの割当て」を参照)。
注意: アップグレード手順に従うと、サーバー上の各Webサイトがアップグレードされます。選択したサイトのみをアップグレードする場合、別のサーバーに他のサイトのコピーを作成する必要があります。 |
Webサイトが単一コンテンツ・サーバーに格納されている場合、アップグレードは次の処理で構成されます。
新規Site Studioコンポーネントのインストール(初めに古いコンポーネントをアンインストール)。
コンテンツ・サーバーでの完全アップグレードの実行。詳細は、B.3.3項「完全アップグレードの実行」を参照してください。
自動アップグレードで行われない追加処理の手動実行。詳細は、B.4項「追加処理の手動実行」を参照してください。
開発サーバー、コントリビューション・サーバー、本番サーバーなど異なる用途の複数のコンテンツ・サーバーにサイトがある場合があります。
各サーバー(ソース・サーバー)のコンテンツは、アーカイバ/レプリケータ・ユーティリティを使用して次のサーバーにコピーされます。したがって、レプリケーションの問題が発生しないよう各サーバーのサイトのアップグレードを注意深く計画することが重要です。
コンテンツ・サーバーの最初の2つのインスタンス上
コンテンツ・サーバー間のレプリケーションを停止します。
新規Site Studioコンポーネントをインストールします。
コンテンツ・サーバーのソース・インスタンス上
サイトの完全アップグレードを実行します。詳細は、B.3.3項「完全アップグレードの実行」を参照してください。
その後
追加処理(自動アップグレードで行われない処理)を手動で実行します。詳細は、B.4項「追加処理の手動実行」を参照してください。
コンテンツ・サーバーのターゲット・インスタンス上
サイトの最小アップグレードを実行します。詳細は、B.3.4項「最小アップグレードの実行」を参照してください。
コンテンツ・サーバーの両インスタンス上
コンテンツ・サーバー間のレプリケーションを再開します。
新規コンポーネントがコンテンツ・サーバーのすべてのインスタンスにインストールされ、Webサイトが前述のようにアップグレードされたら、サイトのレプリケートを再開できます。
Site Studioのレプリケーション機能を使用できます(『Oracle WebCenter Content Site Studio管理者およびマネージャーズ・ガイド』を参照)。あるいは、アーカイバ/レプリケータを使用していて、この使用を続ける場合、Site Studioプロジェクト・ファイルを含めるようアーカイブ問合せを変更すれば可能です。
次のターゲット・コンテンツ・サーバー(レプリケーションでのダウンストリーム)上
ソースとターゲットのコンテンツ・サーバー間のレプリケーションを停止します。
注意: このケースでは、ソース・サーバー(Box 2)は前述の手順のターゲット・サーバーで、ターゲット・サーバー(Box 3)は後続のレプリケーション(ダウンストリーム)での次のサーバーです。 |
新規Site Studioコンポーネントをインストールします。
その後
サイトの最小アップグレードを実行します。詳細は、B.3.4項「最小アップグレードの実行」を参照してください。
その後
ソースとターゲットのコンテンツ・サーバー間のレプリケーションを再開します。
レプリケーションのダウンストリームのコンテンツ・サーバーのターゲット・インスタンスごとに最後の手順を繰り返します。
コンテンツ・サーバーの完全アップグレードは、単一サーバーの設定の場合に必要です。複数サーバーの設定の場合のソース・サーバーにも必要です。(複数サーバーの設定での他のすべてのサーバーには最小アップグレードが必要です。)
サイトをアップグレードすると、Site Studioで既存のフォルダベースのサイトがプロジェクトベースのサイトに変更されます。これが行われる際、プロジェクト・ファイルがコンテンツ・サーバーの管理対象アイテムとして作成されます。したがって、各Webサイトを表すプロジェクト・ファイルに割り当てるメタデータを識別する必要があります。
アップグレード・プロセスで、コンテンツ・サーバーは、変更されるコンテンツの索引付けを試みます。これには、時間とリソースが大幅に必要となる場合があります。アップグレード・プロセスを開始する前に自動索引付けを一時的に無効にし、終了したら再度有効にすることもできます。(詳細は、Oracle Content Serverの管理ドキュメントを参照してください。)
完全アップグレードを開始する前に、サーバーで新規Site Studioコンポーネントをインストールし、有効にしておく必要があります。
完全アップグレードを実行するには、次のタスクを実行します。
管理者としてコンテンツ・サーバーにログオンし、「管理」ページ、「Site Studioの管理」ページの順に開きます。
「プロジェクトのデフォルト・ドキュメント情報の設定」をクリックします。
「プロジェクトのデフォルト・ドキュメント情報の設定」ページが開きます。ここで、Site Studioで作成する新規プロジェクトのデフォルト・メタデータを割り当てます。
メタデータ値を指定したら、「更新」をクリックします。
これによって、「Site Studioの管理」ページに戻ります。ここでアップグレード・プロセスを開始できます。
「Webサイトの管理」をクリックします。
Webサイト更新ページに移動をクリックします。(このオプションは、古いWebサイトが検出された場合にのみ表示されます。)
「詳細オプション」をクリックして、サイトのアップグレード・オプションを指定します。
完全アップグレード向けに次の選択をします。
「プロジェクト・ファイルの作成」を選択します。
「レイアウトのアップグレード」を選択します。
「データファイルのアップグレード」を選択します。
「ハイパーリンクの変換」を選択し、リンク形式を選択します。
サーバー側リンク: サーバー側スクリプトを使用してターゲットの場所をコード化したIDを含むリンク。
パスベースのURL: ターゲットの場所の完全パスを含むリンク。
「オプション設定」をクリックして「レガシーWebサイトのアップグレード」ページに戻ります。
「アップグレードの開始」をクリックします。
アップグレードの必要な各ファイルがこのページに表示されます。アップグレード・プロセスが完了したことを示すメッセージが表示されるまで待ちます。
注意: サイトのアップグレードでサイト階層とその多数のリンクが自動的に更新され、コンテンツ・サーバーの「Webサイト」メニューにサイトがリストされます。 |
最小アップグレードは、複数サーバーの設定の場合に必要で、すべてのターゲット・サーバー(レプリケートされるWebサイトのあるサーバー)に適用されます。
最小アップグレードを開始する前に、サーバーで新規Site Studioコンポーネントをインストールし、有効にしておく必要があります。
最小アップグレードを実行するには、次のタスクを実行します。
管理者としてコンテンツ・サーバーにログオンし、「管理」ページ、「Site Studioの管理」ページの順に開きます。
「デフォルトのプロジェクト・ドキュメント情報の設定」をクリックします。
「プロジェクトのデフォルト・ドキュメント情報の設定」ページが開きます。ここで、Site Studioで作成する新規プロジェクトのデフォルト・メタデータを割り当てます。
メタデータ値を指定したら、「更新」をクリックします。
これによって、「Site Studioの管理」ページに戻ります。ここでアップグレード・プロセスを開始できます。
「Webサイトの管理」をクリックします。
Webサイト更新ページに移動をクリックします。(このオプションは、古いWebサイトが検出された場合にのみ表示されます。)
「詳細オプション」をクリックして、サイトのアップグレード・オプション(図B-2)を指定します。
「プロジェクト・ファイルの作成」を選択します。
注意: これによってプロジェクト・ファイルがアップグレードされ、「Webサイト・セクション」メタデータ値が移入されます。 |
「オプション設定」をクリックして「レガシーWebサイトのアップグレード」ページに戻ります。
「アップグレードの開始」をクリックします。
アップグレード・プロセスが完了したことを示すメッセージが表示されるまで待ちます。
これで、コンテンツ・サーバーの「Webサイト」メニューにサイトがリストされます。
Webサイトのアップグレード後、手動で行う必要のある処理がまだいくつかあります。次のような処理です。
7.5より前のWebサイトをアップグレードしたら、ナビゲーション・ファイルを更新する必要があります。これは、デザイナ(「ナビゲーションの更新」ボタン)または「Site Studioの管理」ページ(具体的には、「Webサイトの管理」ページ)で行えます。この処理は、コントリビュータがサイトで適切に機能するために必要です。
7.5より前のWebサイトをアップグレードしたら、コンテンツ・サーバーの索引を再作成する必要がある場合があります。コンテンツ・サーバーが、データベース検索および索引付け(全文またはメタデータのみ)を使用するよう設定されている場合、検索索引を再作成する必要はありません。別の検索エンジンを使用している場合、検索索引を再作成する必要があります。これが必要なのは、サイトのフォルダに存在するすべてのコンテンツ・アイテム用のxWebsiteSectionメタデータ・フィールドがSite Studioで更新されるためです。
注意: Oracle Content Serverで管理されるコンテンツ・アイテムの数にもよりますが、検索索引の再索引には非常に時間がかかる場合があります。したがって、この再作成は、Oracle Content Serverの使用がオフピークのとき(通常、夜間または週末)に行うことをお薦めします。 |
索引の再作成の詳細は、Oracle Content Serverの管理ドキュメントを参照してください。
7.5より前のWebサイトのアップグレード後に行う必要のある手動更新のほとんどは、カスタム・フラグメントの変更に関係するものです。Site Studioに含まれる、あらかじめ定義されたフラグメントを現在使用している場合、これを行う必要がありません。これは、各フラグメントの更新版がSite Studioの各リリースに含まれているためです。
ほとんどの場合、組織の特定の目的に合せてフラグメントをカスタマイズしていたり、新しいものを導入していたりします。フラグメントが最新バージョンで機能するためにフラグメントに行う必要のある処理が3つあります。
コンテンツ・サーバーのWebアクセス可能なディレクトリ(weblayout)を指す<base>は、使用されなくなりました。サイトのアップグレード時、Site Studioでレイアウト・ページおよびコントリビュータ・データ・ファイル内の必要なコードは更新されますが、カスタム・フラグメントとスクリプトではこの処理を手動で実行する必要があります。
これは、<base>タグのURLを基準とした、ハンドコードされたリンクを再作成して行うか、かわりにHttpRelativeWebRootサーバー側変数を使用します。
例
グラフィックへの次のようなリンクがあるとします。
<img src="groups/public/documents/adacct/logo.gif">
次ものと置き換える必要があります。
<img src="<!--$HttpRelativeWebRoot-->groups/public/documents/adacct/logo.gif">
既存のフラグメントでSS_GET_PAGE、javascript:linkまたはjavascript:nodelinkスタイル・ハイパーリンクを使用する場合、多くの利点を使用できるようパスベースのURLに変更することができます。(詳細は、『Oracle WebCenter Content Site Studio Designerユーザーズ・ガイド』を参照してください。)
例
次のようなリンクについて考えてみます。
<a href="javascript:nodelink(42);">link</a>
次のものと置き換える必要があります。
<a href="<!--ssServerRelativeSiteRoot-->products/servers/index.htm">link</a>
GET_SEARCH_RESULTSサービスを使用したフラグメントは引き続き機能しますが、SS_GET_SEARCH_RESULTSサービスを使用するようアップグレードされるまでSite Studio 7.5および10gR3で提供される機能は利用できません(詳細は、11.7.43項「SS_GET_SEARCH_RESULTS」を参照)。
SS_GET_SEARCH_RESULTSサービスを使用することには、いくつかの利点があります。
limitscopeロジック(現在はサービスで提供され、フラグメントには不要): これは、検索結果を現在のWebサイト内のアイテムのみに限定します。
dontshowinlistsロジック(現在はサービスで提供され、フラグメントには不要): これは、検索結果をコントリビュータによってリストから削除されていないアイテムのみに限定します。
ssUrl: この列は、検索結果の各行にフレンドリURLを提供します。
GET_SEARCH_RESULTSサービスを使用するフラグメントは、通常動的リスト・フラグメントおよび検索結果ナビゲーション・フラグメントです。必要な更新は、Site Studioのアップグレード元のバージョンによって異なります。
Site Studioバージョン6.5を使用し、そのバージョンを使用する動的リストまたは検索結果フラグメントをカスタマイズしていた(Site Studioフラグメントをコピーし、それにカスタム・コードを追加するなど)場合、古いxWebsiteIDメタデータ・フィールドを使用してlimitscopeロジックを実行するコードを使用します。
Site Studioバージョン7.2を使用し、そのバージョンを使用する動的リストまたは検索結果フラグメントをカスタマイズしていた(Site Studioフラグメントをコピーし、それにカスタム・コードを追加するなど)場合、新しいxWebsitesメタデータ・フィールドを使用してlimitscopeロジックを実行するコードを使用します。また、新しいxDontShowInListsForWebsitesメタデータ・フィールドを使用してdontshowinlistsロジックを実行するコードを使用します。
前述のどちらの場合も、古いlimitscopeおよびdontshowinlistsロジックを削除し、この機能を内部で提供する、新しいSS_GET_SEARCH_RESULTSサービスを使用するよう更新する必要があります。
例
Site Studio 6.5では、標準動的リスト・フラグメントには、SSLimitScopeパラメータに対して次のコードが含まれます。これを削除します。
<!--$QueryText=eval(ssQueryText)--> <!--$if ssLimitScope like "true"--> <!--$if strEquals(QueryText, '')--> <!--$QueryText='xWebSiteID=' & siteId--> <!--$else--> <!--$QueryText='(' & QueryText & ') and (xWebSiteID=' & siteId & ')'--> <!--$endif--> <!--$endif-->
Site Studio 7.2では、標準動的リスト・フラグメントには、SSLimitScopeパラメータに対して次のコードが含まれます。これを削除します。
<!--$QueryText=eval(ssQueryText)--> <!--$if ssLimitScope like "true"--> <!--$if strEquals(QueryText, '')--> <!--$QueryText='xWebsites <contains> ' & siteId--> <!--$else--> <!--$QueryText='(' & QueryText & ') and (xWebsites <contains>' & siteId & ')'--> <!--$endif--> <!--$endif--> <!--$if strEquals(QueryText, '')--> <!--$QueryText= 'not(xDontShowInListsForWebsites <contains> ' & siteId & ')'--> <!--$else--> <!--$QueryText='(' & QueryText & ') and not(xDontShowInListsForWebsites <contains> ' & siteId & ')'--> <!--$endif-->
古いlimitscopeロジックをフラグメントから削除したら、SS_GET_SEARCH_RESULTSを使用するようGET_SEARCH_RESULTSサービス・コールを変更します。ただし、SS_GET_SEARCH_RESULTSサービスを呼び出す前に、次のパラメータ値を設定する必要があります。
パラメータ | 説明 |
---|---|
ssLimitScope | limitscopeロジックがSS_GET_SEARCH_RESULTSサービスによって適用されることを指定します。通常、このtrue/false値は、フラグメント・パラメータ値によって指定されます。 |
ssDontShowInLists | dontshowinlistsロジックがSS_GET_SEARCH_RESULTSサービスによって適用されることを指定します。通常、このtrue/false値は、すべてのフラグメントでtrueに指定されます。 |
ssTargetNodeId | 検索結果の表示に使用されるノードIDを指定します。ssTargetSiteIdは、コンテンツ・サーバー上の他のWebサイトへのリンクの生成にも使用できます。ssTargetSiteIdが指定されていない場合、生成されるリンクでは、リンクの生成元と同じサイトが想定されます。 |
ssTargetSiteId | 検索結果の表示に使用されるサイトIDを指定します。ssTargetNodeIdパラメータは、ターゲット・ノードの完全修飾にも使用される必要があります。 |
ssSourceNodeId | リンクを含む現在のページのノードIDを示します。 |
ssSourceSiteId | リンクを含む現在のページのサイトIDを示します。 |
ssWebsiteObjectType | 検索結果が特定のWebsiteオブジェクト・タイプに限定されることを指定します。通常、この値は空のままにします。 |
ssUserSearchText | 完全テキスト検索を実行するユーザー・テキストを指定します。通常、これは、検索ボックス・フラグメントに値を入力するコンシューマによって値が指定される検索結果フラグメントにのみ適用されます。 |
SS_GET_SEARCH_RESULTSサービス・コールの結果をループする際、そのアイテムへのハイパーリンクを作成するには、通常検索結果の新規ssUrl列を使用します。これによって、わかりにくいIDベースのURLではなく、フルパスベースのURLが使用されます。
また、これらのURLは、リンクのソース場所を示すパラメータに追加されます。これによって、無効なリンクがあった場合にエラー・ページが適切に生成されます。
次のパラメータがURLに付加されます。
パラメータ | 説明 |
---|---|
ssSourceNodeId | ソース・ノードIDを宣言します。ssTargetNodeIdとxWebsiteSectionの両方が空の場合、フレンドリURLの生成に使用されます。 |
ssSourceSiteId | ソース・サイトIDを宣言します。これによって、ターゲット・ページが見つからない場合にエラー・ページが表示されます。 |
Idocスクリプトを使用した簡単な例を次に示します。
<!-- New params for SS_GET_SEARCH_RESULTS --> <!--$ssLimitScope="true"--> <!--$ssDontShowInLists="true"--> <!--$ssTargetNodeId=""--> <!--$ssTargetSiteId=""--> <!--$ssSourceNodeId=nodeId--> <!--$ssSourceSiteId=siteId--> <!--$ssWebsiteObjectType=""--> <!--$ssUserText=""--> <!--$executeService("SS_GET_SEARCH_RESULTS")--> <!--$loop SearchResults--> <a href="<!--$ssUrl-->?ssSourceSiteId=<!--$siteId-->&ssSourceNodeId= <!--nodeId-->"> <!--$dDocTitle--> </a><br><br> <!--$endloop-->
詳細は、Site Studio製品に含まれている動的リスト・フラグメントおよび検索結果フラグメントを参照してください。
7.5より前のSite Studioを使用して作成されたカスタム要素フォームは、Site Studio 11gR1と互換性がありません。手動でアップグレードし、再作成する必要があります。下位互換性が維持されていない主な理由は、以前のSite StudioがInternet Explorerの独自仕様のwindow.external機能に依存している(コントリビュータに使用されているActiveXコントロールによる)ためです。Site Studio 10gR3 (10.1.3.3.3)以上で使用されているブラウザに依存しないJavaScriptベースのコントリビュータ・アプリケーションの結果、この機能はSite Studioから削除されました。
Site Studioでは、サイト階層の編成および管理を行うOracle Content Serverフォルダ機能(フォルダ・コンポーネント)は使用されなくなりました。7.5より前のSite Studioで作成されたWebサイトがアップグレードされる場合、アップグレードされたサイトの一部であると認識されるよう、フォルダ内のコンテンツに新規メタデータ値(Webサイト・セクション)が割り当てられます。
アップグレード後にフォルダに追加された新規コンテンツには、このメタデータ値は付加されません。したがって、フォルダを使用してサイトへのコンテンツの追加を続ける場合、各フォルダにWebサイト・セクションを割り当てる必要があります。
Webサイト・セクション値を割り当てるには、次のタスクを実行します。
更新するフォルダへの書込み(RW)アクセス権を持つユーザーとしてコンテンツ・サーバーにログオンします。
「コンテンツの参照」トレイまたはメニューを開き、「Webサイト」ツリーを開きます。
更新するWebサイトを選択します。
変更するフォルダの「フォルダ情報」をクリックします。
「更新」アクションを選択します。
「Webサイト・セクション」フィールドの隣にある「Browse」をクリックします。
対応するWebサイト・セクションを選択します。
「OK」をクリックします。
「更新」をクリックします。
Site StudioでWebサイト・セクションにマップするフォルダごとにこの手順を繰り返します。