Pegaのデータストレージ

ケースタイプなどの具象インスタンスを持つPega Platformのクラスは、データベースのテーブルにマッピングされます。 たとえば、ユーザーがケースを作成すると、システムはケースにIDを割り当て、その値をデータベーステーブルに個別の行として保存します。 レポートを作成する際には、データベーステーブルの行からデータを取得します。 レポートは、1つまたは複数のデータベーステーブルからデータを見つけるために、class mappingsを使用します。 たとえば、ユーザーがケースを作成すると、Pega Platformはクラスマッピングを使用して固有のケースIDを割り当て、そのインスタンスを正しいデータベーステーブルに行として保存します。 同様に、ケースを開いたりレポートを実行したりするなど、クラスのインスタンスにアクセスする場合、Pega Platformはクラスマッピングを使用して、関連するデータベーステーブルからデータを取得します。

レポートを設計する場合、どのテーブルにデータがあるか、データがどのようにマッピングされているかを把握しておく必要があります。 たとえば、Candidateケースに関する情報を含むレポートを作成する必要がある場合を考えてみます。 これらのレコードは、ケースのWork- クラスのインスタンスです。 同じレポートに、Candidateケースに関するワークキュー情報も含めることができます。 ワークキューのレコードは、ワークバスケットクラスのインスタンスです。 各タイプの情報のデータは、別々のテーブルに格納されています。 データをレポートにまとめる際には、クラス名を使用して情報が格納されているテーブルを特定します。

Pega Platformでは、クラスがマッピングされているデータベーステーブルを特定するために、DatabaseおよびDatabase Tableの2つのルールタイプを使用します。

• データベースレコードはPega Platformが特定のデータベースに接続する方法を特定し、Pega Platformがデータベースにアクセスするための接続情報を含みます。 このレコードは、Database Tableレコードのように他の場所で参照できるエイリアスです。 データベースレコードは、データベース接続にJNDIまたはJDBC URLを使用するように設定できます。 デフォルトでは、Pega Platformには常に以下のデータベースレコードが含まれています。

  • PegaRULES – すべてのPega Platformのルールとシステムデータが保存されているデータベースにマッピングします。

  • PegaDATA– データやワークインスタンスが保存されているデータベースにマッピングします。

• データベーステーブルのレコードは、すべての具象クラスに存在します。 クラスマッピング（Data-Admin-DB-Table-Rule）により、具象クラスとデータベーステーブルを関連付けます。Pega Platformはこのレコードを使用して、ユーザーがケースやデータインスタンスを作成または更新する際に、どのテーブルにケースデータを書き込むかを特定します。

複数のクラスのインスタンスを同じテーブルに保存したい場合もあるでしょう。 たとえば、Candidate（TGB-HR-Apps-Work-Candidateクラス）、Onboarding（TGB-HR-Apps-Work-Onboardingクラス）、Benefits Enrollment（TGB-HR-Apps-Work-BenefitsEnrollmentクラス）の3つのケースタイプを持つアプリケーションでは、アプリケーション内のすべてのケースのワークステータスをレポートする必要があります。

ケースタイプごとにデータベーステーブルを作成するのではなく、通常は親クラス（TGB-HR-Apps-Work）であるクラスを、class group（work poolとも呼ばれる）として指定します。 クラスグループでは、システムが類似または関連するケースタイプのインスタンスを単一のデータベーステーブルにまとめて保存します。 「Candidate」などの特定のケースタイプで作成されたレポートは、そのケースタイプのレコードのみを返します。 クラスグループで作成されたレポートは、そのクラスグループに属するクラスのすべてのインスタンスを返します。

次の例は、クラスグループのデータベーステーブル「pc_TGB_HRApps_Work」にマッピングされる作業クラスを示しています。

以下のインタラクションで理解度をチェックしてください。

一般的には、ワーク、アサインメント、履歴の3種類のクラスのプロパティを含むレポートを作成します。 それぞれのレポートは、異なるデータベーステーブルにマッピングされたクラスのプロパティを使用します。

ワークレポート

ケースが作成されると、ワーククラスと継承クラス（パターン、有向）のプロパティを使用して、レポートが作成されます。 よく使用されるプロパティは以下の通りです。

• pyID – ケースの識別子
• pyWorkParty – 参加しているワーク班
• pxUpdateOperator – ケースを最後に更新したユーザー
• pxUpdateDateTime – 最後にアップデートを行った時間
• pyStatusWork – ケースのワークステータス

ワークレポートは、適切なワーククラス（TGB-HRApp-Workなど）で作成され、class mappingでは、必要なデータのソースとしてどのデータベーステーブルを使用するかを特定します。 パフォーマンスを最適化するために、レポートで参照されるプロパティは、データベーステーブルの列として公開されなければなりません。 列が公開されているかどうかを確認するには、Database Class Mappingsランディングページを使用し、クラスのColumns値をクリックしてテーブル内のすべての列を表示します。

アサインメントレポート

アサインメントは、ケースライフサイクルの中で作成され、通常、何らかの形でユーザーとのやり取りが必要となります。 作成されるアサインメントオブジェクトの主な2つのタイプは、ワークリスト（クラスAssign-Worklist）とワークバスケット（クラス Assign-WorkBasket）で、関連するクラスマッピングを使用して、それぞれデータベーステーブル「pc_assign_worklist」および「pc_assign_workbasket」にマッピングされます。 アサインメントが完了すると、アサインメントオブジェクトは削除され、ケースタイプのステップやステージでの処理に従って、別のオブジェクトが作成されます。

アサインメントレポートは、ユーザーのポータルに表示され、ユーザーのワークリストやアクセス権のあるワークキューにあるアサインメントがリスト化されます。 標準的なアサインメントレポート（pyAssignmentWorklistなど）は数多くありますが、これらのレポートは、特定のビジネス要件を満たすために特化されることがよくあります（例：ケースタイプのクラスに結合して関連するケースデータを返すなど）。 ケースタイプのクラスに結合する場合、アサインメントクラス「pxRefObjectKey」は、ケースタイプの「pzInsKey」と一致するように使用されます。

履歴レポート

履歴クラスのプロパティを使用して、パフォーマンスレポートを作成することができます。 たとえば、「pxTaskElapsedTime」というプロパティは、アサインメントに費やした合計時間を保存します。 アサインメントが複数のユーザーにルーティングされている場合、プロパティ「pyPerformTaskTime」は、その課題にすべてのユーザーが費やした合計時間を記録します。 「pyPerformTaskTime」が「pxTaskElapsedTime」よりも大幅に低い場合、その値はアサインメントが長時間アイドル状態になっていることを示しています。

次の画像で「+」アイコンをクリックして、3つの一般的なクラスマッピングの種類を確認してください。