対象読者

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

また、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部: Windowsアプリケーション

この章では、特定のサインオン・シナリオを解決するためにWindowsアプリケーション・テンプレートを構成する方法と理由の理解に必要な概念について説明し、また、Windowsアプリケーション・フォームを
構成およびテストする手順の推奨されるベスト・プラクティスについて、およびエージェントのアプリケーション・フォームに対する検出や応答が不安定になる可能性がある最も一般的な問題の診断と解決手順について説明します。内容は次のとおりです:

・コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

・ SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

・マッチングのトラブルシューティング

・ログオン・ループのトラブルシューティング

・ Javaアプリケーションの問題のトラブルシューティング

ヒント: この章のトラブルシューティングの手順で問題を解決できない場合は、Logon Managerのアクティビティの追跡とロギングを行い、記録された情報を分析のためにOracleサポートに送信することにより、さらにトラブルシューティングを行うことができます。このために、Oracleではトレース・コントローラ・ユーティリティ(Oracleサポートから入手可能)を提供しています。ユーティリティの使用方法の詳細は、Enterprise Single Sign-On Suite Plus管理者ガイドのトレース・コントローラ・ユーティリティの使用に関する説明を参照してください。

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

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

アプリケーション・ウィンドウを認識するため、エージェントは現在ログインしているユーザーのウィンドウ・メッセージ・キューを絶えず監視して応答します:

1. エージェントは、ウィンドウを検出します。 新しいウィンドウを検出するたびに、エージェントは次の手順を実行します:

a. すべての使用可能なWindowsアプリケーション・テンプレートで、テンプレートに定義された識別基準の値に一致するものを検索します。(ウィンドウ・タイトル、ウィンドウ・クラスおよび実行可能ファイルの名前を含みます。)

b. ウィンドウに表示された基準に構成が一致する、1つ目のテンプレートを選択します。

c. レスポンス・プロセスを開始します。

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

a. (オプション)フィールド・フォーカスの設定のような、アプリケーションによってログオン・フォームまたはパスワード変更フォームの起動やアクティブ化が必要になるアクションを実行します。

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

c. 「Logon」ボタンの押下など、資格証明をアプリケーションに送信して処理するために必要なアクションを実行します。

d. (オプション)新しいパスワードの確認など、補足情報のフォームを検出し、必要なアクションを実行します。

ウィンドウ検出の理解

(Windowsメッセージ・キューを通して)新しいウィンドウのインスタンス化を検出したエージェントは、そのウィンドウの次に示す特性値を調べて、それらの値を使用可能な各アプリケーション・テンプレートに格納されている値と比較し、その値が含まれるウィンドウとフォームを一意に特定します:

・ウィンドウのタイトル

・ウィンドウのクラス

・実行可能ファイルの名前(モジュール名またはAppPath keyとも呼ばれる)

注意: アプリケーション・テンプレートは、アプリケーション・ウィンドウとそれらが含まれるフォームの検出方法、およびアプリケーション・ウィンドウに対するレスポンス方法をLogon Manager Agentに指示するための一連の構成オプションです。

このような識別基準の値を、ターゲット・ウィンドウと、ターゲット・ウィンドウ以外のウィンドウで共有する場合、エージェントはターゲット・ウィンドウの他に、そのようなウィンドウに対しても誤って応答する場合があります。このような場合は、これらの基準に対して取り得る値をより詳細に指定するようなマッチングを使用し、その構成でウィンドウとフォームをエージェントで一意に識別できるようにする必要があります。マッチングに関する詳細は、「マッチングの使用による検出精度の向上」を参照してください。

一致が検出されると、エージェントは一致した1つ目のテンプレートに定義されたフォームに応答します(ユーザーをログオンさせる、パスワード変更を開始する、など)。

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

エージェントは、アプリケーション・ウィンドウを認識すると、ログオン・フォームまたはパスワード変更フォームなどのフォームを構成する、フィールドとコントロールの存在をチェックします。たとえば通常ログオン・フォームには、少なくともユーザー名フィールド、パスワード・フィールドおよびアプリケーションに資格証明を送信するボタンが含まれます。ログオン・フォームの例を示します。

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

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

・ログオン

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

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

・パスワードの変更

・パスワードの確認(新しいパスワードを確認するように求めるダイアログ)

・パスワード変更の成功(パスワード変更の成功を示すダイアログ)

・パスワード変更の失敗(新しいパスワードが拒否されたことを示すダイアログ)

同じアプリケーション・ウィンドウに、(ログオンやパスワード変更などの)呼び出される機能に応じて異なるフォームを含めることができるため、そのウィンドウで表示できる複数のフォームの定義を、単一のテンプレートに含めることができます。ほとんどのアプリケーションの場合、定義する必要があるのは、Logon Managerで応答するフォームのみです。

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

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

サポートされるフォーム・レスポンス方式

ターゲット・アプリケーションの設計に応じて、Logon Managerは次のいずれの方式を使用して、ターゲット・フォームのフィールドおよびコントロールと対話することができます。

コントロールID

これは、ほとんどのWindowsアプリケーションでデフォルトかつ推奨されるフォームの対話方式です。この方法は、Windows APIを使用してフォーム内のフィールドおよびコントロールを識別し、対話します。Windows API準拠のアプリケーションでは、各フィールドとコントロールの一意のコントロールIDがオペレーティング・システムに対して公開されます。エージェントはこれらのコントロールIDを検出し、コントロールIDが示すオブジェクト(パスワード・フィールド、「submit」ボタンなど)の用途を意味する特定のサインオン機能にバインドします。

注意: アプリケーションで公開されるコントロールIDのいくつか、またはそのすべてが、一意ではないか動的である場合、これらをエージェントで序数(ウィンドウ内の各アイテムに上から下へ、左から右に割り当てられる連続したID番号)に置き換えて、検出されたフィールドとコントロールを一意に識別することができます。

フィールドまたはコントロールのコントロールIDが公開されていない場合、またはサインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。

?SendKeys

この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・アプリケーションと対話することができます。この方法は、エージェントがターゲット・フィールドおよびコントロールをプログラムで検出できないか、または対話できない場合に使用します。たとえば、アプリケーションがフィールドおよびコントロールのいずれのコントロールIDも公開しない場合は、フィールドに移入する個々のキーストローク、フィールドを切り替えるマウス・クリックまたは[Tab]キーストローク、ログオン・ボタンを動作させる最後のマウス・クリックを送信する必要があります。

注意: コントロールIDによる方法を使用するようにフォーム定義を構成した場合、アプリケーションの非互換性によりLogon Managerが資格証明をプログラム的に注入することに失敗すると、Logon Managerはデフォルトで自動的にSendKeysによる方法にフォール・バックして注入を再試行し、その結果間違ったウィンドウまたはアプリケーションに資格証明が注入される可能性があります。このフォール・バックの動作を、「SendKeysの自動フォールバックの無効化」の手順に従って無効にすることができます。

コントロールIDとSendKeys

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

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

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

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

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

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

ターゲット・ウィンドウは非一意ですか

エージェントがターゲット・ウィンドウを他のウィンドウから一意に区別できない場合(つまり、別のウィンドウのウィンドウ・タイトル、クラスまたはモジュール名、あるいはそのすべてがターゲット・ウィンドウと同一である場合)、エージェントはターゲット・ウィンドウの他にこれらのウィンドウに誤って応答する場合があります。この問題の原因および解決手順については、「フォームの検出のトラブルシューティング」を参照してください。

ターゲット・ウィンドウのタイトルは空白または動的ですか

ウィンドウ・タイトルが空白の場合は特別な構成は必要ありませんが、ウィンドウ・タイトルに動的なテキストを使用している場合は正規表現または環境変数を使用して照合することができます。詳細は、「マッチングの使用による検出精度の向上」を参照してください。

ターゲット・ウィンドウのクラスは動的ですか

ターゲット・ウィンドウのウィンドウ・クラスが部分的に、または完全に動的な場合、エージェントがそのタイトルで一意にターゲット・ウィンドウを識別できるようにマッチングを使用する必要があります。詳細は、「マッチングの使用による検出精度の向上」を参照してください。

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

ほとんどの場合、「Form」ウィザードはターゲット・ウィンドウに存在する資格証明フィールドおよびコントロールを正常に検出して表示します。「Form」ウィザードにフィールドまたはコントロールが表示されない場合、またはリストされる項目がターゲット・ウィンドウのフィールドまたはコントロールと対応しない場合は、SendKeysを使用してフィールドまたはコントロールと対話する必要がある場合があります。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

フォームのコントロールIDは非一意または動的ですか

サインオン用に有効にする資格証明フィールドおよびコントロールを特定したら、そのコントロールIDが一意であることを確認します。重複があった場合、アプリケーションへのLogon Managerのレスポンスの信頼性が低くなる可能性があるため、問題のフィールドおよびコントロールとの対話には序数を使用します。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

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

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

アプリケーションによっては、ユーザー名フィールドや「Change Password」ボタンなど、ログオン関連のフィールドまたはコントロールを含むパスワード変更フォームを表示する場合があります。たとえば、次に示すログオン画面には「Change」ボタンがあります。

この「Change」ボタンは、パスワード変更画面を起動します。

「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションが表示されず、ユーザーは自動的にログインされます。

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

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

ログオン・フォームとは異なるタブにパスワード変更フォームはありますか

ログオン・フォームとパスワード変更フォームをテンプレートで定義します。エージェントは、パスワードの変更が開始されるとパスワード変更タブに自動的に切り替わり、パスワード変更フォーム・タブを別のウィンドウとして扱います。

注意: WinAPI仕様に完全に準拠するタブを実装するアプリケーションのみがサポートされます。

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

フォームでパスワード変更を開始するアクションが必要な場合(チェック・ボックスの選択など)に、エージェントがそのアクションをプログラム的には実行できないときは、SendKeysを使用して、アプリケーションにキーストロークまたはマウス・クリック(あるいはその両方)を送信してそのアクションを完了する必要がある場合があります。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

ターゲット・ウィンドウは非一意ですか

エージェントがターゲット・ウィンドウを他の類似のウィンドウから一意に区別できない場合、つまりウィンドウ・タイトル、クラスおよびモジュール名がターゲット・ウィンドウと同一である別のウィンドウがインスタンス化されている場合、エージェントはターゲット・ウィンドウの他にこのようなウィンドウに誤って応答する場合があります。この問題の原因および解決手順については、「フォームの検出のトラブルシューティング」を参照してください。

ターゲット・ウィンドウのタイトルは空白または動的ですか

ターゲット・ウィンドウのクラスは動的ですか

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

フォームのコントロールIDは非一意または動的ですか

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

アプリケーションによっては、パスワードの変更を実行する際に、ユーザーに新しいパスワードの確認を求めます。ターゲット・アプリケーションでこのようなダイアログを表示する場合は、パスワード変更フォームを構成し、確認ダイアログに応答するように「Confirm Password」を構成します。詳細は、「フォームの構成」を参照してください。

アプリケーションでパスワード変更の成功または失敗のダイアログ(あるいはその両方)を表示しますか

アプリケーションによっては、パスワード変更の成功または失敗を示すメッセージを表示します。
その場合は、アプリケーション・テンプレートでパスワード変更の成功フォーム、またはパスワード変更の失敗フォームを定義します。詳細は、「フォームの構成」を参照してください。

フォームの構成

この項の手順は、このガイドの前の方で説明した概念および用語を使用して説明します。この項の手順を実行するときは、「フォームの最適な構成の確認」を参照して、ターゲット・アプリケーションに最も適した構成を決定してください。

コントロールIDを使用したフォームの構成

コントロールIDレスポンス方式を使用するWindowsアプリケーション・フォームを構成するには、次の手順を実行します。

1. Logon Manager Administrative Consoleを開きます。デフォルトでは、ショートカットは「スタート」a「プログラム」a「Oracle」a「ESSO-LM Administrative Console」にあります。

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します:

・新しいテンプレートを作成し、そのログオン・フォームを定義する場合:

i. 右側のペインで「Add」をクリックします。

ii. 「New Application」ダイアログで、テンプレートのわかりやすい名前を入力し、「Finish」をクリックします。
新しいテンプレートが、格納済テンプレートのリストに表示されます。

注意: 2つ以上のアプリケーション・テンプレートに対して、テンプレートのいずれかの名前が別のテンプレートの名前の先頭部分と同じになるように名前を付けると、エージェントは誤って最も短い名前を持つテンプレートを使用して、すべての対象アプリケーションに応答します。この動作を回避するには、テンプレート名が同じテキスト文字列で始まらないようにします。

・既存のテンプレートにログオン・フォーム定義を追加する場合は、次の手順を実行します:

i. 「Applications」ノードを展開し、目的のテンプレートを選択します。
テンプレートが右側のペインに表示されます。

ii. ペインの下部で「Add」をクリックします。

3. 表示された「Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します:

a. 「Form Type」画面で、目的のフォーム・タイプを選択し、「Next」をクリックします。

b. 「Application Window」画面で、ターゲット・フォームを含むウィンドウを選択します。
選択したウィンドウの周囲には太い青色の境界線が表示され、選択されたことが示されます。

???????????????????????????????

注意: 複数のウィンドウのいずれかのパラメータで同じ値が使用されている場合、エージェントはターゲット・ウィンドウのみに応答するのではなく、これらすべてのウィンドウすべてに誤って応答する可能性があります。この問題の詳細は、「ウィンドウ検出のトラブルシューティング」を参照してください。

c. 「Credential Fields」画面で、次のようにリスト内のオブジェクトの中からターゲット・フィールドおよびコントロールを選択して構成します:

i. (オプション)フォームの複数のフィールドに同じデータを注入する必要がある場合(たとえば、「Password」および「Confirm Password」フィールドへのパスワードの注入)、「Allow multiple field designation」オプションを有効にします。

ii. 目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。

注意: ほとんどの場合「Detect Fields」機能は正確ですが、正確性を保証するためにも、常にフィールドおよびコントロールを手動で構成することをお薦めします。

注意:???? 送信ボタン(通常は「OK」、「Logon」などのラベルが付いているボタン)がリストに表示されない場合でも、Logon Managerは資格証明の注入後に、アプリケーションに送信アクションを送信します。

iii. アプリケーションで、Logon ManagerがそのフィールドおよびコントロールとSendKeys方式で対話する必要がある場合(キーストロークやマウス・クリックなどのユーザー入力をエミュレートする場合)は、「Use "SendKeys" for this form instead of IDs」を選択します。アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください。

