バニティURLの構成

32 バニティURLの構成

バニティURLは、短くてわかりやすい、管理の簡単なURLです。WebCenterサイトには、バニティURLを作成する機能があります。このバニティURLには、通常、バニティURLが参照するWebページの名前やコンテンツを説明する情報が含まれています。

バニティ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の生成

バニティURLを構成する方法は2つあります。1つは、コンテンツ・コントリビュータがバニティURLを個別に手動で構成する方法です(詳細は、『Oracle WebCenter Sitesの使用』のバニティURLの使用に関する項を参照してください)。この項では、パターンからバニティURLを生成するもう1つの方法について説明します。

トピック:

自動生成URLの構成

パターンに基づくバニティURLは、個々のアセットから自動生成されます。パターンを登録した後、アセットを初めて保存する際にバニティURLが生成されます。パターンは、アセット・タイプごとに作成できますが、1つのサイトでのみ有効です。アセット・タイプを共有する各サイトに、同じパターンを作成する必要があります。

アセットのバニティURLの作成中、ユーザーはアセットのデフォルトのバニティURLを編集し、Oracle WebCenter Sitesによって重複するバニティURLの作成が許可されます。したがって、自動生成されたURLはユーザーが生成したURLに変更され、ユーザーはそれらのURLを削除するか、別のURLにリダイレクトするかなどを決定できます。

ノート:

パターンを変更した場合、それが反映されるのはアセットを作成または保存するときのみです。パターンを変更した場合、または新しいパターンを作成した場合、それらはパターンを保存した後に作成されたアセットにのみ適用されます。

自動生成されるバニティURLを構成するには::

「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」ノードを開き、自動生成URLを作成する特定のアセット・タイプのノードを開きます。この特定のアセット・タイプのノードで「URLパターン」を開き、「新規追加」をダブルクリックします。

「URLパターン・フォーム」が表示されます。

図32-1 「URLパターン・フォーム」 - 「アセット」

「図32-1 「URLパターン・フォーム」 - 「アセット」」の説明

図32-2 「URLパターン・フォーム」 - 「Blob」

「図32-2 「URLパターン・フォーム」 - 「Blob」」の説明
「名前」フィールドにパターンの名前を入力します。この名前は一意で、このパターンを参照するためにのみ使用され、いつでも変更できます。

ノート:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、パーセント記号(%)、アンパサンド(&)、疑問符(?)、小なり記号(<)、大なり記号(>)およびバックスラッシュ(\)。
「パターン」フィールドに、バニティURLを定義するルールを入力します。使用可能な有効な属性と関数のリストが右側に表示されます。「URLパターンの使用」を参照してください。
「BLOBヘッダー」フィールド(Blobが選択されている場合のみ入力可能)に、バニティURLのBLOBヘッダーの定義に使用するルールを入力します。
「サイト」は、パターンが適用されるサイトで、アセット・タイプが有効である場所のみリストされます。サイトを選択しても、「ホスト」(WebRoot)、「サブタイプ」、「テンプレート」(アセットのみ)および「ラッパー」(アセットのみ)の選択を絞り込めます。

ノート:

このサイトでこのアセット・タイプが後から無効にされても、定義されているパターンは残ります。ただし、そのようなURLを使用すると、機能しないページが表示される可能性があります。
「ホスト」は、バニティURLが適用されるWebRootです。このサイトに定義されているWebRootまたは「任意」のみが表示されます。WebRootが存在しない場合、パターンは機能しません。
「サブタイプ」は、バニティURLが適用されるアセット・タイプのサブタイプです。「サブタイプ」を選択すると、「テンプレート」と「ラッパー」で選択できるアイテムが絞り込まれます。

ノート:

BLOBの「サブタイプ」フィールドには、フレックス・アセットのオプションとして「任意」は表示されません。BLOBの「サブタイプ」フィールドは、ベーシック・アセットの場合は表示されません。
「フィールド」は、このURLでレンダリングされるBLOBです。このフィールドは、BLOBが選択された場合のみ表示されます。アセットに複数のBLOBエントリが含まれる場合、複数のアイテムが表示される可能性があります。

