20 ページレットの作成: 例および高度なトピック
この章の内容は次のとおりです。
単純なページレットの作成(例)
この項では、ページレット・プロデューサを使用してWebページをプロキシする方法について簡単に説明します。ここでは、単純な静的Webページ"Hello World"をプロキシし、そのページから1つのセクションを切り取り、後からWebCenter PortalやWebCenter Interactionで挿入できるページレットとして独自のアプリケーション・ページに表示します。
この項には次のトピックが含まれます:
ページレット・プロデューサの初期設定の構成
この例では、ページレット・プロデューサ・サーバーがhttp://pageletserver.company.com:8889/pagelets/
で実行されているものとします。
-
まず、そのページレット・プロデューサが稼働しているかどうかを確認します。
これを行うには、単純にそのURL (
http://pageletserver.company.com:8889/pagelets/
など)にアクセスする必要があります。図20-1は、返される結果を示しています。 -
管理者資格証明を使用して、ページレット・プロデューサの管理画面にログインします。
たとえば、
http://pageletserver.company.com:8889/pagelets/admin
を使用します -
プロキシ・サーバーを経由してインターネットに接続する場合は、ページレット・プロデューサ設定でプロキシを構成する必要があります。
-
ナビゲータ・ペインの「移動先」ドロップダウン・リストで、「設定」を選択します。
-
「プロキシ」をクリックします。
-
図20-3に示すように、プロキシ・サーバーの構成を入力します。
-
リソースの作成
まず、Webページのリソースを作成する必要があります。これにより、ページレット・プロデューサに、Webページのすべてのサブパスをプロキシする必要があることが通知されます。また、Webページのプロキシ方法に関する共通ルールの設定が可能になり、ページレットのコンテナとして提供されます。
ページレットの作成
次はHello Worldページレットを作成します。
ライブラリ名には任意の名前を指定でき、リソース名と一致している必要はありません。これはページレットの論理グループ化に使用されます。また、ページレットを複数のリソースから同じライブラリに含めたり、ページレットごとに新しいライブラリを作成できます。
ページレットを保存したら、次の場所からそのページレットにアクセスできます。
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を使用することもできます。
「ドキュメント」ページのURLをクリックすると、次のような画面が表示されます。
WebCenterポータルでのページレットの消費(例)
この項では、単純なHello WorldページレットをWebCenter Portal内で消費する方法の例を示します。先に進む前に、まず「単純なページレットの作成(例)」の手順に従って、この例で使用する"Hello World"ページレットを作成します。
この項では、次の内容について説明します。
WebCenter Portalへのページレット・プロデューサの登録
新しく作成したページレットをWebCenter Portalから使用するには、まずページレット・プロデューサを登録する必要があります。
WebCenter Interactionでのページレットの消費(例)
この項では、単純なHello WorldページレットをWebCenter Interaction (WCI) 10.3.0以降で消費する方法の例を示します。先に進む前に、まず「単純なページレットの作成(例)」の手順に従って、この例で使用する"Hello World"ページレットを作成します。
この項では、次の内容について説明します。
ページレット・プロデューサ・リモート・サーバーの登録
新しく作成したページレットをWCIから使用するには、まずページレット・プロデューサを登録する必要があります。
-
管理者としてWCIにログインします。
-
「管理」をクリックします。
-
次のステップに従って、すべてのページレット・プロデューサ関連のオブジェクトを格納するフォルダを作成します。
-
「オブジェクトの作成」ドロップダウン・リストを開き、「管理フォルダ」を選択します。
-
「名前」に
「PageletProducer」
と入力し、「OK」をクリックします。
-
-
新しく作成した
PageletProducer
フォルダをクリックします。 -
「オブジェクトの作成」ドロップダウンを開き、「リモート・サーバー」を選択します。
-
「ベースURL」フィールドに、
http://pageletserver.company.com:8889/pagelets
と入力します(この例では、これがページレット・プロデューサのアドレスになります)。 -
「終了」をクリックします。
-
PageletProducer
フォルダを選択し、「名前を付けて保存」フィールドにPagelet Producer Remote Server
と入力します。 -
「保存」をクリックします。
これで、PageletProducerフォルダ内にページレット・プロデューサ・リモート・サーバー接続が作成されました。
Oracle WebCenter Sitesでのページレットの消費(例)
この項は、既存のWSRPポートレットまたは、Oracle EBSなどのバックエンド・アプリケーションにより公開されるWeb UIの要素も含めて、Oracle WebCenter Sites 11gの各ページにコンテンツを統合する必要のある開発者を対象としています。開発者はOracle WebCenter SitesおよびOracle WebCenterページレット・プロデューサに精通しており、Webテクノロジを十分に理解している必要があります。
この項では、次の内容について説明します。
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を使用したページレットへのアクセス方法」を参照してください。
IFrameの自動サイズ変更の有効化
ページレットをよりシームレスに消費側ページに統合するには、コンテンツを収められるように動的にサイズ変更することによって、ページレットiFrameがよりインライン・マークアップらしく動作するように設定できます。この機能を有効にするには、サイトとページレット・プロデューサの両方でさらに構成を加える必要があります。
この項では、WebCenter Sitesに同梱されているAviSportsサンプル・サイトを使用します。このサイトに新しいアセットを追加するには、サイト管理ページにログインして、図20-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サイズ設定を使用する必要があります。
ページレット・スタイルの変更
消費側WebCenter Sitesのページでページレットが見栄えよく収まるようにするには、インジェクタを使用して元のCSSをオーバーライドするスタイルを追加することもできます。オーバーライドが適切に機能するためには、インジェクタによるスタイル定義がバックエンド・アプリケーションによって定義されたスタイルの後に置かれることが重要です。次の例では、置換CSSを<HEAD>セクションの末尾に注入することで、これを処理しています。
ページレットのスタイルを変更するには、ページレット・プロデューサ管理コンソールを使用して新しいインジェクタをページレットに追加します。ページレットを開き、「インジェクタ」を選択して、次の設定で新しいインジェクタを作成します。
-
全般
-
名前: new_styles (または任意の名前)
-
URLフィルタ: <none>
-
MIMEフィルタ: text/html
-
インジェクタの場所: </head>の前
-
-
コンテンツ
Injector Location: Before </head>
「EBS11iを使用したページレットとしてのアプリケーションの消費」には、WebCenter SitesでサンプルのAviSportsサイトを適合させるためにEBS UIのスタイル変更に使用されるインジェクタの作業例が含まれています。
アイデンティティ伝播の使用
ページレット・プロデューサの中心的な目的は、バックエンド・アプリケーションをプロキシ設定することです。ページレット・プロデューサはブラウザとバックエンド・アプリケーションの仲介役として動作するため、アイデンティティ伝播を次の2つの部分に分ける必要があります。
ページレット・プロデューサでのアイデンティティの確立
ページレット・プロデューサは通常、図20-21に示すようなIFrameを使用して、WebコンテンツをWebCenter Sitesに挿入します。
コンテンツはIFrameとして注入されるため、ユーザーIDは、図20-22に示すようにサイト・コンテナとページレット・プロデューサ・コンテナの両方に設定されている必要があります。図20-22では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていることに注意してください。
ブラウザと2つのコンテナ間でアイデンティティを管理する理想的な方法は、図20-23に示すようにOracle Access Manager (OAM)を使用することです。図20-23では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていて、OAMアクセス・サーバーが除外されていることに注意してください。また、この構成は11g以前のバージョンではサポートされていないことにも注意してください。
WebCenter Sites11g用にOAMを設定する場合は、Oracle WebCenter Sitesでサポートするソフトウェアの構成の「Oracle Access Manager統合の設定」の章を参照してください。
ページレット・プロデューサにより指定されたログイン・ページの使用
OAMを設定する前に、サイトでページレット・プロデューサの統合をテストしておくと役立つ場合があります。OAMを使用しないと、ユーザーはページレット・プロデューサとサイトでそれぞれ別々に認証する必要があります(図20-22を参照)。この項では、ページレット・プロデューサでの個別認証の構成方法について説明します。
OAM SSOがページレット・プロデューサまたはサイトのどちらかに存在していない場合は、必ずページレット・プロデューサからログイン・フォームが表示されるようにして、図20-24に示す認証スキームをサポートする必要があります。
ページレット・プロデューサでログイン・フォームが表示されるようにするには:
ページレット・プロデューサからバックエンド・アプリケーションへのアイデンティティの伝播
アイデンティティの確立方法は、次の各項で説明するようにアプリケーションのタイプによって異なります。
WSRP/JPDKポートレット
WSRPポートレットは、アイデンティティ伝播のためにWSSトークンを使用する必要があります。セキュリティ・トークンの構成方法の詳細は、『Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項と、「WSRPポートレットのページレットとしての消費」を参照してください。
アイデンティティを必要とするOracle PDK-Javaポートレットごとに、外部アプリケーションのログイン・フォームによって提供される情報に基づいて資格証明が渡されます。詳細は、『Oracle WebCenter Portalの管理』の「外部アプリケーションの管理」およびOracle PDK-Javaポートレット・プロデューサの登録に関する項を参照してください。
ネイティブ認証(非SSO)により保護されたスタンドアロン・バックエンド・アプリケーション
ページレット・プロデューサには「自動ログイン」という機能があり、この機能によってページレット・プロデューサはバックエンド・アプリケーションにより確立されたネイティブ認証メカニズムと相互作用できます。
自動ログインによるアイデンティティ伝播
バックエンド・アプリケーションにはそれぞれ独自の認証手段があるため、必要な資格証明を収集するには、ページレット・プロデューサで独自のログイン・プロンプトを開始する必要があります。ページレット・プロデューサのリソースは、資格証明を基本的な認証ヘッダー、NTLMトークンまたはKerberosトークンとしてバックエンド・アプリケーションに送信し、さらにフォーム・ベースの認証を(通常はセッションCookieを介して)管理するように構成できます。自動ログインの構成の詳細は、「自動ログインの構成方法」を参照してください。
ノート:
「ユーザー・ボールト」を使用するように「ユーザー名」フィールドと「パスワード」フィールドを設定して、バックエンド・アプリケーションへのアクセスに必要なユーザー自身の一意の資格証明を入力するプロンプトが各ユーザーに表示されるようにします。
SSOにより保護されたスタンドアロン・バックエンド・アプリケーション
バックエンド・アプリケーションに適切な自動ログイン設定を決定することは、かなり大変な場合があります。この作業では、リクエスト・ヘッダーの参照、リダイレクトの確認、マークアップ(ときには動的に生成されたもの)の調査が必要になります。この調査および構成プロセスは、自動ログインが必要なアプリケーションが複数存在する場合は、気の滅入るような作業になりかねません。したがって、Oracle Access Manager (OAM) SSOまたはOracle SSO (OSSO)が使用可能な場合は、バックエンド・アプリケーションを保護するためにこれらのシングル・サインオン・ソリューションの1つを使用することを強くお薦めします。
バックエンド・アプリケーションがOAMで保護されると、次のサブセクションで説明するように、次の2つの方法でページレット・プロデューサが資格証明を提供できるようになります。
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をプロキシしようとしないかぎり、すべて実行されます。この項の以降の部分では、サイト統合のコンテキストでこれが実行できる方法を詳しく説明します。
設定例
この例では、図20-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
)。
バックエンド・アプリケーションを直接コールするようにページレット・プロデューサを設定(WebGateをバイパス)することにより、ページレット・プロデューサで受信されるすべてのOAMセキュア・ヘッダーは、バックエンド・アプリケーションをホストしているアプリケーション・サーバー上のOAMアイデンティティ・アサーション・プロバイダに渡されます。バックエンド・アプリケーションをホストしているアプリケーション・サーバー上のOAMアイデンティティ・アサーション・プロバイダは、OAMヘッダーを受信すると、適切なユーザー・プリンシパルを設定します(図20-26を参照)。図20-26では、2つの認証スキーム間での共有が前提となっているユーザー・ディレクトリが省略されていることに注意してください。また、OAMアクセス・サーバーも除外されています。
ノート:
WebGateをバイパスするようにページレット・プロデューサを設定するとシングル・サインオンが実行できますが、このソリューションはいつでも適用できるわけではありません。WebGateをホストしているOHSサーバーがバックエンド・アプリケーションのロード・バランシングも管理している場合は、WebGateをバイパスすることによってロード・バランシングもバイパスされます。アプリケーションへのトラフィックはすべて1つのサーバーにルーティングされます。この場合は、「自動ログインとSSOによるアイデンティティ伝播の使用」で説明するように、自動ログイン用にページレット・プロデューサを構成することをお薦めします。
自動ログインと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」を含めます。
参照: 共通自動ログイン構成
この項では、一般的なバックエンドSSOシナリオに対するページレット・プロデューサでの自動ログイン設定のクイック参照を示します。
この項では、次の項目について説明します。
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 : 非保護または資格証明ボールト
WSRPポートレットのページレットとしての消費
ページレット・プロデューサにはWebCenter Common Consumerが組み込まれているため、WSRPポートレットをページレットとして公開して、WebCenter SitesまたはWSRPコンシューマが含まれていないその他のすべてのWebコンテナで使用することができます。
WSRPポートレット・プロデューサは、Fusion Middleware Control、WLSTまたはページレット・プロデューサ管理コンソールを使用してページレット・プロデューサに登録できます。詳細は、『Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項に関する項を参照してください。登録が完了すると、WSRPプロデューサはページレット・プロデューサ管理コンソールにリソースとして表示され、WSRPエンドポイントに関連付けられたポートレットがリソースのページレット・コレクションにリストされます。
ノート:
自動生成されたWSRPリソースとページレットは変更できません。変更可能なバージョンを作成するには、ページレット・プロデューサ管理コンソールで該当するリソースを選択して、「コピー」をクリックします。リソースのクローン・バージョンは編集可能であり、インジェクタなどの各種要素を追加してページレットの機能をカスタマイズできます。たとえば、カスタム・インジェクタを使用してCSSクラスを注入し、ポートレット・マークアップがページレットをホストするサイトのルック・アンド・フィールのように表示されるように変更することもできます。
ページレット・プロデューサに登録しているWSRPプロデューサで認証が必要な場合は、次のステップを実行する必要があります。
-
『Oracle WebCenter Portalの管理』の「Web Servicesセキュリティの構成」の説明に従って、ページレット・プロデューサとWSRPプロデューサ間にWSセキュリティを構成します。Javaキーストア(JKS)がWSRPプロデューサとページレット・プロデューサ間で適切に構成されていることを確認する必要があります。詳細は、『Oracle WebCenter Portalの管理』のWebCenter Portalドメイン・キーストアの設定に関する項を参照してください。
-
WSRPプロデューサの登録時に、「セキュリティ」セクションで適切な「トークン・プロファイル」を選択して、必要な構成情報を入力します。キーストアへのパスは絶対パスである必要があります。
カスタム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 WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項を参照してください。
Oracle WebLogic Portal用に開発されたWSRPポートレットの公開
Oracle WebLogic Portal (WLP)では、Javaポートレット、Java Server Facesポートレット、Java Server PageおよびHTMLポートレットなど、様々なポートレット・タイプをサポートしています(完全なリストは、Oracle WebLogic Portalポートレット開発ガイドの「ポートレット・タイプ」を参照してください)。リモート(プロキシ)ポートレットはWSRPポートレットであり、ページレット・プロデューサでWSRPプロデューサによってそのままページレットとして公開できます。
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に設定する必要があります。
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 WebCenter Portalの管理』のWebCenter Portalドメイン・キーストアの設定に関する項を参照してください。
ノート:
キーストア値を構成したら、JPS構成変更が選択されるようにするために、ページレット・プロデューサをホストしている管理対象サーバー(デフォルトでは
WC_Portlet
)とWLS管理サーバーの両方を再起動する必要があります。 -
プロデューサの構成の第4項の手順では、発行者名の重要性は強調されていません。ここに入力される名前は、コンシューマにより送信された名前と一致する必要があります。Oracle JPSの場合、送信されたデフォルトの発行者IDは
www.oracle.com
です。
ページレット・プロデューサでのWLP WSRPプロデューサの登録
ページレット・プロデューサでWLP WSRPプロデューサを登録するには、『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とページレット・プロデューサの両方を構成する必要があります。(テスト目的の場合または認証なしでアクセス可能なポートレット・コンテンツの場合は、「セキュリティ」の「デフォルト・ユーザー」フィールドに有効なユーザー名を指定できます。)
サイトへのWLP WSRPポートレットの追加
WLP WSRPポートレットをサイト内のページに追加するには、「Oracle WebCenter Sitesへのページレットの追加」のステップを実行します。ページレット・コンテンツをロードするIFrameタグのsrc
属性に使用するURLは、「RESTを使用したページレットへのアクセス方法」の「ドキュメント」を参照してください。
自動生成されたWSRPリソースとページレットは変更できません。WLPポートレットのマークアップの変更、たとえば、カスタムCSSスタイルの注入によりポートレットUIのルック・アンド・フィールを変更するためにページレット・プロデューサの機能を使用するには、新しいバージョンのリソースを作成する必要があります。ページレット・プロデューサ管理コンソールでWLP WSRPプロデューサ用に作成されたリソースを選択し、「コピー」をクリックします。リソースのクローン・バージョンは変更可能であり、インジェクタなどの要素を追加してページレットの機能をカスタマイズできます。
サイトにおけるWebCenter Portalサービスのページレットとしての消費
WebCenter Portalには、WebCenter Sitesでユーザーのコラボレーションが容易に実行できるように、ドキュメントなどのサービスやツールが組み込まれています。これらのツールの概要は、『Oracle WebCenter Portalでのポータルの使用』の最新情報の入手に関する項および情報の整理に関する項を参照してください。
これらのサービスおよびツールをサイトで公開する場合のお薦めできる方法は、Oracle WebCenter Portal (11.1.1.6およびそれ以降)に組み込まれているサービス・プロデューサ・コンポーネントを利用して、関連するWSRPポートレットをページレット・プロデューサ内で消費することです。
次のポータル・ツールは、デフォルトではWSRPポートレットとして公開されています。
-
アクティビティ・ストリーム
-
メール
-
ドキュメント・マネージャ
-
リスト
-
タグ・クラウド
-
ブログ
ノート:
追加のツールを公開するには、サービス・プロデューサを新しいJSFページに拡張し、そのページにタスク・フローを追加します。
要件
『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』の手順に従って、WebCenter Portalをインストールします。WebCenter Content Serverやページレット・プロデューサを含むすべての依存コンポーネントもインストールされていて、構成済であることを確認します。詳細は、「要件」を参照してください。
セキュリティおよびシングル・サインオンの構成
サイト駆動のWebサイトからWebCenter Portalサービスへのアクセスを可能にするには、次の2つの前提条件があります。
-
WebサイトとWebCenter Portal間に共通のユーザー・ベースを作成する
-
WebサイトからWebCenter Portalへのユーザー・アイデンティティ伝播を確立する
次の各項で、これらの前提条件について説明します。
共通ユーザー・ベースの作成: LDAP統合
共通ユーザー・ベースを作成するには、WebCenter SitesとすべてのWebCenter Portalコンポーネントで使用される共通のLDAPリポジトリを構成する必要があります。LDAPサーバーを選択する際、それがWebCenter Portalコンポーネントを実行するWebLogic Serverに準拠していることを確認します。
WLSでのセキュリティ構成時に、次の点を忘れないようにしてください。
-
「オーセンティケータ」の優先度を「SUFFICIENT」に設定します。
-
「制御フラグ」(カッコ内)と認証プロバイダの順序を次のように設定します。
-
OAMアイデンティティ・アサータ(REQUIRED)
-
LDAPオーセンティケータ(SUFFICIENT)
-
デフォルト・オーセンティケータ(SUFFICIENT)
-
デフォルトのアイデンティティ・アサーション・プロバイダ: (SUFFICIENT)
-
ユーザー・アイデンティティ伝播の確立: OAM構成
ユーザー・アイデンティティ伝播を確立するには、Oracle Access Manager (OAM)を使用してWebCenter SitesおよびWebCenter Portal用にSSOソリューションを構成することをお薦めします。
OAMを使用している場合は、ユーザー・プリンシパル名がORACLE_REMOTE_USERヘッダーに渡されるように構成されていることを確認します。ObSSOCookieとOAM_REMOTE_USERの両方が、WebLogic Server上のOAMアイデンティティ・アサーション・プロバイダでアクティブに設定されている必要があります。
アイデンティティ・ストアでの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>
ディスカッション・サーバー用SSOの構成
ディスカッションを使用するには、WebLogic Serverでオーセンティケータの順序付けを行う前に(デフォルトのオーセンティケータおよびデフォルトのアイデンティティ・アサーション・プロバイダを使用)、ディスカッション・サーバーをSSO用に構成します。WLSTを使用してディスカッション・サーバー用にSSOを構成することもできます。詳細は、『Oracle WebCenter Portalの管理』のSSO用のディスカッション・サーバーの構成に関する項を参照してください。
WSRPポートレットとして公開されたWebCenterサービスのインポート
WebCenterサービスを公開するWSRPポートレットをページレット・プロデューサにインポートするには、Enterprise Manager、WLSTまたはページレット・プロデューサ管理コンソールを使用して、サービス・プロデューサをページレット・プロデューサにWSRPプロデューサとして登録するだけです。
図20-27では、ページレット・プロデューサ管理コンソールでのWSRPエンドポイントの登録例を示しています。詳細は、『Oracle WebCenter Portalの管理』のページレット・プロデューサでのWSRPポートレット・プロデューサの登録に関する項を参照してください。
このページの「セキュリティ」セクションの「トークン・プロファイル」は、サービス・プロデューサをサポートするために「WSS 1.0 SAML Token」に設定する必要があります。また、ページレット・プロデューサで設定されたサービス・プロデューサに対するリクエストに適切な実行タイムアウトを入力します(デフォルトは30秒)。
登録が完了すると、サービス・プロデューサはページレット・プロデューサ管理コンソールにリソースとして表示され、プロデューサによって公開されたすべてのWSRPポートレットがリソースのページレット・コレクションにリストされます。
サイト・ページへのページレットの追加
WebCenterサービスを公開しているページレットはすべて、Oracle WebCenter Sitesへのページレットの追加に関する項で説明するステップに従って、WebCenter Sitesのページに追加できます。図20-28に、WebCenter SitesにあるサンプルのAviSportsサイトのページに埋め込まれたドキュメント・マネージャ・サービスを示します。
ノート:
自動生成されたWSRPリソースとページレット(サービス・プロデューサに関連付けられているものなど)は変更できません。インジェクタを追加したり、その他の変更を加えるには、編集可能なバージョンを作成する必要があります。ページレット・プロデューサ管理コンソールでリソースを選択し、「コピー」をクリックします。リソースのクローン・バージョンは編集可能であり、インジェクタなどの各種要素を追加してページレットの機能をカスタマイズできます。
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/
など)
この項では、次の項目について説明します。
自動ログインの構成
このステップでは、EBSシステムがOSSOによって保護されていて、ページレット・プロデューサがSSOに関与する(WebサイトがSSOで保護されていない場合の一般的なシナリオ)のではなく、「自動ログイン」フォームを提供するように構成されることを前提としています。EBS資格証明はすべてのユーザー用に共有することも(テスト用に有効)、ページレット・プロデューサの資格証明ボールトにユーザー別に格納することもできます。
ノート:
ログイン・フォームのフィールド名は通常、バックエンド・リソースを保護しているログイン・ページのHTMLソースを調べることによって取得されます。
ページレットの作成
このステップでは、ページレットを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」ページが表示されます(ページレットでユーザー・ボールトを使用して資格証明を格納していて、そのページレットにはじめてアクセスする場合を除きます)。このページから「簡易検索」を使用て、ワイルドカード文字として'%'を使ってオーダーを検索できます。
修正構成の作成
ページレットの登録後に、プロキシ設定されたマークアップでのURLリライト関連の問題に対応するため、あるいは単にマークアップのスタイルを変更したり不必要な要素を非表示にするために、ページレットで追加機能(パーサー、インジェクタ、クリップなど)が必要になる場合があります。この項では、EBSでOrder InformationのUIを公開するサンプルのページレットに適用された修正構成について説明します。
この項では、次の内容について説明します。
ポップアップURLリライト用のプラガブル・パーサーの作成
パーサーを使用して、コンテンツを解析したり、リライトする必要のあるURLを検索するために、ビルトイン・ロジックを補足または変更することができますビルトイン・パーサーがURLの識別に失敗した場合は、カスタム・パーサーを使用してこの失敗を修正することができます。EBS 11i UIの場合、このステップは「拡張検索」でのポップアップ処理の修正に必要です。
EBSリソースの下で、次の設定を使用して新しいパーサーを作成します。
-
名前: popupRewriter(または任意の名前)
-
URLフィルタ: *.jsp*
-
基本パーサーの使用: オン
-
フラグメントの場所
-
var _jspDir='(.*?)';
(タイプ静的URL) -
<frame .? src="(.?)
(タイプ静的URL)
-
図20-29にpopupRewriterの設定を示します。
フレーム・バストを無効化するインジェクタの作成
インジェクタによって、プロキシ設定されているリソース・ページの指定された場所にコンテンツが挿入されます。コンテンツには、HTML、CSS、JavaScript、およびページレット宣言も含めて、任意のテキストが使用できます。空のインジェクタを使用して、不必要なコンテンツをページから削除することもできます。次のインジェクタはEBSページレットに対して作成されたものですが、その目的は、ユーザーが職責を選択するよう求められる最初のページで発生するページの継承をEBSページレットが行わないようにすることです。
EBSリソースの下で、次の設定を使用して新しいインジェクタを作成します。
-
全般
-
名前: frameBustDisabler
-
URLフィルタ: <none>
-
MIMEフィルタ: text/html
-
挿入位置:
target=_top
を置換
-
-
コンテンツ: (テキスト)
alt='
'
図20-30に、新しいインジェクタのパラメータ設定を示します。
iFrameを自動サイズ変更するインジェクタの作成
よりシームレスに消費側ページに統合するには、コンテンツを収められるように動的にサイズ変更することによって、ページレットiFrameがよりインライン・コンテンツらしく動作するように構成できます。詳細は、このドキュメントの「IFrameの自動サイズ変更の有効化」を参照してください。
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>
ページレットのスタイル変更用にインジェクタを作成
消費側のページで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>
ページレットのテスト
これでEBS11リソースには、図20-31に示すように、ページレット、カスタム・インジェクタ、およびカスタム・パーサーが含まれるようになりました。
ページレットをテストするには、「ドキュメント」ページを参照し、次に示すURLを使用して、「example.com」をローカル・ホストIDに置き換えます。
http://example.com:8889/pagelets/inject/v2/pagelet/ebs11/order_status?content-type=iframe&csapi=true&ifheight=300px
最終結果
次のスクリーンショットは、iFrameのページレット・アクセス用のREST URLを使用してWebCenter SitesにあるサンプルのAviSportsサイトのページに埋め込まれたEBS 11i Order Informationの画面を示しています。
ページレット・プロデューサを使用したOpenSocialガジェットの消費
ページレット・プロデューサは、次の機能を公開するOpenSocialコンテナです。
-
ユーザー(ピープル・コネクションを公開)
-
アクティビティ(アクティビティ・ストリームを公開)
-
アプリケーション・データ(ガジェットのパーソナライズをサポート)
-
Pub-Subメカニズム
ユーザーおよびアクティビティ機能には、WebCenter Portalが必要です。ユーザーおよびアクティビティ機能を使用するには、WebCenterDSのターゲットとして、WC_Portlet
管理対象サーバー(つまり、ページレット・プロデューサ)を指定します。アプリケーション・データに対して、ページレット・プロデューサでは、ユーザー、インスタンスおよびページレット・スコープのプリファレンスをサポートします。
次に例を示します。
-
ページレット・プロデューサを開き、新しいOpenSocialリソースを作成します。
-
必要に応じてURLとポリシーを定義します。
-
新しいページレットを作成し、外部ガジェットのURLを指定します。
たとえば:
http://bayareacoder.com/gogo/localweather/localweather.xml
-
ガジェットXMLファイルを作成またはアップロードします(図20-34を参照)。
図20-34 ページレット・プロデューサ内のアクティビティJavaScriptおよびXMLオプション
「図20-34 ページレット・プロデューサ内のアクティビティJavaScriptおよびXMLオプション」の説明「名前」フィールドに指定するパスは、ページレット・プロデューサがファイルの提供に使用する'仮想'URLであり、任意のパスまたは名前を使用できます。
-
新しいガジェットに必要な他のファイル(JavaScriptファイルやイメージなど)を作成またはアップロードしたら、作業は完了です。
有効なジオメトリ管理とページ区切りのガイドライン
有効なジオメトリ管理を実施すると、ページでのタスク・フローのサイズ設定と配置を効率良く実行できます。タスク・フローが適切に設計されていない場合、応答時間が遅いページまたはコンポーネント間に不要なスクロール・バーや空白が大量に表示されるページが生成されます。たとえば、データをストレッチするコンテナ(Show Detail Frameコンポーネントなど)をタスク・フローで使用していて、そのコンテナの内部に非常に少量のデータしか存在しない場合、タスク・フローではデータの下に大量の空白が表示されます。設計が不適切な場合、大量のデータが表に表示されるタスク・フローで、スクロールが遅くなったり、予期しない動作を示したりする可能性もあります。これらの問題を避けるために、大量のデータ・セットを表示する際は必ず、従来のページ区切りモデルを使用するフロー・タスク・フローを設計してください。
WebCenter Portalの新しいタスク・フローを設計する際は、この項のガイドラインに従ってください。また、WebCenter Portalの既存のタスク・フローを編集する際も、必ずこの項のガイドラインに従ってください。
この項には次のトピックが含まれます:
インジェクタでのJavaScriptの使用
タスク·フローで不要な空白を回避するためには、タスク·フロー·コンテンツがフローし、タスク·フロー·コンテナによってストレッチされていないことを確認する必要があります。ストレッチ・タスク・フローは、コンテナの高さにストレッチされたもので、フロー・タスク・フローは、ストレッチ・コンテナやタスク・フロー自身の固定された高さではなく、そのコンテンツによって決定されます。データ量の少ないフロー・タスク·フローは、データ量の多いフロー・タスク・フローよりも短くなります
フロー・タスク・フローを設計するには、次のことを保証する必要があります。
-
タスク・フローの子コンポーネントの高さが固定されていない。
-
タスク・フロー・リージョンを囲むShow Detail Frameコンポーネントの高さが(そのcontentStyle属性を使用して)固定されていない。
高度なURLリライト
この項では、ページレット・プロデューサの自動ログイン機能を使用する方法、およびカスタム・パーサーを設計する方法について説明します。
この項では、次の項目について説明します。
自動ログインの使用
自動ログインを使用すると、ユーザー名およびパスワード資格証明をバックエンド・リソースに渡すことができます。これらは、次のいずれかのものとして渡すことができます。
-
静的な資格証明 – すべてのユーザーに1つのセット
-
リソースへの初回アクセス時にユーザーから動的に取得し、セキュアな資格証明ボールトに格納
-
ユーザー・プロファイル(ユーザー名を取得して渡す)
自動ログインでサポートされる認証メカニズムは、次のとおりです。
-
基本ログイン
-
フォーム・ログイン(次の例で使用)
-
NTLMログイン
-
Kerberosログイン
図20-35の例と、次のコード・スニペットは、自動ログインを使用してログイン・ページをリダイレクトする方法を示しています。
次のコードは、図20-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>
カスタム・パーサーの使用
パーサーを使用すると、URL解析の組込みロジックを拡張または変更できます。URLフィルタと正規表現を使用すると、ページ内でパーサーによって変更される部分を絞り込むことができます(図20-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つの正規表現(図20-36の「正規表現」の下)を使用します。
-
XMLFile=(.*?)“
-
param name="movie" value="(.*?\.swf)
-
embed src="(.*?\.swf)