¡Hola, chicos!

En esta publicación me gustaría demostrarles cómo iniciar sesión para ver informes e identificar qué usuario está accediendo a él, es decir, cómo registrar en una tabla de base de datos qué usuario está accediendo a un informe en particular y cuándo se hizo.

La idea de este post surgió de una pregunta en un grupo de Telegram y pensé que podría ayudar a más personas publicando este artículo. De hecho, cuando necesité crear algo como esto, no encontré mucha documentación clara y objetiva en Internet.

Cómo iniciar sesión para ver informes

Como el propósito de esta publicación no es enseñar cómo crear informes en SSRS (crearé una publicación sobre eso), pasaré al objetivo de este artículo. En resumen, lo que se debe hacer para lograr este objetivo es utilizar una variable SSRS estándar para identificar al usuario que ejecuta el informe (=Usuario!UserID) y pasar esta variable al conjunto de datos que está consultando los datos en la base de datos, para que incluya la operación de registro de este registro en el proceso de consulta.

¿Te resultó difícil? Te detallo 🙂

Suponiendo que tiene un informe funcional de Reporting Services, como el que se muestra a continuación, comencemos a preparar nuestra rutina para que podamos registrar la ejecución del informe:

No puedo evitar comentar aquí, ya que apoyo, recomiendo y SIEMPRE uso Procedimientos Almacenados para ejecutar mis informes. Esto me da gran libertad y flexibilidad para consultar y procesar los datos, pasando parámetros y haciendo que pueda editar la consulta simplemente cambiando objetos en la base de datos, sin tener que cambiar mi informe.

El código fuente actual de mi procedimiento almacenado se ve así:

CREATE PROCEDURE dbo.stpConsulta_Relatorio (
    @Ds_Objeto AS VARCHAR(100)
)
AS
BEGIN
    
    SELECT *
    FROM 
        sys.objects
    WHERE
        [name] = @Ds_Objeto

END
GO

Ahora comencemos a realizar cambios para comenzar a registrar los cambios, incluido el nombre del usuario que consulta el informe.

Primero, creemos la tabla que almacenará la información de los registros de ejecución del informe:

CREATE TABLE dbo.Logs_Relatorios (
    Id_Log INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
    Dt_Log DATETIME DEFAULT GETDATE(),
    Ds_Relatorio VARCHAR(100),
    Ds_Usuario VARCHAR(100)
) WITH(DATA_COMPRESSION=PAGE)

Cambiemos nuestro procedimiento almacenado que consulta los datos para que incluya el registro. Para ello agregaré el parámetro @Ds_Usuario al SP para que reciba el nombre del usuario y lo inserte en el log bancario.

ALTER PROCEDURE dbo.stpConsulta_Relatorio (
    @Ds_Objeto AS VARCHAR(100),
    @Ds_Usuario AS VARCHAR(100)
)
AS
BEGIN
    

    -- Loga as operações
    INSERT INTO dbo.Logs_Relatorios ( Dt_Log, Ds_Relatorio, Ds_Usuario )
    VALUES ( GETDATE(), 'Consulta_Relatorio', @Ds_Usuario)


    -- Executa o relatório
    SELECT *
    FROM 
        sys.objects
    WHERE
        [name] = @Ds_Objeto


END
GO

El siguiente paso es cambiar nuestro conjunto de datos en Report Builder para incluir el parámetro de usuario:

Una vez abierta la pantalla de configuración del conjunto de datos, haga clic en la opción Parámetros y agregue la variable @Ds_Usuario a la llamada al Procedimiento almacenado:

Al hacer clic en el botón Expresión, seleccione el campo interno UserID (=Usuario!UserID):

Después de realizar estos cambios, guarde el Informe y acceda a él en el portal SSRS:

Al consultar los datos generados en la tabla de historial (dbo.Logs_Relatorios), podemos visualizar los registros generados, con la fecha en que se consultó el informe y quién lo consultó:

[Video] – Cómo iniciar sesión para ver informes

Si eres el tipo de persona a la que le resulta más fácil aprender con ricos elementos visuales de imagen y audio (también conocido como vídeo), preparé una rápida lección en vídeo sobre cómo hacer esto:

¿Qué pasa con la vista ExecutionLog?

Si está familiarizado con las vistas y tablas del catálogo de Reporting Services, es posible que se pregunte: "¿Por qué no utilizar la vista ExecutionLog, que ya tiene toda esta información almacenada automáticamente, para todos los informes?"

Bueno, antes que nada, presentaré la vista ExecutionLog para aquellos que no la conocen. Esta vista, que contiene datos de la tabla ExecutionLogStorage, registra todas las ejecuciones de todos los informes de Reporting Services, incluidos los parámetros utilizados, el usuario que ejecutó el informe, el tiempo de respuesta, el tiempo de procesamiento, etc.

SELECT * 
FROM ReportServer.dbo.ExecutionLog

Resultado:

"Entonces, ¿por qué utilizar el control de auditoría manual, si el servidor de informes ya lo hace por mí, aportando mucha información y estadísticas interesantes a todos los informes y de forma automática?"
R: Aunque estoy de acuerdo con todo esto, hay ciertas situaciones que te obligan a buscar alternativas para implementar tus controles y algunas de las razones que me llevarían a utilizar esta solución son:

  • El equipo de BI quiere centralizar toda la información de registro, de todas las instancias de RS, en una base de datos específica
  • El equipo de BI no tiene acceso de lectura a la base de datos de ReportServer
  • De forma predeterminada, Report Server tiene un límite de 60 días para almacenar datos en la tabla ExecutionLogStorage.

    Una alternativa interesante sería que el equipo de BI creara un trabajo que recopile estos datos temporales y los almacene en una tabla definitiva, pero cuando los analistas de BI no tienen acceso para crear trabajos, el control manual de los registros termina siendo una opción viable.

  • Restricciones diversas de espacio en disco y permisos en la instancia

Además, el ejemplo mostrado arriba puede servir para otros fines además de la auditoría, como filtrar datos según el usuario, devolver diferentes consultas o incluso restringir el acceso dentro del propio Procedimiento Almacenado.

Bueno amigos, ¡eso es todo!
Espero que hayas disfrutado este artículo y ¡hasta la próxima!

¡Abrazo!