Implementación de un modelo de datos eficaz

Después de iniciar sesión como administrador@FSGPricingTest y COE @FSG, observa un patrón. Las clases que se muestran en la vista Data Types de cada aplicación son las que posee la aplicación. La aplicación es principalmente responsable de probar, mantener y definir cómo se empaquetan e implementan esos tipos de datos.

Desde la aplicación de FSG, el equipo de reservas reutiliza las clases Contacto, Dirección y Ubicación; la omisión de esta acción no se puede justificar.

La clase Constant es reusable. El uso de la clase Constant  evita la codificación de valores que la empresa puede querer ajustar, controlar y mantener. La aplicación FSGSample no define un tipo de datos de solo prueba para demostrar cómo se usa la clase Constant. En cambio, la aplicación FSGSample usa la clase FSG-Sample-Work-TestConstants para demostrar cómo se puede usar la clase FSG-Data-Constant. El equipo de reservas debe decidir un enfoque, ya sea definir un tipo de datos ConstantProps o usar la configuración de la aplicación o algo intermedio.

La aplicación Booking (Reservas) puede usar potencialmente la clase Feedback después de la conclusión de un evento. La clase se usa para capturar datos del cliente sobre qué tan bien FSG organizó el evento.

El equipo de reservas tiene inquietudes sobre la clase Feedback. La aplicación FSGSample no demuestra cómo usar la clase Feedback. Actualmente, la clase Feedback es abstracta y contiene solo dos propiedades. Faltan otros tipos de reglas, como secciones o data transforms. El equipo de reservas también se pregunta si un gestor de eventos debe completar los valores después de comunicarse con el cliente o si el enfoque automatizado interactúa con un formulario de encuesta de Pega.

La primera etapa en la aplicación Booking (Reservas) consiste en cotizar el precio a un cliente (contacto) para realizar un evento en un lugar determinado. La aplicación Booking (Reservas) puede reusar los tipos de datos que posee la aplicación FSGPricingTest. Hay un tipo de datos de solo de prueba denominado PricingDisplay, que está definido por la aplicación FSGPricingTest; este es un indicio de que la aplicación Booking (Reservas) debe definir su propia clase PricingDisplay.

La clase Constant del COE de FSG tiene propiedades como Application, CaseUsage, Description y DataType. La aplicación FSGSample del COE de FSG contiene dos casos de prueba relacionados con su tipo de datos FSG-Data-Constant.

El caso TestAppConstantsLibrary de FSGSample define una página de datos D_FSGSampleConstants que origina un data transform denominado LoadConstantsForClass. El equipo de reservas sigue este ejemplo para definir las páginas de datos D_BookingConstantProps, D_HotelConstantProps y D_WeatherConstantProps.

El equipo de reservas consideró usar configuraciones de aplicaciones categorizables. Al equipo de reservas le gusta cómo la solución de COE de FSG admite la sintaxis de ruta de puntos para una propiedad con un tipo de datos que no sea texto.

Específicamente para la aplicación de reservas, al equipo de reservas le gusta cómo el COE de FSG modeló una pantalla de cotización de eventos de ejemplo en la que se usó un tipo de datos PricingDisplay. El componente de precios admite un parámetro de nombre de página PricingDisplayPage dentro de tres data transforms: Work-WorkRecalculatePrices, @baseclass RecalculatePrices y FSG-Data-Pricing Recalculate. La capacidad está ahí; el equipo de reservas también podría usarlo. Si lo hace, se ahorra el tiempo y el esfuerzo dedicados a crear esa funcionalidad por sí mismo.

El equipo de reservas creó una tabla como la que se usa para analizar y revisar el modelo de datos del COE de FSG. La columna Test-Only Data Types se reutiliza como una columna New Data Types where ownership is undecided.

El caso BookEvent del equipo de reservas necesita capturar información sobre un evento, como su fecha de inicio y finalización.  Organizar un evento es fundamental para el modelo de negocio de FSG; sin embargo, el caso BookEvent de la aplicación Booking (Reservas) es el único lugar, hasta ahora, donde se usa un tipo de datos de evento.

El equipo de reservas puede ampliar la clase FSG-Data-Hotel  propiedad de COE para su aplicación Hotel, pero no ve una necesidad inmediata de hacerlo.

El equipo de reservas podría extender la clase abstracta FSG-Data-Feedback para formar una clase concreta FSG-Data-Feedback-EventVenue. El equipo de reservas recomienda que el COE de FSG agregue una propiedad de referencia a FSG-Data-Feedback. Una definición de reportes se especifica dentro de la clase -EventVenue y realiza un JOIN a FSG-Booking-Work-BookEvent y un JOIN a la propiedad de referencia BookEvent case.VenueGUID a FSG-Data-Venue. El nombre del lugar puede cambiar desde el último registro de datos. Definir un JOIN con una propiedad de nombre no es una práctica recomendada, y es una violación de la integridad de los datos. El nombre del lugar se puede registrar por razones históricas, pero el nombre de la propiedad debe reflejar ese hecho (por ejemplo, .HistoricalVenueName).

