包括的なクエリーと排他的なクエリー
シナリオ
ケースには、複数の独立したレビュアーによるレビューが必要だとします。 次のような方法で解決できます。
- 各レビュアーに子ケースを作成する
- 各レビュアーにSplit For Eachで同じケースを作成する
前提として、レビューワークキューのアサインメントが取得され、レビュアーのワークリストに移動すると、レビュアーは即時に子ケースのレビュアーワークパーティ、例えばpyWorkParty(Reviewer)として永続化されます。
ワークキューアサインメントが参照するケースの親は、レビュアーが以前に取得した子ケースの親と一致することはできません。
- N人の必要なレビュアーごとに子ケースが作成されます。 各子ケースにおける最初のアサインメントは、ワークキューアサインメントです。 各レビュアーは、レビューのワークキューアサインメントを自分のワークリストに取り込むようシステムに依頼します。
- つまり、子ケースをスピンオフする代わりにSplit-For-Eachを使用してサブフローを作成すると、次のクエリーによって、同じレビュアーがGetNextWorkを使用して、レビュアーがすでに持っているケースのワークキューアサインメントを引き出せないようにします。
ソリューション設計
select pzInsKey from |
レビュアーが取得しようとしているケースが2つ上の階層にあるとします。 ケースは、pxCoverCoverInsKey
プロパティを所有していません。 それでもそのプロパティを定義することはできますが、より意味のあるプロパティ名を使用します。 レビュー対象のケースがClaimの場合は、ClaimKeyというワークプールレベルのプロパティを定義する必要があります。 親や親の親(grandparent)のClaimケースはClaimKeyをそのpzInsKeyに設定し、ClaimKeyプロパティをその子ケースに伝搬します。 同様に、それらの子ケースもClaimKeyプロパティをその子ケースに伝搬します。
別の方法として、階層クエリーまたは再帰クエリーを実行することもできます。実装は各データベースベンダーによって異なりますが、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); |
このトピックは、下記のモジュールにも含まれています。
- 高度なクエリー設計 v3