「ダウンロード可能」チェック・ボックスを選択すると、このバニティURLにアクセスしたとき、ブラウザでは、ページ内にBLOBオブジェクトではなく保存ダイアログが表示されます。
「デバイス・グループ」には、定義されているデバイス・グループのリストが表示されます。このフィールドは、アセットが選択された場合のみ表示されます。デバイス・グループが、サイトにおける現在の状態に関係なく、拡張子に基づいてフォーマットされてリストに表示されます。デバイス・グループの詳細は、『Oracle WebCenter Sitesでの開発』のデバイス・グループと接尾辞についてに関する項を参照してください。
「テンプレート」はURLのテンプレートで、そのアセット・タイプ、サブタイプおよびサイトにあてはまるテンプレートはすべて、モバイル・バリエーションの存在に関係なく、表示されます。有効であるすべてのテンプレートが表示されますが、すべてのテンプレートに、指定された「デバイス・グループ」用のバリエーションがあるとはかぎりません。デフォルトでないデバイス・グループを使用する場合、適切なバリエーションが存在することを確認するのは、管理者の仕事です。
「ラッパー」には、「テンプレート」で選択したテンプレートで有効なすべてのラッパー要素のリストが表示されます。1つも存在しない場合、このフィールドは無効になります。
ここで、「保存」をクリックしてパターンを保存して作業を続行するか、URLパターンを評価できます。

フォームの「URLパターンの評価」セクションには、パターン生成されたバニティURLがどのようなものか、例が表示されます。パターンを検証するために保存する前に、URLパターンを評価することをお薦めします。

ノート:

該当するタイプのアセットがない場合、この機能は使用できません。
「アセット」リストでは、パターン・タイプに現在定義されているアセットを選択できます。アセット・タイプの名前を入力するために、「先読み」機能も使用できます。アセットを選択すると、WebCenter Sitesは作成されたパターンを評価し、このアセットのURLがどのように表示されるかを示します。これは、URLの最終的な見かけのほんの一例です。パターンが保存され、アセットが編集、保存されるまで、URLは有効になりません。

WebRootsの使用

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の長所と短所をリストします。

表32-1 WebRootの各タイプの利点と欠点

WebRootタイプ	長所	短所
絶対WebRoot	コンテンツ・コントリビュータに対してURL全体が表示される	すべての環境に固有のURLが必要仮想ルートを使用するためにWebCenter Sitesのプロパティを設定する必要がある。パブリッシュの前にバニティURLをテストすることは困難。
相対WebRoot	すべてのシステムを通じて1つのWebRootで動作するパブリッシュの前にバニティURLを簡単にテストできる	コンテンツ・コントリビュータには、URL全体ではなく、パスのみが表示される。場合によってはURLをリライトするステップを実行する必要がある
組合せ	コンテンツ・コントリビュータに対してURL全体が表示されるすべてのシステムを通じて1つのWebRootで動作するパブリッシュの前にバニティURLを簡単にテストできる	使用するURLの数が増え、それらを格納/パブリッシュする必要がある。コンテンツ・コントリビュータには相対WebRootと絶対WebRootの両方のURLが表示される。URLの数が増えるので、コンテンツ・コントリビュータが混乱する可能性がある。

URLに必要なWebRootsの様々なタイプ: 例

次の例では、この章の冒頭で示したバニティ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を作成するには::

「一般的な管理」ツリーで、「管理」ノード、「WebRoots」ノードの順に展開し、「新規追加」をダブルクリックします。

次の図に示すように、WebRoot編集フォームが開きます。ただし、すべてのフィールドは空白です。

図32-3 WebRoot編集フォーム

「図32-3 WebRoot編集フォーム」の説明
「ホスト名」フィールドに名前を入力します。

この名前がWebRootインスタンスの一意の識別子になります。描画タグでそれを使用して、アセットの固有のバニティURLを取得できます。WebRootを保存した後でこの値を変更することはできません。

ノート:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

「ルートURL」フィールドにURLを入力します。

ルートURLの値は、絶対と相対のいずれかです。絶対WebRootの場合、通常、これは、配信環境でアセットをレンダリングするために使用されるURLです。相対WebRootの場合、これは/<Optional PATH Prefix>です。

コンテンツ・コントリビュータにとって、これは定義されているバニティURLを表示する際に接頭辞として使用するURLです。次の表のルートURLの例を参照してください。

表32-2 ルートURLの例