iv. アプリケーションで、Logon Managerがそのフィールドおよびコントロールの特定にコントロールIDではなく序数を使用する必要がある場合は、「Use ordinals instead of control IDs」を選択します。
(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。

d. 「Summary」画面で、構成の選択内容を確認します。選択したオプションを変更する場合は「Back」をクリックし、変更がない場合は「Finish」をクリックします。

e. 表示されたテンプレート・プロパティ・ダイアログで、「OK」をクリックして新しいフォーム定義を保存します。

注意: テンプレートのその他のオプションを構成する必要があり、その場所と機能がわかっている場合は、ここで実行できます。このダイアログに存在するオプションの構成手順については、このガイドの後半を参照してください。

4. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

SendKeysを使用したフォームの構成

SendKeysレスポンス方式を使用するWindowsアプリケーション・フォームを構成するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを開きます。デフォルトでは、ショートカットは
「スタート」a「プログラム」a「Oracle」a「Logon Manager Console」にあります。

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します:

・新しいテンプレートを作成し、そのログオン・フォームを定義する場合:

i. 右側のペインで「Add」をクリックします。

・既存のテンプレートにログオン・フォーム定義を追加する場合は、次の手順を実行します:

i. 「Applications」ノードを展開し、目的のテンプレートを選択します。
テンプレートが右側のペインに表示されます。

ii. ペインの下部で「Add」をクリックします。

3. 表示された「Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します:

a. 「Form Type」画面で、目的のフォーム・タイプを選択し、「Next」をクリックします。

???????????????????????????????

c. 「Credential Fields」画面で、「Use "Send Keys" for this form instead of IDs」を選択し、「Next」をクリックします。

e. 表示されたテンプレート・プロパティ・ダイアログで、「Fields」タブを選択します。

f. 「Edit」をクリックして、「SendKeys」エディタ・ダイアログを表示します。

g. 必要に応じてSendKeysアクションを構成します。各オプションの詳細は、コンソール・ヘルプを参照してください。

注意: フォームがSendKeysモードである場合に、アクションをプログラム使用(つまり、コントロールIDレスポンス方式を使用)として構成するには、アクションの「Inject directly into control」オプションを有効にします。

h. 終了したら「OK」をクリックして変更を保存し、「SendKeys」エディタ・ダイアログを終了します。

i. フォーム・プロパティ・ダイアログの「OK」をクリックして、フォーム構成を保存します。

4. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

マッチングの使用によるレスポンス精度の向上

マッチングは、Logon Managerがウィンドウおよびそのウィンドウ内のフォームを、同じセッション内に存在する可能性のある他のウィンドウおよびフォームから一意に区別できるメカニズムです。「マッチング」という用語は、ウィンドウ・タイトルやフィールド・ラベルなどの特定のパラメータ値を、テンプレートに格納されている値と比較照合することを指します。

たとえば、アプリケーションで、情報メッセージ、ウィザード、ログオン・フォームなどの様々な目的に使用されるが、同じウィンドウ・タイトルとクラスを共有するダイアログ・ボックスをインスタンス化する場合があります。このような場合、エージェントのレスポンスを特定のフォームに制限するために、一意の要素に対するマッチングを構成することになります。

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

・ウィンドウのタイトル(空白、および部分的または完全に動的な値を含む)

・ウィンドウのクラス(特定の値に対する制限を含む)

・実行可能ファイル名(モジュール名とも呼ばれる)

・フィールド、コントロールまたはテキスト文字列

空白または動的値のマッチング

Microsoft .NETフレームワークでサポートされる正規表現を使用すると、基準に対してエージェントが一致すると認識する必要があるテキスト・パターンを作成することもできます。? (1文字)や* (スペースを除く文字の任意の組合せ)などのワイルドカードは、最も一般的に使用される正規表現です。

次に例を示します。

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

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

・ Afx:400000:0:10011:0:*は最後の6桁が変数であるすべてのウィンドウ・クラスと一致します。この場合Afx:400000:0:10011:0:130927は一致します。

ターゲット基準(ウィンドウ・タイトルなど)に1つ以上のシステム変数(現在ログインしているユーザー名など)が含まれる場合、照合するテキスト・パターンの一部としてそれらの変数名を使用できます。
たとえば、次のパターンは、「Password Expired ?」で始まり、現在ログオンしているユーザーの名前を大文字で含むウィンドウ・タイトルに一致します:

パスワードの期限切れ - %UC%%DOMAINUSER%

次を照合します:

・ 部分的または完全に動的な値: ターゲット・パラメータ値に対して一致するテキスト文字列を作成するために、必要に応じて、正規表現、環境変数および静的テキストを使用します。

・ 空白値: 値としてnullの正規表現^$を指定します。

注意: 空白のウィンドウ・タイトルは自動でサポートされるために、特別な構成は必要ありません。

この項の手順を実行する前に、次の手順を実行します:

1. Logon Manager Administrative Consoleを起動します。

2. 左側のペインのツリーで「Applications」ノードを展開し、目的のテンプレートを選択します。

3. 右側のペインで、「General」タブを選択します。

4. 「Edit」をクリックして、フォーム・プロパティ・ダイアログを表示します。

5. 次の目的の手順に進みます:

・ウィンドウ・タイトルのマッチング

・ウィンドウ・クラスのマッチング

・実行可能ファイル名のマッチング

・フィールド、コントロールまたはテキスト文字列のマッチング

ウィンドウ・タイトルのマッチング

1つ以上の静的または動的なウィンドウ・タイトルを照合するには、次の手順を実行します:

1. テンプレート・プロパティ・ダイアログで、「Identification」タブを選択します。

2. 「Window Titles」セクションで、次のいずれかを実行します:

・新しいマッチング・ルールを追加するには、「Add」をクリックします。

・既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。

3. 「Window Title」ダイアログで、次の手順を実行します:

a. 目的のマッチング・タイプを選択します:

・ Exact: 入力されたとおりの文字列に正確に一致します。静的ウィンドウ・タイトルに対して使用します。

・ Wildcard: テキストとワイルドカードを組み合せたマッチングが可能です。空白または動的なウィンドウ・タイトルに対して使用します。

・ Regular expression: テキストと正規表現を組み合せたマッチングが可能です。動的ウィンドウ・タイトルに対して使用します。

詳細は、「空白または動的値のマッチング」を参照してください。

b. エージェントがマッチングを実行する対象のテキスト文字列を入力します。

c. 「OK」をクリックして、新しいマッチング・ルールを追加します。

4. 「OK」をクリックして、プロパティ・ダイアログを閉じます。

ウィンドウ・クラスのマッチング

1つ以上の静的または動的なウィンドウ・クラスを照合するには、次の手順を実行します:

1. フォーム・プロパティ・ダイアログで、「Matching」タブを選択します。

2. 許可されるウィンドウ・クラスを、次のように指定します:

・指定するクラスの正確な値を知らない場合は、次の手順を実行します:

i. 「Allowable Class」フィールドで、「Choose」をクリックします。

ii. 表示されたダイアログで、ターゲット・ウィンドウを選択します。

iii. 「OK」をクリックします。選択したウィンドウのクラスが、「Allowable Class」フィールドに移入されます。

・エージェントで認識する必要があるクラスの正確な値を知っている場合は、「Allowable Class」フィールドにカンマ区切りのリストとして入力します。1つ以上の動的なウィンドウ・クラスを照合する場合は、「Regular Expression」チェック・ボックスを選択し、必要な正規表現をリストに含めます。

3. エージェントで無視する(応答しない)ウィンドウ・クラスを、次のように指定します:

・指定するクラスの正確な値を知らない場合は、次の手順を実行します:

i. 「Ignore this window class」フィールドで、「Choose」をクリックします。

ii. 表示されたダイアログで、ターゲット・ウィンドウを選択します。

iii. 「OK」をクリックします。選択したウィンドウのクラスが、「Ignore this Window Class」フィールドに移入されます。

・エージェントで認識する必要があるクラスの正確な値を知っている場合は、「Ignore this Window Class」フィールドにカンマ区切りのリストとして入力します。1つ以上の動的なウィンドウ・クラスを照合する場合は、「Regular Expression」チェック・ボックスを選択し、必要な正規表現をリストに含めます。

4. 「OK」をクリックして、プロパティ・ダイアログを閉じます。

実行可能ファイル名のマッチング

特定の実行可能ファイル名を照合するには、次の手順を実行します:

注意: 実行可能ファイル名のマッチングでは、完全一致のみがサポートされます。ワイルドカードまたは正規表現はサポートされていません。

1. フォーム・プロパティ・ダイアログで、「Identification」タブを選択します。

2. 「AppPath Keys」セクションで、次のいずれかを実行します:

・新しいマッチング・ルールを追加するには、「Add」をクリックします。

・既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。

3. 「AppPath Key」ダイアログで、目的の値を入力して「OK」をクリックします。

4. 「OK」をクリックして、テンプレート・プロパティ・ダイアログを閉じます。

フィールド、コントロールまたはテキスト文字列のマッチング

「Matching」タブを使用して、現在選択しているログオンのユーザー資格証明を、同じアプリケーション内の他のログオン・フォーム、パスワード変更フォームまたはパスワード確認フォームにマップします(ここでは、これらのフォームをターゲット・フォームと呼びます)。
エージェントは、ユーザーが指定する一致基準を使用して、同じ資格証明データを使用する類似フォームを区別します。これにより、エージェントは、1組のユーザー資格証明をこのような複数のフォームに適切に適用できます。また、マッチングを使用して、エージェントで無視するフォームを識別することもできます。

特定のフィールドまたはコントロールを照合するには、次の手順を実行します:

1. テンプレート・プロパティ・ダイアログで、「Matching」タブを選択します。

2. 「Matches」セクションで、次のいずれかを実行します:

・新しいマッチング・ルールを追加するには、「Add」をクリックします。

・既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。

3. 表示された「Control Match」ウィザードで、目的のマッチング・タイプを選択します。

4. 「Application Window」画面で、ターゲット・ウィンドウを選択します。

5. 表示された「Match Fields」画面で、目的の一致ルールを構成します。照合するフィールド、コントロールまたはテキスト文字列ごとに、次の手順を実行します:

a. リストで目的の項目を選択し、それを右クリックします。

b. コンテキスト・メニューから目的の一致基準を選択します:

・ Class: この項目の数値のクラス値を照合するように、エージェントに指示します。

・ Style: この項目の数値のスタイル値を照合するように、エージェントに指示します。

・ Text: この項目で表されるテキストを照合するように、エージェントに指示します。入力を求められたら、表示されたダイアログ・ボックスに目的の一致文字列を入力して、「OK」をクリックします。

c. 「Next」をクリックします。

6. 「Credential Fields」画面で、一致した場合に、エージェントがログオンを完了するために使用する資格証明フィールドおよびコントロールを選択して構成します:

a. 目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。

b. アプリケーションで、Logon ManagerがそのフィールドおよびコントロールとSendKeys方式で対話する必要がある場合(キーストロークやマウス・クリックなどのユーザー入力をエミュレートする場合)は、「Use "SendKeys" for this form instead of IDs」を選択します。(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。

c. アプリケーションで、Logon Managerがそのフィールドおよびコントロールの特定にコントロールIDではなく序数を使用する必要がある場合は、「Use ordinals instead of control IDs」を選択します。(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。

d. 「Next」をクリックします。

7. 「Summary」画面で、構成の選択内容を確認します。選択したオプションを変更する場合は「Back」をクリックし、変更がない場合は「Finish」をクリックします。

サービス・ログオンとしてのアプリケーションの構成

Logon Managerで最初にアプリケーション・ウィンドウが検出された後に、そのコンテンツが変更される場合は、アプリケーションをサービス・ログオンとして構成する必要があります。

注意: このオプションを有効にすると、Logon Managerはアプリケーションのウィンドウの更新がないかアクティブにポーリングし、CPU時間の消費が増えるため(ポーリング対象のウィンドウの追加ごとに増加する)、他の検出オプションをすべて使用した後にのみ使用してください。

アプリケーションをサービス・ログオンとして構成するには、次の手順を実行します:

1. 目的のテンプレートを開きます。

2. 「Miscellaneous」タブを選択し、「Service Logon」チェック・ボックスをチェックします。

3. アプリケーションのウィンドウ・クラスを取得します:

a. 「General」タブを選択します。

b. フォーム定義のリストで、ログオン・フォームを選択し、「Edit」をクリックします。

c. フォーム・プロパティ・ダイアログで「Matching」タブを選択し、「Allowable Class」フィールドに存在する値を書き留めます(これは、Logon Managerによってアプリケーションで検出されたウィンドウ・クラスです)。

4. 変更を保存し、更新されたテンプレートをリポジトリにプッシュします(該当する場合)。

5. アプリケーションのウィンドウ・クラスを、ウィンドウ・クラスのリストに追加します(エージェントはこれをシステム・サービスとして認識します):

a. グローバル・エージェント設定のセットをロードします。

b. 左側のツリーで、「Global Agent Settings」a「End-User Experience」a「Windows Apps」にナビゲートします。

c. 「Supported Window Classes for Services」オプションの横のチェック・ボックスがまだ選択されていない場合は、これを選択します。

d. 前述のオプションの横のフィールドに、手順3cで書き留めたウィンドウ・クラスを既存のクラスのリストに、セミコロンで区切って追加します。

6. 変更を保存し、更新した「Supported Window Classes for Services」設定を、管理オーバーライドの一部としてリポジトリにプッシュします。

自動SendKeysフォールバックの無効化

Logon Managerがアプリケーションにプログラム的に応答(コントロールID方式を使用)することができない場合、デフォルトでは、それは自動的にSendKeysレスポンス方式にフォール・バックして、注入を再試行します。特定のシナリオでは、この自動フォールバック動作が望ましくない場合があります(たとえば、Logon Managerは間違ったウィンドウまたはアプリケーションに資格証明を誤って注入し、その資格証明がエンド・ユーザーに公開される場合があります)。この自動フォールバック動作を無効にするには、次のいずれかを実行します:

・特定のフォーム定義の自動SendKeysフォールバックを無効にするには、フォームのプロパティ・ダイアログの「Options」タブで「Fall back to SendKeys if direct injection fails」オプションを無効にします。

・自動SendKeysフォールバックをグローバルに無効にするには、「Global Agent Settings」>「<Target Settings Set>」>「User Experience」>「Application Response」の下の「Allow fallback from control IDs to SendKeys」オプションを、「No」に設定し、変更をリポジトリに公開します。

フォームの構成のテスト

フォームを作成して構成したら、公開前に次の手順を実行してテストします:

1. 左側のツリーの「Applications」ノードを展開し、ターゲット・テンプレートにナビゲートします。

2. ターゲット・テンプレートを右クリックし、コンテキスト・メニューから「Test」を選択します。

3. 表示された「Logon Manager Template Test Manager」ウィンドウで、次の手順を実行します:

a. 「Forms」ペインで、ターゲット・フォームを選択します。

b. 「Interactions」ペインに表示される手順に従います。

c. 次のいずれかを実行します:

・エージェントが期待どおりにアプリケーションに応答し、テストが正常に完了した場合は、「Finish」をクリックします。

・エージェントが期待どおりにアプリケーションに応答しなかった場合は、「Close」をクリックし、この項のトラブルシューティング・フローチャートに従って問題を確認して修正し、手順1-3を繰り返して修正後の構成をテストします。

ログオン・フォームの構成のテスト

エージェントはウィンドウを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・アプリケーションに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「ウィンドウ検出のトラブルシューティング」を参照してください。

エージェントは資格証明を注入しますか

資格証明がユーザーのストア内のターゲット・アプリケーションに対して格納されている場合、エージェントはアプリケーションの検出に成功すると、資格証明を適切なフィールドに注入します。「Auto-Submit」機能が明示的に無効化されていないかぎり、エージェントは自動的に資格証明の送信も行います。資格証明の注入に失敗した場合は、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」および「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

ログアウトでログオン・ループが発生しますか

アプリケーションによってはログアウト時にログオン画面を表示しますが、この場合、それによってエージェントがログオン・ループに入り、エージェントを停止しないかぎり、事実上ユーザーはアプリケーションからログアウトできなくなります。
これが発生した場合は、「ログオン・ループのトラブルシューティング」を参照してください。

エージェントはアプリケーションの再起動後に適切に応答していますか

ターゲット・アプリケーションが停止され、再起動されると、エージェントはアプリケーションに応答し、ユーザーをログオンさせる必要があります。ログオンが発生しない場合は、アプリケーションがユーザー領域ではなくシステム領域で動作することが可能であり、その際はエージェントが監視するパッシブ・メッセージ・キューのかわりにアクティブなポーリングが必要になります。これに該当する場合は、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

パスワード変更フォームの構成のテスト

エージェントはウィンドウを検出しますか

エージェントは資格証明を注入および送信しますか

エージェントはパスワードの変更を検出すると、「Auto Submit」機能が明示的に無効化されていないかぎり、資格証明を適切なフィールドに注入し、アプリケーションに送信します。資格証明の注入が不安定であるか、まったく行われない場合は、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」および「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

Logon Managerで生成される新規パスワードがアプリケーション独自のパスワード・ポリシーを満たさない場合、パスワード変更は失敗します。これに該当するかどうかを確認する場合は、現在エージェントにデプロイされているパスワード生成ポリシーを、ターゲット・アプリケーションのパスワード・ポリシーと比較し、パスワード変更の失敗の原因となる可能性がある非一貫性をすべて修正します。

エージェントはパスワード変更フォームにログオンと同様に応答しますか

エージェントがパスワード変更フォームに対して、ログオン・フォームと同様に応答する場合(つまり、エージェントがユーザーの現在格納されている資格証明を注入および送信する場合)は、次の項目をチェックします。

・テンプレートの構成ミス(誤ったフォーム・タイプ、フィールドおよびコントロール定義など)

・パスワード変更フォームに動的ウィンドウ・タイトルまたはクラスが含まれるかどうかを確認し、それに応じてテンプレートを更新します。

・マッチングを使用している場合は、正しいマッチング・タイプを使用しているかどうかを確認し、マッチング文字列にエラーがないか検証します。

リポジトリへのテンプレートの公開

アプリケーション・テンプレートのテストが正常に終了したら、リポジトリ内の選択したターゲット・コンテナにディレクトリ形式の階層で(デフォルト)、またはフラット形式の構成ファイルとして公開することで、エンドユーザー・マシンに配付できます。

注意: Logon Managerをリポジトリとともにデプロイする方法およびリポジトリ・ツリー構築のベスト・プラクティスは、ご使用のプラットフォームのLogon Managerベスト・プラクティスのガイドを参照してください。

注意: この手順を実行する前に、リポジトリの構造および構成を熟知していることを確認します。

目的のテンプレートおよびその他の構成オブジェクトを選択し、リポジトリに公開するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを起動します。

2. 「Applications」ノードを右クリックし、コンテキスト・メニューから「Publish…」を選択します。
「Publish to Repository」ダイアログが表示されます。

3. 「Available configuration objects」リストで、目的のオブジェクトにナビゲートして選択します。

注意: このリストには、オブジェクトが構成されたカテゴリのみが表示されます。
たとえば、パスワード生成ポリシーが存在しない場合、対応するカテゴリはこのリストに表示されません。

4. 「>>」をクリックして、選択したオブジェクトを、「Selected objects to be published」リストに移動します。
(このリストからオブジェクトを除去して公開しないようにするには、オブジェクトを選択して、「<<」をクリックします。)

5. 次のいずれかを実行して、選択したオブジェクトの公開先のターゲット・コンテナを選択します:

o 以前、目的のコンテナに公開したことがある場合は、「Target Repository」ドロップダウン・リストからそれを選択します。

o 以前、目的のコンテナに公開したことがない場合、またはターゲット・コンテナ・パスが「Target Repository」ドロップダウン・リストに表示されない場合は、「Browse」機能を使用してターゲット・コンテナを検索して選択する必要があります:

i. 「Browse」をクリックして、ディレクトリ・ツリーを参照します。

注意: ディレクトリにまだ接続していない場合は、必要な接続情報を提供するようにコンソールから求められます。

ii. 表示された「Browse for Repository」ダイアログで、ターゲット・コンテナにナビゲートして選択します。

注意: 新しいコンテナを作成する場合は、目的の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択し、新しいコンテナの目的の名前を入力し、「OK」をクリックしてプロセスを完了します。

6. (オプション)構成オブジェクトをフラット形式で格納する必要がある環境の場合は、「Store selected items in configuration files, rather than as individual objects」チェック・ボックスを選択します。 ?

注意: このオプションを選択することで、既存の構成ファイルに格納されているすべての項目が上書きされます(ターゲット・コンテナに存在する場合)。

7. (オプション)初回使用オブジェクト(FTUList)を作成する場合は、対応するチェック・ボックスを選択します。

注意: このオプションは、手順6でフラット形式での構成オブジェクトの格納を選択した場合のみ、アクティブになります。

8. 「Publish」をクリックします。コンソールは、選択したオブジェクトをターゲット・リポジトリに公開します。

注意: 公開プロセスが完了するまで、ダイアログを終了したり、コンソールを閉じようとしないでください。オブジェクトが公開されると、ダイアログは自動的に閉じます。

公開プロセスの詳細は、Logon Manager Administrative Consoleヘルプを参照してください。

ウィンドウ検出のトラブルシューティング

不安定なウィンドウ検出を診断するには、次のステップを使用します。

エージェントはウィンドウを検出しますか

エージェントがウィンドウを検出しない場合は、ターゲット・フォーム定義のプロパティ・ダイアログの「Options」タブにある「Auto-Recognize」オプションが有効になっていることを最初に確認し、有効である場合は次のステップに進みます。

エージェントがターゲット・ウィンドウのみでなく、他のウィンドウにも応答しますか

テンプレートで定義されている特性を備えるすべてのウィンドウにエージェントが応答するため、デフォルトのフォーム構成(フォーム・ウィザードを完了することにより作成)を使用すると、本来無視する必要があるウィンドウに対して不要なレスポンスが行われることがあります。
エージェントがターゲット・ウィンドウを一意に識別できるように、できるだけ特定されるようなテンプレートを構成する必要があります。

注意:? この状況は、エージェントが一意に区別できない複数のサインオン・イベントが発生しているため、重複イベント・モデルと呼ばれることがあります。

より詳細なレスポンス・コントロールが必要かどうかを判断するには、テンプレートを作成するときに「Form Wizard」ウィンドウ内のリストで、重複するウィンドウ・タイトル、モジュール名およびウィンドウ・クラスを調べます。
次の例では、「Login Tester」アプリケーションの2つのインスタンスがモジュール(親プロセス)名とウィンドウ・クラス値を共有しているため、エージェントには同じアプリケーションとして認識されます。

このような場合は、ウィンドウとフォームをエージェントで一意に識別できる基準値に、より詳細な制約を設定するようなマッチングを使用する必要があります。

「Logon Using Logon Manager」トレイ・アイコン・オプションを使用したときに、エージェントはウィンドウを検出しますか

エージェントのシステム・トレイ・アイコンの「Logon Using Logon Manager」オプションを使用して手動でウィンドウ検出を実行してから、次のいずれかを実行します:

・エージェントがウィンドウを検出した場合は、アプリケーションをサービス・ログオンとして構成する必要があることがあります(次のステップに進みます)。

・エージェントのトレイ・アイコンから「Logon Using Logon Manager」オプションを使用して検出を起動しても、エージェントがターゲット・ウィンドウを検出しなかった場合は、ウィンドウ・タイトルやクラスの入力ミスのような、共通構成エラーのテンプレートを確認し、ウィンドウ・タイトルまたはクラスが動的であるかどうかを確認して、テンプレートを適切なものに構成し直してください。

サービスまたは現行ユーザー以外のユーザーでアプリケーションを実行していますか

アプリケーションが、ユーザー領域(現在ログインしているユーザーのアカウント下)ではなく、システム領域(SYSTEMアカウントの下)で動作しているか、または、アプリケーションが現在ログインしているユーザーとは異なるユーザー・アカウントで起動されている場合は、サービス・ログオンとして構成する必要があります。これによってエージェントは、現在ログオンしているユーザーのWindowsメッセージ・キューにあるイベントに対して受動的に応答するのではなく、アプリケーションをアクティブにポーリングすることができます。手順については、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

ウィンドウ・タイトルを検出後に変更しましたか

エージェントがウィンドウを検出した後、そのウィンドウに対する応答を開始する前にターゲット・ウィンドウのタイトルを変更した場合(たとえば、ログオン・フォームを起動したときにウィンドウ・タイトルを変更する場合)、そのアプリケーションをサービス・ログオンとして構成する必要があります。これによってエージェントは、現在ログオンしているユーザーのWindowsメッセージ・キューにあるイベントに対して受動的に応答するのではなく、アプリケーションをアクティブにポーリングすることができます。手順については、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

エージェントがフィールドに移入してもログオンが送信されませんか

資格証明の挿入が、自動的に送信されたものではなかった場合、まず「Auto-Submit」オプションがアプリケーションで有効になっていることを確認します。「Auto Submit」を有効化しても、エージェントからアプリケーションに送信されない場合は、エージェントがフォールドに移入してから資格証明が送信されたかどうかを確認した後で、[Enter]を押します。資格証明が送信される場合は、テンプレートからSubmitアクションを削除します。これによってエージェントでデフォルトのsubmitアクション([Enter]キーストローク)を使用できるようになります。

アプリケーションは、注入された資格証明を拒否しますか

送信された資格証明がアプリケーションで拒否される場合は、そのアプリケーション・テンプレートでWM_CHARスタイルのメッセージングを有効にします。これによってエージェントが代替APIを使用して、ウィンドウのフィールドとコントロールと対話します。これには、テンプレートの「General」タブを選択し、ターゲット・フォームを選択して「Edit」をクリックし、フォームのプロパティ・ダイアログの「Options」タブで、「Use WM_CHAR messages to fill controls」チェック・ボックスを選択します。

フィールドへの移入が不安定ですか

エージェントによるフィールドへの移入が不安定(誤った値、切り捨てられた値、文字化けした値または空白の値を取り込むなど)なときは、1つ以上のターゲットのコントロールIDが動的である場合があります。このような場合、コントロールIDのかわりに序数を使用して、フォーム内のフィールドとコントロールを一意に識別します。序数は、エージェントによってウィンドウ内の各オブジェクトに対して、上から下、左から右に割り当てられる連続したID番号で、これによってエージェントは検出されたフィールドとコントロールをコントロールIDとは別に一意に識別することができます。

コントロールIDではなく序数を使用するようにフォームを切り替えるには、テンプレートの「General」タブでフォームを選択し、「Edit」をクリックして、フォーム・プロパティ・ダイアログで「Wizard」をクリックします。その後、「基本構成」の手順に従ってフォーム定義を再作成しますが、「Credential Fields」画面が表示された場合は、「Use ordinals instead of control IDs」チェックボックスを選択します。ウィザードで新しい構成を選択すると、既存のフォーム定義が上書きされます。

序数を使用しても引き続き問題が発生する場合は、アプリケーションと対話する方法にSendKeysを使用することを検討します。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

事前入力されたフィールドによって誤ったログオンが発生しますか

アプリケーションによっては、ログオン・フォームの表示時にログオン・フィールドの事前入力を行うことがあります(たとえば、ユーザー名のフィールドに、最後に正常にログオンしたユーザーの名前が事前入力されているなど)。1つ以上の[Backspace]または[Delete]キーストロークを送信して、資格証明を注入する前に、事前入力されたフィールドをクリアする必要がある場合があります。

カーソルは常に同じフィールドで開始して、フォーカスを保持しますか

カーソルが必ずしも同じフィールドで開始せず、エージェントによる移入前にフィールドがフォーカスを失う場合は、特定のホットキーの組合せ([Alt]+[U]など)または標準のWindowsキー([Tab]、矢印など)によるフィールドへのナビゲートがアプリケーションで許可されるかどうかを確認します。キーストロークを使用してフィールドにナビゲートできない場合は、次の例に示すとおり、エージェントがフィールド内でクリックできるように、ターゲット・フィールド内の座標ポイントを指定したマウス・クリック・アクションを使用します。

単一のフィールドに複数の値が注入されますか

エージェントが単一のフィールドに複数の値(ユーザー名とパスワードなど)を挿入する場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に応答できていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」a「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

ジャーナル・フックを使用するSendKeysに切り替えると、注入の信頼性が回復しますか

前述の手順の提案を試した後もエージェントが引き続き単一のフィールドに複数の値を注入する場合は、フォームの対話方法をジャーナル・フックを使用するSendKeysに切り替えます。これを行うには、アプリケーション・テンプレートで「General」タブを選択して目的のフォームを選択し、「Edit」をクリックして「Fields」タブを選択し、「Transfer Method」オプションを「SendKeys using Journal Hook」に設定します。

注意: 「“SendKeys” with journal hooks」オプションを使用すると、エージェントが代替APIを使用してキーストロークおよびマウス・クリックをアプリケーションに送信するため、これは通常、Citrix環境で最も効果的です。

注入された値から文字が欠落していますか

注入されたフィールド値から個々の文字が欠落している場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に受け入れることができていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」a「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

マウス・クリック・アクションを使用してフィールドにフォーカスすると、ログオンに成功しますか

ログオンに引き続き失敗する場合は、マウス・クリック・アクションを使用してフォーム内のすべてのフィールドおよびコントロールに対してフォーカスを設定することを検討します。各マウス・クリック・アクションではクリック対象のフィールドまたはコントロールの正確な座標が必要になるため、マウス・クリックが成功するには座標が固定されている必要があることに注意してください。したがって、ウィンドウのサイズが変更されたり、別の解像度で表示されるとコンテンツの位置が変わるような場合は、マウス・クリック・アクションの信頼性が低下する可能性があります。

前述のどの手順でも問題を解決できない場合は、Oracleサポートに連絡してください。

マッチングのトラブルシューティング

ターゲット・フィールドまたはコントロールは「Control Match」ウィザードで認識されますか

「Show all fields」オプションを有効にしても、マッチング対象のフィールドまたはコントロールが「Control Match」ウィザードに表示されない場合、マッチングを実行できない場合があります。このような場合は、Oracleサポートに連絡してください。

フォームのコントロールIDは非一意または動的ですか

1つ以上のターゲットのコントロールIDが一意でない場合、または動的な場合は、コントロールIDのかわりに序数を使用して、フォーム内のフィールドとコントロールを一意に識別します。序数は、エージェントによってウィンドウ内の各オブジェクトに対して、上から下、左から右に割り当てられる連続したID番号で、これによってエージェントは検出されたフィールドとコントロールをコントロールIDとは別に一意に識別することができます。

ログオン・ループのトラブルシューティング

一部のアプリケーションではログアウト時にログオン・フォームが表示されるため、Logon Managerがログオン・フォームを認識してアプリケーションへの再ログインを自動的に行う原因となります。
これによって無限ログオン・ループが作成され、アプリケーションからログアウトできません。管理者は、このループの発生を防ぐために最後のログオン以降、設定された期間内はLogon Managerがアプリケーションにログオンするのを禁止するログオン猶予期間機能を有効にすることを選択できます。

ログアウト後のフォームは、標準ログオン・フォームと異なりますか

ログアウト時に表示されるログオン・フォームがアプリケーションの標準のログオン・フォームと十分に異なっている場合は、マッチングだけでなく「Logon Loop Grace Period」を検討することをお薦めします。

(マッチングの詳細は、「マッチングの使用によるレスポンス精度の向上」を参照してください)。フォームを一意に区別できない場合は、以降で説明するログオン・ループ猶予期間機能を使用します。

「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

ログアウト後のフォームを標準ログオン・フォームと一意に区別できない場合は、指定された猶予期間が完全には経過していない場合にエージェントが同じアプリケーションに自動的にログオンするのを防ぐ猶予期間を構成します。

ログオン・ループ猶予期間タイマーを構成するには、次の手順を実行します:

1. Logon Manager Administrative Consoleで目的のテンプレートを開き、「Miscellaneous」タブを選択します。

2. 「Logon Loop Grace Period」フィールドで、ドロップダウン・リストから目的の操作モードを選択します。

・ Prompt: エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、ログオンを完了するか、アプリケーションを無視するかを尋ねるプロンプトを表示します。

・ Silent: エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、アプリケーションを無視し、ユーザーのログオンを行いません。

・ None: 猶予期間タイマーを非アクティブ化します。エージェントは、アプリケーションのログオン・フォームを検出するたびにアプリケーションに応答します。

3. 猶予期間が有効なときにエージェントに実行させる内容に応じて、次のいずれかを実行します:

・アプリケーションの実行可能ファイルの起動が検出されるたびにエージェントがユーザーのログオンを行うようにするには、「Reset for each process」チェック・ボックスを選択します。

・猶予期間が経過するまでエージェントがアプリケーションを無視するようにするは、「Reset for each process」チェック・ボックスを空白のままにします。

4. 変更を保存してリポジトリにコミットします(該当する場合)。

注意: ログオン猶予期間タイマーを構成しても、ログオン・ループが特定のフォーム定義で発生する場合は、フォーム定義の「Options」タブの「Adhere to logon loop grace period」オプションが有効になっていることを確認します。

この方法でもアプリケーションのログオン・ループが解決されない場合は、Oracleサポートに連絡してください。

Javaアプリケーションの問題のトラブルシューティング

Javaアプリケーション固有の問題を診断し解決するには、次のステップを使用します。

インストールしたJREはサポートされているブランドおよびバージョンですか

サポートされるJREのリストについては、ご使用のバージョンのLogon Managerのリリース・ノートを参照してください。インストールしたJREがサポートされていない場合は、Logon Managerを現在のJREがサポートされるリリースにアップグレードするか、現在のJREをご使用のリリースのLogon Managerでサポートされるバージョンに置き換える必要があります。

Oracle JInitiator、あるいは開発元がOracleまたはIBM以外の別のJREを使用していますか

Logon Managerを、Oracle JInitiatorまたはOracle/IBM以外のJREとともにデプロイした場合の問題は報告されていませんが、このようなJREを使用した場合のLogon Managerの適切な動作についてはサポートおよび保証されません。

JHOはロードされていますか

場合によっては、Javaアプリケーション使用時に構成上の問題によってJHOがロードされない場合があります。JHOがインストールされ実行されていることを確認するには、Microsoft Spy++ (Microsoft Visual Studioに付属)、またはSysInternals Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)などのプロセス・ビューア・ツールを使用して、JVM実行可能ファイルがssojho.dll子スレッドを生成したことを確認してください。

次に示す例は、Process ExplorerでのSun JVM実行可能ファイルjavaw.exeのプロパティ・ボックスを示しており、ssojho.dll子スレッドが実行中であることがわかります:

JHOがターゲットJREに対してロードされていない場合は、ホーム・ディレクトリにあるユーザーの.java.policyファイルで、JHOが必要とする権限が付与されているかどうかを確認します(次の項で説明します)。

JHOで必要な権限の検証および修復

JHOは、ターゲットJREのコンテキストで適切に動作できるように、ユーザーの.java.policyファイルを通じて付与される特定の権限のセットを必要とします。
これらの権限が有効でない場合、Logon ManagerはJavaアプリケーションを検出することも、それに応答することもできません。

必要な権限が付与されているかどうかの確認

Logon Managerが起動するたびに、権限はテンプレート.java.policyファイル(%INSTALLDIR%\v-GO SSO\Helper\Java)から、ユーザーの.java.policyファイル(ユーザーのホーム・ディレクトリ)にコピーされます。これらの権限は、Javaアプリケーションが起動されるたびにJHOに自動的に付与されます。

必要な権限がJHOに付与されていない疑いがある場合は、Logon Managerの起動後に、JHOを参照している例外のうち欠落する権限に関する例外がないか、JREのログを確認してください。そのような例外が存在する場合、必要な権限は付与されていません。次のいずれかの原因が考えられます:

・ユーザーの.java.policyファイルに、JHOで必要な権限が含まれていない。

・ターゲットJREのセキュリティ設定が(通常はJREのjava.securityファイルに保存される)、ユーザーの.java.policyファイルを参照しない。

欠落したJHO権限の修復

必要なJHO権限がユーザーの.java.policyファイルに含まれていない場合、そのファイルのACLによってLogon Managerがそのファイルに権限を書き込めない可能性があるため、ファイルのACLを調べて書込み権限が拒否されていないかを確認してください。

ACLが適切で、必要な権限がユーザーの.java.policyファイルに存在しない場合は、次のいずれかを実行します:

・ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれている場合は、このファイルを編集して欠落しているJHO権限を手動で追加します。

・ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれていない場合は、このファイルを削除してからLogon Managerを再起動すると、ファイルが再作成されて必要な権限が自動的に挿入されます。

注意: JREがそのベンダーによって更新され、将来のリリースで1つ以上の新しい権限が導入される場合がありますが、JHOでそれが必要になったとしても、Logon Managerのリリース時点ではそれが考慮されていない可能性があります。その場合は、Logon ManagerおよびターゲットJavaアプリケーションの起動後に、欠落する権限に関する例外がないかJREのエラー・ログを確認し、その権限をLogon Managerの.java.policyテンプレート・ファイルに追加して、次回Logon Managerを起動したときにユーザーの.java.policyファイルを通じてその権限が付与されるようにします。

Java Helper Object (JHO)の動作の構成

Logon Managerは、JHOの次の側面の動作を制御できる、グローバルなエージェント設定を提供します:

・特定のJREバージョンを除外する

・特定のJREベンダーを除外する

・ Javaアプレットのロードを考慮したレスポンス遅延を定義する

・ JREの初期化を考慮したレスポンス遅延を定義する

・レスポンス再試行間の遅延を定義する

・レスポンス再試行の最大数を定義する

・ JHOが認識または無視する特定の階層、ウィンドウ、コンポーネントおよび注入タイプのイベントを定義する

これらの設定は、Logon Manager Administrative Consoleのツリーの次の場所にあります:

「Global Agent Settings」a「Live」a「User Experience」a「Application Response」a「Java Applications」

これらの設定および構成方法の詳細は、コンソール・ヘルプを参照してください。さらに精度の高い制御を行う場合、Logon Managerではレジストリ設定が提供されています(次の項で説明します)。これらの設定は熟練した管理者のみが行うことをお薦めします。

手動による特定のJREに対するJHOの制限

前述のコンソール設定以外に、Logon Managerでは非常に精度の高い包含および除外ルールを作成できるレジストリ設定が提供されています(包含および除外ルールは、Logon Managerがターゲット・アプリケーションに対してJHOをロードするかどうかを決定する際に使用します)。Java Virtual Machine (JVM)実行可能ファイル、JARファイル、およびJHOで考慮されるコマンドライン・パラメータを、正規表現を使用して指定できます。

これらの設定を構成する際には、次の点に注意してください:

・設定の対象となる値を省略すると、指定されているデフォルトが使用されます。値を設定すると、一致しない値はすべて無視されます。

・ JHOは最初に包含ルールを処理し、その後除外ルールを処理します。

・ N接尾辞は、特定のアプリケーションに属する設定をバンドルする一意の数値識別子です。JHOは、このバンドルを昇順に順次処理します。
N接尾辞は、1から始まる正の整数です。

・トレース・ロギング・ユーティリティを使用して、アプリケーションのホストJVM実行可能ファイルおよび起動コマンドを確認できます。Javaトレース・ログの先頭部分は、アプリケーションのホストJVMおよび起動コマンドを示します。

設定は、Windowsレジストリの次のパスにあります。

HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager\JHO

設定は、次のカテゴリに分けられます:

・ JHO包含ルール

・ JHO除外ルール

・許可されるJava Runtime Environment (JRE)バージョン

JHO包含ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびターゲット・アプリケーションに対してJHOをロードするためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定

説明

JhoIncludeHostNameN

アプリケーションのホストJVM実行可能ファイルを指定します。

たとえば、アプリケーションがjava.exeまたはjavaw.exeという名前のJVM実行可能ファイルによってホストされている場合にJHOをロードするには、値を次のように設定します。

JhoIncludeHostName1=.*javaw?\.exe

値を指定しない場合のデフォルト:

すべての実行可能ファイルが受け入れられます(つまり、JHOはどのような実行可能ファイルに対してもロードされます)。

JhoIncludeHostCommandLineN

アプリケーションの起動に使用されるコマンドを指定します。
通常、コマンド文字列には、JVM実行可能ファイルのフルパスと名前、JARファイル、および必要なすべてのコマンドライン・パラメータが含まれます。

たとえば、アプリケーションのJARファイルがLogin.jarという名前の場合のみJHOをロードする場合(コマンドの残り部分は異なっていても許容される)、値を次のように設定します。

JhoIncludeHostCommandLine1=.*Login\.jar.*

値を指定しない場合のデフォルト:
すべてのコマンド文字列が受け入れられます(つまり、どのようなコマンドでもJHOはロードされます)。

JHO除外ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびJHOがターゲット・アプリケーションを無視するためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定

説明

JhoExcludeHostNameN

アプリケーションのホストJVM実行可能ファイルを指定します。

たとえば、ホストJVM実行可能ファイルの名前が"java.exe"または"javaw.exe"の場合にJHOがアプリケーションを無視するようにするには、値を次のように設定します。

JhoExcludeHostName1=.*javaw?\.exe

値を指定しない場合のデフォルト:
空白(つまり、JHOはアプリケーションを無視しません)

JhoExcludeHostCommandLineN

たとえば、JARファイルの名前が"Login.jar"の場合にJHOがアプリケーションを無視するようにするには(ただし、コマンドの残りの部分は非間接的)、値を次のように設定します。

JhoExcludeHostCommandLine1=.*Login\.jar.*

値を指定しない場合のデフォルト:
空白(つまり、JHOはアプリケーションを無視しません)

許可されるJava Runtime Environment (JRE)バージョン

これらの設定では、JHOがロードされる目的のJRE/JDKバージョンを指定可能であり、この指定範囲外のバージョンはすべて無視され、JHOはロードされません。

どちらの設定の値もx.y.zという形式である必要があります:

・ xは、メジャー・バージョンです。

・ yは、マイナー・バージョンです。

・ zは、リリース・タイプ(機能、メンテナンスまたは更新)、およびインストールされているJREのビルドID (1.6.0_07など)を示します。

設定

説明

JhoMinimumJavaVersion

許可されるJRE/JDKバージョンの下限を指定します。

デフォルト値:

1.2 (JHOでサポートされる最も古いJREバージョン)

JhoMaximumJavaVersion

許可されるJRE/JDKバージョンの上限を指定します。

デフォルト値:

空白(つまり、JREバージョンの上限はありません)

Java Helper Object (JHO)のイベント・レスポンス動作の手動によるカスタマイズ

コンソールで提供される設定以外に、Logon Managerでは、さらに高レベルの精度でJHOのイベント・レスポンス動作を制御するためのレジストリ設定が提供されています。これらの設定を使用すると、Javaアプリケーションが検出された場合に特定のイベントに対するJHOのレスポンスを変更することによって、Javaアプリケーションに応答する際のLogon Managerのパフォーマンスのトラブルシューティングおよび最適化を実行できます。

この設定は、Windowsレジストリの次のキーにあります。

HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager

イベント・レスポンス構成の設定

設定	説明
JhoHierarchyEventProcessing	どのJava階層イベントを認識するかを決定します。フラグを次のように設定します: HIERARCHY_EVENT_CHANGED = 0x1 前述の値は、すべての階層イベントを認識するようにJHOに指示します。
JhoEventWaitTimeout	JHOコントロールのイベント処理タイムアウトを決定します(ミリ秒単位)。デフォルト値の0は、JHOに無期限に待機するように指示します。
JhoWindowEventProcessing	どのJavaウィンドウ・イベントを認識するかを決定します。このフラグは、次の値の組合せです: ・ WINDOW_EVENT_OPENED = 0x1 ・ WINDOW_EVENT_CLOSED = 0x2 ・ WINDOW_EVENT_ACTIVATED = 0x4 ・ WINDOW_EVENT_DEACTIVATED = 0x8 ・ WINDOW_EVENT_CLOSING = 0x10 ・ WINDOW_EVENT_ICONIFIED = 0x20 ・ WINDOW_EVENT_DEICONIFIED = 0x40 デフォルトでは、すべてのウィンドウ・イベントが認識されます。

設定

説明

JhoComponentEventProcessing

どのJavaコンポーネント・イベントを認識するかを決定します。このフラグは、次の値の組合せです:

・ COMPONENT_EVENT_SHOWN = 0x1

・ COMPONENT_EVENT_HIDDEN = 0x2

・ COMPONENT_EVENT_ADDED = 0x4

・ COMPONENT_EVENT_REMOVED = 0x8

デフォルトでは、すべてのコンポーネント・イベントが認識されます。

JhoInjectType

データをコントロールに送信する際にJHOが使用する注入タイプを確認します。このフラグは、次の値のいずれかをとります:

・ INJECT_TYPE_DEFAULT = 0

・ INJECT_TYPE_METHOD = 1

・ INJECT_TYPE_ACCESSIBLE = 2

・ INJECT_TYPE_NONACCESSIBLE = 3

・ INJECT_TYPE_ROBOT = 4

デフォルトでは、このフラグにINJECT_TYPE_DEFAULTが設定され、その場合、JHOは次の各方法を、ここに示す順に、注入が成功するまで試みます:

・ INJECT_TYPE_METHOD (コントロールに適切な設定方法が検出された場合)

・ INJECT_TYPE_ACCESSIBLE (コントロールでアクセシビリティがサポートされている場合)

・ INJECT_TYPE_NONACCESSIBLE

・ INJECT_TYPE_ROBOT

注意: コンボ・ボックスおよびリスト・ボックスの場合、JHOは常にINJECT_TYPE_METHODを使用します。

推奨されるJHOイベント・レスポンス構成のデフォルト

Logon Managerの新規インストールでは、次のデフォルト設定をお薦めします:

・ JhoWindowEventProcessing=0x3

・ JhoComponentEventProcessing=0xB

・ JhoHierarchyEventProcessing=0x0

これらの値は、次のイベントを認識するようにJHOに指示します:

・ WINDOW_EVENT_OPENED (0x1)

・ WINDOW_EVENT_CLOSED (0x2)

・ COMPONENT_EVENT_SHOWN (0x1)

・ COMPONENT_EVENT_HIDDEN (0x2)

・ COMPONENT_EVENT_REMOVED (0x8)

第2部: Webアプリケーション

この部では、特定のサインオン・シナリオを解決するためにアプリケーション・テンプレートを構成する方法と理由の理解に必要な概念について説明し、この章の後で記述しているように、Windowsアプリケーション・フォームを構成およびテストする手順の推奨されるベスト・プラクティスについて、およびエージェントのWebフォームに対する検出や応答が不安定になる可能性がある最も一般的な問題の診断と解決手順についても説明します。この部の内容は次のとおりです。

・ Webフォームの検出のトラブルシューティング

・コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

・ SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

・検出マッチングのトラブルシューティング

・ログオン・ループのトラブルシューティング

・ Javaアプリケーションの問題のトラブルシューティング

ヒント: この章の手順で問題を解決できない場合は、Logon Managerのアクティビティの追跡とロギングを行い、記録された情報を分析のためにOracleサポートに送信することにより、さらにトラブルシューティングを行うことができます。このために、Oracleではトレース・コントローラ・ユーティリティ(Oracleサポートから入手可能)を提供しています。ユーティリティの使用方法の詳細は、Enterprise Single Sign-On Suite Plus管理者ガイドのトレース・コントローラ・ユーティリティの使用に関する説明を参照してください。

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

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

完全にロードされたページごとに、Logon Managerは次の手順を実行します:

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

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

b. 検出したURLと一致する最初のテンプレートをロードします。

c. ページのDocument Object Model (DOM)を調べ、フォーム定義で構成されている各フィールドおよびコントロールを識別します。

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

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

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

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

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

Webフォームの検出の理解

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

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

・ 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検出の理解

Logon ManagerがWebフォームの検出中に考慮する最初の基準は、Webアドレス、つまりターゲット・ページのURLです。これは通常、ページのロードが終了したときにブラウザのアドレス・バーに表示されるアドレスですが、特定のシナリオでは、フォーム定義に指定する必要がある実際のURLは、ログオン・フィールドおよびコントロールが実際に含まれているコンテナまたはフォーム要素など(これらの用語については次の項で説明します)、ページの要素のURLである場合があります。

ページURLは、次のような構造です:

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

プロトコル識別子 ???????????????????????????????

Webアプリケーションをデプロイした方法に応じて、URLは静的になることも部分的に動的になることもあります。たとえば、単純なWebアプリケーションは単一のWebサーバーにデプロイされ、前述の例のように静的なホスト名を持ち単一のHTMLページとして存在します。このような場合、この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など、1つ以上の動的パラメータまたは変数がページURLに
採用されます。

次に例を示します。

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

変数
区切り一部のアプリケーションでは、変数区切り記号(通常はアンパサンド(&))で区切ってURL変数を並べます。

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

ほとんどのエンタープライズWebアプリケーションのシナリオでは、動的ホスト名と動的パラメータの組合せが
使用されており、フォーム定義を正常に構成するにはそれらの両方を考慮する必要があります。Logon Managerでは、正規表現を使用した動的URLに対するマッチングだけでなく、すべてのWebアプリケーションに対してLogon Managerが使用する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一致精度の設定が高すぎると、一意のホスト名を持つ配布済インフラストラクチャを介して提供された1つのアプリケーションが、可変ホストURLが原因で別々のアプリケーションとして誤って認識される可能性があります。

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

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

Logon Managerでは、Administrative Consoleを介してURL一致精度レベルをグローバルに設定できます。
オプションは、「Global Agent Settings」a「End-User Experience」a「Response」a「Web Apps」の下にあります。エージェントの構成およびエンドユーザー・マシンへの変更の公開に関する詳細は、ベスト・プラクティス・ガイドのLogon Manager Agentの構成に関する説明を参照してください。

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

特定の状況では、ページの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で識別します。ほとんどの場合、この値を変更する必要はありません。

<!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">

名前
ログオンの
<form>要素(序数: 0) ???????
??????? <p style="padding-bottom: 20px; text-align: center;">
???????? <b>Welcome - log on below.</b></p>

???????

??????? <p>User name: <input type="text" name="username" id="user"
?????????? size="18" style="border: 2pt solid blue;"></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>

レンダリングされるページの要素の親子関係に対応する、階層的なネストされたコードの構造に
注意してください。

注意: 前述の例の開始および終了タグの各ペアが要素であり、ページ内の機能エンティティ(たとえば、フレーム、フォーム、フィールドなど)を構成するコードの部分です。

テンプレート内でフォーム定義を手動で構成すると、Logon Managerへのフレーム、フォームおよびフィールド要素を次によって識別できます:

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

・序数、つまり、ページのDOMに表示される順序に応じて、サポート対象の各タイプの要素にLogon Managerによって割り当てられた索引番号。

HTML要素の理解

前の項で説明したように、HTMLの要素は、ページ内の機能エンティティ(たとえば、フレーム、フォーム、フィールドなど)を構成するコードの部分です。要素は、
単一行のコード、つまり<input>などの単一タグの場合もあれば、<div>…</div>のように開始および終了タグとその2つのタグ間にあるすべてで構成されている場合があります。

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

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

要素の宣言(<input)の後のコードに注意してください ? これらは要素の属性です。各属性には、次の形式で名前および値があります:

attribute_name="attribute_value"

二重引用符(インチ記号)は、属性値が認識されるために必要です。

フレーム要素の理解

フレームは、フレームセットを定義して、各フレームのサイズおよび表示するHTML文書を指定することによって、Webページを分割できるレガシー・コンテナです。今日の大多数のWebサイトでは、この技術が採用されなくなり、分割を達成するためのCSS形式と並行して<div>や<table>などの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でサポートされる入力要素の理解

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

Logon Managerフィールド・タイプ

Logon Managerフィールド・タイプによって受け入れられる入力要素のタイプ

・ User name/ID

・ Password

・ Third Field

・ Fourth Field

・ テキスト ? type="text"の<input>タグによって識別されるテキスト・フィールド。このフィールドに入力されるテキストはマスキングされません。

・ パスワード ? type="password"の<input>タグによって識別されるテキスト・フィールド。このフィールドに入力されるテキストはマスキングされます。

・ 単一選択 ? 値として単一のリスト項目の選択を許可する、<select>タグによって識別されるリスト・フィールド。

・ 複数選択 ? 値として1つ以上のリスト項目の選択を
許可する、<select multiple … >タグによって
識別されるリスト・フィールド。

・ Submit

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

・ ボタン? - type="button"の<input>タグによって識別されるボタン・コントロール。機能的にはsubmitタイプの<input>要素と同一ですが、より柔軟にスタイル設定できます。

・ イメージ ?type="image"の<input>タグによって識別されるハイパーリンクされたイメージであり、クリックすると参照先リンクを実行します。

・ IMG ?<img src=タグによって識別されるイメージであり、アンカー(<A HREF=)タグまたは、クリック時に送信URLを実行するJavaScriptのonClickアクション内にラップされています。

・ アンカー ? 最も一般的なテキスト・ハイパーリンクのマニフェストです(デフォルトで、青の下線付きテキストとして
ページに表示されます)。<A HREF="…">タグによって識別されます。

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

Webアプリケーションをプロビジョニングする際、オラクル社では、ページのDOM(およびオプションでソース・コードも)を簡単にナビゲートおよび検索できる方法で表示して、ページの構造をより簡単にすばやく理解できるようにする、ページ検査ツールを取得することを強くお薦めしています。

Mozilla FirefoxのDOM Inspector

このようなツールの例として、Mozilla FirefoxのアドオンDOM Inspectorがあります。例のページのDOMは、DOM Inspectorに次のように表示されます:

ページの階層構造は左側のペインにナビゲート可能なツリーとして表示され、要素をクリックするとブラウザ・ウィンドウでハイライトされ、右側のペインにその要素の属性および値が表示されて、ページのソース・コードを調べなくてもターゲット・ページ要素を容易に識別および理解できます。このツールは、大きくて複雑なページに特に便利です。

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

Mozilla FirefoxのFirebug

DOM Inspectorと同様のさらに拡張されて柔軟なツールは、Mozilla FirefoxのアドオンFirebugです。FirebugにはDOM inspectorのすべての機能が備わっており、マウスを置いた各コード要素の視覚的なハイライト表示を含め、DOMツリー内の完全なソース・コード表示が追加されています。ユーザーは、コードを変更してブラウザ・ウィンドウでその変更を確認することもできます。Firebugは主にWeb開発者用ですが、複雑なWebページを分析すると、Firebug自体が非常に有益であることがわかります。

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

検出マッチングの理解

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

たとえば、Webアプリケーションがメンテナンスのために停止している場合、ログオンしようとすると、ログオン失敗の理由を示すエラー・メッセージとともにログオン・フォームが再表示されます。そのようなシナリオで
Logon Managerがログオンの試行を繰り返さないように、テンプレートに2つのログオン・フォームを定義し、定義の1つでエラー・メッセージ・テキストを照合するためのテキスト・マッチングを使用して、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:? テキスト

・ 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」オプションにより、Logon Managerは「Value」フィールドに入力された文字列全体を照合しますが、これはデフォルトで有効になっています。ページ上の部分一致(<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 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一致ルール。

例に基づくと、前述のルールは次のように構成されます:

ルール1

・ Tag: html

・ Criteria:? テキスト

・ Value:? Logon error

・ Match whole value: Yes

・ Use regular expression: No

・ Operation: NOT

ルール2

・ Tag: html

・ Criteria:? テキスト

・ 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は除く ? ANDルールとしてルール1を構成し、ORルールとしてルール2を構成し、NOTルールとしてルール3を構成し、連鎖の最初に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フォームおよびその入力フィールドの識別に成功すると、適切なヘルパー・オブジェクトを使用してターゲット・フィールドに移入し、フォーム内のsubmitコントロールを作動させます。Webページのコード化方法に応じて、次のレスポンス方式のいずれかを使用します。

コントロールID

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

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

SendKeys

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

コントロールIDとSendKeys

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

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

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

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

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

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

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

・フィールドがまだ表示されない場合、「Oracleサポートへの連絡」で詳細を参照してください。

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

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

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

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

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

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

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

submitコントロールがイメージであり、その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」オプションを有効にし、それに応じてフィールドを割り当てます。

アプリケーションでパスワード変更の成功または失敗のメッセージ(あるいはその両方)を表示しますか

アプリケーションによっては、パスワード変更の成功または失敗を示すメッセージを表示します。
その場合は、アプリケーション・テンプレートでパスワード変更の成功フォーム、またはパスワード変更の失敗フォームを定義します。

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

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

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

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

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

フォームの構成

基本構成

フォームの基本構成を完了するには、次の手順を実行します:

注意: ターゲット・アプリケーションのタイトル・バーにある「Logon Manager」ボタン(有効な場合)をクリックし、
表示されたコンテキスト・メニューから「Create Template」を選択すると、構成プロセスをすぐに開始できます

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します:

・新しいテンプレートを作成し、その最初のフォームを定義します:

i. 右側のペインで「Add」をクリックします。

・既存のテンプレートにフォーム定義を追加する場合は、次の手順を実行します:

i. 「Applications」ノードを展開し、目的のテンプレートを選択します。
テンプレートが右側のペインに表示されます。

ii. ペインの下部で「Add」をクリックします。

3. 表示された「Web Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します:

a. 「Form Type」画面で、目的のフォーム・タイプを選択し、「Next」をクリックします。

b. 次の画面で、ターゲット・ページ、フォームまたは要素のURLを入力し、プレビュー・ペインのロードが完了するのを待機します。

注意: 同じ名前を共有するフィールドが2つ以上表示される場合、構成の完了時にエージェントがフォームに誤って応答する可能性があります。そのような場合は名前オプションのかわりに「Use ordinals」を有効にし、序数(連続した索引番号)を介してエージェントへの入力フィールドを一意に識別します。
詳細は、「Webフォームの検出の理解」を参照してください。

c. 画面の下にあるフィールド・リストで、次のようにリスト内のオブジェクトの中からターゲット・フィールドおよびコントロールを選択して構成します:

注意: 1つ以上のフィールドまたはコントロールがリストにない場合、手動で構成する必要がありことがあります。そのような場合は、ウィザードの残りをそのまま完了し、影響のある入力フィールドごとに「フィールドまたはコントロールの手動構成」の手順に従います。

注意: デフォルトでは、すべてのフィールドおよびコントロールはコントロールIDレスポンス方式を使用します。1つ以上のフィールドにSendKeysレスポンス方式を使用する場合、この手順の説明に従ってそれらを定義してから、「SendKeys方式を使用したフィールドまたはコントロールの構成」の手順に従います。

ii. 目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。選択したフィールドは、ページ・プレビューでハイライト表示されます。

注意:???? 送信ボタン(通常は「OK」、「Logon」などのラベルが付いているボタン)がリストに表示されない場合でも、Logon Managerは資格証明の注入後に、アプリケーションに送信アクションを送信します。このアクションは、ユーザーが手動で[Enter]キーを押すのと同等です。

iii. submitコントロールが欠落している場合、アンカー
(つまり、<A HREF=)またはイメージ(つまり、<IMG SRC=)として実行されていることがあります。その場合は、「Show anchor tags」または「Show non-input fields」(あるいはその両方)のオプションをそれぞれ有効にして、そのようなコントロールを表示します。

iv. 表示できる入力フィールドをすべて構成したら、「OK」をクリックします。

d. コンソールに、構成したばかりのWebフォーム定義のプロパティ・ダイアログが表示されます。次のいずれかを実行します。

・「Web Form」ウィザードを使用してターゲット入力フィールドのすべてを正常に完了し、追加の構成が必要ない場合、「OK」をクリックしてダイアログを終了し、「リポジトリへのテンプレートの公開」の説明に従って変更をリポジトリに公開します(該当する場合)。

・「Web Form」ウィザードを使用して1つ以上のターゲット・フィールドを構成できない場合、「フィールドまたはコントロールの手動構成」の手順3に進みます。

・既存のURL検出基準の変更または追加のURL検出基準の指定が必要な場合は、
「URL検出基準の構成」に進みます。

警告: フィッシング攻撃の発生を防ぐために、デフォルトのワイルドカード正規表現の接頭辞である.*?をURL定義から削除することを強くお薦めします。

・ 「Matching」タブを使用して追加のフィールド検出基準を構成する必要がある場合、「追加のフィールド検出基準の構成」に進みます。

注意: ページのコンテンツが動的である場合、つまり、ページのロードが完了した後に変化する場合は、「Options」タブの「Dynamic Page」オプションを選択して、アクティブなページ・ポーリングを有効にします。このようにすると、エージェントがページの変更を監視できます。

フィールドまたはコントロールの手動構成

「Web Form」ウィザードを使用して入力フィールドを構成できなかった場合、またはフィールドの既存の構成を変更する場合、次の手順に従います。

コントロールID方式を使用したフィールドまたはコントロールの構成

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されるフォーム・プロパティ・ダイアログで、「Fields」タブを選択します

4. 「Fields」タブで、次の手順を実行します:

a. 新しいフィールドを構成する場合は「Add」をクリックし、既存のフィールドの構成を変更する場合はリスト内のフィールドを選択して「Edit」をクリックします。

b. 表示された「Web Field」ダイアログで、次の手順を実行します:

注意: ここで指定する必要がある値の詳細は、「フィールド検出の理解」を
参照してください。

i. 「Function」ドロップダウン・リストで、フィールドの目的を選択します。使用可能な
値は、「Username/ID」、「Password」、「Third Field」および「Fourth Field」です。

ii. 「Frame」フィールドに、フィールドの親フレーム要素の名前または序数を入力します。

iii. 「Form」フィールドに、フィールドの親フォーム要素の名前または序数を入力します。

iv. 「Field Type」ドロップダウン・リストで、ターゲット入力フィールドのタイプを選択します。

v. 「Field Identification」フィールドで、 「…」(省略記号)ボタンをクリックし、次の手順を実行します:

a) Logon Managerがフィールドを識別する方式を選択します。
使用可能な方式は、フィールド名、序数およびマッチングです。

b) 選択した識別方式に適切な値を入力します。

注意: マッチングの構成の詳細は、「検出マッチングの理解」を参照してください。

c) 「OK」をクリックして変更を保存し、ダイアログを終了します。

