Patrones de diseño de caso

Los patrones de diseño son definiciones de componentes reutilizables o patrones de solución aplicados para resolver problemas recurrentes comunes. Como parte de un equipo COE, un PCLSA debe usar patrones de diseño de casos específicos para su dominio de negocio, lo que ayuda al equipo a crear rápidamente soluciones que se pueden reutilizar y mantener.

La noción de casos de Pega es única. En general, modelan un proceso de negocio. Los casos de Pega constan de una o más etapas con pasos y pueden contener casos hijo que forman una jerarquía de casos. Un caso padre puede interactuar con un caso hijo y viceversa. Los casos pueden, en raras ocasiones, interactuar con casos hermanos o pares sin ser parte de una jerarquía de casos. Por ejemplo, no es necesario crear un caso hijo para actualizar un caso padre existente. Los casos de nivel superior pueden actualizarse entre sí.

Los siguientes diseños de patrones pueden categorizar interacciones de caso.

1. Divide y vencerás (más común)
2. Inscripción/agregar una tarea a una lista de TAREAS
3. Instancia de datos en primer lugar
4. Disponibilidad limitada y concurrencia
5. Casos hermanos; uno actualiza al otro

Divide y vencerás es un conocido algoritmo computacional de solución de problemas. El trabajo a realizar se divide en unidades más pequeñas que se pueden resolver de forma independiente que, a su vez, se pueden dividir en unidades aún más pequeñas. Cuando se completa cada unidad hijo de trabajo, se notifica a su unidad padre de trabajo. Cuando se notifica a la última unidad hijo de trabajo de un padre, ese padre notifica a su padre, y así sucesivamente. Eventualmente, el padre que no tiene ningún padre, es decir, el caso de nivel superior, observa que se han completado todas las unidades hijo de trabajo. Cuando esto ocurre, el algoritmo se detiene.

El principal beneficio del enfoque Divide y vencerás es que las unidades hermano de trabajo se pueden resolver en paralelo. Esto reduce significativamente el tiempo total para completar el trabajo en comparación con el procesamiento secuencial. Este enfoque también proporciona una oportunidad más importante para la reutilización.

En el ámbito del procesamiento de negocio, un beneficio importante del enfoque Divide y vencerás es que las diferentes unidades de trabajo se pueden enrutar a las personas, los grupos o las colas de trabajo apropiadas que tienen las habilidades adecuadas para realizar el trabajo de manera eficiente. Se pueden establecer metas y fechas límite para completar el trabajo. Es una cuestión simple visualizar el grado en que el trabajo se ha completado o no en relación con un caso complicado, como un reclamo.

La siguiente imagen muestra una representación de muestra del patrón de diseño Divide y vencerás dentro del contexto de la aplicación Booking (Reserva).

El patrón de diseño de Enrollment/TODO list (Inscripción/lista de tareas) se implementa en Pega a través de las páginas de la UI. El diseño permite un enfoque Object-Action (Objeto-Acción). Es posible que ya exista un objeto que se pueda seleccionar o que ya se seleccionó para su visualización. El usuario luego le dice a ese objeto qué hacer. Las acciones de ejemplo incluyen actualizar o eliminar.

En el contexto de un objeto existente, también es posible decirle a la computadora que realice la acción de creación contra un nuevo objeto. La expectativa es que el nuevo objeto se asocie con el objeto existente. El nuevo objeto no necesita ser un caso hijo ni cualquier otro caso. En cambio, el nuevo objeto podría ser una instancia de datos que haga referencia al objeto existente.

Una de las principales ventajas de este patrón de diseño es que se evitan los problemas de bloqueo. Por ejemplo, se puede crear una instancia de datos que haga referencia a un caso existente en lugar de crear un caso hijo del caso actual. Se insertan los datos; nada se actualiza.

Un segundo beneficio es que si se aplica un solo acuerdo de nivel de servicio (SLA) a todos los elementos de datos ingresados, es más rápido y conveniente que los datos ingresados se traten como una “listas de tareas” que llenar la lista de trabajo de esa persona con múltiples asignaciones de casos hijo. Divide y vencerás no es aplicable ya que solo hay un "trabajador". El único beneficio derivado del uso de casos hijo es que se puede realizar un seguimiento del trabajo en un nivel más detallado si cada elemento de datos tiene un SLA.

El patrón de diseño Instancia de datos en primer lugar demuestra cómo se conservan los datos relacionados con un caso antes de crear un caso.

Por ejemplo, al usar mashup, no es necesario crear un caso de inmediato. En lugar de ello, los datos del caso se pueden conservar antes de que se cree el caso. En este ejemplo, se configura una interfaz mashup como Display a page (Mostrar una página) en lugar de Create a new case (Crear un nuevo caso).

Tenga en cuenta que la opción Create a new case de mashup también se puede relacionar con el patrón de diseño Instancia de datos en primer lugar. Create a new case cuenta con el respaldo directo de Case Designer (Diseñador de caso) en Pega Platform™ versión 8.5 con la adición de la etapa Create (Crear). La diferencia entre Display a page y Create a new case es que con Display a page la decisión de si se debe crear un caso se toma en el servidor después de que una instancia de datos persista.

Con la opción Create a new case ya se ha tomado la decisión de crear un caso, aunque temporal. La plantilla de circunstancias pyIsMashup permite ocultar el hecho de que se ha creado un caso, pero que aún no persiste. En particular, se puede hacer que la sección pyCaseMainInner muestre solo la plantilla de la sección Panel principal de la caja móvil. El resto de las funciones del portal del trabajador del caso, como el menú de navegación, Recientes, Contenido relacionado y Participantes, no se muestran.