絶対ルートURL...	相対ルートURL...
本番URL: http://www.example.com 完全なバニティURL: http://www.example.com/Running/Home	本番URL: http://www.example.com/Prefix 完全なバニティURL: http://www.example.com/Prefix/Running/	本番URL: http://www.example.mobi 完全なバニティURL: http://www.example.mobi/Running/Home	本番URL: /<context>/example 完全なバニティURL: http://<Current Host Name>/<context>/example/Running/Home	本番URL: / 完全なバニティURL: http://<Current Host Name>/Running/Home

絶対ルートURL...

相対ルートURL...

ホスト名のみの使用

ホスト名と接頭辞の両方をパスに使用

モバイル・サイトのホスト名の使用

使用

本番URL: http://www.example.com

完全なバニティURL: http://www.example.com/Running/Home

本番URL: http://www.example.com/Prefix

完全なバニティURL: http://www.example.com/Prefix/Running/

本番URL: http://www.example.mobi

完全なバニティURL: http://www.example.mobi/Running/Home

本番URL: /<context>/example

完全なバニティURL: http://<Current Host Name>/<context>/example/Running/Home

本番URL: /

完全なバニティURL: http://<Current Host Name>/Running/Home

1つ以上の仮想URLを入力します。仮想URLは2つの部分から構成されます。

環境: 他の環境の識別子。wcs_properties.jsonファイルにsites.environment=<name>を設定して、環境を識別する必要があります。Adminインタフェースで、プロパティ管理ツールからこのプロパティを設定します。(手順の説明は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のコア・カテゴリのプロパティに関する項を参照してください)。
ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。

初期表示では、環境とルートURLを追加するための行が1つのみ存在します。「新規追加」ボタンをクリックすると、「環境」フィールドと「ルートURL」フィールドで構成される行が追加されます。

入力する仮想URLには、絶対ルートURLを使用する必要があります。次の表に、移入する必要がある仮想URLのフィールドを示します。

表32-3 仮想URLのフィールド

管理URL ホスト名と接頭辞の両方をパスに使用モバイル・サイトのホスト名の使用

管理URL	ホスト名と接頭辞の両方をパスに使用	モバイル・サイトのホスト名の使用
たとえば、管理URLがhttp://management.example.com/Running/Homeの場合、次のようにフィールドを移入します。環境: `management` ルートURL:`management.example.com` `sites.environment=management` in `wcs_properties.json` (このプロパティはプロパティ管理ツールを使用して設定します)。	たとえば、ステージングURLがhttp://staging.example.com/Running/Homeの場合は、次のようにフィールドを移入します。環境: `staging` ルートURL:`management.example.com` `wcs_properties.json`の`sites.environment=staging` (このプロパティはプロパティ管理ツールを使用して設定します)。	たとえば、開発(ポートを含む) URLがhttp://dev.example.com:8080/Running/Homeの場合、次のようにフィールドを移入します。環境: `dev` ルートURL:`dev.example.com:8080` `wcs_properties.json`の`sites.environment=dev` (このプロパティはプロパティ管理ツールを使用して設定します)。

たとえば、管理URLがhttp://management.example.com/Running/Homeの場合、次のようにフィールドを移入します。

環境: management
ルートURL:management.example.com
sites.environment=management in wcs_properties.json (このプロパティはプロパティ管理ツールを使用して設定します)。

たとえば、ステージングURLがhttp://staging.example.com/Running/Homeの場合は、次のようにフィールドを移入します。

環境: staging
ルートURL:management.example.com
wcs_properties.jsonのsites.environment=staging (このプロパティはプロパティ管理ツールを使用して設定します)。

たとえば、開発(ポートを含む) URLがhttp://dev.example.com:8080/Running/Homeの場合、次のようにフィールドを移入します。

環境: dev
ルートURL:dev.example.com:8080
wcs_properties.jsonのsites.environment=dev (このプロパティはプロパティ管理ツールを使用して設定します)。

ノート:

仮想ルートURLは、Contributorインタフェースでの表示には使用されません。これが使用されるのは、「環境」の値がwcs_properties.jsonのsites.environmentプロパティに設定されている値と一致する環境でWebページをレンダリングする場合のみです。

1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。

次の例では、「サイト」にavisportsを設定しています。これは、このサイトに固有のURLを使用しているためです。
すべての情報を追加したら、「保存」アイコンをクリックします。

WebRootが作成されます。

初めて作成した後のWebRootは、「管理」タブの「アセット・タイプ」ノードにアセット・タイプとして表示されます。

WebRootの表示

WebRootを表示するには::