vi. 「OK」をクリックして、フィールド定義をテンプレートに保存します。

e. 構成する追加フィールドごとに手順iからviを繰り返します。

4. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

5. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

SendKeys方式を使用したフィールドまたはコントロールの構成

Logon Managerでは、フォームのレスポンス方式がSendKeysに変更された後に、SendKeysアクションを直接追加することはできません。SendKeysレスポンス方式に切り替えられたフォーム定義に新しいアクションを追加するには、まずフォームをコントロールID方式に戻して、「コントロールID方式を使用したフィールドまたはコントロールの構成」の説明に従って目的のアクションを追加してから、フォーム定義をSendKeys方式に戻す必要があります。この手順では、既存のコントロールIDアクションをSendKeysアクションに変換する方法、および変換されたSendKeysアクションを構成する方法が説明されています。

注意: SendKeysフォーム定義をコントロールIDに戻すと、「Inject directly into control」オプションが無効化されていたすべてのSendKeysアクションは、削除されます。
構成手順を開始する前に、フォーム構成を十分に計画しておくことを強くお薦めします。

SendKeysアクションを構成するには、次の手順を実行します:

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されたフォーム・プロパティ・ダイアログで、「Fields」タブを選択し、次の手順を実行します:

a. (オプション) SendKeys方式への最初の切替えの場合、「Transfer Method」セレクタの「SendKeys」を選択します。

