アクションは、
新規レコードをデータベースに登録したり、レコードをある状態から別の状態に遷移させたり、
レコードを修正または削除するためのメカニズムです。
ユーザーが、フォームの [アクション] ボタンをクリックするか、
ツール バーの [アクション] メニューを開くと、有効なアクションの
リストが表示され、デフォルト アクションが太字で強調表示されます。デフォルト アクションを定義するには、
状態のプロパティ ウィンドウの [デフォルト アクション] タブを
使用します。「デフォルト アクション」を参照してください。フックからデフォルト アクションを呼び出すこともできます。
ユーザーの権限とレコードの状態に基づいて、その時点で使用可能なアクションのみが表示されます。潜在的な
パフォーマンス上の問題を避けるため、Access Control フックは、有効なアクションを
確認するときには実行されません。
次のタスクを実行するアクションを定義できます。
- 新規レコードを作成してデータベースに追加する。
- レコード内の情報を修正する
(各フィールドに関連付けられた動作は、レコードの特定のフィールドのアクセスを制限することもできます。)
- レコードをある状態から別の状態に移動する。
- あるレコードを別のレコードの重複としてマークする。
- フックを実行する。
アクション フックでは、アクセス制御、初期化、確認、通知を処理できます。
「フックの追加によるアクションのカスタマイズ」を参照してください。
- レコードをデータベースから削除する。
どのユーザーがどのアクションにアクセスできるか、
いつアクションを実行できるかを制御できます。
Submit アクションや Change State アクションなど、
よく使用されるアクションのために事前定義されたアクション タイプが多数サポートされています。
「サポートしているアクション タイプ」を参照してください。
Designer には、各レコード タイプに、そのタイプのレコードが使用できるアクションを定義する
アクション グリッドがあります。アクション グリッドを使用して、アクションの追加、修正、削除が可能で、
状態遷移も作成できます。
サポートしているアクション タイプ
Rational® ClearQuest® ソフトウェアでは、
次のアクション タイプをサポートしています。
- アクション タイプ
- 説明
- Base
- Base アクションは、ほかのアクションの結果として 2 次的に実行されるアクションです。
Base アクションに作成できるアクション フックは 1 つですが、複数のアクションで
そのフックを使用できます。アクションが起動するたびに、Base アクションはフックの基準を満たしているかどうかを確認し、
基準を満たしている場合、Base アクションのプロセスは完了します。
例えば、Notification アクション フックを Base アクションに追加して、Close アクション (レコードを Closed 状態に
遷移させる Change_state アクション タイプ) が発生した際に、Base アクションに電子メール通知を
送信させることができます。
Rational ClearQuest クライアントのアクション リストに、Base アクションは表示されません。
Base アクションに
アクセス制御を設定すると、スキーマ内のすべてのアクションに影響します。パッケージを適用することによってスキーマに追加されるアクションも含めて、
アクションへのアクセス制御を修正することができます。ただし、Base アクション内に置かれたアクセス制御は、
他のすべてのアクションに適用されます。
- Change_state
- Change_state アクションは、状態ありレコード タイプでのみ使用可能です。
レコードを遷移元の状態から遷移先の状態に移行させます。
多くの遷移元の状態を参照できますが、参照できる遷移先の状態は 1 つのみです。
Change_state アクションは、現在のレコードが遷移元の状態の 1 つであれば、Rational ClearQuest クライアントのアクション リストに表示されます。
- Delete
- Delete アクションを使用すると、ユーザーはデータベースからレコードを削除できます。Delete アクションは、Rational ClearQuest クライアントのアクション リストに表示されます。
- Duplicate
- Duplicate アクションは状態ありレコード タイプでのみ使用可能です。このアクションは、
レコードを、類似情報を持つほかのレコードにリンクします。
Duplicate アクションは、現在のレコードが遷移元の状態の 1 つであれば、Rational ClearQuest クライアントのアクション リストに表示されます。
- Import
- Import アクションはレコードを別のソースからインポートします。インポートされるレコードの
内容は、このアクションの一部として確認されますが、フィールド レベルでの確認は
行われません。さらに、状態ありレコードのセットがインポートされると、
これらのレコードは、データ ファイルで指定された状態に割り当てられ、本来その状態に
遷移できたかどうかの確認は行われません。Import アクションは、Rational ClearQuest クライアントのアクション リストに表示されません。
- Modify
- Modify アクションを使用すると、ユーザーはレコードの状態を遷移させずに
レコードのフィールドの値を修正できます。Modify アクションは、Rational ClearQuest クライアントのアクション リストに表示されます。
- Record_script_alias
- Record_script_alias はアクション名をレコード スクリプトと関連付けます。これによって、Record_script_alias アクションが Rational ClearQuest クライアントの
アクション リストに表示されるようになります。ただし、Record_script_alias アクションは、
レコード タイプ状態の一部ではなく、エンティティを自動的には操作しない (その動作は、レコード スクリプト別名の
コード化の方法で決まる) ため、エンティティ アクションではありません。このため、Record_script_alias アクションは
、GetActionName や GetActionType などのエンティティ関数、または、
エンティティ アクションを操作する他の関数の、有効なパラメータの一部ではありません。
- Submit
- Submit アクションは新規レコードを Rational ClearQuest ユーザー データベースに
入力します。状態ありレコードの場合、このアクションを使用して遷移先の状態が割り当てられますが、
遷移元の状態は必要ありません。
各レコード タイプは、タイプが Submit のアクションを 1 つのみ持つことができます。
- Unduplicate
- Unduplicate アクションは状態ありレコード タイプで使用可能です。このアクションは、
重複レコード間のリンクを削除します。
状態遷移の作成
Rational ClearQuest のスキーマ開発者は、
ユーザーがレコードの状態を遷移させるためのルールを定義します。状態遷移は、アクションを使用して実行されます。
状態遷移を作成するには、CHANGE_STATE タイプのアクションを定義し、次にそのアクションの遷移元の状態と
遷移先の状態を選択します。
フックの追加によるアクションのカスタマイズ
アクティブ レコードのライフサイクルの主要ポイントで
タスクを実装するアクション フックを追加できます。例えば、すべてのユーザーは、
デフォルトですべてのアクションにアクセスできます。Access Control フックを使用して、特定のアクションへのアクセスを制限できます。
サポートされるアクション フックには、Access Control、Initialization、Validation、Commit、Notification が
あります。
アクション フックに関する詳しい説明とフィールド フックとの関連については、「ワークフローのカスタマイズにおけるフックの使用法」を参照してください。
Access Control アクション フックの作成方法については、「アクセス制御アクション フック例」を参照してください。
また、「スクリプト言語」と「アクション アクセス制御 も参照してください。
デフォルト アクション
状態のデフォルト アクションを定義できます。
状態のデフォルト アクションは、Rational ClearQuest クライアントの [アクション] メニューに
太字で表示されます。
デフォルト アクションは、ユーザーに対する状態モデルのガイドとして役に立ちます。
UCM スキーマやパッケージなど、特定のスキーマとパッケージでは必須になります。
UCM スキーマやパッケージを使用する場合は、状態のデフォルト アクションを使用して、状態タイプ モデルにおける有効なパスを提供する必要があります。詳細については、「IBM® Rational UCM 統合の追加」を参照してください。デフォルト アクションは、フック コードから呼び出すこともできます。
状態のデフォルト アクションを定義するには、先に状態遷移を作成する必要があります。
アクションの削除
アクションの削除の際に、スキーマの変更が必要な場合があります。例えば、CHANGE_STATE アクションを削除する場合は、
脱落するアクションを補正するよう状態遷移マトリックスを修正する必要があります。
削除したアクションをスクリプトで参照している場合、スクリプトを修正して、
削除したアクションへの参照も削除する必要があります。