ケース処理

ケースの処理は、サービス（アプリケーション）、バックグラウンド処理（バッチ）、および「Web」ユーザー（ブラウザー）の3つの主なリクエスタータイプで実行されます。 Webユーザーは人間ではなくロボットのこともあります。 各リクエスターは、それぞれのJAVAスレッド内で実行されます。 個別のJAVAスレッドにより、複数のリクエスターが並行してアクションを実行できます。

ケースデザインは、ワークをいかに効率よく処理するかに影響します。 効率的なケースデザインでは、個別のリクエスターが並行して実行可能なステップやプロセスを考慮します。 たとえば、異なるユーザーがお互いに干渉することなく同じ高コストの行項目を同時に承認または拒否できるように工夫しています。 各承認は、別のWebリクエスターが行います。 拡張可能なソリューションが同じ例に必要な場合は、タスクをバックグラウンドプロセッサーに照会して、自動承認を実現することもできます。

Divide and Conquerパターンのように、ある時点で複数の人が同時にケースを処理する必要がある場合、同一ケース、サブケース、兄弟ケースの処理を選択する必要があります。

以下の要素が考慮されます。

各要素の重要性は、その時の状況によって異なります。

ロック中

非常に短時間のユーザー入力の場合、一度に1人の作成者しかアクセスできない同一ケースのロックは重要ではありません。 作成者は、メールその他のコラボレーションツールを使用して、すぐにケースにアクセスしたいことを伝達できます。 ユーザーが、お互いに干渉することなく同時に関連するコンテンツをケースに添付することは可能です。 データインスタンスは、ケースを参照するPegaSocial-Documentインスタンスで使用されているのと同じ、干渉しないアプローチを採用できます。 リードシステムアーキテクトミッションのBookingアプリケーションの例として、FSG-Data-Pricingがあります。

セキュリティー

所有者が1種類のシンプルなケースの場合は、セキュリティは心配ありません。 すべてのケースを1つのペルソナが所有する場合、セキュリティは簡素化されます。

純粋にセキュリティのためにステージ内に子ケースを作成することは、ワーク自体が分割されておらず、再割り当てされているだけであるため、Divide and Conquerの原則に反しています。 1人のペルソナにはアクセスを簡素化できますが、子ケースにアクセスできないようにする必要があるN-1人の他のペルソナの場合はより複雑になります。 ペルソナに基づいてケースタイプへのアクセスを制御する方法は他にもあります。

Access Managerランディングページでは、アクセスグループ（ペルソナ）とケースタイプの関係を、RBACの観点から限定的に表示および管理するサポートを行います。 条件付きアクセスの場合、Access ManagerでAccess Whenルールを選択することができます。 Access Whenルールは、ABACでも使用することができます。

レポート

レポートの簡素化は、セキュリティの簡素化と密接な関係があります。 Pegaには、ケースステージに基づいたレポートディフィニッションがあります（Work- pyGetWorkinStage、pyCountByStageなど）。

レポート：ケースごとのデータへのアクセス

レポートの複雑さは、追加ケースの作成を正当化するものではありません。 たとえば、Limited AvailabilityとConcurrencyデザインパターンでは、サブケースよりもデータインスタンスを使用することを主張します。 データをケースBLOB内外のどちらに保存するかは、ケースデザインとは関係なく、データモデルの決定事項です。

レポート：レポート用のデータへのアクセス          

セキュリティ上の問題から別のケースを作成する必要がある場合は、ケースやアサインメントに関するレポートも別のケースを作成するメリットがあります。

パフォーマンス

シンプルなデータインスタンスと比較してケースやアサインメントが多すぎると、データベースやRAMの使用率に悪影響を及ぼす可能性があります。 Enrollment/TODOリストへのタスクの追加デザインパターンは、この懸念事項を示すものです。 各乗客をサブケースとして表現するクルーズ船は、乗客をデータインスタンスとして表現するよりも多くのリソースを消費します。 クルーズ船には平均3000人の乗客が乗っていることを考慮すると、My Casesランディングページを使用したり、WorkQueueリストを表示したりたりすることは避けたいものです。

複数の小さなサブケースは、1つのケースのBLOBに格納されている同じデータと比較して、クリップボードのメモリ消費量が少なくなります（同時に開かない場合）。 これがどの程度懸念されるかは、BLOB内に格納されるデータ量とBLOB外に格納されるデータ量によります。

潜在的な特殊化

関心の分離と単一責任の原則では、ケースをモジュールや組み込みのコンポーネントアプリケーションに分解することが容易になるため、小さなケースが好まれます。 これら2つの原則を遵守するケースでは、上位層の直接継承や同一層のパターン継承を通して、より簡単に特殊化できます。

サブケース関連のコンテンツアクセス

