REPORTE DE MONITOREO
Fuente: /var/www/html/qareportes/app/Http/Controllers/Cloud/MonitoreoController.php
1) Nombre del reporte
-
Nombre: Reporte de Monitoreo
-
Código / Alias: report_monitoreo_
-
Responsable: Equipo de Reportes Cloud
-
Propósito (1 línea):
2) Alcance temporal
-
Campo(s) de fecha utilizados:
-
first_date
-
second_date
-
Tipo de rango (diario / mensual / personalizado): Mensual
-
Inclusión de horas (sí/no). Si sí: [00:00:00 – 23:59:59]
-
Zona horaria: La del servidor
3) Origen de datos (tablas/APIs)
-
Conexión / Base: Empresarial
-
Tabla / Recurso: emp_reportes_validation
-
Alias (si aplica): no aplica
-
Campos utilizados (clave → descripción):
-
report → nombre de la tabla
-
first_date →Fecha inicio
-
second_date →Fecha Fin
-
created_date → Fecha y hora de creacion
-
status → Estado
-
Condiciones (WHERE) aplicadas: no aplica
-
Tipo de unión con otras fuentes (JOIN y llave): no aplica
-
Observaciones (ej. particiones, índices):
-
Tablas particionadas por año y mes: report_monitoreo_YYYY_MM
4) Filtros globales del reporte
-
Inclusiones (must-have):
-
Generar el rango de fecha con la función obtainRangeDaysByYear
-
Registro en la tabla de validación emp_reportes_validation con estado (status = 1 o status = 0).
-
Manejo de transacciones: beginTransaction, commit, rollBack
-
Exclusiones (reglas de descarte):
-
Si la tabla dinámica no existe se detiene el update y ya no hace truncate
-
Si no hay parámetros de fecha se corta la ejecución y se regresa un error
-
Reglas por estado / habilitado:
-
Si show(...) fue exitoso → se registra con status = 1.
-
Si falla o lanza excepción → se registra con status = 0.
-
Parámetros externos (si el usuario puede filtrarlo):
-
$table → parámetro de entrada en truncate_bd(), permite definir qué tabla se limpia.
-
Fechas derivadas del sistema (date("Y-m-d")) → afectan $year, $last_month, $first_month, por ende, los rangos de trabajo.
-
Los rangos calculados ($first_date, $second_date) son dinámicos, dependen de la fecha actual.
5) Transformaciones y Reglas de negocio
-
Derivaciones de campos (cómo se calculan):
-
$first_month → derivado de $last_month.
-
Si es enero o febrero, siempre vale 1.
-
Si no, se calcula como el mes anterior al actual.
-
$obtain_ranges → derivado de obtainRangeDaysByYear(), que devuelve un rango de fechas según $year, $last_month y $first_month.
-
$table → derivado de la fecha inicial ($first_date) → "report_monitoreo_" . date("Y_m", strtotime($first_date)).
-
$body["created_date"] → derivado con date("Y-m-d H:i:s").
-
Mapeos de estado: En $body["status"] se mapea el resultado de la transacción:
-
1 → si el bloque try ejecuta correctamente.
-
0 → si ocurre una excepción y se hace rollBack().
-
Reglas de validación (p.ej., sólo registros validados):
-
Antes de truncar la tabla, se valida si la tabla existe.
-
También hay una validación en el try catch solo se continúa si el reporte fue generado exitosamente.
-
Reglas condicionales (si X entonces Y):
-
Condicional en la derivación de mes inicial:
-
Si el mes es enero o febrero → $first_month = 1.
-
Si no → $first_month = mes anterior.
-
Condicional de rangos adicionales:
-
Si el mes es enero o febrero → se agregan también los rangos de diciembre del año anterior:
-
Condicional de commit/rollback:
-
Si no hay error en la ejecución → se hace commit() y status = 1.
-
Si hay error → rollback() y status = 0
6) Estructura de salida
-
Tabla/archivo destino: report_monitoreo_ AÑO_MES (Tabla Dinamica)
-
Particionado / sufijo: AAAA_MM de la tabla
-
Clave(s) primaria(s) o únicas: no aplica
-
Columnas del reporte (nombre → tipo → descripción):
-
report → VARCHAR → Nombre del reporte
-
first_date → DATE → Fecha de inicio del rango
-
second_date → DATE → Fecha de fin del rango
-
created_date → DATETIME → Fecha de ejecución/creación del registro de validación
-
status → TINYINT → Estado de la operación (1 = éxito, 0 = falla)
-
Ordenamiento por defecto: No se especifica ORDER BY
7) Frecuencia y operación
-
Frecuencia de actualización: PENDIENTE(Esperando info de eduardo)
-
Ventana que recalcula (días/meses):
-
Si el mes en que se ejecuta es Enero o Febrero. Recalcula la fecha y abarca Todo Diciembre del año pasado y Todo Enero del año actual.
-
En otros meses, toma el mes anterior → mes actual.
-
Tamaño de lote / paginado (chunking): No aplica paginado por cantidad de registros. Procesa los registros por mes(La cantidad de registros en un mes lo considera un lote).
-
Tolerancia a fallos / reintentos:
-
En caso de errores se inserta un registro en emp_reportes_validation con status = 0
-
Tiempos de ejecución esperados: PENDIENTE(Esperando info de eduardo)
8) Calidad y controles
-
Validaciones previas/post:
-
Previas:
-
Antes de insertar los datos en la tabla dinámica, se verifica si la tabla existe. Si existe, limpia los datos de la tabla.
-
Post:
-
Se guarda un registro en la tabla emp_reportes_validation con los siguientes datos:
-
Nombre del reporte
-
Fechas de inicio y fin
-
Estado (status = 1 si OK, 0 si falló)
-
Fecha de creación
-
Controles de duplicados: No hay una validación de duplicados, pero lo que sí hay es una creación de tablas dinámicas. ejm: report_monitoreo_2025_09
-
Métricas de completitud (qué se monitorea):
-
Se monitorea si la ejecución fue exitosa insertando datos en la tabla emp_reportes_validation con status (1 = éxito, 0 = error)
-
También se guarda la ventana temporal para medir la cobertura temporal(que meses fueron procesados)
9) Dependencias externas
-
APIs / servicios y endpoints: No aplica. Se procesa con métodos internos, no existe endpoint.
-
Autenticación / headers: No aplica.
-
Mapeos y contratos de datos: Cada que se ejecuta el reporte se inserta los siguientes datos en la tabla emp_reportes_validation:
-
report → STRING → Nombre del reporte
-
first_date → DATE → Fecha de inicio
-
second_date → DATE → Fecha de fin
-
created_date → DATETIME → Fecha de ejecución
-
status → TINYINT → Estado de la operación (1 = éxito, 0 = error)
10) Historial de cambios
2025-09-24 10:56 - Elian Franco Arroyo Rodas - Documentación inicial
No hay comentarios para mostrar
No hay comentarios para mostrar