Las variables en QlikView funcionan prácticamente igual que en cualquier otro software, sin embargo muy pocos desarrolladores las utilizan y aún menos aprovechan su verdadero potencial.
El objetivo de este post es demostrar que aun cuando QlikView ya es naturalmente dinámico, al utilizar variables se puede mejorar o aumentar esta mecánica. Por ejemplo, la manera tradicional o predeterminada de crear una expresión implica la definición del campo específico a calcular, lo cual a menudo conlleva la generación de múltiples fórmulas que se colocan en varios objetos.Este escenario no es necesariamente incorrecto, después de todo es el método más común para creación de expresiones y dependiendo del caso puede no existir una alternativa. Sin embargo, existen ocasiones en donde muchas de las fórmulas utilizan los mismos filtros y condiciones de cálculo y la única diferencia es el campo que se calcula en la función. En este último escenario podemos hacer uso de las varibles para facilitar el mantenimiento de las fórmulas y aportar mayor dinámica a los objetos que las utilizan.
En el siguiente video ejemplifico cómo implementar el uso de variables para reutilizar fórmulas en múltiples objetos, además de facilitar al usuario la indentificación de la métrica que se está visualizando.
Como siempre, espero que este ejemplo les sea de utilidad y no duden en preguntar o comentar sus impresiones al respecto.
Es muy común que además de filtrar registros de datos con Section Access también se te solicite filtrar las hojas y los objetos a los que cada usuario tiene acceso. Sin embargo, y siendo honesto, yo no estoy a favor de filtrar objetos individuales debido a que ello implica mucho mantenimiento y una tabla de Section Access muy compleja (si se utiliza tal método). Así que normalmente describo el escenario completo, sobre todo la parte del futuro mantenimiento, a la gente de TI y los usuarios clave y ello los convence (hasta ahora) de que la mejor opción es el filtrado de hojas/pestañas y no de objetos. Lo cual en mi opinión es la mejor alternativa debido a que es más común ocultar un bloque completo de información o análisis que un solo indicador.
Existen métodos alternativos a la utilización de Section Access para cubrir este requerimiento. Por ejemplo, se puede utilizar la función MATCH(), la cual no describiré en este post pero puedo realizar un ejemplo si lo desean. Sin embargo, la desventaja de utilizar estos métodos es que todas las condiciones se deben mantener manualmente y desde la aplicación QlikView (.qvw), lo cual los hace altamente dependientes del desarrollador y de difícil mantenimiento, sobre todo si se cuenta con decenas o cientos de usuarios.
Por otro lado, utilizar Section Access otorga dos grandes ventajas:
Concentrar todos los aspectos de seguridad de una aplicación en un mismo mecanismo, lo cual facilita un poco la revisión de problemas.
Habilitar la posibilidad de administrar los privilegios de manera externa a la aplicación QlikView. Por ejemplo, un usuario clave podría realizar el mantenimiento de los perfiles desde un archivo de Excel.
Por supuesto, utilizar Section Access también tiene desventajas:
Se debe ser cuidadoso a la hora de definir los perfiles de acceso o se puede perder todo el trabajo hecho en una aplicación si colocamos credenciales incorrectas o simplemente las olvidamos.
Se debe recargar la aplicación y cerrar por completo la instancia de QlikView para poder revisar si los perfiles se aplican correctamente, además de que se debe iniciar sesión con el usuario correspondiente de Windows para poder revisar cada perfil.
No obstante estas desventajas, yo utilizo Section Access siempre que el número de usuarios con acceso a una aplicación supera la decena o cuando simplemente ya estaba utilizándolo para filtrar registros en la misma aplicación.
A continuación les dejo un video de ejemplo, así como el QVW, que describe rápidamente cómo implementar este mecanismo de seguridad por hojas. En el QVW se utilizan cargas INLINE para permitir que cualquiera que lo descargue pueda recargar la aplicación y realizar pruebas, sin embargo se debe notar que los registros que se carguen en Section Access pueden provenir de cualquier fuente, ya sean xls, qvds, o tablas de bases de datos.
Sin más preámbulo, estás son las instrucciones para poder probar el ejemplo:
Descargar el archivo NTNAME Sheets Security.qvw
Ir al script y en la pestaña Section Access descomentar el código deshabilitado.
En la misma pestaña, cambiar los valores de los campos NTNAME y USER para que hagan referencia a los usuarios locales o de dominio de su ambiente o máquina.
Guardar y salir del script. Ir al menú Configuraciones/Propiedades del Documento/Al Abrir y habilitar la opción “Reduccion Inicial de Datos basada en la Sección de Acceso”. No habiliten la opción “Exclusión Estricta”.
Recarguen la aplicación y guarden.
Nota. Si cuentan con un ambiente QliKView que utilice Publisher tendrán que realizar lo siguiente antes de poder ejecutar la recarga y distribución:
Deberán añadir la cuenta del usuario que ejecuta los servicios de QlikView como un usuario ADMIN en la tabla de Section Access.
Añadir todos los usuarios que se carguen en Section Access a la tarea de Distribución.
Si solo utilizan la versión de Escritorio de QlikView, guarden y cierren todas las instancias de QlikView. Con todas las instancias cerradas, abran la aplicación nuevamente para ver revisar si los filtros se aplicaron correctamente.
Nota. Para revisar todos los perfiles será necesario cerrar la sesión de Windows y loguearse en la sesión de cada usuario. Les recomiendo copiar la aplicación en un usb para poder abrir la aplicación desde cada sesión.
Dependiendo del usuario con el que se hayan logueado en Windows deberían ver los siguientes resultados:
Si se loguearon como el usuario admin (primer registro en la tabla de Section Access), deberían poder ver ambas hojas (A y B) y todos los países y ciudades.
Si utilizaron el primer usuario (Segundo registro), únicamente deberán ver la hoja A pero si deben visualizar todos los países y ciudades.
Utilizando el último usuario (tercer registro), sólo deben ver la hoja B y las ciudades de MEXICO y USA.
Espero que este ejemplo les sea útil y no duden en preguntar en caso de que posean alguna duda al respecto.
Para estrenar mi blog quiero comenzar con algo sencillo pero que resulta ser un punto muy importante a la hora de posicionar QlikView: su capacidad para integrar múltiples fuentes de datos y en específico Excel.
A menudo, por no decir casi siempre, los usuarios de negocio terminan por exportar a Excel la información que les provee un sistema de reporteo o de análisis. Esto se debe en gran parte a que, como en cualquier proyecto, los sistemas son inicialmente desarrollados con un alcance y enfoque definidos, más posteriormente es difícil modificarlos o actualizarlos para reflejar y cubrir nuevas necesidades de negocio. Lo más común es que dicha herramienta provea cierta información bajo cierto formato, lo cual, por supuesto, resuelve ciertas necesidades. Y son justamente estas capacidades y limitaciones las que orillan a los usuarios insatisfechos a llevar la información a Excel para manipular los datos de la manera que necesitan.
En este escenario, QlikView aparece como un mecanismo para que los usuarios instasfechos o con necesidades de análisis en constante cambio sean autosuficientes. Si ya se cuenta con un esquema de licenciamiento QlikView, los usuarios nombrados (Named CALs) pueden desarrollar sus propias aplicaciones a partir de fuentes de datos como archivos de excel, o similares, como csv, txt o xml, o complementar modelos de datos, desarrollados por el área de TI, con información adicional que probablemente pueda ser extraída desde archivos en los formatos antes mencionados. Sin embargo lo más atractivo al respecto es que no es imperativo adquirir el licenciamiento para hacer uso de la herramienta, pues un usuario puede descargar la versión personal y desarrollar una aplicación QlikView por completo desde su laptop. Aunque claro, no podrá compartir su resultado con nadie más.
Es a partir de este escenario que hace poco creé un pequeño tutorial que ejemplifica como extraer información desde Excel para crear una aplicación QlikView. Les comparto el video y espero que sea de su agrado.
Me llamo Carlos Alberto Reyes Díaz y deseo darles la bienvenida a mi primer blog. Como se podrán dar cuenta a partir del título, este blog se centrará en algunos comentarios, trucos y experiencias que he ido acumulando durante mi carrera como consultor QlikView en México.
No deseo convertir este espacio en un medio de solución de problemas o algo parecido a un servicio de soporte técnico de QlikView. Simplemente busco compartir algunos de los conocimientos y experiencias que me han ayudado a crecer como consultor de BI con esta herramienta. También estoy consciente de que existen otras alternativas en el mercado, más dado mi pasado y actual enfoque en QlikView, será raro, por no decir imposible, que publique o hable acerca de las mismas. Aunque quién sabe, talvéz el futuro me lleve a trabajar con algún software diferente y este blog evolucione hacia lo mismo.
Hablando un poco más de mi, soy mexicano y chiapaneco. Radico actualmente en la Ciudad de México, donde sigo desarrollándome como consultor QlikView en proyectos de BI y Data Discovery. Llevo 4 años trabajando en todos los aspectos relacionados con QlikView: Soporte, Pre-venta, Implementación y Capacitación. He participado en un gran número de proyectos a través de distintas industrias y cuento con la certificación QlikView Designer & Developer para la versión 11 (Actual).
Espero contar con su participación activa para cualquier duda o comentario, pues uno nunca sabe de quién puede aprender algo nuevo.
Por último, y porque hay que comer, si necesitan cualquier tipo de servicio profesional relacionado con QlikView no duden en contactarme en mi correo electrónico: carlos.reyes@evolcon.com o visiten la página http://evolcon.com
Aprendiendo Data Discovery 