En mi empresa llevamos 5 años utilizando QlikView como he comentado en algún otro artículo y puedo asegurar que cuando lo compré no tenía la más remota idea de lo que podría llegar a convertirse para ciertas personas y los problemas que iba a lucionarso con este producto. Lo compramos un poco para probar como aquel que dice.
Como todo, esta situación tiene un lado bueno, y otro malo.
El bueno: la de pasta gansa que nos hemos ahorrado en horas de programación de informes con el sistema operativo actual.
La mala: esto ha llevado a una situación un tanto caótica en cuanto al volumen de documentos que hemos llegado a generar y, en bastantes casos, el volumen se mide en cientos de MB comprimidos.
Otro factor siempre presente en nuestra vida, además del tener que comer, dormir, y...., son las prisas. Este último factor nos ha llevado a la situación que actualmente tenemos: infinidad de documentos que no están relacionados entre sí, que se recargan de forma separada cada día, con información redundada y que comienza a hacerse insostenible sus modificaciones (campos, tablas, etc). Con lo cual me enfrento, después de una cierta experiencia, con problemas de "sostenibilidad". La versión 32 bits además acentúa los problemas de los usuarios con algunos problemas de memoria ajenos a QlikView y que son imputables a la arquitectura de gestión de la memoria en máquinas windows de 32 bits (en fin, otro cantar).
Por resumir, inconvenientes:
- Una lista de tareas programadas interminable recargando documentos diariamente, incluso cada hora.
- La información está redundada en algún caso más de 15 veces (por ejemplo, la tabla "ARTICULOS")
- Modificar, añadir, o eliminar un campo de una tabla (ARTICULOS por ejemplo) supone repetir n veces la modificación de este campo en cada documento que contenga esta tabla. En algún caso, los documentos han sido hechos por personas diferentes con lo que os podéis imaginar.
- Las estructuras internas de tablas son diferentes en distintos documentos. Esto supone un problema sobre todo cuando se dispone de licencias Profesional o Enterprise (o en la versión nueva 8.5 si se habilita la creación de objetos compartidos de servidor) y los usuarios pueden ver los campos. Imaginad explicar a un usuario diferentes arquitecturas para la misma BD, un desastre...
- No queda ventana de horas disponible por la noche para ejecutar todas las recargas de documentos. Ejemplo: 10 documentos que tarden 1 hora en recargarse = 10 horas.
Todos estos problemas y algún otro más, los hemos pasado en mi empresa por lo que voy a intentar hacer una especie de documento de buenas prácticas (o "Best Practices") para la creación y mantenimiento de numerosos documentos en un servidor. Me gustaría no ser el único que hace anotaciones en esta entrada y que aportéis vuestras ideas o soluciones:
"Best Practices" para la sostenibilidad de documentos grandes de QlikView:
- Piensa antes de hacer. Creo que el más importante. Pensar y estudiar lo que se pretende con el documento y si ya tenemos otro con datos similares. Es posible que convenga ampliar el existente y no crear uno nuevo.
- Archivos QVD. QlikView hace ya tiempo que inventó estos archivitos. La ventaja es que los recargas una vez y que tarde lo que tarde. Desde tu nuevo documento de QlikView puedes recargar tablas enteras alojadas en estos archivos QVD como si se tratasen de un excel o archivo de texto, con las siguientes ventajas: 1.- Velocidad (es entre 10 y 100 veces más rápida la recarga de un archivo QVD que un equivalente en otro formato) y 2.- La estructura de campos es única y hay un único punto de mantenimiento.
- Recargas Parciales: Es aconsejable utilizar la sentencia "Partial Load ..." para ganar en velocidad de recarga.
- Invierte más horas en el script de carga y menos en formulación extraña en los objetos y en código en el editor de módulo: Ganarás en velocidad de cara al usuario al tener el dato ya pre-calculado. Créeme, el usuario notará que vuela al hacer selecciones, bookmarks, etc...
- Utiliza la sentencia $(include=""). Puedes dejar fuera de QlikView fragmentos comunes entre varios documentos para que modificarlo sea cosa de abrir el notepad. Además (que me perdone la gente de QlikView) pero otras personas de tu departamento podrán mantener código de script genérico sin necesidad de tener acceso a la aplicación (evidentemente nos ahorramos unas pelillas...;-). Ni que decir tiene que deben primero controlar y conocer lo que tocan...
- Oculta las pestañas. Esto se lo ví a un gran amigo (http://http://www.cmigestion.es/) y me dió la idea perfecta para documentos de mucho contenido (muchas pestañas). Una primera hoja con una especie de menú te va a permitir que el usuario navegue de una forma controlada para obtener lo que necesita, frente a mostrar todas las pestañas y que vaya entrando en información que no le es necesario en ese momento. (Estoy preparando un documento que explique esto para una próxima entrega).
- Los nombres de campos claritos: Sobretodo si sois varias personas manteniendo los documentos. QlikView tiene la posibilidad de cualificar o no los campos de las tablas. Una buena especificación a la hora de llamar a los campos por su nombre puede ahorrarnos muchos dolores de cabeza, os lo aseguro. Los campos del tipo "CArtN" son menos descriptivos que "Costo Neto Articulo". Es triste decirlo pero más triste es robar ;-)
- NO al editor de módulo: QlikView desaconseja encarecidamente su uso salvo excepciones, claro está. Entre que el editor no lo tienen muy currado y que en posteriores versiones no te garantizan al 100% su correcto funcionamiento, muerto el perro, se acabó la rabia...
- Be graphic, my friend... Uséase, que como todo en esta vida, es importante hacerlo bien, pero casi más importante es venderlo bien. ¿No conocéis el típico en la empresa que no hace grandes cosas pero que las sabe vender?. Si tenéis un departamento de diseño gráfico o, simplemente alguien con un poco de gusto estético, no dejar al informático de turno hacer con vuestra obra de arte a presentar a dirección, un cuadro de Miró (con todos mis respetos...).
- Let's Backup. Backup, backup y más backup....
Estos son consejos a la hora de hacer un documento. A la hora de montar la estructura de carpetas NTFS en el server yo lo tengo montado de la siguiente forma:
RAIZ
- QVD (carpeta con archivos QVD)
- SCRIPTS (carpeta con permisos NTFS selectivos para modificar partes de ciertos script de carga)
- DOCUMENTOS (esta es la carpeta pública a la que tienen acceso los usuarios y que contiene a su vez, subcarpetas y archivos QVW)
- LOGS (carpeta con archivos logs del servidor, archivos .mem, etc...)
Esta parte es un ejemplo pero que podéis montarlo cómo queráis. QlikView tiene más opciones como la posibilidad de montar en el servidor de QlikView otras carpetas con rutas diferentes.
Un saludo
Entradas
