Procesamiento de casos
Procesamiento de casos
El procesamiento de casos está a cargo de tres tipos principales de solicitantes: servicios (aplicación), procesos en segundo plano (lote) y usuarios “web” (navegador). Un usuario web puede ser un robot en vez de un ser humano. Cada solicitante lo ejecuta dentro de su propio hilo de Java. Los hilos de Java independientes permiten que varios solicitantes realicen acciones en paralelo.
El diseño del caso afecta la eficiencia con la que procesa el trabajo. Un diseño de caso eficiente da cuenta de pasos o procesos que pueden ser realizados en paralelo por solicitantes separados. Un ejemplo es idear una forma que permita a diferentes usuarios aprobar o rechazar el mismo elemento de línea de alto costo al mismo tiempo sin interferir entre sí. Un solicitante web independiente realiza cada aprobación. Si se requiere una solución más escalable para el mismo ejemplo, las tareas de cola se pueden realizar en un procesador en segundo plano para lograr la aprobación automática.
Consideraciones del procesamiento paralelo
Cuando se requiere que varias personas trabajen en un caso simultáneamente en un momento determinado, como ocurre con el patrón Divide y vencerás, se debe elegir entre el procesamiento del mismo caso, de un subcaso y de un caso hermano.
Se pueden tener en cuenta varios factores:
|
|
La importancia de cada factor depende de la situación en cuestión.
Bloqueo
Para la entrada del usuario que es de muy corta duración, el bloqueo del mismo caso que permite que solo un colaborador acceda al caso a la vez es intrascendente. Los colaboradores pueden comunicar en un correo electrónico o en alguna otra herramienta de colaboración que les gustaría tener acceso al caso pronto. Los usuarios pueden adjuntar contenido relacionado a un caso al mismo tiempo sin interferir entre sí. Una instancia de datos puede emplear el mismo enfoque de no interferencia utilizado por la instancia de PegaSocial-Document que hace referencia a un caso. Un ejemplo en la aplicación de reserva de la misión Lead System Architect es FSG-Data-Pricing.
Seguridad
La seguridad es una preocupación menor para un caso simple con un tipo de propietario. Si cada caso fuera propiedad de una Persona, la seguridad se simplificaría.
Crear un caso hijo dentro de una etapa simplemente por motivos de seguridad es contrario al principio Divide y vencerás, ya que el trabajo en sí no se divide, solo se reasigna. El acceso se simplifica para una Persona, pero se hace más complejo para otras Personas N-1 a las que se debe evitar que accedan al caso hijo. Hay otras formas de controlar el acceso al tipo de caso en función de la Persona.
La landing page de Access Manager (Gerente de acceso) admite la visualización y administración, hasta cierto punto, de la relación entre grupos de acceso (personas) y tipos de casos desde una perspectiva de RBAC. Para el acceso condicional, el Access Manager (Gerente de acceso) le permite elegir una regla de decisión. ABAC también puede usar una regla de decisión.
Creación de reportes
La simplificación de la creación de reportes va de la mano con la simplificación de la seguridad. Pega posee definiciones Report Definitions (Definiciones de reportes) basadas en la etapa del caso (por ejemplo, Work-pyGetWorkinStage y pyCountByStage).
Creación de reportes: acceso a Datos por el Caso
La complejidad de la creación de reportes no justifica la creación de un caso adicional. Por ejemplo, el Patrón de diseño de disponibilidad limitada y concurrencia constituye el argumento a favor del uso de instancias de datos en lugar de subcasos. Si los datos se conservan dentro o fuera del BLOB del caso, no tiene nada que ver con el diseño del caso; en cambio, es una decisión del modelo de datos.
Creación de reportes: acceso a datos para creación de reportes
Si las preocupaciones de seguridad justifican la creación de un caso separado, entonces los reportes sobre casos y asignaciones también se benefician de tener un caso separado.
Rendimiento
Una sobreabundancia de casos y asignaciones en comparación con instancias de datos más simples podría tener un impacto negativo en el uso de la base de datos y la RAM. El patrón de diseño de Enrollment/Add a Task to a TODO list (Inscripción/agregar una tarea a una lista de TAREAS) demuestra esta preocupación. Un crucero que representa a cada pasajero como un subcaso consume más recursos que si representa a un pasajero como una instancia de datos. Desea evitar el uso de la landing page My Cases (Mis casos) o ver una lista WorkQueue, teniendo en cuenta que un crucero en promedio transporta 3.000 pasajeros.
Varios subcasos más pequeños consumen menos memoria del portapapeles (si no se abren al mismo tiempo) en comparación con los mismos datos que se almacenan en el BLOB de un solo caso. El grado en que esto es una preocupación depende de la cantidad de datos almacenados en el BLOB en comparación con la cantidad de datos almacenados fuera del BLOB.
Potencial de especialización
Los Principios de separación de preocupaciones y responsabilidad única favorecen los casos más pequeños porque los casos son más fáciles de desglosar en una aplicación de componente incorporado y modular. Un caso que se adhiere a esos dos principios se especializa más fácilmente a través de la herencia directa de capa superior o la herencia de patrón de la misma capa.
Acceso a contenido relacionado con el subcaso
En versiones anteriores de Pega, antes del cambio de Pega 8 para implementar contenido relacionado, existía una opción de archivos adjuntos de casos que permitía incluir archivos adjuntos de subcasos en la lista de archivos adjuntos de un caso, no solo los archivos adjuntos que hacen referencia al caso padre. No existe esta opción actualmente. Solo en raras circunstancias, la capacidad de ver todo el Related Content (Contenido relacionado) dentro de una jerarquía de casos al mismo tiempo se vuelve lo suficientemente preocupante como para favorecer un solo caso sobre los subcasos.
Gestión de dependencias de subcaso
Una capacidad que se obtiene mediante subcasos que es difícil de lograr mediante el subproceso Split-For-Each-or-Join (Cada-uno-separado-o-unido) es la capacidad de definir una Wait shape (Figura de espera) basada en la dependencia del tipo de caso. Si existe este tipo de complejidad de casos, la decisión de usar subcasos en lugar del procesamiento del mismo caso se toma no solo desde una perspectiva de administración de dependencias, sino también desde otras perspectivas (como Seguridad, Creación de reportes y Bloqueo).
Anulación de política (si corresponde).
Una capacidad de Pega que se usa con poca frecuencia es suspender un caso en función de una decisión Declare-OnChange (Declarar sobre cambio), lo que no permite que el caso continúe hasta que se investigue. Es más fácil suspender y reactivar un caso que todos los casos en una jerarquía de casos. Si esta característica fuera esencial, podría entrar en juego con respecto a una decisión de diseño del caso. En su lugar, se pueden implementar otros medios, como cambiar a una etapa alternativa. Se puede usar la misma condición Declare-OnChange (Declarar sobre cambio). La diferencia es la acción que toma la regla Declare-OnChange (Declarar sobre cambio) como reacción a la condición que se cumple.
Procesamiento ad hoc (si corresponde)
Un caso ad hoc, o Work-Cover-SimpleCase, define una tarea o lista de tareas cuando surge una situación atípica. Esta opción es útil cuando no hay suficiente tiempo para esperar a que se actualice la aplicación. Un caso ad hoc se puede convertir en un tipo de caso oficial mediante la opción Configure for Reuse (Configurarlo para la reutilización). Tenga en cuenta que los usuarios deben recibir capacitación sobre cómo usar esta función. El botón Quick Create (Creación rápida) se encuentra en la landing page My Cases (Mis casos).
Consideraciones de procesamiento dentro del caso
Para la implementación de reglas que Case Designer (Diseñador de caso) podría aprovechar, diseñe teniendo en cuenta la configurabilidad. La forma en que se diseña internamente un caso es importante. La audiencia para un diseño de caso no es solo Senior System Architects (SSA) y Lead System Architects (LSA): la audiencia puede incluir a cualquiera que participe en el desarrollo y mantenimiento de la aplicación.
El Case Designer (Diseñador de caso) utiliza figuras inteligentes que simplifican la interfaz con otras reglas, como actividades. Por ejemplo, la figura Send Email (Enviar correo electrónico) permite especificar los parámetros necesarios para invocar la actividad CorrNew. Un ejemplo más complejo es la figura Approve/Reject (Aprobar/Rechazar), que es un contenedor para el subflujo pxApproval con parámetros de trabajo que contiene 19 parámetros configurables. Pega simplifica la configuración de los parámetros de subflujo mediante un panel de tres columnas, como se muestra en la siguiente imagen:
Un ejemplo simple de encapsulación de funcionalidad es un subflujo Work-AllCoveredResolved que consta de lo siguiente:
- Asignación única con la acción de flujo pyContinueAfterWait que lleva a la figura final con el ticket AllCoveredResolved
- Parámetros = WorkQueue, ServiceLevel, WaitReason
La aplicación Booking (Reserva) usa un componente AllCoveredResolved proporcionado por FSG COE al final de su caso Book Event (Evento de reserva). El componente evita agregar figuras Timer Wait (Espera de temporizador) redundantes al final de cada proceso paralelo dentro de la etapa Manage Event (Administrar evento), donde cada Timer (Temporizador) esperaría a que llegara el mismo momento (.Event.EndDT).
El COE de FSG también proporcionó un subflujo Work- Approval Queue (Cola de aprobación de trabajo). Este subflujo admite la configuración de aprobación en paralelo. Consiste en lo siguiente:
- Una lista Work- Approvers Field Group (Grupo de campos de aprobadores de trabajo) de la clase Data-Admin-Operator-ID
- Propiedades NumApprovals y NumRejections
- Parámetros de subflujo = WorkQueue, ApprovalsNeeded, RejectionsNeeded, ApprovalPurpose
- Una figura Fork (Horquilla) delante de una WorkQueue de circuito cerrado
- Al ingresar al subflujo, NumApprovals y NumRejections se establecen en 0, y se elimina la lista de grupo de campos Approvers (Aprobadores).
Los operadores actualizan su propia página en la Approvers Field Group List (Lista de grupo de campos de aprobadores). Cuando se alcanza un umbral, ya sea ApprovalsNeeded o RejectionsNeeded, se sale del flujo de bucle invertido.
El subflujo de Approval Queue (Cola de aprobación) se utiliza en la etapa de aprobaciones de FSG del caso Book Event (Evento de Reserva) de la aplicación Booking (Reservas). Dentro del Case Designer (Diseñador de casos), este subflujo podría configurarse de modo que la aprobación de dos administradores de eventos constituya una aprobación general; de lo contrario, dos rechazos constituirán un rechazo general. Dentro de la solución proporcionada, solo se necesita una aprobación o rechazo.
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?