フィールド フックとアクション フックの実行順序

フィールド フックとアクション フックは、 事前定義された時間に事前定義された順序で実行されます。

レコードが開いているときには、4 つのフック実行ポイントがあります。

アクション開始時に実行されるフック

データベースに変更をコミットする前、 または、ClearQuest® Web または RCP クライアントから検証が要求されたときに、Rational® ClearQuest ソフトウェアは 次の順序でフックを実行してレコードを検証します。

  1. Access Control アクション フックが、 ユーザー アクセスを検査し、ユーザーにアクションを開始する権限がない場合は アクションの処理を停止します。この場合、残りのフックは実行されません。

    パッケージを適用することによってスキーマに追加されるアクションも含めて、 アクションへのアクセス制御を修正することができます。ただし、Base アクション内に置かれたアクセス制御は、 他のすべてのアクションに適用されます。ネストされたアクションに対して、Access Control フックは実行されません。

  2. Permission フィールド フックが、各フィールドが必須、オプション、読み取り専用の いずれであるかを判定します。
  3. Initialization アクション フックが、アクションが開始する前に フィールド値の設定などの初期化タスクを実行します。
  4. Default Value フィールド フックが、各フィールドの値を設定します (Submit アクションの場合のみ)。
  5. Validation フィールド フックが、各フィールドの内容を確認します。 ただし、確認が発生しない Import アクションは除きます。Validation フィールド フックは、値を設定していない必須フィールドなど、存在しない値を確認することはできません。
  6. Choice List フィールド フックが、[選択リストを再計算] オプションを使用する 各フィールドに対して実行されます。依存フィールドが存在し、 そのフィールドの作成時に [選択リストを再計算] オプションを選択した場合、 まず Validation フィールド フックが実行され、次に各フィールドに対して Choice List フィールド フックが実行されます。 このフック実行は、変更したすべてのフィールドの設定と確認が終了するまで続きます。

    Value Changed フィールド フックが、Entity オブジェクトの SetFieldValue メソッドを呼び出す場合、SetFieldValue 関数が呼び出されるたびにそのフィールドに対する VALUE_CHANGED フックが実行されます。

ネストされたアクション

Access Control フックやすべての Notification フックの実行を含め、 ネストされたアクションの処理中は、実行されないフックがあります。詳しくは、『IBM Rational ClearQuest API リファレンス』の「アクションとアクセス制御」および「ネストされたアクションのフック」を参照してください。

フィールド値の設定時に実行されるフック

ユーザーがレコードを編集すると、次の順序でフックが実行されます。

  1. Value Changed フィールド フックが、変更された各フィールドに対して実行されます。

    [リストに制限] オプションがオンの場合、 ユーザーが不正な値を入力すると、そのフィールドは無効なフィールドとしてマークされます。ユーザーが有効な値を入力するまで次のフックは実行されません。

    別のフィールドの値を変更するために、Value Changed フィールド フックが SetFieldValue メソッドを 呼び出すと、そのフィールドに対して Value Changed フィールド フックが即時に実行されます。

  2. Validation フィールド フックが、各フィールドに対して実行されます。
  3. Choice List フィールド フックが、[選択リストを再計算] オプションを使用する 各フィールドに対して実行されます。

    [選択リストを再計算] オプションをオンにして 依存フィールドを使用する場合には、まず Validation フィールド フックが実行され、 次に各フィールドに対して Choice List フィールド フックが実行されます。 このフック実行は、変更されたすべてのフィールドの設定と確認が終了するまで続きます。

フィールド フックが実行されるのは、ユーザーが Submit アクションを開始したときだけです。 ただし、フィールドが依存フィールドを含むものとしてマークされている場合は除きます。「フックを使用した Web セッションの検出」を参照してください。

レコードの確認時に実行されるフック

データベースに変更をコミットする前に、Rational ClearQuest ソフトウェアでは 次の順序でフックを実行してレコードを確認します。

  1. Validation フィールド フックが、レコード内の各フィールドに対して実行されます。
  2. Validation アクション フックが、実行されたアクションに対して実行されます。

レコードのコミット時に実行されるフック

Commit フックが実行されるのは、 現在のレコードに対する変更でデータベースが更新された後ですが、 更新トランザクションがデータベースにコミットされる前です。したがって、Commit フックを使用して現在のレコードを 変更することはできません (例えば、Commit フックからフィールドを変更することはできません)。

Commit フックで行われる作業が完了するまでデータベースはロックされるため、 それらのロックによって、ほかのユーザーがクエリーの実行、新規レコードの作成、 既存レコードの修正を行えない場合があります。パフォーマンス上の理由から、Commit フック内で実行する作業は 最小化することをお勧めします。

Commit フックは、主要なアクションと同じデータベース トランザクションの一部として組み込む (ほかのレコードへの) アクションに対してだけ使用します (例えば、親レコードの障害が解決したときに重複レコードの障害も解決する場合)。適切な呼び出しを正しいコンテキストに置くようにしなければなりません。 例えば、Commit フックから Revert を呼び出したり、Commit フック以外のアクションから Commit を 呼び出したりしないようにしてください。

レコードの確認が終わると、 次の順序でフックを実行してレコードをデータベースにコミットします。

  1. Commit アクション フックが実行されます。
  2. トランザクションがデータベースにコミットされます。
  3. Notification アクション フックが実行されます。例えば、電子メール通知が さまざまなユーザーに送信されます。

詳細については、『IBM Rational ClearQuest API リファレンス』の「既存レコードの編集」を参照してください。


フィードバック