Creación de las aplicaciones de reservas y FSG

Pega Academy le proporciona la oportunidad de practicar lo que aprende.

Pega Academy proporciona diferentes tipos de sistemas de ejercicios para que complete los ejercicios.

1. Instancia en la nube (en línea)
2. Máquina virtual (VM) (sin conexión)

Se puede acceder a la instancia de la nube (si está disponible) haciendo clic en el botón Initialize Pega (Inicializar Pega) en las instrucciones del reto del escenario.

La VM está disponible como un archivo OVA (Open Virtualization Archive) que contiene una versión comprimida "instalable" de una máquina virtual.  

Puede usar cualquier reproductor de VM de su elección, como Virtual Box (Windows, macOS), VMWare Player (Windows) o VMware Fusion (macOS). Usted es responsable de descargar e instalar su propio reproductor de VM.

Archivo de máquina virtual de ejercicio

La VM del ejercicio está disponible como un archivo .ova (archivo de virtualización abierto) que contiene una versión comprimida e “instalable” de una máquina virtual. Puede descargar el archivo .ova de la VM y su correspondiente suma de comprobación (.md5) mediante los siguientes enlaces:

LinuxLite-Pega861.ova 

LinuxLite-Pega861.md5

El archivo .ova pesa 7,5 GB y puede tardar en descargarse. Debido al gran tamaño del archivo, recomendamos usar Chrome o Mozilla para completar la descarga. Después de descargar el archivo .ova, puede usar el archivo de suma de comprobación (.md5) para asegurarse de que los datos dentro del archivo .ova estén completos y no se hayan dañado durante la descarga. Después de descargar el archivo, si tiene una extensión de archivo .tar (archivo de cinta), cambie el nombre de la extensión de archivo .tar a .ova antes de ejecutar la suma de comprobación o importarla.  Windows, macOS y Linux tienen utilidades integradas para generar sumas de verificación. Por ejemplo, en Windows, puede ejecutar el comando: “Get-FileHash LinuxLite-Pega861.ova -Algorithm MD5” desde PowerShell de Windows. 

Si usa Microsoft Internet Explorer, Microsoft Edge o Google Chrome, lea la guía Pega_Virtual_Machine_User_Guide_85.pdf para obtener información importante sobre cómo configurar correctamente la máquina virtual del ejercicio.

Use su software de virtualización (reproductor de VM) para abrir, importar y extraer el archivo .ova.

Si bien Pega no proporciona un reproductor de VM, le recomendamos que use uno de los siguientes: Virtual Box (Windows, macOS); VMWare Player (Windows) y VMware Fusion (macOS). La Guía del usuario de la máquina virtual proporciona detalles sobre cómo descargar e importar el archivo OVA y ejecutar la VM en uno de los reproductores de VM recomendados. Usted es responsable de descargar e instalar su propio reproductor de VM.

Debe importar el archivo RAP (Rule Application Product) de la solución de reserva de FSG proporcionado al comienzo del curso en su Pega Platform una vez que haya instalado la máquina virtual de Linux-Lite.  Para tener habilitadas todas las identificaciones de operadores durante la importación del archivo RAP, asegúrese de seleccionar las opciones “Enable advanced mode to provide more granular control over the import process” (Habilitar modo avanzado para proporcionar un control más granular sobre el proceso de importación) y “Enable new operators and overwrite existing operators on import” (Habilitar nuevos operadores y sobrescribir los operadores existentes en la importación).

Después del análisis de los requerimientos de la aplicación Booking (Reservas), se llega a las siguientes conclusiones: 

• El patrón de diseño Divide-and-Conquer es el que mejor se adapta a esta aplicación.
• Una jerarquía de subcasos es un mejor enfoque que usar procesos paralelos del mismo caso.
• Se crea un único subcaso meteorológico de forma incondicional.
• Se crea un único subcaso de estacionamiento de forma condicional.
• Se crea un subcaso de solicitud de habitaciones para cada hotel seleccionado de forma condicional.

La aplicación PegaRULES contiene un grupo de clase denominado PegaSample. El propósito de este grupo de clase es demostrar las características y capacidades de Pega Platform™. La cantidad de registros asociados con el grupo de clase PegaSample es mínima en relación con el resto de la aplicación PegaRULES. Sin embargo, los registros de PegaSample nunca se usan en una aplicación de producción. La aplicación PegaSample se puede empaquetar como una aplicación independiente basada en PegaRULES.

Una aplicación empresarial no necesita contener tipos de casos. El objetivo principal de la aplicación empresarial es proporcionar un modelo de datos de objetos comerciales estandarizados además de otros tipos de registros reusables, como bibliotecas. Esta descripción es acerca de la aplicación FSG Enterprise, que en teoría es mantenida por el grupo Centro de Excelencia (COE) de FSG. La aplicación de FSG no incluye ningún tipo de caso. Otras aplicaciones mantenidas por el grupo COE, como FSGEmail, están incorporadas en la aplicación FSG y contienen tipos de casos.

Todas las aplicaciones creadas con el asistente de nueva aplicación contienen una clase de grupo de trabajo y un grupo de clase. El asistente de nueva aplicación genera clases que comienzan con ORG-APP-[Data/Work/Int/UIPages] y clases que comienzan con ORG-[Data/Int]. El asistente de nueva aplicación también crea una clase abstracta ORG-FW independientemente de si se elige Framework, que se puede ignorar si no se usa.

