対象読者

このマニュアルでは、Webアプリケーション・テンプレートを作成し、構成するためのベスト・プラクティスと、推奨される手順を示します。ログオンおよびパスワード変更のフォームの構成とテスト、および最も一般的なWebアプリケーションのレスポンスの問題に関する診断と解決について説明しています。

Hypertext Markup Language (HTML)、Webページの構造に関する実用的な知識を持ち、HTMLとCSSのコードを理解して分析できる方を対象としています。また、Logon Manager Agentのデプロイおよび構成、Logon ManagerのAdministrative Consoleの使用にも習熟している方を対象としています。(このマニュアルで説明する各機能の詳細は、Logon Manager Administrative Consoleヘルプで参照することができます。)

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。

詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

用語または略語	説明
太字	太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。
イタリック	イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。
固定幅	固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第1部: Webフォームの検出とレスポンスの理解

この部では、後で説明するように、特定のサインオン・シナリオを解決するためにアプリケーション・テンプレートを構成する方法とその理由を理解するために必要な概念を説明します。内容は次のとおりです:

· サインオン・イベントの概要

· Webフォームの検出の理解

· フォーム・レスポンスの理解

サインオン・イベントの概要

ログオン、パスワード変更およびその他の多様なサインオン・イベントを、Logon Managerで検出して応答するように構成することができ、様々なフォーム、フィールド、コントロールおよびイベント・フローがサポートされています。

Webフォームを認識するため、Logon Managerでは、実行中のWebブラウザが監視され、Webページがブラウザにロードされるとすぐに検出されます。

ページがすべてロードされると、Logon Managerで次の手順が実行されます:

1. ターゲットのWebページとフォームを検出します。監視中のブラウザから新しいURLがアクセスされると、Logon Managerは次の手順を実行します:

a. そのページのURLを調査し、使用可能なすべてのWebアプリケーション・テンプレートに格納されているURLと比較します。

b. 検出されたURLと一致する1つ目のテンプレートをロードします。

c. ページのDocument Object Model (DOM)を確認し、そのフォーム定義に構成された各フィールドとコントロールを特定します。

d. (オプション)ページのソース・コードを調べて、フォーム定義で構成されているその他のマッチングを実行します。

2. エージェントがフォームに応答し、ログオンを実行します。検出が完了して一致するものが見つかった場合、エージェントはテンプレートに格納されている構成に従って、フォームのフィールドおよびコントロールとの対話方法を判断します。通常、エージェントは次の手順を実行します:

a. ユーザーのストア(存在する場合)から関連する資格証明を取得し、該当するフィールドに注入します。(資格証明が存在しない場合、エージェントはユーザーに格納するよう求めます。)

b. 資格証明をアプリケーションに送信するために必要なアクションを実行し、処理を行います。

c. (オプション)ログオンまたはパスワード変更の成功や失敗のメッセージなど、補足情報のフォームを検出し、必要なアクションを実行します。

Webフォームの検出の理解

Logon Managerは、インストールされているWebブラウザにフックするヘルパー・オブジェクトを使用してそのブラウザとの通信を行い、データ(ページのURL、DOMおよびHTMLソース)をブラウザに問い合せたり、資格証明をターゲット・フィールドに注入して、検出が成功するとそれらを送信します。

ヘルパー・オブジェクトは、次のバックグラウンド・プロセスとして実行されます:

· Microsoft Internet Explorerの場合: SSOBHO.EXE

· Mozilla Firefoxの場合: SSOWEBHO.EXE

Webブラウザがページをロードし終わるたびに、このイベントが各ヘルパー・オブジェクトからLogon Managerに通知され、500ミリ秒の猶予期間タイマーが開始されます。この猶予期間中に、次のいずれかが発生します:

· 現在のページがリフレッシュされないか、または別のページのロードが開始されない場合、Logon Managerが検出を開始します。

· 現在のページがリフレッシュされたか、または別のページのロードが始まると、Logon Managerは検出の前にタイマーを再度開始し、そのページのロードが終わるまで待機します。

注意: ページがリフレッシュされるか、検出が始まった後に別のページのロードが始まった場合、Logon Managerは検出を中断し、そのページのロードが終了するまで待機した後に、500ミリ秒間の猶予期間タイマーを開始して、前述のとおりに経過するのを待ちます。

通常はブラウザ・ウィンドウの下部にあるステータス・バーに「Done」や「Finished.」などの適当なメッセージが表示され、そのページがロード完了したことが示されます。

検出が始まると、Logon Managerは次のようなページの特性を調べて、使用可能なテンプレートと比較します:

· URL

· ターゲット・フィールドとコントロール

· (オプション)ターゲット・フォームのテンプレートに構成された、その他の任意のマッチング基準(テキスト、HTMLコード、要素属性など)。

注意: アプリケーション・テンプレートは、Webアプリケーション・フォームの検出方法とWebアプリケーション・フォームに対するレスポンス方法をLogon Manager Agentに指示し、正常にログオンできるようにするための一連の構成オプションです。

下記の場合、WebアプリケーションとしてではなくWindowsアプリケーションとしてアプリケーションを構成する必要があるということに注意してください:

· Internet Explorerを使用していて、ターゲット・フォームをActiveXコントロールとして実装する場合

· Mozilla Firefoxを使用していて、ターゲット・フォームをブラウザに組込みの認証ダイアログを使用して表示する場合

詳細は、『Windowsアプリケーションのためのテンプレート構成および診断』を参照してください。

サポート対象のフォーム・タイプ

このドキュメントのリリース時点で、Logon Managerは次のタイプのフォームをWebアプリケーションでサポートします:

· ログオン

· ログオン成功(ログオンの成功を示すメッセージ)

· ログオン失敗(注入された資格証明が拒否されたことを示すメッセージ)

· パスワード変更

· パスワード変更の成功(パスワード変更の成功を示すメッセージ)

· パスワード変更の失敗(新しいパスワードが拒否されたことを示すメッセージ)

1つのテンプレートには、Webアプリケーションで表示できる複数のフォームの定義を含めることができます。ほとんどのアプリケーションの場合、定義する必要があるのは、Logon Managerで応答するフォームのみです。

注意: フォームを定義することで一意の識別基準ができ、そのフォームが検出されたときにとるアクションおよびそのアクションで実行する必要がある特定の動作(資格証明の注入など)が指定されます。

Logon Managerは、ユーザーの資格証明ストアから自動的に資格証明を取得し、それをフォーム内の適切なフィールドに移入することができるだけでなく、フォームのコントロールを操作して、アプリケーションに資格証明を送信して処理することもできます。
フォームのフィールドおよびコントロールとの対話方法をエージェントに指定する構成オプションは、テンプレートに格納されています。

URL検出の理解

Webフォームを検出する際に、Logon Managerで最初に考慮される基準は、Webアドレス(ターゲット・ページのURL)です。これは通常はページのロードが完了した後でブラウザのアドレス・バーに表示されるアドレスですが、ある状況では、フォーム定義で指定する必要がある実際のURLが、ログオン・フィールドやコントロールを含むコンテナまたはフォーム要素(用語については次の項で後述)などの、ページの要素のURLであることがあります。

ページURLの構造は次のとおりです:

http://apphost01.website.com/webapp01/apphome.html

プロトコル識別子

URLは、そのWebアプリケーションのデプロイ方法に応じて、静的または部分的に動的になります。たとえば前述の例に示すように、静的ホスト名を持ち単一のHTMLページとして存在する単一のWebサーバー上に、単純なWebアプリケーションをデプロイするとします。このような場合は、そうしたURLと一致するフォーム定義を構成すれば、テンプレートを動作させることができます。

一方で、多くのエンタープライズWebアプリケーションは、ロード・バランスされているか、またはクラスタ化された複数のサーバーにデプロイされ、個々のインスタンスのURLは、単一エントリURLでマスクされます。

たとえばWebアプリケーションへのアクセスに使用されるURLが、次のものだけである場合、

http://webapp.website.com/webapp01/apphome.html

ロード・バランスされた個々のインスタンスへの実際のURLは、次のものであることがあります。

http://apphost01.website.com/webapp01/apphome.html

http://apphost02.website.com/webapp01/apphome.html

http://apphost03.website.com/webapp01/apphome.html

多くのエンタープライズWebアプリケーションでは、ブラウザとWebサーバーまたはデータベースとの間でデータを受渡しするために、JavaScriptやPHPのようなアクティブ・スクリプトのテクノロジを使用します。
そのようなアプリケーションは、一意のセッションIDのような動的パラメータまたは変数を、ページのURL内に1つ以上使用します。

例:

http://webapp.website.com/apphome.html?s=bd4cecd0d934870

可変の
デリミタ一部のアプリケーションは、可変的な区切り記号(通常はアンパサンド(&))でURL変数を区切り、複数指定します:

…apphome.html?s=bd4cecd0d934870&view=full&sidebar=off

多くのエンタープライズWebアプリケーションのケースで、動的ホスト名と動的パラメータが同時に使用されており、フォーム定義を正常に構成するには、この両方が必要です。
Logon Managerでは、正規表現によって動的なURLを照合したり、Logon ManagerがすべてのWebアプリケーションに対して使用するURLマッチング精度をグローバル・エージェント設定で指定したりすることができます。

URLマッチング精度の理解

URLマッチング精度によって、検出時に考慮されるホストURL(ページURL内で右から左にカウントされる)のセグメント数が決まります。

たとえば、デフォルトの精度レベルが2で、ホスト名URLがアプリケーションURLの場合

http://webapp.website.com/apphome.php

前述のホストURLと、下記に示す、個々にホストされたアプリケーションのインスタンスのURLは、テンプレートに一致します:

http://apphost01.website.com/apphome.php

http://apphost02.website.com/apphome.php

これは、ホストURLの最後のセグメントを、次のいずれかでマスクしたものと同じです。ワイルドカードの場合:

http://*.website.com/apphome.php

正規表現の場合:

http://.*\.website\.com/apphome\.php

注意: URLには、標準的な単一セグメントのトップ・レベル・ドメイン(TLD) (.com、.netなど)ではなく、2つのセグメント(イングランドの.co.uk 、オーストラリアの.co.auなど)で構成されるTLDが含まれる場合があります。その場合、URLマッチング精度およびWebアプリケーション・テンプレートを構成する際、ホストURLにセグメントを追加することを検討する必要があります。