「一般的な管理」ツリーで、「管理」ノード、「WebRoots」ノードの順に展開し、リスト内のWebRootをダブルクリックします。

WebRootの「コンテンツ」フォームが開き、そのWebRootの保存済の情報が表示されます。

図32-4 WebRootの「コンテンツ」フォーム

「図32-4 WebRootの「コンテンツ」フォーム」の説明

既存のWebRootの編集

既存のWebRootを編集するには::

「一般的な管理」ツリーで、「管理」ノード、「WebRoots」ノードの順に展開し、リスト内のWebRootをダブルクリックします。

WebRootの「コンテンツ」フォームが開きます。
WebRootを編集するには、「編集」アイコンをクリックします。

WebRoot編集フォームが開きます。

図32-5 WebRoot編集フォーム

「図32-5 WebRoot編集フォーム」の説明
「ホスト名」、「ルートURL」、「仮想ルートURL」および「サイト」の各フィールドに、保存されている情報が開きます。
「ホスト名」フィールドは、WebRootインスタンスの一意の識別子です。描画タグでこれを使用して、アセットの固有のバニティURLを取得できます。

「ルートURL」フィールドは、通常は、配信環境でアセットのレンダリングに使用するURLです。これは、コンテンツ・コントリビュータに対して表示されるURLです。

「仮想ルートURL」は2つの部分から構成されます。
- 環境: 他の環境の識別子。wcs_properties.jsonファイルにsites.environment=<name>を設定して、環境を識別する必要があります。Adminインタフェースで、プロパティ管理ツールからこのプロパティを設定します。(手順の説明は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のコア・カテゴリのプロパティに関する項を参照してください)。
- ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。
仮想URLをさらに追加するには、「新規追加」ボタンをクリックして、「環境」フィールドと「ルートURL」フィールドで構成される行を追加します。

1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。
すべての情報を追加したら、「保存」アイコンをクリックします。WebRootが更新されます。

WebRootの承認とパブリッシュ

WebRootは、他のアセットと同じ方法でパブリッシュ用に承認できます。

WebRootをプレビューした状態で、緑のチェック・マーク・アイコンをクリックします。
管理者は、WebRootを個別に承認してパブリッシュする必要があります。WebRootはブロッキング・アセットとして設定されることはありません。

URLパターンの使用

自動パターンは、バニティURLの中心的存在です。ただし、管理者がパターン一致させたURLは、多くの場合、サイトに存在するバニティURLの大部分を構成します。パターンはパスと変数を組み合せた形式であり、変数はアセットから取得するフィールドまたは事前定義済関数です。

ノート:

URLのすべての部分は、保存する前にURLとしてエンコードされます。

存在する実際の変数は、選択されているアセット・タイプに応じて異なりますが、すべてのアセット・タイプで共有される共通変数が存在します。次の表に、最も一般的な変数を示します。

表32-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の作成に役立つ事前定義済関数が用意されています。

機能をクリックすると、パターン・フィールドの後に表示されます。

カーソルがどこにあっても違いはなく、新しいパターンは常に最後のアイテムです。次の表に、事前定義済関数のリストを示します。

事前定義済関数	説明
`spaceToUnderscore(java.lang.String)`	空白を_に変換します。たとえば、`Page 001`が`Page_001`になります。
`formatDate(java.util.Date, java.lang.String)`	日付を数字とスラッシュを使用した形式にフォーマットします。たとえば、updatedateが"Thu Feb 28 12:57:12 UTC 2013"である場合、`formatDate`関数を使用して"2/28/2013"と表示できます。使用する文字列は、Javaの`SimpleDateFormat`関数で使用する文字列と一致する必要があります。
`spaceToDash(java.lang.String)`	空白を-に変換します。たとえば、`Page 001`が`Page-001`になります。
`listAsPath(java.util.List, int)`	配列を、その先頭のx個のアイテムのリストに変換します。たとえば、`[1, 2, 3 ,4, 5, 6]`という配列に対してlistAsPathをx = 4で使用すると、`1\2\3\4`というリストが生成されます。 x (intで定義)は必須です。
`getFileName(com.fatwire.assetapi.data.BlobObject)`	BLOBオブジェクトのファイル名をテキストとして取得します。たとえば、BLOBの名前が`xyz.png`である場合、テキストxyz.pngを返します。通常は、これを一番最後に使用して、正しいファイル拡張子を指定します。この関数は、アセット・メーカー・アセットのバイナリ・フィールドには使用できません。
`property(java.lang.String, java.lang.String, java.lang.String)`	`ini`ファイルまたはプロパティ・ファイルからプロパティを読み込みます。これは、`ics.GetProperty`を使用します。このメソッドのパラメータは、1)プロパティ名、2)プロパティがない場合はデフォルト値、3)ファイル名のカンマ区切りリストです。

