プロモーションプロセスの強化
現在のところ、プロモーションオブジェクトを最新作業版数に再表示するための、またはリビジョンシリーズの変更によってプロモートされるプロモーション候補を自動的に改訂するための定義済みソリューションはありません。
バックグラウンド
プロモーションリクエストレビューおよび承認プロセス時、参加者によってプロモーション候補に関する問題が発見されることは珍しくありません。やり直しループを導入することにより、プロモーションリクエストを却下するよりも効率の高いプロセスを実行することができます。このやり直しループにより、プロモーションリクエストの作成者は、コメントをレビューし、プロモーション候補に対する適切な調整を行い、ワークフローで自動的にほかのレビューや承認に対するプロモーションリクエストを再表示できます。
結果が検証エラーとなりそうな場合は、承認用のプロモーションターゲットは送信しないことをお勧めします。やり直しループには、プロモーションターゲットの現在の作業版数や、自動再表示が有効な場合は更新された作業版数に基づく検証が含まれます。
製品にプロモーションリクエストをゲートレビューとして使用している会社にとっての最善策は、オブジェクトのリビジョンラベルを数値連続から英数字連続に切り替えることです。ライフサイクルを適切に設計すると、目的のターゲット状態に達し、自動的にプロモーション候補を新しいリビジョンシリーズの最初のリビジョンラベルに変更するようなゲート状態がモデル化されます。
範囲/適用可能性/前提条件
次の説明は、ワークフロープロセスの変更、およびワークフロー内の Windchill メソッドを呼び出す方法についての知識があることを前提としています。
予測される結果
自動再表示を追加したり、カスタマイズされたワークフローに自動改訂機能を追加することができます。
ソリューション
プロモーションリクエストの定義済みプロセステンプレートには、自動再表示と自動改訂機能の両方を実行する方法について示されています。また、テンプレートにはレビュー検証も含まれています。
前提となる知識
この結果を達成するには、以下のことを理解している必要があります。
• 基本的な Java 開発
• 集計定義式および定義式ロボットを含むワークフロープロセスの修正
• リソースバンドルファイルの管理
• Windchill プリファレンス管理ユーティリティ
 |