Pega 8で関連コンテンツの実装が変更される以前のPegaの初期バージョンでは、親ケースを参照する添付ファイルだけでなく、サブケースの添付ファイルをケースの添付ファイルリストに含めることができる、Case Attachmentsオプションが存在していました。 現在、そのようなオプションはありません。 まれに、ケース階層内のすべての関連コンテンツを一度に表示できるかどうかが、サブケースよりもシングルケースを優先するほど重要になる場合があります。

サブケースの依存性管理

同一ケースのSplit-For-Each-or-Joinサブプロセスを使用したのでは実現が難しい、サブケースの使用を通して得られる機能は、ケースタイプの依存性に基づいてWaitシェープを定義する機能です。 この種のケースの複雑さが存在する場合、同一ケースの処理ではなくサブケースを使用する意思決定は、依存性管理の観点だけでなく、他の観点（セキュリティ、レポート、ロックなど）からも行われます。

ポリシーの重複（該当する場合）

あまり使用されていないPegaの機能に、Declare-OnChange意思決定に基づいてケースを中断し、調査完了までケースを続行できないようにするものがあります。 ケース階層のすべてのケースよりも、1つのケースを中断し、中断を解除する方が簡単です。 この機能が重要である場合は、ケースデザインの意思決定に影響を与える可能性があります。 オルタネートステージに変更するなど、代替手段を実装することも可能です。 同じDeclare-OnChange条件を使用できます。 違いは、Declare-OnChangeルールが満たす条件に対するリアクションです。

非定型な処理（該当する場合）

非定型なケース（Work-Cover-SimpleCase）は、変則的な状況が発生した場合のタスクやTODOリストを定義します。 このオプションは、アプリケーションが更新されるのを待つ時間が十分にない場合に役立ちます。 非定型なケースは、Configure for Reuseオプションを使用して正式なケースタイプに変換できます。 この機能を使用するにはユーザーへのトレーニングが必要であることに注意してください。Quick CreateボタンはMy Casesランディングページに設置されています。

ケースデザイナーが活用する可能性のあるルールの実装については、設定可能性を念頭に置いて設計してください。 ケースをどのように内部で設計するかが重要です。 ケースデザインの「対象者」には、シニアシステムアーキテクト（SSA）やリードシステムアーキテクト（LSA）だけでなく、アプリケーションの開発や保守に関わるすべての人が含まれます。

ケースデザイナーでは、アクティビティなどの他のルールとのインターフェイスを簡素化するSmartシェープを使用します。 たとえば、Send Emailシェープでは、CorrNewアクティビティの起動に必要なパラメーターを指定できます。 より複雑な例として、19個の設定可能なパラメーターを含むWorkパラメーター化されたpxApprovalサブフローのラッパーである、Approve/Rejectシェープがあります。 Pegaでは、次の画像に示すように3列のウィンドウを使用して、サブフローパラメーターの設定を簡素化しています。

機能のカプセル化の簡単な例にはWork-AllCoveredResolvedサブフローがあり、以下のように構成されています。

1. AllCoveredResolved TicketのエンドシェープにつながるpyContinueAfterWaitフローアクションを使用した単一アサインメントで、。
2. パラメーター＝WorkQueue、ServiceLevel、WaitReason

Bookingアプリケーションは、Book Eventケースの最後に、FSG COEが提供するAllCoveredResolvedコンポーネントを使用します。 コンポーネントは、各Timerが同じタイミングでアクセスするのを待機する、Manage Eventステージ内の各並列プロセスの最後に冗長なTimer Waitシェープを追加できないようにします（.Event.EndDT）。

ワーク承認キューサブフローもFSG COEで提供されます。 このサブフローでは、並列承認を設定できます。 これは、次の内容で構成されています。

1. クラスData-Admin-Operator-IDのワーク承認者フィールドグループリスト
2. NumApprovalsプロパティとNumRejectionsプロパティ
3. サブフローパラメーター＝WorkQueue、ApprovalNeeded、RejectionsNeeded、ApprovalPurpose
4. ループバックWorkQueueの前のForkシェープ
5. サブフローに入ると、NumApprovalsとNumRejectionsが0に設定され、Approversフィールドグループリストが削除されます。

オペレーターは、Approversフィールドグループリスト内の自身のページを更新します。 ApprovalsNeededまたはRejectionsNeededのいずれかのしきい値を満たすと、ループバックフローが終了します。

Approval Queueサブフローは、BookingアプリケーションのBook EventケースのFSG Approvalsステージで使用されます。 ケースデザイナー内では、このサブフローを、2人のイベントマネージャーが承認すると全体の承認となり、2人が拒否すると全体の拒否となるように設定できます。 指定されたソリューション内では、承認または拒否は1回のみ必要です。