Manuales POS

Diagnóstico de error en construcción de reportes

Audiencia

Este documento está pensado para ser consumido por los equipos de:

Soporte Farmax OR (Niveles 1 y 2)
Equipo de desarrollo TI (Farmacias del Ahorro y proveedor externo)

Descripción general

Se reporta vía chat electrónico que varios reportes de BackOffice se quedan “atorados” sin poder generarse; el detalle se muestra en la siguiente consulta:

select horaSolicitud, SUM(solicitud)solicitud, SUM(pendiente)pendiente, sum(construccion)construccion, SUM(ejecucion) ejecucion, SUM(error)error, SUM(finalizado)finalizado, SUM(construccion+ejecucion+solicitud+pendiente+error+finalizado)total
from (
select estadoSolicitud, CONVERT(varchar(13),fechaSolicitud,120) horaSolicitud
, case estadoSolicitud when 'R' then SUM(1) else SUM(0) end as ejecucion
, case estadoSolicitud when 'S' then SUM(1) else SUM(0) end as solicitud
, case estadoSolicitud when 'P' then SUM(1) else SUM(0) end as pendiente
, case estadoSolicitud when 'E' then SUM(1) else SUM(0) end as error
, case estadoSolicitud when 'F' then SUM(1) else SUM(0) end as finalizado
, case estadoSolicitud when 'B' then SUM(1) else SUM(0) end as construccion
from rptReporteSolicitudEjecucion with(nolock)
where fechaSolicitud>=convert(varchar(10),GETDATE(),120) and fechaSolicitud<convert(varchar(10),GETDATE()+1,120)
group by estadoSolicitud, CONVERT(varchar(13),fechaSolicitud,120)
) t
group by horaSolicitud
order by 1;

Impacto a la operación

El impacto de la operación es baja en virtud de que la operación no se ve comprometida por esta incidencia.

Alto
Medio	X
Bajo

Sistemas/módulos involucrados

POS

Precondiciones

Aquí se debe especificar el nivel de acceso requerido por cada sistema (aplicativo o base de datos), indicando el rol o perfil necesario para para el diagnóstico y/o solución del incidente.

POS

Procedimiento de diagnóstico

1.- Se procede a sacar una estadística para identificar los reportes que han sufrido el mayor tiempo de consumo del día 22/Marzo al 03/abril con la siguiente consulta:

use POSDB_OR
--Creacion de tabla temporal e insersion de datos
select codigoReporte, fechaSolicitud,fechaFinalizacion,
DATEDIFF(S,fechaSolicitud,fechaFinalizacion) as Tiempo into #estadistica
from rptReporteSolicitudEjecucion where fechaSolicitud > '2024-04-01 00:00:00' order by Tiempo desc

--Consulta de temporal
select codigoReporte, fechaSolicitud,fechaFinalizacion,
case when Tiempo >= 3600 then ROUND(CONVERT(float,Tiempo)/3600,2) when Tiempo < 3600 then 0
end as horas,
case
when Tiempo > 3600 then 0
when Tiempo <= 3600 then Tiempo/60
end as minutos,
case
when Tiempo > 60 then 0
when Tiempo < 60 then Tiempo
end as segundos
from #estadistica
order by Tiempo desc

--Borrado de temporal

drop table #estadistica

Obteniendo el siguiente resultado:

2.- Se revisó el tiempo de consumo promedio del reporte con mayor consumo en este caso:

SALEPEREMPLOYEE

Y se detectó que a la fecha dicho reporte se ejecutó un total de 7780 veces y para el primer día de afectación el tiempo de ejecución fue de 34.8 h. Dentro de los cuales 7283 veces el reporte se tardó 15 minutos o menos en el tiempo de ejecución.

3.- Por lo cual se procedió a revisar los logs del servidor Fahorromex337, de la ruta:

C:\ProgramData\FAhorro\FX_CENTRAL_REPORTS

