Skip to main content

包括的なクエリーと排他的なクエリー

シナリオ

  ケースには、複数の独立したレビュアーによるレビューが必要だとします。 次のような方法で解決できます。

  1. 各レビュアーに子ケースを作成する
  2. 各レビュアーにSplit For Eachで同じケースを作成する

前提として、レビューワークキューのアサインメントが取得され、レビュアーのワークリストに移動すると、レビュアーは即時に子ケースのレビュアーワークパーティ、例えばpyWorkParty(Reviewer)として永続化されます。

ワークキューアサインメントが参照するケースの親は、レビュアーが以前に取得した子ケースの親と一致することはできません。

  1. N人の必要なレビュアーごとに子ケースが作成されます。 各子ケースにおける最初のアサインメントは、ワークキューアサインメントです。 各レビュアーは、レビューのワークキューアサインメントを自分のワークリストに取り込むようシステムに依頼します。
    Multi case reviewer
    この図は、ケース、子ケース、レビュアーがどのようにリンクしているかを示しています。 また、レビュアーが子ケースを取得した場合に、レビュアーのワークリストに移動することでそのケースのワークパーティーになることも示しています。  
  2. つまり、子ケースをスピンオフする代わりにSplit-For-Eachを使用してサブフローを作成すると、次のクエリーによって、同じレビュアーがGetNextWorkを使用して、レビュアーがすでに持っているケースのワークキューアサインメントを引き出せないようにします
    Multicasereviewer_subprocess_v2
    この図は、ケース、Split For Eachにより作成されたサブプロセスのアサインメント、レビュアーがどのようにリンクしているかを示しています。 また、レビュアーがGet Next Workを使用してワークキューからアサインメントを引き出した場合に、レビュアーのワークリストに移動してワークパーティーになることも示しています。

 

ソリューション設計

select pzInsKey from
{Assign-WorkBasket} WB,
{Org-App-Work-Review} REV
where
WB.pxAssignedOperatorID = [workqueue]
and WB.pxRefObjectKey = REV.pzInsKey
and REV.pxCoverInsKey not in
(select REV2.pxCoverInsKey from
{Org-App-Work-ReviewCover} REV2, {Index-WorkPartyUri} WP
where
WP.pxInsIndexedKey = REV2.pzInsKey
and WP.pxPartyRole = "Reviewer"
and WP.pyPartyIdentifier = OperatorID.pyUserIdentifier);

レビュアーが取得しようとしているケースが2つ上の階層にあるとします。 ケースは、pxCoverCoverInsKeyプロパティを所有していません。 それでもそのプロパティを定義することはできますが、より意味のあるプロパティ名を使用します。 レビュー対象のケースがClaimの場合は、ClaimKeyというワークプールレベルのプロパティを定義する必要があります。 親や親の親(grandparent)のClaimケースはClaimKeyをそのpzInsKeyに設定し、ClaimKeyプロパティをその子ケースに伝搬します。 同様に、それらの子ケースもClaimKeyプロパティをその子ケースに伝搬します。

静止データを前提としたデータの伝搬も、Access Whenルールを定義するだけで済みます。 この方法であれば、情報が陳腐化したり不正確になったりする可能性は低いとはいえ、注意が必要です。 たとえば、pxMoveアクティビティが起動されると、子ケースの親ケースが変更されることがあります。 このシナリオは、データの整合性違反が発生する可能性がある例です。

別の方法として、階層クエリーまたは再帰クエリーを実行することもできます。実装は各データベースベンダーによって異なりますが、Report Definitionルールではサポートされていません。

なお、同じレビュアーが同じケースを2回はレビューしないようにすることを目的として、ケースデザインに子ケースを含めない場合は、Coverという単語を削除すれば、上記のクエリーは同じように機能します。 子ケースをスピンオフする代わりにSplit-For-Eachを使用してサブフローを作成すると、次のクエリーによって、同じレビュアーがGetNextWorkを使用して、レビュアーがすでに持っているケースのワークキューアサインメントを引き出せないようにします。

select pzInsKey from
{Assign-WorkBasket} WB,
{Org-App-Work-Review} REV
where WB.pxAssignedOperatorID = [workqueue]
and WB.pxRefObjectKey = REV.pzInsKey
and REV.pxInsKey not in
(select REV2.pxInsKey from
{Org-App-Work-Review} REV2,
{Index-WorkPartyUri} WP
where
WP.pxInsIndexedKey = REV2.pzInsKey
and WP.pxPartyRole = "Reviewer"
and WP.pyPartyIdentifier = OperatorID.pyUserIdentifier);

 


このトピックは、下記のモジュールにも含まれています。

If you are having problems with your training, please review the Pega Academy Support FAQs.

このコンテンツは役に立ちましたか?

改善できるところはありますか?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice