Cambio dinámico de clases
La capa Empresa es libre de definir reglas aplicadas a las clases ORG, Work-Cover- o Work- que hacen referencia a las clases ORG-Data-. Las clases ORG-APP-Work de la capa de aplicación también son libres de hacer referencia a las clases ORG-Data. Las clases ORG-APP-Work de la capa Aplicación también pueden hacer referencia a las clases ORG-App-Data.
Supongamos que una clase de datos se puede compartir entre aplicaciones del mismo nivel. En ese caso, como es importante para la empresa, tiene sentido definir la parte compartible como una clase ORG-Data. Cada aplicación del mismo nivel es libre de extender esa clase de datos de la capa Empresa para adaptarla a sus necesidades específicas.
El código de la capa Empresa, que es extensible a la capa Aplicación, puede aprovechar el hecho de que las clases de datos de la capa Empresa pueden extenderse a capas superiores.
Ejemplo de clase de cambio lista para usar
Pega usa px, py y pz como prefijos para sus propiedades.
El prefijo px por lo general significa que el valor de una propiedad debe permanecer invariable una vez establecido su valor. Entre los ejemplos, se incluyen pxCreateDateTime y pxCreateOperator que registran información histórica. Algo solo puede crearse una vez por quien lo creó.
Cuando se trata de decidir qué prefijo usar para la propiedad que representa la clase Apply-to de una regla, Pega usa el prefijo px. Sin embargo, Pega, por ejemplo, durante la asignación de la transferencia cambia el valor de pxObjClass durante el tiempo de ejecución de Assign-WorkBasket a Assign-Worklist y viceversa mediante la utilización del método Page-Change-Class.
El método de actividad Page-Change-Class tiene un parámetro de conservación. Ignorando la tercera opción, más compleja, con el valor 2, los restantes valores de los parámetros de conservación son los siguientes:
- 0 = el valor de cualquier propiedad presente se mantiene igual
- 1 = el data transform sobrescribirá el valor de cualquier propiedad presente
La conclusión es que pxObjClass se puede cambiar durante el tiempo de ejecución, pero hay que hacerlo con cuidado.
Por ejemplo, no es necesario configurar una tabla de decisión para devolver un nombre de clase y alterar la pxObjClass, sino que se debe intentar crear el nombre de la clase utilizando la herencia de patrón anexada por el tipo de especialización. Sin embargo, esto puede no ser posible cuando se quiere cambiar la clase de trabajo a datos.
Referencias de clases dinámicas (RCD) es un patrón que se ha utilizado en Pega cuando el valor pxObjClass de un objeto se decide durante el tiempo de ejecución en lugar de hacerlo durante el tiempo de diseño.
Instanciar páginas de diferentes clases utilizando código reutilizable
Normalmente, una página de datos Lookup con una sola clave, como pyGUID, utiliza un solo parámetro pyGUID. La página de datos D_Location, sin embargo, tiene un segundo parámetro Type. La página de datos D_Location origina una actividad LoadLocationDCR que utiliza el parámetro Type de la siguiente manera:
Cuando el parámetro Type !="" continúe procesando. De lo contrario, vaya al paso GO.
Establezca param.ObjClassNew = "FSG-Data-" + param.Type
Llame a PageChangeClass pasando la página principal como página principal.
GO
Abra una instancia de FSG-Data-Location (Location) en LocationTEMP
pasando param.OpenClass como Primary.pxObjClass
usando param,pyGUID el valor para la clave de la clase, .pyGUID
Copie LocationTEMP en Primary
Elimine LocationTEMP de la memoria
Este parámetro Type le dice a Pega que cree una página LocationTEMP basada en el valor de Primary.pxObjClass después de que se haya cambiado. Independientemente de la clase derivada, Pega accede a la fila de la tabla de base de datos Location que coincide con el pyGUID suministrado. Pega no solo devuelve las propiedades definidas por FSG-Data-Location. En cambio, Pega devuelve todas las propiedades de la tabla Location asociada a la clase Location derivada. La página original D_Location estaba definida en la clase FSG-Data-Location, pero cambiando el nombre de la clase podemos sacar los datos de la instancia ParkingLocation y también asegurarnos de tener la clase cambiada como pxObjClas en la página de datos.
Esta actividad muestra que se puede escribir código reutilizable para instanciar páginas con diferentes clases. Las clases generadas sobre la marcha NO realizan lecturas a partir de la tabla de base de datos. No hay ninguna columna pxObjClass en el esquema de datos del cliente.
La clase de la página de datos puede cambiarse en función del parámetro Type, garantizando así la creación de una única página de datos que puede utilizarse para cualquier clase.
Ejemplo de referencia de clase dinámica
Use la RCD en relación con una clase con un tipo claramente definido en lugar de una clase que no tiene uno, como ORG, ORG-App, [*]-Data y [*]-Work. Dentro del código de solución proporcionado por la misión, hay dos aplicaciones de muestra relacionadas: FSGSample y FSGSample2. En cada aplicación de ejemplo se definen dos tipos de casos similares: Roadside Assist (Asistencia en carretera) y Service Complaint (Reclamos de servicio).
Estos cuatro tipos de casos utilizan y extienden el mismo tipo de datos genéricos: FSG-Sample-Data-Vehicle. La siguiente imagen muestra tres especializaciones de *-Data-Vehicle dentro de cada capa, siendo las especializaciones -Car, -Truck y -Motorcycle.
Una forma común de usar la RCD es definir un tipo de datos para toda la aplicación con una propiedad para cada valor (por ejemplo, .MotorCycleClass). Dentro de este tipo de datos para toda la aplicación se define una página de datos, normalmente denominada D_AppExtension. Esa página de datos utiliza un data transform para completar los valores de propiedades de la página de datos. Un valor se recupera utilizando sintaxis como D_AppExtension.MotorCycleClass. Las capas por encima de la capa que definió el tipo de datos para toda la aplicación anularían ese data transform de la página de datos AppExtension. Tenga en cuenta que este enfoque no se adhiere al principio de abierto y cerrado. Cada vez que se define una nueva clase derivada, se debe añadir una nueva propiedad al tipo de datos AppExtension.
La forma modular de usar la RCD dentro de una jerarquía de clases es definir una página de datos de RCD en la base de esa jerarquía de clases. Dentro de la solución proporcionada, la clase FSG-Sample-Data-Vehicle define una página de datos D_VehicleDCR. El único propósito de esta página de datos es establecer su pxObjClass basándose en el valor del parámetro Type requerido de la página de datos. Para ello, utiliza un data transform denominado LoadVehicleDCR.
El código en FSGSample, en realidad, no usa D_VehicleDCR. El código puede llamar directamente al data transform LoadVehicleDCR. Lo hace dentro de la etapa de creación del caso Service Complaint (Reclamos de servicios). La sección FSG-Sample-Data-Vehicle IdentifyVehicle tiene un control de autocompletar que establece la propiedad Vehicle's .Type. Al cambiar, la sección se actualiza. Antes de la actualización, se invoca el data transform LoadVehicleDCR. La propiedad .Type proporciona el valor del parámetro Type. La actividad PageChangeClass se activa para cambiar la clase en función de la propiedad type.
La meta principal de los dos casos de ejemplo Vehicle (Vehículo) es mostrar que las clases polimórficas definidas en dos capas diferentes pueden persistir y recuperarse de la misma tabla de base de datos del esquema CustomerData: una tabla que no tiene las columnas pzInsKey ni pxObjClass.
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?