生成されたデータや再フォーマットされたデータに基づいたクエリー

たとえば、毎日作成されるケースの数と毎日解決されるケースの数をチャート化したトレンドレポートを作成するという要件があるとします。

前提として、ケースは完了までに1日以上かかる場合があります。

• ワークプール：分析したケースのワークプールクラスに対してトレンドレポートを定義しがちですが、これは適切な処理ではありません。 トレンドレポートには、2つの結果（たとえば、作成されたケースの数と解決されたケースの数）をプロットする対象の日付が必要です。 pxCreateDateTimeもpyResolvedTimeStampも、プロットの日付として使用できません。 その場合は、数日後に解決したケースは、ケース作成日にカウントされます。 あるいは、解決する数日前に作成されたケースは、解決した時点でカウントされます。
• 履歴テーブル：ケース履歴を照会して、ケース作成イベントとケース解決イベントを特定しようとする場合があります。 History-Workを使用して、ケース作成イベントとケース解決のイベントを特定することは可能ですが、複雑です。 また、履歴テーブルには、他の種類の情報を含む多数の行が含まれています。
• カスタムデータテーブル：ケース履歴内のケース作成イベントとケース解決イベントを検索するのではなく、別のデータタイプを定義できます。 たとえば、Data-SimpleCaseHistoryです。
  • String CaseID
  • String CaseType
  • String EventType
  • DateTime WhenOccurred

  ここで、EventTypeの許容値は、「Create」や「Resolve」など、最小限の値に抑えられています。 トレンドレポートは、このテーブルに対して単独で定義できます。 あるいは、pyID = CaseIDを使用して、ワークプールクラスをこのテーブルに結合できます。 いずれにせよ、各EventTypeはWhenOccurred DateTime値のDate値への切り上げに対してプロットされます。 このテーブル内のデータインスタンスは、過去にさかのぼって生成できます。

• タイムラインデータテーブル：別の解決策としては、プロットする日付を含むタイムラインテーブルを定義して入力できます。
  • Data-Timeline
  • Date Date
  • TrueFalse IsWeekStart
  • TrueFalse IsMonthStart
  • TrueFalse IsYearStart

  このテーブルには、必要な限りの過去と未来のデータを入力する必要があります。 他のトレンドレポートでも同じテーブルを活用できます。

  ただし、day()、CreateDate、ResolveDate DateなどのSQL関数の結果に基づいてJOINを定義できないため、ワークプールテーブル内にプロパティを追加して公開する必要があります。 また、これらのデータベース列にはインデックスを付ける必要があります。 Timelineテーブルを使用するクエリーでは、2つのサブレポートが必要です。1つ目のサブレポートは、CreateDateが指定されたTimeLine Dateと一致する行を選択してカウントします。 2つ目のサブレポートは、ResolveDateが同じTimeLine Dateと一致する行を選択し、その行数をカウントします。

まとめ

Timelineを使用すると、ワークプールテーブルに2回結合する必要があるため、SimpleCaseHistoryを使用する場合と同等のパフォーマンスになります。 また、メインレポートがGROUP BY集計を実行するのではなく、各サブレポートがCOUNTを実行するため、Listレポートとしてのみ使用し、チャート化できます。 SQLを使用すれば、2つのサブレポートの結果をUNIONできますが、PegaのReport DefinitionルールはこのSQLをサポートしていません。

理想的な解決策は、ワークプールテーブルに結合せずに、SimpleCaseHistoryクラスのみを基にしたトレンドレポートを作成することです。 この例では、データを抽出して別のフォームに永続化することで、ビジネスインテリジェンスを促進するというメリットを示しています。