ケースデザインのパターン

デザインパターンとは、再利用可能なコンポーネントの定義や、繰り返し発生する一般的な問題を解決するために適用されるソリューションパターンのことです。 COEチームの一員として、PCLSAはビジネス領域に特化したケースデザインパターンを使用する必要があり、これによりチームは再利用可能かつ維持可能なソリューションを迅速に構築するのに役立ちます。

Pegaには、独自のケースの概念があります。 一般的には、ビジネスプロセスをモデル化したものです。 Pegaのケースは1つ以上のステージとステップで構成されており、ケース階層を形成する子ケースを含める場合があります。 親ケースは子ケースと相互作用する場合があり、その逆もあります。 めったにないものの、ケースは、ケース階層の一部でなくても兄弟ケースまたは仲間ケースと相互作用できます。 たとえば、既存の親ケースを更新するために子ケースを作成する必要はありません。 トップレベルのケースは、相互に更新される場合があります。

以下のデザインパターンで、ケースの相互作用を分類できます。

1. Divide and Conquer（最も一般的）
2. Enrollment/TODOリストへのタスクの追加
3. Data Instance First
4. Limited AvailabilityとConcurrency
5. 兄弟ケースでは、あるケースが他のケースを更新する

Divide and Conquerは、有名な計算問題解決アルゴリズムです。 実行するワークを、独立した解決可能な小さなユニットに分解し、それをさらに小さなユニットに分解していきます。 子ユニットのそれぞれの作業が完了すると、親ユニットのワークに通知されます。 ある親ユニットにその子ユニットの終了が通知されると、親ユニットからさらにその親に通知される、という流れです。 最終的には、親のない親ユニット、つまりトップレベルのケースが、すべての子ユニットのワークが完了したことを確認します。 このようになると、アルゴリズムは停止します。

Divide and Conquerアプローチの主な利点は、兄弟ユニットのワークを並行して解決できることです。 これにより、逐次処理と比較して全体の完了時間を大幅に短縮することができます。 このアプローチでは、再利用の機会もより多くあります。

ビジネスプロセス領域におけるDivide and Conquerアプローチの主な利点は、異なるユニットのワークを、そのワークを効率的に達成するための適切なスキルを持つ適切な人、グループ、またはワークキューにルーティングできることです。 ワークを完了するための目標と期限を確立できます。 苦情などの複雑なケースに関して、ワークがどの程度完了しているか、または完了していないのかを可視化するのは簡単な問題です。

次の画像は、Bookingアプリケーションのコンテキスト内でのDivide and Conquerデザインパターンの表現例です。

EnrollmentデザインパターンまたはTODOリストデザインパターンは、UIページ経由でPegaに実装されます。 このデザインでは、Objectアクションアプローチを実行できます。 オブジェクトには、選択可能なものがすでに存在するか、表示用にすでに選択されている場合があります。 次に、ユーザーはそのオブジェクトに次にすべきことを指示します。 アクションの例として、更新や削除などがあります。

既存のオブジェクトのコンテキスト内で、新しいオブジェクトに対してCreateアクションを実行するようにコンピューターに指示することも可能です。 新しいオブジェクトが既存のオブジェクトに関連付けられていることが予想されます。 新しいオブジェクトは、子ケースである必要はなく、どのようなケースであっても構いません。 新しいオブジェクトは、既存のオブジェクトを参照するデータインスタンスになる場合もあります。

このデザインパターンの主な利点は、ロックの問題を回避できることです。 たとえば、現在のケースの子ケースを作成する代わりに、既存のケースを参照するデータインスタンスを作成することができます。 データは挿入されますが、何も更新されません。

2つ目の利点は、入力されたデータ項目のすべてに単一のサービスレベルアグリーメント（SLA）が適用される場合、その人のワークリストを複数の子ケースの割り当てで埋めるよりも、入力されたデータを「TODOリスト」として扱う方が早くて便利だということです。 「ワーカー」が1人しかいないため、Divide and Conquerが該当しません。子ケースを使用することで得られる唯一の利点は、各データ項目にSLAがある場合、より細かいレベルでワークを追跡できることです。

Data Instance Firstデザインパターンは、ケースを作成する前に、ケースに関連するデータを永続化させる方法を示します。

たとえば、マッシュアップを使用する場合、すぐにケースを作成する必要はありません。 代わりに、ケースが作成される前にケースのデータを永続化できます。 この例では、マッシュアップインターフェイスがCreate a new caseではなくDisplay a pageとして設定されています。

マッシュアップのCreate a new caseオプションは、Data Instance Firstデザインパターンにも関連していることに注意してください。 Create a new caseは、Createステージが追加されたPega Platform™バージョン8.5のCase Designerで直接サポートされています。 Display a pageとCreate a new caseの違いは、Display a pageではケースを作成する必要があるかどうかの判断は、データインスタンスが永続化された後にサーバー上で行われることです。