注意: SendKeys方式を選択すると、「Fields」リスト内のすべてのアクションが「SendKeys」アクションに変換され、(アクションのプロパティ・ダイアログにある)「Inject directly into control」オプションは有効になります。つまり、それらのアクションは、SendKeys方式を使用して実行する各アクションの「Inject directly into control」オプションを無効化するまでは、
プログラム的に保持されます。

可能な場合は必ずプログラム的な注入を使用し、
フィールドまたはコントロールとのプログラム的な対話が不可能な場合のみ
SendKeysを使用することをお薦めします。

注意: 「SendKeys using journal hook」オプションを使用するタイミングの詳細は、
「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

「Fields」タブの表示が変更されて、SendKeysレスポンス方式が反映されます:

b. SendKeysアクションが実行される順序を変更するには、位置を変更するアクションを選択し、上および下矢印のボタンを使用して移動します。

c. SendKeysアクションを構成するには、リストから選択して「Edit」をクリックし、表示された「SendKeys」ダイアログを使用してアクションを構成します。ダイアログに表示される各オプションの説明は、コンソール・ヘルプを参照してください。

d. アクションをすべて構成したら、「OK」をクリックして変更を保存し、「SendKeys」ダイアログを終了します。

6. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

7. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

URL検出基準の構成

「Web Form」ウィザードによって構成されたデフォルトのURL検出基準を変更する必要がある場合、または追加の基準を指定する必要がある場合、次の手順を実行します:

警告: フィッシング攻撃の発生を防ぐために、デフォルトのワイルドカード正規表現の
接頭辞である.*?をURL定義から削除することを強くお薦めします。

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されたフォーム・プロパティ・ダイアログで、「Identification」タブを選択します。

4. 「Identification」タブで、次の手順を実行します:

a. 新しいURL定義を構成する場合は「Add」をクリックし、URL定義の構成を変更する場合はリスト内の定義を選択して「Edit」をクリックします。

b. 表示されたURL定義プロパティ・ダイアログで、次の手順を実行します:

注意: ここで指定する必要がある値の詳細は、「URL検出の理解」を
参照してください。

i. 目的の一致タイプを選択します。

ii. 目的の一致基準を入力します。

iii. 「OK」をクリックしてURL定義を格納します。

c. 構成する追加のURL定義がある場合は、手順iからiiiを繰り返します。

d. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

5. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

追加のフィールド検出基準の構成

追加のフィールド検出基準を標準マッチングまたはオフセット・マッチング・モードで構成する必要がある場合、次の手順を実行します:

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。フォーム・プロパティ・ダイアログが
表示されます。

3. ダイアログで、「Matching」タブを選択します。

4. 目的のマッチング・タイプに応じて、「Detection Match」または「Form Offset Match」セクションのいずれかで次の手順を完了します(詳細は、「検出マッチング対オフセット・マッチング」を参照してください)。

注意: オフセット・マッチングを実行する場合、「Offset Start」値を指定する必要があります。

a. 新しいマッチング・ルールを構成する場合は「Add」をクリックし、既存のルールを変更する場合はリスト内のルールを選択して「Edit」をクリックします。

b. 表示された「Match Criteria」ダイアログで、次の手順を実行します:

注意: ここで指定する必要がある値の詳細は、「検出マッチングの理解」を参照してください。

i. 「Tag」フィールドで、親要素の名前を指定します。

ii. (オプション)ページ内に親要素のインスタンスが複数ある場合は、序数を決定し、「Match tag instance」ボックスを選択して値フィールドに序数を入力します。

iii. 「Criteria」フィールドで、目的のマッチング・モードを選択します。

iv. 「Value」フィールドにターゲット基準値を入力します。

v. ほとんどのシナリオで、「Match whole value」オプションを有効なままにします。これにより、Logon Managerは基準値に対して厳密に照合します。このオプションを無効化すると、Logon Managerは基準値に対する部分一致もポジティブ・マッチとみなします。

vi. 基準値の一部として正規表現を使用する場合、「Use regular expression」オプションを有効にします。

vii. (オプション)マッチング・ルール連鎖を作成して複雑なマッチング・ルールを作成する場合、「Operation」ドロップダウン・リストから目的のブール演算子を選択し、前にあるルールにこのルールを連鎖させる方法を示します。

viii. 「OK」をクリックしてマッチング・ルールを保存します。

c. 追加のマッチング・ルールごとに手順iからviiiを繰り返します。

d. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

5. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

フォームの構成のテスト

フォームを作成して構成した後は、エンドユーザーのワークステーションにデプロイする前に構成をテストすることを強くお薦めします。これを行うには、Logon Manager Administrative ConsoleにあるTemplate Test Manager機能を使用します。

注意: Template Test Managerにより、最も一般的な構成の問題に対する対話型トラブルシューティングおよび是正手順が提供されますが、可能性があるすべての問題のシナリオに対応するようには設計されていません。完全なトラブルシューティングを行うには、次のように、このガイドとともにTemplate Test Managerの手順に従います。