Partiendo de los datos del reporte SALEPEREMPLOYEE con fecha de solicitud (Según la estadística). 2024-03-30 21:16:02.513

20240330_FX_CENTRAL_REPORTS:

En dónde se visualiza la petición del reporte:

En dicho reporte se detectó la siguiente excepción, perteneciente a la solicitud del reporte:

[2024-03-30 21:16:04:074],FX_CENTRAL_REPORTS,,ERROR,[RUNINTERNAL],El thread de ejecución del reporte 'SALEPEREMPLOYEE' del usuario '13953' con solicitud:5048512 genero una excepción no controlada, posiblemente errores de base de datos

4.- Se procede a revisar la construcción del reporte en el log 20240330_FX_CENTRAL_REPORTS_REPORTBUILDER.

En dónde se muestra la petición de construcción del reporte hasta la fecha de finalización.

8.- Se revisó el visor de eventos de Windows y se observó que el servicio FAhorro FARMAX Central Reports se reiniciaba todos los días a las 4 a.m. hasta el día 24 de marzo, un día antes de presentarse el problema de manera recurrente.

9.- Se revisó el código fuente, en dónde se detectó que cada ejecución de reportes tiene por default 3 intentos por usuario en caso de existir una excepción, provocando un “encolamiento” de peticiones y dando como resultado que el “pool” de conexiones hacia la base de datos llegara a su límite. Para volver a tener esa cantidad de conexiones, es necesario actualmente reiniciar el servicio FAhorro FARMAX Central Reports.

Los reportes no tienen un tiempo de espera límite para terminar la consulta, por lo que si la sentencia SQL a ejecutar degrada el performance de la base de datos y limita la disponibilidad de conexiones del “pool”.

10.- Se procede a ejecutar la siguiente consulta para conocer la transacción más antigua (año 2021) con el fin de saber la información contenida en el archiving:

Select top 1 * From trnTransaccionesCab With (NoLock )order by idFechaOperacion asc

El tiempo de ejecución fue de poco más de 8 minutos y la transacción más antigua es del día 2-abril-2021, es decir, 3 años a la fecha.

Procedimiento de solución

El servicio FAhorro FARMAX Central Reports que se encuentra en el servidor FAHORROMEX337 dejó de reiniciarse todos los días a las 4 a.m. a partir del día 24 de Marzo, por lo cual sugerimos reactivar el reinicio a la misma hora, ya que anteriormente si se presentaban errores en BackOffice pero no con frecuencia.

Se obtendrán las estadísticas de los reportes con mayor concurrencia para validar el plan de ejecución, tomar el tiempo que demora cada uno y realizar las mejoras pertinentes de acuerdo al resultado.

Considerar el uso de la propiedad "Command Timeout" en la creación de la conexión, esto afectaría el código del servicio FAhorro FARMAX Central Reports.

Configurar a 1 los reintentos modificando la siguiente llave <add key="CONFIG_REPORT_MAX_REPORT_RETRIES" value="1"/> del archivo .Config del servicio FAhorro FARMAX Central Reports del punto 9.

Realizar una depuración a la base de datos de archiving, ya que la cantidad de registros históricos, el consumo de la base de base de datos y la sincronización degradan los tiempos de respuesta de las consultas, tal como se aprecia en el punto 10.

Nota Adicional:

El usuario que ingresa a BackOffice tiene la posibilidad de ejecutar la descarga de los reportes en múltiples ejecuciones al mismo tiempo (en menos de 10 segundos), por lo que la carga al servidor de aplicación y base de datos se puede ver afectada; esto se puede confirmar con ciclos de pruebas de estrés hacia BackOffice e implementar un proceso de encolamiento de peticiones por usuario.

Por el momento y cómo sugerencia se puede solicitar a la operación que cada usuario realice la ejecución de un reporte a la vez.

Se complementa la información con la estadística concreta en el formato:

Estadística de reportes consultados por usuario.xlsx