La extensión del equipo de reservas de FSG-Data-Feedback can  se incorporará a la aplicación FSGSample2 para que otros equipos de desarrollo de nivel superior conozcan qué es posible hacer. En la lista de tareas pendientes de FSG, se encuentra el desarrollo de una forma común de enviar una encuesta de Pega, recibir la respuesta y luego persistir la respuesta en la capacidad adecuada FSG-Data-Feedback . 

Los datos persistentes no incluyen una propiedad en la que un Net Promoter Score se haya convertido en una categoría (promotor, pasivo, detractor). Si lo hicieran, también constituiría una violación de la integridad de los datos. Una definición de reportes puede usar una función SQL parametrizada de tres entradas personalizadas para derivar una categoría. El primer parámetro se completa con la propiedad de puntaje de promotor sin procesar. El segundo y tercer parámetro son el inicio y el final del rango de números enteros de la categoría (por ejemplo, 0 y 6 son el inicio y el final del rango “detractor”). La función SQL personalizada genera 1 si el primer parámetro se encuentra dentro del rango. De lo contrario, da como resultado 0. La definición de reportes agrega la columna mediante la función estandarizada de SQL SUM().

La aplicación Hotel y la aplicación Hotel Proxy se comunican mediante la API RESTful de Pega. Por varios motivos, como el tamaño de la aplicación, la seguridad y la facilidad de mantenimiento, la aplicación Hotel Proxy no se desarrolla sobre la base de la aplicación Hotel. Se debe definir un tipo de datos de RoomsRequest en el nivel de COE de FSG para que ambas aplicaciones hereden la base. Las aplicaciones Hotel y Hotel Proxy deben usar otro mecanismo para compartir la clase. Sin embargo, es necesario compartir las clases de integración REST que usan ambas aplicaciones. La conclusión lógica fue desarrollar un componente para albergar las clases compartidas y el código relacionado.

El COE no ha definido un conjunto de tipos de datos relacionados con el pronóstico del tiempo. Por lo tanto, el equipo de reservas debe decidir si su aplicación de pronóstico meteorológico posee esos tipos de datos. La previsión meteorológica no es imprescindible en el modelo de negocio de FSG. ¿Deberían otras aplicaciones usar los mismos tipos de datos de pronósticos meteorológicos pero ignorar la preparación meteorológica? ¿Qué impacto hay si el código para realizar ambos se empaqueta en conjunto? La suposición es que el código de pronóstico del tiempo es liviano.

La aplicación de estacionamiento se ocupa de diferentes tipos de ubicaciones, como estacionamientos o garajes. Los asistentes a un evento que deseen estacionar cerca querrán ver sus opciones de estacionamiento en un mapa.

La aplicación de transporte puede manejar cualquier ubicación, ya sea un lugar, un hotel o un espacio de estacionamiento. Este conocimiento refuerza la noción de que el COE de FSG debe definir una clase ParkingLocation. El equipo de reservas puede heredar esa clase directamente o heredar patrones, según sea necesario.

Finalmente, la aplicación Shuttle requiere tipos de datos relacionados con viajes de transporte. El equipo de reservas puede definir sus tipos de datos, pero ¿pueden otras aplicaciones aprovechar una abstracción de esos tipos de datos, como viaje, vehículo y empresa?

Organizar un evento es fundamental para la línea de negocio de FSG. Existe la posibilidad de que otras aplicaciones dentro de FSG, como Billing y Advertising, usen la misma definición de tipo de datos. A medida que pasa el tiempo, otras aplicaciones pueden agregar propiedades a FSG-Data-Event. Un cliente puede ponerse en contacto con un miembro del equipo de reservas para preguntar cómo se factura el alojamiento de un evento. La seguridad ABAC de lectura de propiedades se puede aplicar para enmascarar información que solo los miembros del equipo de facturación deberían poder ver. El miembro del equipo de reservas puede transmitir la información que el miembro del equipo puede ver y luego derivar al cliente al equipo de facturación si el cliente desea información detallada.

Una práctica recomendada es estandarizar las definiciones de personas y lugares en una empresa. Se recomienda que el COE de FSG mantenga las definiciones básicas para las clases que extienden FSG-Data-Location. Una razón para hacerlo es que las ubicaciones se almacenan en la misma tabla de esquema CustomerData. Cuando se crea la aplicación de transporte, se debe definir un viaje como si tuviera lugar en dos ubicaciones cualquiera, independientemente del tipo de ubicación. Es mejor dejar que el COE de FSG tome posesión de una clase ParkingLocation.

La siguiente tabla registra las decisiones tomadas con respecto al conjunto original de tipos de datos no definidos.

Se desconoce cuándo se debe iniciar el desarrollo de la aplicación Shuttle. El equipo de reservas sin duda puede beneficiarse si el COE de FSG diseña un modelo de datos abstracto donde cualquier Vehicle con una capacidad limitada hace Trips entre dos Locations. Con toda probabilidad, el Company propietario del Vehicle no es FSG. FSG no quiere que sus empleados se conviertan en despachadores de transporte a tiempo completo. En cambio, FSG quiere automatizar la toma de decisiones tanto como sea posible. Por ejemplo, el sistema funciona solo sin supervisión. La dependencia excesiva de los datos obsoletos podría conducir a una situación de “basura que entra = basura que sale”. La solución debe ser capaz de aceptar datos en tiempo real y tomar decisiones en tiempo real.