URLマッチング精度を3に増やすと、Logon ManagerはホストURLの連続する3つのセグメントを照合します - この例では、次に示すとおり、それがホスト名全体と一致することになります。

http://webapp.website.com/apphome.php

検出時、サーバー名の相違は許容されず、テンプレートに構成された正確なURL以外はLogon Managerによって拒否されます。この例では、前述のWebアプリケーションの個々のインスタンスのURLは、一致しているとみなされません。

ご使用の環境に適したURLマッチング精度を判断するには、次のガイドラインに従ってください:

· URLマッチング精度が低すぎると、Logon Managerは、あるイントラネット・アプリケーションと別のものを間違えたり、誤った資格証明で応答することがあります。

· URLマッチング精度の設定が高すぎると、一意のホスト名による分散インフラストラクチャを介して利用できるアプリケーションが、異なるホストURLによって、別々のアプリケーションとして誤認識される場合があります。

· 通常は、URLマッチング精度を5 (最大値)に設定します。これによって、ログオンをリクエストしているアプリケーションのURLがテンプレートに格納されたURLと厳密に一致する場合のみLogon Managerが応答することが保証されます。自動認識機能は限定されることになります。

· Logon ManagerのWebアプリケーション用自動認識機能のメリットを最大限に利用するには、URLマッチング精度をデフォルト値の2のままにします。ただし、イントラネット・アプリケーションへのレスポンスは低下することがあります。

Logon Managerでは、管理コンソールからグローバルにURLマッチング精度レベルを設定することができます。
このオプションは、「Global Agent Settings」>「End-User Experience」>「Response」>「Web Apps」にあります。エージェントの構成および変更のエンドユーザー・マシンへの公開については、ベスト・プラクティス・ガイドのLogon Manager Agentの構成を参照してください。

ページ、要素またはポップアップのURLの取得

ある状況では、ページまたはページ内の要素のURLが容易に入手できない場合がありますが、テンプレートでのフォーム定義は完了する必要があります。たとえば、次のURLが必要な場合があります:

· WebページのURLとは異なるURLからロードする埋込みフォーム

· ブラウザとWebサーバーまたはデータベースとの間でデータを受け渡すログオン処理スクリプト

· 画像または埋込みのマルチメディア・オブジェクト

· ポップアップ

その場合は、次の手順を1つ以上実行して必要なURLを取得します:

· ブラウザのアドレス・バーが表示されていない場合は、[F11]を押して表示させます。

· オブジェクトまたはフォーム内で右クリックして「Properties」を選択すると、「Properties」ダイアログに、そのオブジェクトのURLが表示される場合があります。

· そのページのロードが完了してからHTMLソース・コードを調べて、必要なオブジェクトを検索します

特に、そのURLが部分的に動的な場合に、HTTPWatchまたはURL Getterのようなサードパーティ・ツールを使用してその要素のURLを取得します。ページのソース・コードを表示すると、必要なオブジェクトのすべてのURLを取得できる場合があります。

フィールド検出の理解

検出されたURLがテンプレートに一致すると、Logon Managerはフォーム定義に構成されたフィールドを検出するために、そのページのDocument Object Model (DOM)を確認します。

各フィールドおよびコントロールに対して、エージェントは次のものの名前または序数を調べます:

· 親フレーム要素

· 親フォーム要素

· ターゲット・フィールド要素

フィールドを正しく特定するには、3つの値すべてが、テンプレートのフォーム定義に構成された値に一致する必要があります。
下記の図および対応するコード例に、ログオン・フォームを含む単純なWebページの構造を示します。

注意: 現在のWebページのほとんどが、コンテンツの再分割にフレームを使用していません。
検出のために、Logon Managerは<html>コンテナをページのマスター・フレームとみなし、それを0の序数値で特定します。ほとんどの場合、その値は変更する必要がありません。

説明: web_app.png

<!DOCTYPE html>

<html>

<head>

<title> Enterprise Web Application </title>

</head>

<body style="border: 2pt solid red; width: 490px; padding: 20px;
margin: 20px;">

名前のないマスター・フレーム要素として動作する<html>コンテナ(序数: 0) <div id="page-header" style="font: 12pt Tahoma;
padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

<form action="/script/logon_form.html" method="POST" name="logon">

      <div id="logon_form" style="font: 11pt Tahoma; border: solid 2pt
             green; width: 220px; padding: 20px; margin-top: 20px;
            margin-left: 107px">

logonという名前の
<form>要素
(序数: 0)
        <p style="padding-bottom: 20px; text-align: center;">
         <b>Welcome - log on below.</b></p>

       <p>Password:   <input type="password"
           name="password" id="pass" size="18" style="border: 2pt
           solid blue;"></p>

        <p><input type="submit" id="submit_btn" name="submit"
           value="Log On" style="margin-left: 75px; margin-top:
           15px;"></p>
     </div>

</form>

</body>

</html>

表示されたページの要素の親子関係に対応するコードの、階層的なネスト構造に注意します。

注意: 前述の例にある開始タグと終了タグの各ペアは、要素(フレーム、フォーム、フィールドのように、ページ内で1つの機能エンティティを構成しているコード部分)です。

