Consultas que hacen referencia a predecesores
Escenario
Suponga que un caso debe ser revisado por varios revisores independientes. Se puede solucionar de las siguientes maneras:
- Crear un caso hijo para cada revisor.
- Crear el mismo caso con Split For Each para cada revisor.
Suposición: cuando se recupera una asignación de cola de trabajo de revisión y se mueve a la lista de trabajo del revisor, el revisor se mantiene inmediatamente como parte de trabajo del revisor del caso hijo, por ejemplo pyWorkParty (Revisor).
El padre del caso al que hace referencia la asignación de la cola de trabajo no debe coincidir con el padre de ningún caso hijo que el revisor haya recuperado previamente.
- El caso hijo se crea para cada uno de los N revisores requeridos. La asignación inicial en cada caso hijo es una asignación de cola de trabajo. Cada revisor pide al sistema que extraiga una asignación de cola de trabajo de revisión en su lista de trabajo.
" data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="c10a17b8-dbbf-4ba1-8f76-1313fb00100a"> - En otras palabras, si se crean subflujos usando Split-For-Each en lugar de derivar casos hijo, la siguiente consulta evita que el mismo revisor use GetNextWork para extraer asignaciones de cola de trabajo para un caso que ya tiene.
Diseño de la solución
select pzInsKey from |
Suponga que el caso está dos niveles por encima del caso que debe recuperar un revisor. Los casos no tienen la propiedad pxCoverCoverInsKey
. Sin embargo, puede definir esta propiedad y usar un nombre de propiedad más significativo. Si el caso a revisar es un Claim (Reclamo), quiere definir una propiedad a nivel del grupo de trabajo llamada ClaimKey. El caso Claim (Reclamo) padre y abuelo determina un valor de ClaimKey igual a su pzInsKey y propaga la propiedad ClaimKey a sus casos hijo. Del mismo modo, esos casos hijos también propagan la propiedad ClaimKey a sus casos hijo.
Una alternativa es realizar lo que se conoce como “consulta jerárquica o recursiva”, que cada proveedor de base de datos implementa de manera diferente, pero que no es compatible con la regla de definición de reportes.
Curiosamente, si la meta es evitar que la misma persona revise el mismo caso dos veces y el diseño del caso no involucra casos hijo, la consulta anterior funciona igualmente bien si se elimina la palabra Cover (Cubrir). Si los subflujos se crean usando Split-For-Each en lugar de derivar casos hijo, la siguiente consulta evita que el mismo revisor, al usar GetNextWork
, obtenga asignaciones de cola de trabajo para un caso que ya ha revisado.
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); |
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?