前提条件
独自のルールを定義するには、以下の条件を満たす必要があります。
• 電子メール通知ルールとシステム全体のトリガ権限を持っている。
• SQL、特に WHERE 句の書き方を熟知している。
• データベース スキーマ、特に問題に関連するテーブル IM_Defect および IM_DefectHistory の列を熟知している。
• ワークフローとワークフローで使用される値を熟知している。
構文的にも意味的にも正しい WHERE 句を書く上で役に立つ重要なヒントを、ここでいくつか紹介しておきましょう。
IM_Defect と IM_DefectHistory 双方への参照
SQL WHERE 句には、おそらく IM_Defect テーブルと IM_DefectHistory テーブル双方への参照が必要になるでしょう。IM_Defect テーブルには、問題の最新情報が格納されるのに対して、IM_DefectHistory テーブルには、問題に対して取られたすべてのアクションのほか、それらの変更の結果、問題のいくつかのフィールドにどのような影響があったかが記録されます。
たとえば、IM_DefectHistory には、アクションが取られる前と後の問題の受信箱割り当てが格納されます。これらの列は、アクション実行前の受信箱割り当てについては AssignedIN、新しい受信箱については AssignedOUT です。
問題に対して取られたアクションはすべて、IM_DefectHistory テーブルの ActionCode フィールドに記録されます。これらのアクションは、[履歴] タブの [アクション] 列にアクション コードとして表示されます。たとえば、サンプル データベースでは、"解決" や "検証済み" といったコードが表示されます。
自分のデータベースで使用されているアクションの大半について、そのアクション コードを確認するには、各状態の [状態 "<状態名>" のアクションの編集] ダイアログを開きます（"入力"、"再割り当て"、"変更" はハードコードされていて表示されないので除きます）。ある状態の [状態 "<状態名>" のアクションの編集] ダイアログにアクセスするには、[設定｜ワークフロー] ページを開き、[ボタン ラベル] 列に表示されているアクション名をクリックします。[履歴アクション コード] フィールドの値を確認します。
テーブルにはエイリアスが定義されています。IM_Defect テーブルを参照するにはエイリアス D を、IM_DefectHistory を参照するにはエイリアス DH をそれぞれ使用する必要があります。
IM_Defect テーブルでは、カスタム フィールドは、タブ上の位置によって Custom1、Custom2 などで識別されます。各カスタム タブにはフィールドが最大 10 個あります（1 〜 10 と 11 〜 20）。[カスタム タブ 1] では、最初の 5 つのフィールドが左側の列に降順に表示され、フィールド 6 からフィールド 10 までが右側の列に降順に表示されます。
個々のカスタム フィールドのスキーマ名を調べるには、[設定｜問題のカスタム タブ] を選択します。たとえば、サンプル データベースのダイアログでは、[カスタム タブ 1] の左列の第 4 フィールドが [リリース ノートに追加する] チェック ボックスになっており、これは問題テーブルの Custom4 に当たります。
メモ： カスタム フィールドの位置を変更した場合、そのフィールドを参照している電子メール通知ルールをすべて更新する必要があります。
カスタム フィールドの変更は追跡の対象外
Issue Manager では、IM_DefectHistory テーブル内のカスタム フィールドの変更を追跡しません。カスタム フィールドの現在の値を確かめることはできますが、以前の値を参照することはできません。たとえば、WHERE 句では、[リリース ノートに追加する] チェック ボックスが選択されているかどうかを検査することはできますが、そのチェック ボックスの値がオフからオンに変化したのを捉えることはできません。
選択されていないチェック ボックスの値は '.'（ピリオド）です。選択されているチェック ボックスの値は 'X'（大文字の X）です。
たとえば、[リリース ノートに追加する] チェック ボックスがオンの問題をすべて取得するには、WHERE 句の一部に以下のように指定します。
D.Custom4 = ‘X’
ここで、ルールを新規作成する状況を 4 つ紹介しましょう。最初の 2 つの状況は、個々の問題のトリガでルールが使用される場合です。後の 2 つの状況は、システム全体のトリガでルールが使用される場合です。各例の後に、サンプル データベースを対象とした WHERE 句を示します。
Technical Support などのグループは、特定のバグ修正がいつ修正済みと確認されたかを知る必要があります。
この場合、WHERE 句は以下のようになります。
DH.ActionCode = '検証済み'
IM_DefectHistory テーブル内の ActionCode の値はユーザーがアクションを取るたびに更新されるので、Technical Support グループは、"検証" アクションの結果、アクション コード "検証済み" が IM_DefectHistory テーブルと [履歴] タブに入力されたときに 1 回だけ電子メールを受信します。
代わりに、理由コード（データベースでは Disposition 列）への参照を使ってこの句を書いた場合、以下のようになります。
D.Disposition = '解決'
この場合、データベースでは理由コードが "解決" のままなので、Technical Support グループはほぼ間違いなく複数回電子メールを受け取ることになるでしょう。その後ユーザーが問題にコメントを追加したり問題を保存しても、ルールがやはり一致するので、電子メールがトリガされることになります。
例 2
平均的なユーザーは自分ではバグに対処しないので、自分の報告したバグがどうなったかを知りたくなる場合があります。特に、バグが開発者の注意を引いたときに電子メールを受け取りたいと思います。ワークフロー的に言えば、これは問題がちょうど "開発準備完了" 状態を抜けたことを意味するので、WHERE 句では、アクション実行後の状態変化を検査する必要があります。
この場合、WHERE 句は以下のようになります。
DH.StatusIN = '開発準備完了'
AND DH.StatusOUT <> '開発準備完了'
アクションの実行前は "開発準備完了" 状態でしたが、開発者がアクションを取った後、バグは別の状態に移行しました。
例 3
ドキュメント部門では、Issue Manager のドキュメント関連の問題をすべて、ユーザーの受信箱 "Judy -- Doc" ではなくグループの受信箱 "Doc (Product A)" に送ってもらっています。ドキュメント管理者は、グループの受信箱に問題が入ったときに電子メールを受け取りたいと考えています。
この場合、WHERE 句は以下のようになります。
DH.AssignedIN <> ‘Doc (Product A)’
AND DH.AssignedOUT = ‘Doc (Product A)’
これは、アクション実行前には "Doc (Product A)" でなかった 受信箱がアクション実行後には "Doc (Product A)" になったときに電子メールを送信するように指定しています。電子メールは、ドキュメント関連の問題が "Doc (Product A)" に送られたときに 1 回だけ送信されます。
なお、ｌWHERE 句の最初の部分がなければ、ドキュメント関連の問題が "Doc (Product A)" に割り当てられている段階でも、それに対して何かアクションが取られたらドキュメント管理者が電子メールを受信することになります。トリガをシステム全体に適用する必要があるので、このルールは大量の電子メールを生成しそうですが、WHERE 句の 2 行が相まってルールを単一のイベント、すなわち受信箱が "Doc (Product A)" になったときに制限しています。
ルールでは、問題の種類を "ドキュメントの問題" に限定して指定する必要がないことにも注意してください。"Doc (Product A)" はドキュメント関連の問題だけを保持しているので、それでも不正確にはなりません。
例 4
Issue Manager のリリース マネージャは、メジャー リリース前の来月一杯、修正できない最も深刻なバグに関する電子メールを受け取りたいと考えています。WHERE 句では、深刻度、"Product B"、そして開発者が "解決不能" アクションを取ったときに割り当てられる "解決不能" アクション コードを検査する必要があります。
この場合、WHERE 句は以下のようになります。
D.Severity = '1:Fatal/Data Loss'
AND DH.ActionCode = '解決不能'
AND D.ProductCode = 'Product B'
これらの制約がすべて必要なのはなぜでしょうか。深刻度はユーザーが明示的に変更するまで変わらないので、WHERE 句で深刻度だけを検査した場合、問題が変更され保存されるたびにルールが一致します。
特にこのルールがシステム全体のトリガで適用された場合、リリース マネージャは、大量の電子メールを受け取る可能性があります。ただし、リリース マネージャはリリース サイクルが終了した後でトリガを容易に削除することができます。
WHERE 句の書き方のヒント
一般的なものから特定のものへと取り組みます。
まず、電子メール通知ルールが必要になりそうな一般的なビジネス状況を検討します。問題に関する電子メールをいつ受け取りたいかを Issue Manager ユーザー全員に尋ねてみてもよいでしょう。各ユーザーがその電子メールからどのような情報を収集したいと思っているかを正確に把握します。たとえば、ユーザーは、バグがいつ修正されたかを知りたいと言うかもしれません。さらに話を聞いてみると、本当は、修正がいつ QA エンジニアによって検証されたかを知りたいのだということがわかるかもしれません。このわずかな変化で、必要な WHERE 句が変わる可能性があります。
次に、ユーザーの希望を十分理解したと思ったら、その状況を、所属組織のワークフローの言葉に翻訳します。
最後に、SQL WHERE 句を作成します。高度なクエリを通じて WHERE 句をテストしてみて、ちょうど意図したとおりに条件を指定しているかどうかを確かめます。高度なクエリの作成の詳細については、『SilkCentral Issue Manager オンライン ヘルプ』を参照してください。
一般的に言えば、個々の問題に関するトリガを対象としたルールは簡単かつ包括的なものとして作成しなければならないのに対して、システム全体のトリガ向けのルールは、過剰な電子メールを避けるためにできるだけ正確かつ限定的なものにしなければなりません。
ユーザーが希望する電子メールのトリガ頻度（1 回だけなのか、変化が生じるたびか）について自問します。ユーザーが 1 回だけの電子メール通知を希望する場合は、ルールをより限定的なものにします。