公開の前に、フォーム構成をテストする次の一連の手順を完了します:

1. 左側のツリーの「Applications」ノードを展開し、ターゲット・テンプレートにナビゲートします。

2. ターゲット・テンプレートを右クリックし、コンテキスト・メニューから「Test」を選択します。

3. 表示された「Logon Manager Template Test Manager」ウィンドウで、次の手順を実行します:

a. 「Forms」ペインで、ターゲット・フォームを選択します。

b. 「Interactions」ペインに表示される手順に従います。

c. 次のいずれかを実行します:

・エージェントが期待どおりにアプリケーションに応答し、テストが正常に完了した場合は、「Finish」をクリックします。

・エージェントが期待どおりにアプリケーションに応答せず、Template Test Managerによって提供された手順で問題が解決されない場合は、「Close」をクリックし、このガイドの後にあるトラブルシューティング・フローチャートに従って問題を確認して修正します。終了したら、手順1から3を繰り返して修正後の構成をテストします。

ログオン・フォームの構成のテスト

エージェントはフォームを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・フォームに自動的に応答します。エージェントがフォームへの応答に失敗した場合は、「Webフォームの検出のトラブルシューティング」を参照してください。

エージェントは資格証明を注入しますか

資格証明がユーザーのストア内のターゲット・アプリケーションに対して格納されている場合、エージェントはアプリケーションの検出に成功すると、資格証明を適切なフィールドに注入します。「Auto-Submit」機能が明示的に無効化されていないかぎり、エージェントは自動的に資格証明の送信も行います。資格証明の注入が失敗する場合、「資格証明の注入および送信のトラブルシューティング」を参照してください。

ログアウトでログオン・ループが発生しますか

パスワード変更フォームの構成のテスト

エージェントはフォームを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・フォームに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「Webフォームの検出のトラブルシューティング」を参照してください。

エージェントは資格証明を注入および送信しますか

エージェントはパスワードの変更を検出すると、「Auto Submit」機能が明示的に無効化されていないかぎり、資格証明を適切なフィールドに注入し、アプリケーションに送信します。
資格証明の注入が不安定になるか、まったく発生しない場合、「資格証明の注入および送信のトラブルシューティング」を参照してください。

新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

エージェントはパスワード変更フォームにログオンと同様に応答しますか

・テンプレートの構成ミス(誤った要素またはフォーム・タイプ、入力フィールド定義など)。

・パスワード変更フォームに動的URLが含まれるかどうかを確認し、含まれる場合はそれに応じてテンプレートを更新します。

・検出マッチングを使用している場合は、正しいマッチング・タイプを使用しているかどうかを確認し、マッチング文字列にエラーがないか検証します。

リポジトリへのテンプレートの公開

注意: この手順を実行する前に、リポジトリの構造および構成を熟知していることを確認します。

目的のテンプレートおよびその他の構成オブジェクトを選択し、リポジトリに公開するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを起動します。

3. 「Available configuration objects」リストで、目的のオブジェクトにナビゲートして選択します。

5. 次のいずれかを実行して、選択したオブジェクトの公開先のターゲット・コンテナを選択します:

o 以前、目的のコンテナに公開したことがある場合は、「Target Repository」ドロップダウン・リストからそれを選択します。

i. 「Browse」をクリックして、ディレクトリ・ツリーを参照します。

注意: ディレクトリにまだ接続していない場合は、必要な接続情報を提供するようにコンソールから求められます。

ii. 表示された「Browse for Repository」ダイアログで、ターゲット・コンテナにナビゲートして選択します。

7. (オプション)初回使用オブジェクト(FTUList)を作成する場合は、対応するチェック・ボックスを選択します。

注意: このオプションは、手順6でフラット形式での構成オブジェクトの格納を選択した場合のみ、アクティブになります。

8. 「Publish」をクリックします。コンソールは、選択したオブジェクトをターゲット・リポジトリに公開します。

公開プロセスの詳細は、Logon Manager Administrative Consoleヘルプを参照してください。

Webフォームの検出のトラブルシューティング

不安定なフォーム検出を診断するには、次の手順を使用します。

「Logon Using Logon Manager」トレイ・アイコン・オプションで検出に成功しますか

エージェントはフォームを検出しないが、エージェントのシステム・トレイ・アイコンからの「Logon Using Logon Manager」オプションの呼出しでは検出に成功する場合、次の手順を実行します:

・フォーム定義の「Options」タブにある「Auto-recognize」オプションが有効になっていることを確認します。

・誤ったまたは不明確なURLおよび入力フィールド定義、マッチング・ルールなど、テンプレートにエラーがないか確認します。

?ページのロードは完了しましたか

ページのロードが完了したことがブラウザによって示されるまでは、エージェントは検出を開始しません。
ページのロードが遅い場合、完全にロードされるまで待ってから、検出が適切に行われているかどうかを判断する必要があります。通常、ブラウザのステータス・バーは、ブラウザ・ウィンドウの下にあり、「Done」または「Finished」などの適切なメッセージを表示することによって、ページのロードが完了したことを示します。

適切なヘルパー・オブジェクトが実行されていますか

ブラウザに接続され、ブラウザとデータを送受信する手段をLogon Managerに提供するヘルパー・オブジェクトを、エージェントは、インストール済Webブラウザと通信するために使用します。ヘルパー・オブジェクトがバックグラウンドで実行されていない場合、Logon Managerはブラウザと通信できません。詳細は、「Webフォームの検出の理解」を参照してください。

検出およびオフセット・マッチング・ルールをすべて削除すると検出に成功しますか

ターゲットWebフォームの正常な検出を妨げるように1つ以上のマッチング・ルールを構成している可能性があります。すべてのマッチング・ルールを削除し、問題を発生させているルールがわかるまで検出をテストしながら、1つずつ追加し直します。

URL定義をhost.domainフォームに切り捨てると検出に成功しますか

エージェントがフォームを一貫して検出することを妨げる動的セグメントが、URLに含まれている可能性があります。URL定義をhost.domainフォームに単純化し、テンプレートをテストします ? 検出が成功する場合、問題を発生させているセグメントがわかるまで一度に1セグメントずつURL定義を再作成し、正規表現を使用して動的セグメントに対応します。詳細は、「URL検出の理解」を参照してください。

前述の手順で問題が解決されない場合は、「Oracleサポートへの連絡」で詳細を参照してください。

コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

エージェントはフォームを検出しますか

エージェントがフォームをまったく検出せず、レスポンスを試行しない場合、「WEbフォームの検出の理解」を参照して、検出を阻止している可能性があるテンプレート構成の問題を識別します。

エージェントは資格証明を注入しますが、送信はしませんか

エージェントがフィールドを正常に検出して正しい資格証明を注入するが、それらを処理のためにアプリケーションに自動的に送信することができない場合、[Enter]を押して、資格証明が送信されるかを確認し、次のいずれかを実行します:

・ [Enter]を押すと資格証明が送信される場合、テンプレートからsubmit入力フィールド定義を削除します。submitフィールド定義が欠けている場合、エージェントは、デフォルトのsubmitアクションである[Enter]キーストロークを送信します。

・ [Enter]を押しても資格証明が送信されない場合、手動で送信するようにユーザーに指示します。

フィールドへの移入が不安定ですか

エージェントによるフィールドへの移入が不安定(誤った値、切り捨てられた値、文字化けした値または空白の値を取り込むなど)なときは、1つ以上のターゲットの要素名が非一意または動的である場合があります。このような場合、要素名のかわりに序数を使用して、Logon Managerへの要素を一意に識別します。

前述の手順で問題が解決されない場合は、「Oracleサポートへの連絡」で詳細を参照してください。

SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

事前入力されたフィールドによって誤ったログオンが発生しますか

カーソルは常に同じフィールドで開始して、フォーカスを保持しますか

カーソルが必ずしも同じフィールドで開始せず、エージェントによる移入前にフィールドがフォーカスを失う場合は、特定のホットキーの組合せ([Alt]+[U]など)または標準のWindowsキー([Tab]、矢印など)によるフィールドへのナビゲートがアプリケーションで許可されるかどうかを確認します。フィールドへのナビゲートにキーストロークを使用できない場合、目的のフィールドまたはコントロールをターゲット指定するマウス・クリック・アクションを使用します。

単一のフィールドに複数の値が注入されますか

ジャーナル・フックを使用するSendKeysに切り替えると、注入の信頼性が回復しますか

前述の手順の提案を試した後もエージェントが引き続き単一のフィールドに複数の値を注入する場合は、フォームの対話方法を「SendKeys with journal hook」に切り替えます。これを行うには、アプリケーション・テンプレートで「General」タブを選択して目的のフォームを選択し、「Edit」をクリックして「Fields」タブを選択し、「Transfer Method」オプションを「SendKeys using journal hook」に設定します。

注意: 「SendKeys using journal hook」方式を使用すると、エージェントが代替APIを使用してキーストロークおよびマウス・クリックをブラウザに送信するため、これは通常、Citrix環境で最も効果的です。

注入された値から文字が欠落していますか

マウス・クリック・アクションを使用してフィールドにフォーカスすると、ログオンに成功しますか

ログオンに引き続き失敗する場合は、マウス・クリック・アクションを使用してフォーム内のすべてのフィールドおよびコントロールに対してフォーカスを設定することを検討します。

前述のどの手順でも問題を解決できない場合は、Oracleサポートに連絡してください。

検出マッチングのトラブルシューティング

すべてのマッチング・ルールを削除すると、フォームの検出が回復しますか

テンプレートのフォーム定義からすべてのマッチング・ルールを削除すると、適切なフォーム検出が回復する場合、問題を発生させているルールがわかるまでルールを1つずつ追加し直します。次に、問題のルールの範囲を広げる(たとえば、サイトのDOM階層で現在指定しているものよりも1つ上にあるHTMLコンテナを指定する)か、問題のルールを完全に削除して、検出が回復するか確認します。マッチングを完全に無効化しても検出が回復しない場合、問題はどこか別の場所にあります。
「Webフォームの検出のトラブルシューティング」を参照して問題を解決してください。

前述の手順で問題が解決されない場合は、「Oracleサポートへの連絡」で詳細を参照してください。

ログオン・ループのトラブルシューティング

ログアウト後のフォームのURLは、標準ログオン・フォームのURLと異なりますか

ログアウト時に表示されるログオン・フォームのURLが、標準ログオン・フォームのURLと異なる場合、テンプレートでURL定義を変更して、ログオン後のフォームのURLがポジティブ・マッチにならないようにします。手順は、「URL検出基準の構成」を参照してください。

ログアウト後のフォームは、標準ログオン・フォームと異なりますか

ログアウト時に表示されるログオン・フォームがアプリケーションの標準ログオン・フォームと十分に異なる場合、マッチングを使用して2つのログオン・フォームを一意に区別します。手順は、「追加のフィールド検出基準の構成」を参照してください。

「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

ログオン・ループ猶予期間タイマーを構成するには、次の手順を実行します:

5. Logon Manager Administrative Consoleで目的のテンプレートを開き、「Miscellaneous」タブを選択します。

6. 「Logon Loop Grace Period」フィールドで、ドロップダウン・リストから目的の操作モードを
選択します。

7. 猶予期間が有効なときにエージェントに実行させる内容に応じて、次のいずれかを実行します:

8. 変更を保存してリポジトリにコミットします(該当する場合)。

前述の手順で問題が解決されない場合は、「Oracleサポートへの連絡」で詳細を参照してください。

Javaアプリケーションの問題のトラブルシューティング

Javaアプリケーション固有の問題を診断し解決するには、次のステップを使用します。

インストールしたJREはサポートされているブランドおよびバージョンですか

Oracle JInitiator、あるいは開発元がOracleまたはIBM以外の別のJREを使用していますか

JHOはロードされていますか

JHOで必要な権限の検証および修復

必要な権限が付与されているかどうかの確認

・ユーザーの.java.policyファイルに、JHOで必要な権限が含まれていない。

・ターゲットJREのセキュリティ設定が(通常はJREのjava.securityファイルに保存される)、ユーザーの.java.policyファイルを参照しない。

欠落したJHO権限の修復

ACLが適切で、必要な権限がユーザーの.java.policyファイルに存在しない場合は、次のいずれかを実行します:

Java Helper Object (JHO)の動作の構成

Logon Managerは、JHOの次の側面の動作を制御できる、グローバルなエージェント設定を提供します:

・特定のJREバージョンを除外する

・特定のJREベンダーを除外する

・ Javaアプレットのロードを考慮したレスポンス遅延を定義する

・ JREの初期化を考慮したレスポンス遅延を定義する

・レスポンス再試行間の遅延を定義する

・レスポンス再試行の最大数を定義する

・ JHOが認識または無視する特定の階層、ウィンドウ、コンポーネントおよび注入タイプのイベントを定義する

これらの設定は、Logon Manager Administrative Consoleのツリーの次の場所にあります:

「Global Agent Settings」a「Live」a「User Experience」a「Application Response」a「Java Applications」

手動による特定のJREに対するJHOの制限

これらの設定を構成する際には、次の点に注意してください:

・設定の対象となる値を省略すると、指定されているデフォルトが使用されます。値を設定すると、一致しない値はすべて無視されます。

・ JHOは最初に包含ルールを処理し、その後除外ルールを処理します。

設定は、Windowsレジストリの次のパスにあります。

HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager\JHO

設定は、次のカテゴリに分けられます:

・ JHO包含ルール

・ JHO除外ルール

・許可されるJava Runtime Environment (JRE)バージョン

JHO包含ルール

設定

説明

JhoIncludeHostNameN

アプリケーションのホストJVM実行可能ファイルを指定します。

すべての実行可能ファイルが受け入れられます(つまり、JHOはどのような実行可能ファイルに対してもロードされます)。

JhoIncludeHostCommandLineN

JHO除外ルール

設定

説明

JhoExcludeHostNameN

アプリケーションのホストJVM実行可能ファイルを指定します。

JhoExcludeHostCommandLineN

許可されるJava Runtime Environment (JRE)バージョン

どちらの設定の値もx.y.zという形式である必要があります:

・ xは、メジャー・バージョンです。

・ yは、マイナー・バージョンです。

・ zは、リリース・タイプ(機能、メンテナンスまたは更新)、およびインストールされているJREのビルドID (1.6.0_07など)を示します。

設定

説明

JhoMinimumJavaVersion

許可されるJRE/JDKバージョンの下限を指定します。

デフォルト値:

1.2 (JHOでサポートされる最も古いJREバージョン)

JhoMaximumJavaVersion

許可されるJRE/JDKバージョンの上限を指定します。

デフォルト値:

空白(つまり、JREバージョンの上限はありません)

Java Helper Object (JHO)のイベント・レスポンス動作の手動によるカスタマイズ

この設定は、Windowsレジストリの次のキーにあります。

HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager

イベント・レスポンス構成の設定

設定	説明
JhoHierarchyEventProcessing	どのJava階層イベントを認識するかを決定します。フラグを次のように設定します: HIERARCHY_EVENT_CHANGED = 0x1 前述の値は、すべての階層イベントを認識するようにJHOに指示します。
JhoEventWaitTimeout	JHOコントロールのイベント処理タイムアウトを決定します(ミリ秒単位)。デフォルト値の0は、JHOに無期限に待機するように指示します。
JhoWindowEventProcessing	どのJavaウィンドウ・イベントを認識するかを決定します。このフラグは、次の値の組合せです: ・ WINDOW_EVENT_OPENED = 0x1 ・ WINDOW_EVENT_CLOSED = 0x2 ・ WINDOW_EVENT_ACTIVATED = 0x4 ・ WINDOW_EVENT_DEACTIVATED = 0x8 ・ WINDOW_EVENT_CLOSING = 0x10 ・ WINDOW_EVENT_ICONIFIED = 0x20 ・ WINDOW_EVENT_DEICONIFIED = 0x40 デフォルトでは、すべてのウィンドウ・イベントが認識されます。

設定

説明

JhoComponentEventProcessing

どのJavaコンポーネント・イベントを認識するかを決定します。このフラグは、次の値の組合せです:

・ COMPONENT_EVENT_SHOWN = 0x1

・ COMPONENT_EVENT_HIDDEN = 0x2

・ COMPONENT_EVENT_ADDED = 0x4

・ COMPONENT_EVENT_REMOVED = 0x8

デフォルトでは、すべてのコンポーネント・イベントが認識されます。

JhoInjectType

データをコントロールに送信する際にJHOが使用する注入タイプを確認します。このフラグは、次の値のいずれかをとります:

・ INJECT_TYPE_DEFAULT = 0

・ INJECT_TYPE_METHOD = 1

・ INJECT_TYPE_ACCESSIBLE = 2

・ INJECT_TYPE_NONACCESSIBLE = 3

・ INJECT_TYPE_ROBOT = 4

デフォルトでは、このフラグにINJECT_TYPE_DEFAULTが設定され、その場合、JHOは次の各方法を、ここに示す順に、注入が成功するまで試みます:

・ INJECT_TYPE_METHOD (コントロールに適切な設定方法が検出された場合)

・ INJECT_TYPE_ACCESSIBLE (コントロールでアクセシビリティがサポートされている場合)

・ INJECT_TYPE_NONACCESSIBLE

・ INJECT_TYPE_ROBOT

注意: コンボ・ボックスおよびリスト・ボックスの場合、JHOは常にINJECT_TYPE_METHODを使用します。

推奨されるJHOイベント・レスポンス構成のデフォルト

Logon Managerの新規インストールでは、次のデフォルト設定をお薦めします:

・ JhoWindowEventProcessing=0x3

・ JhoComponentEventProcessing=0xB

・ JhoHierarchyEventProcessing=0x0

これらの値は、次のイベントを認識するようにJHOに指示します:

・ WINDOW_EVENT_OPENED (0x1)

・ WINDOW_EVENT_CLOSED (0x2)

・ COMPONENT_EVENT_SHOWN (0x1)

・ COMPONENT_EVENT_HIDDEN (0x2)

・ COMPONENT_EVENT_REMOVED (0x8)

第3部: メインフレーム・アプリケーション

この部では、特定のサインオン・シナリオを解決するためにアプリケーション・テンプレートを構成する方法と理由の理解に必要な概念について説明し、また、メインフレーム・アプリケーション・フォームを構成およびテストする手順の推奨されるベスト・プラクティスについて、およびエージェントのアプリケーション・フォームに対する検出や応答が不安定になる可能性がある最も一般的な問題の診断と解決手順について説明します。内容は次のとおりです:

・フォームのレスポンスのトラブルシューティング

・ログオン・ループのトラブルシューティング

・ SSO MHOステータス・ツールでのトラブルシューティング

ヒント: この章に示された手順で問題を解決できない場合は、Logon Managerのアクティビティの追跡とロギングを行い、記録された情報を分析のためにOracleサポートに送信することにより、さらにトラブルシューティングを行うことができます。このために、Oracleサポートではトレース・コントローラ・ユーティリティを提供しています。ユーティリティの使用方法の詳細は、Enterprise Single Sign-On Suite Plus管理者ガイドのトレース・コントローラ・ユーティリティの使用に関する説明を参照してください。

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

Logon Managerでは、ターミナル・エミュレータを介してアクセスされるメインフレーム/ホスト・アプリケーションに対するシングル・サインオン機能を提供できます。ターミナル・エミュレータは、IBM 5270/5050、Telnet、SSHなどを含む様々なプロトコルを使用して、ユーザーのWindowsワークステーションからマルチユーザー・メインフレーム・システムにターミナル・セッションを確立するアプリケーションです。ログオン、パスワード変更およびその他の多様なサインオン・イベントを、Logon Managerで検出して応答するように構成することができ、様々なフォーム、フィールド、コントロールおよびイベント・フローがサポートされています。

注意: 現在サポートされているエミュレータのリストは、ご使用のバージョンのLogon Managerのリリース・ノートにあります。Logon Manager Administrative Consoleを使用してmrfmlist.iniファイルの内容を表示することによっても、エミュレータがサポートされているかどうかを確認できます。
手順は、「エミュレータ構成の表示および変更」を参照してください。

サポートされているWindowsベースのターミナル・エミュレータ内に表示されるテキストベースの
メインフレーム・アプリケーション・フォームを認識するために、Logon Managerでは次の手順が実行されます:

1. エミュレータのHLLAPIインタフェース、ウィンドウ、ターミナル・セッションおよびターゲット・フォームを検出します:

a. 起動時に、mfrmlist.iniファイルに指定されたエミュレータ検出データをロードし、新しいターミナル・セッション用のシステムで検出されたすべてのHLLAPIインタフェースの監視を開始します。
(エミュレータがHLLAPI通知を提供せず、ポーリングが有効である場合、Logon Managerでは、これらのエミュレータに対してデフォルトで700ミリ秒ごとにHLLAPI経由で問合せが行われます)。

