バニティURLは、製品の既存のURLに置き換わるものではありません。これらは既存のURLとともに動作します。ユーザーは、既存のURLまたはバニティURLを使用してコンテンツにアクセスできます。コンテンツ・コントリビュータは、ContributorインタフェースでバニティURLを自動生成することも作成することもできます。
通常のWebCenter Sites URLの例:
http://www.example.com/<context>/Satellite?c=Page&cid=3451344545&pagename=avisports/Page/HomeLayout
同じアセットに、次のようなバニティURLを指定できます。
http://www.example.com/Running/Home
この例からわかるように、バニティURLの方が(特にモバイル・デバイス上で)簡単に入力でき、ユーザーが読んだり、後で思い出したりしやすいという利点があります。
バニティURLは、2つの部分から構成されています。まず、様々な環境でのバニティURLの解釈を制御するWebRoot。バニティURLのもう1つの部分は、URLパターンまたはフリー・フォーム・エントリです。URLパターンは、アセット・タイプ全体に対して定義されるルールですが、フリー・フォーム・エントリは、コンテンツ・コントリビュータによって各アセットに対して個々に作成されます。
バニティURLの管理に関するその他の重要な情報は、次の各項を参照してください。
バニティURLを構成する方法は2つあります。1つは、コンテンツ・コントリビュータがバニティURLを個別に手動で構成する方法です(詳細は、『Oracle WebCenter Sitesの使用』のバニティURLの使用に関する項を参照してください)。この項では、パターンからバニティURLを生成するもう1つの方法について説明します。
トピック
パターンに基づくバニティURLは、個々のアセットから自動生成されます。パターンを登録した後、アセットを初めて保存する際にバニティURLが生成されます。パターンは、アセット・タイプごとに作成できますが、1つのサイトでのみ有効です。アセット・タイプを共有する各サイトに、同じパターンを作成する必要があります。
アセットのバニティURLの作成中、ユーザーはアセットのデフォルトのバニティURLを編集し、Oracle WebCenter Sitesによって重複するバニティURLの作成が許可されます。したがって、自動生成されたURLはユーザーが生成したURLに変更され、ユーザーはそれらのURLを削除するか、別のURLにリダイレクトするかなどを決定できます。
注意:
パターンを変更した場合、それが反映されるのはアセットを作成または保存するときのみです。パターンを変更した場合、または新しいパターンを作成した場合、それらはパターンを保存した後に作成されたアセットにのみ適用されます。
自動生成されるバニティURLを構成するには::
WebRootsは、バニティURLの不可欠な部分を形成します。WebRootsは、同じベースURLを持つが、本番環境や管理環境など、異なる環境に使用されるバニティURL間を識別するために必要です。
WebRootは、バニティURLの解釈方法を制御するために使用します。WebRootはアセットに似ています。WebRootを配信システムで使用するには、構成した後に宛先にパブリッシュする必要があります。
WebRootsには、絶対および相対の2つの形態があります。絶対WebRootは、URL接頭辞全体(ホストおよびポート情報など)を含んでいる必要があり、また、オプションでPATH接頭辞を含む場合もあって、すべてのサーバーに固有です。相対WebRootは、PATHに関連する情報のみを含んでおり、ホストまたはポートに関する情報は一切含みません。両方のURLとも、WebCenter Sitesによって同様に処理されますが、相対WebRootでは、複数の環境(たとえば開発環境、ステージング環境および本番環境)でも単一のWebRootのみが必要です。絶対WebRootでは、これらの環境の各々が固有のWebRootを持ちます。
この制限を除去するために、VirtualRootの概念がサポートされています。VirtualRootを使用するには、wcs_properties.json
ファイルに環境識別子(sites.environment
)を設定して、指定の環境で有効であることを識別する必要があります。パラメータが存在しない場合、WebRootが使用されます。絶対ルートと相対ルートを同時に定義しておくと便利な場合があるため、WebRootsのタイプを特定および理解しておくことは重要です。
次の表では、これらのタイプのWebRootの長所と短所をリストします。
表29-1 WebRootの各タイプの利点と欠点
WebRootタイプ | 利点 | 欠点 |
---|---|---|
絶対WebRoot |
|
|
相対WebRoot |
|
|
組合せ |
|
|
次の例では、この章の冒頭で示したバニティURL (http://www.example.com/Running/Home
)を使用し、管理サーバーと本番サーバーでそのURLを使用したり、アクセスしたりする方法を示します。
各環境で使用するバニティURLは次のとおりです。
本番: http://www.example.com/Running/Home
管理: http://management.example.com/Running/Home
本番サーバーに使用するサーバー名はhttp://www.example.com/
、管理サーバーに使用するサーバー名はhttp://management.example.com/
です。
絶対WebRootの場合、ルートURLをhttp://www.example.com
として、各環境に固有のWebRootが必要です。プロパティ管理ツールでsites.environment
プロパティをmanagement
に設定します。サイトは、avisports
です。
仮想ルートURIのWebRootに指定する値とsites.environment
プロパティに指定する値は同一である必要があることに注意することが重要です。
相対WebRootの場合、すべての環境を通じて1つのWebRootを使用します。ルートURLは/です。サイトは、avisports
です。
新しいWebRootを作成するには::
初めて作成した後のWebRootは、「管理」タブの「アセット・タイプ」ノードにアセット・タイプとして表示されます。
自動パターンは、バニティURLの中心的存在です。ただし、管理者がパターン一致させたURLは、多くの場合、サイトに存在するバニティURLの大部分を構成します。パターンはパスと変数を組み合せた形式であり、変数はアセットから取得するフィールドまたは事前定義済関数です。
注意:
URLのすべての部分は、保存する前にURLとしてエンコードされます。
存在する実際の変数は、選択されているアセット・タイプに応じて異なりますが、すべてのアセット・タイプで共有される共通変数が存在します。次の表に、最も一般的な変数を示します。
表29-4 共通のアセット・タイプ変数
変数名 | 変数タイプ |
---|---|
createdby |
文字列 |
createddate |
日付 |
description |
文字列 |
enddate |
日付 |
fwtags |
配列 |
id |
long |
locale |
文字列 |
name |
文字列 |
startdate |
日付 |
status |
文字列 |
subtype |
文字列 |
template |
文字列 |
updatedby |
文字列 |
updateddate |
日付 |
変数をパターン・フィールドの後に配置するには、クリックします。カーソルがどこにあっても違いはなく、新しいパターンは常に最後のアイテムです。
変数は、${<Name>}
のように指定します。たとえば、アセットのIDを取得するには、${id}
と指定します。
タイプがstring、intおよびlongの変数は、変更せずにそのまま使用できます。
タイプがarrayの変数は、1つの値のみが抽出されるように指定する必要があります。たとえば、アセットに最初に定義されているタグを取得するには、${fwtags[0]}
と指定するか、またはlistAsPath
関数を使用します。配列の番号付けは0で始まり、配列の境界外の値を使用するとNULLになります。
タイプがdateの変数はフォーマットする必要があります。そのための関数としてformatDate
が用意されています。
urlなど、他のタイプは、使用できなかったり、URLを生成する機能を必要としたりする場合があります。これらの変数を使用する場合、「URLパターンの評価」オプションを使用すると便利です。
通常のJava関数も追加できるように、変数はJava標準タイプを使用して定義されています。たとえば、nameというstring変数に対して、name.toLowerCase()
は名前を小文字に変換します。
この項の内容は次のとおりです。
関数は、データを変換およびフォーマットして、バニティURLに使用する際に役に立ちます。WebCenter Sitesには、バニティURLの作成に役立つ事前定義済関数が用意されています。
ここでは、avisports記事アセット・タイプに基づいて例を示します。アセット名は、"Baker Likely to Stay With Stars"です。
注意:
URLの先頭部分は常にWebRootです。例の場合、これはローカル・システム名とコンテキスト・ルートです。次の部分、「Avi」はフィルタ接頭辞です。この後の例では、固有のパスのみを示します。
アセット"Baker Likely to Stay With Stars"に対して、URL生成に使用できる様々なオプションがあります。それぞれの例で、関数と生成されるURLを示します。
ステップ | 機能 | 結果のURL |
---|---|---|
まずは単純な名前のパターンです。 | /Article/${name} |
/Article/Baker+Likely+to+Stay+With+Stars |
名前を小文字に変換します。 | /Article/${name.toLowerCase()} |
/Article/baker+likely+to+stay+with+stars |
このURLから空白を削除します。 | /Article/${f:spaceToUnderscore(name)} |
/Article/Baker_Likely_to_Stay_With_Stars |
複数の変数を使用します。 | /Article/${id}/${createdby} |
/Article/1328196049037/fwadmin |
関数内部で関数を使用します。 | /Article/${(f:formatDate(createddate,"yy/MM/dd")} |
/Article/12-04-27 |
開発者は、一部のインスタンスのバニティURLの一時的な無効化が必要になります。たとえば、開発者はテスト・インスタンスをバニティURLにリダイレクトしない場合があります。WebCenter SitesのバニティURLへのリダイレクトは、JVMパラメータを設定することで無効化できます。
アプリケーション・サーバーで、JavaオプションのJVMパラメータとして-Dsites.disablevanityurl
オプションを設定します。
JAVA_OPTIONS=$JAVA_OPTIONS -Dsites.disablevanityurl="true"
たとえば、多くの場合、管理者は競合を解決するためにシステム全体で定義されているバニティURLを1箇所で表示しようとします。「システム・ツール」ノードを使用すると、管理者は現在定義されているすべてのバニティURLを表示して、URL競合を解決できます。次の各項の説明を参照してください。
すべてのバニティURLを表示するには:
このリストには、(すべてのサイトで)定義されているすべてのURLが表示されるので、用意されている検索ボックスを使用してフィルタすることによって、目的のURLを探す必要があります。このメニューから、バニティURLの手動による削除、問題の有無のチェック、競合の発生元の確認を実行できます。ただし、パターンに基づいて生成されたURLは、アセットが次回保存されたときに自動的に再生成されます。
同じパスを持つバニティURLは(WebCenter Sites全体でも) 1つしか存在できないので、バニティURLは一意です。たとえば、2つのサイトがあり、各サイトにルール・パターン/Page/${name}
が存在し、両方でページに同じ名前(たとえば"Home")を使用している場合、競合が発生します。
どちらのページであっても、先に保存したページは正常に保存されてバニティURLが作成されますが、後から保存したページはバニティURLの作成に失敗します。
バニティURLを解決する方法は2つあります。1つは、Webサーバーを使用してURLをリライトする方法です。もう1つは、開発時によく見られる、Webサーバーが存在しない場合のために設計された方法で、フィルタを使用します。
WebCenter Sitesにはデフォルトで、サンプル・サイト専用のURLリライタ・フィルタが用意されています。このリライタ・フィルタは、任意のサイトでWebRootと組み合せて使用するように構成できます。このフィルタは、(先頭からの文字列一致に基づいて)フィルタを通過するすべてのコールをインターセプトし、バニティURLフィルタとしてWebCenter Sitesに渡します。
簡単に言えば、Webサーバー上にリライト・ルールが存在しなくてもバニティURLが動作するようにできます。このフィルタを使用する場合の主要な制限は、正しいURLがバニティURLとして処理されるように、コンテキスト・ルートと一意の接頭辞を持つ必要があるということです。
注意:
"FSII"と"Avi"は、サンプル・サイトがインストールされる際に、URLリライト・フィルタ用に事前構成されるパラメータです。値はsite.prefixプロパティで設定されます。
リライタ・フィルタを有効にするには::
例:
相対WebRootが/Avi
、パスが/Running/Home
である場合、フィルタによって次のようなURLが生成されます。
http://<Sites Host>:<Sites Port>/<Context Root>/Avi/Running/Home
フィルタを使用するので、フィルタとWebRootの両方で接頭辞(具体的に言うと、この例ではAvi
)を使用する必要があります。
注意:
バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があります。そのような場合、既存のパラメータが既存のURLに連結されます。たとえば、time=true
を渡す場合、サイトに送信される前述のURLは、次のようになります。
http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true
多くの場合、モバイル固有のサイトを使用するユーザーは、モバイル・ユーザー専用のURLを使用することを望みます。短いURLがモバイル・ユーザーに利点をもたらすだけでなく、通常は固有のドメインとURLが存在するためです。Webサイトのモバイル・ページ用に固有のドメインとURLを設定するには、次のアイテムを実行します。
フィルタと同じ方法でバニティURLにアクセスする要件がある場合、URLリライトに伴うすべての制御と機能が必要な場合、Webサーバーを使用することができます。
Webサーバーを使用する場合、リライトされるバニティURLはすべて、WebCenter Sitesに送信される前に2つに分割する必要があります。1つはWebRoot、もう1つはパスです。たとえば、URL http://www.example.com/Running/Home
に対しては、WebRoot http://www.example.com
と、/Running/Home
を生成するパターンを使用します。このURLをWebサーバーから渡すには、URLをWebRootとパスに分ける必要があります。そうすると、これらはWebCenter Sitesの特別なフィルタへの問合せパラメータとして別々に渡されます。リライトされたURLを処理するために使用されるバニティURLフィルタは、「サイト」と呼ばれ、<content root>/Sites
でアクセスされます。
URLの2つの部分は分割されて、それぞれlookuphostとlookuppageに格納されます。lookuphostはWebRootを参照します(絶対WebRootの場合はフル・サーバー名、ポートおよび接頭辞、相対WebRootの場合は接頭辞のみ)。lookuppageは接頭辞の後のパスの残りの部分を参照します。例に示したURLを使用する場合、WebCenter Sitesに渡すURLは、次のようにリライトされている必要があります。
http://<Sites Host>:<Sites Port>/<contextpath/Sites?lookuppage=/Running/Home &lookuphost=http://www.example.com
注意:
バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があります。そのような場合、既存のパラメータが既存のURLに連結されます。たとえば、time=true
を渡す場合、サイトに送信される前述のURLは、次のようになります。
http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true
Webサーバーとサイトの組合せはすべて一意なので、次の内容は、mod_rewrite
(OHS、ApacheおよびIBM HTTPサーバーでURLのリライトに使用される)の使用方法のガイドラインおよび例として参照する必要があります。ほとんどのシステムでは、示されているルールを正しく動作させるために変更が必要です。
mod_rewrite
を使用する方法は2つあります。WebCenter SitesフィルタのURLを直接変換するために使用することも、URLリライタ・フィルタとともに使用して、同じアクションをはるかに単純なmod_rewrite
ルールで実行することもできます。どちらの方法についても例を示します。どちらが適切かを決定するには、WebCenter SitesフィルタがバニティURLを分割する追加手順(ならびにコスト)が、リライト・ルール簡略化に見合うかどうかを判断します。
次以降の手順は、手動でコンパイルされたApache 2.4.xに基づいています。オペレーティング・システム付属のバージョンを使用する場合、mod_rewrite
を有効にして構成するために必要な変更は異なる可能性がありますが、ルールと概念は同じです。
トピック
mod_rewriteを設定するには:
注意:
はるかに簡単な構造とテストが可能なWebページがあります。mod_rewrite
ルールを最初に作成しておく場合、これらのサイトの1つを使用することをお薦めします。
mod_rewrite
ルールの例をいくつか示すために、まず環境の概要を定義します。次に示すのは、このガイドで使用しているバニティURLに基づくサンプルです。開始するには、同じエレメントを、環境にあわせて値を変更して使用してください。
ユーザーが使用することになるバニティURL:
本番:
http://www.example.com/Page/Surfing http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars http://www.example.com/Home http://www.example.com/Home?time=true
開発:
http://dev.example.com:8080/Running/Home
WebCenter Sitesの一般情報:
本番コンテキスト・ルート: /cs
本番リライト・フィルタ: /AVISPORTS
開発コンテキスト・ルート: /csdev
開発リライト・フィルタ: /Avi
各サーバーに定義されているWebRoot:
本番 - 絶対: http://www.example.com
開発 - 相対: /Avi
次の表に、URLの構造を示します。
URL | WebRoot | パス | 問合せパラメータ |
---|---|---|---|
http://www.example.com/Page/Surfing |
http://www.example.com |
/Page/Surfing |
|
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars |
http://www.example.com |
/Article/Baker_Likely_to_Stay_With_Stars |
|
http://www.example.com/Home |
http://www.example.com |
/Home |
|
http://www.example.com/Home?time=true |
http://www.example.com |
/Home |
time=true |
http://dev.example.com:8080/Running/Home |
/Avi |
/Running/Home |
フィルタは2つあります。1つはWebCenter SitesバニティURLフィルタ、もう1つはWebCenter Sitesリライト・フィルタです。リライト・フィルタを使用する場合、データはリライト・フィルタからバニティURLフィルタに透過的に渡されます。
WebCenter SitesバニティURLフィルタを使用する場合、URLは次のようになります。
本番:
http://www.example.com/Page/Surfing
lookuphost=http://www.example.com &lookuppage=/Page/Surfing
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
lookuphost=http://www.example.com &lookuppage=/Article/Baker_Likely_to_Stay_With_Stars
http://www.example.com/Home
lookuphost=http://www.example.com &lookuppage=/Home
http://www.example.com/Home?time=true
lookuphost=http://www.example.com &lookuppage=/Home&time=true
開発:
http://dev.example.com:8080/Running/Home
lookuphost=/cs/Avi&lookuppage=/Running/Home
WebCenter Sitesリライタ・フィルタを使用する場合、URLは次のようになります。
本番:
http://www.example.com/Page/Surfing
/cs/AVISPORTS/Page/Surfing
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
/cs/AVISPORTS/Article/Baker_Likely_to_Stay_With_Stars
http://www.example.com/Home
/cs/AVISPORTS/Home
http://www.example.com/Home?time=true
/cs/AVISPORTS/Home?time=true
開発:
http://dev.example.com:8080/Running/Home
/csdev/Avi/Running/Home
いくつかのURLを選択して、コンポーネント部分に分割したら、mod_rewrite
を使用してこれらのURLを変換する必要があります。mod_rewrite
のルールは、2つの部分から構成されます: 1つ目は、Webサーバーに提供されるURLに適合する正規表現、2つ目は、渡されたときの表示内容です。前半部分が一致しない場合、URLは次のリライト・ルールに渡されます。定義されているどのルールも一致しない場合、URLは変更されないままで渡されます。したがって、複数のルールが存在する場合、その順序が重要になります。
注意:
1. mod_rewrite
は、あらかじめ有効にしておくオプション・コンポーネントです。mod_rewrite
ルールを作成しても、mod_rewrite
コンポーネントを実際に有効にしていない場合、ルールはスキップされます。エラーは発生せず、何もリライトされません。そのため、開発中はデバッグをアクティブにしてerror.logを監視し、mod_rewrite
に関する詳細を取得することをお薦めします。
ここで説明する内容は、mod_rewrite
の機能のほんの一部にすぎません。大部分のサイトでは、通常はもっと複雑なルールが必要になります。詳細は、ベンダーのドキュメントを参照してください。
この例では、次に示す、本番用の最初のURLを使用します。
http://www.example.com/Page/Surfing
これに次のルールを作成します。
RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1 [L]
このルールには、次の表に示すように4つのコンポーネント部分があります。
RewriteRule — |
^(.*)$ |
/<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1 |
[L] |
---|---|---|---|
後に続くエントリがmod_rewrite ルールであることを示す文です。 |
正規表現で、次のように分割されます。
したがって、この式は、文字列の開始と終了の間にあるすべてのテキストを変数に保存することを示します。 |
バニティURLのWebCenter Sitesコンテキスト・ルート、フィルタおよびパスで、次のように分解されます。
|
mod_rewrite にルールの終了を通知します。すべてのmod_rewrite ルールは、最後にこれを記述する必要があります。 |
次のルールは/Page/Surfing
だけでなく、送信された他のすべてのページも処理して、ホストの後から行の終了までのすべてを抽出します。
RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com& lookuppage=$1 [L]
したがって、次ではこのルールで処理されます。
http://www.example.com/Article/Baker_Likely_to_Stay_With_Starsおよび
http://www.example.com/Home
しかし、次のURLは、ホストとパス以外に、問合せパラメータが渡されているため、このルールで処理されません。
http://www.example.com/Home?time=true
リライト・フィルタを使用する場合、バニティURLフィルタの場合のようにURLを分割する必要はありません。かわりに、Sitesコンテキスト・ルートおよびリライタ・フィルタ接頭辞がURLに追加されます(これはバニティURLの導入前のWebCenter Sitesを使用する場合とよく似ています。したがって、既存のルールは、バニティURLをサポートするように簡単に変更できます)。
http://www.example.com/Page/Surfing
を使用しており、これは/<context>/AVISPORTS/Page/Surfing
になります。WebCenter Sitesでは、動的に設定できるように、自動生成されるバニティURLをカスタマイズできます。
CustomElements/VanityUrl/sitename/assettype/ModifyWebrefs
CustomElements/VanityUrl/assettype/ModifyWebrefs
CustomElements/VanityUrl/sitename/ModifyWebrefs
CustomElements/VanityUrl/ModifyWebrefs
ここで、sitename
はユーザーがログインしているサイトの名前で、assettype
は保存されるアセットのタイプです。
注意:
優先順位に応じて、1つの要素のみ実行されます。表29-5では、要素スコープで使用できる2つのオブジェクト(assetDataおよびwebrefs)について説明します。
表29-5 assetDataおよびwebrefsの説明
オブジェクト | 説明 |
---|---|
assetData |
アセットの現在のデータを含むassetDataのインスタンス。 |
webrefs |
webreferenceのインスタンスのリスト。現在のアセットの自動生成済webreferencesのリストが含まれます。戻りオブジェクトとしても動作します。このオブジェクトによって渡されるすべてのwebreferencesがアセットに割り当てられます。 |