ルールセット、クラス、状況設定の特殊化

オブジェクト指向原則に従って開発されたコードは、本質的に拡張可能です。 Pegaは、ルールセット、クラス、状況によるルールの特殊化をサポートしています。

Pegaの3つの特殊化の手法のうち、クラスの特殊化は非常に柔軟で再利用の可能性があります。 

• クラスは、従来にはない高度な柔軟性を持つセキュリティを提供します。 
• クラスは、永続性オプションに高度な柔軟性を与えます。 
• ルールレゾリューション時には、クラスが優先される。
• クラスで区切られたルールは、ルールセットや状況設定だけで区切られている場合よりも区別しやすく、ナビゲーションもしやすくなります。

Data-Partyクラス階層は、クラスの特殊化の一例です。 Data-Partyクラスのルールはすべて再利用でき、派生したクラスで上書きすることもできます。 たとえば、Data-Party-Person.クラスとData-Party-Operatorクラスは、WorkPartyRetrieveアクティビティを上書きします。

ルールセットをクラスと並行して効果的に使用することで、各特殊化のルール管理や拡張戦略をより柔軟に実行できます。

Pega Platformは、ルールセットの特殊化を活用してローカライゼーションをサポートします。 フィールド値は、言語固有のルールセットに保存されます。 Pegaは、ユーザーのOperatorレコードのProfileタブの下部に記載されているロケールを参照して、ユーザーのApplication Profileルールセットスタックの最上位にどのルールセットを配置するかを決定しています。

ルールセットの構造を設計する際には、以下の点に注意してください。

• 同じアプリケーション内の2つのルールセットで、同じクラスに同じ名前のルールを定義すると、アプリケーションスタック内で最下位のルールセットのルールが実行されることはありません。 
• ルールセットレゾリューションは、クラスレゾリューションよりも粒度が粗くなります。 ルールセットの特殊化と比較して、クラスの特殊化など、より柔軟にセキュリティルールを差別化できます。
• 異なるルールセット内で同じ名前を持つルール間のナビゲーションは、クラス構造に基づくナビゲーションよりも混乱しやすくなる場合があります。

状況設定を用いると、プロパティや日付に基づいてルールを特殊化できます。 状況設定レゾリューションは、クラスレゾリューションとルールセットレゾリューションの後に行われるという点に注意してください。 

状況間にまたがるセキュリティーは存在しません。 たとえば、同じクラスとルールセット内のルールでも状況設定が別の場合は、セキュリティールールをカスタマイズしないと、そのルールに対する読み取り/書き込みのアクセスを制御することはできません。 

また、同じルールに多くの状況設定バージョンがあると、クラスで区切られたルールよりもナビゲーションしにくくなります。 Dev Studioでは、App Explorerで展開/折りたたみナビゲーションを使用して、状況設定ルールを表示します。 状況設定ルールを検索するには「Case Management」 > 「Tools」 > 「Find Rules」 > 「Find By Circumstance」の順にアクセスします。

状況設定のメリットは、基本ルールと状況設定のバリエーションを並べて比較できることです。 Case Designerは、このような状況設定別のケースタイプルールの表示にも対応しています。

ケースタイプルールの状況設定には、デシジョンルールなどの他のルールタイプの状況設定とは対照的に、いくつか欠点があります。 Dev Studioは、リクエスターレベルスコープを使用してルールを表示します。 ケースタイプルールは通常、ケースに関連するプロパティを使用して状況設定されます。 その結果、状況設定ルールは、設計時ではなく実行時のスレッドレベルスコープになっているケースのコンテキストでのみ解決されます。

Case Designerはリクエスターレベルスコープを持つため、常にフローなどの状況設定ルールの基本バージョンを表示します。 他のルールから状況設定ルールを開くと、そのルールの基本バージョンが表示されます。 ルールの「Action」 > 「View siblings」メニューオプションで、基本ルールの正しい状況設定バリエーションを検索する必要があります。 ケースデザインでよく見られる、相互に関連する多数のルールの場合は、この作業に手間がかかることがあります。 Case Designerで確認できる状況設定ケースタイプルールは、この欠点を解決するものではありません。

フレームワークは、共通の作業処理基盤であり、実装に拡張できます。 フレームワークを設計するには、複数の実装がどのようにフレームワークを使用しているかを理解しておく必要があります。

この情報がない場合、両方の実装に共通するモデルの抽象化は困難です。 将来的に特殊化することも視野に入れながら、最初のうちは実装に集中します。

次の画像は、Pega Platformがルールセットとクラス特殊化ディメンションをどのようにサポートしているかを示しています。 この例では、センターオブエクセレンス（COE）チームが、ベースとなる01.01.01 MyAppアプリケーションのロックダウンを担当しています。 また、COEは、基盤（ベース）となるMyAppアプリケーションの次のバージョン（例：02.01.01）の開発も担当しています。

本番アプリケーションのMyAppEUとMyAppUKは、MyAppを02.01.01バージョンにアップデートする準備が整うまで、MyApp 01.01.01上に構築された状態です。 これは、アプリケーションをPega Platformの新しいバージョンにアップグレードすることと同じです。 「Application Version」軸の目的は、基盤アプリケーションを含むアプリケーションの進化（アップグレードやバージョニング）を可能にすることです。 両方のアプリケーションともがClassディメンションを活用する必要はありませんが、本番アプリケーションがどのようにRulesetディメンションを活用しているかに注意してください。

ここで、UKのユーザー集団はUK以外のユーザー集団より少なく、両方のユーザー集団が元のデータベースに残っていると仮定します。 また、UKではケースデータを分離して保存するため、ケースタイプクラスには直接継承を選択するとします。 UKの既存のケースを新しいケースタイプクラスに移行する必要があり、さらに、MyAppEUアプリケーションがMyAppUKのデータにアクセスしたり、その逆ができないようにセキュリティ対策を講じる必要があります。

MyAppのアプリケーションからすれば、MyAppUKユーザーを新しいユーザー集団に分離するにしても、先にUK以外のユーザーを分離して、後からUKユーザーをMyAppUKアプリケーションに追加するにしても、変わりはありません。 いずれの場合でも、MyAppアプリケーションは2種類のユーザーに対応することから、慎重に管理する必要があります。

MyAppEUアプリケーションでは、ユーザー集団のケースを別のクラス名に移行する必要がないため、ルールセットの特殊化を使用できます。 これは、新しいユーザー集団や分離したユーザー集団に対して同じデータベースを使用しても、新しいデータベースを使用しても同じです。 唯一の違いは、同じデータベースを使用する場合には、継承とさらなるセキュリティ対策が必要になるという点です。 新しいユーザー集団を新しいデータベースに移動する場合には、Classディメンションを活用する必要はありません。 Rulesetディメンションで十分です。