注意: mfrmlist.iniファイルには、サポートされるターミナル・エミュレータに対する検出データ(HLLAPIインタフェース・ライブラリ名およびパス、ウィンドウ・タイトル、クラス、および必要なカスタム構成パラメータなど)が含まれます。このデータにより、Logon Managerは、エミュレータおよびエミュレータによって表示されるターミナル・セッションを識別し、それらと対話することができます。

b. 実行中のエミュレータが、新しいターミナル・セッションが開かれたことをHLLAPIを介してLogon Managerに通知すると(または、ポーリングが有効な場合、Logon Managerがエミュレータ内に新しいセッションを検出すると)、Logon Managerは、使用可能なすべてのメインフレーム・アプリケーション・テンプレートで、ターミナル・セッションに表示されているテキストと一致するフォーム定義を含むテンプレートを検索します。

c. HLLAPIイベント(キーストローク、画面更新など)が検出されるたびに、使用可能なメインフレーム・アプリケーション・テンプレートの再スキャンおよび指定された一致テキストの再検出が1度ずつ行われます。

2. 検出したフォームに応答し、ログオンを完了します:

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

b. 資格証明を処理のためにアプリケーションに送信します。

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

フォームの検出とレスポンスの理解

Logon Managerは、ssomho.exeという名前のバックグラウンド・プロセスとしてインスタンス化されたMainframe Helper Object (MHO)を使用し、High-Level Language API (HLLAPI)を介してターミナル・エミュレータと対話します。
これにより、Logon ManagerはエミュレータのHLLAPIインタフェースをプログラム的に検出し、エミュレータのセッションのインスタンス化、画面更新やその他のイベントを監視(または問合せ)することができ、一致テキストの検出、資格証明の注入およびそれらを処理のためにアプリケーションに送信するためにエミュレータと対話することができます。

MHOは、HLLAPIを介して最新の32ビット・エミュレータと直接インタフェースをとります。さらに、オラクル社は、一般的な非HLLAPIエミュレータのいくつかおよび16ビット・エミュレータに対するサポートも提供しており、このようなエミュレータについては、次に示す追加のヘルパー・オブジェクト(Logon Managerインストーラの「Extensions」a「Mainframe Support」ノードで入手可能)をインストールする必要があります:

・ コンソール・ウィンドウ ? cmd.exeインタプリタによってインスタンス化されて、MicrosoftのTelnetクライアントなどの32ビット・アプリケーションを実行する、Windowsのコマンドライン・コンソール・ウィンドウをサポートします。

・ PuTTY ? PuTTYターミナル・エミュレータをサポートします。

注意: アプリケーションへのTelnet、SSHまたはRS-232接続が必要であり、現在のターミナル・エミュレータがIBM 5270/5050接続に対するHLLAPIのみをサポートする場合、これらのプロトコルを介した接続について、オラクル社では無料のPuTTYターミナル・エミュレータの使用をサポートし、お薦めしています。

Logon Managerを起動すると、MHOはmfrmlist.iniファイル(%PROGRAMFILES%\Passlogix\v-GO SSO\Helper\Emulatorにあります)の内容を読み取り、これには、サポートされているエミュレータについての検出データ(HLLAPIインタフェース・ライブラリの名前および場所、ウィンドウ・タイトルおよびクラス、実行可能ファイル名、エミュレータのサポートに必要な任意のカスタム構成オプションなど)が含まれます。

注意: Logon Managerにファクトリmfrmlist.iniファイルが同梱されている場合、Logon Managerがリストにないエミュレータを検出してそれと対話できるようにするために、そのエミュレータをファイルに追加することもできます。詳細は、「エミュレータ構成の表示および変更」を参照してください。

MHOは次に、mfrmlist.iniファイルにある各エミュレータの構成データを解析し、検出する登録済の各HLLAPIインタフェースの監視(または構成されている場合はポーリング)を開始します。構成データのロードが終了すると、MHOは新しいセッション短縮名について、検出したHLLAPIインタフェースを監視します。

新しく検出したターミナル・セッション短縮名ごとに、MHOは、HLLAPIを介してエミュレータにセッション・ウィンドウのタイトルやクラスなどの詳細を問い合せます。この情報は、mfrmlist.iniファイルのエミュレータのエントリに存在するウィンドウのタイトルおよびクラスと照合されます。

HLLAPI自体はオープン・スタンダードですが、多くの場合、エミュレータのベンダーがターミナル・エミュレータを実装する際の準拠や完全性の度合いは様々です。このため、一部のHLLAPI対応のエミュレータでは、セッションのインスタンス化や画面更新などのセッション・イベントがLogon Managerに適切に通知されません。これらのエミュレータについては、ポーリングを有効にするChangeNotificationBroken=1 構成パラメータが、mfrmlist.ini ファイルのエントリ内に存在する必要があります。

注意: mfrmlist.iniファイル内のエミュレータ・エントリを表示し、必要に応じてこのパラメータを追加する方法は、「エミュレータ構成の表示および変更」を参照してください。
(このパラメータが必要なオラクル社テスト済のエミュレータは、初期状態でmfrmlist.iniファイルに含めるために事前構成されています。)

エミュレータが明確に識別されると、MHOは、使用可能なすべてのメインフレーム・アプリケーション・テンプレートに、ターミナル・セッションに表示されたテキストの一致があるかを調べて、検出されたフォーム・テキストに対するポジティブ・マッチである最初のテンプレートをロードします。MHOは、エミュレータで新しいHLLAPIイベントが検出されるたびに、すべてのメインフレーム・テンプレートの再スキャンおよび一致テキストの再検出も行います。

メインフレーム・アプリケーションはテキストモードで機能し、つまり、ターミナル画面を構成する既知のサイズ・グリッド(通常、80行25列)に表示される一連の固定幅文字を使用します。このため、画面上の各文字は、垂直および水平の1組の座標で一意に識別できます。メインフレーム・アプリケーション・フォームを定義するとき、Logon Managerに各ターゲット・フィールドの開始座標(つまり、Logon Managerが注入を開始する座標)を指定します。

たとえば、「Username」フィールドは列10、行15から開始し、(つまり、Logon Managerは行15のセミコロンの後から開始するユーザー名を注入し)、一方パスワード・フィールドは、2行下の列10、行17の「Password」:フィールド・テキストの後から開始します:

Welcome to Aperture Science GLaDOS Release 6.10.
-------------------------------------------------------
| GLaDOS 6.10 |
-------------------------------------------------------
Today’s date is March 1st, 2011. There will be cake. Username: . Password: . LOG ON DISCONNECTT

,80列

,「Username」フィールド(C10、R15で開始)、「Password」フィールド(C10、R17で開始)

25行

注意: Logon Managerは任意のサイズのターミナル表示をサポートし、単一のテンプレートが異なるサイズで実行しているアプリケーションへの応答を提供します(構成された一致テキストおよびフィールドの絶対座標が、画面サイズの変更時も同じまま保持されるかぎり)。

ヒント:??? ほとんどのエミュレータでは、ターミナル・カーソルの座標がステータス・バーに表示されます。
フィールドの座標をすばやく判断するには、ターミナル・カーソルをフィールドの最初に置き、エミュレータのステータス・バーに表示された位置を確認します。

検出中、Logon Managerは指定された一致テキストの座標を取得し、そのテキストが指定された座標に存在するかどうかを確認し、応答中は、Logon Managerは指定されたフィールド座標の場所を特定し、資格証明をその画面位置に注入します。

固定画面フォーム対スクロール画面フォーム

この項で前に示して説明した例で、固定画面アプリケーションを表しており、それは最も一般的に見られるタイプのアプリケーションです。ただし、Telnetクライアントなどのアプリケーションによっては、スクロール画面表示を利用する場合があります。違いは次のとおりです:

・ 固定画面。アプリケーション画面の水平(列数)および垂直(行数)サイズは固定であり、つまり、垂直方向にスクロールしません。ほとんどのメインフレーム・アプリケーション(在庫管理やマシン・コントロール・システムなど)がこのカテゴリに入ります。固定画面セッションでは、セッションに表示されるすべての文字の位置が静的であり、つまり、その座標は変更されません。

・ スクロール画面。アプリケーション画面の水平サイズ(列数)は固定ですが、垂直サイズ(行数)は無制限であるか連続しています。スクロール画面セッションでは、フィールドの座標は静的ではなく、座標を特定するために、カーソルの列位置(つまり、ログオン・シーケンスの各手順を完了した後、カーソルがあると期待される水平方向の位置)、さらに、ログオンの完了に必要なフィールドおよびアクションのシーケンスを指定するようLogon Managerに要求されます。Logon Managerは、HLLAPIを介して画面がいつどれだけスクロールしたか検出することができ、また、必要に応じて、シーケンスの次のフィールドまたはアクションに進むことができます。

注意: スクロール画面フォームの場合、Logon Managerは動的水平座標を持つフィールドもサポートするため、水平座標として正規表現を入力できます。詳細は、「動的列配置に対するフォームの構成(スクロール画面のみ)」を参照してください。

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

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

・ログオン

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

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

・パスワードの変更

・パスワード変更の成功(パスワード変更の成功を示すダイアログ)

・パスワード変更の失敗(新しいパスワードが拒否されたことを示すダイアログ)

メインフレーム・ログオン・フォームには、たとえば、通常は少なくともユーザー名フィールド、パスワード・フィールド、および場合によってはLogon Managerが画面をナビゲートできる追加のコントロールが含まれます。通常、資格証明は、Logon Managerのデフォルトのsubmitアクションである[Enter]キーストロークを介して送信されます(フォーム定義で明示的には指定しません)。

注意: 一部の非HLLAPIエミュレータでは、Windowsスタイルのログオン・ダイアログを表示できるスクリプト言語が提供されている場合があります。このような場合は、スクリプト化されたログオン・ダイアログにWindowsアプリケーション・テンプレートを作成し、SendKeysを使用して、資格証明を注入しログオンを完了できます。必要なスクリプトを作成する手順は、ベンダーによって提供されるエミュレータのドキュメントを参照し、Windowsアプリケーション・テンプレートを作成する手順は、ベスト・プラクティス・ガイドのWindowsアプリケーションのためのテンプレート構成および診断を参照してください。

メインフレーム・アプリケーション・テンプレートでフォームを定義する際、アプリケーションの表示内のターゲット・フィールドの座標を識別する必要があります。Logon Managerは、セッション画面に表示されるフォームを検出する前にエミュレータ・ウィンドウを検出するため、単一のアプリケーション・テンプレートは、そのテンプレートを作成するために使用した元のエミュレータと同一に動作するすべてのサポートされるエミュレータに対して機能します。HLLAPIのおかげで、Logon Managerは画面取得を実行する必要も、テキスト画面全体で一致を分析する必要もありませんが、そのかわりに、Logon Managerは、エミュレータ内で新しいHLLAPIイベントが検出されるたびに定義済の一致テキストを再検出します。

同じターミナル・セッションに、(ログオンやパスワード変更などの)呼び出される機能に応じて
異なるフォームを表示できるため、そのウィンドウで表示できる複数のフォームの定義を、単一のテンプレートに含めることができます。ほとんどのアプリケーションの場合、定義する必要があるのは、Logon Managerで応答するフォームのみです。Logon Managerは、ユーザーの資格証明ストアから取得した資格証明をフォーム内の適切なフィールドに自動的に移入することができるだけでなく、その資格証明をアプリケーションに処理のために送信することもできます。フォームの定義は、一意の識別基準の指定と、そのフォームが検出されたときにとるアクションおよびそのアクションで実行する必要がある特定の動作(資格証明の注入など)の指定で構成されます。

注意: Logon Managerは、アプリケーション表示に一意のセッション識別情報(ホスト名など)が含まれていない場合、1つのアプリケーションの複数セッションを区別できません。たとえば、同じアプリケーションを実行する2台のメインフレーム・ホストに対して2つのセッションを開き、それぞれが異なる資格証明を必要とする場合、Logon Managerは、テンプレートに格納された資格証明で両方のセッションに対してログオン(またはパスワード変更)を完了させようとします。そのような場合は、1つのアプリケーションについての可能性があるすべてのセッションの資格証明を単一テンプレート内に格納し、ログオン・チューザ機能を使用して、各セッションに対する資格証明をユーザーが手動で選択するようにプロンプトを表示することをお薦めします。

サポート対象の資格証明注入方式

ターゲット・アプリケーションの設計に応じて、Logon Managerは次のいずれの方式を使用して、ターゲット・フォームのフィールドおよびコントロールと対話することができます:

・ HLLAPI - これは、ほとんどのメインフレーム・アプリケーション(特にIBM 5270/5050プロトコルを使用するもの)でデフォルトかつ推奨されるフォーム対話方式です。この方式は、HLLAPIインタフェースを使用して、指定された座標に資格証明をプログラム的に注入します。

・ SendKeys - この方式は、キーストロークをエミュレートすることによって資格証明を注入します。エミュレータでHLLAPIがサポートされない場合、またはログオン・シーケンスを完了するために特別な動作が必要な場合、たとえば、アプリケーションでユーザーがキーストロークを使用して手動で次のフィールドに進むことが要求され、ユーザーがナビゲートするまではフィールドが無効化されたままである場合などに、この方式を使用します。構成が堅牢になるため、可能なかぎりHLLAPIを使用することをお薦めします。

注意:? メインフレーム・アプリケーション・テンプレートを構成する際、ウィザードの完了後、フォーム定義に追加のフィールドまたはアクションを加え始めるとすぐに、
Logon ManagerはHLLAPIからSendKeysベースの注入へと切り替わります。

・ WindowsアプリケーションとしてのSendKeys ? 他の注入方式が機能しない場合のみ推奨され、メインフレームをWindowsアプリケーションとして構成し、アプリケーションのログオン画面へのナビゲートおよび資格証明の注入の両方にSendKeysを使用することを試行できます。Logon Managerは画面更新を検出できず、アクションはアプリケーションに盲目的に送信されるため、この方式は、範囲が制限されます。そのため、この方式は、アプリケーションの初期画面(通常、ログオン画面)に対してのみ機能し、ログイン後に表示される後続の画面には機能しません。

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

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

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

初期状態でLogon Managerによってサポートされるエミュレータですか?????????????????????????????????????????????????????????????????????????????????

エミュレータがオラクル社によってテストされ、Logon Managerと互換性があるとわかった場合、初期状態でLogon Managerによってサポートされており、mfrmlist.iniファイルにそのエミュレータの対応するエントリが存在します。現在サポートされているエミュレータのリストは、最新のアプリケーション・リリース・ノートにあります。これは、「エミュレータ構成の表示および変更」の説明に従って、問題のエミュレータのエントリをmfrmlist.iniファイル内で探しても確認できます。

エミュレータが初期状態ではLogon Managerによってサポートされておらず、HLLAPI準拠である場合は、Logon Managerと完全に互換性があるかどうかを確認するために、(「エミュレータ構成の表示および変更」の説明に従って)それをmfrmlist.ini ファイルに追加できます。構成の問題が発生した場合にOracleサポートは支援に努めますが、テスト済でないエミュレータが、予期されるすべての可能性においてLogon Managerと連携して適切に機能することをオラクル社は保証できません。

注意: リストにないエミュレータをmfrmlist.iniファイルに追加し、Logon Managerで完全に動作することがわかった場合、次のリリースのLogon Managerでそのエミュレータに対する正式サポートを含めることを検討できるように、エミュレータの名前およびバージョンをOracleサポートに送信してください。

エミュレータはHLLAPI準拠ですか

エミュレータがHLLAPI準拠であるかどうかに応じて、次のいずれかを実行します:

・エミュレータはHLLAPI準拠であるが、Logon Managerによって正式にサポートされていない場合、そのエミュレータをmfrmlist.iniファイルに手動で追加し、Logon Managerがそれと対話できるようにし、そのエミュレータを介したLogon Managerのターゲット・アプリケーションへのレスポンスが信頼できるかどうかを確認します。手順は、「エミュレータ構成の表示および変更」を参照してください。

・エミュレータがHLLAPIをサポートしていない場合、アプリケーションのログオンおよびパスワード変更フォームをWindowsスタイルのダイアログとして表示するスクリプトをコード化できるスクリプト言語が提供されているかどうかを確認します。エミュレータにこのスクリプト機能がある場合、ベンダーのドキュメントに従ってスクリプトを作成し、Windowsスタイルのダイアログに応答するようにWindowsアプリケーション・テンプレートを構成します。Windowsアプリケーション・テンプレートの作成の詳細は、ベスト・プラクティス・ガイドのWindowsアプリケーションのためのテンプレート構成および診断を参照してください。

注意: スクリプトの作成の詳細は、エミュレータのベンダーにお問合せください。オラクル社では、第三者のスクリプトの作成またはトラブルシューティング(またはその両方)に関するヘルプを提供できません。

前述のどのオプションも使用可能ではない場合は、Oracleサポートに連絡してください。

エミュレータのHLLAPI実装は最新ですか

場合によっては、エミュレータの最初のHLLAPI実装が不完全であるか欠陥があることがあります。
可能な場合は、エミュレータのLogon Managerとの互換性を改善する方法で、エミュレータのHLLAPI実装を改善または拡張するベンダーの更新を調査して適用することを
お薦めします。エミュレータのHLLAPI実装のレベルの詳細は、エミュレータのベンダーにお問合せください。

ターゲット・フォームは非一意ですか

フォームを構成する際、アプリケーション内の他の場所に出現しない一致テキスト文字列をフォーム内で選択する必要があります。そうしないと、Logon Managerが、ターゲット・フォームでない場合でも非一意の一致テキストを含む画面に応答する可能性があります。一意の一致テキスト文字列がターゲット・フォームに存在しない場合、フォームに一意のテキストを追加するようにアプリケーションを変更できるか調査してください。

アプリケーションの変更という選択肢がない場合、テンプレートにログオン・チューザ機能を構成し、影響のあるアプリケーションにログオンするときに目的の資格証明を選択するようユーザーに指示します。ログオン・チューザ機能の詳細は、コンソール・ヘルプを参照してください。

ログオン・フォームは複数の画面で構成されていますか

Logon Managerは新しい画面のそれぞれを別々のフォームとして処理するため、ターゲット・フォームが複数画面で構成されている(つまり、ユーザー名フィールドが表示され、画面が消去されてからパスワード・フィールドが新しい画面に表示される)場合、画面のそれぞれに別々のフォームを定義します。

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

一部のアプリケーションでは、ログオン・フィールドとパスワード変更フィールドまたはコントロール(あるいはその両方)が同じ画面に表示されます。そのような場合は、「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションが表示されず、ユーザーは自動的にログインされます。ユーザーが目的のアクションを選択できるようにするには、テンプレートでログオン・フォームおよびパスワード変更フォームを定義します。エージェントは、ログオン・フォームおよびパスワード変更フォームが統合されたアプリケーションに応答する場合は、ユーザーに目的のアクション(ログオンまたはパスワード変更)を選択するように求めます。

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

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

一部のアプリケーションでは、ログオン・フィールドとパスワード変更フィールドまたはコントロール(あるいはその両方)が同じ画面に表示されます。
そのような場合は、「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションが表示されず、ユーザーは自動的にログインされます。ユーザーが目的のアクションを選択できるようにするには、テンプレートでログオン・フォームおよびパスワード変更フォームを定義します。エージェントは、ログオン・フォームおよびパスワード変更フォームが統合されたアプリケーションに応答する場合は、ユーザーに目的のアクション(ログオンまたはパスワード変更)を選択するように求めます。

PWCフォームは複数の画面で構成されていますか

Logon Managerは新しい画面のそれぞれを別々のフォームとして処理するため、ターゲット・フォームが複数画面で構成されている(つまり、アプリケーションが古いパスワードを入力するプロンプトを表示し、画面を消去してから新しいパスワードのプロンプトを表示し、再び画面を消去してから新しいパスワードの確認のプロンプトを表示する)場合、画面のそれぞれに別々のフォームを定義します。

非一意の画面が1つ以上ありますか

複数画面フォームの1つ以上の画面が非一意である(つまり、Logon Managerによって区別できない)場合、それらの画面に対するレスポンスが誤ります。フォームを構成する際、アプリケーション内の他の場所に出現しない一致テキスト文字列をフォーム内で選択する必要があります。そうしないと、Logon Managerが、ターゲット・フォームでない場合でも非一意の一致テキストを含む画面に応答する可能性があります。一意の一致テキスト文字列がターゲット・フォームに存在しない場合、フォームに一意のテキストを追加するようにアプリケーションを変更できるか調査してください。アプリケーションの変更という選択肢がない場合、テンプレートにログオン・チューザ機能を構成し、影響のあるアプリケーションにログオンするときに目的の資格証明を選択するようユーザーに指示します。

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

アプリケーションで、パスワード変更中に新しいパスワードの確認(再入力)をユーザーに要求する場合、パスワード確認画面に応答するログオン・フォームを定義します(2番目のログオン・フォームにパスワード・フィールドのみを定義します)。

