Estructura de la aplicación

Cualquier aplicación puede desarrollarse en base a otras aplicaciones. Cualquier aplicación puede aprovechar los componentes. Una aplicación se puede especializar de múltiples maneras, como por ejemplo utilizando la herencia de clases, la anulación de rulesets o, hasta cierto punto, la puesta en circunstancia. La herencia de patrón puede usarse para la especialización de clases en una aplicación. La herencia directa puede utilizarse para la especialización de clases entre una aplicación de capa superior y otra de capa inferior.

Todo lo descrito anteriormente se engloba en el término “arquitectura modular”. A estas alturas, ya no cabe duda sobre qué enfoque de la estructura de la aplicación debe utilizarse. El único debate en estos momentos es qué tan modular debe ser la estructura modular de la aplicación. La definición de la estructura comienza con la aplicación misma antes de buscar de manera descendente para identificar las dependencias. Las dependencias definen qué aplicaciones o componentes subyacentes deben existir previamente antes de que una aplicación pueda implementarse en otro sistema.

En la pestaña Application wizard, cualquier aplicación puede “anunciarse” como una aplicación reutilizable sobre la que se pueden desarrollar otras aplicaciones. Un componente, por definición, está diseñado para ser utilizado por múltiples aplicaciones. La herramienta New Application wizard es precisamente eso, una herramienta que tiene una larga historia que se remonta al momento en que una aplicación de framework era la única opción incorporada disponible. Inicialmente, Pega ofrecía la opción de generar simultáneamente tanto un framework como una aplicación de implementación.

Cuando se crea una aplicación, el asistente New Application (Nueva aplicación) comienza preguntando qué tipo de aplicación se desea crear.

Si selecciona una aplicación que no sea una aplicación principal proporcionada por Pega, por ejemplo, si selecciona la aplicación ORG/Enterprise, Pega asume que es posible que desee importar tipos de casos de esa aplicación a la aplicación que se está generando. Si no desea importar ninguno de los tipos de casos de la aplicación seleccionada, si los hubiera, puede desactivar el checkbox Include all case types (Incluir todos los tipos de casos) o puede desactivar individualmente los tipos de casos que no desee importar.

Si elige una aplicación propiedad de Pega, como Cosmos o Classic, el asistente New Application (Nueva aplicación) se comporta de forma diferente. A menos que genere una aplicación demo rápida, siempre haga clic en Advanced configuration para especificar la ORG y la parte de la APP del prefijo del nombre de la clase [Work/Data/Int] de la nueva aplicación.

De manera predeterminada, se genera una aplicación de implementación. La aplicación generada contiene cuatro rulesets, dos para la ORG y dos para la APP. Estos rulesets generados desarrollaron clases que establecen la Estructura de clase empresarial inicial, o ECS para abreviar.

En Advanced configuration, es posible elegir entre Framework o Implementation. Si se selecciona Framework , el asistente New Application (Nueva aplicación) genera rulesets que terminan en FW y contienen clases con un prefijo ORG-FW-APP.

El uso de esta opción de Framework perdió popularidad cuando Pega introdujo la compatibilidad con varias aplicaciones incorporadas (MBO) a partir de la versión 7.2.2. Esta opción solo debe seleccionarse cuando al inicio de un proyecto se sabe que un negocio ha expresado su deseo de aprovechar una aplicación de framework.

La opción Framework no debe elegirse solo en función de una garantía futura. Se requiere un esfuerzo adicional para desarrollar y mantener una aplicación de framework. El tiempo y el esfuerzo adicionales necesarios para desarrollar una aplicación de framework no pueden justificarse sin pruebas claras de que es necesaria.

Si opta por desarrollar a partir de una aplicación que no sea una aplicación principal proporcionada por Pega, eventualmente llegará a la misma pantalla name-the-application que contiene el enlace de configuración Advanced (Avanzada). Cualquier tipo de caso seleccionado para la importación es heredado directamente por un tipo de caso generado del mismo nombre. La clase de grupo de trabajo dentro de la aplicación a generar también hereda directamente la clase de grupo de trabajo dentro de la aplicación incorporada seleccionada. Puede cambiar esto después para que la clase de grupo de trabajo generada extienda Work-Cover- en su lugar.

Una aplicación es un objeto; los tipos de caso son objetos. Cada uno tiene diferentes puntos débiles. Una aplicación posee las clases Work/Data (Trabajo/Datos) en su ruleset. Los tipos de casos deben asociarse a un ruleset diferente del ruleset de la aplicación. Un tipo de caso que tiene el potencial de convertirse en una aplicación de componente (aún por definir) debe crearse en un ruleset específico para el tipo de caso. Evite crear dependencias entre los tipos de casos y las reglas definidas dentro de la clase de grupo de trabajo de una aplicación. No cree una regla dentro de la clase de grupo de trabajo de una aplicación simplemente porque dos tipos de casos diferentes usen una regla del mismo nombre y tipo, una propiedad de grupo de campos, por ejemplo. Las vistas se pueden definir con respecto a la clase de datos del grupo de campos. Ambos tipos de caso pueden reutilizar esa vista.

El asistente New Application (Nueva aplicación) siempre incluye dos rulesets ORG dentro de las aplicaciones que genera. Los ruleset ORG están configurados para usar el modo Ruleset Validation (Validación de rulesets) en lugar del modo Application Validation (Validación de aplicaciones).

Es un proceso sencillo colocar el ruleset de las dos ORG en una aplicación Enterprise independiente. El ruleset asociado a la regla de aplicación de la aplicación Enterprise debe ser el ruleset ORG. Se puede crear un registro de ClassGroup de la clase ORG ya que esta clase extiende Work-Cover-. Se puede crear una clase ORG-UIPages que extienda a Data-Portal y luego utilizarla como clase de UI de la regla de aplicación de la aplicación Enterprise.

La razón por la que se crea una aplicación Enterprise independiente es para que pueda ser tratada igual que cualquier otra aplicación en términos de implementación. Por ejemplo, la aplicación Enterprise puede tener su propio conducto de DevOps, aunque no continúe hasta el entorno de producción.

Se pueden definir diferentes versiones de la aplicación Enterprise en función de la versión de la aplicación PegaRULES en base a la cual se desarrolla la aplicación Enterprise. Del mismo modo, una aplicación que es una aplicación Enterprise incorporada puede declarar que depende de una determinada versión de esa aplicación Enterprise.