Dispatcher バニティ URL | AEM
このドキュメントでは、Adobe Experience Managerでのバニティ URL の処理方法と、書き換えルールを使用してコンテンツを配信のエッジに近づけるなどの追加手法を説明します。
説明 description
環境
Adobe Experience Manager
問題/症状
AEMではバニティ URL をどのように扱いますか？ 配信のエッジに近いコンテンツをマッピングする追加の手法はありますか？
バニティ URL とは
意味のあるフォルダー構造に存在するコンテンツがある場合、参照しやすい URL に存在しないことがあります。 バニティ URL はショートカットのようなものです。 実際のコンテンツが存在する場所を参照する短い、または一意の URL。
例：/content/we-retail/us/en/about-us.html を指す/aboutus
AEM オーサーには、AEM内のコンテンツの 1 つにバニティ URL プロパティを設定して公開するオプションが用意されています。
この機能を使用するには、バニティを許可するように Dispatcher フィルターを調整する必要があります。 作成者がこれらのバニティページエントリの設定に必要となる割合で Dispatcher 設定ファイルを調整する際には、これによって無理が生じます。
このため、Dispatcher モジュールには、コンテンツツリーにバニティとしてリストされるすべての項目を自動許可する機能があります。
解決策 resolution
仕組み
バニティ URL の作成
作成者がAEMのページにアクセスしてページのプロパティを閲覧し、「バニティ URL」セクションにエントリを追加します。
変更を保存してページをアクティベートすると、バニティがこのページに割り当てられます。
タッチ UI:
クラシックコンテンツファインダー :
メモ： これは名前空間の問題に対して非常に脆弱であることを理解してください。 バニティエントリはすべてのページに対してグローバルです。これは、回避策を計画する必要がある欠点の 1 つにすぎません。 その一部については、後ほど説明します。
リソースの解決/マッピング :
各バニティエントリは、内部リダイレクトの Sling マップエントリです。 これらのマップは、AEM インスタンスの Felix コンソール（/system/console/jcrresolver）に表示されます。
バニティエントリによって作成されたマップエントリのスクリーンショットを次に示します。
上記の例では、AEM インスタンスにへのアクセスを指示す /aboutus と、/content/we-retail/us/en/about-us.html に解決されます。
Dispatcher自動許可フィルター :
安全な状態のDispatcherは、JCR ツリーのルートであることが理由で、Dispatcher経由で/へのリクエストを除外します。
パブリッシャーが、/content や他の安全なパスなどからのコンテンツを許可し、/system などのパスからのコンテンツを許可していないことを確認するのが重要です。
以下は、のベースフォルダーに格納されているバニティ URL です。安全を確保しながらパブリッシャーにどう到達できるでしょうか。
シンプルな Dispatcher には自動フィルターの許可メカニズムが備わっており、AEM パッケージをインストールしてから、そのパッケージページを指すようにDispatcherを設定する必要があります。 AEM パッケージについては、 こちらを参照してください。
Dispatcherのファームファイルには、設定セクションがあります。
/vanity_urls { /url "/libs/granite/dispatcher/content/vanityUrls.html"
/file "/tmp/vanity_urls" /delay 300 }
この設定では、300 秒ごとにAEM インスタンスからこの URL を取得し、許可する項目のリストを取得するようにDispatcherに指示されます。
応答のキャッシュを/file 引数（この例では/tmp/vanity_urls）に保存します。
そのため、URI でAEM インスタンスにアクセスすると、そのインスタンスが取得する内容が表示されます。
これは非常にシンプルなリストです。
バニティルールとしてのルールの書き換え
上述のように、AEMに組み込まれているデフォルトのメカニズムの代わりに、書き換えルールを使用することが挙げられるのはなぜでしょうか。
名前空間の問題、パフォーマンス、より適切に処理できる高レベルのロジックについて簡単に説明されています。
これを実行するために Apache の mod_rewrite モジュールを使用して、/content/we-retail/us/en/about-us.html のコンテンツに /aboutus するバニティエントリの例を見てみましょう。
RewriteRule /aboutus /content/we-retail/us/en/about-us.html PT,L,NC
このルールはバニティ /aboutus を探し、PT （Pass Through）フラグを使用してレンダラーからフルパスを取得します。
また、他のすべてのルール L （Last）フラグの処理が停止します。つまり、JCR Resolving などの大量のルールリストをトラバースする必要がなくなります。
リクエストをプロキシする必要なく、AEM パブリッシャーがこのメソッドのこれらの 2 つの要素に応答するのを待つことで、パフォーマンスが大幅に向上します。
さらに良いのは、NC フラグ（大文字と小文字を区別しない）です。つまり、URL を /aboutus の代わりに /Aboutus で入力しても、引き続き機能し、適切なページを取得できます。
これを実行するために書き換えルールを作成するには、Dispatcherに設定ファイル（例：/etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules）を作成し、これらのバニティ URL を適用する必要があるドメインを処理する .vhost ファイルに含めます。
以下に、内部の Include のコードスニペットの例を示します。
/etc/httpd/conf.d/enabled_vhosts/we-retail.vhost
VirtualHost *:80 ServerName weretail.com ServerAlias
www.weretail.com ........ SNIP ........ IfModule mod_rewrite.c
ReWriteEngine on LogLevel warn rewrite:info
Include /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules / IfModule
........ SNIP ......../VirtualHost
使用する方法と場所
A. バニティエントリの制御にAEMを使用すると、次のメリットがあります。
- 作成者はその場で作成できます
- コンテンツと共に存在し、コンテンツと共にパッケージ化できる
B. バニティエントリの制御に mod_rewrite を使用すると、次のメリットがあります。
- コンテンツの解決を迅速化
- エンドユーザーコンテンツリクエストのエッジに近い
- 他の条件でのコンテンツのマッピング方法を制御するための拡張性とオプションの増加
- 大文字と小文字を区別しない場合がある
C.両方の方法を使用しますが、どちらをいつ使用するかについてのアドバイスと条件は次のとおりです。
- バニティが一時的なもので、予定されているトラフィックレベルが低い場合は、AEMの組み込み機能を使用します
- バニティが頻繁に変更されず、頻繁に使用されるステープルエンドポイントの場合は、
mod_rewriteルールを使用します。 - バニティ名前空間（例：
/aboutus）を同じAEM インスタンス上の多数のブランドで再利用する必要がある場合は、書き換えルールを使用します。
メモ： AEM バニティ機能を使用してネームスペースを避ける場合は、命名規則を作成できます。 /brand1/aboutus, brand2/aboutus, brand3/aboutus のようにネストされたバニティ URL の使用