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);

 


トレーニングを実施中に問題が発生した場合は、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