Especialización por circunstancia, clase y ruleset

El código desarrollado según los principios de orientación a objetos es de por sí extensible. Pega admite la especialización de reglas según la circunstancia, la clase y el ruleset

Entre las tres técnicas de especialización en Pega, la especialización por clase ofrece la mayor flexibilidad y posibilidad de reutilización. 

• Las clases proporcionan la flexibilidad de seguridad más innovadora. 
• Las clases proporcionan la mayor flexibilidad para opciones de persistencia. 
• Las clases tienen prioridad durante la resolución de las reglas.
• Las reglas separadas por clases tienden a ser más fáciles de diferenciar y de navegar que aquellas separadas solo por rulesets o circunstancias.

La jerarquía de clase Data-Party es un ejemplo de una especialización por clase. Las clases derivadas pueden reutilizar o anular cualquier regla de la clase Data-Party. Por ejemplo, las clases Data-Party-Person y Data-Party-Operator anulan la actividad WorkPartyRetrieve.

Los rulesets pueden usarse de forma eficaz junto con las clases para proporcionar más flexibilidad en la administración de reglas y las estrategias de promoción para cada especialización.

Pega Platform aprovecha la especialización por ruleset para permitir la localización. Los valores de campo se almacenan en rulesets específicos de lenguaje. Pega tiene en cuenta el configuración regional indicada al final de la pestaña “Profile” (Perfil) del registro del operador del usuario a la hora de decidir qué ruleset ubicar en la parte superior del ruleset stack del perfil de aplicación del usuario.

Tenga en cuenta lo siguiente cuando diseñe su estructura de ruleset:

• Si hay dos rulesets en la misma aplicación que definen una regla con el mismo nombre en la misma clase, significa que la regla del ruleset más bajo dentro de la pila de aplicación no se ejecutaría nunca. 
• La resolución de ruleset es más específica que la resolución de clase. Por ejemplo, hay más flexibilidad para diferenciar las reglas de seguridad si se usa la especialización por clase en comparación con la especialización por ruleset.
• La navegación entre reglas que tienen el mismo nombre en diferentes rulesets puede ser más confusa que la navegación basada en la estructura de clase.

Las circunstancias le permiten especializar una regla en función de una propiedad o una fecha. Recuerde que la resolución de circunstancia ocurre después de la resolución de clase y ruleset. 

La seguridad entre circunstancias no existe. Por ejemplo, no puede controlar el acceso de lectura o escritura a reglas de la misma clase y ruleset, y tienen diferentes circunstancias, sin personalizar las reglas de seguridad. 

Además, si hay muchas versiones de circunstancia de la misma regla, la navegación puede ser más difícil que en el caso de las reglas separadas por clases. Dev Studio muestra reglas circunstanciadas con la navegación por contracción y ampliación en App Explorer. Para buscar reglas circunstanciadas, use Case Management > Tools > Find Rules > Find By Circumstance (Gestión de casos > Herramientas > Buscar reglas > Buscar por circunstancia).

Una ventaja de las circunstancias es que le permite ver la regla base y sus variaciones circunstanciadas en paralelo. El diseñador de casos también es compatible con esta vista de las reglas de tipo de caso circunstanciadas.

Circunstanciar reglas de tipo de caso trae varias desventajas en comparación con circunstanciar otro tipo de reglas, como reglas de decisión. Dev Studio muestra reglas mediante el alcance de nivel de solicitante. Las reglas de tipo de caso suelen circunstanciarse con una propiedad relacionada con el caso. Como resultado, las reglas circunstanciadas solo se resuelven en el contexto de un caso, que tiene un alcance a nivel de hilo, y tienen un tiempo de ejecución, no de diseño.

Debido a su alcance de nivel de solicitante, el diseñador de caso siempre muestra las versiones base de reglas circunstanciadas, como los flujos. Si se abre una regla circunstanciada desde otra regla, se mostrará la versión base de dicha regla. Es necesario usar la opción de menú de la regla Action > View siblings (Acción > Ver reglas del mismo nivel) para ubicar la variación circunstanciada correcta de la regla base. En el caso de las reglas relacionadas entre sí, como suele pasar en un diseño de caso, este proceso puede volverse tedioso. Las reglas de tipo de caso circunstanciadas, que pueden visualizarse en el diseñador del caso, no son una solución a esta desventaja.

Un framework es una referencia de procesamiento de trabajo que puede ampliar a una implementación. El diseño de un framework requiere saber cómo se utiliza en más de una implementación.

Sin esta información, es difícil abstraer un modelo común para ambas implementaciones. Concéntrese en la implementación al principio, cuando analice la especialización futura.

En la siguiente imagen, se muestra cómo Pega Platform admite las dimensiones de especialización por clase y ruleset. En este ejemplo, el equipo del centro de excelencia (COE) es responsable de trabar la aplicación de base MyApp 01.01.01. El COE también es responsable de desarrollar la siguiente versión de la aplicación de referencia o base MyApp (por ejemplo, 02.01.01).

Las aplicaciones de producción, MyAppEU y MyAppUK, permanecen incorporadas a MyApp 01.01.01 hasta que puedan actualizarse a la versión 02.01.01 de MyApp. Es similar a la actualización de aplicaciones a una versión más reciente de Pega Platform. El propósito del eje de la versión de aplicación es permitir la evolución (actualización y versionado) de las aplicaciones, incluida la aplicación de referencia. Observe cómo las aplicaciones de producción aprovechan la dimensión de ruleset, aunque ambas aplicaciones no necesitan aprovechar la dimensión de clase.

Suponga que la población de usuarios del Reino Unido es más pequeña que la población de usuarios que no son del Reino Unido, y que ambas poblaciones permanecen en la base de datos original. Asimismo, suponga que el Reino Unido quiere almacenar sus datos de caso de forma separada, por lo que opta por la herencia directa para sus clases de tipo de caso. Es necesario migrar los casos existentes del Reino Unido a nuevas clases de tipo de caso, además de implementar necesidades de seguridad para evitar que la aplicación MyAppEU acceda a los datos de MyAppUK y viceversa.

Desde la perspectiva de la aplicación MyApp, no existe diferencia al separar los usuarios de MyAppUK en una nueva población de usuario o comenzar con usuarios que no son del Reino Unido y agregar usuarios que sí sean del Reino Unido más adelante, pero a una aplicación específica. En cualquier caso, la aplicación MyApp debe administrarse con cuidado porque admite dos conjuntos de usuarios.

La aplicación MyAppEU puede usar la especialización por ruleset porque no es necesario migrar sus casos de población de usuario a diferentes nombres de clase. Esto se aplica, ya sea que se use la misma base de datos o una nueva para la población de usuarios dividida o nueva. La única diferencia es que, si se utiliza la misma base de datos, se necesitará una seguridad adicional y una herencia. Si se tuviera que trasladar la población nueva de usuarios a una base de datos nueva, no sería necesario usar la dimensión de clases. La dimensión de ruleset sería suficiente.