¿Qué tal amigos? Aquí les traigo un nuevo episodio de este hermoso segmento llamado #BestInMicro.
Hoy les voy a contar una situación que me encontré hace poco. Resulta que un manager me pide un listado de todos los reportes y objetos que fueron modificados por los usuarios. El objetivo final era poder detectar qué usuarios tenían más privilegios de los que realmente utilizaban, ya que como todos sabemos dependiendo las licencias que tiene cada usuario varía el precio de licencia de Microstrategy.
Lo primero que pensé fue en hacer una simple búsqueda de todos los objetos y filtrarlos por propietario. De esta forma, iba a poder encontrar que usuarios van creando distintos objetos. Hasta aquí, fácil… hasta que luego me encontré con distintas situaciones:
– Primero, que no iba a poder detectar quiénes modificaban los objetos
– Segundo, es posible cambiar el propietario de un objeto a través de las propiedades. por lo que el resultado de mi búsqueda no iba a ser del todo preciso.
Fue ahí que se me ocurrió buscar en el Change Journal, y para quien no sabe…
Se trata de una herramienta de MicroStrategy que registra las modificaciones de que van teniendo los objetos, y ésta se puede consultar desde el menú propiedades de cada objeto:
En versiones anteriores, era posible deshabilitar el registro de logs, pero ahora esto ya no es posible. De todas formas, para que los usuarios tengan acceso a ver el registro de actividad es necesario otorgarle el privilegio de “Audit Change Journal”
Por defecto, MicroStrategy nos permite incluso poner comentarios al editar un objeto, que luego se verán reflejados en el change journal. Es común deshabilitar este input, pero es posible habilitarlo también en Tools > MicroStrategy Developer Preference>Optional Actions>General>Display change journal comments input dialog.
Volviendo a nuestra problemática, si bien es posible ver las modificaciones que tuvo el objeto, mi caso seguía muy complicado ya que el proyecto en cuestión tenía más de 6000 reportes (y lógicamente no iría revisando uno a uno), sino que, además, me habían pedido solamente los usuarios web. Es decir, no me interesa obtener información de los objetos eran modificados desde el developer.
Para esto, debemos consultar el registro completo del journal. Dentro del menú administración de MicroStrategy, en la solapa System administrator, podemos encontrar el historial de change journal. Esta pestaña nos permite no solo filtrar lo distintos campos sobre los cuales nos interese ver los elementos del change Journal, sino que también nos permitirá exportarlo, por lo que lo único que precisé hacer fue definir el proyecto de interés, que el modo de acceso sea exclusivamente vía web y el rango de fechas el cual me interesaba extraerlo. Nunca había utilizado este filtro antes y la verdad que me pareció bastante interesante.
Un último detalle que me llamó la atención. El journal no sólo está dividido por páginas (es decir, la cantidad de registros), sino también está dividido por transacciones (save, delete, create, etc).
Mucho ojo con esto, porque puede pasar que piensan que llegan al final de la página cuando en realidad es el fin de la transacción. La cantidad de registros mostrados puede ser modificado desde el menú de Intelligence server. Para esto se debe modificar la cantidad de transacciones y/o registros en el menú mostrado aquí debajo:
Y claro, como todos somos curiosos y realmente queremos llegar al fondo de cada una de estas cosas, ya bien sabemos (de leer artículos anteriores como los de queries a la metadata) toda la información de MicroStrategy se almacena en Metadata y en tablas de estadísticas.
El change journal no es la excepción, y se almacena en las siguientes tablas:
DSSMDJRNOBJS: Básicamente el change journal. 4 columnas: transacción, proyecto, objeto y modificación hecha. Si bien hay un código, en la KB44377 nos describe a que hace referencia cada uno. Aquí les dejo una query para que utilicen.
*Nota: 1-3: Registra cualquier creación, modificación o borrado de cualquier objeto.
4: Cada vez que se elimina una carpeta, se registran los cambios en la carpeta padre.
5-7: Los elementos de vínculo (“link Items”) son objetos que conectan dos o más objetos (por ejemplo, los filtros de seguridad conectan a los usuarios con métricas).
8-10: Registra cada vez que el change journal se activa, se desactiva o se borra.
DSSMDJRNINFO: Entra en los detalles de la transacción, donde figura qué se hizo, cuándo, desde donde y quién la hizo. Al igual que antes, les dejo la descripción de cada tipo de transacción
*Nota: 1-3: El Change journal se registrará cada vez que el usuario lo activa, desactiva o desea eliminar el historial del journal.
4-5: Registra al guardar uno o más objetos.
6: Los Link items son objetos que vinculan dos o más objetos. Por ejemplo, un filtro de seguridad vinculará un usuario y una métrica.
7-9: Registra cuando se eliminan uno o más objetos o proyectos.
10: Registra cuando se copian objetos.
11: Los usuarios duplicados se pueden combinar y esta transacción se registra.
12: Registra al utilizar el “Unused Managed System Objects” en el menú administración.
13: Crear una nueva propiedad del sistema.
14. Crear una contraseña de base de datos
DSSMDJRNLNKS: Esta tabla refleja los objetos afectados “indirectamente”. Por ejemplo, si modifico un atributo, un filtro afectado a este cambio se reflejará aquí.
DSSMDJRNOBJC: Esta almacena los comentarios hechos en el change journal.
DSSMDJRNOBJD: Almacena un poco más de detalle sobre el objeto modificado. Esta se cruza con la DSSMDOBJINFO y obtendremos todos los detalles del objeto.
Dejo aquí también unos comentarios que encontré en una nota del community que merecen mención:
– Siempre puede utilizar Freeform SQL en MicroStrategy para ejecutar estas consultas. Por lo tanto, se puede revisar el change journal en Web e incluso crear distribuciones.
– No es recomendable crear una nueva tabla dentro del repositorio de metadatos (el por qué lo vimos en el articulo sobre ScanMD), pero el rendimiento de la consulta puede mejorar considerablemente si almacenamos nuestras búsquedas en tablas físicas.
– Se pueden crear consultas similares mediante el Administrador de comandos y la API COM; sin embargo, personalmente me pareció que esto era mucho más fácil y completo.
– La ejecución de múltiples consultas en la base de datos del repositorio de metadatos puede afectar al rendimiento general del entorno. Utilícenlas con discreción.
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