Una clase de datos plana simple que no tiene páginas embebidas se puede conservar rápidamente en el esquema de CustomerData. Esto, sin embargo, sería una restricción importante desde la perspectiva de ingreso de datos de la UI. Idealmente, la UI también admitiría el ingreso de instancias de datos asociadas con la clase de datos original. Una solución sería definir una clase de datos de vista en la que se haya agregado una lista de grupo de campos a la definición de la clase de datos del modelo. Dado que el esquema CustomerData no permite páginas embebidas, cada página dentro de la lista de grupo de campos de la clase de datos de vista debe hacer referencia a la instancia de datos del modelo.

Se puede crear un caso después de que se hayan conservado los datos de la clase de datos View (Vista). Se puede invocar un caso POST de "casos" Pega API para crear el caso. Por ejemplo, una clase de datos Org-Data-MemberView contiene un grupo de campos Org-Data-Member. Después de que se persiste una instancia de Org-Data-Member, una página de datos D_CreateMember llama a un “caso” Pega API REST Connector. La página de contenido de la solicitud POST contiene una propiedad MemberGUID, cuyo valor es pyGUID de la instancia persistente Org-Data-Member. El caso que se crea tiene una propiedad MemberGUID, donde la página de contenido de la solicitud POST establece el valor. El caso también puede poseer una propiedad de referencia de datos Org-Data-Member definida como una página de datos de búsqueda. La propiedad MemberGUID proporciona el parámetro a esa página de datos de búsqueda..

Este patrón de diseño se parece al patrón Enrollment/TODO list (Inscripción/lista de tareas) en lo siguiente:

• Algo es preexistente, como un caso.
• Después, varias cosas, como datos o casos, quieren asociarse con el elemento preexistente.

Un ejemplo concreto que demuestra que esto sería una línea de ferry que transporta vehículos. Un caso Trip (Viaje) representa el ferry. Las personas solicitan reservar espacio en un Trip (Viaje) en particular para sí mismos y para su vehículo. 

El patrón de diseño de Disponibilidad limitada + Concurrencia se diferencia en lo siguiente:

1. La capacidad es limitada. Por ejemplo, existe un límite en el número de pasajeros y vehículos permitidos en el ferry.
2. La gestión de la concurrencia es esencial.

En cuanto a la gestión de la concurrencia, suponga que se realizan dos reservas al mismo tiempo para el mismo viaje. Solo queda suficiente capacidad para cumplir con una de las reservas; el otro intento debe agregarse al final de una lista de espera. ¿Son los casos hijo de Reservation (Reserva) la mejor solución a este problema?

La respuesta depende de la configuración de bloqueo. Si una configuración de bloqueo es tal que el padre y todos los casos hijo se bloquean simultáneamente, esta configuración resuelve el problema del exceso de reservas porque solo se puede hacer una reserva a la vez. Sin embargo, nadie más puede ingresar sus datos de reserva en paralelo, lo que también es una posible pérdida de recursos.

Si la configuración de bloqueo es tal que el caso hijo no bloquea el caso padre, esto presenta el problema potencial de reservas en exceso. Para agregar un caso hijo a un caso padre, el caso padre debe estar abierto y bloqueado. Si la capacidad del viaje está cerca de su límite y se realizan varias reservas simultáneamente para ese viaje, se deben realizar validaciones adicionales para garantizar que no se exceda la capacidad.

Por ejemplo, si la capacidad del ferry es de 500, no tiene sentido crear tantos casos hijo. Un enfoque más simple y rápido es insertar o actualizar instancias de datos de Reservation (Reserva) sin intentar bloquear nada. Las instancias de datos Reservation (Reserva) hacen referencia al caso Trip (Viaje). El tiempo que lleva escribir una sola fila en una sola tabla de base de datos es corto en comparación con el tiempo necesario para ejecutar un proceso de lock-query-save-commit-unlock (bloquear-consultar-guardar-confirmar-desbloquear).

El patrón de diseño de actualización de casos hermanos está representado por casos hermanos que interactúan entre sí en el mismo nivel en la jerarquía de casos. Pueden ser dos casos de nivel superior o dos casos hijo con el mismo caso padre. Por ejemplo, suponga que el caso A está relacionado con el caso B. Si hay un período de tiempo en el que el estado del caso B depende del estado del caso A, no hay razón para que el caso B sea un caso hijo del caso A. Ambos casos pueden ser hermanos para lograr este comportamiento.

Por ejemplo, en el escenario del ferry, el ciclo de vida del caso Trip (Viaje) finaliza cuando el ferry llega a su destino y los pasajeros han desembarcado. Un caso de Reservation (Reserva), implementado como un caso hermano y no como un caso hijo, puede avanzar a etapas como Facturación, Reembolso o Encuesta de satisfacción. Si el caso de Reservation (Reserva) se implementa como caso hijo del caso viaje, puede continuar adelante si el caso padre es resuelto. Sin embargo, el proceso anula la razón inicial para implementarlo como un caso hijo.

La decisión de implementar casos que interactúan como una relación de hermanos requiere tomar una decisión sobre la mejor manera de implementar esa relación. Las posibilidades incluyen (pero no se limitan a) usar la figura de flujo Update a case (Actualizar un caso) o el método Queue-For-Processing (Cola para procesar) en una actividad.