
ダイナミックなクラスの変更
エンタープライズレイヤーは、ORG-Data-クラスを参照するORG、Work-Cover-、またはWork-に適用されるルールを自由に定義できます。 アプリケーションレイヤーのORG-APP-Workクラスは、ORG-Data-クラスも自由に参照できます。 アプリケーションレイヤーのORG-APP-WorkクラスはORG-App-Dataクラスも参照できます。
あるデータクラスが兄弟アプリケーション間で共有できる場合を考えます。 そのような場合、企業にとって重要であるため、共有可能な部分をORG-Dataクラスとして定義することは合理的です。 各兄弟アプリケーションは、それぞれの固有のニーズに合わせてエンタープライズレイヤーデータクラスを自由に拡張できます。
アプリケーションレイヤーに拡張可能なエンタープライズレイヤーコードは、エンタープライズレイヤーデータクラスが上位層に拡張可能である事実を活用できます。
OOTB変更クラスの例
Pegaはプロパティのプレフィックスとしてpx、py、およびpzを使用します。
pxプレフィックスは、一般的には、一度設定したプロパティの値を変更しないことを意味します。 例として、履歴情報を記録したpxCreateDateTime やpxCreateOperator などがあります。 あるデータの作成は、それを作成した人による一度のみです。
ルールのApply-toクラスを表すプロパティに使用するプレフィックスを決定する場合、Pegaはpxプレフィックスを使用します。 しかし、Pegaでは、たとえば、転送の割り当て時に実行時にpxObjClass の値をAssign-WorkBasket から Assign-Worklistに変更したり、逆にPage-Change-Classメソッドを使用して変更したりします。
Page-Change-Classアクティビティメソッドには、Keepパラメーターがあります。 より複雑な3番目のオプションである2を無視して、維持するKeepパラメーター値は以下のとおりです。
- 0=既に存在するプロパティの値は変わらない
- 1=既に存在するプロパティの値はデータトランスフォームで上書きされる
ここから得られることは、pxObjClass は実行時に変更できますが、その変更を慎重に行う必要があるということです。
たとえば、クラス名を返すデシジョンテーブルを設定してpxObjClassを変更する必要はありませんが、特殊化タイプで付加されたパターン継承を使用してクラス名の構築を試みる必要があります。 しかし、ワークからデータにクラスを変更する場合には、これを行うことができない場合もあります。
ダイナミッククラス参照(DCR)は、オブジェクトのpxObjClassの値が、設計時ではなく実行時に決定される場合に、Pegaで使用されてきたパターンです。
再利用可能なコードを使用して異なるクラスのページをインスタンス化する
通常、pyGUIDなどの単一のキーを持つLookupデータページでは、単一のpyGUIDパラメーターを使用します。 しかし、D_Locationデータページには、2つ目のTypeパラメーターがあります。 D_Locationデータページは、Typeパラメーターを使用するLoadLocationDCRアクティビティを次のように取得します。
パラメーターType !=""の場合は処理を続行します。 それ以外の場合は、ステップGOに進みます。
param.ObjClassNew = "FSG-Data-" + param.Type と設定する
プライマリページをそのまま渡してPageChangeClassを呼び出す
GO
FSG-Data-Location(場所)のインスタンスをLocationTEMP上に開く
param.OpenClassをPrimary.pxObjClassとして渡す
param,pyGUIDをクラスのキーであるpyGUIDの値に使用する
LocationTEMPをプライマリーにコピーする
メモリからLocationTEMPを削除する
このTypeパラメーターは、Primary.pxObjClassの変更後、その値に基づいてLocationTEMPページを作成するようPegaに伝達します。 派生クラスに関係なく、Pegaは用意されたpyGUIDに一致するLocationデータベーステーブル内の行にアクセスします。 PegaはFSG-Data-Locationで定義されたプロパティを返すだけではありません。 代わりに、Pegaは、派生したLocationクラスに関連するLocationテーブル内のすべてのプロパティを返します。 元のD_LocationページはFSG-Data-Locationクラスで定義されていましたが、クラス名の変更によりParkingLocationインスタンスデータを引き出し、さらにデータページで変更したクラスをpxObjClasとして確保できます。
このアクティビティでは、異なるクラスのページをインスタンス化するために、再利用可能なコードを記述できることを示しています。 その場で生成されたクラスは、データベーステーブルで読み取られません。 CustomerデータスキーマにpxObjClass列がありません。
データページのクラスはTypeパラメーターに基づいて変更できるため、どのクラスにも使用できる単一のデータページが作成されます。
ダイナミッククラスの参照例
ORG、ORG-App、[*]-Data、および[*]-Workのように、タイプが明確に定義されていないクラスではなく、タイプが明確に定義されているクラスに対しては、DCRを使用します。 ミッション指定型のソリューションコードの中には、FSGSampleとFSGSample2という、関連する2つのサンプルアプリケーションがあります。 各サンプルアプリケーションでは、Roadside AssistとService Complaintの2つの類似したケースタイプが定義されています。
これら4つのケースタイプは、一般的な同じデータタイプであるFSG-Sample-Data-Vehicleを利用し、拡張します。 次の画像は、各レイヤー内の*-Data-Vehicleの3つの特殊化を示しています。それぞれ、-Car、-Truck、-Motorcycleです。
DCRを使用する一般的な方法では、すべての値(.MotorCycleClassなど)に対応するプロパティを持つアプリケーション全体のデータタイプを定義します。 このアプリケーション全体のデータタイプの中には、D_AppExtensionという名前のデータページが定義されています。 そのデータページは、データトランスフォームを取得して、データページのプロパティ値を入力します。 D_AppExtension.MotorCycleClassなどの構文を使用して値を取得します。 アプリケーション全体のデータタイプを定義したレイヤーの上位のレイヤーでは、AppExtensionデータページからそのデータトランスフォームを上書きします。 このアプローチは、「開放/閉鎖の原則」に準拠していないことに注意してください。 新しい派生クラスが定義されると、AppExtensionデータタイプに新しいプロパティを追加する必要があります。
クラス階層内でDCRを使用するためのモジュール方法は、そのクラス階層のベースにDCRデータページを定義することです。 用意されたソリューションの中で、FSG-Sample-Data-Vehicleクラスは、D_VehicleDCRデータページを定義します。 このデータページの唯一の目的は、データページに必要なTypeパラメーターの値に基づいて、そのpxObjClassを設定することです。 この操作は、LoadVehicleDCRというデータトランスフォームを取得して実行します。
FSGSampleのコードでは、実際にはD_VehicleDCRを使用していません。 このコードは、LoadVehicleDCRデータトランスフォームを直接呼び出すことができます。 これは、Service ComplaintケースのCreateステージで行われます。 FSG-Sample-Data-Vehicle IdentifyVehicleセクションには、Vehicleの.Typeプロパティを設定するオートコンプリートコントロールがあります。 変更すると、セクションが更新されます。 更新前に、LoadVehicleDCRデータトランスフォームが呼び出されます。 .Typeプロパティには、Typeパラメーターの値が用意されています。 PageChangeClassアクティビティは、Typeプロパティごとにクラスを変更するためにトリガーされます。
2つのVehicleサンプルケースの主な目的は、2つの異なるレイヤーで定義された多相クラスが、pzInsKey列およびpxObjClass列が欠落した、同じCustomerDataスキーマデータベーステーブルから永続化および復元できることを示すことです。
このトピックは、下記のモジュールにも含まれています。
- データモデルの設計 v3
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。