ポータルアプリケーションを追加する

受信トラフィックを特定のバックエンドサーバーにルーティングするために、ヘッダーベースのアプリケーションを作成し、構成します。

Access Gatewayアプリケーションは、ポリシーと特別なポリシー構成を使用してポータルアプリケーションを作成できます。ポータルは、アクセスポリシーとURIリクエストに基づき、特定のバックエンドサーバーに一部のトラフィックを誘導し、残りのトラフィックを別のバックエンドサーバーに誘導します。

アーキテクチャ

ユーザーがリソースを要求すると、ポータルはリクエストを受け取り、適切なバックエンドサーバーにルーティングします。各リクエストは、コアURL（www.myportal.com）と、コアURLに続く要素である特定のリソース（アーキテクチャの図の/2ndを参照）から構成されます。

アーキテクチャの図で示したように、www.myportal.com/2ndへのリクエストは2ndbackend.myportal.comにルーティングされます。同様に、www.myportal.com/3rdへのリクエストは3rdbackend.myportal.comにルーティングされます。それ以外のリクエストは、backend.myportal.comにルーティングされます。

書き換え

ポータルアプリケーションは、複数のバックエンドサーバーへのアクセスを定義するために、カスタムポリシーおよび構成を使用します。デフォルトポリシーは、他のポリシーに該当しないURIを、デフォルトのバックエンドアプリケーションにリダイレクトします。追加のポリシーステートメントとその設定は、リクエストを書き換え、リクエストを特定のバックエンドアプリケーションにリダイレクトするために使用されます。

この表は、期待される動作を満たすために、ユーザーリクエストがどのように書き換えられるかの例を示しています。

ユーザーリクエスト	期待される動作	インバウンドおよびアウトバウンドの書き換え
myportal.com/	backend.myportal.comにリダイレクトされます。	backend.myportal.com myportal.com/
myportal.com/abc.htm	backend.myportal.com/abc.htmにリダイレクトされます。	backend.myportal.com/abc.htm myportal.com/abc.htm
myportal.com/2nd	/2ndに基づき2ndbackend.myportal.comにリダイレクトされます。	2ndbackend.myportal.com myportal.com/2nd
myportal.com/2nd/efg.html	/2ndに基づき2ndbackend.myportal.comにリダイレクトされます。インバウンドの書き換えについて、文字列から/2ndを削除します。アウトバウンドの書き換えについて、/2ndを文字列に追加して戻します。	2ndbackend.myportal.com/efg.htm myportal.com/2nd/efg.htm
myportal.com/3rd	/3rdに基づき3rdbackend.myportal.comにリダイレクトされます。	3rdbackend.myportal.com myportal.com/3rd
myportal.com/3rd/hij.html	/3rdに基づき3rdbackend.myportal.comにリダイレクトされます。インバウンドの書き換えについて、文字列から/3rdを削除します。アウトバウンドの書き換えについて、/3rdを文字列に追加して戻します。	3rdbackend.myportal.com/hij.htm myportal.com/3rd/hij.htm

ポリシー

デフォルト

デフォルトポリシーは、他の特定のポリシーと一致しないすべてのリクエストに適用されます。デフォルトポリシーによって、リクエストはデフォルトアプリケーションドメインに対して書き換えられ、その後バックエンドアプリケーションに転送されます。リクエストが処理された後、結果は元のドメインに書き戻され、返されます。

/2ndへのリクエストのポリシーの書き換え

後続の各バックエンドには、必要に応じてリクエストを書き換えるためのポリシーと高度な構成が含まれています。この例では、ポリシーは、書き換えをトリガーするルートURIとして/2ndを指定します。書き換えルールはURIを削除し、リクエストをセカンダリバックエンドアプリケーション（2ndbackend.myportal.com）にリダイレクトします。

/3rdへのリクエストのポリシーの書き換え

後続の各バックエンドには、必要に応じてリクエストを書き換えるためのポリシーと高度な構成が含まれています。この例では、ポリシーは、書き換えをトリガーするルートURIとして/3rdを指定します。書き換えルールはURIを削除し、リクエストをセカンダリバックエンドアプリケーション（3rdbackend.myportal.com）にリダイレクトします。

開始する前に

アプリケーションで使用される外部URLを決定します。この例では www.myportal.comです。
可能性のあるURIとバックエンドの組み合わせを決定します。サンプルのアーキテクチャは以下の組み合わせを使用しています。
- www.myportal.com/2nd > 2ndbackend.myportal.com
- www.myportal.com/3rd > 3rdbackend.myportal.com
他のすべてのURIはバックエンドにbackend.myportal.comを使用しています。
認証で必要なすべての必須のヘッダー属性を決定します。

一般的なワークフロー

タスク	説明
包含するグループを作成する	アプリケーションに割り当てる任意のグループを作成します。
ヘッダーアプリケーションを作成する	共有された共通バックエンドをデフォルトとするヘッダーアプリケーションを作成します。
ポータルアプリケーションに証明書を割り当てる	任意の証明書をアプリケーションに割り当てます。
その他の属性を追加する	（任意ですが、多くは必須の）その他の属性をアプリケーションに追加します。
必要なアクセスポリシーを追加する	すべてのサービスURIに対して必要なすべてのポリシーを追加します。
アプリケーションをテストする	ヘッダーおよびポリシーシミュレーションを使用してアプリケーションをテストします。