De manera similar a la forma en que PegaRULES usa PegaSample, una aplicación empresarial debe ofrecer una forma de probar y demostrar las funciones que contiene. Al igual que PegaRULES, una aplicación empresarial no necesita incluir esos registros de prueba y demostración dentro de su aplicación. En su lugar, se puede desarrollar una aplicación de prueba y demostración sobre la aplicación empresarial. Esto plantea la pregunta de cómo se desarrolla la aplicación empresarial.

La aplicación FSG Enterprise se desarrolla mediante el asistente de nueva aplicación, que crea una aplicación denominada FSGSample. La aplicación inicial contiene los cuatro rulesets enumerados en la columna FSGSample App BEFORE de la siguiente tabla.

A continuación, se guarda una copia de la aplicación FSGSample como FSG en el ruleset de FSG. Los rulesets FSG y FSGInt se eliminan del ruleset stack de la aplicación FSGSample en su definición. En lugar de los rulesets eliminados, la aplicación FSGSample declara la aplicación FSG como una aplicación incorporada. A su vez, la aplicación FSG elimina los rulesets FSGSample y FSGSampleInt de su ruleset stack. 

Se necesita una pequeña cantidad de cambios para que la aplicación FSG sea válida, comenzando con la selección de una regla de máscara disponible, como CosmosSkin genérica u otra máscara de nivel de organización de FSG. Además, en la sección Associated Classes de la pestaña Cases and Data, los nombres de las clases deben actualizarse para hacer referencia a las clases válidas. Por ejemplo, en el caso de la aplicación FSG, las clases a las que se hace referencia deben ser específicas de FSG porque cada clase ORG amplía Work-Cover- la clase FSG se puede declarar un grupo de clases para que App Explorer muestre la clase FSG. Finalmente, la pestaña Application Wizard se puede editar para anunciar que la aplicación FSG está diseñada para usarse como una aplicación incorporada.

Por fines de coherencia, el Validation mode  de los rulesets FSG y FSGInt se cambia de Ruleset Validation a Application Validation. Esta opción proporciona más control sobre las versiones de los rulesets FSG  que están en uso por otras aplicaciones en un momento dado.

El equipo de reservas puede desarrollar la aplicación Booking (Reservas) sobre la aplicación FSG por sí mismo. En cambio, debido a que la aplicación Booking (Reservas) se considera fundamental para el éxito de FSG, el equipo del Centro de Excelencia (COE) cree que es mejor definir la primera etapa del caso BookEvent de la aplicación de reservas y luego dejar que el equipo de reservas desarrolle el resto.

El COE hace esto para garantizar que la fijación de precios se inicialice correctamente. El COE también quiere asegurarse de que el “Customer” se implemente como una referencia de FSG-Data-Contact, y que el lugar de un evento se implemente como una referencia de FSG-Data-Venue. Al almacenar la información del cliente en el esquema CustomerData fuera del BLOB, se evita tener que volver a ingresar la misma información cuando un cliente habitual desea reservar otro evento.

El equipo de reservas decide desarrollar su aplicación de forma altamente modular. De este modo, se facilita un desarrollo más rápido, ya que se puede realizar más codificación en paralelo. Además, el equipo de reservas no quiere refactorizar su aplicación en el futuro para descomponer uno o más subcasos en aplicaciones de componentes reusables. Las aplicaciones más pequeñas son más flexibles y fáciles de mantener e implementar. Esta estrategia es similar a la estrategia de microservicios, donde se evitan las aplicaciones monolíticas.

Para desarrollar y probar la aplicación Booking (Reservas), se debe extender cada tipo de caso definido dentro de una aplicación incorporada usando una herencia directa. Cada tipo de caso extendido e incorporado se implementa como caso hijo del caso BookEvent. El equipo de reservas primero crea un ruleset para cada tipo de caso hijo que creará dentro de la aplicación Booking (Reservas). El equipo de reservas crea cada tipo de caso hijo dentro de cada ruleset correspondiente. Posteriormente, la herencia directa de la clase de tipo de caso generada se cambia a la clase del tipo de caso de la aplicación incorporada correspondiente. Por último, se elimina la regla de tipo de caso que se generó en cada ruleset de tipo de caso hijo de la aplicación Booking (Reservas).

En el diseñador de casos de la aplicación Booking (Reservas), los tipos de casos WeatherPrep, BookingParking y RoomsRequest no se pueden editar porque no existe una regla de tipo de caso. La edición del Diseñador de casos se realiza dentro de las aplicaciones incorporadas WForecast, Parking y Hotel. Esta técnica evita el problema de “edición simultánea de dos aplicaciones”, donde las reglas pueden terminar en la capa incorrecta y en el ruleset incorrecto.

Este enfoque funciona bien para el equipo de reservas, y el equipo está satisfecho con el resultado. Como suele ser el caso, varias reglas consideradas innecesarias u obsoletas se retiran durante el desarrollo. Se realiza un skim importante en cada ruleset para hacer que esas reglas innecesarias u obsoletas ya no sean visibles.