¡Muy buenos días a todos, y otra vez bienvenidos al club de curiosos de #BestInMicro! Este lugarcito donde comparto aventuras, historias, experiencias y aprendizajes en el mundo de la consultoría con MicroStrategy.
Esta semana traigo un artículo que siempre viene bien tener a mano. Seamos sinceros, ¿quién nunca borró o sobrescribió algún objeto por accidente? ¿De cuántos cristos se acordaron y maldiciones al cielo al tener que rehacer un objeto de nuevo por no hacer una copia de emergencia? Jaja tranquilos, que todos hemos estado ahí en algún momento, y de camino a que no se repita, hoy les contaré un poco la metodología de backup y restauración. ¡Acompáñenme!
Si hay algo que durante toda mi vida como desarrollador he sentido falta mientras estaba haciendo distintos documentos con MicroStrategy, fue algún sistema de versionado y no me refiero al registro de actividades de un objeto. Muchos de ustedes habrán comenzado hace poco con la herramienta, y desde que lo hice yo ha mejorado mucho. Incluso, recuerdo el momento en que se anunció la versión web de la 9.3 que al guardar un documento había incluido la opción de “volver a ejecutar el documento original o volver al que se estaba trabajando” luego de un “guardar como”, como para ayudar a generar algún tipo de versionado a la hora de ir evolucionando el desarrollo.
Con esto, uno podía ir haciendo alguna modificación cada tanto, o guardando una versión del desarrollo…
En fin, vamos a lo que vinimos. Digamos que, en la vorágine de nuestro día laboral, sin querer eliminamos o modificamos un objeto y le dimos a guardar, es momento de analizar alternativas para evitar tener que comenzar nuevamente.
Copias y versiones antiguas
Esta es la vieja y clásica. Es una muy buena práctica el ir guardando versiones de lo que se vaya desarrollando, aunque al largo plazo si no se lleva un buen mantenimiento puede generar una bola de basura muy grande (en especial si hablamos de objetos de esquema, lo que puede traer problemas en algún caso). Dicho esto, vamos al detalle de esta forma: No es lo mismo hacer un copy paste y sobrescribir el objeto que existe, y aquí hay que tener cuidado. Todos los objetos tienen un ID único dentro de cada proyecto.
Si hacemos un copy de un objeto A y sobrescribimos el objeto B, el id no será el mismo. Esto tiene un impacto enorme, ya que los objetos se vinculan entre sí a través de los ID (un documento con su reporte, un reporte con su filtro, un filtro con su atributo, etc, etc.). A la hora de querer tomar un objeto y reemplazarlo con otro sin que afecte todo el entorno que lo rodea, es necesario editar nuestro objeto B, dar en “guardar como” y ahí sobrescribir el objeto A. De esta forma, se mantendrá el ID original y el objeto restaurado no afectará a los otros objetos de los que depende.
Object manager
Este es el siguiente nivel. En un entorno medianamente maduro, existen distintos entornos: uno de desarrollo y uno de producción (mínimamente). A medida que un desarrollo va siendo aprobado para su despliegue, es buena práctica ir creando paquetes y almacenarlos en algún directorio a modo de “punto de restauración”. Digo que es buena práctica porque puede hacerse de forma directa, sin la creación del paquete, pero generalmente el utilizar paquetes no solo sirve como punto de restauración, sino que hasta es más sencillo de gestionar.
Backup de metadata
Y esta es la ultima esperanza para muchos en estado crítico de desesperación y llanto: un backup de Metadata. Bueno, quizás le estoy dando una importancia mucho mas grande de la que realmente implica, pero necesitaba darle un toque dramático al asunto 😊.
Ya sea que la metadata se almacene en cloud o in-premise, lo más común es que se mantenga algún tipo de almacenamiento de backup, generalmente diario, aunque también puede ser de forma semanal o mensual.
La forma de restaurar objetos a partir de un backup es similar a la anterior: utilizando object manager. Hagamos un repaso rápido de la arquitectura de MicroStrategy: Sin entrar en complejidades, podemos decir que puede haber conexiones de de 2 hasta 4 capas en Microstrategy:
1- Metadata. Es donde se encuentra la información y la estructura de MicroStrategy.
2- La terminal desde la cual nos conectaremos (Developer, Workstation, app mobile, browser, etc)
3- Intelligence Server. Esta capa nos permite utilizar las funcionalidades OLAP de MicroStrategy, además de las herramientas y facilidades que ofrece la plataforma.
4- Mobile/Web Server. Esta capa nos permite acceder a través de la red..
Cuando hablamos de una conexión de dos capas, es generar una conexión “directa” a la metadata. Es decir, desde nuestra terminal (Workstation o Developer) hacia la base de datos de metadata, sin pasar por Intelligence server, conectándonos con las credenciales de la base de datos.
Lo que debemos hacer es restaurar el backup en un esquema de la base de datos, y crear una conexión directa hacia este esquema restaurado. Esto creará un nuevo origen de proyecto, conectando al backup. Luego, simplemente es crear un paquete con lo que se quiere restaurar y se importa en nuestro entorno actual.
En fin, hay distintas maneras de recuperar o volver atrás en algún error, pero no son técnicas infalibles, y en especial depende de que haya algún tipo de punto de restauración. Otro tema a tener en cuenta es que aquí estamos hablando de objetos de MicroStrategy. En el caso de los objetos de aplicación el impacto es más probable que sea menor, pero si modificamos objetos como tablas, o incluso tablas en la base de datos, entonces ahí ya va a un tema más sensible y quizás más complejo de resolver… en fin, espero que con esta nota les haya sacado de un apuro, o al menos los ayude a tomar consciencia de algunas buenas prácticas.
¡Ya me contarán si tienen algún otro consejo para agregar! ¡Sin más, los espero en la próxima edición! ¡Saludos!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