Create a new caseオプションでは、一時的ではあるものの、すでにケースの作成が決定されています。 pyIsMashup状況テンプレートを使用すると、ケースが作成されたにもかかわらずまだ永続化されていない事実を隠すことができます。 特に、pyCaseMainInnerセクションは、Mobile Main Case Panelセクションのテンプレートのみを表示するようにすることができます。 Navigationメニュー、Recents、Related Content、Participersなど、Case Workerポータルの残りの機能は表示されません。

組み込みのページがないシンプルなフラットデータクラスは、CustomerDataスキーマに素早く永続化することができます。 しかし、これはUIデータ入力の観点では大きな制約になります。 理想的には、このUIが元のデータクラスに関連するデータインスタンスの入力もサポートするようになることです。 解決策は、Modelデータクラスの定義にフィールドグループリストを追加したViewデータクラスを定義することです。 CustomerDataスキーマでは組み込みページを許可していないため、Viewデータクラスのフィールドグループリスト内の各ページは、Modelデータインスタンスを参照する必要があります。

ケースは、Viewデータクラスのデータが永続化された後に作成できます。 Pega API「ケース」POSTケースを呼び出してケースを作成することができます。 たとえば、Org-Data-MemberViewデータクラスにはOrg-Data-Memberフィールドグループが含まれます。 Org-Data-Memberのインスタンスが永続化された後、D_CreateMemberデータページは「ケース」Pega API REST Connectorを呼び出します。 POSTリクエストのコンテンツページにはMemberGUIDプロパティが含まれ、その値は永続化されたOrg-Data-MemberインスタンスのpyGUID です。 作成されたケースにはMemberGUIDプロパティがあり、POSTリクエストのコンテンツページでその値が設定されます。 ケースは、データページLookupとして定義されたOrg-Data-Memberデータ参照プロパティを所有することもできます。 MemberGUIDプロパティは、そのLookupデータページにパラメーターを供給します。

このデザインパターンは、以下のEnrollmentパターンやTODOリストパターンに類似しています。

• ケースのように、何かが事前に存在しています。
• その後、データやケースなどのいくつかのものを既存の項目と関連づける必要があります。

具体的な例としては、自動車を輸送するフェリー航路が挙げられます。 出張ケースがフェリーを表現します。 お客様は、自分自身と車両のために特定のTripのスペースを予約するために申し込みます。

Limited AvailabilityとConcurrencyのデザインパターンは、以下の点で異なります。

1. 容量に制限があります。 たとえば、フェリーに乗船できる乗客や車両の数には制限があります。
2. Concurrencyマネジメントが不可欠です。

Concurrencyマネジメントに関して、同じ時間の同じ旅行に2件の予約が同時に行われたとします。 1件の予約に対して残り容量が十分ではなく、もう1件の予約はキャンセル待ちリストに追加する必要があります。 この問題を解決するには、Reservation子ケースが最適解でしょうか?

その答えは、ロックの設定によって異なります。 親ケースとすべての子ケースが同時にロックされるようなロック設定である場合は、一度に1件の予約しかできないため、この設定でオーバーブッキングの問題を解決することができます。 しかし、他の人が予約データを並行して入力することはできないため、これもリソースが無駄になる可能性があります。

ロックの設定が、子ケースが親ケースをロックしないような場合は、これによりオーバーブッキングの問題が発生する可能性があります。 親ケースに子ケースを追加するには、親ケースを開いてロックする必要があります。 旅行のキャパシティが限界に近い状態で、その旅行に同時に複数の予約が行われている場合、キャパシティを超えないように追加の検証を行う必要があります。

たとえば、フェリーの定員が500名の場合、その数の子ケースを作成しても意味がありません。 よりシンプルですばやいアプローチは、何もロックしようとせずにReservationデータインスタンスを挿入するか、更新することです。 Reservationデータインスタンスは、Tripケースを参照します。 1つのデータベーステーブルに1つの行を書き込むのにかかる時間は、lock-query-save-commit-unlockプロセスを実行するのに必要な時間より短くなります。

兄弟ケースの更新デザインパターンは、ケース階層の同じレベルで兄弟ケース同士が相互作用することで表現されます。 これは、2つのトップレベルのケースである場合と、同じ親ケースの2つの子ケースである場合があります。 たとえば、ケースAがケースBと関連している場合を考えます。 ケースBのステータスがケースAのステータスに依存している期間がある場合、ケースBがケースAの子ケースである理由はありません。 この動作を実現するためには、両ケースが兄弟関係である必要があります。

たとえば、フェリーのシナリオでは、フェリーが目的地に到着し、乗客が下船した時点でTripケースライフサイクルが終了します。 子ケースではなく、兄弟ケースとして実施されたReservationケースは、Billing、Refund、またはSatisfaction Surveyなどのステージに進むことができます。 ReservationケースがTripケースの子ケースとして実装されている場合、親ケースが解決されると、そのケースを次に進めることができます。 しかし、このプロセスでは、子ケースとして実装した当初の理由が崩れてしまいます。

相互作用するケースを兄弟関係として実装する意思決定には、その関係をどのように実装するのが最適であるか判断する必要があります。 可能性としては、Update a caseフローシェープを使用したり、アクティビティでQueue-For-Processingメソッドを使用したりすることがありますが、これらに限定されるものではありません。