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.
The figure illustrates the how the case, sub process assignments created by split for each and reviewers are linked. It also depicts that when a reviewer pulls an assignment from work queue using Get Next Work, it moves to his worklist and he becomes the workparty.
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.
La propagación de datos que se supone que permanecen estáticos también simplifican la definición de las reglas de decisión. Se debe tener cuidado con este enfoque, ya que es posible, aunque improbable, que la información se vuelva obsoleta o inexacta. Por ejemplo, el caso padre de un caso hijo se puede modificar cuando se invoca la actividad pxMove. Este escenario es un ejemplo en el que potencialmente puede ocurrir una violación de la integridad de los datos.
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:
If you are having problems with your training, please review the Pega Academy Support FAQs.
¿Quiere ayudarnos a mejorar este contenido?