ケース参加者とルーティング
ケースタイプにケース参加者（旧称：ワークパーティ）を追加することで、一貫性のある設計ができます。 ケースライフサイクルを通じてルーティングの設定を簡素化できます。 ケース参加者をソリューションに使用することで、ベースの製品で提供される機能（すぐに使えるデータモデル、検証、UIフォーム、連絡など）を活用して、設計や保守を簡素化できます。 このトピックでは、ケース参加者の機能とルーティング設定について理解を深め、開発者がこの機能を十分に活用できるように説明します。
ケースの参加者の動作
ケース参加者向けの既存のコードのほとんどは、Data-Partyクラスに含まれており、派生クラスのルールに対する基本機能とオーケストレーションを提供します。 複数のクラスはData-Partyを拡張したもので、たとえばData-Party-Operatorは基本機能を上書きしています。 ワークパーティの定義に使用するクラスによって動作が変わるため、この多相的な動作を理解することは重要です。 たとえば、Data-Party-Operatorクラスで構築されたワークパーティとData-Party-Personクラスで構築されたワークパーティでは、ワークパーティの初期化、検証、表示などが異なります。 Data-Partyクラスとサブクラスで提供されるルールを確認し、比較することで、提供される基本機能と特殊性を理解することが推奨されます。 多相ルールの例として、WorkPartyRetrieveアクティビティが挙げられます。 このアクティビティは、Data-Party-Operator派生クラスとData-Party-Person派生クラスの中で上書きされます。
WorkPartyRetrieveアクティビティは、ケースに組み込まれた.pyWorkParty()ページにページが追加されるたびに呼び出されるため、重要です。 .pyWorkParty()ページグループには、案件に追加され個々のパーティが保存されます。 このプロパティ定義には、最終的にWorkPartyRetrieveアクティビティを呼び出すon-changeアクティビティが含まれています。
検証や表示など、ワークパーティの一部のデフォルト動作を上書きすることが必要な場合もあります。 ルールセットの特殊化や、ワークパーティクラスの拡張と必要なルールの上書きによって、上書きを実行できます。 これが必要な場合は、動作が誤って変化しないよう、変更の範囲を正しく設定するようにしてください。
ケース参加者と高度な構成
Work Partyルールは、ケースで使用可能なケース参加者を定義する契約を定義します。
標準のワークパーティのルールpyCaseManagementDefaultで、ケースに対するケース参加者を定義します。 意味のあるパーティロール名を使用すると、アプリケーションの保守性が高まります。 OwnerやOriginatorなど、一般的な名前は避けてください。 Ownerのように一般的でありふれたロール名は、変更される可能性があり、ケースに関するパーティのロールが直観的にわからない場合があります。
VOE（Visible On Entry）オプションを使用すると、ケースの作成時にワークパーティを追加できます。 VOEを使用すると以下の設定が可能になります。
- 新規ハーネスでユーザーがワークパーティを追加できるようにする
- 現在のオペレーターを自動的にワークパーティとして追加する
- 別のオペレーターを自動的にワークパーティとして追加する
ワークパーティのルールでデータトランスフォームCurrentOperatorを使用して、ケース作成時に現在のオペレーターをCase Participantとして追加します。 カスタムデータトランスフォームを作成すると、ケースの作成時にワークパーティを追加できます。
ソリューションを対象としたロジックで、既存のデータトランスフォームを作成またはカスタマイズします（既存のデータトランスフォームルールを参照してください）。
CurrentOperator, NewParty
ケース参加者とApp Studio
App Studioでは、ケースタイプで「Settings 」タブを使用して参加者を追加できます。
「Participant configuration」ペインで、「Add Participant」をクリックし、「Role name 」フィールドに一意のタイトルを入力します。 このロールは、ケースタイプにおける参加者の関係を示します。
参加者がアプリケーションユーザーの場合は、システムはそのユーザーをOperatorタイプのワークパーティとして追加します。
「Map participant」セクションでは、参加者を現在のユーザーまたは現在のユーザーの直属の上司として関連付けることができます。 Pegaはデータトランスフォームを作成します。 たとえば、BookEventケースタイプで、ロール名がManagerの場合に、PegaはBookEvent_Managerという名前のデータトランスフォームを作成します。
参加者がアプリケーションユーザーでない場合は、システムはそのユーザーをPersonタイプのワークパーティとして追加します。
以下の表に、App StudioとDev Studioで追加されるケース参加者の違いをまとめました。
| App Studio | Dev Studio |
|---|---|
|
|
|
|
|
|
ワークパーティのプロパティ値の初期化
指定されたケース参加者にルーティングする前に、ワークパーティのプロパティ値を初期化する必要があります。 ケース作成時にWork PartiesルールのVOEオプションを使用して値を初期化することも、ケース処理中に動的に初期化を実行することもできます。 ワークパーティの値を動的に設定する場合は、addWorkObjectPartyアクティビティを活用します。 アクティビティを活用することで、データトランスフォームを指定して値を初期化することもできます。 ケース参加者がすでに存在していても、繰り返し使用可能であると宣言されていない場合は、このアクティビティは注意して使用してください。
| 実行時（前処理） | 送信時（後処理） |
|---|---|
|
SET Param.PartyClass=”Data-Party-Person” SET Param.PartyModel=“NewParty” WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")") = false SET Param.Success=@pxExecuteAnActivity(“Primary”,“addWorkObjectParty”) |
SET Param.PartyClass=”Data-Party-Operator” SETParam.PartyModel=“CurrentOperator” WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")") REMOVE .pyWorkParty(param.PartyRole) SET Param.Success= @pxExecuteAnActivity(“Primary”,“addWorkObjectParty”) |
|
NewParty データトランスフォームで、これらの必須フィールドに値を設定する .pyFirstName, .pyLastName, .pyEmail1 |
CurrentOperator データトランスフォームで、これらの必須フィールドに値を設定する .pyFirstName, .pyLastName, .pyEmail |
ワークパーティページの値を直接初期化したり設定したりしないでください。意図しない結果になる可能性があります。
ベストプラクティスとして、最初のアサインメントを含むすべてのアサインメントに対してルーティングを定義してください。 これにより、ケースの処理中にケースが最初のアサインメントに戻されたり、SLA（サービスレベルアグリーメント）によって前のステップが自動的に進められたりした場合に、ルーティングの問題を防ぐことができます。
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。