プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発
12c (12.2.1.2.0)
E82735-01
目次へ移動
目次

前
次

19 ページレットの作成: 例および高度なトピック

この章では、Oracle WebCenter Portalのページレット・プロデューサを使用したページレットの作成方法について例を示します。

この章の内容は次のとおりです。

19.1 単純なページレットの作成(例)

この項では、ページレット・プロデューサを使用してWebページをプロキシする方法について簡単に説明します。ここでは、単純な静的Webページ"Hello World"をプロキシし、そのページから1つのセクションを切り取り、後からWebCenter PortalやWebCenter Interactionで挿入できるページレットとして独自のアプリケーション・ページに表示します。

この項には次のトピックが含まれます:

19.1.1 ページレット・プロデューサの初期設定の構成

この例では、ページレット・プロデューサ・サーバーがhttp://pageletserver.company.com:8889/pagelets/で実行されているものとします。

  1. まず、そのページレット・プロデューサが稼働しているかどうかを確認します。

    これを行うには、単純にそのURL (http://pageletserver.company.com:8889/pagelets/など)にアクセスする必要があります。図19-1に、返される結果を示します。

    図19-1 ページレット・プロデューサのようこそページ

    図19-1の説明が続きます
    「図19-1 ページレット・プロデューサのようこそページ」の説明
  2. 管理者資格証明を使用して、ページレット・プロデューサの管理画面にログインします。

    たとえば、http://pageletserver.company.com:8889/pagelets/adminを使用します

    図19-2 ページレット・プロデューサの管理画面

    図19-2の説明が続きます
    「図19-2 ページレット・プロデューサの管理画面」の説明
  3. プロキシ・サーバーを経由してインターネットに接続する場合は、ページレット・プロデューサ設定でプロキシを構成する必要があります。

    1. ナビゲータ・ペインの「移動先」ドロップダウン・リストで、「設定」を選択します。

    2. 「プロキシ」をクリックします。

    3. 図19-3に示すように、プロキシ・サーバーの構成を入力します。

      図19-3 ページレット・プロデューサのプロキシ設定

      図19-3の説明が続きます
      「図19-3 ページレット・プロデューサのプロキシ設定」の説明

19.1.2 リソースの作成

まず、Webページのリソースを作成する必要があります。これにより、ページレット・プロデューサに、Webページのすべてのサブパスをプロキシする必要があることが通知されます。また、Webページのプロキシ方法に関する共通ルールの設定が可能になり、ページレットのコンテナとして提供されます。

  1. ナビゲータ・ペインの「移動先」ドロップダウン・リストから、「リソース」を選択します。
  2. いずれかの既存のリソースをクリックします(welcome_resourceなど)。
  3. 「選択したタイプの作成」をクリックします。
  4. 「プロデューサ・タイプの選択」ダイアログから「Web」を選択し、「OK」をクリックします。
  5. リソースを作成したら、ナビゲーション・ペインの「全般」ノードをクリックし、次の値を指定します(図19-4を参照)。
    • 名前: AppServer

    • ソースURL: http://appserver.company.com:1234/

    • 宛先URL: /appserver/

    図19-4 ページレット・プロデューサの「全般」設定ページ

    図19-4の説明が続きます
    「図19-4 ページレット・プロデューサの「全般」設定ページ」の説明
  6. 「保存」をクリックします。

    リソースを作成すると、WebページにURL: http://pageletserver.company.com:8889/pagelets/appserver/からアクセスできるようになります

    図19-5 Hello Worldページレット

    図19-5の説明が続きます
    「図19-5 Hello Worldページレット」の説明

    元のWebページ・アドレスのソースURLは、ページレット・プロデューサのURL (http://pageletserver.company.com:8889/pagelets)と宛先URLを組み合せたものに置き換えられています。

19.1.3 ページレットの作成

次はHello Worldページレットを作成します。

  1. 「リソース」ノードの下にある新しく作成された「AppServer」ノードを開きます。
  2. 「選択したタイプの作成」をクリックします。
  3. 新しく作成したページレットの「全般」ノードをクリックし、次の値を指定します(図19-6を参照)。

    名前: Hello_World

    ライブラリ: MyLib

    ライブラリは、論理グループ化に使用します。ポータルでは、ライブラリの値を使用して、ページレットをそれぞれのUIにグループ化します。たとえば、ページレットをWebCenter Portalポータルに追加すると、「ライブラリ」の下に個々のページレットがリストされます。

    URL接尾辞: helloworld/index.html

    URL接尾辞は、Hello WorldページのHTMLの提供元です。

    図19-6 Hello Worldページレットのページレット・プロデューサ設定

    図19-6の説明が続きます
    「図19-6 Hello Worldページレットのページレット・プロデューサ設定」の説明
  4. 「保存」をクリックします。

ライブラリ名には任意の名前を指定でき、リソース名と一致している必要はありません。これはページレットの論理グループ化に使用されます。また、ページレットを複数のリソースから同じライブラリに含めたり、ページレットごとに新しいライブラリを作成できます。

ページレットを保存したら、次の場所からそのページレットにアクセスできます。

http://pageletserver.company.com:8889/pagelets/inject/v2/pagelet/MyLib/Hello_World

つまり、次のようになります。

http://pageletserver.company.com:8889/pagelets/inject/v2/pagelet/ +[Library] +[Name]

また、iFrameへのページレットの挿入をテストするために、ページレットの「ドキュメント」ノードをクリックし、「RESTを使用してページレットにアクセス」のURLを使用することもできます。

図19-7 ページレットの「ドキュメント」ページ

図19-7の説明が続きます
「図19-7 ページレットの「ドキュメント」ページ」の説明

「ドキュメント」ページのURLをクリックすると、次のような画面が表示されます。

図19-8 Hello Worldページレット

図19-8の説明が続きます
「図19-8 Hello Worldページレット」の説明

19.1.4 ページレットのクリップ

作成したページレットは、Webページ全体に表示されます。必要なのはHello Worldのセグメントのみであるため、次の手順に従って、そのセグメントをクリップする必要があります。

  1. 「Hello_World」ページレット・ノードの下にある「クリップ」をクリックします。
  2. 「選択したタイプの作成」をクリックします。
  3. 新しく作成するクリッパの名前を指定します(c1など)。
  4. クリッパの「コンテンツ」ノードをクリックし、「クリッパの起動」をクリックします。

    図19-9 ページレット・プロデューサのクリッパ

    図19-9の説明が続きます
    「図19-9 ページレット・プロデューサのクリッパ」の説明
  5. ブラウザ・ウィンドウで、クリップする領域をマウスで選択します。

    マウス・ボタンをクリックすると、ブラウザ・ウィンドウが非表示になり、クリッピング・パスが自動的に生成されます。

  6. クリップされたページレットを保存し、もう一度「ドキュメント」ページからそのリンクにアクセスします。
  7. これでページレットが適切にクリップされ、WebCenter Portalポータル内で使用できるようになりました(図19-10を参照)。

    図19-10 クリップされたHello Worldページレット

    図19-10の説明が続きます
    「図19-10 クリップされたHello Worldページレット」の説明

19.2 WebCenterポータルでのページレットの消費(例)

この項では、単純なHello WorldページレットをWebCenter Portal内で消費する方法の例を示します。先に進む前に、まず「単純なページレットの作成(例)」の手順に従って、この例で使用する"Hello World"ページレットを作成します。

この項では、次の内容について説明します。

19.2.1 WebCenter Portalへのページレット・プロデューサの登録

新しく作成したページレットをWebCenter Portalから使用するには、まずページレット・プロデューサを登録する必要があります。

  1. 管理者としてWebCenter Portalにログインします。

    注意:

    WebCenter PortalAdministratorロールまたは次の権限を付与するカスタム・ロールが必要です。

    • Portal Server-Manage Configuration

  2. 「ポータル」メニューから「管理」を選択し、「設定」タブをクリックします。
  3. 「ツールとサービス」ページで、「ポートレット・プロデューサ」をクリックします。
  4. 「登録」をクリックします。
  5. 「ページレット・プロデューサ」を選択し、フィールドの値を次のように入力します。

    プロデューサ名: MyPageletProducer

    サーバーURL: http://pageletserver.company.com:8889/pagelets/

  6. 「テスト」をクリックし、接続が正しく構成されたことを確認します。

    すべて成功した場合、「テストのステータス」ダイアログに、テスト接続が成功したことを示すメッセージが表示されます。

  7. 「OK」をクリックします。

    これでページレット・プロデューサが登録されました。

19.2.2 ポータルへのページレットの挿入

この演習用に、ポータルを作成する必要があります。まず、WebCenter Portalにログインし、デフォルトの「ポータル」テンプレートを使用してmyportalというポータルを作成します。

  1. 管理者としてWebCenter Portalにログインします。
  2. 「ポータル」テンプレートを使用して、myportalというポータルを作成します。

    新しいポータルのホーム・ページがポータル・エディタで開きます。

  3. ページレットを追加するページの領域で「コンテンツの追加」をクリックしてリソース・カタログを開きます。
  4. 「ページレット・プロデューサ」をクリックします。
  5. 以前に登録したページレット・プロデューサを選択します。

    Hello_Worldページレットを含むライブラリMyLibが表示されます。

  6. 「MyLib」をクリックし、Hello_Worldページレットを選択します。
  7. ページを保存します。
  8. 「ポータルの表示」をクリックします。

    これで、Hello Worldページレットがmyportalのホーム・ページに挿入されます。

19.3 WebCenter Interactionでのページレットの消費(例)

この項では、単純なHello WorldページレットをWebCenter Interaction (WCI) 10.3.0以降で消費する方法の例を示します。先に進む前に、まず「単純なページレットの作成(例)」の手順に従って、この例で使用する"Hello World"ページレットを作成します。

この項では、次の内容について説明します。

19.3.1 ページレット・プロデューサ・リモート・サーバーの登録

新しく作成したページレットをWCIから使用するには、まずページレット・プロデューサを登録する必要があります。

  1. 管理者としてWCIにログインします。

  2. 「管理」をクリックします。

  3. 次の手順に従って、すべてのページレット・プロデューサ関連のオブジェクトを格納するフォルダを作成します。

    1. 「オブジェクトの作成」ドロップダウン・リストを開き、「管理フォルダ」を選択します。

    2. 「名前」「PageletProducer」と入力し、「OK」をクリックします。

      図19-11 WCI - 「管理フォルダの作成」

      図19-11の説明が続きます
      「図19-11 WCI - 「管理フォルダの作成」」の説明
  4. 新しく作成したPageletProducerフォルダをクリックします。

    図19-12 WCI - 新しく作成したフォルダ

    図19-12の説明が続きます
    「図19-12 WCI - 新しく作成したフォルダ」の説明
  5. 「オブジェクトの作成」ドロップダウンを開き、「リモート・サーバー」を選択します。

    図19-13 WCI - 「リモート・サーバーの作成」

    図19-13の説明が続きます
    「図19-13 WCI - 「リモート・サーバーの作成」」の説明
  6. 「ベースURL」フィールドに、http://pageletserver.company.com:8889/pageletsと入力します(この例では、これがページレット・プロデューサのアドレスになります)。

  7. 「終了」をクリックします。

  8. PageletProducerフォルダを選択し、「名前を付けて保存」フィールドにPagelet Producer Remote Serverと入力します。

    図19-14 WCI - ページレット・プロデューサ・リモート・サーバー・オブジェクトの保存

    図19-14の説明が続きます
    「図19-14 WCI - ページレット・プロデューサ・リモート・サーバー・オブジェクトの保存」の説明
  9. 「保存」をクリックします。

    これで、PageletProducerフォルダ内にページレット・プロデューサ・リモート・サーバー接続が作成されました。

    図19-15 WCI - ページレット・プロデューサ・リモート・サーバー・オブジェクト

    図19-15の説明が続きます
    「図19-15 WCI - ページレット・プロデューサ・リモート・サーバー・オブジェクト」の説明

19.3.2 Hello World Webサービスの作成

この項では、"Hello World" Webサービスを作成します。

  1. 「オブジェクトの作成」ドロップダウンを開き、「Webサービス - リモート・ポートレット」を選択します。
  2. 「参照」をクリックし、ページレット・プロデューサ・リモート・サーバーを選択します。

    図19-16 WCI - 「リモート・サーバーの選択」ダイアログ

    図19-16の説明が続きます
    「図19-16 WCI - 「リモート・サーバーの選択」ダイアログ」の説明
  3. 「OK」をクリックします。
  4. 「ポートレットURL」フィールドの値を、次のように入力します。

    inject/v2/portlet/MyLib/Hello_World?content-type=iframe&csapi=true&ifheight=300px

    MyLibはHello Worldページレットを含むライブラリで、Hello_Worldはページレットの名前です。

    図19-17 WCI - Webサービス - リモート・ポートレットの作成ダイアログ

    図19-17の説明が続きます
    「図19-17 WCI - Webサービス - リモート・ポートレットの作成ダイアログ」の説明
  5. 「終了」をクリックします。
  6. PageletProducerフォルダを選択し、「名前を付けて保存」フィールドにHello World Web Serviceと入力します。
  7. 「保存」をクリックします。

    これで、Hello World Webサービスが作成されました。

19.3.3 Hello Worldポートレットの作成

この項では、Hello Worldポートレットを作成します。

  1. 「オブジェクトの作成」ドロップダウン・リストを開き、「ポートレット」を選択します。

    「テンプレートまたはWebサービスの選択」ダイアログが表示されます(図19-18)。

    図19-18 WCI - 「テンプレートまたはWebサービスの選択」

    図19-18の説明が続きます
    「図19-18 WCI - 「テンプレートまたはWebサービスの選択」」の説明
  2. テンプレートまたはWebサービスのリストから、「Hello World Web Service」を選択し、「OK」をクリックします。
  3. 「ポートレット・タイプ/サイズ」で、使用するポートレット・タイプおよびサイズを選択し、「終了」をクリックします。
  4. 「PageletProducer」フォルダを選択します。
  5. 「名前を付けて保存」フィールドにHello World Portletと入力し、「保存」をクリックします。

    これで、Hello Worldポートレットが作成されました。

19.3.4 WCIホーム・ページでのHello Worldポートレットの使用

ページレット・プロデューサの登録、ページレット・プロデューサWebサービスの設定およびHello Worldポートレットの作成が完了したので、次はそのポートレットをWCIのページ上で使用します。ここでは、説明を簡潔にするためにWCIホーム・ページを使用しますが、他のWCIページを使用することもできます。

  1. WCIで、「マイ・ページ」→「ホーム・ページ」に移動します。
  2. 「ページの編集」をクリックし、「PageletProducer」フォルダを開きます。
  3. Hello Worldポートレットをクリックします。
  4. 「エディタを閉じる」をクリックします。

    WCIのホーム・ページに挿入されたHello Worldページレットを次に示します。

    図19-19 WCI - ホーム・ページ上のHello Worldページレット

    図19-19の説明が続きます
    「図19-19 WCI - ホーム・ページ上のHello Worldページレット」の説明

19.4 Oracle WebCenter Sitesでのページレットの消費(例)

この項は、既存のWSRPポートレットまたは、Oracle EBSなどのバックエンド・アプリケーションにより公開されるWeb UIの要素も含めて、Oracle WebCenter Sites 11gの各ページにコンテンツを統合する必要のある開発者を対象としています。開発者はOracle WebCenter SitesおよびOracle WebCenterページレット・プロデューサに精通しており、Webテクノロジを十分に理解している必要があります。

この項では、次の内容について説明します。

19.4.1 Oracle WebCenter Sitesへのページレットの追加

ページレットとその関連リソースが構成されたら、JavaScriptまたはRESTを使用してそれをWebページに挿入できます。詳細は、「Webページへのページレットの追加」を参照してください。

ここでは、コンテンツ・ソースとしてページレットにアクセスするためのREST URLを指定したIFrameを使用して、ページレットがOracle WebCenter Sites内のページ・テンプレートに直接追加されるアプローチを採用します。このためには、CSAPI JavaScriptライブラリ(必要な機能を親ページに追加します)と、ページレット・コンテンツをロードする実際のiFrameをロードするために、ページ・テンプレート・スクリプト・タグに次のように追加する必要があります。

<script type="text/javascript" src="http://%PAGELET_PRD_HOST%/pagelets/inject/v2/csapi"/>
<iframe id="pt-pagelet-iframe-1" width="100%" frameborder="0" src="http://%PAGELET_PRD_HOST%/pagelets/inject/v2/pagelet/lib_name/pagelet_name?content-type=html&consumepage=true&ifheight=auto"></iframe>

ここで、lib_nameおよびpagelet_nameはページレット・プロデューサに構成されたライブラリとページレットを示しています。パラメータの詳細は、「RESTを使用したページレットへのアクセス方法」を参照してください。

19.4.1.1 IFrameの自動サイズ変更の有効化

ページレットをよりシームレスに消費側ページに統合するには、コンテンツを収められるように動的にサイズ変更することによって、ページレットiFrameがよりインライン・マークアップらしく動作するように設定できます。この機能を有効にするには、サイトとページレット・プロデューサの両方でさらに構成を加える必要があります。

この項では、WebCenter Sitesに同梱されているAviSportsサンプル・サイトを使用します。このサイトに新しいアセットを追加するには、サイト管理ページにログインして、図19-20に示すように左側のナビゲーションで開発セクションを開きます。

図19-20 サイト管理ページ

図19-20の説明が続きます
「図19-20 サイト管理ページ」の説明

まず、次の設定を使用して新しいテンプレートを作成します。

  • 名前

    • 名前: iFrameResizeRelay (または任意の名前)

    • アセット・タイプの場合: 様々なアセット・タイプに適用可能(タイプなし)

  • エレメント

    • 使用方法: 要素はHTMLページ全体を定義し、外部からコール可能です。

    • 要素記憶域パス/ファイル名: iframe-resize.html(または任意の名前)

    • エレメント・ロジック:

      <html>
       <head>
       <title>Resizing Page</title>
       <script type="text/javascript">
      function onLoad() {
      var params =window.location.search.substring( 1 ).split( '&' );
      var height;
      var width;
      var iframe;
      for( var i =0, l =params.length; i < l; ++i ) {
      var parts =params[i].split( '=' );
      switch( parts[0] ) {
      case 'height':
      height =parseInt( parts[1] );
      break;
      case 'width':
      width =parseInt( parts[1] );
      break;
      case 'iframe':
      iframe =parts[1];
      break;
      }
      }
      window.top.updateIFrame( iframe, height, width );
      }
      if (window.addEventListener) {
      window.addEventListener("load", onLoad, false);
      } else if (window.attachEvent) {
      window.detachEvent("onload", onLoad);
      window.attachEvent("onload", onLoad);
      } else {
      window.onload=onLoad;
      }
       </script>
       </head>
       <body>
       </body>
      </html>
      
  • サイト・エントリ

    • キャッシュ・ルール: キャッシュ済(デフォルト)

  • 保存

  • SiteCatalogパラメータを%PAGENAME%として記録(デフォルト名を使用した場合、これは<site_name>/iFrameResizeRelayになります)

新しいテンプレートには、次のようにアドレス可能です。

http://%SITES_HOST%/cs/Satellite?pagename=%PAGENAME%

このURLをメモしておきます。これは、ページレット用にインジェクタを構成するために使用します。

次に、ページレット・プロデューサ管理コンソールを使用して新しいインジェクタをページレットに追加することによって、iFrameサイズ変更機能を適用します。ページレットを開き、「インジェクタ」を選択して、次の設定で新しいインジェクタを作成します。

  • 全般

    • 名前: auto_resizer (または任意の名前)

    • URLフィルタ: <none>

    • MIMEフィルタ: text/html

    • 挿入位置: </head>の前

  • コンテンツ: 「テキスト」(デフォルト)を選択し、次のJavaScriptをテキスト・エリアにコピーします。

    次のJavaScript内のSITES_RESIZE_RELAY_PAGEを、前の手順で作成したテンプレートのURLに置き換えます。

    <script type="text/javascript">
    var SITES_RESIZE_RELAY_PAGE ="http://%SITES_HOST%/cs/Satellite?pagename=%PAGENAME%"; //CHANGE ME!
     
    if (window.addEventListener) {
    window.addEventListener("load", calculateSizeFixed, false);
    } else if (window.attachEvent) {
    window.attachEvent("onload", calculateSizeFixed);
    } else {
    window.onload=calculateSizeFixed;
    }
    function calculateSizeFixed() {
    var PTResizeIFrame =PTResizeIFrame ││{};
     if (PTPortalPage && PTPortalPage.portlets) {
    for (var i in PTPortalPage.portlets) {
    if ( PTPortalPage.portlets[i].id != "page") {
    PTResizeIFrame.pageletInstanceID =PTPortalPage.portlets[i].id;
     break;
     }
    }
    }
    else if (!PTResizeIFrame.pageletInstanceID) {
    PTResizeIFrame.pageletInstanceID =1;
     }
    
    if (!PTResizeIFrame.pageletResizePage) {
    var match =window.location.search.match(/resizepage=[^&]*/);
     if (match != null && match.length > 0) PTResizeIFrame.pageletResizePage =unescape(match[0].substr("resizepage=".length));
     else PTResizeIFrame.pageletResizePage =SITES_RESIZE_RELAY_PAGE;
     }
    var agent =navigator.userAgent;
     var ffversion =agent.indexOf("Firefox") >= 0 ? agent.substring(agent.indexOf("Firefox")).split("/")[1] : -1;
     var FFextraHeight =parseFloat(ffversion)>=0.1? 25 : 0;
     var scrollHeightExtra =15;
     if (agent.indexOf('MSIE') > 0) {
    scrollHeightExtra =35;
     }
    if (FFextraHeight > 0) scrollHeightExtra =FFextraHeight;
     var wrapper =document.getElementById( 'pt-inner-iframe-wrapper-' +PTResizeIFrame.pageletInstanceID);
     if (wrapper ==null) wrapper =createRelayIFrame(PTResizeIFrame.pageletInstanceID);
     var iframe =document.getElementById( 'pt-inner-iframe-' +PTResizeIFrame.pageletInstanceID);
     var height =0;
     var width =0;
     var iframename ='';
     
    if( (document.contentDocument) && (document.contentDocument.documentElement.offsetHeight) ) {
    height =document.contentDocument.documentElement.offsetHeight +FFextraHeight; 
    }else if( (document.contentDocument) && (document.contentDocument.body.offsetHeight) ) {
    height =document.contentDocument.body.offsetHeight+FFextraHeight; 
    }else if (document && document.documentElement.scrollHeight ) {
    height =document.documentElement.scrollHeight +scrollHeightExtra;
     }else if( document && document.body.scrollHeight ) {
    height =document.body.scrollHeight +scrollHeightExtra;
     }else {
    height =wrapper.offsetHeight;
     }
    width =wrapper.offsetWidth;
     iframename ='pt-pagelet-iframe-' +PTResizeIFrame.pageletInstanceID;
     var qsSeparator =PTResizeIFrame.pageletResizePage.indexOf("?") >= 0 ? "&" : "?";
     
    iframe.setAttribute("src", PTResizeIFrame.pageletResizePage +qsSeparator +'height=' +height +'&' +'width=' +width +'&' +'iframe=' +iframename);
    }
     
    function createRelayIFrame(pageletInstanceId) {
    var wrapper =document.createElement("div");
     wrapper.id ="pt-inner-iframe-wrapper-" +pageletInstanceId;
     var iframe =document.createElement("iframe");
     iframe.id ="pt-inner-iframe-" +pageletInstanceId;
     iframe.setAttribute("height", 0);
     iframe.setAttribute("frameborder", 0);
     iframe.setAttribute("width", 0);
     wrapper.appendChild(iframe);
     document.body.appendChild(wrapper);
     return wrapper;
    }
    </script>
    

IFrame内でREST URLを使用して、サイトにあるページ・テンプレートにページレットを追加します。IFrameでは、IDパラメータにはページレットIFrameを識別する一意の番号を使用する必要があります(たとえば、「pt-pagelet-iframe-1」)。IFrame自動サイズ変更をサポートするために、次の問合せ文字列パラメータをページレットURLに追加する必要があります。

  • resizepage=http://%SITES_HOST%/cs/Satellite?pagename=%PAGENAME%

  • ifheight=auto

例:

<script type="text/javascript" src="http://%PAGELET_PRD_HOST%/pagelets/inject/v2/csapi"/>
<iframe id="pt-pagelet-iframe-1" width="100%" frameborder="0" src="http://%PAGELET_PRD_HOST%/pagelets/inject/v2/pagelet/lib_name/pagelet_name?content-type=html& consumepage=true&resizepage=http://%SITES_HOST%/cs/Satellite?pagename=%PAGENAME%&ifheight=auto">
</iframe>

注意:

1ページに複数のページレットが存在する場合は、自動サイズ変更が適切に機能しないことがあります。これは、外部認証サーバーに対してフォーム自動ログインを必要とするページレットで発生することが知られています。この場合は自動サイズ変更用に構成できるページレットは1つだけであり、その他のページレットには静的なIFrameサイズ設定を使用する必要があります。

19.4.1.2 ページレット・スタイルの変更

消費側WebCenter Sitesのページでページレットが見栄えよく収まるようにするには、インジェクタを使用して元のCSSをオーバーライドするスタイルを追加することもできます。オーバーライドが適切に機能するためには、インジェクタによるスタイル定義がバックエンド・アプリケーションによって定義されたスタイルの後に置かれることが重要です。次の例では、置換CSSを<HEAD>セクションの末尾に注入することで、これを処理しています。

ページレットのスタイルを変更するには、ページレット・プロデューサ管理コンソールを使用して新しいインジェクタをページレットに追加します。ページレットを開き、「インジェクタ」を選択して、次の設定で新しいインジェクタを作成します。

  • 全般:

    • 名前: new_styles (または任意の名前)

    • URLフィルタ: <none>

    • MIMEフィルタ: text/html

    • インジェクタの場所: </head>の前

  • コンテンツ

    Injector Location: Before </head>
    

「EBS11iを使用したページレットとしてのアプリケーションの消費」には、WebCenter SitesでサンプルのAviSportsサイトを適合させるためにEBS UIのスタイル変更に使用されるインジェクタの作業例が含まれています。

19.4.2 アイデンティティ伝播の使用

ページレット・プロデューサの中心的な目的は、バックエンド・アプリケーションをプロキシ設定することです。ページレット・プロデューサはブラウザとバックエンド・アプリケーションの仲介役として動作するため、アイデンティティ伝播を次の2つの部分に分ける必要があります。

19.4.2.1 ページレット・プロデューサでのアイデンティティの確立

ページレット・プロデューサは通常、図19-21に示すようなIFrameを使用して、WebコンテンツをWebCenter Sitesに挿入します。

図19-21 サイトにおけるIFrameとしてのページレット・プロデューサのコンテンツ

図19-21の説明が続きます
「図19-21 サイトにおけるIFrameとしてのページレット・プロデューサのコンテンツ」の説明

コンテンツはIFrameとして注入されるため、ユーザーIDは、図19-22に示すようにサイト・コンテナとページレット・プロデューサ・コンテナの両方に設定されている必要があります。図19-22では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていることに注意してください。

図19-22 サイトおよびページレット・プロデューサで異なる認証スキーム

図19-22の説明が続きます
「図19-22 サイトおよびページレット・プロデューサで異なる認証スキーム」の説明

ブラウザと2つのコンテナ間でアイデンティティを管理する理想的な方法は、図19-23に示すようにOracle Access Manager (OAM)を使用することです。図19-23では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていて、OAMアクセス・サーバーが除外されていることに注意してください。また、この構成は11g以前のバージョンではサポートされていないことにも注意してください。

図19-23 OAMを使用した理想的なフロントエンド認証構成

図19-23の説明が続きます
「図19-23 OAMを使用した理想的なフロントエンド認証構成」の説明

WebCenter Sites11g用にOAMを設定する場合は、Oracle WebCenter Sitesでサポートするソフトウェアの構成の「Oracle Access Manager統合の設定」の章を参照してください。

19.4.2.2 ページレット・プロデューサにより指定されたログイン・ページの使用

OAMを設定する前に、サイトでページレット・プロデューサの統合をテストしておくと役立つ場合があります。OAMを使用しないと、ユーザーはページレット・プロデューサとサイトでそれぞれ別々に認証する必要があります(図19-22を参照)。この項では、ページレット・プロデューサでの個別認証の構成方法について説明します。

OAM SSOがページレット・プロデューサまたはサイトのどちらかに存在していない場合は、必ずページレット・プロデューサからログイン・フォームが表示されるようにして、図19-24に示す認証スキームをサポートする必要があります。

ページレット・プロデューサでログイン・フォームが表示されるようにするには:

  1. ページレットへのアクセスを制限するJ2EEロールを特定するか、ページレット・プロデューサをホストしているJ2EEアプリケーション・サーバーに新しいロールを作成します。

    この例では、デフォルトのWLSインストールに存在しているグローバルなWebLogic Server (WLS)の「匿名」J2EEロールを使用しています。

  2. ページレット・プロデューサ管理コンソールにログインし、サイト内で表面化する必要のあるページレットが含まれているリソースに移動して、ステップ1で選択したロールを追加します。

    ロールは、リソースの「ポリシー」ページで定義されます。

    図19-24 ページレット・プロデューサ管理コンソール - 「ポリシー」ページ

    図19-24の説明が続きます
    「図19-24 ページレット・プロデューサ管理コンソール - 「ポリシー」ページ」の説明

19.4.3 ページレット・プロデューサからバックエンド・アプリケーションへのアイデンティティの伝播

アイデンティティの確立方法は、次の各項で説明するようにアプリケーションのタイプによって異なります。

19.4.3.1 WSRP/JPDKポートレット

WSRPポートレットは、アイデンティティ伝播のためにWSSトークンを使用する必要があります。セキュリティ・トークンの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項と、「WSRPポートレットのページレットとしての消費」を参照してください。

アイデンティティを必要とするOracle PDK-Javaポートレットごとに、外部アプリケーションのログイン・フォームによって提供される情報に基づいて資格証明が渡されます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』の外部アプリケーションの管理に関する項およびOracle PDK-Javaポートレット・プロデューサの登録に関する項を参照してください。

19.4.3.2 ネイティブ認証(非SSO)により保護されたスタンドアロン・バックエンド・アプリケーション

ページレット・プロデューサには「自動ログイン」という機能があり、この機能によってページレット・プロデューサはバックエンド・アプリケーションにより確立されたネイティブ認証メカニズムと相互作用できます。

19.4.3.3 自動ログインによるアイデンティティ伝播

バックエンド・アプリケーションにはそれぞれ独自の認証手段があるため、必要な資格証明を収集するには、ページレット・プロデューサで独自のログイン・プロンプトを開始する必要があります。ページレット・プロデューサのリソースは、資格証明を基本的な認証ヘッダー、NTLMトークンまたはKerberosトークンとしてバックエンド・アプリケーションに送信し、さらにフォーム・ベースの認証を(通常はセッションCookieを介して)管理するように構成できます。自動ログインの構成の詳細は、「自動ログインの構成方法」を参照してください。

注意:

「ユーザー・ボールト」を使用するように「ユーザー名」フィールドと「パスワード」フィールドを設定して、バックエンド・アプリケーションへのアクセスに必要なユーザー自身の一意の資格証明を入力するプロンプトが各ユーザーに表示されるようにします。

19.4.3.4 SSOにより保護されたスタンドアロン・バックエンド・アプリケーション

バックエンド・アプリケーションに適切な自動ログイン設定を決定することは、かなり大変な場合があります。この作業では、リクエスト・ヘッダーの参照、リダイレクトの確認、マークアップ(ときには動的に生成されたもの)の調査が必要になります。この調査および構成プロセスは、自動ログインが必要なアプリケーションが複数存在する場合は、気の滅入るような作業になりかねません。したがって、Oracle Access Manager (OAM) SSOまたはOracle SSO (OSSO)が使用可能な場合は、バックエンド・アプリケーションを保護するためにこれらのシングル・サインオン・ソリューションの1つを使用することを強くお薦めします。

バックエンド・アプリケーションがOAMで保護されると、次のサブセクションで説明するように、次の2つの方法でページレット・プロデューサが資格証明を提供できるようになります。

19.4.3.4.1 OAMで保護されたバックエンド・アプリケーションへのアイデンティティ直接伝播の使用

OAM 11g WebGateは、OAMサーバーでユーザー資格証明のすべての検証を管理するOracle HTTP Server (OHS)で実行するApacheモジュールです。ユーザーの妥当性が確立されると、OHSがプロキシ設定しているアプリケーション・サーバー上のWebアプリケーションにOAM_REMOTE_USERヘッダーが送信されます。アプリケーション・サーバー上ではOAMアイデンティティ・アサーション・プロバイダが実行して、JAASユーザー・プリンシパル名をOAM_REMOTE_USERヘッダー値に設定します。

ページレット・プロデューサがOAM 11g WebGateで保護されると、OAM_REMOTE_USERヘッダーを受信します。これによってプロキシ設定されたWebアプリケーションもすべて、このヘッダーを受信します。プロキシされているWebアプリケーションがOAMアイデンティティ・アサータを備えたアプリケーション・サーバー上に存在する場合、OAMアイデンティティ・アサータではページレット・プロデューサから渡されたOAM_REMOTE_USERヘッダー値を使用してユーザー・プリンシパルを設定します。この動作は、ページレット・プロデューサが、保護されたWebアプリケーションに対してWebGateのURLをプロキシしようとしないかぎり、すべて実行されます。この項の以降の部分では、サイト統合のコンテキストでこれが実行できる方法を詳しく説明します。

設定例

この例では、図19-23に示すように、WebCenter Sitesとページレット・プロデューサの両方がOAM WebGateによって保護され、次のホストとポートがアプリケーションによって使用されることを前提としています。

  • OAM SSO WebGate: www.example.com:80

  • WebCenter Sites: sites_host:8080

  • WebCenterページレット・プロデューサ: pp_host:8889

  • バックエンド・アプリケーション: backendhost:8001

  • ブラウザから(WebGate経由で)表示されるバックエンド・アプリケーションの完全URL

    http://www.example.com/backend/console

  • アプリケーション・サーバーから直接アクセスする場合のバックエンド・アプリケーションの完全URL(内部ネットワークのみで使用可能) http://backendhost:8001/console

バックエンド・アプリケーションへの直接URLを使用するようにページレット・プロデューサ・リソースを設定して、WebGateをバイパスします(つまり、http://backendhost:8001/console)。

図19-25 ページレット・プロデューサ管理コンソール - 「一般プロパティ」ページ

図19-25の説明が続きます
「図19-25 ページレット・プロデューサ管理コンソール - 「一般プロパティ」ページ」の説明

バックエンド・アプリケーションを直接コールするようにページレット・プロデューサを設定(WebGateをバイパス)することにより、ページレット・プロデューサで受信されるすべてのOAMセキュア・ヘッダーは、バックエンド・アプリケーションをホストしているアプリケーション・サーバー上のOAMアイデンティティ・アサーション・プロバイダに渡されます。バックエンド・アプリケーションをホストしているアプリケーション・サーバー上のOAMアイデンティティ・アサーション・プロバイダは、OAMヘッダーを受信すると、適切なユーザー・プリンシパルを設定します(図19-26を参照)。図19-26では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていることに注意してください。また、OAMアクセス・サーバーも除外されています。

図19-26 バックエンド・アプリケーションを直接コールするページレット・プロデューサ

図19-26の説明が続きます
「図19-26 バックエンド・アプリケーションを直接コールするページレット・プロデューサ」の説明

注意:

WebGateをバイパスするようにページレット・プロデューサを設定するとシングル・サインオンが実行できますが、このソリューションはいつでも適用できるわけではありません。WebGateをホストしているOHSサーバーがバックエンド・アプリケーションのロード・バランシングも管理している場合は、WebGateをバイパスすることによってロード・バランシングもバイパスされます。アプリケーションへのトラフィックはすべて1つのサーバーにルーティングされます。この場合は、「自動ログインとSSOによるアイデンティティ伝播の使用」で説明するように、自動ログイン用にページレット・プロデューサを構成することをお薦めします。

19.4.3.4.2 自動ログインとSSOによるアイデンティティ伝播

OAM WebGateのバイパス(「OAMで保護されたバックエンド・アプリケーションへのアイデンティティ直接伝播の使用」を参照)が実行可能なオプションでない場合でも、ページレット・プロデューサの自動ログイン機能を使用して資格証明を提供できます。バックエンド・アプリケーションごとに個別のログイン・フォームを使用する場合(「自動ログインによるアイデンティティ伝播」を参照)と異なり、Oracle SSOソリューション(OAMまたはOSSO)のログイン・ページによる自動ログインを使用すると、自動ログインを1回だけ設定すればよく、構成手順はすべての実装で同じであるという利点があります。

OSSOによる自動ログインの設定手順については、「自動ログインの構成」を参照してください。本番環境では、この手順はそのまま実行できますが、例外としてssousernameフォーム・フィールドとpasswordフォーム・フィールドを「ユーザー・ボールト」にリンクする必要があります。

OAMで保護されたバックエンド・アプリケーションも、このドキュメントの自動ログインの構成に関する項でOSSOに関して説明した手順に従って設定できますが、次の例外があります。

  • login form URLは設定済の場所(例: http://oam11g.mycompany.com:14100/oam/server/obrareq.cgi)です。

    自動ログインのフォーム識別URLを設定するときに、固定位置引数の後の問合せ文字列を必ず削除してください。

  • form action URLは異なる値になりますが、静的な値である必要があります。OAM formを調べて、form action URLを決定します。

  • 「username」フィールドと「password」フィールドの値が異なる場合があります。「OAM form」フィールドを調べて、これらの値を決定します。

  • 次の生成された2つの値、「request_id」および「OAM_REQ」を含めます。

19.4.3.5 参照: 共通自動ログイン構成

この項では、一般的なバックエンドSSOシナリオに対するページレット・プロデューサでの自動ログイン設定のクイック参照を示します。

この項では、次の項目について説明します。

19.4.3.5.1 Oracle Access Manager (OAM)の自動ログイン設定

ログイン・フォームID:

  • URL: http://%OAM_ROOT%/server/obrareq.cgi

フォームの送信場所:

  • URL: /oam/server/auth_cred_submit

フォーム・フィールド:

  • actionURL: 静的: /oam/server/auth_cred_submit

  • request_id: 生成済

  • username: 非保護または資格証明ボールト

  • OAM_REQ: 生成済

  • password : 非保護または資格証明ボールト

19.4.3.5.2 Oracle SSO (OSSO)の自動ログイン設定

ログイン・フォームID:

  • URL: %OSSO_HOST%/sso/jsp/login.jsp

フォームの送信場所:

  • URL: %OSSO_HOST/sso/auth - POST

フォーム・フィールド:

  • appctx: 生成済

  • locale: 生成済

  • password : 非保護または資格証明ボールト

  • site2pstoretoken: 生成済

  • ssousername: 非保護または資格証明ボールト

  • v: 生成済

19.5 WSRPポートレットのページレットとしての消費

ページレット・プロデューサにはWebCenter Common Consumerが組み込まれているため、WSRPポートレットをページレットとして公開して、WebCenter SitesまたはWSRPコンシューマが含まれていないその他のすべてのWebコンテナで使用することができます。

WSRPポートレット・プロデューサは、Fusion Middleware Control、WLSTまたはページレット・プロデューサ管理コンソールを使用してページレット・プロデューサに登録できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項を参照してください。登録が完了すると、WSRPプロデューサはページレット・プロデューサ管理コンソールにリソースとして表示され、WSRPエンドポイントに関連付けられたポートレットがリソースのページレット・コレクションにリストされます。

注意:

自動生成されたWSRPリソースとページレットは変更できません。変更可能なバージョンを作成するには、ページレット・プロデューサ管理コンソールで該当するリソースを選択して、「コピー」をクリックします。リソースのクローン・バージョンは編集可能であり、インジェクタなどの各種要素を追加してページレットの機能をカスタマイズできます。たとえば、カスタム・インジェクタを使用してCSSクラスを注入し、ポートレット・マークアップがページレットをホストするサイトのルック・アンド・フィールのように表示されるように変更することもできます。

ページレット・プロデューサに登録しているWSRPプロデューサで認証が必要な場合は、次の手順を実行する必要があります。

  • 『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のWeb Servicesセキュリティの構成に関する項の説明に従って、ページレット・プロデューサとWSRPプロデューサ間にWSセキュリティを構成します。Javaキーストア(JKS)がWSRPプロデューサとページレット・プロデューサ間で適切に構成されていることを確認する必要があります。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のWebCenterポータル・ドメイン・キーストアの設定に関する項を参照してください。

  • WSRPプロデューサの登録時に、「セキュリティ」セクションで適切な「トークン・プロファイル」を選択して、必要な構成情報を入力します。キーストアへのパスは絶対パスである必要があります。

19.6 カスタムADFタスクフローをWSRPポートレットとして公開

ADFタスク・フローがホストされているページからそれを「クリッピング」することで、そのADFタスク・フローをページレット・プロデューサで消費できますが、この方法はお薦めできません。ADFページによって生成されたマークアップの複雑さや、他のタスク・フローまたはADFページ・パラメータへの潜在的な依存性を考慮すると、お薦めできる方法は、タスク・フローに基づいてWSRPポートレットを作成してから、そのポートレットをページレット・プロデューサで消費することです。この方法の利点の1つは、ADFタスク・フローのパラメータがポートレットのパラメータになってページレット・パラメータにマップ可能になり、情報をサイト・ページからタスク・フローに渡せるようになることです。ADFタスク・フローからポートレットを作成する方法の手順は、「タスク・フローに基づいたJSFポートレットの作成方法」を参照してください。

ADFタスク・フローがポートレットとして公開された後で、WLSドメインにある管理対象サーバー(たとえば、WebCenterドメイン上のWC_Portletサーバー)に新しいWSRPプロデューサをデプロイします。WSDL URLを情報ページ(http://%PRODUCER_HOST%/%APP_CONTEXT%/info)から取得して、それをメモしておきます。新しいWSRPプロデューサをページレット・プロデューサに登録するには、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項を参照してください。

19.6.1 Oracle WebLogic Portal用に開発されたWSRPポートレットの公開

Oracle WebLogic Portal (WLP)では、Javaポートレット、Java Server Facesポートレット、Java Server PageおよびHTMLポートレットなど、様々なポートレット・タイプをサポートしています(完全なリストは、Oracle WebLogic Portalポートレット開発ガイドの「ポートレット・タイプ」を参照してください)。リモート(プロキシ)ポートレットはWSRPポートレットであり、ページレット・プロデューサでWSRPプロデューサによってそのままページレットとして公開できます。

19.6.2 WLPをWSRPプロデューサとして使用したWLPポートレットの公開

WLPは、Java、ページ・フロー、JSP、JSFおよびStrutsのポートレットを、必須のWSRPインタフェース、オプションのインタフェースおよびいくつかの拡張インタフェースを含んだ"複合プロデューサ"として公開できます(詳細は、Oracle Fusion Middleware Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドのWebLogic Portalのプロデューサに関する項を参照)。その結果、ページレット・プロデューサはネイティブWLPポートレットをその他のすべてのWSRPポートレットとして消費できます。WLPとWebCenter共通コンシューマ間のWSRPの相互運用の構成とベスト・プラクティスについては、Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドの「Oracle WebCenter PortalおよびOracle PortalとのWSRPの相互運用」に記載されています。

注意:

WLPポータルは、デフォルトではバージョン9.2以降、WSRPに対応しています。それ以前のバージョンでは、ポートレットのプロパティを編集し、「Offer as Remote」プロパティをtrueに設定する必要があります。

19.6.3 WLP WSRPプロデューサとWebCenterコンシューマ間のWSセキュリティの構成

WebCenter共通コンシューマ(ページレット・プロデューサ)でWLPにより公開されたWSRPポートレットを消費するには、プロデューサとコンシューマの両方で構成する必要があります。

通常、WebLogic Portalによって公開されたWSRPポートレットを匿名ユーザーとして消費することはできないため、プロデューサとWebCenter共通コンシューマに対してWLP上でSAMLセキュリティを構成する必要があります手順は、Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドのWebCenter Portal: Frameworkアプリケーション・コンシューマとWebLogic Portalプロデューサ間のSAMLセキュリティに関する項に記載されています。これらの手順は包括的であり、次の調整が加えられています。

  • プロデューサの構成に関する項の第5項で、WSRPコンシューマでのキーストア情報の構成に関する手順はJDeveloperで実行します。この手順は、WebCenter共通コンシューマ(ページレット・プロデューサ)で完了する必要があります。WLSTまたはFusion Middleware Controlを使用すると、署名の別名やキーストア・パスワードを指定できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のWebCenter Portalドメイン・キーストアの設定に関する項を参照してください。

    注意:

    キーストア値を構成したら、JPS構成変更が選択されるようにするために、ページレット・プロデューサをホストしている管理対象サーバー(デフォルトではWC_Portlet)とWLS管理サーバーの両方を再起動する必要があります。

  • プロデューサの構成の第4項の手順では、発行者名の重要性は強調されていません。ここに入力される名前は、コンシューマにより送信された名前と一致する必要があります。Oracle JPSの場合、送信されたデフォルトの発行者IDはwww.oracle.comです。

19.6.4 ページレット・プロデューサでのWLP WSRPプロデューサの登録

ページレット・プロデューサでWLP WSRPプロデューサを登録するには、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項に記載されている新しいWSRPプロデューサの作成および構成の標準的な手順に従ってください。次の設定が含まれていることを確認します。

  • WSDL URL:

    http://%WLP_HOST%/%PORTAL_APP_NAME%/producer/wsrp-1.0/markup?WSDL

  • セキュリティ:

    トークン・プロファイル: 「WSS 1.0 Token with Message Integrity」を選択

登録後、新しいページレット・プロデューサ・リソースが自動的に作成され、ページレットに移入されて、このWSRPエンドポイントに関連付けられたWLPポートレットを表現します。

注意:

ポートレットへのユーザー・アイデンティティ伝播を可能にするには「ページレット・プロデューサからバックエンド・アプリケーションへのアイデンティティの伝播」の説明に従って、WLPとページレット・プロデューサの両方を構成する必要があります。(テスト目的の場合または認証なしでアクセス可能なポートレット・コンテンツの場合は、「セキュリティ」の「デフォルト・ユーザー」フィールドに有効なユーザー名を指定できます。)

19.6.5 サイトへのWLP WSRPポートレットの追加

WLP WSRPポートレットをサイト内のページに追加するには、「Oracle WebCenter Sitesへのページレットの追加」の手順を実行します。ページレット・コンテンツをロードするIFrameタグのsrc属性に使用するURLは、「RESTを使用したページレットへのアクセス方法」の「ドキュメント」を参照してください。

自動生成されたWSRPリソースとページレットは変更できません。WLPポートレットのマークアップの変更、たとえば、カスタムCSSスタイルの注入によりポートレットUIのルック・アンド・フィールを変更するためにページレット・プロデューサの機能を使用するには、新しいバージョンのリソースを作成する必要があります。ページレット・プロデューサ管理コンソールでWLP WSRPプロデューサ用に作成されたリソースを選択し、「コピー」をクリックします。リソースのクローン・バージョンは変更可能であり、インジェクタなどの要素を追加してページレットの機能をカスタマイズできます。

19.7 サイトにおけるWebCenter Portalサービスのページレットとしての消費

WebCenter Portalには、WebCenter Sitesでユーザーのコラボレーションが容易に実行できるように、お知らせやドキュメントなどのサービスやツールが組み込まれています。これらのツールの概要は、『Oracle Fusion Middleware Oracle WebCenter Portalの使用』の最新情報の入手に関する項および情報の整理に関する項を参照してください。

これらのサービスおよびツールをサイトで公開する場合のお薦めできる方法は、Oracle WebCenter Portal (11.1.1.6およびそれ以降)に組み込まれているサービス・プロデューサ・コンポーネントを利用して、関連するWSRPポートレットをページレット・プロデューサ内で消費することです。

次のポータル・ツールは、デフォルトではWSRPポートレットとして公開されています。

  • アクティビティ・ストリーム

  • ディスカッション・フォーラム

  • メール

  • ドキュメント・マネージャ

  • リスト

  • タグ・クラウド

  • ブログ

  • お知らせ

注意:

追加のツールを公開するには、サービス・プロデューサを新しいJSFページに拡張し、そのページにタスク・フローを追加します。

19.7.1 要件

『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の手順に従って、WebCenter Portalをインストールします。WebCenter Contentサーバー、ディスカッション・サーバー、ページレット・プロデューサを含むすべての依存コンポーネントもインストールされていて、構成済であることを確認します。詳細は、「要件」を参照してください。

19.7.2 セキュリティおよびシングル・サインオンの構成

サイト駆動のWebサイトからWebCenter Portalサービスへのアクセスを可能にするには、次の2つの前提条件があります。

  • WebサイトとWebCenter Portal間に共通のユーザー・ベースを作成する

  • WebサイトからWebCenter Portalへのユーザー・アイデンティティ伝播を確立する

次の各項で、これらの前提条件について説明します。

19.7.2.1 共通ユーザー・ベースの作成: LDAP統合

共通ユーザー・ベースを作成するには、WebCenter SitesとすべてのWebCenter Portalコンポーネントで使用される共通のLDAPリポジトリを構成する必要があります。LDAPサーバーを選択する際、それがWebCenter Portalコンポーネントを実行するWebLogic Serverに準拠していることを確認します。

WLSでのセキュリティ構成時に、次の点を忘れないようにしてください。

  • 「オーセンティケータ」の優先度を「SUFFICIENT」に設定します。

  • 「制御フラグ」(カッコ内)と認証プロバイダの順序を次のように設定します。

    • OAMアイデンティティ・アサータ(REQUIRED)

    • LDAPオーセンティケータ(SUFFICIENT)

    • デフォルト・オーセンティケータ(SUFFICIENT)

    • デフォルトのアイデンティティ・アサーション・プロバイダ: (SUFFICIENT)

19.7.2.2 ユーザー・アイデンティティ伝播の確立: OAM構成

ユーザー・アイデンティティ伝播を確立するには、Oracle Access Manager (OAM)を使用してWebCenter SitesおよびWebCenter Portal用にSSOソリューションを構成することをお薦めします。

OAMを使用している場合は、ユーザー・プリンシパル名がORACLE_REMOTE_USERヘッダーに渡されるように構成されていることを確認します。ObSSOCookieとOAM_REMOTE_USERの両方が、WebLogic Server上のOAMアイデンティティ・アサーション・プロバイダでアクティブに設定されている必要があります。

19.7.2.3 アイデンティティ・ストアでのGUID属性の構成

GUID属性値を指定して、アイデンティティ・ストアで使用される値がLDAP認証プロバイダで構成された値と一致していることを確認します。この値は、jps-config.xmlファイル内で構成されます。

使用しているLDAPオーセンティケータのGUIDをjps-config.xmlファイルに設定します。

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
<property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/>
<property value="oracle.security.idm.providers.stdldap.JNDIPool" name="CONNECTION_POOL_CLASS"/>
<property value="GUID=uuid" name="PROPERTY_ATTRIBUTE_MAPPING"/>
</serviceInstance>

19.7.2.4 ディスカッション・サーバー用SSOの構成

ディスカッションを使用するには、WebLogic Serverでオーセンティケータの順序付けを行う前に(デフォルトのオーセンティケータおよびデフォルトのアイデンティティ・アサーション・プロバイダを使用)、ディスカッション・サーバーをSSO用に構成します。WLSTを使用してディスカッション・サーバー用にSSOを構成することもできます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のディスカッション・サーバーをSSO対応に構成する方法に関する項を参照してください。

19.7.3 WSRPポートレットとして公開されたWebCenterサービスのインポート

WebCenterサービスを公開するWSRPポートレットをページレット・プロデューサにインポートするには、Enterprise Manager、WLSTまたはページレット・プロデューサ管理コンソールを使用して、サービス・プロデューサをページレット・プロデューサにWSRPプロデューサとして登録するだけです。

図19-27では、ページレット・プロデューサ管理コンソールでのWSRPエンドポイントの登録例を示しています。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』のページレット・プロデューサのWSRPポートレット・プロデューサに関する項を参照してください。

図19-27 ページレット・プロデューサ管理コンソール - WSRPエンドポイント

図19-27の説明が続きます
「図19-27 ページレット・プロデューサ管理コンソール - WSRPエンドポイント」の説明

このページの「セキュリティ」セクションの「トークン・プロファイル」は、サービス・プロデューサをサポートするために「WSS 1.0 SAML Token」に設定する必要があります。また、ページレット・プロデューサで設定されたサービス・プロデューサに対するリクエストに適切な実行タイムアウトを入力します(デフォルトは30秒)。

登録が完了すると、サービス・プロデューサはページレット・プロデューサ管理コンソールにリソースとして表示され、プロデューサによって公開されたすべてのWSRPポートレットがリソースのページレット・コレクションにリストされます。

19.7.3.1 サイト・ページへのページレットの追加

WebCenterサービスを公開しているページレットはすべて、Oracle WebCenter Sitesへのページレットの追加に関する項で説明する手順に従って、WebCenter Sitesのページに追加できます。図19-28に、WebCenter SitesにあるサンプルのAviSportsサイトのページに埋め込まれたドキュメント・マネージャ・サービスを示します。

注意:

自動生成されたWSRPリソースとページレット(サービス・プロデューサに関連付けられているものなど)は変更できません。インジェクタを追加したり、その他の変更を加えるには、編集可能なバージョンを作成する必要があります。ページレット・プロデューサ管理コンソールでリソースを選択し、「コピー」をクリックします。リソースのクローン・バージョンは編集可能であり、インジェクタなどの各種要素を追加してページレットの機能をカスタマイズできます。

図19-28 ドキュメントが埋め込まれたサンプルのAviSportsサイト

図19-28の説明が続きます
「図19-28 ドキュメントが埋め込まれたサンプルのAviSportsサイト」の説明

19.8 EBS11iを使用したページレットとしてのアプリケーションの消費

この項では、Oracle E-Business Suite 11i Order InformationモジュールのUIをページレットとして消費する場合の詳細な手順を説明します。ここでは、自動ログイン、ナビゲーション抑止、スタイル変更、およびURLリライトについて説明します。

この例は、Oracle SSOで保護されているEBS 11iインスタンスを使用して作成されました。この例では、次の共通用語と変数を使用しています。

  • %EBS_HOST%: EBSホストのルートURL(http://my-ebs.company.com:port/など)

  • %OSSO_HOST%: OSSOホストのルートURL(http://sso.company.com:port/など)

この項では、次の項目について説明します。

19.8.1 基本のURLマッピング(プロキシ)に対するリソースの作成

次の手順によって、ページレット・プロデューサ内の新しいEBSリソースに対して基本的なURLマッピングを設定します。

  1. 次の設定を使用して新しいWebリソースを作成します。
    • 名前: EBS 11(または任意の名前)

    • ソースURL: %EBS_HOST%

      UIで使用されるURLと見間違いされないように、このURLはあまり具体的にしないようにしてください

    • 宛先のURL: /ebs11/(または任意のもの)

    • URLリライト: オン

    • DHTMLリライト: オン

  2. 「保存」をクリックします。

19.8.2 自動ログインの構成

この手順では、EBSシステムがOSSOによって保護されていて、ページレット・プロデューサがSSOに関与する(WebサイトがSSOで保護されていない場合の一般的なシナリオ)のではなく、「自動ログイン」フォームを提供するように構成されることを前提としています。EBS資格証明はすべてのユーザー用に共有することも(テスト用に有効)、ページレット・プロデューサの資格証明ボールトにユーザー別に格納することもできます。

  1. 次の設定を使用して新しいWebリソースを作成します。
    • 名前: OSSO(または任意の名前)

    • ソースURL: %OSSO_HOST%

    • 宛先のURL: /osso/(または任意のもの)

    • URLリライト: オン

    • DHTMLリライト: オフ

  2. 「保存」をクリックします。
  3. 新規に作成されたOSSOリソースの下で、次のように「フォーム・ログイン」オプションを使用して「Autologin」を構成します。
    • ログイン・フォームの識別: URL - %OSSO_HOST%/sso/jsp/login.jsp

    • フォームの送信場所: URL - %OSSO_HOST/sso/auth - POST

    • フォーム・フィールド:

      appctx: 生成済

      locale: 生成済

      password: 非保護またはユーザー・ボールト

      site2pstoretoken: 生成済

      ssousername: 非保護またはユーザー・ボールト

    • v: 生成済

  4. 「保存」をクリックします。

注意:

ログイン・フォームのフィールド名は通常、バックエンド・リソースを保護しているログイン・ページのHTMLソースを調べることによって取得されます。

19.8.3 ページレットの作成

この手順では、ページレットをEBS Order Informationモジュールの順序ステータス・ページに関連付けます。新しいページレットを作成するには、作成したEBSリソースの下で「ページレット」セクションを選択して「作成」アイコンをクリックします。次の設定を使用して新しいページレットを作成します。

  • 名前: order_status (または任意の名前)

  • ライブラリ: ebs11 (または任意のもの)

  • URL接尾辞: OA_HTML/RF.jsp?function_id=1005664&resp_id=22480&resp_appl_id=660&security_group_id=0&lang_code=US

  • インラインのリフレッシュ: オフ

構成済のページレットをテストするには、「ドキュメント」ページで、そのページレットにRESTリンク経由でアクセスします。ログインしなくても「Sales Order」ページが表示されます(ページレットでユーザー・ボールトを使用して資格証明を格納していて、そのページレットにはじめてアクセスする場合を除きます)。このページから「簡易検索」を使用て、ワイルドカード文字として'%'を使ってオーダーを検索できます。

19.8.4 修正構成の作成

ページレットの登録後に、プロキシ設定されたマークアップでのURLリライト関連の問題に対応するため、あるいは単にマークアップのスタイルを変更したり不必要な要素を非表示にするために、ページレットで追加機能(パーサー、インジェクタ、クリップなど)が必要になる場合があります。この項では、EBSでOrder InformationのUIを公開するサンプルのページレットに適用された修正構成について説明します。

この項では、次の内容について説明します。

19.8.4.1 ポップアップURLリライト用のプラガブル・パーサーの作成

パーサーを使用して、コンテンツを解析したり、リライトする必要のあるURLを検索するために、ビルトイン・ロジックを補足または変更することができますビルトイン・パーサーがURLの識別に失敗した場合は、カスタム・パーサーを使用してこの失敗を修正することができます。EBS 11i UIの場合、この手順は「拡張検索」でのポップアップ処理の修正に必要です。

EBSリソースの下で、次の設定を使用して新しいパーサーを作成します。

  • 名前: popupRewriter(または任意の名前)

  • URLフィルタ: *.jsp*

  • 基本パーサーの使用: オン

  • フラグメントの場所

    • var _jspDir='(.*?)'; (タイプ静的URL)

    • <frame .? src="(.?) (タイプ静的URL)

図19-29にpopupRewriterの設定を示します。

19.8.4.2 フレーム・バストを無効化するインジェクタの作成

インジェクタによって、プロキシ設定されているリソース・ページの指定された場所にコンテンツが挿入されます。コンテンツには、HTML、CSS、JavaScript、およびページレット宣言も含めて、任意のテキストが使用できます。空のインジェクタを使用して、不必要なコンテンツをページから削除することもできます。次のインジェクタはEBSページレットに対して作成されたものですが、その目的は、ユーザーが職責を選択するよう求められる最初のページで発生するページの継承をEBSページレットが行わないようにすることです。

EBSリソースの下で、次の設定を使用して新しいインジェクタを作成します。

  • 全般

    • 名前: frameBustDisabler

    • URLフィルタ: <none>

    • MIMEフィルタ: text/html

    • 挿入位置: target=_topを置換

  • コンテンツ: (テキスト)alt=''

図19-30に、新しいインジェクタのパラメータ設定を示します。

図19-30 frameBustDisablerインジェクタ

図19-30の説明が続きます
「図19-30 frameBustDisablerインジェクタ」の説明

19.8.4.3 iFrameを自動サイズ変更するインジェクタの作成

よりシームレスに消費側ページに統合するには、コンテンツを収められるように動的にサイズ変更することによって、ページレットiFrameがよりインライン・コンテンツらしく動作するように構成できます。詳細は、このドキュメントの「IFrameの自動サイズ変更の有効化」を参照してください。

19.8.4.4 JavaScriptの挿入によるクリッピングの設定

ページレットとして公開されたページ要素を抑止するオプションの1つとして、ページレット・プロデューサで使用可能なグラフィカル・クリッピングまたは正規表現ベースのクリッピングを使用してクリップを作成します。ただし、お薦めできる方法は、プロキシ設定されたページに注入されているカスタムJavaScriptを使用することです。この方法では、抑止する要素の識別ルールを動的に調節する必要性や、ページ上の複数要素の抑止ルールを調整する必要性に容易に適応できるため、より柔軟に対応できます。

カスタムJavaScriptは、プロキシ設定されたリソースにインジェクタを使用して追加できます。EBS 11i標準ヘッダーとナビゲーション要素を抑止するには、次のインジェクタ定義を使用して、ページのロード時に不必要な要素を非表示にするJavaScriptのスニペットを挿入します。(ページレット・プロデューサの標準クリッパ機能は、EBS Web UIが複雑であるため使用しません。)

EBSリソースの下で、次の設定を使用して新しいインジェクタを作成します。

  • 全般:

    • 名前: nav_suppressor(または任意の名前)

    • URLフィルタ: <none>

    • MIMEフィルタ: text/html

    • 挿入位置: </body>の前

  • コンテンツ: (テキスト - 次のコンテンツをコピーおよび貼付け)

    <script type="text/javascript">
    // this script is injected into the page by ensemble
    // it hides header and footer tables at page load
     
    //register handler function to the page load event
    if (window.addEventListener) {
    window.addEventListener('load', hideHeaderFooter, false);
    } else if (document.attachEvent) {
    window.attachEvent('onload', hideHeaderFooter);
    }
     
    //this function does the actual hiding
    function hideHeaderFooter() {
    var form =document.forms[0];
     if (typeof(form) =='undefined') return;
     //main span is form's second child span
     var spansFound =0;
     var mainSpan =null;
     for (var i =0; i < form.childNodes.length; i++) {
    var child =form.childNodes[i];
     if (child.tagName && child.tagName.toLowerCase() =='span') {
    if (++spansFound ==2) {
    mainSpan =child;
     break;
     }
    }
    }
    if (typeof(mainSpan) != "undefined" && mainSpan != null) {
    for (var i =0; i < mainSpan.childNodes.length; i++) {
    var child =mainSpan.childNodes[i];
     if (child.tagName && child.tagName.toLowerCase() =='table') {
    child.style.display ='none';
     }
    }
    }
    }
    //call this function directly
    hideHeaderFooter();
    </script>
    

19.8.4.5 ページレットのスタイル変更用にインジェクタを作成

消費側のページでEBSページレットが見栄えよく収まるようにするには、インジェクタを使用して元のCSSをオーバーライドするスタイルを追加できます。

次のインジェクタ定義の例では、WebCenter SitesにおけるサンプルのAviSports Webサイトのスタイル変更の実装方法を示しています。

注意:

オーバーライドが適切に機能するためには、インジェクタによるスタイル定義がバックエンド・アプリケーションによって定義されたスタイルの後に置かれることが重要です。次の例では、コンテンツはページの<HEAD>セクションの終わりに注入されています。

EBSリソースの下で、次の設定を使用して新しいインジェクタを作成します。

  • 全般:

    • 名前: avisports_styles

    • URLフィルタ: <none>

    • MIMEフィルタ: text/html

    • 挿入位置: 次より前 </head>

  • コンテンツ: (テキスト - 次のコンテンツをコピーおよび貼付け)

    <style>
    * {
    font: 11px Arial,Helvetica,sans-serif; 
    }
    body {
    background: url("http://sites-host:port/cs/avisports/images/BlueSliver.png") repeat-x scroll center bottom transparent;
    }
    .OraTableCellText, .x1l, .OraTableCellNumber, .x1n, .OraTableCellIconButton, .x1p, .OraTableCellSelect, .x55, 
    .OraTableControlBarTop, .x1i, .OraTableControlBarBottom, .x1j {
    background-color: #eceef1;
     border-color: #0b2a55;
    }
    .OraTableColumnHeader, .x1r, .OraTableSortableColumnHeader, .x20, .OraTableSortableHeaderLink, .x23 {
    background-color: #0b2a55;
     border-color: #F7F7E7;
     color: #336699;
    }
    .OraTableHeaderLink, .x24, .OraTableColumnHeaderNumber, .x1s, .OraTableColumnHeaderIconButton, .x1t {
    background-color: #0b2a55;
     color: #ffffff;
    }
    .p_InContextBrandingText, .x2l, .OraHGridNavRowInactiveLink, .x3v, .OraNavBarInactiveLink, .x42, 
    .OraBINavBarInactiveLink, .x7n, .OraBINavBarInactiveLink_small, .x7o {
    color: #000000;
    }
    .OraLink:link, .xd:link, .OraBreadCrumbs, .xh, .OraBulletedList a, .xj a, .OraLinkText, .x2v, 
    .OraHGridNavRowActiveLink, .x3u, .OraNavBarActiveLink, .x41, .OraBINavBarActiveLink, .x7l, .OraBINavBarActiveLink_small, .x7m {
    color: #0b2a55;
    }
    .OraBreadCrumbs a, .xh a {
    color: #0b2a55;
    }
    </style>

19.8.4.6 ページレットのテスト

これでEBS11リソースには、図19-31に示すように、ページレット、カスタム・インジェクタ、およびカスタム・パーサーが含まれるようになりました。

図19-31 EBS11プロジェクト・リソース

図19-31の説明が続きます
「図19-31 EBS11プロジェクト・リソース」の説明

ページレットをテストするには、「ドキュメント」ページを参照し、次に示すURLを使用して、「example.com」をローカル・ホストIDに置き換えます。

http://example.com:8889/pagelets/inject/v2/pagelet/ebs11/order_status?content-type=iframe&csapi=true&ifheight=300px

19.8.4.7 最終結果

次のスクリーンショットは、iFrameのページレット・アクセス用のREST URLを使用してWebCenter SitesにあるサンプルのAviSportsサイトのページに埋め込まれたEBS 11i Order Informationの画面を示しています。

19.8.4.8 トラブルシューティング

イメージが適切にレンダリングされない場合は、DHTMLリライトが有効になっていることを確認します。(DHTMLリライトの設定はリソースの「一般」ページにあります。)

19.9 ページレット・プロデューサを使用したOpenSocialガジェットの消費

ページレット・プロデューサは、次の機能を公開するOpenSocialコンテナです。

  • ユーザー(ピープル・コネクションを公開)

  • アクティビティ(アクティビティ・ストリームを公開)

  • アプリケーション・データ(ガジェットのパーソナライズをサポート)

  • Pub-Subメカニズム

ユーザーおよびアクティビティ機能には、WebCenter Portalが必要です。ユーザーおよびアクティビティ機能を使用するには、WebCenterDSのターゲットとして、WC_Portlet管理対象サーバー(つまり、ページレット・プロデューサ)を指定します。アプリケーション・データに対して、ページレット・プロデューサでは、ユーザー、インスタンスおよびページレット・スコープのプリファレンスをサポートします。

次に例を示します。

  1. ページレット・プロデューサを開き、新しいOpenSocialリソースを作成します。

  2. 必要に応じてURLとポリシーを定義します。

  3. 新しいページレットを作成し、外部ガジェットのURLを指定します。

    例:

    http://bayareacoder.com/gogo/localweather/localweather.xml

  4. ガジェットでプリファレンスをサポートする場合、必須パラメータを構成します(図19-32および図19-33を参照)。

    図19-32 プリファレンス・エディタ

    図19-32の説明が続きます
    「図19-32 プリファレンス・エディタ」の説明

    図19-33 「ページレット・パラメータ」ダイアログ

    図19-33の説明が続きます
    「図19-33 「ページレット・パラメータ」ダイアログ」の説明
  5. ガジェットXMLファイルを作成またはアップロードします(図19-34を参照)。

    図19-34 ページレット・プロデューサ内のアクティビティJavaScriptおよびXMLオプション

    図19-34の説明が続きます
    「図19-34 ページレット・プロデューサ内のアクティビティJavaScriptおよびXMLオプション」の説明

    「名前」フィールドに指定するパスは、ページレット・プロデューサがファイルの提供に使用する'仮想'URLであり、任意のパスまたは名前を使用できます。

  6. 新しいガジェットに必要な他のファイル(JavaScriptファイルやイメージなど)を作成またはアップロードしたら、作業は完了です。

19.10 有効なジオメトリ管理とページ区切りのガイドライン

有効なジオメトリ管理を実施すると、ページでのタスク・フローのサイズ設定と配置を効率良く実行できます。タスク・フローが適切に設計されていない場合、応答時間が遅いページまたはコンポーネント間に不要なスクロール・バーや空白が大量に表示されるページが生成されます。たとえば、データをストレッチするコンテナ(Show Detail Frameコンポーネントなど)をタスク・フローで使用していて、そのコンテナの内部に非常に少量のデータしか存在しない場合、タスク・フローではデータの下に大量の空白が表示されます。設計が不適切な場合、大量のデータが表に表示されるタスク・フローで、スクロールが遅くなったり、予期しない動作を示したりする可能性もあります。これらの問題を避けるために、大量のデータ・セットを表示する際は必ず、従来のページ区切りモデルを使用するフロー・タスク・フローを設計してください。

WebCenter Portalの新しいタスク・フローを設計する際は、この項のガイドラインに従ってください。また、WebCenter Portalの既存のタスク・フローを編集する際も、必ずこの項のガイドラインに従ってください。

この項には次のトピックが含まれます:

19.10.1 インジェクタでのJavaScriptの使用

タスク·フローで不要な空白を回避するためには、タスク·フロー·コンテンツがフローし、タスク·フロー·コンテナによってストレッチされていないことを確認する必要があります。ストレッチ・タスク・フローは、コンテナの高さにストレッチされたもので、フロー・タスク・フローは、ストレッチ・コンテナやタスク・フロー自身の固定された高さではなく、そのコンテンツによって決定されます。データ量の少ないフロー・タスク·フローは、データ量の多いフロー・タスク・フローよりも短くなります

フロー・タスク・フローを設計するには、次のことを保証する必要があります。

  • タスク・フローの子コンポーネントの高さが固定されていない。

  • タスク・フロー・リージョンを囲むShow Detail Frameコンポーネントの高さが(そのcontentStyle属性を使用して)固定されていない。

19.10.2 インジェクタでのSSLの使用

SSLリソースを消費するには、次のものを含むHTTPS経由のページレット・プロデューサ接続が必要です。

  • WLSとページレット・プロデューサ間のセキュアなポート・マッピング

  • HTTPSを経由したコンテナへのアクセス

インジェクタでは、ページレット・プロデューサによってプロキシされるHTMLマークアップを、次のように変更できます。

  • URLパターン(リソース・スコープ)に基づきます。

  • MIMEタイプに基づきます。

  • 場所(上部または下部)またはテキストの完全一致(前、後、置換)に基づきます。

  • コンテンツ・ページで挿入内容を定義します。

19.11 高度なURLリライト

この項では、ページレット・プロデューサの自動ログイン機能を使用する方法、およびカスタム・パーサーを設計する方法について説明します。

この項では、次の項目について説明します。

19.11.1 自動ログインの使用

自動ログインを使用すると、ユーザー名およびパスワード資格証明をバックエンド・リソースに渡すことができます。これらは、次のいずれかのものとして渡すことができます。

  • 静的な資格証明: すべてのユーザーに1つのセット

  • リソースへの初回アクセス時にユーザーから動的に取得し、セキュアな資格証明ボールトに格納

  • ユーザー・プロファイル(ユーザー名を取得して渡す)

自動ログインでサポートされる認証メカニズムは、次のとおりです。

  • 基本ログイン

  • フォーム・ログイン(次の例で使用)

  • NTLMログイン

  • Kerberosログイン

図19-35の例と、次のコード・スニペットは、自動ログインを使用してログイン・ページをリダイレクトする方法を示しています。

図19-35 ページレット・プロデューサ - 自動ログインの例

図19-35の説明が続きます
「図19-35 ページレット・プロデューサ - 自動ログインの例」の説明

次のコードは、図19-35の設定を反映しています。

<form action="wwv_flow.accept" method="post" name="wwv_flow" id="wwvFlowForm" autocomplete="off">
 <input type="hidden" name="p_flow_id" value="53557" id="pFlowId" />
<input type="hidden" name="p_flow_step_id" value="101" id="pFlowStepId" />
<input type="hidden" name="p_instance" value="724836084846701" id="pInstance" />
<input type="hidden" name="p_page_submission_id" value="1431956852758801" id="pPageSubmissionId" />
<input type="hidden" name="p_request" value="" id="pRequest" /> 
<div id="login"> <div id="messages"></div> <div id="login-main">
<table id="myapp_layout_45149677586857064102" border="0" class="formlayout" summary="" role="presentation" datatable=0 >
<tr><td align="right"><label for="P101_USERNAME" tabindex="999“><a class="optional-w-help"
 href="javascript:popupFieldHelp('45149677686365064111','724836084846701')" tabindex="999">
User Name</a></label></td> <td colspan="1" rowspan="1" align="left"><input
type="hidden" name="p_arg_names" value="45149677686365064111" /><input type="text"
id="P101_USERNAME" name="p_t01" value="" size="20" maxlength="100" class="text_
field" /></td></tr><tr><td align="right"><label for="P101_PASSWORD" tabindex="999"><a class="optional-w-help"
href="javascript:popupFieldHelp('45149677888869064121','724836084846701')" tabindex="999">Password</a></label></td> <td colspan="1" rowspan="1"
align="left"><input type="hidden" name="p_arg_names" value="45149677888869064121"/> <input type="password" name="p_t02" size="20"
maxlength="100" value="" id="P101_PASSWORD" class="password" onkeypress="return
submitEnter(this,event)" /> <input type="button" value="Login"onclick="myapp.submit('LOGIN');" id="P101_LOGIN" /> </td></tr>
</table> Please refer to "Using Myapp" in the Myapp User's Guide for more
information.</div> </div> <input type="hidden" name="p_md5_checksum" value="" />
<input type="hidden" name="p_page_checksum" value="D95DBE8607E971820E98E93FC0EC064E" /></form>

19.11.2 カスタム・パーサーの使用

パーサーを使用すると、URL解析の組込みロジックを拡張または変更できます。URLフィルタと正規表現を使用すると、ページ内でパーサーによって変更される部分を絞り込むことができます(図19-36)。

図19-36 ページレット・プロデューサ - カスタム・パーサーの例

図19-36の説明が続きます
「図19-36 ページレット・プロデューサ - カスタム・パーサーの例」の説明

正規表現を使用すると、解析するHTMLフラグメントを指定できます。カッコで囲まれた最初のグループ化表現はフラグメントを識別し、残りの表現はそれを検索するためのコンテキストを提供します。プラガブル・パーサー・フレームワークを使用すると、プロキシが様々なタイプのコンテンツを、MIMEタイプ、HTTPヘッダーまたはURLに基づいてどのように認識するかを微調整できます。

この例では、Flashを動作させるために、ページ・マークアップ内の2つの場所にある3つのURLを変更する必要があります。

<embed src=“ /i/flashchart/anychart_5/swf/OracleAnyChart.swf?
XMLFile=http://example.com/pls/myapp/myapp_ util.flash?p=53557:1:74175370346201:FLOW_FLASH_CHART5_R45192463162785599619_en"
 <param name="movie" value=“/i/flashchart/anychart_5/swf/AnyChart.swf?
XMLFile=http://example.com/pls/myapp/myapp_ util.flash?p=53557:1:74175370346201:FLOW_FLASH_CHART5_R45192463162785599619_en"

これを行うには、次の3つの正規表現(図19-36の「正規表現」の下)を使用します。

  • XMLFile=(.*?)“

  • param name="movie" value="(.*?\.swf)

  • embed src="(.*?\.swf)