| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.2.0) E82735-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.2.0) E82735-01 |
|
|
前 |
次 |
この章の内容は次のとおりです。
この項では、ページレット・プロデューサの概念と機能の概要について説明します。ページレット・プロデューサの使用方法と、その基になるアーキテクチャおよびコンポーネントについて説明し、重要な概念を紹介します。
この項には次のトピックが含まれます:
ページレットは、再使用可能なユーザー・インタフェース・コンポーネントです。任意のHTMLフラグメントをページレットにできますが、ページレット開発者は、パラメータ化され、その他のページレットと動的にやり取りしたり、ユーザー入力に応答するように構成可能なページレットを記述することもできます。ページレットは、ポータルやその他のWebアプリケーション内など、任意のWebページで実行できます。ページレットを使用すれば、他のWeb環境でプラットフォーム固有のポートレットを公開できます。Oracle WebCenter Portalのページレット・プロデューサ(旧Oracle WebCenter Ensemble)は、動的なページレット開発を容易にする有用なツールと機能のコレクションを提供します。
ページレット・プロデューサにより、既存のWebインフラストラクチャを新しい方法で使用できるようにすることで、このインフラストラクチャへの投資を活用できます。ページレット・プロデューサによって、次のものを利用できます。
デフォルトで統合APIやポートレットを公開しないアプリケーションのWeb UI
WSRP (JSR-168またはJSR-286)、Oracle PDK-Java、CSP、WebPartsなどの標準ポートレット
また、Web UIをWebCenter Portal、WebCenter SitesまたはほとんどのHTMLページに配信でき、さらに、ページレット・プロデューサ・リソースに対するロールベースのアクセス制御や、HTMLマークアップの解析、クリッピング、挿入およびイベント処理(ページレット間の通信)によるWebリソースのリバース・プロキシも可能になります。
ページレット・プロデューサでは、次のものが提供されます。
既存のWeb UIを利用し、それをページレットという移植可能なコンポーネントとして再利用するためのツール
ポートレットの標準をサポートしない非標準または非コンプライアンス・コンテナおよびコンポーネントを統合するための代替手段。たとえば、次の操作が可能です。
ポートレットを公開しないWebアプリケーションから機能を取得します
既存のWSRP、Oracle PDK-JavaまたはContent Syndication Protocol (CSP)ポートレットを非ポータル設定で使用できるようにします
HTMLマークアップを変更するためのインジェクタとパーサー
ページレット間の通信およびイベント処理用のJavaScriptフレームワーク
この項では、ページレット・プロデューサのアーキテクチャと主要コンポーネントについて説明します。
この項には次のトピックが含まれます:
図14-1に、ページレット・プロデューサのコンポーネントとその相互作用の概念図を示します。また、図14-1には、ページレット・リクエストがページレット・プロデューサ内でどのように処理されるかも反映されています。リクエストは、受信リクエストをリソースにマップするプロキシ・サーブレットによって受信されます。次に、リクエストは認証されます。リクエストされたリソースにユーザーがアクセスできる場合、ページレットの処理は、バックエンド・システムからHTMLマークアップをリクエストすることによって開始されます。受信したマークアップは、定義済のクリッパやパーサーなどを使用して変更されます。
図14-2に、コンポーネントの相互作用を異なる見方で示します。
A: ページレット・プロデューサ・アプリケーションがJ2EEアプリケーション・サーバー上で実行されます。ページレット・プロデューサにはWebCenterスキーマは必要ありませんが、MDSインスタンス(通常はWebCenterと共有されている)は必要です。
B: ユーザーがページレットを含むWebCenter Portalページをコールします。
C: WebCenter Portalによってページが返され、さらにページレットをレンダリングするためのページレット・プロデューサをコールするJavaScriptが返されます。
D: JavaScriptによってページレット・プロデューサへのレンダリング・コールが行われます。
E: ページレット・プロデューサでは、外部(E1)または内部(E2) WebアプリケーションをHTMLコンテンツのソースとしてコールできます。ページレット・プロデューサによってコンテンツが変換され(つまりURLがリライトされ)、ページに挿入できるようブラウザに返されます。ページレット・プロデューサ自体には、外部から(つまり、DMZ内で)アクセスできます。
ページレット・プロデューサの使用時に役立つ主要概念は、次のとおりです。
リソースは、スタンドアロンのWebアプリケーション、ページレット・プロデューサ、OpenSocialコンテナなど、ページレット・プロデューサ内のアプリケーションを登録するために使用する主要オブジェクトです。リソースを作成すると、プロキシによる外部URLへの内部アプリケーションのマッピング、認証の管理およびアプリケーションの変換が可能になります。Webアプリケーションをページレット・プロデューサのリソースとして登録すると、次の操作ができるようになります。
外部アドレスへの内部Webアプリケーションのプロキシ。
プロキシ・レベルとリソース・レベルの両方における認証の管理
プロキシされたWebアプリケーションの変換(URLのリライトを含む)。
リソースの作成の詳細は、「リソースの作成」を参照してください
ページレットは、ページレット・プロデューサを通してアクセスするWebページのサブコンポーネントであり、プロキシされた任意のアプリケーションに挿入できます。ページレット・プロデューサのリソース上にあるアプリケーションでマークアップを返すものはページレットとして登録でき、登録すると、WebCenter Portalまたは他のWebアプリケーションで表示できるようになります。
どのようなHTMLフラグメントでもページレットにできます。ページレット開発者は、他のページレットと動的に相互作用し、Asynchronous Javascript and XML (AJAX)を使用してユーザー入力に対応する、パラメータ化され構成可能なページレットを作成できます。
ページレットの作成の詳細は、「ページレットの作成」を参照してください。
ページレット・プロデューサの登録は動的です。既存のプロデューサに対する追加および更新は、すぐに実行できます。ほとんどの場合、WebCenter Portalまたは管理対象サーバーを再起動する必要はありません。
ページレット・プロデューサ・コンソールは、ページレット・プロデューサのデプロイで様々なオブジェクトの作成と管理に使用されるブラウザ・ベース管理ツールです。このコンソールから、リソースとしてのWebアプリケーションの登録、ページレットの作成、プロキシおよび変換設定の管理などを行うことができます。
ページレット・プロデューサ・コンソールには、次のURLで任意のWebブラウザからアクセスできます。
http://<host>:<port>/pagelets/admin
ページレット・プロデューサ・コンソールは、次の場所からアクセシビリティ・モードで起動することもできます:
http://<host>:<port>/pagelets/admin/accessible
実行中、ページレット・プロデューサ・コンソールには、WebCenter Portalの「共有アセット」タブからアクセスすることもできます。
注意:
ページレット・プロデューサ・コンソールでは、標準の管理言語とオランダ語のみがサポートされています。これらの言語以外をブラウザの言語に構成すると、現在のサーバーに定義された言語に戻ります。
ページレット・プロデューサ・コンソールを使用したページレット・プロデューサの構成およびオブジェクトの作成の詳細は、「ページレット・プロデューサ設定の構成」および「ページレット・プロデューサ・オブジェクトの作成」を参照してください。ページレット・プロデューサ・コンソールを使用したプロデューサの登録およびページレット・データの移行の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサの管理に関する項を参照してください。
HTTPは通常WebページのコンテンツとXMLをサーバーとクライアント間で送信するために使用されるプロトコルです。Content Syndication Protocol (CSP)は、HTTPを拡張したオープン標準であるHTTP 1.1に基づく、プラットフォームに依存しないプロトコルで、ページレット・プロデューサと外部CSPリソース間の通信構文を定義します。
外部リソースのサービスは、CSPを使用してページレット・プロデューサと通信します。たとえば、ブラウザがページをリクエストすると、ページレット・プロデューサが各外部リソースに対する同時リクエストを作成し、ページからページレット・コンテンツを取得します。外部リソースは、現在のユーザーのプリファレンスをページレット・プロデューサから送信されたCSPヘッダーから読み取り、適切なHTMLを戻します。ページレット・プロデューサはHTMLをページ・マークアップに挿入します。イメージ・サービスに格納されたイメージは、ブラウザによって取得、表示されます。
この項には次のサブセクションが含まれます:
HTTP通信は、リクエストとレスポンスで構成されます。リクエストとレスポンスは、基本的にはヘッダー内のメタデータの名前/値ペアのリストで、オプションでボディが付いています。ボディは、送信されているデータ(HTMLページまたはXMLファイル)です。ヘッダー内のメタデータは、リクエストまたはレスポンス自体の情報(コンテンツを表示する言語、ブラウザがコンテンツをキャッシュする期間など)です。リクエストとレスポンスには、それぞれ、次に説明する固有の情報が含まれています。HTTPの詳細は、RFC 2616を参照してください(http://www.faqs.org/rfcs/rfc2616.html)。
クライアントはサーバーにHTTPリクエストを送信し、コンテンツを要求します。リクエスト・ボディは、POSTやPUTなど、サーバーにデータを送信するリクエストにのみ使用されます。
HTTPリクエストの形式:
[METHOD] [REQUEST-URI] HTTP/[VERSION] [fieldname1]: [field-value1] [fieldname2]: [field-value2] [request body, if any]
HTTPリクエストの例:
GET /index.html HTTP/1.1 Host: www.xmlns.oracle.com User-Agent: Mozilla/3.0 (compatible; Opera/3.0; Windows 95/NT4) Accept: */* Cookie: username=JoeSmith
サーバーは、ページ・コンテンツ、およびコンテンツのタイプ、ドキュメントの最終変更時期、サーバー・タイプなどの重要な詳細を含むHTTPレスポンスを返します。リクエストされたコンテンツが見つからない場合は、レスポンスにエラー・メッセージが含まれます。
HTTPレスポンスの形式:
HTTP/[VERSION] [CODE] [TEXT] [fieldname1]: [field-value1] [fieldname2]: [field-value2] [response body, if any (document content here)]
HTTPレスポンスの例:
HTTP/1.0 200 Found Last-modified: Thursday, 20-Nov-97 10:44:53 Content-length: 6372 Content-type: text/html <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 3.2 Final// EN'><HTML> ...followed by document content...
カスタムHTTPヘッダーを、特殊な情報を格納するように構成できます。
注意:
ヘッダー・サイズ制限は、コードをホストしているサーバーによって制御されます。IIS/ASPの標準制限は60Kです。Javaアプリケーション・サーバーの場合は2Kから10Kまでです。これらの制限は通常、構成可能です。詳細は、使用しているサーバーのドキュメントを参照してください。
サービスからも、Set-CookieヘッダーやHTTP 1.1 Basic認証ヘッダーなどの標準のHTTPヘッダーにアクセスできます。HTTPをさらに調べる場合は、ロギングを使用して、ブラウザとWebサーバー間でやり取りされるすべてのヘッダーを表示できます(「ページレットのデバッグ」を参照)。HTTPは、SSLとともに使用され、セキュアなコンテンツを提供します。また、シングル・サインオン(SSO)でもBasic認証用のHTTPヘッダーが使用されます。
Content Syndication Protocol (CSP)は、HTTPを拡張し、ページレット・プロデューサと外部CSPリソース(具体的にはOracle WebCenter Interactionポートレット)間で設定を渡すための専用ヘッダーを定義します。CSPでは、これらのサービスがHTTPを使用して設定を通信および変更する方法の概略を記述します。CSPプロトコルの最新バージョンは1.4で、次の場所から入手できます。
http://docs.oracle.com/cd/E13158_01/alui/wci/docs103/devguide/references/CSP1.4.pdf
システム変数とユーザー構成変数(表14-1を参照)の通信に使用されるカスタムCSPヘッダーは、ページレットでも使用できます。
表14-1 ページレット・プロデューサのヘッダー
| ヘッダー名 | 説明 |
|---|---|
ユーザーID |
現在ログインしているユーザーのユーザーID。この値は、セッションの有効期限を判別するときに使用できます。UserID=2の場合、デフォルトの'Guest'ユーザーがログインして、その他のユーザーのセッションはすべて終了します。 |
ユーザー名 |
ログインしているユーザーの名前。ユーザー名は、表示のパーソナライズやフォーム・フィールドの事前指定に使用できます。 |
イメージ・サービスのURL |
ページレット・プロデューサのユーザー実装での、イメージ・サービスの仮想ルート・ディレクトリのURL。この場所は、サービスで使用されるすべての静的イメージに使用する必要があります。 |
スタイルシートのURL |
現在のユーザーのスタイルシートのURL。ページレット・プロデューサの実装ごとに、UIがカスタマイズされます。一部のポータルでは、ユーザーはスタイルシートの中から選択できます。これらのスタイルを使用すると、ページレットが、現在のユーザーによるページレット・プロデューサの実装スタイルで表示されます。 |
ページレットID |
現在のリソース(ページレット)のID、および現在のページレットのインスタンスID。この値は、HTMLフォームおよびクライアント側JavaScript機能の名前に追加し、ページ上のフォームや機能の一意の名前を確保して名前の競合を回避するために役立ちます。 |
ホスト・ページのURL |
ページレットをホストするページのURL。設定の構成後にユーザーを正しいページに戻すために、プリファレンス・ページにはこのURLが必要です。この値を使用して、単一のページレットで様々なページに各種コンテンツを表示できるようにすることもできます。 |
ページレット・プロデューサはプロキシ・サーバーとして動作し、クライアント・コンピュータと外部リソース間のトランザクションを仲介します。この構成は通常、それ以外の方法では外部リソースにアクセスできない可能性のあるクライアントに対するコンテンツとして使用されますが、これは、ポリシーの使用も含めて、クライアントに対して追加のセキュリティ制約を課するために使用することもできます。プロキシでは外部リソースは表示されず、コンテンツはプロキシ・サーバーから直接送られてくるように見えます。
このアーキテクチャにより、ページレット・プロデューサはコンテンツの単一アクセス・ポイントとなり、外部リソースがプライベート・ネットワークやファイアウォールの内側に存在できるようになります。ページレット・プロデューサが外部リソースに接続できるかぎり、ユーザーはコンテンツに直接アクセスできない場合でも、そのコンテンツを表示できます。ブラウザにとっては、ページレット・プロデューサは外部リソースのコンテンツのソースであるように見えます。
ユーザーがサービスとやり取りする際、プロキシで行われたURLへのリクエストはすべて、ページレット・プロデューサを通して自動的に再ルーティングされます。ユーザーにとって、コンテンツはページレット・プロデューサから送信されてくるように見えます。外部リソースは不明のバックエンド・システムです。
この構成には多くのメリットがあります。サービスに最も役に立つメリットは次のとおりです。
動的な機能とパーソナライズ: ページレット・プロデューサは、ページレットからのリクエストをインターセプトするため、MDS、リクエストまたはレスポンスからの情報を使用して、レスポンスを動的に変更することが可能になります。
セキュリティ: サービスを使用すると、ユーザーはパブリックに使用できないコンテンツにアクセスできます。特定のURLをプロキシの構成に含めることにより、保護されたサーバーに格納されているファイルが使用可能になります。
警告:
プロキシは強力な機能であるため、不適切に構成された場合はセキュリティを著しく低下させます。保護されていないプライベート・コンテンツをホストしている外部リソースに直接アクセスできるようにすると、危険なセキュリティ・ギャップが生じる可能性があります。
パフォーマンス: ページレット・プロデューサはプロキシ・コンテンツをキャッシュし、エンド・ユーザーに対するレスポンス時間を短縮し、外部リソースのパフォーマンスを向上させます。プロキシはHTMLなどのコンテンツに対しては効率的に機能しますが、静的イメージなどのバイナリ・データには通常は適していません。イメージは変換する必要がないため、大きなイメージをプロキシすると、パフォーマンスに悪影響を与える可能性があります。これが、イメージ・サービスを使用してプロキシ経由での静的イメージのルーティングを避ける必要がある1つの理由です。
プロキシされる他のCSPまたはWebリソースのURLはすべて、「プロキシしないホスト」フィールドに指定されていないかぎり、デフォルトでプロキシされます。プロキシの構成の詳細は、「プロキシ設定の構成方法」を参照してください。
プロキシを使用するサービスを実装する場合は、次の警告とベスト・プラクティスに留意してください。
URL変換: ページレット・プロデューサは、プロキシされるURLを正確に開くため、コードを変換する必要があります。ページレット・プロデューサは、レスポンスを送信する前にHTMLを解析し、「HTTPプロキシ・サーバーURL」フィールドの接頭辞を含むURLを探します(「プロキシ設定の構成方法」を参照)。ページレット・プロデューサは、レスポンスをクライアントに返す前に、プロキシするURLを変換します。関連するURLは、正しい場所を指すように変換されます。
スクリプト制限: URLを動的に作成するJavaScript構成は、コンテンツがすでに変換された後に実行されるため、問題を起こすことがあります。VBScriptはプロキシによって変換されません。使用しているコードがプロキシを認識するかぎり、動的スクリプトとVBScriptを引き続き使用できます。パーサーとWebインジェクタを使用して、URLのリライトに対するターゲット・コントロールを実装できます。パーサーとWebインジェクタの詳細は、「実行時のページレット機能の変更」を参照してください。
URLエンコーディング: 予期しない変換を防ぐために、URLであるヘッダーをすべてエンコードすることはベスト・プラクティスです。JSPでは、書き込まれたURLをすべてエンコードします。コードによってページ本体にURLが書き込まれる場合は(たとえば、プリファレンス・ページへのリンクなど)、そのコードをエンコードする必要があります。標準のJavaサーブレット・コマンド、response.encodeURL()は優先される方法ですが、URLEncoder.encode(url)も使用できます。.NETフレームワークでは、HttpUtility.URLEncodeクラスによって必要な機能が提供されます。.NETでは、リダイレクトURLをエンコードする必要はありません。これは、バックエンドで自動的に処理されます。
この項では、すべてのページレット・プロデューサ・リソースに影響を与える重要な構成設定、およびページレット・プロデューサ・コンソールの「設定」ページを使用してそれらを設定する方法について説明します。ページレット・プロデューサ・コンソールの概要は、「ページレット・プロデューサ・コンソール」を参照してください。
「設定」ページは次の項を参照してください。
WCIリソースを消費するには、CSPログイン・トークンが必要であり、そのログイン・トークンをページレット・プロデューサからCSPポートレットに伝播するには、データ・ソースが必要です。ページレット・プロデューサによって生成されたログイン・トークンは、ユーザー・アイデンティティを伝播し、受信リクエストを検証するために、すべてのリモート・ポートレットに送信されます。データ・ソースを構成するには、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項の手順に従います。データ・ソースにはwcidbという名前を付ける必要があります。
「ロギング」ページでは、ページレット・プロデューサ・コンポーネントのロギング・レベルを設定できます。
任意のコンポーネントのロギングを有効にするには、次のいずれかのロギング・レベルを選択します。
重度
警告
情報
構成
普通
詳細
最も詳細
ロギング・メッセージは、管理対象サーバーのログ・ファイル内で確認できます。Oracle WebLogic Serverの場合、この場所はdomain_home/servers/managed server name/managed server name.logおよびmanaged server name-diagnostic.logです。
「プロキシ」ページでは、プロキシしないURLのリストを定義し、必要に応じてHTTPプロキシのURL、ユーザー名およびパスワードを設定できます。
プロキシ設定を変更したら、ページレット・プロデューサを再起動する必要があります。
注意:
デプロイメント環境内の外部接続にHTTPプロキシが必要な場合、サーバーの初回起動時に接続エラーが報告されます。これらのエラーは環境の問題を示しているのではなく、一部の外部OpenSocialライブラリをリモートでロードできないことを示しています。エラーを解決するには、前述の説明に従ってプロキシ設定を構成し、サーバーを再起動します。
注意:
「プロキシ」ページで入力したHTTPプロキシ・サーバーURLは、ページレット・プロデューサをホストするサーバーで実行されているすべてのアプリケーションに適用されます(Oracle WebLogic Serverでは、この設定はWC_Portlet管理対象サーバーで実行されているすべてのアプリケーションに適用されます)。Oracle WebLogic Serverユーザーは、特にこの設定に注意し、WLS管理サーバー・ホストとすべてのクラスタ化された管理対象サーバーが「プロキシしないホスト」リストに含まれていることを確認する必要があります。
「プロキシ」ページには、次の設定が含まれます。
「プロキシしないホスト」フィールドでは、プロキシしないURLのリストをセミコロンで区切って定義できます(ワイルドカードを使用できます)。Oracle WebLogic Serverデプロイメントの場合は、WLS管理サーバー・ホストとすべてのクラスタ化された管理対象サーバーをこのリストに含めてください。
「HTTPプロキシ・サーバーのパスワード」フィールドでは、プロキシ・サーバーのパスワードを設定できます。
「HTTPプロキシ・サーバーURL」フィールドでは、プロキシ・サーバーのURLを定義できます。
「HTTPプロキシ・サーバーのユーザー名」フィールドでは、プロキシ・サーバーへのアクセスに使用するユーザー名を定義できます。
「変換」ページでは、資格証明ボールト・プロバイダへのパスを入力したり、ページレット・プロデューサのセキュア・ポートとセキュアでないポートを構成できます。このページでは、変換前および変換後のコンテンツをログに記録するかどうかを選択することもできます。
「変換」ページには、次のフィールドが含まれます。
「資格証明ボールト・プラグインのパス」フィールドでは、プラグインが格納されている資格証明ボールトへのパスを定義できます。
「セキュアでないポート」フィールドでは、ページレット・プロデューサのセキュアでないポートを定義できます。
注意:
「セキュアでないポート」のデフォルトは8889です。ページレット・プロデューサを異なるポートにデプロイした場合、このエントリを変更し、サーバーを再起動します。
「セキュア・ポート」フィールドでは、ページレット・プロデューサ用にセキュアなポートを定義します。
「変換のトレース」オプションを選択すると、変換前および変換後のコンテンツに対するロギングがオンになります。このオプションはデバッグに役立ちますが、本番環境ではオンにしないことをお薦めします。
CSPは、HTTP 1.1のオープン標準に基づく、プラットフォームに依存しないプロトコルです。CSPは、ページレット・プロデューサと外部リソース間の通信構文を定義します。また、カスタム・ヘッダーを定義し、サービスがHTTPを使用して設定を通信および変更する方法の概略を記述します。
「CSP」ページでは、Oracle WebCenter Interaction資格証明マッパー、SOAP APIサービスおよびイメージ・サービスを構成できます。
注意:
Oracle WebCenter Interactionがデプロイメント内に存在しない場合、このページは無視される可能性があります。これらの設定は、Oracle WebCenter Interaction用に記述されたCSPポートレットとの下位互換性を維持するために使用されます。
「Kerberos」ページは、Kerberos構成ファイル(java.security.krb5.confおよびjava.security.auth.login.conf)へのパスを定義するために使用します。これら2つの構成ファイルは、Kerberosサービス・チケットの取得場所をHTTPClientに指示するようKerberosレルムとKDCを構成するために必要です。
「OpenSocial」ページでは、OpenSocialガジェットを使用するようページレット・プロデューサを構成できます。
「OpenSocial」ページには、次の設定が含まれます。
「キャッシュ」オプションでは、OpenSocialガジェットに対してページレット・プロデューサの内部キャッシュを有効にできます。
「コンテキスト」フィールドでは、ページレット・プロデューサのデプロイ先となるコンテキストを定義します。この値は、OpenSocialコンテナによって変更を要求されないかぎり、デフォルト設定(pagelets)のまま残してください。コンテキストの変更の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』の異なるコンテキストへのページレット・プロデューサの再デプロイに関する項を参照してください。
「デバッグ」オプションでは、OpenSocialガジェットに対してデバッグを有効に(JavaScriptの不明瞭化を無効に)できます。
「ホスト」フィールドには、ページレット・プロデューサ・ホストの完全修飾ドメイン名を含める必要があります。この値は、環境から自動的に取得されます。取得されない場合は、サーバーを再起動して正しい構成設定を取得します。「コンテキスト」の設定と同様、この値は、OpenSocialコンテナによって変更を要求されないかぎり、デフォルトのまま残してください。
「SSL」オプションでは、OpenSocialガジェットに対してSSLを有効にできます。
注意:
OpenSocialガジェットをインポートする前に、セキュア(HTTPS)およびセキュアでない(HTTP)ポートも構成する必要があります。これらの設定の詳細は、「変換設定の構成方法」を参照してください。