関数は、${f:<name>(<variables>)}という形式で指定します。したがって、前述のspaceToUnderscoreの例の関数は次のように記述します。

${f:spaceToUnderscore("Page 001")}

記述が正しくない場合、または無効なパラメータを渡した場合、「URLパターンの評価」セクションで、パスの該当する部分にはNULLが返されます。最も外側の変数のみ${}を使用する必要がありますが、すべての関数は先頭にf:を指定する必要があります。

パターンの使用

ここでは、avisports記事アセット・タイプに基づいて例を示します。アセット名は、"Baker Likely to Stay With Stars"です。

図32-6 「URLパターン・フォーム」 - 「アセット」

「図32-6 「URLパターン・フォーム」 - 「アセット」」の説明

ノート:

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パターンのパブリッシュについて

パターンは、アセット・タイプとともに自動的にパブリッシュされます。URLパターンの場合、特に承認またはパブリッシュする必要はありません。

バニティURLへのリダイレクトの無効化

開発者は、一部のインスタンスのバニティURLの一時的な無効化が必要になります。たとえば、開発者はテスト・インスタンスをバニティURLにリダイレクトしない場合があります。WebCenter SitesのバニティURLへのリダイレクトは、JVMパラメータを設定することで無効化できます。

アプリケーション・サーバーで、JavaオプションのJVMパラメータとして-Dsites.disablevanityurlオプションを設定します。

たとえば、

JAVA_OPTIONS=$JAVA_OPTIONS -Dsites.disablevanityurl="true"

システム・ツールによるバニティURLの使用

たとえば、多くの場合、管理者は競合を解決するためにシステム全体で定義されているバニティURLを1箇所で表示しようとします。「システム・ツール」ノードを使用すると、管理者は現在定義されているすべてのバニティURLを表示して、URL競合を解決できます。次の各項の説明を参照してください。

すべてのバニティURLの表示

すべてのバニティURLを表示するには:

「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」ノードを開き、次に「システム・ツール」ノードを開きます。
「URL」をダブルクリックします。

「URLユーティリティ」フォームが開きます。

図32-7 「URLユーティリティ」フォーム

「図32-7 「URLユーティリティ」フォーム」の説明

このリストには、(すべてのサイトで)定義されているすべてのURLが表示されるので、用意されている検索ボックスを使用してフィルタすることによって、目的のURLを探す必要があります。このメニューから、バニティURLの手動による削除、問題の有無のチェック、競合の発生元の確認を実行できます。ただし、パターンに基づいて生成されたURLは、アセットが次回保存されたときに自動的に再生成されます。

バニティURL競合の解決

同じパスを持つバニティURLは(WebCenter Sites全体でも) 1つしか存在できないので、バニティURLは一意です。たとえば、2つのサイトがあり、各サイトにルール・パターン/Page/${name}が存在し、両方でページに同じ名前(たとえば"Home")を使用している場合、競合が発生します。

どちらのページであっても、先に保存したページは正常に保存されてバニティURLが作成されますが、後から保存したページはバニティURLの作成に失敗します。

この場合、システム・ツールを使用してバニティURLの作成を阻害する原因を特定し、必要に応じて既存のURLを削除して、新しいURLを作成できるようにする必要がある可能性があります。
この問題は、WebRootが特定のサイトに固有であることを保証することによって抑止できます。

リライタ・フィルタによるバニティURLの解決

バニティURLを解決する方法は2つあります。1つは、Webサーバーを使用してURLをリライトする方法です。もう1つは、開発時によく見られる、Webサーバーが存在しない場合のために設計された方法で、フィルタを使用します。

Sitesにはデフォルトで、サンプル・サイト専用のURLリライタ・フィルタが用意されています。このリライタ・フィルタは、任意のサイトでWebRootと組み合せて使用するように構成できます。このフィルタは、(先頭からの文字列一致に基づいて)フィルタを通過するすべてのコールをインターセプトし、バニティURLフィルタとしてWebCenter Sitesに渡します。

