例えば、チーム・メンバーのそれぞれに割り当てられている作業を定期的にクエリーするとします。チーム・メンバーごとにクエリーを作成することもできますが、その場合、互いに多少の違いしかない複数のクエリーが作成されることになります。 それよりも有効な選択肢は、プロンプト・クエリーを使用して、例えば「user に割り当てられたシステム ABC の障害」というように、異なる部分をパラメーター化することです。 このクエリーを開始すると、チーム・メンバーのリストが表示されます。
プロンプト・クエリーの定義には、プレースホルダーが使用されます。プレースホルダー・キーワードは、クエリー内で、ユーザーがクエリーを実行するたびに入力する場所です。 例えば、あるユーザーがチーム・リーダーとなっていて、そのチームには Tom、Jane、および Joe がいるとします。このユーザーは、以前は作業負荷について調べるために、個々のクエリーを実行していました。つまり、各チーム・メンバーに割り当てられた CR を個別にクエリーしていました。 現在このユーザーには、解決者の名前を求めるプロンプトを出した上で、その特定のチーム・メンバーに割り当てられている CR を表示する 1 つのクエリーを作成するという選択肢があります。
このクエリーを構成するには、特定の名前の代わりに、プレースホルダー・キーワードを使用します。プレースホルダー・キーワードは、%1、%2、%3 というように、%integer の形を取ります。プレースホルダー・キーワードの値は、クエリーを実行するプロセスの一環として、常にユーザーが提供しなければなりません。プレースホルダー・キーワードは、システムによって自動的に提供される標準のキーワードとは異なります。
プレースホルダー・キーワードと標準キーワード (例えば、%username) は、同じクエリー・ストリングに混在させることができます。プレースホルダーは、その固有のパターンによって認識されます。そのパターンとは、常に整数であることです。例えば、クエリーにパーセントを含める場合、%% はリテラル % 記号として解釈されます。keyword='%%1' と入力した場合、キーワード %1 を持つ CR が検索されます。単一の % (%1) は、クエリーを実行する前にユーザーが提供しなければならないプレースホルダーを示します。
プレースホルダーとして使用される整数の番号付けによって、プレースホルダーの値をユーザーに要求する順序が決まります。クエリー内で使用される整数の順序は、関係ありません。この例の場合、クエリー release='%2' and owner='%1' は、「所有者」の値を求めるプロンプトを出した後、「リリース」の値を求めるプロンプトを出します。
プレースホルダーは、同じクエリーのなかで再使用可能です。プロンプトが出されるのは、固有のプレースホルダーごとに一度だけです。システムは同じプレースホルダーの各オカレンスを同じ値で置き換えます。
プレースホルダーを指定するのに最も一般的な方法は、プロンプト・クエリーの既存の値を選択することです。クエリーで使用する情報に対応する属性名を選択します。例えば、CR が割り当てられているチーム・メンバーから選択します。このクエリーで使用する属性として、「解決者」を選択します。すると、システムはデータベース内のユーザー名を使用して、プロンプトを出します。これで、クエリー対象のチーム・メンバーを選択して、クエリーを実行できます。クエリーを再定義することなく、別のチーム・メンバーをクエリー対象として選択できます。
データベースに変更を加えると、属性はそれに応じて最新状態に維持されます。例えば、属性タイプがライフサイクル・エディターで変更されると、その属性を使用するプレースホルダーが自動的に更新され、その変更を反映します。
プレースホルダーを定義するときに、(「属性」ではなく)「型」を選択することで、カスタマイズ・プレースホルダーを作成できます。「型」を選択する場合には、プレースホルダーの入力形式をストリング、日付、またはリスト・ボックスのいずれかに定義します。この設定により、情報収集時のプレースホルダーの値が決まります。
例えば、カスタム・リスト・ボックスを作成できます。型として「リスト・ボックス」を選択し、プロンプトでリスト・ボックスの選択項目として表示する一連の値を入力します。 次に、プロンプト・クエリーを実行するたびにフリー・フォーム・ストリングを入力する代わりに、プレースホルダーの値として管理可能な選択項目一式をセットアップします。プレースホルダー・リスト・ボックスは、その作成対象とする特定のプロンプト・クエリーの特定のプレースホルダーにのみ使用されるため、共有されません。