テンプレートにフォーム定義を手動で構成する際、Logon Managerに対してフレーム、フォームとおよびフィールドの要素を次のもので指定できます:

· 要素のname属性の値、これが指定されない場合は

· 序数(ページのDOMに表示される順序に従って、サポートされる各タイプの要素にLogon Managerが割り当てるインデックス番号)。　

HTML要素の理解

前述のとおり、HTML内の要素は、フレーム、フォーム、フィールドのように、ページ内で1つの機能エンティティを構成しているコード部分です。要素は、1行のコードであり、<input>のような単一のタグの場合と、<div>…</div>のような開始タグおよび終了タグからなり、これらのタグの間にすべてが入る場合があります。

たとえば、典型的な<input>要素は次のようになります:

<input type="text" name="username" id="user" size="18"
style="border: 2pt solid blue;">

要素宣言(<input)の後のコードに注意してください。これらは要素の属性です。各属性には、フォーム内での名前と値があります:

attribute_name="attribute_value"

属性値を認識させるには、直線の二重引用符(インチマーク)が必要です。

フレーム要素の理解

フレームは、フレームセットを定義し、各フレームのサイズと表示するHTMLドキュメントを指定することでWebページをセクションに分けることができる、旧式のコンテナです。現在、大多数のWebサイトではこの技術を使用しておらず、<div>、<table>とCSSフォーマッティングの使用など、XHTML標準に定義された論理コンテナを使用してセクション化を実現しています。したがって、多くの場合、Logon Managerは<html>コンテナをページ内のマスターの(そして唯一の)フレームとして扱い、これをフレーム0として識別することになります。

フィールドおよび検出マッチング・ルールを構成する際、フレーム識別子を変更する必要はありません。ただし、Webアプリケーションが旧式のアプリケーションで、特にそれを必要とする場合(たとえば、スタンドアロンHTMLドキュメントとして存在し、親Webページのフレームに表示されるログオン・フォームを使用する場合)は別です。そのようなページを識別するには、DOMまたはソースで<frameset>タグで示されたフレームセット定義を検索します。フレームセット定義の例は、次のとおりです:

<FRAMESET cols="20%, 20%, 60%">

<FRAME src="frame1.html">

<FRAME src="frame2.html">

<FRAME src="frame3.html">

</FRAMESET>

フレームは、次のような<frame>タグで特定できます:

<FRAME src="contents_of_frame3.html">

フォーム要素の理解

<form>要素は、HTMLフォームを定義し、これは1つ以上の入力フィールドを含む論理エンティティ(次の項で説明)です。

<form>要素の定義では、スクリプトまたは別のリソースを参照し、フィールドに入力されてブラウザを介して送信される値を受け取って処理します。次に例を示します:

<form action="/script/logon_form.html" method="POST"
name="logon">

この例で、logon_form.htmlページは、ユーザー認証を処理します。ユーザーがフォームを送信すると、logon_form.htmlはフォームの入力フィールドに入力された値を受け取り、適切な認証ロジックを実行します。

Logon Managerによってサポートされるinput要素の理解

一般に、HTMLフォーム・フィールドは、特定のクラスのinput要素として定義され、要素の定義に使用されるタグとtype属性で示されます。フォーム定義を構成すると、Logon Managerは次の要素タイプを認識します。

Logon Managerのフィールドのタイプ

Logon Managerのフィールド・タイプで受け入れるinput要素のタイプ

· User name/ID

· Password

· Third Field

· Fourth Field

· Text – <input>タグのtype="text"で識別されるテキスト・フィールド。このフィールドに入力されるテキストは、マスクされません。

· Password – <input>タグのtype="password"で識別されるテキスト・フィールド。このフィールドに入力されるテキストは、マスクされます。

· Select-one – <select>タグで識別され、その値として単一のリスト・アイテムを選択できるリスト・フィールド。

· Select-multiple – <select multiple … >タグで識別され、その値として1つ以上のリスト・アイテムを選択できるリスト・フィールド。

· Submit

· Submit – <input>タグのtype="submit"で識別されるボタン・コントロール。<form>タグのaction属性で指定されているコードを実行します(通常はHTMLドキュメントか、アプリケーションのログオン・ロジックを含むスクリプトをコールします。)

· Button - <input>タグのtype="button"で識別されるボタン・コントロール。より広い範囲のスタイルを設定できること以外、機能的にはsubmitタイプの<input> 要素と同じです。

· Image –<input>タグのtype="image" で識別され、クリックすると参照先のリンクを実行するハイパーリンク付きイメージ。

· IMG – アンカー(<A HREF=)タグか、クリックされるとURLの送信が実行されるJavaScriptのonClick アクションのどちらかで囲まれる、<img src=タグで識別されるイメージ。

· Anchor – テキスト・ハイパーリンクの最も一般的な宣言(デフォルトでは、ページ内の青色のアンダーライン付きのテキストとして表示されます)。<A HREF="…">タグで識別されます。

推奨されるページ調査ツール