簡単に言えば、Webサーバー上にリライト・ルールが存在しなくてもバニティURLが動作するようにできます。このフィルタを使用する場合の主要な制限は、正しいURLがバニティURLとして処理されるように、コンテキスト・ルートと一意の接頭辞を持つ必要があるということです。

ノート:

"FSII"と"Avi"は、サンプル・サイトがインストールされる際に、URLリライト・フィルタ用に事前構成されるパラメータです。値はsite.prefixプロパティで設定されます。

リライタ・フィルタを有効にするには::

「一般的な管理」ツリーで、「管理」ノード、「WebRoots」ノードの順に展開し、「新規追加」をダブルクリックします。
WebRoot編集フォームが開きます。
WebRootを作成します。
「新しいWebRootの作成」を参照してください。
「管理」インタフェースで、「プロパティ管理ツール」を開き、site.prefixプロパティを検索します。(プロパティ管理ツールのアクセス手順は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のコア・カテゴリのプロパティに関する項を参照してください)。

図vanityurl_rewritefilter.pngの説明
新しく作成したWebRootを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がモバイル・ユーザーに利点をもたらすだけでなく、通常は固有のドメインとURLが存在するためです。Webサイトのモバイル・ページ用に固有のドメインとURLを設定するには、次のアイテムを実行します。

モバイル・ドメイン名用のWebRootを設定する必要があります。WebRootのルートURLには、モバイル・ドメイン名を使用する必要があります。
モバイル・デバイス・グループ用のバニティURLを作成する際、正しいホスト名を選択します。これにより、モバイル・ドメイン名用のリンクが正しく生成されることが保証されます。
WebサーバーのURLのリライトなど、他のすべてのステップは、WebRootの使用、バニティ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

ノート:

http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true

mod_rewriteによるバニティURLの処理

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の設定

mod_rewriteを設定するには:

httpd.confを編集し、次の行を非コメント化することによってmod_rewriteを有効にします。
```
LoadModule rewrite_module modules/mod_rewrite.so
```
httpd.confに次の行を追加して、リライト・エンジンを有効にします。
```
RewriteEngine On
```
デバッグ用に、mod_rewriteのロギングのみ有効にします(これは非常にコストの高い操作なので、デバッグ時のみ使用してください)。
```
LogLevel alert rewrite:trace6
```
httpd.confへの変更を保存します。これで、mod_rewriteが有効になります(ルールはなし)。Webサーバーの起動を確認します。

ノート:

はるかに簡単な構造とテストが可能な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

一般情報:

本番コンテキスト・ルート: /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つはSitesバニティURLフィルタ、もう1つはSitesリライト・フィルタです。リライト・フィルタを使用する場合、データはリライト・フィルタからバニティURLフィルタに透過的に渡されます。

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
```

mod_rewriteによる変換について

いくつかの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]

`RewriteRule —`	`^(.*)$`	`/<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1`	`[L]`
後に続くエントリが`mod_rewrite`ルールであることを示す文です。	正規表現で、次のように分割されます。 ^ — 行インジケータの開始 (.*) — 全テキスト一致選択インジケータ。カッコ内に記述すると、選択されたテキストが変数に保存されます。 `$` — 行インジケータの終了したがって、この式は、文字列の開始と終了の間にあるすべてのテキストを変数に保存することを示します。	バニティURLのWebCenter Sitesコンテキスト・ルート、フィルタおよびパスで、次のように分解されます。 `/<context>/Sites` — Sitesコンテキスト・ルート(`cs`)およびバニティURLフィルタ(`Sites`) `?` — この後に続くパラメータが問合せパラメータであることを示す `lookuphost=http://www.example.com` `lookuphost` — バニティURLフィルタにWebRootの名前を提供 `http://www.example.com` — 本番サーバーのWebRoot (絶対WebRoot)	`mod_rewrite`にルールの終了を通知します。すべての`mod_rewrite`ルールは、最後にこれを記述する必要があります。

後に続くエントリがmod_rewriteルールであることを示す文です。

正規表現で、次のように分割されます。

^ — 行インジケータの開始
(.*) — 全テキスト一致選択インジケータ。カッコ内に記述すると、選択されたテキストが変数に保存されます。
$ — 行インジケータの終了

したがって、この式は、文字列の開始と終了の間にあるすべてのテキストを変数に保存することを示します。