アプリケーションでパスワード変更の成功または失敗のメッセージを表示しますか

アプリケーションで、パスワード変更後に成功または失敗のメッセージを表示する場合、テンプレートでパスワード変更の成功フォーム、またはパスワード変更の失敗フォームを定義します。詳細は、「フォームの構成」を参照してください。

フォームの構成

注意: フォームを構成する前に、目的のターミナル・エミュレータを起動し、ターゲット・アプリケーションに接続し、ターゲット・フォームが表示されることを確認します。

固定画面フォームの基本構成

固定画面フォームの基本構成を完了するには、次の手順を実行します:

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します:

・新しいテンプレートを作成し、そのログオン・フォームを定義する場合:

i. 右側のペインで「Add」をクリックします。

・既存のテンプレートにログオン・フォーム定義を追加する場合は、次の手順を実行します:

i. 「Applications」ノードを展開し、目的のテンプレートを選択します。
テンプレートが右側のペインに表示されます。

ii. ペインの下部で「Add」をクリックします。

3. 表示されたウィザードで、一致テキスト、およびアプリケーションへのログオン時にLogon Managerと対話させるフィールドを定義します:

a. 「Form Type」画面で、目的のフォーム・タイプを選択し、「Next」をクリックします。

b. 「Screen Type」画面で、「Fixed Screen」をクリックします。

c. 「Paste Screen Text」画面が表示されたら、エミュレータ・ウィンドウでターゲット・フォームを構成するテキスト全体をクリップボードにコピーし、「Paste Text」をクリックしてウィザードに貼り付けます。テキストを貼り付けたら、「Next」をクリックします。

d. 「Text to Match」画面で、Logon Managerが一意に識別するためにフォーム内を検索してテンプレートと照合するテキストを定義します:

注意: マッチング・ルールは、目的のマッチング動作を保持しながら最小にすることをお薦めします。大きい部分のテキストのマッチングは、ログオン・プロセスを遅くする可能性があります。

i. 目的の一致テキスト・ブロックをハイライト表示します。

ii. [Enter]を押してテキスト・マッチング・ルールを追加します。

iii. 手順iからiiを繰り返して、追加のテキスト・マッチング・ルールを定義します。

iv. 目的のルールを定義したら、「Next」をクリックします。

e. 「Fields」画面で、Logon Managerが資格証明を注入するターゲット・フィールドを定義します:

ii. Logon Managerが資格証明を注入するフィールドの先頭にカーソルを置きます。

iii. [Enter]を押します。

iv. 表示されたコンテキスト・メニューで、目的のフィールド・タイプを選択します。

v. 手順iからiiiを繰り返して、追加のフィールドを定義します。

vi. 目的のフィールドをすべて定義したら、「Next」をクリックします。

f. 表示された要約画面で、構成の選択内容を確認します。選択内容に誤りがある場合は「Back」をクリックして修正し、誤りがない場合は「Finish」をクリックします。

4. 表示されたフォーム・プロパティ・ダイアログで、次のいずれかの手順を実行します:

・追加の構成を実行する必要がある場合は、ここで行います。

・構成が十分である場合は、「OK」をクリックしてダイアログを終了します。

5. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

スクロール画面フォームの基本構成

スクロール画面フォームの基本構成を完了するには、次の手順を実行します:

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します:

・新しいテンプレートを作成し、そのログオン・フォームを定義する場合:

i. 右側のペインで「Add」をクリックします。

・既存のテンプレートにログオン・フォーム定義を追加する場合は、次の手順を実行します:

i. 「Applications」ノードを展開し、目的のテンプレートを選択します。
テンプレートが右側のペインに表示されます。

ii. ペインの下部で「Add」をクリックします。

3. 表示されたウィザードで、一致テキスト、およびアプリケーションへのログオン時にLogon Managerと対話させるフィールドを定義します:

a. 「Form Type」画面で、目的のフォーム・タイプを選択し、「Next」をクリックします。

b. 「Screen Type」画面で、「Scrolling Screen」をクリックします。

d. 「Cursor Position」画面で、エミュレータ表示内の現在のカーソル位置を次のように指定します:

i. 画面テキスト内で目的の位置をクリックします。(垂直座標および水平座標を「Cursor Row」および「Cursor Column」フィールドに入力することもできます。)

ii. 「Next」をクリックします。
?

e. 「Text to Match」画面で、Logon Managerが一意に識別するためにフォーム内を検索してテンプレートと照合するテキストを定義します:

i. 目的の一致テキスト・ブロックをハイライト表示します。

ii. [Enter]を押してテキスト・マッチング・ルールを追加します。

iii. 手順iからiiを繰り返して、追加のテキスト・マッチング・ルールを定義します。

iv. 目的のルールを定義したら、「Next」をクリックします。

f. 「Fields」画面で、Logon Managerが資格証明を注入するターゲット・フィールドを、アプリケーションのログオン・シーケンスに現れる順序で定義します:

ii. 「Tab Character」フィールドで、Logon Managerが、フィールドに注入されるデータをアプリケーションに送信して次のフィールドに進むために送信するキーストロークを選択します。

iii. 「Add」をクリックします。

iv. 表示されたダイアログで、フィールド・タイプを選択して「OK」をクリックします。

v. 手順iからiiiを繰り返して、追加のフィールドを定義します。

vi. 目的のフィールドをすべて定義したら、「Next」をクリックします。

4. 表示された要約画面で、構成の選択内容を確認します。選択内容に誤りがある場合は「Back」をクリックして修正し、誤りがない場合は「Finish」をクリックします。

5. 表示されたフォーム・プロパティ・ダイアログで、次のいずれかの手順を実行します:

・追加の構成を実行する必要がある場合は、「拡張フォーム構成」を参照します。

・構成が十分である場合は、「OK」をクリックしてダイアログを終了します。

6. 必要に応じて、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

拡張フォーム構成

この項では、ウィザードを使用してフォームを定義した後に実行できる追加の構成について説明します。内容は次のとおりです。

・ウィンドウ・タイトルのマッチング・ルールの定義

・追加のテキスト・マッチング・ルールの定義

・追加フィールドの定義

・ログオン・シーケンスへのキーストローク、一時休止またはテキストの追加

・動的列配置に対するフォームの構成(スクロール画面のみ)

・注入のタイミングの調整

・エミュレータのポーリング間隔の調整

・資格証明要求の遅延間隔の調整

次の手順を開始する前に、目的のフォームのプロパティ・ダイアログを次のように開きます:

1. Logon Manager Administrative Consoleの左側のツリーで、「Applications」
ペインを展開し、目的のテンプレートを選択します。

2. 右側のペインで、「General」タブを選択します。

3. 「General」タブで、目的のフォーム定義をダブルクリックします。

4. 目的の手順に進みます。

ウィンドウ・タイトルのマッチング・ルールの定義

エージェントのレスポンスを特定のウィンドウ・タイトル(またはそれに関する複数のバリエーション)に制限するには、1つ以上の特定のウィンドウ・タイトルのマッチング・ルールを次のように定義します:

1. フォーム・プロパティ・ダイアログの「Identification」タブで、「Add」をクリックします。

2. 表示された「Window Title」ダイアログで、次の手順を実行します:

a. 目的のマッチング・タイプを選択します。

b. 目的の一致する値を入力します。

c. 「OK」をクリックして変更を保存します。

3. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了します。

追加のテキスト・マッチング・ルールの定義

追加のテキスト・マッチング・ルールを定義するには、次の手順を実行します:

1. フォーム・プロパティ・ダイアログの「Matching」タブで、「Add」をクリックします。

2. 表示されたダイアログで、目的の一致テキストおよびその開始座標を入力します。

3. 定義する追加のルールごとに手順1から2を繰り返します。

4. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了し、必要に応じて変更をリポジトリに公開します。

追加フィールドの定義

ウィザードで構成したフィールドに追加してフィールドを定義するには、次の手順を実行します:

警告: この手順を開始すると、テンプレートは、ネイティブのHLLAPIテンプレートからSendKeysテンプレートに変換されます。つまり、Logon Managerは、HLLAPIを介してプログラム的に資格証明を注入せず、そのかわりに、キーストロークをエミュレータに送信することによってユーザーの入力をエミュレートします。この変換は元に戻すことはできず、ネイティブのHLLAPI注入に戻すには、テンプレートを削除して再作成する必要があります。ネイティブのHLLAPI対SendKeysベースの注入の詳細は、「サポート対象の資格証明注入方式」を参照してください。

1. フォーム・プロパティ・ダイアログの「Fields」タブで、「Edit」をクリックします。

2. 表示されたダイアログで、「Fields」タブを選択します。

3. タブで目的のフィールド・タイプを選択し、その座標を入力します
(固定画面のみ)。

4. 上矢印または下矢印を使用して、ログオン・シーケンスの順序を調整します。

5. 追加フィールドごとに手順2から3を繰り返します。

6. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了し、
必要に応じて変更をリポジトリに公開します。

ログオン・シーケンスへのキーストローク、一時休止またはテキストの追加

ログオン・シーケンスにキーストローク、一時休止またはテキストを追加するには、次の手順を実行します:

1. フォーム・プロパティ・ダイアログの「General」タブで、「Fields」セクションの「Edit」をクリックします。

2. 表示されたダイアログで、次のいずれかの手順を実行します:

・キーストロークを追加する場合:

a. 「Special Keys」タブを選択します。

b. タブで、キーストローク・カテゴリを選択し、次にキーストローク自体を選択します。

c. 「Insert」をクリックします。

・一時休止を追加する場合:

a. 「Delay」タブを選択します。

b. タブで、一時休止の長さを秒数で指定します。

c. 「Insert」をクリックします。

・テキストを追加する場合:

a. 「Text」タブを選択します。

b. タブで、目的のテキスト文字列を入力します。

c. 「Insert」をクリックします。

3. 新しく挿入したアクションを選択し、上矢印または下矢印を使用してログオン・シーケンス
での順序を調整します。

4. 追加フィールドごとに手順2から3を繰り返します。

5. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了し、
必要に応じて変更をリポジトリに公開します。

動的列配置に対するフォームの構成(スクロール画面のみ)

動的列配置に対してスクロール画面フォームを構成するには、次の手順を実行します:

1. フォーム・プロパティ・ダイアログの「Options」タブを選択します。

2. 「Column position of cursor」フィールドに、フォーム内のカーソルを置くことができる水平位置を定義する数字または正規表現を入力します。

3. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了し、
必要に応じて変更をリポジトリに公開します。

注入速度の削減

デフォルトでは、Logon Managerは、資格証明を注入および送信する際に、遅延することなくこれらのアクションを実行します。注入速度を遅くするには、次の手順を実行します:

1. フォーム・プロパティ・ダイアログの「Options」タブを選択します。

2. 「Field Delay」フィールドに、Logon Managerが各フィールドの移入後に待機する目的の時間をミリ秒単位で入力します。

3. 終了したら、「OK」をクリックしてフォーム・プロパティ・ダイアログを終了し、
必要に応じて変更をリポジトリに公開します。

エミュレータのポーリング間隔の調整

ポーリングが有効である場合、Logon Managerは、デフォルトでは700ミリ秒ごとにHLLAPIを介してエミュレータに新しいイベントがないかを問い合せます。このポーリング間隔の長さを調整するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを開き、現在のグローバル・エージェント設定のセットをロードします。

2. 左側のツリーで、「Global Agent Settings」a <現在の設定セット> a「End-User Experience」a「Response」a「Host Mainframe Apps」を展開します。

3. 右側のペインで、「Polling Interval」オプションの横のチェック・ボックスを選択し、フィールドに目的の間隔をミリ秒単位で入力します。

4. 終了したら、必要に応じて変更をリポジトリに公開します。

資格証明要求の遅延間隔の調整

テンプレートが存在するが資格証明が格納されていないメインフレーム・アプリケーションにユーザーがログオンすると、Logon Managerは、ユーザーに資格証明を格納するよう要求します。ユーザーが資格証明を格納せずにダイアログを終了すると、Logon Managerはデフォルトの60秒間待機し、次にユーザーがアプリケーションと対話したときに、Logon Managerは再びユーザーに資格証明の格納を要求します。ユーザーにアプリケーションの資格証明の格納を再び要求するまでLogon Managerが待機する時間を変更するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを開き、現在のグローバル・エージェント設定のセットをロードします。

2. 左側のツリーで、「Global Agent Settings」> <現在の設定セット> >「End-User Experience」>「Response」>「Host Mainframe Apps」を展開します。

3. 右側のペインで、「Credential Request Interval」オプションの横のチェック・ボックスを選択し、フィールドに目的の間隔をミリ秒単位で入力します。

4. 終了したら、必要に応じて変更をリポジトリに公開します。

フォームの構成のテスト

フォームを作成して構成したら、公開前に次の手順を実行してテストします:

1. 左側のツリーの「Applications」ノードを展開し、ターゲット・テンプレートにナビゲートします。

2. ターゲット・テンプレートを右クリックし、コンテキスト・メニューから「Test」を選択します。

3. 表示された「Logon Manager Template Test Manager」ウィンドウで、次の手順を実行します:

d. 「Forms」ペインで、ターゲット・フォームを選択します。

e. 「Interactions」ペインに表示される手順に従います。

f. 次のいずれかを実行します:

・エージェントが期待どおりにアプリケーションに応答し、テストが正常に完了した場合は、「Finish」をクリックします。

ログオン・フォームの構成のテスト

エージェントはフォームを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・アプリケーションに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「フォームの検出のトラブルシューティング」を参照してください。

エージェントは資格証明を注入しますか

資格証明がユーザーのストア内のターゲット・アプリケーションに対して格納されている場合、エージェントはアプリケーションの検出に成功すると、資格証明を適切なフィールドに注入します。「Auto-Submit」機能が明示的に無効化されていないかぎり、エージェントは自動的に資格証明の送信も行います。資格証明の注入が失敗する場合、「フォームのレスポンスのトラブルシューティング」を参照してください。

ログアウトでログオン・ループが発生しますか

ログオン失敗または期限切れパスワードの例外をテンプレートで考慮しますか

ログオン試行が失敗した場合(たとえば、不正な資格証明のため)、または格納済のパスワードの期限が切れた場合、ほとんどのアプリケーションでは適切なメッセージが表示されますが、Logon Managerはデフォルトでは何が発生したかがわからず、ログオンを再試行します。これを回避するために、エラー・メッセージの正確な場所にブランク(テキストなし)または空白文字を予期するマッチング・ルールを設定します。このようにすると、メッセージが表示されたときは常に一致ルールが満たされず、Logon Managerはログオンを試行しません。

パスワード変更フォームの構成のテスト

エージェントはフォームを検出しますか

エージェントは資格証明を注入および送信しますか

エージェントはパスワードの変更を検出すると、「Auto Submit」機能が明示的に無効化されていないかぎり、資格証明を適切なフィールドに注入し、アプリケーションに送信します。
資格証明の注入が不安定になるか、まったく発生しない場合、「フォームのレスポンスのトラブルシューティング」を参照してください。

新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

エージェントはパスワード変更フォームにログオンと同様に応答しますか

エージェントがパスワード変更フォームにログオン・フォームと同様に応答する(つまり、エージェントが、現在格納されているユーザーの資格証明を注入して送信する)場合、パスワード変更フォームの定義がログオン・フォームの定義と同じ一致テキスト文字列を使用していないことを確認し、使用しているときは、異なるテキスト文字列で照合するか、可能な場合はどちらかのアプリケーション画面を変更してLogon Managerが一意に照合できるテキストを含めます。

エージェントが引き続きフォームに応答しない場合、「SSO MHOステータス・ツールでの検出およびレスポンスのトラブルシューティング」を参照してください。

リポジトリへのテンプレートの公開

注意: この手順を実行する前に、リポジトリの構造および構成を熟知していることを確認します。

目的のテンプレートおよびその他の構成オブジェクトを選択し、リポジトリに公開するには、次の手順を実行します:

1. Logon Manager Administrative Consoleを起動します。

3. 「Available configuration objects」リストで、目的のオブジェクトにナビゲートして選択します。

5. 次のいずれかを実行して、選択したオブジェクトの公開先のターゲット・コンテナを選択します:

o 以前、目的のコンテナに公開したことがある場合は、「Target Repository」ドロップダウン・リストからそれを選択します。

i. 「Browse」をクリックして、ディレクトリ・ツリーを参照します。

注意: ディレクトリにまだ接続していない場合は、必要な接続情報を提供するようにコンソールから求められます。

ii. 表示された「Browse for Repository」ダイアログで、ターゲット・コンテナにナビゲートして選択します。

7. (オプション)初回使用オブジェクト(FTUList)を作成する場合は、対応するチェック・ボックスを選択します。

注意: このオプションは、手順6でフラット形式での構成オブジェクトの格納を選択した場合のみ、アクティブになります。

8. 「Publish」をクリックします。コンソールは、選択したオブジェクトをターゲット・リポジトリに公開します。

公開プロセスの詳細は、Logon Manager Administrative Consoleヘルプを参照してください。

エミュレータ構成の表示および変更

mfrmlist.iniファイルには、ターミナル・エミュレータを検出してそのターミナル・エミュレータと対話することを可能にする構成情報が含まれます。

注意: このmfrmlist.iniファイルは、次の場所にあります:
%PROGRAMFILES%\Passlogix\v-GO SSO\Helper\Emulator

各エミュレータの最も重要な構成パラメータは次のとおりです:

・ HLLAPIライブラリ・ファイルのフルパスおよびファイル名

・セッション短縮名

・ウィンドウのタイトル

・ウィンドウのクラス

・ポーリング切替え(HLLAPIイベントのMHOを適切に通知しないエミュレータに対して)

パラメータおよびその説明の完全なリストは、「エミュレータ構成パラメータ参照」を参照してください。

mfrmlist.iniファイルに格納されているエミュレータの構成を表示または編集するには、次の手順を実行します:

警告: mfrmlist.iniファイルを外部エディタで変更しないでください。そのようにすると、外部エディタで構成を編集したエミュレータに対して、メインフレームのサポートが操作不可能になります。これは、エミュレータの構成が変更されたとき、コンソールの組込みエディタは、各エミュレータのContextパラメータに格納されたマジック番号を自動的に再計算して更新しますが、外部エディタはマジック番号を更新しないためです。

1. Logon Manager Administrative Consoleを起動します。

2. 「Tools」メニューから、「Modify Configuration」a「MfrmList」を選択します。

コンソールの組込みエディタにmfrmlist.iniが表示されます。

ファイルの一番上に、構成データがファイルの残りでセクションとして格納されているエミュレータのリストがあります。

3. 次のいずれかを実行します:

・既存の構成データを変更するには、そのセクションにナビゲートし(特定のセクションにすばやくジャンプするには、「Section」ドロップダウン・リストから選択します)、目的のパラメータを探して必要に応じて値を変更します。

警告: Contextパラメータの値は変更しないでください。

・新しいエミュレータ用のセクションを追加するには、次の手順を実行します:

a. ファイルの一番上のリストの末尾に、次の形式でエントリを追加します:

EMUxx=NewSectionName

ここでxxは、リストの最後のエントリの数字より1大きい数字です。

b. 新しいセクションを次の形式で作成します:

[NewSectionName]

Parameter1=Value1

Parameter2=Value1

…

ParameterN=ValueN

注意: 新しいセクションの名前は、手順2aでファイルの一番上のEMUxx エントリで指定した名前と一致する必要があります。

4. 終了したら、「Save」をクリックして変更をコミットし、ファイル内のすべてのエントリのContextパラメータを再計算します。

5. 新しく追加したエミュレータを起動し、アプリケーション・セッションに接続します。

6. MHOステータス・ツールを使用して、MHOがエミュレータのHLLAPIインタフェースに正常にアタッチし、開いているセッションを検出したことを確認します。手順は、「SSO MHOステータス・ツールでの検出およびレスポンスのトラブルシューティング」を参照してください。

エミュレータ構成パラメータ参照

次の表は、mfrmlist.iniファイルにエントリを作成する際に使用可能なエミュレータ構成パラメータ(およびその値)をリストしています。

注意:? ブール型のパラメータは次の値をサポートします: true、y、yes、1、false、n、no、0。

設定

説明

GroupName

型: テキスト

