IBM® Rational® ClearQuest® では、VBScript か Perl のいずれかを使用したカスタム フック コードの作成をサポートしています。ただし、パフォーマンスと機能のトレードオフを考慮して、スクリプト言語、フック内で使用する操作のタイプを選択するべきです。このトピックに関して十分に議論が尽くされているわけではありませんが、どのスキーマ変更についても、以下のガイドラインを適用すべきです。Rational ClearQuest スキーマのパフォーマンスについて、 詳しくは IBM developerWorks® Web サイトを参照してください。
混在するクライアント プラットフォームをサポートする Rational ClearQuest システムの場合、New Rational ClearQuest Web を使用することにはパフォーマンス上の利点があります。
新規 Rational ClearQuest Web は、Windows®、UNIX® システム、または Linux® システムに展開できます。
すべての Rational ClearQuest Windows クライアント (Rational ClearQuest Web サーバーを含む) は、 VBScript か Perl のいずれかで記述されたフックを実行できます。ただし、UNIX システム、または Linux の Rational ClearQuest クライアントは、Perl スクリプトのみ実行できます。したがって、Rational ClearQuest の展開で、UNIX システムまたは Linux のクライアントが必要な場合、フックを Perl で記述する必要があります。
一般的に、データベースへのアクセスは、フックが実行する操作のうち最も時間のかかる操作です。データベース アクセスを必要とする操作の例には、次のものがあります。
エンティティ (レコード) の取得には、プライマリ レコードを照会するデータベースのクエリーを少なくとも 1 つと、各 REFERENCE_LIST フィールドを照会する 1 つ以上のクエリーを必要とします。エンティティは、GetEntity または LoadEntity のようなセッション メソッドによって明示的に取得されますが、REFERENCE フィールドのフィールド値にアクセスして暗黙的に取得することもできます。 次の例は、product フィールドによって参照されるエンティティが暗黙的にロードされ、次に、ロードされた product レコードから component フィールドの値が取得されるものです。
$component = $entity->GetFieldValue("product.component")->GetValue();
エンティティをロードする時間は、スキーマの複雑さ、主に、選択されたエンティティの参照リスト フィールドの数によって決まります。多くの場合、エンティティのフィールドのうち一部のフィールドのみが必要なので、それらのフィールド値を照会するほうが、エンティティ全体を取得するよりも効率的です。
エンティティ レコード全部を取得するより効率的ですが、クエリーは、データベース アクセスを必要とするので、全体的なスキーマ パフォーマンスに影響を与えることになります。あらゆる手段を講じて、データベースとのやり取りの回数を最小化するべきです。例えば、フック コード内のさまざまな場所で同じクエリーを複数回実行するよりも、クエリーを一度だけ実行して、ResultSet 値を 1 つのセッション変数にキャッシュすることができます (VBScript の場合)。 また、それぞれのレコードごとに重要なフィールドのみを取得するようにします。クエリー結果セット内で複数行にわたるテキスト フィールドを指定すると、それぞれのテキスト フィールドを取得するためのデータベースとのやり取りが追加で必要になるので、そのような指定を避けます。
選択リストのプロパティで [選択リストを再計算] オプションを選択すると、レコードのほかのフィールドで値が変わるたびに、有効な選択リストの再移植に必要なフック コードが実行されます。 これは、データベースとの不要なやり取りのため大量のクエリー トラフィックの原因となる可能性があります。選択リストが有効であることを確認にするためのより効率的な方法は、この選択リスト内の値に影響を与える可能性のあるその他のフィールドを判別し、それらのフィールドの値が変わった場合のみ選択リストが再計算されるように強制することです。
例えば、自動車を表す Automobile レコードにデータを収集する場合、自動車の製造会社を表す Manufacturer フィールドと、モデルを表す Model フィールドがあると想定します。Model フィールドの有効な選択リストは、選択された Manufacturer のみに依存します。 Model フィールドに対して [選択リストを再計算] を選択することは、このフィールドの選択リストが常に有効であることを確認する上で非効率な方法です。 代わりに、Manufacturer フィールドにフィールド値変更フックをコーディングできます。これにより、Model フィールドの選択リストは無効化されます。 このメソッドの使用法について、詳しくは「InvalidateFieldChoiceList 例」を参照してください。
フックのカスケードは、いくつかのフィールド間の依存関係またはネストされた関係によって発生します。このセクションで前に説明した、自動車の Manufacturer と Model の依存関係を考えてみてください。 この例を拡張して、Model が選択されると、Body Style、Color、Engine のいずれかの有効な選択リストが変わるものと想定します。 フォーム上の 1 つのフィールド値の変更によって、ほかのフィールドのために実行および再実行されるフックのカスケードがどのように発生するかを調べるのは簡単です。ネストされたこれらのフィールドの関係の深さを最小化し、スキーマのインプリメンテーションではフック コードの不要な実行や余分な実行を避けるように注意する必要があります。例については、GetFieldStringValues メソッドとその他の関連メソッドを参照してください。
AdminSession オブジェクトの取得は、パフォーマンスに影響を与え、データの取得については代替手段がある可能性があります。 例えば、AdminSession オブジェクトと、その下にある User オブジェクトと Group オブジェクトのメソッドを使用してユーザー情報またはグループ情報を取得する代わりに、ユーザー データベース内にある User レコードと Group レコード (状態なしレコード タイプ) を照会するクエリーを作成することが可能です。