バニティURLのWebCenter Sitesコンテキスト・ルート、フィルタおよびパスで、次のように分解されます。

/<context>/Sites — Sitesコンテキスト・ルート(cs)およびバニティURLフィルタ(Sites)
? — この後に続くパラメータが問合せパラメータであることを示す
lookuphost=http://www.example.com
- lookuphost — バニティURLフィルタにWebRootの名前を提供
- http://www.example.com — 本番サーバーのWebRoot (絶対WebRoot)

mod_rewriteにルールの終了を通知します。すべてのmod_rewriteルールは、最後にこれを記述する必要があります。

mod_rewriteによるWebCenter Sitesフィルタの使用

次のルールは/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

問合せパラメータを処理するには、次のようにします。

mod_rewrite組込み変数"%{QUERY_STRING}"を使用して、/<context>/Sites? lookuphost=http://www.example.com& lookuppage=$1ルールを更新します。
更新後:
```
/<context>/Sites? lookuphost=http://www.example.com& lookuppage=$1&%{QUERY_STRING}
```
問合せパラメータを渡さないURLの場合、%{QUERY_STRING}は空になります。したがって、前述の3つのURLに加えて、次のURLも処理できます。
今度は次の開発URLについて考えます。
```
http://dev.example.com:8080/Running/Home
```
これを、次のようにしてバニティURLフィルタに渡す必要があります。:
```
lookuphost=/<context>/Avi&/<context>/Sites?lookuppage=/Running/Home
```
mod_rewriteは、デフォルトではホストとポートを処理しないので(この情報を含む専用パラメータが存在します)、リライト・ルールは次のルールによく似たものになります。
```
RewriteRule ^(.*)$ /<context>/Sites?lookuppage=$1&lookuphost=/<context>/Avi [L]
```
この場合、開発では相対WebRootを利用するので、名前を調整する必要があります。URLの残りの部分は変更されないため同じルールが適用されます。

mod_rewriteによるリライタ・フィルタの使用

リライト・フィルタを使用する場合、バニティURLフィルタの場合のようにURLを分割する必要はありません。かわりに、Sitesコンテキスト・ルートおよびリライタ・フィルタ接頭辞がURLに追加されます(これはバニティURLの導入前のWebCenter Sitesを使用する場合とよく似ています。したがって、既存のルールは、バニティURLをサポートするように簡単に変更できます)。

次の例では、URLとしてhttp://www.example.com/Page/Surfingを使用しており、これは/<context>/AVISPORTS/Page/Surfingになります。

前述のURLを処理するには、次のmod_rewriteルールを新しく作成します。
```
RewriteRule ^(.*)$ /<context>/AVISPORTS$1 [L]
```
このルールは、単純に渡されたものを受け取り、その先頭に/<context>/AVISPORTSを追加します。

同じルールで次も処理できます。
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars およびhttp://www.example.com/Home
http://www.example.com/Home?time=trueを処理するために、ルールに%{QUERY_STRING}パラメータを追加するため、次のようになります。
```
RewriteRule ^(.*)$ /<context>/AVISPORTS$1?%{QUERY_STRING}  [L]
http://www.example.com/Home?time=true 
```

mod_rewriteによる静的コンテンツの使用

mod_rewriteとバニティURLを使用する場合の問題の1つが、既存のCSSと静的イメージのアクセスです。通常、これらはアプリケーション・サーバー上またはWebサーバー上にある、サイトと同じ名前のディレクトリに格納されます。多くの場合、リライト・ルールによって、それらにアクセスできなくなります。

次の例を使用し、CSSファイルは、AVISPORTS_STATICという名前のディレクトリに格納されているものとします。
```
http://www.example.com/Page/Surfing 
```
これを処理するには、2つ目のmod_rewriteルールを作成します。このルールを前述のルールの前に置くことによって、このディレクトリへのコールがリライトされないことを保証します。
これは、次のように記述できます。
```
RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /<context>/<site-prefix>/$1 [L,PT].
```
これらの2つのルールを使用して、1つ目のルールですべての静的ページとCSSがバニティURLに変換されないことを保証し、2つ目のルール(mod_rewriteによる変換についてで構築)で残りのURLをバニティURLフィルタに送信します。
```
RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /<context>/<site-prefix>/$1 [L,PT]
RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1&%[QUERY STRING} [L]
```

バニティURLのカスタマイズ