(エミュレータ定義をグループ化し、グループ内の1つのロードのみを許可します

型: テキスト

DisplayName

型: テキスト

コマンドラインで他のMHOプロセスに対して内部的に使用されます

RegistryName

型: テキスト

確認するINIファイル名を指定します。

Windowsディレクトリが最初に検索され、次にPATH変数が検索されます。

この値が指定されている場合、RegistryLocはセクション名を指定し、ValueNameはセクション内のエントリ名を指定し、省略できません。

特別な値:

WinIni ? Windows INIファイルを確認する必要があることを示します。

RegistryLoc

型: テキスト

レジストリの場所のパス(関連項目: RegistryName、ValueName)

HKEY_LOCAL_MACHINE\Softwareツリー内でValueNameを検索するレジストリの場所を指定します。

特別な値:

\HKEY_CURRENT_USER\Software\”? エントリがこのテキスト(大小文字を区別)で開始している場合、HKEY_LOCAL_MACHINE\SoftwareのかわりにHKEY_CURRENT_USER\Softwareが検索されます。

ValueName

型: テキスト

レジストリ・キー名(関連項目: RegistryName、StripFileName、DLLFile)

DLLFileの場所を指定したレジストリまたはセクション名を指定する値。

RegistryLocを省略すると、この値はDLLFileフォームをロードする場所を直接指定します。

特別な値:

WinDir ? Windowsディレクトリからdllをロードします。

SysDir ? Windowsのシステム・ディレクトリからdllをロードします。

HomeDir ? Logon Managerのインストール・ディレクトリからdllをロードします。

EmulDir ? Logon Managerのエミュレータのインストール・ディレクトリからdllをロードします。

“\” ? パスがこの値で開始する場合、Windowsがインストールされているドライブ上の指定されたディレクトリからdllをロードします。

DLLFile

型: テキスト

ロードするdllの名前。

StripFileName

型: ブール

取得したレジストリ文字列からファイル名を削除します。

PresentationSpaceSharing

型: 特殊

エミュレータをスーパーバイザ・モードにするSUPER_WRITE(これをサポートしないエミュレータもあります)

Process

型: 特殊

sharedはエミュレータをmhoの元のコピーにロードします。その他のものおよび新しいプロセスが生成されます。

ConvertPosType

型: 特殊

long、short - Convert PositionおよびConvert RowCol (99)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

QuerySessionsType

型: 特殊

long32、long、short、both ? shortおよびlongは、Query Sessions (10)関数に標準または拡張HLLAPIインタフェースを使用します。bothは最初に拡張HLLAPIインタフェースの使用を試行し、拡張が失敗した場合は、次に標準の使用を試行します(常に機能するわけではないため、正しい値を指定することが望ましいです。) long32は、Windowsコマンド・プロンプトHLLAPIエミュレーションに使用されます。

デフォルト: HLLAPIType設定。

ValidateQuerySessionsData

型: ブール

QuerySessionsから返されたデータを使用する前に検証します。

QuerySessionStatusType

型: 特殊

long、short - Query Session Status (22)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

QueryHostUpdateType

型: 特殊

long、short - Query Host Update (24)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

StartNotificationType

型: 特殊

long、short - Start Host Notification (23)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

PlatformSize

型: 数値

16、32 ? 16ビットまたは32ビットのHLLAPI。

デフォルト: 32

IntSize

型: 数値

16、32 ? エミュレータによって使用される整数のサイズ。

デフォルト: 32

QuerySystemType

型: 特殊

long、short - Connect Presentation Space (20)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

UpdateNotificationHandling

型: 特殊

更新通知が発生したときの戻りコードの特別な処理。

?例:

? 1.ReconnectSession

?戻りコード1に対して、内部関数ReconnectSessionを呼び出します

?使用可能な関数:

? RecheckResetConnection - リセットを呼び出し、ログインを再試行します

? CheckLoginStatusAndReset - 保留中のログインがない場合、HLLAPIサブシステムをリセットします

? ReconnectSession - セッションへの接続を試行します

? FirstLogin - 最初の接続時に画面が変更したことの承認を、一部のエミュレータが拒否します

? StartNotification - 現在のセッションへのログインを試行します

WindowClass

型: regexlist

セミコロン区切りの正規表現のリスト。

ウィンドウ・クラスのマッチング。正規表現を含みます。部分文字列に一致します。

WindowTitle

型: regexlist

セミコロン区切りの正規表現のリスト。

ウィンドウ・タイトルのマッチング。部分文字列に一致します。

特別な値:

$s ? セッションの短縮名で代替されます。代替は、正規表現マッチングの前に発生します。

UseSendKeys

型: regexlist

エミュレータへのキーストロークの送信に、HLLAPIのCopy String to Presentation Space (15)ではなく、HLLAPIのSend Key (3)を使用します(WindowsのSendKeysと混同しないでください)

QuerySystemRequired

型: ブール

リセットの実行前にシステムが問合せされることを確認します。

ChangeNotiticationBroken

型: ブール

一部のエミュレータは、変更通知を実装しませんでした。

RequireVisibleWindow

型: ブール

ウィンドウが非表示の場合はログインしないでください。

EmulatorFixedRowWidth

型: ブール

一部のエミュレータは、行の幅を決定できません。

HllapiExportedCallName

型: テキスト

DLLのエクスポート済関数名。hllapiではない場合に必要です。

LogonUsingTimeout

型: 数値

ログオン画面が表示されるまで待機する時間(ミリ秒)。

デフォルト: 1000

LoginDelay

型: 数値

最後の試行の後、このミリ秒の時間よりも早くログインしないでください。

デフォルト: 1

WinHLLAPIStartup

型: バージョン

指定した場合、DLLのロード後、指定した要求バージョンでWinHLLAPIStartupを呼び出します。dllのアンロード前にWinHLLAPICleanupを呼び出します。

呼出しに失敗すると、dllはロードされません。

例: 1.0または1.1

HllapiParamCommand

型: ブール

エミュレータは、すべての設定が渡されることを要求します

IgnoreErrorCount

型: ブール

いくつかのエラーの後、リセットが必要なエミュレータもあれば、[true, false]を実行した場合に動作を停止するエミュレータもあります

SupportsHwnd

型: ブール

HLLAPI仕様のLogon Manager拡張。SsoConNTおよびSSoConCP [true, false]にのみ実装されます

HLLAPIType

型: 特殊

long、short ? すべてのHLLAPI関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: short

ConnectSessionType

型: 特殊

long、short - Connect Presentation Space (5)関数に、拡張または標準HLLAPIインタフェースを使用します。

デフォルト: HLLAPIType設定。

フォームの検出のトラブルシューティング

「Logon Using Logon Manager」トレイ・アイコン・オプションの起動時にエージェントはフォームを検出しますか

・エージェントがウィンドウを検出する場合、エミュレータの構成データがmfrmlist.iniファイルから欠落しているか、誤りがあります。mfrmlist.iniファイルの内容の理解および編集の手順は、「エミュレータ構成の表示および変更」を参照してください。

・エージェントのトレイ・アイコンから「Logon Using Logon Manager」オプションを使用して手動で検出を呼び出したときでさえ、エージェントがターゲット・ウィンドウを検出しない場合、次の手順を実行してください:

o フォーム定義の「Options」タブにある「Auto-recognize」オプションが有効になっていることを確認します。

o テンプレートで、ウィンドウ・タイトルやクラスの入力ミスなどの一般的な構成エラーがないかを確認し、また、ウィンドウ・タイトルまたはクラスが動的であるかどうかも確認し、テンプレートを適切に再構成します。

エミュレータの有効なエントリがmfrmlist.iniに存在しますか

エミュレータがオラクル社によってテストされ、Logon Managerと互換性があるとわかった場合、初期状態でLogon Managerによってサポートされており、mfrmlist.iniファイルにそのエミュレータの対応するエントリが存在します。現在サポートされているエミュレータのリストは、最新のLogon Managerのリリース・ノートにあり、「エミュレータ構成の表示および変更」の説明に従って、問題のエミュレータのエントリをmfrmlist.iniファイル内で探しても確認できます。

注意: リストにないエミュレータをmfrmlist.iniファイルに追加し、Logon Managerで完全に動作することがわかった場合、次のリリースのOracleでそのエミュレータに対する正式サポートを含めることを検討できるように、エミュレータの名前およびバージョンをOracleサポートに送信してください。

「Host/Mainframe Support」のグローバル・エージェント設定が無効化されていますか

Logon Managerの構成に以前加えた変更が、「Global Agent Settings」a「End-User Experience」a「Response」a「Host/Mainframe Apps」の下のLogon Manager Administrative Consoleツリーの下にある「Host/Mainframe Support」グローバル・エージェント設定を誤って無効化していないかどうかを確認します。オプションが無効化されている場合、再び有効にして、必要に応じて変更をリポジトリに公開します。

一致テキスト、フィールド・テキストおよび対応する座標は正しいですか

テンプレートに格納されている一致テキスト、フィールド・テキストおよびそれぞれの座標が、アプリケーションによって表示されるものと一致しているかを確認し、不一致があった場合は修正します。詳細は、「フォームの検出とレスポンスの理解」を参照してください。

エミュレータのHLLAPI実装は最新で、有効になっていますか

場合によっては、エミュレータの最初のHLLAPI実装が不完全であるか欠陥があることがあります。可能な場合は、エミュレータのLogon Managerとの互換性を改善する方法で、エミュレータのHLLAPI実装を改善または拡張するベンダーの更新を調査して適用することをお薦めします。また、エミュレータのHLLAPIサポートが有効であり、エミュレータがHLLAPIを介してセッション短縮名を公開していることを確認します。そうでない場合は、Logon Managerはエミュレータ内でセッションを検出できません。

エミュレータのHLLAPI実装のレベルの詳細、およびその構成手順は、エミュレータのベンダーにお問合せください。コンソール・ヘルプでも、最も一般的に使用されるエミュレータのHLLAPIサポートを有効にするヒントが提供されます。

適切なメインフレーム・サポート・コンポーネントがインストールされていますか

HLLAPIを介してターミナル・エミュレータとインタフェースするために、Logon Managerでは「Mainframe Support」(Logon Managerインストーラの「Extensions」ノードで入手可能)がインストールされている必要があります。さらに、ご使用のエミュレータによっては、そのエミュレータでLogon Managerを完全に有効にするために追加のヘルパー・コンポーネントをインストールする必要があります。(これらのヘルパー・コンポーネントの詳細は、「フォームの検出とレスポンスの理解」を参照してください。)

エージェントが引き続きフォームを検出しない場合、「SSO MHOステータス・ツールでの検出およびレスポンスのトラブルシューティング」を参照してください。

フォームのレスポンスのトラブルシューティング

エージェントはフォームを検出しますか

エージェントがフォームを検出しない場合、「Auto-Recognize」機能が無効化されていないか確認し、無効化されている場合は再び有効にします。機能が無効化されていない場合は、「フォームの検出のトラブルシューティング」を参照してください。

エージェントは資格証明を注入しますが、送信はしませんか

資格証明が注入されるが、自動的に送信されない場合、まず「Auto-Submit」オプションがアプリケーションで有効になっていることを確認します。これにより、エージェントは、デフォルトのsubmitアクションとして[Enter]キーストロークを送信します。「Auto Submit」が有効であるがエージェントがアプリケーションへの送信を行わない場合、アプリケーションは資格証明を送信するために[Enter]以外の特別なキーストローク([PF4]など)を要求する場合があります。そのような場合は、「Auto Submit」機能を無効にし、「ログオン・シーケンスへのキーストローク、一時休止またはテキストの追加」の説明に従って、特別なキーストロークをログオン・シーケンスに追加します。

[Enter]キーストロークがログオン・シーケンスに明示的に追加されましたか

[Enter]キーストロークをログオン・シーケンスに明示的に追加しており、アプリケーションがログオン中に誤った動作をする場合、ログオン・シーケンスから[Enter]キーストロークを削除します。「Auto Submit」機能が有効であると、エージェントは、追加された明白な[Enter]キーストロークとともに、デフォルトのsubmitアクションとして[Enter]キーストロークを自動的に送信し、アプリケーションは、[Enter]キーストロークを予期していた1つではなく2つ受け取り、これによってログオン後に望ましくない動作が発生します。

フィールドへの移入が不安定ですか

エージェントによるフィールドへの移入が不安定(誤った値、切り捨てられた値、文字化けした値または空白の値を取り込むなど)なときは、テンプレートで定義されたフィールドの座標が正しいか確認して(エミュレータに示される実際の表示と比較して)、正しくない場合は修正します。座標が正しい場合、「ログオン・シーケンスへのキーストローク、一時休止またはテキストの追加」の説明に従って各アクションの後に一時休止を追加します。一時休止を追加した後も引き続き問題が発生する場合は、「SSO MHOステータス・ツールでの検出およびレスポンスのトラブルシューティング」を参照して、障害の場所を特定します。

ログオン・ループのトラブルシューティング

ログアウト後のフォームは、標準ログオン・フォームと異なりますか

ログアウト時に表示されるログオン・フォームがアプリケーションの標準のログオン・フォームと十分に異なっている場合は、マッチングだけでなく「Logon Loop Grace Period」を検討することをお薦めします。

フォームを一意に区別できない場合は、以降で説明するログオン・ループ猶予期間機能を使用します。

「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

ログオン・ループ猶予期間タイマーを構成するには、次の手順を実行します:

1. Logon Manager Administrative Consoleで目的のテンプレートを開き、「Miscellaneous」タブを選択します。

2. 「Logon Loop Grace Period」フィールドで、ドロップダウン・リストから目的の操作モードを選択します。

3. 猶予期間が有効なときにエージェントに実行させる内容に応じて、次のいずれかを実行します:

4. 変更を保存してリポジトリにコミットします(該当する場合)。

この方法でもアプリケーションのログオン・ループが解決されない場合は、Oracleサポートに連絡してください。

SSO MHOステータス・ツールでの検出およびレスポンスのトラブルシューティング

MHOによって、MHOとターミナル・エミュレータの対話を示すリアルタイム情報を表示するHLLAPIステータス・インタフェースが提供されます。このインタフェースを表示するには、MHO実行可能ファイル(ssomho.exe)を/showmhoスイッチを付けて実行します:

<program_files_folder>\Passlogix\v-GO-SSO\Helper\Emulator\ssomho.exe /showmho

正確な構文を覚えなくても、このツールをいつでも簡単に起動できるように、ツールへのデスクトップ・ショートカットを作成することを強くお薦めします。

注意: MHOは、システム上のアクティブなHLLAPIインタフェースが1つも検出されない場合、リソースの節約のために停止し、これによってトラブルシューティング・プロセスに障害が発生する場合があります。MHOの実行を継続させるために、「DOS Window Support」コンポーネント(「フォームの検出とレスポンスの理解」で説明しています)をインストールし、これにより、アクティブなHLLAPIインタフェースが常にMHOに対して公開されます。

MHOステータス・ツールのインタフェースの理解

MHOステータス・インタフェースは次のようになります:

インタフェースは次のセクションで構成されます:

・ 「HLLAPI DLL Status」ペイン ? mfrmlist.ini ファイルに存在するすべてのエミュレータ・エントリ、および関連付けられたHLLAPIインタフェースのステータスを表示します: o 「Running」 ? エミュレータのインタフェースが検出され、MHOによって接続されています。「Running」ステータスのノードを展開すると、検出されたセッションが表示されます。前述の例では、NetManage Chameleon Hostlinkエミュレータがこの状態です。

・ 「Not loaded」 ? エミュレータのインタフェースはMHOによって検出されませんでした。このノードを展開して、エミュレータ・ノードの下のサブノードとしてロード障害が表示される理由を表示します。一般的な理由には次のものがあります:

o 「Registry path not found」 ? エミュレータのHLLAPI動的リンク・ライブラリ(DLL)へのパスを定義するレジストリ・キーが、mfrmlist.ini ファイルで指定された場所に見つかりません。エミュレータのベンダーに問い合せてこのパラメータの正しい値を取得し、エミュレータに対するmfrmlist.iniファイルのエントリを変更してこの問題を修正します。前述の例では、IBM Personal Communicationsエミュレータがこのエラーを示しています。

o 「DLL failed to load」? エミュレータのHLLAPIライブラリが、前述のレジストリ・パスで指定された場所に見つからなかったか、または指定された場所に存在するファイルが破損しておりMHOによって接続できません。前述の例では、Seagull BlueZoneエミュレータがこのエラーを示しています。

・ ログ・データ・ペイン ? このペインは、MHOと「HLLAPI DLL Status」ペインで選択したエミュレータ間の対話を示すリアルタイム情報を表示します。

ログ・データ・ペインの上のチェック・ボックスは、次のクラスのイベントの表示を有効または無効にできます:

・ 「HLLAPI」 ? MHOと検出されたエミュレータ・インタフェース間のすべてのHLLAPI通信。これは常に選択したままにしないと、ログ・データが取得されません。

・ 「Emulator」 ? ユーザー入力やウィンドウのインスタンス化などのエミュレータ・イベント。

・ 「QuerySessions」 ? 開いているセッションのリスト、検出したセッションの短縮名など、セッション関連のイベント。

・ 「Screens」 ? エミュレータの表示の内容。MHOが画面更新イベントを受け取るたびに(ポーリングが有効な場合は検出するたびに)、更新画面の内容が取得されます。

・ 「MatchData」 ? テンプレートに定義された一致テキストに対して試行された一致、およびその試行の結果。

ログ・データ・ペインに表示される情報はすばやくスクロールされるため、何か気になるものがあったときは、「Pause」チェック・ボックスを選択して一時的にデータ取得を停止し、そのデータをさらに分析するためにテキスト・エディタにコピーします。

MHOステータス・ツールを使用したセッションの検出およびレスポンスの診断

メインフレーム・アプリケーション・テンプレートを作成したがLogon Managerがターミナル・セッションを検出しない場合、最も一般的な原因は次のとおりです:

・ エミュレータがHLLAPIを介してセッション短縮名を公開していません。Logon Managerはセッション短縮名を
使用してセッションを検出し、テキスト・マッチングを開始します。一部のエミュレータでは、セッション短縮名をグローバルまたはセッションごとに公開する明白な構成が必要です。この場合、エミュレータは「HLLAPI DLL Status」ペインに「Running」としてリストされますが、エミュレータのノードを展開しても、アクティブ・セッションが(そのエミュレータ自体において接続された場合でも)表示されません。この必須機能を有効にする方法の詳細は、ベンダーのドキュメントを参照してください。

・ エミュレータのHLLAPIサポートが無効化されているか、インストールされていません。この場合、エミュレータは「HLLAPI DLL Status」ペインに「Not loaded」としてとしてリストされ、そのノードを展開すると、前の項で説明した「Registry path not found」または「DLL failed to load」エラーのどちらかが表示されます。HLLAPIサポートの有効化またはインストールの方法の詳細は、ベンダーのドキュメントを参照してください。

・ エミュレータのコードに不具合があるか、またはコードがHLLAPIに準拠していません。 ベンダーに問い合せて、使用可能な更新があるか確認してください。たとえば、エミュレータが「HLLAPI DLL Status」ペインで「Running」として表示されており、そのノードを展開すると検出したセッションが表示される場合でも、ログ・データ・ペインで有効なすべてのイベント・タイプについて、画面更新イベントまたはセッション関連情報(セッションの開始や終了など)が表示されません。


	Oracle® Enterprise Single Sign-On Logon Manager Logon Managerアプリケーション・テンプレートの構成と診断リリース11.1.2.1.0 B71101-02(原本部品番号:E27165-03) 2013年3月

関連ドキュメント

ウィンドウ検出の理解

サポートされるフォーム・レスポンス方式

コントロールID

?SendKeys

コントロールIDとSendKeys

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

ターゲット・ウィンドウは非一意ですか

フォームのコントロールIDは非一意または動的ですか

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

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

ログオン・フォームとは異なるタブにパスワード変更フォームはありますか

フォームのコントロールIDは非一意または動的ですか

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

アプリケーションでパスワード変更の成功または失敗のダイアログ(あるいはその両方)を表示しますか

フォームの構成

コントロールIDを使用したフォームの構成

空白または動的値のマッチング

ウィンドウ・タイトルのマッチング

ウィンドウ・クラスのマッチング

実行可能ファイル名のマッチング

フィールド、コントロールまたはテキスト文字列のマッチング

サービス・ログオンとしてのアプリケーションの構成

自動SendKeysフォールバックの無効化

パスワード変更フォームの構成のテスト

新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

リポジトリへのテンプレートの公開

ウィンドウ検出のトラブルシューティング

サービスまたは現行ユーザー以外のユーザーでアプリケーションを実行していますか

コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

ジャーナル・フックを使用するSendKeysに切り替えると、注入の信頼性が回復しますか

マッチングのトラブルシューティング

フォームのコントロールIDは非一意または動的ですか

ログオン・ループのトラブルシューティング

ログアウト後のフォームは、標準ログオン・フォームと異なりますか

「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

Javaアプリケーションの問題のトラブルシューティング

JHO包含ルール

JHO除外ルール

許可されるJava Runtime Environment (JRE)バージョン

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

Webフォームの検出の理解

URL検出の理解

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

フィールド検出の理解

検出マッチングの理解

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

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

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

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

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

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

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

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

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

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

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

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

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

フォームの構成

コントロールID方式を使用したフィールドまたはコントロールの構成

SendKeys方式を使用したフィールドまたはコントロールの構成