Inclusive and exclusive queries

Within XPath there is the notion of the following axes, one of which is named “ancestor”. The definition of ancestor is parent, grandparent and so forth.

Suppose a case needing to be reviewed by multiple independent reviewers. A subcase is created for each of the N required reviewers. The initial assignment in each subcase is a workbasket assignment. Each reviewer asks the system to pull a Review workbasket assignment into their worklist. The parent of the case that the workbasket assignment references should not match any parent of a subcase that the reviewer has previously fetched.

Assumption: When Review workbasket assignment is fetched and moved to the reviewer’s worklist, the reviewer is immediately persisted as the subcase’s Reviewer work party, i.e., pyWorkParty (Reviewer).

select pzInsKey from
{Assign-WorkBasket} WB,
{Org-App-Work-Review} REV
where
WB.pxAssignedOperatorID = [workbasket]
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);

Suppose though that the case being review is two levels above the case to be fetched by a reviewer? Cases do not possess a “pxCoverCoverInsKey” property. Still, if you needed, you could define that property but should use a more meaningful property name. If the case to be reviewed is a Claim you would define a work pool-level property named “ClaimKey”. The “parent” and “grandparent” Claim case would set ClaimKey equal to its pzInsKey plus propagate that ClaimKey property to its subcases. Likewise those subcases would also propagate the ClaimKey property to their subcases.

Propagation of data assumed to remain static would also simply the definition of Access When rules. Care must be taken with this approach as it is possible, however unlikely, that the information can become stale or inaccurate. For example, the parent case of a subcase can be altered when the pxMove activity is invoked. This is an example where a data integrity violation can potentially occur.

An alternative is to perform what is known a hierarchical or recursive query which each database vendor implements differently but is not supported by the Report Definition rule.

Interestingly if the goal is to avoid the same person reviewing the same case twice, and the case design not involve subcases, the query shown above would work just as well if the word “Cover” was removed. In other word, if subflows are created using Split-For-Each, as opposed to subcases being spun off, the query below would prevent the same reviewer, using GetNextWork, from pulling a workbasket assignment for a case that the reviewer has already reviewed.

select pzInsKey from
{Assign-WorkBasket} WB,
{Org-App-Work-Review} REV
where WB.pxAssignedOperatorID = [workbasket]
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);