WebCenter Sitesでは、動的に設定できるように、自動生成されるバニティURLをカスタマイズできます。

アセットを保存する前に、事前定義済の場所にカスタム要素が存在するかがチェックされます。優先順位に応じて、次のカスタム要素の存在がチェックされます。

CustomElements/VanityUrl/sitename/assettype/ModifyWebrefs
CustomElements/VanityUrl/assettype/ModifyWebrefs
CustomElements/VanityUrl/sitename/ModifyWebrefs
CustomElements/VanityUrl/ModifyWebrefs

ここで、sitenameはユーザーがログインしているサイトの名前で、assettypeは保存されるアセットのタイプです。

カスタム要素が見つかると、そのカスタム要素が実行されます。

ノート:

優先順位に応じて、1つの要素のみ実行されます。

表32-5では、要素スコープで使用できる2つのオブジェクト(assetDataおよびwebrefs)について説明します。

表32-5 assetDataおよびwebrefsの説明

オブジェクト	説明
assetData	アセットの現在のデータを含むassetDataのインスタンス。
webrefs	webreferenceのインスタンスのリスト。現在のアセットの自動生成済webreferencesのリストが含まれます。戻りオブジェクトとしても動作します。このオブジェクトによって渡されるすべてのwebreferencesがアセットに割り当てられます。

カスタマイズされたバニティURLの作成

次の例では、カスタマイズされたバニティURLの作成方法について説明します。

avisportsサイトのアセット・タイプAVIArticleでは、AVIArticleアセットのカテゴリおよびアセットIDのバニティURLを追加しようとしているとします。次のステップによって、このカスタマイズされたURLを作成できます。

管理UIで、「一般的な管理」ツリーにナビゲートします。「管理」ノードで、「アセット・タイプ」を開き、カスタマイズされたバニティURLを作成するためのアセット・タイプを開きます。次の図に示すように、この例では「AVIArticle」になります。
次の図に示すように、URLパターンを作成します。ステップの詳細は、「バニティURLの生成」を参照してください。
アセット用に静的URLを作成するための試行が行われます。

図32-8 URLパターンの作成

「図32-8 URLパターンの作成」の説明
新しい要素「CustomElements/VanityUrl/avisports/AVIArticle/ModifyWebrefs」を作成します。この例では、次の図に示すように、Sites Explorerを使用してGroovy要素を作成しています。

図32-9 Sites Explorerを使用したGroovy要素の作成

「図32-9 Sites Explorerを使用したGroovy要素の作成」の説明

要素に次の行を追加して保存します。

/* 
* This element is invoked during asset save. It lets users to edit the webreferences for the asset. Following objects are available in ics scope when this element is called
* assetData - updated values of the asset that is being saved 
* webrefs   - list of auto generated webreferences for this asset (input/output)
* 
* Webreferences available in ics will be associated with current asset being saved. Any changes to assetData object are ignored. 
*/

import com.fatwire.assetapi.data.* 
import java.util.*

String token = "__my_custom_url__" 

// get the asset data and form the vanity url based on asset data 
AssetData aData = AssetData.class.cast(ics.GetObj("assetData"))
String category = aData.getAttributeData("category").getData()[0]
String id = String.valueOf(aData.getAssetId().getId())
String url = category+"/"+id 

// get the auto generated webreferences and iterate over the list
List webrefs = List.class.cast(ics.GetObj("webrefs"))
Iterator it = webrefs.iterator()
while(it.hasNext())
{ 
	WebReferenceImpl webref = 
WebReferenceImpl.class.cast(it.next())
	// replace existing token with asset data
	if(webref.getAssetUrl().equals(token)) {
		webref.setAssetUrl(url)
	} 
}

このコードでは、現在のアセットのAssetDataを読み込み、icsオブジェクトから自動生成済webreferencesを読み込みます。AssetDataからカテゴリおよびアセットIDを読み込み、新しいURLを動的に作成します。次に、すべてのwebreferencesをループして静的トークンを検索し、新しく作成したURLで置き換えます。

ノート:

assetDataオブジェクトに対する変更は、アセットに影響を及ぼしません。webrefsオブジェクトでwebreferencesを追加、削除または更新できます。webrefsオブジェクトによって渡されるすべてのwebreferencesが現在のアセットに割り当てられます。

アセットに割り当てられたカスタム・バニティURLを参照するために、サイトavisportsのArticleアセットを編集および保存します。