Consultas basadas en datos generados o reformateados

Suponga que existe el requerimiento de crear un reporte de tendencias en el que el gráfico muestre la cantidad de casos creados cada día y la cantidad de casos resueltos cada día.

Suposición: los casos pueden tardar más de un día en completarse.

• Equipo de trabajo: existe la tentación de definir el reporte de tendencia respecto de la clase de equipo de trabajo de los casos analizados, pero esto no es correcto. Un reporte de tendencias requiere una Fecha contra la cual trazar los dos resultados (como la cantidad de casos creados frente a la cantidad de casos resueltos). pxCreateDateTime y pyResolvedTimeStamp no se pueden usar como fecha de trazado. Si es así, los casos resueltos días después se cuentan el día de la creación del caso. O bien los casos creados días antes de que se resuelvan se cuentan cuando se resuelve el caso.
• Tabla de historial: se podría intentar consultar el historial de casos para identificar eventos de creación y resolución de casos. Si bien es posible usar History-Work (Historial-Trabajo) para identificar eventos de creación y resolución de casos, es complejo. Además, la tabla de historial contiene numerosas filas con otros tipos de información.
• Tabla de datos personalizados: en lugar de buscar eventos de creación y resolución de casos dentro del historial de casos, puede definir un tipo de datos separado. Por ejemplo: Data-SimpleCaseHistory
  • Cadena CaseID
  • Cadena CaseType
  • Cadena EventType
  • DateTime WhenOccurred

  Aquí, los valores permitidos para EventType se mantienen al mínimo, por ejemplo, “Create” (Crear) y “Resolve” (Resolver). Un reporte de tendencia se puede definir en esta tabla por sí mismo. O bien la clase del equipo de trabajo se puede unir a esta tabla usando pyID = CaseID. De cualquier manera, cada EventType se traza contra el truncamiento del valor WhenOccurred DateTime en un valor Date (Fecha). Las instancias de datos en esta tabla se pueden generar retroactivamente.

• Tabla de datos de línea de tiempo: una solución diferente es definir y completar una tabla Timeline (Línea de tiempo) que tenga las fechas contra las cuales trazar.
  • Data-Timeline
  • Date Date
  • TrueFalse IsWeekStart
  • TrueFalse IsMonthStart
  • TrueFalse IsYearStart

  Esta tabla debe completarse tanto en el pasado como en el futuro según sea necesario. Otros reportes de tendencias podrían aprovechar la misma tabla.

  Sin embargo, debido a que no es posible definir un JOIN basado en el resultado de una función SQL como day(), CreateDate y ResolveDate Date, las propiedades deben agregarse y exponerse dentro de la tabla del equipo de trabajo. Esas columnas de la base de datos también deben indexarse. La consulta que usa la tabla Timeline (Línea de tiempo) requiere dos subreportes, uno seleccionando y contando filas donde CreateDate coincide con TimeLine Date (Fecha de línea de tiempo) determinada. El segundo subreporte selecciona y cuenta el número de filas donde ResolveDate coincide con la misma fecha de TimeLine.

Conclusión

El enfoque Timeline (Línea de tiempo) tiene el mismo rendimiento que el enfoque SimpleCaseHistory debido a que debe unirse a la mesa del equipo de trabajo dos veces. También se usa solo como un reporte de Lista, ya que cada subreporte realiza un COUNT en lugar de que el reporte principal realice una agregación GROUP BY, que se puede graficar. Con SQL, es posible UNION el resultado de los dos subreportes, pero la regla de definición de reportes de Pega no lo admite.

La solución ideal es basar el reporte de tendencias solo en la clase SimpleCaseHistory sin unirse a la mesa del equipo de trabajo. Este ejemplo muestra el beneficio de extraer datos y conservarlos en una forma diferente para facilitar la inteligencia empresarial.