Webアプリケーションをプロビジョニングするときは、ページ調査ツールを入手することをお薦めします。これによって、簡単にナビゲートして検索できる方法でページのDOM(必要に応じてソース・コードも)を表示させ、ページの構造を非常に簡単に短時間で理解することができます。

Mozilla FirefoxのDOMインスペクタ

そのようなツールの例に、Mozilla FirefoxのDOMインスペクタ・アドオンがあります。このページ例のDOMは、DOMインスペクタで次のように表示されます:

説明: dom_inspector.png

ページの階層構造は左側のペインにあるナビゲート可能なツリーに表示されており、ある要素をクリックすると、ブラウザ・ウィンドウにあるその要素がハイライト表示され、その要素の属性と値が右側のペインに表示されるため、ページのソース・コードを厳密に調べなくても、ターゲット・ページ要素を簡単に特定し、理解することができます。このツールは特に、大規模で複雑なページに有用です。

DOMインスペクタは、Mozilla Firefoxのアドオン・サイト(http://addons.mozilla.org)で入手できます。

Mozilla FirefoxのFirebug

DOMインスペクタと同種のより高度で柔軟なツールに、Mozilla FirefoxのFirebugアドオンがあります。FirebugはDOMインスペクタのすべての機能を備えており、さらにすべてのソース・コードをDOMツリーに表示して、各コード要素をマウスオーバーで視覚的に強調表示することができます。ユーザーは、コードを変更したり、その変更をブラウザ・ウィンドウで確認することもできます。Firebugは主にWeb開発者向けですが、複雑なWebページの分析において、非常に優れていることがわかります。

説明: firebug.png

Firebugは、Mozilla Firefoxのアドオン・サイト(http://addons.mozilla.org)で入手できます。

検出マッチングの理解

ここまでに説明したURLと要素が、ページ内のログオン・フォームを一意に特定するのに不十分である場合は、追加の検出基準を指定し、マッチングによって検出範囲を絞り込むことができます。「マッチング」という用語は、要素名や属性値などの特定のパラメータ値を、アプリケーションのテンプレートに格納されている値と比較照合することを指します。

たとえば、Webアプリケーションがメンテナンスのために停止状態のときにログオンしようとしても、そのログオンが失敗する理由を示すエラー・メッセージとともに、ログオン・フォームがもう1度表示されるという結果になります。そのような場合にLogon Managerが繰り返しログオンを試行することを防ぐため、テンプレートで2つのログオン・フォームを定義し、一方の定義ではテキスト・マッチングを使用してエラー・メッセージ・テキストを照合し、そのエラーを表示するログオン・フォームを無視するようにLogon Managerに指示します。

注意: この項では、Webアプリケーションに対するマッチングを正しく構成するために必要な、マッチング・メカニズムの根底にある原則を説明します。コンソールを介してマッチングを構成する実際の手順については、「追加のフィールド検出基準の構成」を参照してください。

Logon Managerでは、次に対するマッチングが可能です:

· ページに表示されるテキスト

· ページのソース・コードにあるHTMLコード

· ページ要素の属性の名前と値

前述のマッチング・タイプを説明するため、15-16ページの例を使用します。例には、ヘッダーEnterprise Web Applicationが表示され、特定のテキスト部分を簡単にインライン表示できるように、<div>コンテナとして実装されています。

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

検出マッチングとオフセット・マッチング

Logon Managerには、検出とオフセットの2種類のマッチングがあります。ほとんどの場合は検出マッチングを使用し、オフセット・マッチングは使用しません。後者は、フレームが名前や属性によって特定されないフレームセットを使用している旧式のページに対して有用です。このような場合、Logon Managerは、そのフレームがページのDOMに表示される順に、フレームの序数を割り当てます。そのようなフレームセットにある特定のフレーム内の要素に一致させるには、フォーム検出ダイアログの「Matching」タブの「Offset Start」パラメータの値としてその序数を指定します。

ページ上のテキストに対するマッチング

最も一般的に使用されるマッチング・モードでは、そのフォーマットに関係なく、ヘッダー・テキスト自体を照合することができます。たとえば、「Enterprise Web Application」と一致するようにマッチング・ルールを構成するには、次のようにします:

· Tag: div

· Criteria: Text

· Value: Enterprise Web Application

· Match whole value: Yes

· Use regular expression: No

この構成では、次のものが一致することになります:

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

ページのソース内のHTMLコードに対するマッチング

「HTML」マッチング・モードを使用すると、ページのソース・コード内の任意のコードの一部を照合することができます。このモードが最も一般的に使用されるのは、レンダリングされたテキスト(マークアップを含む)に対するマッチングですが、ページに固有の特定のコードの一部のマッチングにも使用できます。

注意: HTMLの仕様の性質により、Logon Managerは<span>タグを照合することができません。

たとえば、「Enterprise Web Application」と一致し、「Enterprise Web Application」と一致しないようにするには、次のようにマッチング・ルールを設定します:

· Tag: div

· Criteria: HTML

· Value: <b>Enterprise Web Application></b>

· Match whole value: Yes

· Use regular expression: No

この構成では、次が一致します:

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

注意: 「Match Whole Value」オプションは、「Value」フィールドに入力された文字列全体に対するマッチングをLogon Managerに強制します。デフォルトで有効になっています。ページでの部分一致(<b>Enterpriseなど)を可能にするには、このオプションを無効にします。

前述の<div>コンテナの開始タグ全体を照合するには、これを基準値として指定し、その親要素をタグとして指定します:

· Tag: body

· Criteria: HTML

· Value: <div id="page-header"…

· Match whole value: Yes

· Use regular expression: No

これにより、次が一致します:

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

要素属性の名前および値に対するマッチング

要素内の特定の属性またはその値を照合することもできます。たとえば、<div>要素のid属性の値を照合することができます:

· Tag: div

· Criteria: Attribute

· Attribute name: id

· Value: page-header

· Match whole value: Yes

· Use regular expression: No

これにより、次が一致します:

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

ただし、「Value」フィールドを空白のままにすると、属性名で一致します:

<div id="page-header" style="font: 12pt Tahoma; padding-bottom: 10px">

<b>Enterprise Web Application</b>

</div>

論理演算子を使用した複雑なルール・チェーンの構築

Logon Managerでは、ブール論理演算子を使用して個々のマッチング・ルールを連鎖させ、特定の状況の組合せでのみ一致する複雑なルール・チェーンを作成できます。

たとえば、パスワード変更フィールドとコントロールを表示しながら、パスワードが正常に変更されたときに成功メッセージを表示するパスワード変更フォームの一致ルール・チェーンを作成するとします。このような場合は、Logon Managerがパスワード変更ループに入らないように、成功メッセージが表示された後はLogon Managerがこのフォームを無視するようにすると同時に、標準のパスワード変更フォームに対する適切なレスポンスを保持する必要があります。

これを実現するには、次のルールを作成します:

· 成功メッセージ・テキストに対する「NOT」一致ルール(これにより、Logon Managerはフォームを無視します)。

· フォーム上の任意のテキストに対する「AND」一致ルール(これは、成功メッセージが存在しない場合に一致し、Logon Managerが応答するようにします)。

この例に基づき、前述のルールを次のように構成します:

ルール1

· Tag: html

· Criteria: Text

· Value: Logon error

· Match whole value: Yes

· Use regular expression: No

· Operation: NOT

ルール2

· Tag: html

· Criteria: Text

· Value: Enterprise Web Application

· Match whole value: Yes

· Use regular expression: No

· Operation: AND

注意: 「NOT」一致ルールを定義するときは、これに続けて、一致する結果が得られる「AND」ルールを必ず定義する必要があります。これを行わないと、Logon Managerはフォームに応答しません。

その他の一般的なマッチング・ルール・チェーンを作成する例を次に示します。次の場合に一致する結果を得るには:

· ルール1かつルール2: この順序で、AND演算子を使用して両方のルールを構成します。

· ルール1またはルール2: この順序で、AND演算子を使用してルール1を構成し、OR演算子を使用してルール2を構成します。

· ルール1かつルール2であるが、ルール3ではない: 前述と同じです。「NOT」ルールをチェーン内で最初に配置し、その後に2つの「AND」ルールを配置します。

· ルール1またはルール2であり、ルール3ではない: ルール1を「AND」ルール、ルール2を「OR」ルール、ルール3を「NOT」ルールとして構成してから、「NOT」ルールをチェーン内で最初に配置し、その後に「AND」ルールと「OR」ルールを配置します。

ワイルドカードを使用した検出基準の構成

? (1文字)や* (スペースを除く文字の任意の組合せ)などのワイルドカードは、動的な検出基準で最も一般的に使用される方法です。フォーム定義で基準を構成する際に「Wildcard」オプションを使用し、次のガイドラインに従って使用します:

· Je???eは、JeanneとJessieの両方と一致します。ただし、Jeanineとは一致しません(文字列の長さも、文字の順序も一致しないためです)。

· Je*eは、Jeで始まり、eで終わるすべての語と一致し、前述の3つの例は、この場合はすべて一致します。

· webapp*.company.comは、webappで始まるホスト名を含むすべてのURLと一致します。この方法は、共通のURLを使用して複数のアプリケーションのロード・バランスおよびマスクが実現されていて、アクセスするたびにアプリケーションが異なる物理ホストからロードされるためアプリケーションのURLが変化するような場合に、そのURLを照合する手段として便利です。

正規表現を使用した検出基準の構成

ATLフレームワークがサポートする正規表現を使用すると、このガイドで前述した基準に対してLogon Managerが一致すると認識するテキスト・パターンを作成することもできます。(フォーム定義で基準を構成する際に、「Regular expression」オプションを使用します)。参考として、最も一般的に使用される演算子およびメタ文字を次に示します:

表現	説明
[ ]	大カッコ内のいずれかの文字と一致する文字クラスを示します。例: [abc]は"a"、"b"および"c"と一致します。
( )	文字をグループ化する演算子を示します。例: (\d+,)*\d+は、カンマで区切られた数字のリストと一致します("1"、"1,23,456"など)。
{ }	一致クラスを示します。
\|	2つの式を区切り、そのうちの1つが完全に一致します。例: T\|theは、"The"または"the"と一致します。
.	任意の1文字と一致します。
^	^が文字クラスの先頭にある場合、その文字クラスは否定されます。否定された文字クラスは、大カッコ内の文字以外の任意の文字と一致します。例: [^abc]は、"a"、"b"および"c"以外のどの文字とも一致します。正規表現の先頭に^がある場合、入力の先頭と一致します。例: ^[abc]は、"a"、"b"または"c"で始まる入力のみと一致します。
$	正規表現の末尾にある$は、入力の最後と一致します。例: [0-9]$は、入力の最後の数字と一致します。
-	文字クラスでは、ハイフンは文字の範囲を示します。例: [0-9]は、"0"から"9"の任意の数字と一致します。
!	後に続く式を否定します。
?	前にある式がオプションであることを示します。1回一致するか、またはまったく一致しません。例: [0-9][0-9]?は"2"および"12"と一致します。

表現

説明

前にある式が1回以上一致することを示します。

例: [0-9]+は、"1"、"13"、"666"などと一致します。

前にある式が0回以上一致することを示します。

??,+?,*?

?、+および*の「最長一致でない」バージョン。できるかぎり多く一致する「最長一致」バージョンと異なり、これらはできるかぎり少なく一致します。

例: 入力を<abc><def>とすると、<.*?>は<abc>と一致するのに対して、<.*>は<abc><def>と一致します。

次の文字がリテラルに解釈されることを強制するエスケープ文字。

例: [0-9]+は1つ以上の数字と一致しますが、[0-9]\+は後にプラス文字の後にくる数字と一致します。

\の後に数字のnがある場合は、n番目の一致グループ(0から始まる)と一致します。

例: <{.*?}>.*?</\0>は<head>Contents</head>と一致します。

\は略語にも使用されるため、次に最も一般的な略語を示します:

略語	説明
\a	任意の英数字文字。a-z、A-Z、0-9の代替
\b	空白(ブランク)。\\tの代替
\c	任意のアルファベット文字。a-z、A-Zの代替
	任意の10進数字。0-9の代替
\d \h	任意の16進数字。0-9、a-f、A-Fの代替
\n	新しい行。\r\|\r?\nの代替
\q	引用符付き文字列。 \"[^\"]\"\|\'[^\']\'の代替
\z	整数。0-9+の代替

フォームのレスポンスの理解

Logon Managerは正常にWebフォームとその入力フィールドを識別すると、適切なヘルパー・オブジェクトを使用してターゲット・フィールドに移入し、フォームの送信コントロールを動作させます。Webページのコードの記述方法に応じて、次に説明するレスポンス方式のいずれかを使用します。

コントロールID

これは、ほとんどのWebアプリケーションでデフォルトかつ推奨されるフォーム・レスポンス方式です。この方式では、Logon ManagerはブラウザのAPIを使用して、適切な資格証明をプログラムによってターゲット・フィールドに注入し、送信コントロールを動作させます。

ただし、Logon Managerがフォームのフィールドおよびコントロールとプログラムで対話する機能が妨げられたり、禁止されるような方法でWebページが記述されている場合、またはサインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。

SendKeys

この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・フォームと対話することができます。エージェントがフォームのフィールドおよびコントロールとプログラムによって対話できない場合は、この方法を使用します。たとえば、ログオン・フォームがAdobe Flashで実装されている場合は、マウス・クリックを送信してターゲット・フィールドを選択し、キーストロークを送信してデータを移入し、最後のマウス・クリックを送信して送信コントロールを動作させる必要があります。

コントロールIDとSendKeys

これは、前述の2つの方式を組み合せて両方の長所を活かすもので、プログラムでは実行できないアクションを必要とするサインオン・シナリオのソリューションとして望ましい方式です。可能な場合は常にコントロールIDを使用してフォームと対話する一方で、キーストロークおよびマウス・クリックを送信して、フィールドのフォーカス設定、チェック・ボックスの選択、エージェントがターゲット・アプリケーション内ではプログラムで実行できないその他のアクションなどのタスクを実行します。

たとえば、カスケード検証のために特定の順序でフィールドに移入する必要がある場合(つまり、ユーザー名フィールドにデータが移入されたときにかぎりパスワード・フィールドがアクティブになる場合)、コントロールIDを使用して資格証明をフィールドに注入しますが、各フィールドの注入の合間にSendKeysで[Tab]キーストロークを送信してフィールドのフォーカスを移動することになります。

注意: この混合モードを実装するには、最初にSendKeysレスポンス方式を使用するようにフォームを構成し、目的のSendKeysアクションを構成し、そのアクションの構成中に、プログラム的なコントロールIDレスポンス方式を保持するアクションに対して「Inject directly into control」オプションを有効にします。

第2部: フォームの構成およびテスト

この部では、Windowsアプリケーション・フォームを構成およびテストする際に推奨されるベスト・プラクティスの手順を示します。内容は次のとおりです:

フォームの最適な構成の確認

フォームを構成する際に、この項の情報を使用して、ターゲット・アプリケーションの要件および機能に基づいて最適な構成を確認します。

ログオン・フォームの最適な構成の確認

ターゲット・フィールドとコントロールが「Web Form」ウィザードで表示されますか

ほとんどの場合、「Web Form」ウィザードはターゲット・フォームに存在する資格証明フィールドおよびコントロールを正常に検出して表示します。フィールドまたはコントロールの一部またはすべてが欠落している場合は、次のいずれかを実行します。

· フィールドまたはコントロールがフォーム・ウィザードに表示されない場合、ログオン・フォームが別のURLを持つか、ログオン・フォームがポップアップ内にあります。「ページ、要素またはポップアップのURLの取得」の説明に従ってこのURLを取得し、ページの主要URLのかわりに、ウィザードに提供します。

· 送信コントロールが認識されない場合、「Show Anchor Tags」オプションを有効にして、実装されているコントロールをアンカー(<A HREF=)・タグとして表示します。

· それでもフィールドが表示されない場合は、さらなるサポートを受けるために「Oracleサポートへの問合せ」を参照してください。

フィールド名は非一意または動的ですか

ターゲット・フィールド要素の名前が一意でない場合、または動的な場合は、要素名のかわりに序数を使用して、Logon Managerに対するフィールドを識別します。該当するかどうかを確認するには、ページのDOMまたはソース・コード(あるいはその両方)を調べます。詳細は、「フィールド検出の理解」を参照してください。

ページまたは要素のURLは動的ですか

ページまたはフォーム要素のURLが動的な場合は、ワイルドカードまたは正規表現を使用してエージェントのレスポンスを目的のURLまたはURL範囲に制限する必要があります。詳細は、「URL検出の理解」を参照してください。

ログオン・フォームはFlashアプレットですか

ログオン・フォームをAdobe Flashで実装した場合、Logon Managerはそのフィールドおよびコントロールとプログラム的に対話することはできないため、この場合はSendKeys方式を使用してフォームと対話します。

送信コントロールはイメージですか

送信コントロールがイメージで、そのURLが動的な場合(つまり、イメージが分散環境でホストされていて、URLのホスト名部分が静的でない場合)、ワイルドカードまたは正規表現を使用して目的のURL範囲がコントロールに対して有効になるように指定する必要があります。そうしないと、Logon Managerでは、コントロールURLが、テンプレート構成に使用された元の静的値と異なるとすぐに、コントロールの検出が停止されます。詳細は、「URL検出の理解」を参照してください。

ページにターゲット・フィールド以外のフィールドがありますか

ページに、ターゲット・フィールド以外の入力フィールドおよびコントロールがある場合、マッチングを使用してエージェントのレスポンスを目的のフィールドに制限します。詳細は、「追加のフィールド検出基準の構成」を参照してください。

アプリケーションでログオン成功または失敗のメッセージを表示しますか

アプリケーションによっては、ログオンの成功または失敗を示すメッセージが表示されます。
その場合は、アプリケーション・テンプレートでログオン成功フォームまたはログオン失敗フォーム(あるいはその両方)を定義します。

パスワード変更フォームの最適な構成の確認

ログオン・フォームとパスワード変更フォームは同一画面上にありますか

アプリケーションによっては、ユーザー名フィールド、またはアプリケーションのパスワード変更(PWC)フォームを起動する「Change Password」ボタンなど、ログオン関連のフィールドまたはコントロールを含むパスワード変更フォームを表示する場合があります。「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションは表示されず、ユーザーは自動的にログインされます。

ユーザーが目的のアクションを選択できるようにするには、テンプレートでログオン・フォームおよびパスワード変更フォームを定義します。エージェントは、ログオン・フォームおよびパスワード変更フォームが統合されたアプリケーションに応答する場合は、ユーザーに目的のアクション(ログオンまたはパスワード変更)を選択するように求めます。

注意: アクション・チューザ機能の猶予期間を構成するオプションもあります。この猶予期間の間、エージェントは、自動的にログオンを優先アクションと想定して、目的のアクションの選択を求めることなくユーザーをログオンさせます。このオプションは、アプリケーション・テンプレート・ダイアログの「Miscellaneous」タブに、「Action Chooser Grace Period」という名前であります。

パスワード変更を開始するためにアクションは必要ですか

フォームでパスワード変更を開始するアクションが必要な場合(チェック・ボックスの選択など)、Webアプリケーションの性質上、Logon Managerはそのアクションをプログラム的には完了できない場合があります。
その場合は、可能であればSendKeys方式を使用してターゲット・コントロールと対話し、それ以外の場合は必要なアクションを手動で実行するようにユーザーに指示します。

ターゲット・フィールドとコントロールが「Web Form」ウィザードで表示されますか

· それでもフィールドが表示されない場合は、さらなるサポートを受けるために「Oracleサポートへの問合せ」を参照してください。

アプリケーションで新しいパスワードの確認は必要ですか

アプリケーションによっては、パスワードの変更を実行する際に、ユーザーに新しいパスワードの確認を求めます。ターゲット・アプリケーションでこのようなフォームを表示する場合は、テンプレートで2つ目のログオン・フォームを定義し、それをパスワード確認フォームに応答するように構成します。

同じデータを複数のフィールドに注入する必要はありますか

同じデータを複数のフィールド(「Password」、「Confirm Password」フィールドを含むフォームなど)に注入する必要があり、エージェントによってその両方に新しいパスワードを注入する場合は、「Web Form」ウィザードの「Allow Multiple Field Designation」オプションを有効にして、それに従ってフィールドを割り当てます。