定義済みのワークフロープロセステンプレートには直接修正を加えないでください。それらのプロセステンプレートは、修正する前に名前を変更する必要があります。
|
ソリューションエレメント
|
エレメント
|
タイプ
|
説明
|
|---|---|---|
|
wt.maturity.MaturityServerHelper.service.unlockTargets (pn)
|
メソッド
|
このメソッド呼び出しは、やり直しの場合にプロモーションターゲットをロック解除するワークフロー定義式に追加することができます。この結果は、プロモーションリクエストが作成された時点でのプロモーションターゲットの状態と同じプロモーションターゲットとなります。プロモーションターゲットをロック解除すると、やり直しが割り当てられたユーザーは (アクセス制御に従って) オブジェクト上で更新を行うことができます。
|
|
wt.workflow.work.WfTally
|
クラス
|
このクラスを使用して、ワークフロータスクの投票を集計します。たとえば、あるタスクが承認役割に割り当てられた場合、ユーザーはそのタスクと投票を別々に受信することができます。このクラスでは、そのオプションに投票する必要があるのは全ユーザーか、または任意のユーザーであるかに基づいて、実行すべきルートを定義するメソッドが提供されています。
|
|
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
|
メソッド
|
このメソッドは、プロモーションオブジェクトの更新処理を行うワークフロー定義式に追加することができます。内部では、このメソッドは最初に新しいプリファレンス「最新作業版数の再表示」を使用して動作を制御します。以下の値を実行します
1. プロモーション候補を再表示します (デフォルト設定)。この値はプロモーション候補のみを再表示します。
2. すべてのオブジェクトを再表示します。この値は、プロモーション候補および成熟度ベースラインのその他オブジェクトを含む、すべてのプロモーションオブジェクトを再表示します。
3. 何もしない。このオプションはプロモーションオブジェクトの再表示を行いません。
4. プロモーションターゲットを検証します (詳細については、セクション「手順 - やり直しにおけるプロモーションターゲットの検証」を参照してください)。
|
|
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
|
メソッド
|
このメソッド呼び出しは、プロモーションターゲットをロック解除するワークフロー定義式に追加することができます。ロック遷移を持つプロモーションターゲットのみがロック対象となります。
|
|
com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.revisePromotables(pn, pn.getCreator(), locale);
|
メソッド
|
このメソッドは、プロモーションオブジェクトを自動的に改訂するワークフロー定義式に追加することができます。内部では、このメソッドは 2 つのプリファレンスを使用します。
1. 自動リビジョンモード。これには 3 つのモードがあります。
a. 何もしない。
このモードは、自動リビジョンを実行しません。
b. プロモーション候補のみを自動改訂します。
このモードは、プロモーション候補のみを自動改訂します。
c. バージョン管理スキームが変更されたプロモーション候補のみを自動改訂します。
このモードは、バージョン管理スキームが変更されたプロモーション候補のみを改訂します。
2. 自動リビジョン状態。
このプリファレンスは、自動リビジョンが有効な状態を含む複数値リストです。自動リビジョンモードプリファレンスが "何もしない" 以外の場合にのみこのプリファレンスが有効になります。
|
手順 — 自動再表示の追加
プロモーションリクエストで使用されるカスタマイズされたワークフロープロセステンプレートは、自動再表示に対応するよう修正することができます。以下の例は、定義済み "プロモーションリクエスト承認プロセス" の最新の作業版数で使用する手順についての概要です。
この例ではやり直しループが追加されています。ループの開始点は「プロモーションリクエストの承認」タスクです。プロモーション承認者のメンバーがこのタスクを受信します。「やり直し」という追加ルートが「プロモーションリクエストの承認」タスクに追加されています。
この例では、すべての承認者の投票に基づき、実行すべきルートを決定する集計定義式が定義されます。
Vector v = new Vector();
v.addElement("Approve");
v.addElement("Reject");
v.addElement("Rework");
Vector vResult = wt.workflow.work.WfTally.any(self, v);
if( vResult.contains("Rework")) {
result = "Rework";
} else if ( vResult.contains("Reject") ) {
result = "Reject";
}else {
vResult = WfTally.all(self,v);
if( !vResult.isEmpty() ) {
result = (String)vResult.get(0);
}
}
v.addElement("Approve");
v.addElement("Reject");
v.addElement("Rework");
Vector vResult = wt.workflow.work.WfTally.any(self, v);
if( vResult.contains("Rework")) {
result = "Rework";
} else if ( vResult.contains("Reject") ) {
result = "Reject";
}else {
vResult = WfTally.all(self,v);
if( !vResult.isEmpty() ) {
result = (String)vResult.get(0);
}
}
この定義式は、任意の承認者が「やり直し」を選択した場合、「やり直し」オプションが行われることを示しています。承認者が「やり直し」を選択せず、任意の承認者が「却下」を選択した場合は、「却下」が行われます。「やり直し」と「却下」が選択されない場合は、「承認」ルートに進みます。
承認者のタスクには、特別な指示が含まれなくなりました。ただし、special_instructions というプロセス変数が存在します。このフィールドは処理においてグローバルのため、プログラムによって設定することができます。強化されたワークフローは、「プロモーションリクエストの承認」タスクの「コメント」フィールドを使用して、承認者が「やり直し」に投票したコメントの文字列をアセンブリします。この文字列は、やり直しの特別な指示として設定されます。たとえば、user1、user2、user3 という承認者役割の 3 人のユーザーがいるとします。
• User1 は、"Looks good" コメント付きで承認に投票
• User2 は、"Modify" コメント付きでやり直しに投票
• User3 は、"Resize" コメント付きでやり直しに投票
この場合、やり直し担当者は特別な指示付きのタスクを受信します。
• [User2]: Modify
• [User3]: Resize
一度やり直しルートが選択されると、やり直しのためにプロモーションターゲットがロックされ、プロモーション作成者はプロモーションリクエストのやり直しタスクを受信します。このタスクには、やり直しが必要なプロモーションアイテムに関する承認者の特別な指示が提供されます。特別な指示フィールドは、承認タスクの場合は書き込み可能、やり直しタスクの場合は読み取り専用です。作成者はその後、このタスクの特定のプロモート可能オブジェクトに作業版数を適用できます。作成者は、プロモーションに不向きかどうかを判断し、却下オプションを選択できます。この場合、プロモーションリクエストは却下されます。
やり直しを実行するユーザーは、修正が許可されたオブジェクトのみを更新することができます。プロモーションリクエストの大幅なやり直しでプロモーションリクエストのコンテンツの修正が行えない場合は、却下が必要となり、やり直しアイテムと新規プロモーションリクエストが必要となります。やり直しループは、大幅な構造変更以外の書式エラー、数量または単位の問題、ジオメトリの細部の変更などといった、軽度の問題を処理するためのものです。
プロモーション作成者がサブミットオプションを選択すると、プロモーションリクエストによってプロモーションオブジェクトを再表示する定義式が実行されます。
wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
catch( Exception wte )
}
{
wte.printStackTrace();
}
try
{
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
catch( Exception wte )
}
{
wte.printStackTrace();
}
PromotionNoticeWorkflowHelper.refresh(pn) メソッドによって、プロモーションオブジェクトが「ソリューション」セクションで定義したプリファレンス規則に従って最新の作業版数に再表示されます。ループが終了し、承認者は再度「プロモーションリクエストの承認」タスクを受信します。ロックがサポートされている場合、承認の前にプロモーションターゲットが不注意で修正されないよう、lockTargets() の呼び出しを含めることは重要です。
FIT テーブル
以下の FIT テーブルは、最新作業版数の再表示プリファレンスが自動再表示にどのように影響するかについて示しています。
プロモート可能 | プロモーションターゲット | 最新作業版数の再表示のプリファレンス値 | 再表示可能 |
|---|---|---|---|
part_1 | なし | 何もしない | false |
part_2 | 必須 | プロモーション候補を再表示 | true |
part_3 | 必須 | すべて | true |
part_4 | N | プロモーション候補を再表示 | false |
part_5 | 必須 | すべて | true |
手順 — 自動リビジョンの追加
プロモーションリクエストで使用されるワークフロープロセステンプレートは、自動リビジョンに対応するよう修正することができます。
以下の例は、定義済み "プロモーションリクエスト承認プロセス" の最新の作業版数で使用する手順についての概要です。
この例では、新しい条件式が追加されています。この条件式は、ターゲットをプロモートする条件式の後に追加されます。条件式は次のようになります。
ルーティング定義式を展開すると次のようになります。
wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
java.util.Locale locale = wt.session.SessionHelper.getLocale();
com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.
revisePromotables(pn, pn.getCreator(), locale);
reviseValidationMsg= com.ptc.windchill.enterprise.maturity.validators.PromotionTargetsReviseValidator.getReviseResultSetMessage(set, locale);
if (!reviseValidationMsg.isEmpty() )
result="Partial";
else
result="Full";
}
catch( Exception wte )
{
wte.printStackTrace();
}
try
{
java.util.Locale locale = wt.session.SessionHelper.getLocale();
com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.
revisePromotables(pn, pn.getCreator(), locale);
reviseValidationMsg= com.ptc.windchill.enterprise.maturity.validators.PromotionTargetsReviseValidator.getReviseResultSetMessage(set, locale);
if (!reviseValidationMsg.isEmpty() )
result="Partial";
else
result="Full";
}
catch( Exception wte )
{
wte.printStackTrace();
}
上記の「ソリューション」セクションで定義したプリファレンスに従って、メソッド revisePromotables(pn, pn.getCreator(), locale); によるプロモーションオブジェクトの改訂が実行されます。
適切なプロモーションオブジェクトが改訂されるとメッセージが作成されます。プロモーションに適さないプロモーションターゲットがある場合は、このメッセージにプロモーションオブジェクトが不適格と見なされた理由が含まれます。メッセージはプロモーション作成者に送信されます。不適格と見なされたターゲットがあるかどうかにかかわらず、有効なプロモーションターゲットが改訂されます。
| | CAD ドキュメントと部品を一緒にプロモートする場合、CAD ドキュメントまたは部品のいずれかの改訂が不適格とみなされると、そのオブジェクトは一緒には改訂されず、プロモートの後にプロモーションリクエストの作成者 (またはその他のユーザー) によって正しく修正される必要があります。 |
ゲートレビューとしてのプロモーションプロセス
製品にプロモーションリクエストをゲートレビューとして使用している会社にとっての最善策は、オブジェクトのリビジョンラベルを数値連続から英数字連続に切り替えることです。ライフサイクルを適切に設計すると、目的のターゲット状態に達し、自動的にプロモーション候補を新しいリビジョンシリーズの最初のリビジョンラベルに変更するようなゲート状態がモデル化されます。
以下の FIT テーブルは、このシナリオが「ソリューション」セクションで説明したプリファレンスのさまざまな値に基づいてどのように行われるかを示しています。
プロモート可能 | ライフサイクル状態に基づく | プリファレンス | プリファレンス値 | プリファレンス | プリファレンス値 | 改訂に有効 |
|---|---|---|---|---|---|---|
part_1 | いいえ | 自動リビジョン状態 | リリース済み | 自動リビジョンモード | すべてのプロモーション候補を自動改訂します。 | はい |
part_2 | はい | 自動リビジョン状態 | リリース済み | 自動リビジョンモード | バージョン管理スキームが変更されたプロモーション候補のみを自動改訂します。 | はい |
part_3 | いいえ | 自動リビジョン状態 | リリース済み | 自動リビジョンモード | バージョン管理スキームが変更されたプロモーション候補のみを自動改訂します。 | いいえ |
part_4 | いいえ | 自動リビジョン状態 | 作業中 | 自動リビジョンモード | すべてのプロモーション候補を自動改訂します。 | いいえ |
この例では、プロモーションリクエストの成熟度状態は "リリース済み" です。また、各部品は一意のコンテナに入っています。
手順 - やり直しにおけるプロモーションターゲットの検証
セクション「手順 - 自動再表示の追加」で説明した自動再表示機能には、再表示するプロモーションターゲットに対して、プロモーションに有効な新しい作業版数があるかどうかをチェックする機能が拡張されています。以下のチェックが行われます。
• プロモーションターゲットがチェックアウトされていない。
• 作成者がプロモーションターゲット上の修正アクセス権を持っている。
• プロモーションターゲットのライフサイクルがプロモーション作成時から変更されていない。
• プロモーションターゲットの状態がプロモーション作成時から変更されていない。
ワークフローテンプレート
以下は、拡張された検証付きのプロモーション通知ワークフローテンプレートです。
これには、上記のチェックを実行するための条件が追加されています。プロモートできないプロモーションターゲットがある場合、プロモーションターゲットのリストが添付された電子メールが作成者に送信されます。プロモーションリクエストの一部のターゲットがプロモートできない場合は、作成者がサブミットまたは却下を行えるやり直しに対してプロモーションリクエストが再び送信されます。すべてのターゲットが有効な場合、プロモーションリクエストが承認用に送信されます。