Você está na página 1de 68

QlikView Guia de Boas Práticas:

Desenvolvimento

Versão: 0,5 - projecto


Data: Jan, 2011 Autor:
BPN, JCA
Diretrizes de Boas Práticas: Desenvolvimento
Diretrizes de Boas Práticas: Desenvolvimento

Índice

Projeto UI .......................................................................................... 4

Scripting .............................................................................................. 9

Modelos de Dados .................................................................................. 15

Variáveis, Ações e Macros ....................................................... 23

Project Management ........................................................................ 29

Segurança (Seção Access) ..................................................................... 33

Otimização .................................................................................... 34

Código Gestão e Migração ............................................................. 38

Padrões de nomenclatura ........................................................................... ... 48

Estruturas de pastas ...................................................................... 49

Testing / Certification ........................................................................ 51

Solução de problemas / Suporte .................................................................. .. 57

Formação ............................................................................................. 62

Resumo ........................................................................ ............... ... 64


Diretrizes de Boas Práticas: Desenvolvimento
Introdução
Este guia Melhores Práticas é um manual de referência para desenvolvedores do QlikView. desenvolvedores do QlikView são indivíduos
que projetar e implementar aplicativos QlikView e suas áreas de gama conhecimentos de modelagem de dados para criação de scripts
para design de interface. Este documento destina-se a facilitar a compreensão muito mais clara das metodologias e práticas que são
ideais para a produção altamente usável, altamente otimizado e aplicativos QlikView altamente configuráveis, se usado por pequenos
serviços ou pelas grandes empresas.

projeto UI

questões de design. Tem impacto taxas de adoção pelo usuário, taxas de utilização, velocidade de padrões de análise e uso.
Todas estas coisas impactar o quão eficaz o seu documento QlikView pode ser. Os princípios de bom design de interface
promovidas por Stephen Few e Edward Tufte são a base para as melhores práticas QlikTech recomenda ao projetar e construir um
documento QlikView. O esquema abaixo mostra (em um nível alto) alguns desses inquilinos de um bom design. QlikTech faz
muitos exemplos QlikView, documentos, conjuntos de slides e outros materiais disponíveis para ajudar a demonstrar esses
princípios.

Exemplos

O uso de modelos fornecidos ou desenvolvidos para a consistência e simplicidade:


Diretrizes de Boas Práticas: Desenvolvimento

Uso de fecho implícita para limitar o espaço de tinta não-dados:

O uso de cores neutras e suaves e uso de contraste: Cores suaves e neutros são muito menos cansativo para os olhos e
aumentar a adoção do usuário. Uso de contraste ajuda os olhos rapidamente identificar pontos de interesse ou exceções.
Estes conceitos andam juntos, pois o uso de contraste com cores primárias é difícil de fazer. Considerar uma combinação de
cores suaves eo uso de contraste em todas as cartas, especialmente onde exceções ou valores atípicos são destinadas a ser
destacado.
Diretrizes de Boas Práticas: Desenvolvimento
Uso de tamanho, formas e intensidade chamar a atenção para pontos de dados: Shapes são outro ponto de identificação rápida para os olhos.

Eles podem ser usados ​para pontos de dados em grupos de segmento. intensidades de cor funcionar bem para faixas de valores ou valores

discrepantes.

Muitas das melhores práticas de design são exibidas nas aplicações demo que estão disponíveis publicamente em http://www.demo.qlikview.com
. Além disso, há uma apresentação conjunto de slides que abrange técnicas de design para QlikView que é muito
abrangente. Por favor, visite QlikCommunity e procurar DataVisualization.ppt.

Outras melhores práticas para UID projeto incluem:


- Coloque uma caixa de seleções atuais em cada folha no mesmo local

- Faça caixas de listagem aparecem nos mesmos locais em cada folha

- Organizar caixas de listagem e multi-caixas primeiro na frequência de utilização (mais utilizado na parte superior, menos usado na

parte inferior). Em seguida, sub-classificar as caixas de lista em grupos, a fim hieratical (maior grupo na parte superior, o menor do

grupo na parte inferior).

- Coloque selecione propriedades suspensas em cada mesa reta / pivô

- Use Variáveis ​como expressões em vez de definir as expressões diretamente no editor de expressão

- Ao criar um grupo de perfuração, adicionar uma expressão para a etiqueta do campo no grupo da broca. A expressão deve
ser igual a somente (Todos os campos Superior) e '>' e 'nome de campo atual, de modo que equivale a SalesRepA>
produtos. SalesRepA é o item que foi perfurado em, produto é os valores os quais são representados no gráfico

- Em vez de definir exceções nas tabelas em linha reta / pivô, em vez usar gráficos que mostram as exceções rapidamente
Diretrizes de Boas Práticas: Desenvolvimento

- Sempre inclua um Help tab / How-To e / ou um link para um site de ajuda em nosso site. Exemplos de guias Ajuda /
How-To estão incluídas na seção de Introdução no QlikView. Considere copiando um dos interativa How-To
páginas em um modelo que você pode usar todos os aplicativos.

- O nome de cada folha e objecto com cabeçalhos descritivos

- gráficos Preto e branco são os melhores quando se considera daltonismo e simplicidade

- Red & Green - Muitas pessoas são vermelho / verde cor-cego - considerar este exemplo ao usar pistas visuais

- Vermelho e verde também estão associados com bons e maus indicadores / performance. Apenas usar vermelho e
verde quando você quer dizer para indicar bons e maus.

- Projeto de resolução fixa que se aplica a suas organizações desktops (eg1024 x 768)

- Sempre considerar ordem de classificação e se apresentar frequência (# ou%) em caixas de lista (por vezes
muito útil, mas definitivamente não sempre)

- objetos repetidas (botões limpar) na mesma posição em cada folha

- caixas multi pode ser bom para as pessoas que são usados ​para trabalhar com QV, mas eles não são muito intuitivos. Caixas de

listagem tomar mais espaço, mas são melhores (você pode, por exemplo, ver as áreas cinzentas melhor).

- layout limpo em gráficos - alinhar títulos dos eixos, título do gráfico, texto, etc ...

- dimensões de hierarquia colocados em ordem

- Hora e datas são elementos cruciais da maioria dos aplicativos e eles devem ser altamente intuitiva para pesquisar e uso

- colunas da tabela deve ser sempre procurado (exibição totais nas tabelas sempre que fizer sentido)
Diretrizes de Boas Práticas: Desenvolvimento

QlikTech recomenda a incorporação de melhores práticas de design para todos os desenvolvedores e designers Ao iniciar uma
implantação QlikView QlikView. Bom design de interface leva a altas taxas de adoção e interfaces eficazes. camada de interface do
usuário rica do QlikView permite a visualização de classe mundial e design em todas as aplicações QlikView.

Para novas implantações do QlikView e novos designers recomenda-se fortemente que o treinamento Designer QlikView com a presença de
todos os desenvolvedores e designers. Os cursos de designer são estruturadas para reforçar bom design e para aprender as técnicas do
QlikView que ajudam a entregar esse projeto de uma forma simples e elegante. Eles também são uma grande oportunidade para a prática de
bom design e aplicar esse projeto a suas aplicações QlikView em um ambiente de laboratório.

UI design Referências:
QlikTech Local de Demo http://www.demo.qlikview.com

QlikTech Visual Design Apresentação no QlikCommunity DataVisualization.ppt


Informações Dashboard Design , Por Stephen poucos
Mostra-me os números , Por Stephen poucos

A apresentação visual de informações quantitativas , Edward R. Tufte

Explicações visuais , Por Edward R. Tufte


Diretrizes de Boas Práticas: Desenvolvimento
Scripting
visão global
Script é o ambiente em que um QlikView desenvolvedor irá automatizar o extracto, transformar e processo de carregamento
de trazer dados no ambiente QlikView. Cada documento QlikView (aplicação) contém um editor de script, através do qual
este processo está habilitado.

Melhores práticas ditam que usar várias guias dentro de um script irá dividir as várias partes, permitindo uma visão simples da
informação para o desenvolvimento e apoio futuro. Dependendo da complexidade da aplicação, você pode ter uma variedade de
diferentes seções de script. As partes comuns de um roteiro estão abaixo:

• Segurança (roteiro normalmente oculto)

• Datas e informações de calendário


• Tab por fonte de dados
• Separador por medida tabela de chave / núcleo

• Tab por tabela de pesquisa

Guia Segurança (Script Oculto)


No QlikView é possível restringir os privilégios de um usuário documento do Propriedades do documento: Segurança e a Propriedades da
folha: páginas de segurança. Todas as configurações podem ser alteradas se o usuário documento é registrado como ADMIN.

A identidade de usuário e senha necessário para abrir um documento restrito de usuários são especificados no script de carga e vai
aparecer no arquivo de log se você permitir QlikView para gerar um. No entanto, por ter o acesso do usuário no script escondido em
vez disso, o arquivo de log não vai dar qualquer informação de login. O botão Script Invisível abrir o script oculto é encontrado no
menu Editar Script.
Diretrizes de Boas Práticas: Desenvolvimento

precedendo Cargas
O uso de preceder as declarações de carga pode simplificar o seu script e torná-lo mais fácil de entender. Veja o código abaixo
para um exemplo disso.

Tabela 1:

CustNbr CARGA como [número do cliente],


ProdID como [ID do produto], andar (EventTime) como
[Data Evento], mês (EventTime) como [o mês de
evento], ano (EventTime) como [Ano Evento], hora
(EventTime) como [horas de evento];

SQL SELECT
CustNbr,
ProdID,
EventTime DE
MyDB;

Isto irá simplificar a instrução SQL SELECT para que o desenvolvedor pode continuar a testar / aumentam a
instrução usando outras ferramentas, sem a complexidade das transformações QlikView incorporados na
mesma instrução SQL.

Para mais informações sobre o recurso de carga anterior, consulte o Manual de Referência do QlikView.

Outras melhores práticas de script incluem:


- Use Autonumber somente após o desenvolvimento de depuração é feita. É mais fácil para os valores de depuração com um número

nele em vez de apenas ser capaz de usar substitutos. Consulte o Manual de Referência do QlikView, se você não tem certeza de

como / quando usar Autonumber.

- Coloque áreas em diferentes abas para que você não confundir os desenvolvedores com muita complexidade

- Nomeie o concatenate / associar-se declarações

- Ao adicionar script para um QVW, o melhor é fazer uma carga binário em grandes conjuntos de dados, em seguida, estender o

script. Mais tarde fundir o script após o desenvolvimento é quase completa. Isto não funcionalmente mudar alguma coisa, mas ele

economiza tempo durante o desenvolvimento.


Diretrizes de Boas Práticas: Desenvolvimento
- Use HidePrefix =%; para permitir que o desenvolvedor empresa para ocultar os campos-chave e outros campos que raramente
são usados ​pelo designer (este só é relevante quando co-desenvolvimento está sendo feito).

- Ao utilizar a função Applymap (), preencher o valor padrão com o padrão algo como 'desconhecido' & valor que é
desconhecido para que os usuários sabem que o valor é desconhecido e pode ir preenchê-lo no sistema de origem sem que
os administradores têm que se envolver. Consulte o Manual de Referência do QlikView, se você não tem certeza de como /
quando usar Applymap ().

- usuário nunca sublinhados ou barras (ou qualquer coisa 'techie') nos nomes de campo. Em vez nomes de usuário amigável
código, com espaços.

- Em vez de: “mnth_end_tx_ct” uso: “Month End Conde Transação”

- Só use Qualificar * quando absolutamente necessário. Alguns desenvolvedores usar Qualificar * no início do script, e só unqualify
as chaves. Isso faz com que um monte de scripting problemas com junte esquerda declarações, etc. É mais trabalho do que vale
a pena no longo prazo. Consulte o Manual de Referência do QlikView, se você não tem certeza de como / quando usar Qualificar
e Unqualify.

- Use “Incluir” arquivos ou roteiro escondida para todas as conexões de banco de dados ODBC / OLEDB.

- Use variáveis ​para o nome do caminho, em vez de codificar-los em todo o seu script. Isto reduz a manutenção e também
fornece uma maneira simples de encontrar caminhos (supondo que você colocá-los na primeira guia para torná-lo fácil de
encontrar).

- Todas as referências de arquivo deve usar UNC convenção de nomenclatura. Não use C: \ MyDocs \ ...

- Sempre tem a opção de Logfile ativado se você precisa capturar informações em tempo de carga para degbugging propósito

- Comentar cabeçalhos de script para cada guia. Veja o exemplo abaixo:


Diretrizes de Boas Práticas: Desenvolvimento

- Comentar seções de script dentro de um guia com breves descrições. Veja o exemplo abaixo:

- Adicionar mudança de comentários de data se for o caso. Veja o exemplo abaixo:

- Use recuo para fazer roteiro mais legível pelos desenvolvedores. Veja o exemplo abaixo:

- Nunca use CARGA * em uma instrução de carregamento. Em vez disso listar as colunas para carregar explicitamente assim

que você sabe quais campos serão carregados e isso não vai mudar à medida que novas colunas são
Diretrizes de Boas Práticas: Desenvolvimento
adicionados ou excluídos tabelas de origem. Isso também ajuda os desenvolvedores a identificar os campos carregados no script.
Veja o exemplo abaixo:

Listas de verificação de desenvolvimento


QlikTech recomenda o uso de uma lista de verificação desenvolvedor para destacar e reforçar as melhores práticas de desenvolvimento.

A maioria dos clientes corporativos desenvolver este a partir de um modelo ou de exemplo de boas práticas. Consulte o seu Executivo de
Contas ou Serviços Director Regional para uma amostra da QlikTech. Uma maneira de ajudar a promover a visibilidade ea presença do
checklist é limitá-lo a uma página e laminado-lo para cada desenvolvedor. Isto tornará mais fácil para publicar a lista de verificação e
consultá-la frequentemente. Alguns clientes vão usar a lista de verificação em revisões de código para garantir que as melhores práticas foram
seguidas antes de liberar um QVW para teste ou ambientes de produção.
Diretrizes de Boas Práticas: Desenvolvimento

Uma amostra de imagem de uma lista de verificação é abaixo:


Diretrizes de Boas Práticas: Desenvolvimento
Modelos de dados
Representado abaixo são diagramas de 3 modelos de dados básicos que podem ser construídos em QlikView (juntamente com muitas
outras combinações). Usando estes exemplos 3 podemos demonstrar algumas das diferenças em termos de desempenho,
complexidade e flexibilidade entre eles.

Opção 1 opção 2 opção 3


Floco de neve Star Schema Mesa única

Enquanto esquemas estrela são geralmente a melhor solução para aplicações rápidas, flexíveis QlikView, há momentos em que são
necessárias várias tabelas de fatos. Aqui estão as formas erradas e direita para se juntar a eles:
Diretrizes de Boas Práticas: Desenvolvimento

Outros exemplos de como construir e mesas de utilização de link estão contidas em QlikCommunity na linha ( http://community.qlikview.com/
)

Além de modelagem para várias tabelas de fatos, uma alternativa é para concatenar as duas tabelas de fatos em uma
única tabela fato. Isto é ilustrado abaixo.

Para mostrar como isso poderia ser feito, a seção abaixo leva-nos através de um cenário de duas tabelas de fatos a serem
combinadas em uma tabela de fatos.
Diretrizes de Boas Práticas: Desenvolvimento
Diretrizes de Boas Práticas: Desenvolvimento
Um exemplo de tabela deste concatenação de tabelas de fatos é mostrado abaixo.
Diretrizes de Boas Práticas: Desenvolvimento

Grandes conjuntos de dados


QlikView pode lidar com grandes conjuntos de dados e rotineiramente faz isso. No entanto, para otimizar a experiência do usuário e
hardware necessário, você tem opções.

Considere o seguinte cenário: Você tem um grandes encomendas conjunto de dados (1 bilhão de linhas). Você precisa fornecer métricas de
resumo de alto nível para seus executivos, análise de tendências para seus analistas de negócios e tabelas de detalhes e valores para sua
equipe de processamento de pedidos. Você tem muitas opções de design de dados com QlikView, mas para fins de demonstração vamos
explorar apenas 3 deles abaixo:

1) tabela de fatos detalhada única - permitir QlikView para fazer todo o trabalho para exibir os detalhes e resumir
métricas do menor nível de detalhe para o mais alto resumo necessário.
uma. Vantagens - simplicidade. Esta é a solução mais fácil de código. Basta ligar as ordens em um nível
detalhado (talvez nível SKU) para o modelo de dados e projetar todas as métricas de alto nível,
tendendo gráficos e tabelas detalhados e seleções no QVW.

b. Desvantagens - QlikView precisará agregar até 1 bilhão de linhas de detalhe com cada seleção feita. Enquanto
QlikView é provavelmente a única ferramenta de BI que pode fazer isso com um desempenho aceitável, ainda vai
resultar em uma experiência de usuário mais lento do que ele precisa.
Diretrizes de Boas Práticas: Desenvolvimento

2) Documento encadeamento - 2 (ou mais) versões do QVW são construídos. Um deles tem a tabela Pedidos detalhados
como a tabela principal fato, os outros têm versões de tabela Pedidos pré-agregados como suas tabelas de fatos
primários. Vamos supor apenas 2 QVWs para este caso. Você tem um diagrama abaixo mostra o modelo de dados do
“Resumo” QVW e um modelo de dados do “detalhe” QVW. Note-se que os valores das dimensões são praticamente os
mesmos entre os dois modelos. A principal diferença é a tabela de fatos no modelo de dados. Os usuários podem iniciar
a partir da aplicação resumo, mostrando métricas de alto nível e gráficos.

Se eles querem furar detalhes você pode usar o recurso de encadeamento de documentos no QlikView para transferir
seleções de um QVW para outro QVW e abrir essa segunda QVW. O usuário verá novas tabelas e guias aparecer e (se
você projetá-lo como tal) nem sequer precisam saber que eles têm trasferred de um QVW para outro. Isto significa que
você só vai estar usando a tabela de fatos a 1 bilhão de linha quando os usuários precisam. O resto do processamento
ocorrerá na versão pré-agregada de tabela Pedidos, o que pode ser menor do que 100 milhões de linhas, por exemplo.
Documento encadeamento é discutido em detalhes no Manual do QlikView de Referência e em vários documentos
QlikView.

uma. Vantagens - otimiza hardware e rapidez de resposta para navegação QlikView e gráficos. Porque seleções e
navegação dos usuários são específicas para suas necessidades, você não perca CPU e memória RAM de
processamento de 1 bilhão de linhas de detalhe quando o usuário não precisa de coisas processados ​nesse nível.

b. Desvantagens - tabelas (QVDs) precisam ser pré-agregados e mantida por esta abordagem. Enquanto este é um
esforço de desenvolvimento de uma só vez, é um pouco mais complexa do que a opção 1, onde é necessária
apenas uma versão de tabela Pedidos.
Diretrizes de Boas Práticas: Desenvolvimento

3) A terceira opção (e não significa o último) é a utilização de uma tabela de resumo de pré-agregadas em
adição à a tabela detalhada em um único modelo de dados QVW. O diagrama mostrado abaixo é uma maneira de usar uma
tabela de pré-agregados no mesmo modelo de dados como a versão detalhada da tabela. Você poderia carregar a tabela
pré-agregados como uma ilha de dados (não ligado a outras tabelas no modelo de dados). Então, como seleções
relevantes na tabela de fatos detalhados são feitos você pode transferir essas seleções para a mesa pré-agregadas usando
uma ação desencadeada (QlikView versão 9 e acima).

uma. Vantagens - esta opção não requer uma segunda QVW e encadeamento de documento, a fim de usar as
versões detalhadas e sumárias de uma grande mesa.
b. Desvantagens - esta opção vai exigir alguns ajustes a serem feitos no QVW para desencadear as ações que
transferem seleções de uma tabela para outra. Como as mudanças QVW ao longo do tempo, você vai precisar
para manter o controle de onde / quando fazer estas ações disparam.
Diretrizes de Boas Práticas: Desenvolvimento

Atenção: estes são muitas mais maneiras do que poderia satisfazer as necessidades descritas no cenário acima. Estes são apenas 3
mothods que chamam as funcionalidades e capacidades do QlikView para gerenciar grandes conjuntos de dados. Por favor, consulte
Arquitetura Guia de Melhores Práticas para mais exemplos de maneiras de gerenciar grandes conjuntos de dados e grandes
implementações de QlikView de uma forma optimizada.

Os principais fatores que afetam o modelo:


• dados coluna distinta.
• informações de campo chave distinta.

Ambos podem afetar o tamanho da memória do modelo de dados e experiência do usuário. Por ter muitas mesas, as ligações podem tornar-se

um devorador de memória.

Tem sido conhecido que você pode reduzir a sua cópia do pé de memória por cinqüenta por cento ao modificar a estrutura de dados;
e, assim, adicionalmente, aumentar a resposta UI.

Consulte a seção Otimização deste documento para obter dicas úteis na redução do tamanho e complexidade do seu modelo
de dados.
Diretrizes de Boas Práticas: Desenvolvimento
Variáveis, Ações e macros

variáveis
(A seguir é tirado de um post no blog: http://www.quickqlearqool.nl/?p=902 )

Neste post eu quero compartilhar com você uma boa prática em lidar com as várias expressões que existem em um documento

QlikView. As expressões mais utilizadas são as utilizadas em gráficos, onde eles mantêm medidas como Sum (Sales), Sum

(Preço * Quantidade), etcetera. Estes são os mais propensos a ser reutilizados por outros objetos e em diferentes folhas. Há

muitas outras expressões incluindo atributos Gráfico, expressões cores e mostrar as condições, você pode vê-los todos, indo para

o menu Configurações / Expression Overview.

As expressões mais utilizadas são as utilizadas em gráficos, onde eles mantêm medidas como Sum (Sales), Sum (Preço *

Quantidade), etcetera. Estes são os mais propensos a ser reutilizados por outros objetos e em diferentes folhas. Há muitas

outras expressões incluindo atributos Gráfico, expressões cores e mostrar as condições, você pode vê-los todos, indo para o

menu Configurações / Expression Overview.

O uso de expressões pode ser intensivo em QlikView, especialmente quando se tem uma interface de usuário sofisticada. Há uma

necessidade crescente de lidar com essas expressões de uma forma mais eficiente, e isso pode ser feito com o uso de variáveis.

Razões para a realização de expressões em variáveis:

• Para alcançar a reutilização: a fórmula para uma medida como vendas geralmente permanece o mesmo em um

documento QlikView, por isso não faz sentido para escrevê-lo em cada gráfico.

• Para reforçar a consistência nas fórmulas:, evitando o risco de ter fórmulas diferentes que calculam a
mesma medida.

• Para fornecer um único ponto para aplicar as alterações: se e quando uma fórmula precisa ser mudado, você só precisa

mudar uma variável e todas as cartas e outros objetos que fazem referência a essa variável se seguirão.

• Para permitir que o usuário final para fazer alterações através de uma caixa de entrada, quando necessário. Este poderia ser o caso

de metas de KPIs ou parâmetros gerais.


Diretrizes de Boas Práticas: Desenvolvimento
As variáveis ​podem ser criadas manualmente, indo para o menu Configurações / Resumo Variável ou usando o SET / DEIXE

declarações no script. Eles têm um nome e um valor, que pode conter qualquer tipo de strings ou números, e eles podem ser

usados ​como uma referência de cada objeto folha. A Caixa de Entrada é o objeto projetado para mostrar variáveis ​na interface do

usuário.

Se você quiser começar a experimentar com mover suas expressões a variáveis ​tente o seguinte:

1. Vá até a aba Expressões em uma de suas cartas e copiar uma das fórmulas, por

exemplo Soma (SalesValue)

2. Vá para o menu Configurações / Visão geral da variável e clique no botão “Adicionar” para criar uma

variável. Dê-lhe um nome como vFormulaSales (é uma boa prática para ter todos os nomes de variáveis ​começando

com av para ajudar a diferenciá-los dos Campos).

3. Selecione a variável da lista de variáveis ​um colar a fórmula do gráfico no


caixa de texto “Definição”. Se a fórmula começa com um sinal =, removê-lo. Por fim, clique em “OK” para salvar as alterações.

4. Volte para a guia Expressões de suas propriedades do gráfico e substituir a fórmula com

o seguinte: $ (vFormulaSales)

A expansão de US $ sinal indica a string contida na variável é uma fórmula que precisa ser calculado.

O passo final é a de substituir substituir as fórmulas clonados em todos os outros objectos de modo que todas elas se referem à

mesma fórmula contida na nova variável. Cada novo objeto que precisa mostrar Sum (Sales) também deve se referir à variável.

Você já pode ter muito poucos documentos QlikView onde não se aplicam esta prática, mas nunca é tarde demais para
começar. No longo prazo, é realmente vale a pena.

<Conteúdo do blog final>


Diretrizes de Boas Práticas: Desenvolvimento
As variáveis ​são comumente usados ​para ajudar a mudar as configurações de banco de dados entre ambientes sem disco rígido
codificação exigido no QVW como ele se move de um ambiente para. Consulte o código de exemplo abaixo para uma melhor técnica
prática para fazer isso:

SET vEnvironment = 'PROD';

IF vEnvironment = 'PROD' ENTÃO


· · · ODBC CONNECT TO MyOracleDBProd ( XUserID é *****, Xpassword é ****)
SET vDBName = ' MyOracleDBProd ';
ELSEIF vEnvironment = 'teste' ENTÃO
· · · ODBC CONNECT TO MyOracleDBTest ( XUserID é *****, Xpassword é ****)
SET vDBName = ' MyOracleDBTest ';
OUTRO

· · · ODBC CONNECT TO MyOracleDBDev ( XUserID é *****, Xpassword é ****)


SET vDBName = ' MyOracleDBDev ';
FIM SE

Em suas declarações carga que você agora fazer referência ao vDBName da seguinte forma:

SQL SELECT * FROM $ ( vDBName). meu_esquema.minha_tabela;

Existem dois métodos simples para alterar esse valor variável de ambiente para ambiente como o QVW é promovido:

1) forçar o desenvolvedor ou administrador para alterar manualmente o valor da variável no script

2) Use um arquivo com o SET vEnvironment Incluir .... declaração nele. Cada ambiente tem seu próprio arquivo de texto
declaração inlcude que permanece no ambiente. O QVW será carregado no arquivo de inclusão que existe em seu
diretório, assim, sempre recebendo o conjunto variável adequada para seu ambiente.

As variáveis ​também podem ser usados ​para armazenar expressão comum lógica (métrico) e usado em vários documentos QlikView. A lógica de

expressão pode ser armazenado em Excel, um arquivo simples ou em um banco de dados.


Diretrizes de Boas Práticas: Desenvolvimento
O exemplo abaixo mostra algumas expressões armazenadas em um arquivo do Excel relacionada com métricas médico.

Essas variáveis ​são então lidas em arquivos QVW usando uma instrução LOAD simples e, em seguida, convertido em variáveis
​usando esta lógica a seguir:

Uma vez feito isso as variáveis ​podem ser usadas em quaisquer expressões na QVW. Um exemplo da lógica de expressão para
utilizar a variável é mostrado abaixo.

Este método permite o gerenciamento central da lógica em métricas. Você pode simplesmente mudar e melhorias de lógica de teste em uma
planilha ou banco de dados e, em seguida, permitir que os QVWs para recarregar a lógica da próxima vez que são acionados para recarga.
Diretrizes de Boas Práticas: Desenvolvimento
macros
A seguir estão algumas reflexões que você deve estar ciente de quando você começa incluindo instruções de macro em seu
aplicativo.

Executando uma macro automaticamente exclui todos os caches, desfazer-disposição buffers e desfazer buffers operação lógica
e este, em geral, tem um grande im-pacto negativo no desempenho como experimentado pelos clientes. A razão para a exclusão
do caches etc é que é possível modificar as propriedades, as seleções do mac-ros, abrindo assim para conflitos entre o estado
em cache e o estado que foi modificado a partir de uma macro e esses conflitos vão quase sempre falhar ou pendurar os clientes
(e no pior dos casos, travar ou falhar o servidor também).

Os próprios macros são executadas a nível VBS enquanto QlikView no gen-eral é executado a nível assembler que é milhares de
vezes mais rápido por de-culpa. Além disso, as macros são único síncrono roscada em oposição ao QlikView que é assíncrono e
fortemente roscado e isto faz com que as macros para interromper de forma eficaz todos os cálculos em QlikView até acabado e
depois QlikView tem de continuar todos os cálculos interrompidos, que é um processo delicado e muito mais um fonte (pelo
menos historicamente) para impasses (ie QlikView congela enquanto a macro ainda está em execução, sem qualquer
possibilidade de que a macro será terminado).

Enquanto QlikView é cada vez mais optimizado em termos de desempenho e sta-dade, as macros irá sempre manter o seu
pobre desempenho e a abertura ser-tween funcionalidade QlikView genuíno e as macros continuará em-rugas, tornando
macros menos e menos desejáveis ​de um desempenho ponto de vista. Este facto combinado com o fato acima, que as
macros tendem a sob-mine todas as otimizações feitas no QlikView pede compensações negativas graves assim que
macros se uma parte integrante de qualquer aplicação maior.

As macros são de natureza secundária quando se trata de funcionalidade QlikView - primeiros todas as funções do QlikView básicos
internos são executados e testados e, posteriormente, as macros são executados e testados que efetivamente significa que macros
nunca terá o mesmo status ou prioridade como funcionalidade básica QlikView - sempre macros con-sider como um último recurso, mas
nada muito mais. Como a API de automação reflete o QlikView básico em termos de propriedades de objetos etc., o teor de macro pode
realmente mudar entre as versões tornando esta uma área muito comum para as questões de migração. Uma vez que uma macro é
incorporada em um aplicativo, esta aplicação tem de ser revisto a cada nova versão, a fim de se certificar de que as macros não foram
afetados por quaisquer alterações estruturais no QlikView e isso faz com macros extremamente pesado em termos de manutenção.

Apenas um subconjunto de macros irá trabalhar em um ambiente de servidor com thin clients (Java, Ajax) desde que as operações locais (cópia

para área de transferência, exportação, impressão etc.) não são suportadas, embora alguns deles têm um equivalente do lado do servidor (por

exemplo, servidor -SideExport etc.) que é muito caro em termos de desempenho com cada cli-ent afetando de forma eficaz o desempenho do

servidor de uma forma negativa.

Em conclusão: o que estamos lutando por uma maior consciência quando se trata de macros e o que pode funcionar com
alguns milhares de registros não necessariamente escala muito bem quando macros estão envolvidas e os problemas tende
a manifestar-se e tornar-se mais grave quando
Diretrizes de Boas Práticas: Desenvolvimento
conjuntos de dados são maiores em-vidos. Também é importante notar que certos eventos só pode ser capturado através do uso de
macros e, por essa razão, pode ser difícil evitar macros completamente. O departamento de R & D sempre se esforça para incorporar o
máximo desta funcionalidade quanto possível, a funcionalidade básica QlikView, limitando assim o uso de macros no longo prazo - no
entanto como afirmado anteriormente: certos eventos são difíceis de apanhar, exceto a partir de uma macro do lado de fora ...

Dado tudo o que precede, macros não pode ser parte de qualquer padrão de design QlikView recomendado!

Ações
A ação é uma nova entidade no QlikView 9. Elas são derivadas dos antigos atalhos de botão, que também substituir. Além
de oferecer uma gama muito maior de operações do que os antigos atalhos (incluindo a maioria das operações comuns em
folhas, objetos folha, campos e variáveis), você também pode definir uma série de operações em uma única ação. A
introdução de ações devem reduzir muito a necessidade de macros, que é bom desde macros não são eficientes do ponto de
vista do desempenho.

As novas ações não só pode ser usado em botões. Também objetos de texto, linha / objetos de seta e gráficos de calibre
podem ser dadas ações, que são executadas ao clicar no objeto de folha em questão.

As macros de disparo das versões anteriores do QlikView foram substituídas por ações de disparo. Isto dá-lhe a possibilidade de
construir gatilhos bastante elaboradas sem o uso de macros. macros gatilho de versões anteriores serão automaticamente
traduzido para uma acção ExecutarMacro quando carregado no QlikView.

Leia mais sobre disparadores do QlikView Manual de Referência.


Diretrizes de Boas Práticas: Desenvolvimento
Gerenciamento de Projetos

visão global
As recomendações nesta secção destinam-se a ser explorado e decidida antes do início do projeto, não
durante a fase de implementação.

SCRUM Metodologia funciona bem com o QlikView. Alguns fatores importantes são
• Desde projetos QlikView são muito rápida, métodos de reuniões do projeto frequentes do SCRUM trabalhar bem com o
desenvolvimento QlikView

• Um método de notificação deve ser configurado entre desenvolvedores concorrentes quando um deles estão mudando objetos

compartilhados

• Definir processos para:


• QA
O que denota um 'erro' ao executar QA?
• dados incorretos / totais são erros
• Incorretas etiquetas / descrições são erros que
denota uma 'Melhoramento'?
• Alterações no layout (adicionar, alterar itens) são melhorias se o item /
folha já passou a aceitação inicial pelo usuário final

* É importante para denotar entre erros e aprimoramentos porque os erros devem ser corrigidos,
Melhorias deve obter aprovação antes de serem implementadas. Nós tentamos ficar longe de
melhorias durante QA, uma vez que pode nos obrigar a re-QA um monte de trabalho.

• Pedidos de mudança
O que devemos fazer quando um usuário pede para mudar os itens? Quando é que vamos ter que pedir

permissões?

• Comunicação e plano de execução


• Quando é que as principais partes interessadas se reúnem para passar por cima de mudanças de escopo, ou solicitações de melhoria?

metodologia DSDM
• Com base na metodologia RAD
• Um dos métodos ágeis; parte da Agile Alliance
• Semelhante ao SCRUM em processo e conceito, porém:
- Menos jargão do que SCRUM
- Sem educação em papéis e títulos SCRUM
- documentos menos necessário
• Globalmente reconhecida metodologia Agile RAD
• Iterativo e incremental
• Ênfase na participação do usuário contínua
Diretrizes de Boas Práticas: Desenvolvimento
• Concentre-se em “no prazo, no orçamento”, a consciência âmbito encaixotado-time

• Ajustes para requisitos variáveis ​construídos para agendar


• Facilmente dobrado em mais abrangentes projetos de clientes e PMO de

• “Linguagem simples” esforço do projeto, papéis e documentação.


• volta cíclica de vendas adicionais e oportunidades de receita

Metodologia RAD / DSDM


• RAD = Implantação Rapid Application
• DSDM = Dynamic Systems Development Method
- metodologias RAD e DSDM altamente reconhecido na América do Norte e Europa como parte da Agile
Alliance Project Management
- metodologias RAD e DSDM encaixa no perfil típico projeto QlikView com modificações
mínimas
- metodologias RAD e DSDM pode ser referenciado e pesquisou a governança do projeto
ajudante e modelos
- metodologias RAD e DSDM fornecer uma base para a transferência de conhecimentos
- metodologias RAD e DSDM são exigência de recursos e documentação magra ainda completa

RAD / Elementos DSDM


Fases do projeto 3 fases:
• Pré-projeto
• Projeto de Desenvolvimento do ciclo de vida

• Pós-projeto
Roles Projeto de Recursos Equipe 6 Roles
• Proprietário do Projeto / Patrocinador

• Analista técnico
• Gerente de Projetos / Analista de Negócios

• Consultor especialista em Serviços

• QlikView Service Partner desenvolvedor


• Equipe do Projeto Cliente
Documentos necessários 8 Documentos
• Carta projeto com escopo
• Requisitos: Negócios, funcional,
não-funcionais, técnicas
• Plano & resumo do teste
• Cronograma e Plano de Projeto

• Design & Development Resumo


• Transferência de Conhecimento e Assistência

Resumo

• Equipe de pós-projeto Resumo


Entrevista
• Cliente Resumo satisfação Entrevista
Diretrizes de Boas Práticas: Desenvolvimento
Documento de noivado “Definição do Projeto”

Documento único com documentação


tabelas:
• Carta Purpose, Resumo Executivo, Visão Geral
do Projeto, Espaço com metas, objetivos e
resultados e Condições com suposições, plano
de comunicação, issue tracker, rastreador de
riscos, restrições e caminho de escalonamento,
abordagem estruturada, Plano de Organização
Team, Equipe Contato Links

• Documentos Apêndice: cronograma do projeto


(planilha eletrônica), Porca, solicitações de
mudança, resumos marco (requisitos, projeto e
desenvolver, testar, implantação)

Cronograma do projeto planilha Excel exportável para MS Project, et al software de


gerenciamento de projeto, com base em formatos MS Project
Diretrizes de Boas Práticas: Desenvolvimento
Mostrado abaixo é um plano de projeto de exemplo para um projeto QlikView. QlikTech recomenda que um plano de projeto ser
criado e seguido para projetos QlikView, e que a ajuda de um gerente de projeto qualificado ser procurado para projetos
maiores. Muitos outros modelos e exemplos estão disponíveis através QlikTech Serviços Especializados ou on-line através
QlikCommunity.
Diretrizes de Boas Práticas: Desenvolvimento
Segurança (Seção Access)
Seção O acesso pode ser configurado no script QlikView para lidar com segurança. Ela está contida dentro do
. arquivo qvw, ou seja, a um único arquivo pode ser feita para conter os dados para um número de usuários ou grupos de usuários.
QlikView vai usar as informações na seção de acesso para autenticação e autorização e reduzir dinamicamente os dados, de modo
que um usuário só vê os dados que ele / ela é permitido.

QlikView fornece os seguintes níveis de acesso:


Admin - pode mudar tudo no documento. usando o Segurança página na
Propriedades do documento e Propriedades da folha diálogos, uma pessoa com acesso de administrador pode limitar as possibilidades

de modificar o documento dos usuários. USUÁRIO - não pode acessar as páginas de segurança.

NONE - opcionalmente utilizadas para maior clareza, sempre tratados como “nenhum acesso”.

Enquanto QlikView Publisher pode usar o seu “loop e reduzir a” funcionalidade para reduzir a QVW por fileiras por usuário ou
grupo como está sendo recarregada, você também pode fazer isso na seção de acesso dinamicamente à medida que o
documento é aberto. Qualquer método irá funcionar, e ambos têm benefícios. The Loop e reduzir a partir do Publisher irá
ajudá-lo a reduzir o consumo de memória dos QVWs em seu servidor (s), enquanto o método seção de acesso é portátil com o
documento. Outro motivo para usar seção de acesso é a aplicação de autenticação no QVW, através de um ID de usuário,
senha ou ambos. Isto é especialmente importante se o QVW vai estar habilitado para download no AccessPoint ou distribuído
para os usuários.

QlikTech recomenda que QVWs que serão distribuídos deve ser protegido por senha, ou pelo menos validado contra
um userID com a Seção Access.

Melhores práticas ao utilizar Seção Acesso:


• Na Seção Access, sempre use a função UPPER () ao utilizar uma declaração de carga, usá-lo em cada coluna, não
importa o quê. (Mesmo quando a leitura de .qvd)
• Grupos de anúncios para a segurança

• Segurança em incluir arquivos

• Adicionar conta de serviço do Publisher para mesa acessar a seção


• Utilizando projeto um 'esquema Star' para o modelo de dados sem tabelas de link. Vincular tabelas prejudicar o desempenho muito!

• Melhor caso é ter uma tabela de fatos com as dimensões todos diretamente ligados ao fato. Em casos raros, deve
ser usado '' Snowflaked dimensões adicionais.
• Nas tabelas verdade, não têm mais de 30 - 40 colunas definidas. (Pode haver um pouco mais / menos, mas não têm 150
colunas a menos que você fato é menos de 10 milhões de discos (com um servidor decente)

• Muitas vezes, com muitas colunas são uma situação provocada pela utilização de 'Role Playing Metrics'.
Embora isso possa ser útil, também muitas dessas métricas criar uma degradação de desempenho no
servidor.
Diretrizes de Boas Práticas: Desenvolvimento
Otimização
visão global
Quando a fase de desenvolvimento em um aplicativo está completa e a fase de implantação começa, é muito importante
considerar as melhores práticas para otimizar a pegada do aplicativo para que a experiência do usuário final é suave e sem
costura. Esta seção discute as melhores práticas de otimização de dados e manipulação de expressões.

carga de dados
Após a carga, soltar todos os campos desnecessários. Um desnecessária arquivado é aquele que não é usado atualmente em
gráficos, caixas de listagem, etc. Algo que não está sendo usado. Há utilitários aplicativos QlikView disponíveis no QlikCommunity
que identificarão as colunas não utilizados em sua QVW e até mesmo gerar as instruções DROP necessários para eliminá-los do
seu modelo de dados. Uma imagem do UnsedFields.QVW é mostrado abaixo. Este QVW é acessível em QlikCommunity para
download e utilização gratuita.
Diretrizes de Boas Práticas: Desenvolvimento
• Se os seus dados é enorme, decide dividi-lo em vários prazos. Por exemplo: Tenha um “Este ano vs ano passado”
QVW, um segundo que tem 5 anos de dados (ou mais), uma vez que a maioria das pessoas querem ver este ano
contra o ano passado. (se esse é o caso). Nota: isto também resulta em uma experiência de usuário final muito mais
rápido. Vamos supor que você descobre que 80% de seus usuários só olhar para os últimos 13 meses de dados, mas
o seu QVW detém 60 meses de dados. Se você criar duas versões do QVW (aquele que detém apenas os últimos 13
meses e outra que contém todos os 60 meses) você pode permitir que os usuários primeiro analisar a versão de 13
meses do QVW e, em seguida, conectar-se a outra versão apenas quando necessário . Isto irá resultar em 80% de
suas sessões de usuários finais que consomem uma fração do RAM, CPU e tempo de processamento que eles
tinham antes de dividir a aplicação.

• Não normalizar os dados demais. Plano para 6 - 10 mesas totais numa típica aplicação QlikView. Esta é apenas uma orientação,
mas há um equilíbrio a ser alcançado com modelos de dados do QlikView. Consulte a seção Modelo de Dados deste documento
para obter mais detalhes.

• Eliminar pequenas “folha” tabelas utilizando Mapeamento de carga para rolar valores de código para outras dimensões ou tabelas

de fatos.

• Eliminar Count (Distinto x) 's Eles são muito lentos

• Eliminar números de contagem, ou Contagem textos, eles são quase tão lento como Count (Distinct)

• Armazenar qualquer coisa possível como um número em vez de uma string

• De-normalizar tabelas com um pequeno número de campos

• Usar inteiros para se juntar tabelas juntos

• Só permitem um nível de neve em flocos dimensões do registro fato. (Fato, dimensão, floco, nenhum)

• Use Autonumber quando apropriado

• Usar modelo Carga Incremental para carregar de forma incremental e quebrar os arquivos .qvd históricos em .qvds
individuais com base no prazo incrementais

• Sempre use caminhos relativos ao fazer referência para arquivos


Diretrizes de Boas Práticas: Desenvolvimento

• Use nomes UNC, ou tarefas automatizadas pode não ser capaz de referenciar os caminhos

• Preferências do usuário local em um arquivo de inclusão

• Incluir arquivos para conexões

• timestamp dividido em campos data e hora quando for necessário data e hora

• Remover tempo entre a data por andar () ou por data (data # (..)) quando não é necessário tempo

• Reduzir os campos-chave ampla concatenadas via autonumber (), quando todas as tabelas relacionadas são processados ​em um

roteiro

• (Não há nenhuma vantagem ao transformar os campos alfanuméricos, quando a corda eo campo numérico
resultando têm o mesmo comprimento)

• Use campos numéricos em funções lógicas (comparações de string são mais lentas)

• (A - b) / b melhor: (a / b) - 1

• data (max (sdate, 'DD.MM.YYYY')) é fator de xxx mais rápido do que

max (data (sdate, 'DD.MM.YYYY'))

• É a granularidade dos dados de origem necessários para a análise? “Soma () grupo por”

• Utilizar bandeiras numéricos (por exemplo, com 1 ou 0), os quais são pré-calculado no script

• sum (Flag * Valor) vs. soma (if (Bandeira, Valor))

• Reduzir a quantidade de objectos gráficos abertos

• Calcule medidas dentro do script (tamanho do modelo <> desempenho on-line)

• Limitar a quantidade de expressão dentro de objectos gráfico / articulação, distribuí-los em vários objectos (utilização de auto

minimizar)

• De-ativar Hyperthreading dentro BIOS do servidor; Hyperthreading (somente Intel CPUs) pode abrandar o processamento
do script

• Tenha muito cuidado usando Macros!


Diretrizes de Boas Práticas: Desenvolvimento

• Para grandes QVWs você pode otimizar ainda mais por seleções pré-cache na RAM. QlikView armazena um resultado de um
cálculo fórmula regular dentro de diagramas para a memória cache compartilhado. O mesmo utilizador ou também outro
utilizador obtém o resultado do cache quando a fórmula e os filtros são o mesmo, ou seja, o resultado é entregue
imediatamente, sem qualquer processamento. O cache entradas permanecem na memória cache atribuído até o QVmodel é
recarregado por exemplo, após uma atualização. Isto significa que os primeiros usuários após uma recarga tem que aceitar o
tempo de espera, porque o cache está vazio. Esta emissão pode ser resolvido através de um script do Visual Basic (VBS) que
simula as seleções do usuário na aplicação e que pode ser iniciado automaticamente (através de uma tarefa execução externa
no Publisher) após a atualização do modelo de dados.

Esta amostra VBS abaixo atravessa todas as pastas da aplicação, abre todos os diagramas e seleciona todos os
campos da Região dimensão
Diretrizes:
Diretrizes de Boas Práticas: Desenvolvimento
Desenvolvimento

Use
1. Use
Use expressões
expressões
expressões Condição
Condição
Condição dede
de cálculo
cálculo
cálculo para
para limitar
limitar
limitar o cálculo
oo cálculo
cálculo de muito
dotabelas
de muito que não
muito é relevante.
grandes quando
O cálculo
O cálculodode objectos
diagrama de diagrama
objetos - especialmente comespecialmente
muitos complexo pode causar
com muitos uma carga
complexo

significativa
fórmulas sistema
- podempode
causar e,uma
uma
causar portanto,
carga umsistema
temposistema
significativa
carga de de espera, e,quando
e, portanto,
significativa nenhum
um
portanto, tempo
algum filtro é definido.
de espera,
tempo de Pode
quando
espera, fazer sentido
nenhum
quando nenhum forçar o Pode
filtro é definido. usuário
para selecionar
fazer sentido um ano,a uma
forçar o usuário categoria
selecionar de produto ou de uma região ou de todas essas
um sim dimensões
r, uma antes
categoria de do cálculo
produto ou um do

região ou todas
diagrama de estas dimensões
objetosdimensões antes de
é iniciado. antes de oo cálculo
cálculo do
do diagrama
diagrama de
de objectos
objectos ééiniciado.
iniciado.

2. Utilize
Utilizevariáveis
Utilize variáveis​e​e/ ou
variáveis /ou Set Análise
ouanálise
análise vez deemcálculos
apresentada
apresentada em
vezvez decálculos
de dados
de cálculos complexos
de dados
de dados em em
expressões.
complexos
complexos Usando
Usando funções
em expressões.
expressões. detempo
funções de tempo
dentro

dentro
de de expressão
expressão (1resulta no tempo de 3 mais tempo em comparação
(1-3 abaixo) abaixo) resulta
comemumtempo decomparação
simples espera 3-15(4vezes
abaixo) ou para definir

Análise
mais (5 abaixo)
longo de espera.
em comparação com um
com um simples
simples comparação
comparação (4
(4 abaixo)
abaixo) ou
ou para
paradefinir
definirAnálise
Análise(5
(5abaixo).
abaixo).

(inmonth (Date,
1. sum (if (inmonth (Date, data
data (max
(max (Data
(Datatotal)),
total)),- 12), Vendas)) inmonth (Date,
2. sum (inmonth (Date,
data (max datatotal)),
(Data (max (Data
- 12) *total)),
-1 * Vendas)
3. sum (if (inmonth (Data, vPYMonthEnd, 0), Vendas))
4. sum (if (Data> = vPYMonthStart e data <= vPYMonthEnd, Vendas))
5. sum ({$ <Date = { “> = $ (vPYMonthStart) <= $ (vPYMonthEnd)”}>} Vendas)

Estas melhores
melhores práticas
práticasde
práticas deotimização
de otimizaçãosão
otimização sãodemonstradas
são demonstradaseeepraticadas
demonstradas praticadas
praticadas no
no
no Developer
Developer
Developer eformação
formação
eeformação Designer
Designer
Designer cursos
cursos
cursos QlikView.
QlikView. QlikTech
QlikTech
QlikTech insta insta veementemente
insta veementemente
veementemente os
os clientesos clientes
clientes
a tirar aatirar
tirar
proveito proveito
proveito
desta destaaformação,
desta
formação, a fim de
fim de otimizar as otimizar as implantações
implantações do QlikViewdo
e
QlikView e omaximizar
maximizar o retopode
retorno sobre realizar com
investimento que o QlikView. urna sobre o investimento que
Diretrizes de Boas Práticas: Desenvolvimento
Diretrizes de gerenciamento de código e migração

Gestão código
A fim de fornecer uma visão geral de Gestão Código de boas práticas, é útil olhar para um estudo de caso fictício que
examina um processo de mudança aplicação QlikView para uma empresa. O nome da empresa fictícia é Acme Industries.

Relatório: Guia Request Alterar Acme Industries'

Mudando o processo QlikView App -Release


Esperamos que os usuários finais terão solicitações de melhoria e / ou relatórios de defeitos para a aplicação QlikView. Vamos

gerenciar tais solicitações de mudança utilizando procedimentos de gestão de mudança de software padrão Acme Industries,

sempre que possível.

Várias solicitações de mudança pode ser implementada e enrolado em uma nova versão. A frequência de novos lançamentos ainda não

está determinada, mas uma vez que a aplicação está estabilizado, novos lançamentos são mais propensos a ser um evento trimestral ou

mensal, em vez de um evento diário.

Abrindo uma Solicitação de Mudança

A solicitação de mudança deve primeiro ser celebrado Acme Industries ferramenta de solicitação de mudança ou sistema de rastreamento de

bugs. A solicitação de mudança deve então ser priorizados pelo Gerente QlikView Projeto. À medida que mais solicitações de mudança entrar,

o gerente do projeto atribui os pedidos de maior variação prioridade a um desenvolvedor QlikView para a implementação.

Implementando uma Solicitação de Mudança

1. Saída de Arquivo QVW (s)

O desenvolvedor QlikView em seguida, verifica o arquivo QVW apropriado (s) a partir de ferramenta de controle de revisão da Acme Industry.

( Alternativamente, em vez de verificar o arquivo (s) QVW, os arquivos de script e layout podem ser exportados a partir do QVW (s) via

QlikView Developer para a gestão pela ferramenta preferencial de controle de revisão).


Diretrizes de Boas Práticas: Desenvolvimento

2. Alterar o aplicativo QlikView

O desenvolvedor do aplicativo QlikView agora se estende e / ou reparos a aplicação QlikView, usando as habilidades do Designer

QlikView e cursos para desenvolvedores. A aplicação QlikView pode ser modificado e ampliado localmente no desktop de um

desenvolvedor, ou remotamente no servidor de teste. A tabela seguinte compara as duas abordagens diferentes:

desenvolvimento Desktop Software Software de Servidor Notas


Local Obrigatório Requerido

Localmente no desktop QlikView desktop n/D desenvolvimento baseado em

servidor é útil para volumes de


Remotamente no Test Windows Client Remote QlikView desktop
dados maiores.
Server Desktop Connection

Normalmente, é uma boa prática para usar hosts separados para teste e Produção propósitos para grandes implantações. No entanto, uma

máquina pode servir em ambos os papéis se necessário, especialmente em implantações menores. No caso de uma máquina que serve em

ambos os papéis, teste e Produção arquivos podem ser armazenados em árvores de pastas separadas, e o administrador de sistemas pode

controlar o acesso ao

Produção árvore de diretórios usando permissões de arquivo NTFS do Windows. O restante deste documento discute o uso dos

exércitos de teste e produção separados; no entanto, os mesmos conceitos podem ser aplicados à utilização diretório de teste e

produção separada árvores numa única máquina.

3. Implantação de teste no Test Server

O desenvolvedor QlikView agora copia o arquivo QVW atualizado para pasta do servidor QlikView do servidor de teste e

valida que o aplicativo funciona como desejado quando acessado pelo tipo de cliente preferencial (ex do QlikView

Internet Explorer plug-in).

4. Recarregar teste no servidor de produção

O desenvolvedor QlikView trabalha com o administrador do servidor para validar que o arquivo QVW atualizado pode recarregar dados

com êxito no servidor de produção. Este teste é especialmente crítico se o desenvolvedor QlikView adicionou chamadas para quaisquer

novas fontes de dados no arquivo QVW atualizado, como as fontes de dados podem não estar disponíveis a partir do ambiente de

produção.
Diretrizes de Boas Práticas: Desenvolvimento
5. Redução de dados antes de check-in

No desenvolvimento de software, o objetivo de um sistema de controle de revisão é controlar mudanças nos artefatos de aplicativos de

software si mesmos, e não para os dados processados ​pela aplicação. Como tal, antes de verificar a nova versão do arquivo (s) QVW,

todos os dados devem ser removidos dos arquivos QVW, através da área de trabalho QlikView Arquivo> Reduzir Data> Remover todos os

valores comando. Isso irá reduzir o tamanho do arquivo QVW de cerca de 2 MB até 200 kb. Nós não estamos preocupados com o check-in

este arquivo sem dados, como o arquivo QVW será re-preenchidos com dados depois de ser implantado no servidor de produção, quando o

seu script de carga é executado.

Este passo só é relevante se Acme é realizar o controle de revisão sobre o arquivo (s) QVW; não é relevante quando se utiliza a

abordagem alternativa de realizar o controle de revisão sobre os arquivos de script e layout.

6. Check-in e Implantação

O desenvolvedor deve verificar no, arquivo QVW reduzida atualizado para o sistema de controle de revisão, e depois alertar o

administrador do sistema para a disponibilidade do arquivo atualizado. O administrador do sistema, em seguida, copia o arquivo (s)

QVW atualizado para a Produção diretório no servidor.

Se Acme está usando a abordagem alternativa de realizar o controle de revisão sobre os arquivos de layout e script (em vez do

QVW), em seguida, o desenvolvedor deve verificar nos arquivos de script e layout modificado, eo administrador do sistema, então,

importar os arquivos de script e layout atualizado nos arquivos QVW produção.

Fechando a Solicitação de Mudança

A solicitação de mudança deve ser marcado como fechado na ferramenta de solicitação de alteração ou erro sistema de rastreamento Acme

Industries.

Isto conclui o relatório típico na implementação de uma solução de controle de mudanças para o QlikView.
Diretrizes de Boas Práticas: Desenvolvimento
Diretrizes de migração

Esta seção descreve o caminho de migração de alterações em documentos de produção do QlikView do desenvolvedor e
utilizadores profissionais em produção. Isto terá de ser um esforço coordenado entre várias pessoas para fazer o trabalho
processo corretamente.

Segue-se uma discussão sobre os vários papéis que são usados ​nesta seção:

Roles

Função responsabilidades
Administrador Editora empregos noturnos (Criar, modificar, manter)

Atuando como um gateway para mudanças (controle de origem)

Integrando Novas mudanças de / utilizadores profissionais


desenvolvedores em produção
Desenvolvedor Isso geralmente é uma pessoa que desenvolve o modelo de dados e
trabalha com os sistemas de origem

Professional Usuário Isso geralmente é uma pessoa que cria / modifica o gráficos
/ layout reportsand

QA Usuário Este é o usuário final que ajuda a definir os requisitos de


relatórios e são a validação final que os relatórios estão
corretos. Este poderia ser o desenvolvedor ou uma pessoa
fora da equipe de desenvolvimento.
Diretrizes de Boas Práticas: Desenvolvimento
definições
Documento: Um arquivo QlikView QVW. AKA 'QVW'

Candidato produção: Um documento que tem todas as últimas alterações aplicadas a ele. Isso geralmente é um documento que
está nas mãos do administrador. É a responsabilidade aos administradores manter o controle de qual documento é o candidato
produção e deve haver apenas um candidato produção por documento a qualquer momento.

Definições de mudanças
Alterações iria incluir qualquer coisa que requer um desenvolvedor para abrir o documento, editá-lo e salvar as alterações. Isso inclui
alterações no layout (mover as coisas), alterando as cores, adicionando / modificando as propriedades em qualquer coisa (lista caixas,
tabelas, gráficos, etc.), mudanças em grupos de script, de ciclo e de perfuração, código de macro.

Esta referência de mudanças não incluem a actualização dos dados de todas as noites através de um processo automatizado (tal como

editor)

visão global

O processo básico é que um desenvolvedor irá fazer algumas alterações no layout do documento e deseja mesclar essas alterações
em produção. Uma vez que o desenvolvedor tenha verificado que as alterações estão corretas, eles vão notificar o administrador. O
administrador irá integrar as alterações do desenvolvedor (e, possivelmente, vários desenvolvedores) e colocar o documento em QA
para o desenvolvedor para revisão.

Se o usuário desenvolvedor e final verificou o documento estiver correta, então o administrador pode mover as alterações
na produção.
Se um grande número de mudanças estão ocorrendo, o administrador pode (em coordenação com as todas as partes envolvidas) desenvolver

uma agenda de lançamento e solte muitas mudanças ao mesmo tempo.

Processo de Comunicação do Usuário Final

Um processo terá de ser desenvolvido para notificar os usuários usuários finais que novos recursos estão disponíveis em um aplicativo
específico. Em outras palavras, este deve ser um processo para notificar os usuários finais que novos recursos estão disponíveis uma vez
que o desenvolvimento tenha sido concluído eo aplicativo é promovido a produção. Isso pode variar dependendo do tamanho da mudança.
Se é um novo relatório simples, então nenhuma notificação pode ser necessária. Se é uma mudança para um relatório que é usado o tempo
todo por muitas pessoas, então você pode querer notificar todos com e-mail ou ter uma sessão de treinamento com as mudanças.

Estratégia de liberação

Se vai haver várias mudanças de vários desenvolvedores de entrar em produção no mesmo documento, em seguida, uma
estratégia de liberação devem ser desenvolvidos para coordenar as alterações para minimizar o número de promoções para
produção e sobrecarga adicional de promover novos recursos para produção (QA, tempo administrativo mudanças de fusão,
possível chance para erros durante a promoção, etc)
Diretrizes de Boas Práticas: Desenvolvimento
Detalhes para desenvolvedores

Estes detalhes são os passos gerais cada desenvolvedor seria necessário para desenvolver novas mudanças e tê-los adicionado à
produção.

Uma vez que um desenvolvedor recebe um pedido para desenvolver uma mudança a um documento de produção, existem 2 maneiras de proceder:

1. Se houver um grande número de alterações que afetam um grande número de áreas do documento

a) O desenvolvedor ou usuário profissional entraria em contato com o administrador e solicite a versão mais atual do
documento ser dada ao desenvolvedor para acesso exclusivo.
b) O desenvolvedor faria as mudanças por
Eu. Copiar o documento que o administrador dá-lhe para o seu diretório de trabalho

ii. Fazendo as alterações no documento


iii. Copiando o novo documento para o e: \ Directory Desenvolvimento QlikView Server usando o nome apropriado (Veja o

“Processes.doc Desenvolvimento”) para permitir que os usuários de controle de qualidade para validar as alterações.

iv. Quando os usuários QA validaram as mudanças, devolver o documento para o administrador com

Eu. 1. A lista geral de mudanças. (Uma lista abrangente de mudanças não seria necessário uma
vez que o administrador levaria o documento a partir do desenvolvedor, validar algumas
normas (ver detalhes de seção de administração deste documento) e colocar o documento
diretamente na produção.)

ii. 2. Uma lista de usuários GQ que deve QA o documento uma vez que é colocado no diretório
QA. O administrador irá conceder acesso ao documento para a lista específica de usuários
de QA.
v. O administrador iria colocar o documento em produção depois de alguns testes básicos que o trabalho de
aplicação corretamente no ambiente de produção e que os padrões adequados estão sendo atendidas
(roteiro não está quebrado, todos os relatórios funcionam corretamente)

2. Se existem pequenas alterações, ou as alterações são limitadas a um subconjunto específico do documento

uma. O desenvolvedor deve copiar uma versão do documento a partir do “E: \ QlikView Cópia da Produção” para seu
diretório de trabalho e desenvolver mudanças. É muito importante manter uma lista de todas as mudanças que
foram feitas.
b. O desenvolvedor deve copiar o documento para o diretório “e: \ Directory QlikView Development Server” (no servidor de
desenvolvimento) usando o nome apropriado (Veja o “Processes.doc Desenvolvimento”) e permitir que os usuários de
controle de qualidade para validar as alterações.

c. Neste ponto, o usuário QA seria validar as alterações e o desenvolvedor iria notificar o


administrador de
Diretrizes de Boas Práticas: Desenvolvimento
Eu. Quando o documento está localizado
ii. O nome do documento (nome exato do arquivo)
iii. Altera o administrador precisaria se fundem em produção
iv. Que os usuários devem ver o documento uma vez que é colocado em QA

d. O administrador iria mesclar as alterações de alterações de um ou mais de desenvolvedor em um acúmulo de


produção; coloque a construir no “E: \ Directory QlikView QA Servidor” para QA pelos usuários desenvolvedores e
QA e notificar os desenvolvedores e usuários de QA do nome do documento e que ele está pronto para QA (O nome
poderia ser diferente do que o que a desenvolvedor tinha originalmente uma vez que o administrador pode ter se
fundiram em alterações de vários desenvolvedores)

e. Uma vez que o desenvolvedor (e opcionalmente o usuário QA) teve tempo para controle de qualidade do

documento, o administrador iria promovê-lo em produção

Detalhes para administrador


Seu papel vai abranger mantendo o ambiente de produção organizado e também para mesclar as novas alterações em produção. Essas
mudanças incluem alterações ao roteiro, relatórios e trabalhos do Publisher. Para desempenhar esse papel, você precisará ter um aperto
firme em todos os produtos QlikView desde que você será o gerenciamento do fluxo de dados através de todos eles.

Princípios gerais para todas as tarefas

• práticas tradicionais SDLC, deverá aplicar o processo de desenvolvimento passa por um Desenvolvimento - QA -
seqüência de Produção de promover alterações de produção. Desde QlikView não tem recursos para mostrar a
diferença entre 2 documentos diferentes, comparando mudanças e promover mudanças de produção é um
processo manual.

• Ao mesclar em novas mudanças de desenvolvedores que você precisa para ter certeza de manter o controle de qual documento tem
todas as suas alterações mais recentes e mesclar as alterações do desenvolvedor para esse documento mais recente.

• Você vai precisar para evitar ter várias versões do mesmo documento em QA, ao mesmo tempo. A razão para isso é que, se
você tiver várias versões do mesmo documento no QA, em seguida, quando você migra as alterações para a produção terá
de voltar a mesclar as alterações que significa que você precisa para mudar as coisas que significa QA adicional (desde que
as mudanças poderiam afetar outras modificações)

Responsabilidades de admin

• Coordenar as alterações em produção


• problemas do sistema Fix

• Operar com os princípios bom software de design (backups, verificações de qualidade, etc.)

• Impor padrões de codificação / práticas


Diretrizes de Boas Práticas: Desenvolvimento
• desenvolvedores treinador como para projetar diretores para promover um melhor sistema

• Monitoramento / ajuste do servidor QlikView

• Monitorar alterações em grupos de segurança

• Gerir CALs de Usuário


• Levantando questões com navegação (embora pudessem ser anulada se houver uma necessidade de negócio)

Responsabilidades de administração não incluem

• Validando os números / dados de precisão


• Gestão dos projectos QlikView
• Decidir o que parece "bom

Mesclando em novos relatórios (alterações de layout):

Quando um desenvolvedor avisa de mudanças que deve fornecê-lo com


• A localização e nome do documento que tem as mudanças para que você promova a produção

• A lista das mudanças. Essas mudanças poderiam incluir


o objetos de layout (gráficos, relatórios, caixas de listagem, etc)

o Variáveis ​que os relatórios fazem referência


o objetos de ciclo e broca
• Uma lista de pessoas que irão controle de qualidade do documento

O processo é ter uma versão candidata a produção do documento que você vai trabalhar e o documento
recém-reforçada que o desenvolvedor deu-lhe (possivelmente vários desenvolvedores)

• O administrador iria percorrer a lista de mudanças e mover as alterações para os novos candidatos produção Muitas
vezes isso pode ser um simples copiar / passado do novo objeto para o candidato produção e excluir o objeto de idade.

• Depois de migrar as alterações ao novo documento terá de validar que parece correta.

• Verifique todos os campos - Em tabelas e gráficos, você vai querer verificar todos os campos para se certificar de que eles existem no

candidato produção. Todos os campos que não existem geralmente ficam vermelhos, ou ter um X vermelho ao lado deles nas

propriedades do gráfico (se é um gráfico).

• Verifique todas as expressões (expressões em todos os lugares, não apenas no separador expressão)

• Verifique se elas são válidas

• Verifique se eles são eficientes (alterações do modelo de dados adicionais podem ser necessárias se as expressões poderia
ser feito para ser mais eficiente)

• Broca / grupos ciclo - Não há maneira de copiar / colar estes, eles terão de ser reconstruídos. Também olhar para a ordem de

classificação nos grupos, a ordem de classificação pode ser importante para o desenvolvedor

• Possivelmente qualquer outra arquitectura de apoio, tais como mesas Island, novos campos, etc.
Diretrizes de Boas Práticas: Desenvolvimento

Mesclando in new Script:

• Identificar o novo script e validar o script vai trabalhar com os padrões de codificação que foram adoptadas.

• Certifique-se de que ele executa corretamente.

• Mesclar o novo script no script existente. Pode ser possível mesclar o novo script com algum script existente para
melhorar a eficiência em vez de constantemente adicionando novo script para o documento

Modificações Publisher:

Os usuários não serão dando-lhe itens editor reais para entrar em produção. Em vez disso, as mudanças editor
virá com os requisitos de outras melhorias.

Por exemplo, se uma nova solicitação é feita para recarregar os dados em um novo horário, que seria uma mudança
publisher que precisam ser executadas. Se um novo módulo de script foi adicionado que utilizou documentos adicionais,
editor teria que ser ajustado para acomodar os documentos adicionais.

mudanças Editora caberá a seu critério sobre o que precisa ser realizado eo que tempo que eles precisam para ser
realizado. Há um par de orientações que você vai querer seguir no entanto:

• Não 'Distribuir' grandes documentos ao recurso QlikView Server durante períodos em que os usuários estão utilizando o
sistema. Fazendo isso vai retardar os servidores QlikView dramaticamente pequenos documentos (que levam 30 segundos ou
menos) são muito bem.

• Ao validar as novas alterações do modelo de dados (mudanças no roteiro e tal), é melhor para desenvolver os trabalhos
editor e deixá-los executar a partir publisher para validar que o movimento de dados está ocorrendo como deveria. Sem
isso, você não vai saber se editora tem as permissões adequadas e tal definidos para executar os trabalhos em seu
ambiente de produção real
Diretrizes de Boas Práticas: Desenvolvimento
Processo de desenvolvimento
Diretrizes de Boas Práticas: Desenvolvimento
padrões de nomenclatura

Editor
• É geralmente considerado uma má prática para colocar o tempo de uma ação (IE 'Diariamente', 'noite') no nome da tarefa, uma vez que a

tarefa pode ser agendada por muitos empregos diferentes, que todos podem ser programadas de forma diferente

• É geralmente considerada uma boa prática para colocar o tempo de uma ação em nome de um Job.

• Se você tiver um ambiente de QA mista / Dev, você vai querer para prefixar qualquer coisa (exceto para um .qvw
indivíduo) com qualquer um DEV_ ou QA_ Produção gostaria têm um prefixo Prod_ ou sem prefixo (sua escolha, desde
que todo mundo segue a mesmos padrões)
• Sempre usar arquivos de log para qualquer aplicação promovido a produção. Sem arquivos de log, o editor não pode
capturar os detalhes do sucesso / insucesso da execução de uma aplicação

• Use nomes UNC, ou tarefas automatizadas pode não ser capaz de referenciar os caminhos

Abbr. Abbr. Tipo Significado

Todos Meio Ambiente Aplicável a todos os ambientes


DEV Meio Ambiente Ambiente de desenvolvimento
PRD Meio Ambiente Ambiente de produção
TST Meio Ambiente Ambiente de teste
abril Itens da editora Editor Resource Access Point
TRABALHO Itens da editora Publisher Job
Editor Resource Fonte pasta de documentos
SDF Itens da editora
TSK Itens da editora tarefa Publisher
DSR Itens da editora Resource Directory Service

Scripting e layout
Come-se com um padrão de nomenclatura:

• Use nomes de negócios para os campos de dados, por exemplo, Cliente Nbr em vez de CustNo

• Todas as abreviaturas são um tipo padrão. Obter uma lista de abreviaturas e usá-lo (IE use sempre desconto para Descrição,
conforme especificado na lista de abreviaturas)

• Utilize um Prefixo

- variáveis = Começa com um “v” por exemplo, vCurrentYear

- campos-chave = Começa com um “%” por exemplo,% CustomerKey

- campos de flag = Começa com um “_” por exemplo, _YTDFlag

- / Grupo Ciclo = começa com um “<” por exemplo, <ProductCycle

- Drilldown Group = começa com um “>” por exemplo,> GeographyDrilldown

- Key Field Separator = separados por “_” por exemplo, Company & '_' & Nbr como

Chave

- Temp campos / quadros = termina com "_tmp” por exemplo, Daily_Trans_tmp


Diretrizes de Boas Práticas: Desenvolvimento
estruturas de pastas

visão global
Pastas para armazenar seus arquivos do QlikView de produção também são importantes. A estrutura das suas pastas devem permitir que os

desenvolvedores para localizar e ler os arquivos para os quais eles têm acesso facilmente. Abaixo estão algumas estratégias para a localização dos

arquivos do QlikView.

Departamento Breakdown
Esta estratégia é separar os arquivos em pastas para áreas específicas, nas pastas do ambiente, incluindo uma pasta comum para armazenar
todos os arquivos que são candidatos para ser usado em áreas temáticas. Esta é uma boa estratégia para implantações estabelecidos que não
têm muitos novos projetos de desenvolvimento em execução em um determinado momento. Pode ser menos desejável se muitos novos projetos
de desenvolvimento estão em execução, uma vez que não são pastas específicas do projeto desta estratégia. Isso significa que novos arquivos
de desenvolvimento que podem ou não podem estar em produção estará presente nas pastas Dev / Teste / QA misturados com arquivos de
produção estabelecidas.
Diretrizes:
Diretrizes de Boas Práticas: Desenvolvimento
Desenvolvimento
Breakdown projeto
Esta estratégia é comum, onde vários projetos de desenvolvimento estão sendo executados simultaneamente. isto

abriga
abriga os arquivosespecíficos
os arquivos
arquivos específicos
específicos para
para
para umum
um projeto
projeto
projeto dentro
dentro
dentro deuma
dede
umauma pasta
pasta
pasta chamada
chamada
chamada opara
parapara oo projeto.
projeto.
projeto. Isto
Isto Isto
torna torna
torna
mais mais
mais
fácil fácil
fácil
para para desenvolvedores
desenvolvedores e e
administradores
administradores aaidentificar
identificar rapidamente
rapidamente novos
novos arquivos
arquivos ated para
rel relacionados com um projecto e isolá-los comoum projecto
teste e isolar
e promoção código. Uma
-los paraarquivos
vez que o teste de
e promoção código.
torná-lo para Umaeles
Produção vezestão
que arquivos torná-lo
de torná-lo
todos alojados para
para
na pasta Produção
Produção
“Shared” eles
eles
já que estão
nãoestão todos alojados
todos
há projetos alojados
de na pasta
na pasta da
desenvolvimento
“Shared” produção.
produção. já que não há projetos de desenvolvimento da produção.

Breakdown aplicação Esta estratégia é


comum
Esta onde é comum onde existem grandes
estratégia aplicações
grandes QlikView
aplicativos que
QlikView não muito
existentes quesenão
sobrepõem
fazer muitouns aos outros em uso de arquivos.
se sobrepõem

Separando
uns os arquivos
aos outros porarquivos.
em uso de aplicação
arquivos. torna maisos
Separando
Separando osfácil identificar
arquivos
arquivos por arquivos torna
por aplicação
aplicação necessários
tornamais para
maisfácil
fácil melhorias
identificar
identificar ou adições
arquivos
arquivos a um aplicativo.
necessários
necessários paramelhorias
para melhorias
Note-se
ou quea ainda
adições há uma casa
um aplicativo. dobra
Note-se
Note-se quecompartilhada
que ainda há
ainda umatodos
há uma os arquivos
pastadobra
casa queque
compartilhada sãovai
compartilhada comuns
os a
abrigar
todos mais de
todos
arquivos uma
osque das
arquivos
são aplicações.
que são
comuns Com
comuns
a mais ao mais
de umatempo,
dasde
esta
uma abordagem
aplicações. Com pode
das aplicações. ser esta
Com
o tempo, menos desejável
o tempo,
abordagem se cada
esta abordagem
pode vez
podemais
ser menosser comunsdesejável
menos
desejável arquivos
se são
se
cada vez usados.
cada
mais vez maisarquivos
comuns comunssão
arquivos são usados.
usados.

Composição mista
mistura aa Breakdown
Esta estratégia mistura Breakdown Departamento
Departamentotanto
tantocom
comooBreakdown
Pr Composição
Projeto ou oject
o Breakdown ou o
Aplicação. A imagem
Breakdown
Breakdown aplicação.
aplicação.
acima mostra AA imagem
a combinação imagem acimaDepartamento
acima
/ Aplicação mostraaacombinação
mostra combinação / Aplicação
para fins/ de
Aplicação Departamento
Departamento
demonstração. para
para fins
fins
Esta abordagem dede demonstração.
demonstração.
é comum Esta
para maiores
Esta abordagem
abordagem
implantações é comum
é QlikView
comum para para maiores
ondemaiores
vários implantações
implantações
departamentos estão QlikView
QlikView ondeaplicações
onde vários
a desenvolver departamentos estão desenvolvendo
que podem aplicações
não se sobrepõem uns aos
que muito.
outros pode não se sobrepõem uns aos outros grandemente.

É importante notarque
importante notar
notar quequalquer
que qualquerabordagem
qualquer abordagemacima
abordagem acima
acima ou
ou
ou combinação
combinação
combinação de
de
de abordagens
abordagens
abordagens iráiráirá funcionar,
funcionar,
funcionar, mas
mas
mas aa consistência
consistência
a consistência aé chave
a
é aé chave para a
chaveaestratégia.
pasta
para para
pastaaestratégia.
pasta estratégia.
Você pode, Vocêé mudar
Você épode,
claro, pode, éestratégias
claro,estratégias
claro, mudar mudar estratégias
como como do
a implantação
como o seu a implantação do QlikView
QlikView cresce, cresce, mas
mas permanecem re, a fim e
consistentes
de manter
vigilante o controle
dentro e
a estratégia que você está usando, a fim de manter o controle e governança de gerenciamento de código
a estratégia que você e
está usando

implantação. governança de gerenciamento de código e implantação.

Segurança pasta
Este éé um
Este umexemplo
exemplode
decomo
comoproteger
proteger seus
seus
seus arquivos
arquivos
arquivos QlikView
QlikView
QlikView Fonte.
Fonte.
Fonte. Há muitas
Há muitas
Há muitas maneiras
maneiras
maneiras de fazer
de fazer
de fazer isso,
isso,mas
isso, mas como
mascomo
como uma
umaboa
uma boa boa prática
prática
prática QlikTech
QlikTech
QlikTech
recomendarecomenda que você uma
que você incorporar incorporar umade
estratégia
estratégia estratégia
de segurança
segurançadeque
segurança
que queàà sua
corresponde
corresponde sua estratégia
estratégia de
de desenvolvimento.
desenvolvimento.Isso
Issopermitirá
permitiráque
quevocê
você
dev pessoas
isolar arquivos que não devem acessá-los,
de desenvolvimento de pessoas enquanto ainda permitindo-lhes
que não devem acessoainda
acessá-los, enquanto a arquivos arquivos
compartilhados
permitindo-lhes acessoolvimento
que de a re
permitem
a arquivos
compartilhados que permitem a reutilização e consistência.

Use grupos diferentes para combinar com seu


a sua
arquivo
estrutura
de dados
de arquivo
de origem
de dados de

origem.

A) grupo Department1 /grupo


1 Desenvolvimento
Desenvolvimento
B) grupo Department2 /Desenvolvimento
2 Desenvolvimento
grupo 1 2
de dados
C) Partilhada de dados da empresa (Shared_Folders)
(Shared_Folders)

tem
D) QlikView Administrador tem acesso acesso
a todos os adocumentos
todos os grupos e
distribuídos
E))conta
Contadedeserviço
serviçopara
parao oserviço
serviçoQlikView,
QlikView,são
sãoo membros
grupo D da

Este serviço deve ter acesso de leitura paraacesso


o sistema de de dados,
a bases
sistema
arquivo e ActiveeDirectory
Active Directory
Diretrizes de Boas Práticas: Desenvolvimento
Teste e Certificação

Testes para executar

1. Recarregar Testing
a) Atualizar localmente

b) Recarregar a partir QVS (manualmente)

c) Recarregar automatizado de uma tarefa Editora isolado

Teste 2. Publisher
a) As tarefas de teste individualmente para recarga, distribuição, estados

b) construir dependências (se necessário) e teste individualmente

3. Teste de usuário (UI)


a) testes de utilizador individual

b) bookmarks privados
c) As exportações (todos os formatos)

d) teste utilizador concomitante (não estruturados)


e) Ensaio de utilizador concomitante (teste de função simultânea)
f) o teste de simultaneidade (várias aplicações)

4. Teste do usuário (Colaboração)


a) Testando novos objetos de colaboração
b) Teste de objetos compartilhados de colaboração

c) Marcadores do Servidor

Teste 5. Desempenho
testes simultâneos de 10 + usuários em QVW

6. Teste de Regressão
Se este for um acessório para uma QVW, realizar um teste de regressão utilizando os processos de ensaio de
implantação inicial do QVW

Teste 7. Ciclo
Executar 4-6 diárias recarrega ciclo completo para atualizar a QVW de fonte para acabar com interface de usuário

ambientes

uma. único ambiente - testes locais

Esta abordagem é usado quando um cliente tem apenas um servidor (PROD) e, como tal, precisa localmente código de

teste em máquinas desenvolvedor até que o código está pronto para produção. Isso pode ser feito com o teste de

unidade local sobre os desenvolvedores


Diretrizes de Boas Práticas: Desenvolvimento
máquinas, em seguida, uma versão limitada disponibilidade do QVW pode ser colocado em PROD para teste de
aceitação. Uma vez que a versão do QVW passou no teste do que pode ser disponibilizado como a versão PROD.

b. ambiente 2-Server - promoção

Esta abordagem envolve a execução de todos os testes no servidor / Teste Dev e, em seguida, uma vez aprovada, o código

é promovido a PROD. O teste de unidade ainda pode ser executada localmente pelos desenvolvedores, mas um teste

oficial de aceitação deve ser realizada no servidor / Teste Dev uma vez que o desenvolvedor tenha concluído o teste de

unidade.

c. ambiente 3-Server - promoção

Este é basicamente o mesmo que a abordagem anterior, excepto que DEV, TEST e PROD são utilizados. DEV é
usado pela primeira vez para o teste de unidade. Então teste é utilizado para o teste de aceitação, e uma vez que
ele passa testa a QVW é promovido a PROD.

Teste de Usuário Final

1. Pessoal - Unstructured

Estes testes seriam realizados por usuários finais em sua conveniência, sem planos estruturados ou
orientações sobre o que e como eles iriam testar. usuários finais individuais são simplesmente concedido o
acesso ao ambiente de teste v9 e disse para testar qualquer coisa que eles gostariam.

2. Pessoal - Estruturado

Estes testes envolveria instruções sobre o que e como fazer o teste, mas eles não iria ditar quando testar
ou coordenar os testes entre grupos de usuários. Eles provavelmente teria direções indicando que QVWs
para testar e quais funções para testar em uma ordem específica. Os resultados seriam reunidos para
comparar entre os usuários que completaram os testes.

3. Group - Unstructured

Um grupo de usuários finais estão todos concedido acesso ao ambiente de teste v9 e testar simultaneamente por
um período de tempo. Isto pode ser realizado ao longo de uma série de blocos de tempo n horas ou dias, ou podia
ser uma janela de teste contínuo. Os usuários finais não são dadas orientações estruturadas sobre o que e como
fazer o teste, mas são simplesmente disse para testar tudo.
Diretrizes de Boas Práticas: Desenvolvimento
4. Grupo - Estruturado

Um grupo de usuários finais estão todos concedido acesso ao ambiente de teste v9 e testar simultaneamente por
um período de tempo. Isto pode ser realizado ao longo de uma série de blocos de tempo n horas ou dias, ou podia
ser uma janela de teste contínuo. Elas são dadas instruções específicas sobre o que e como fazer o teste. Eles
também são coordenadas (de preferência na mesma sala ou através de uma linha chamada de conferência), para
que possam realizar testes de simultaneidade para iniciar simultaneamente funções ou acessar documentos. Os
resultados seriam reunidos para comparar com testes similares realizados no ambiente 8.5 como um controle.

Adoção de teste
Pode ser difícil de obter acesso a tempo dos usuários finais e esforço para testes. Algumas dessas abordagens
pode ajudar a promover testes e garantir bons resultados.

1. Coordenar janelas de teste para usuários com antecedência. Permita que os usuários finais sabem que você terá “janelas
de teste” onde o ambiente será monitorado e você estará disponível para ajudar com quaisquer dúvidas ou
necessidades. Isso ajuda a garantir que o seu tempo não será desperdiçado e eles não vão estar à espera de ajuda ou
orientação, se necessário.

2. Ter um prêmio para o usuário final ou grupo que descobre a maior quantidade de bugs com documentos da
nova versão. Este é um grande motivador para os usuários finais e vai garantir que eles enfatizam testar os
QVW do de forma completa.

3. Co-localizar usuários para testes. Encontrar uma grande sala de conferências e têm usuários finais chegar a esse espaço para o

teste. laboratórios de treinamento funcionar bem se os usuários não podem levar laptops.

4. ter usuários coordenado por telefone durante o teste. Possui uma linha de conferência aberta disponível durante todas as
janelas de teste para que os usuários finais podem conversar uns com os outros, pode fazer perguntas, e pode tomar a
direcção para eventos de testes simultâneos.

5. Dê aos usuários uma lista de verificação de documentos de teste ou funções para testar. Às vezes, os usuários não podem se

lembrar de todos os recursos disponíveis para eles de dentro de um QVW. Dê-lhes uma lista de verificação que inclui

marcadores, relatórios, exportações, condicionalmente objetos visíveis, colaboração, etc ...

6. Coordenar janelas de teste para usuários com antecedência. Permita que os usuários finais sabem que você terá “janelas
de teste” onde o ambiente será monitorado e você estará disponível para ajudar com quaisquer dúvidas ou
necessidades. Isso ajuda a garantir que o seu tempo não será desperdiçado e eles não vão estar à espera de ajuda ou
orientação, se necessário.
Diretrizes de Boas Práticas: Desenvolvimento
7. Ter um prêmio para o usuário final ou grupo que descobre a maior quantidade de bugs com documentos da
nova versão. Este é um grande motivador para os usuários finais e vai garantir que eles enfatizam testar os
QVW do de forma completa.

8. Co-localizar os utilizadores para os testes. Encontrar uma grande sala de conferências e têm usuários finais chegar a esse espaço para

o teste. laboratórios de treinamento funcionar bem se os usuários não podem levar laptops.

9. Ter usuários coordenado por telefone durante o teste. Possui uma linha de conferência aberta disponível durante todas as
janelas de teste para que os usuários finais podem conversar uns com os outros, pode fazer perguntas, e pode tomar a
direcção para eventos de testes simultâneos.

10. Dar aos usuários uma lista de verificação de documentos de teste ou funções para testar. Às vezes, os usuários não podem se

lembrar de todos os recursos disponíveis para eles de dentro de um QVW. Dê-lhes uma lista de verificação que inclui

marcadores, relatórios, exportações, condicionalmente objetos visíveis, colaboração, etc ...

Há muitas maneiras de testar o código em QlikView. Os dois mais importantes fatores de sucesso em testes eficazes
têm sido:
1. Planejamento.

Ter um plano para o teste que lhe permite dividir as responsabilidades do QlikView e testá-los individualmente
(desenvolvimento, recarregando, publicação, segurança, uso, monitoramento, solução de problemas, etc ...).
Então, trazer essas responsabilidades juntos e ciclo de testá-los sempre que possível. Documentar o plano de
teste e repita os passos que podem ser repetidos.

2. Compromisso de tempo. Garantir o compromisso tempo sério de desenvolvedores, administradores e usuários finais de
QlikView. Um ponto de referência comum é que o teste deve incluir pelo menos 10% do tempo de desenvolvimento
para uma QVW. Isto significa que se um QVW levou 160 horas para desenvolvê-lo deve obter 16 horas de tempo de
teste antes de sua promoção para Produção. Isto poderia ser de 16 para os utilizadores de uma hora cada um ou
qualquer combinação de utilizadores e que o total de horas a 16 (ou 10% do tempo de desenvolvimento). Fazer essas
horas contam dando alguns estruturado e algum tempo livre para os usuários finais, bem como garantir que eles
tenham alguma motivação para descobrir problemas.
Diretrizes de Boas Práticas: Desenvolvimento
Os fluxos de trabalho

QlikTech recomenda a criação de um documento de Desenvolvimento de fluxo de trabalho que diagramas as etapas envolvidas na
promoção código em todos os ambientes do QlikView. O diagrama a seguir mostra um exemplo de um fluxo de trabalho de
desenvolvimento:

Certificação

Muitas empresas beneficiar da velocidade e flexibilidade de desenvolvimento QlikView, mas também desejam manter um processo mais
rigoroso para algum desenvolvimento QlikView de aplicações muito importantes ou de alto perfil.
A fim de distinguir entre “ir mais rápido” aplicações e aplicações “high Rigor”
muitos clientes QlikView usa um processo de certificação.

Este processo serve como um pedágio para a obtenção de um aplicativo QlikView “certificado”. Certificação significa uma
aplicação passou por este processo e foi aprovado. Um ícone de “certificado” é então colocado na seção de título do aplicativo
para que os usuários e equipes de apoio saber quais
Diretrizes de Boas Práticas: Desenvolvimento
aplicações são certificados e quais não são. Isso permite que as equipes de colocar ênfase sobre este processo, por não
prestar o mesmo nível de suporte para aplicações não-certificadas.

O diagrama abaixo mostra o que uma reunião Certificação amostra pode parecer.
Diretrizes de Boas Práticas: Desenvolvimento

Solução de problemas e suporte


Tipos de apoio
Suporte a aplicações e ambientes QlikView pode ser feito de várias maneiras. Como prática, a QlikTech
recomenda que os níveis e serviços de apoio ser identificados para as seguintes áreas:

- Aplicações QlikView (QVWs)


- QlikView interface (apoio ao utilizador final)
- QlikView Server / Publisher
- QlikView Arquitetura de Dados (dados QVDs e QlikView, em geral)

Muitos clientes QlikView utiliza QVWs certificados para suporte a aplicativos de aplicativos altos importância. Isso pode ajudar
especialmente quando equipes de negócios estão criando seus próprios QVWs e sua equipe de suporte só é responsável por
apoiar as aplicações certificadas que tiveram a oportunidade de código / Interface / revisão de dados. Veja a seção chamada
Teste e Certificação neste documento para obter mais detalhes sobre o processo de certificação.

Equipes de Desenvolvimento QlikView


QlikView é uma ferramenta de BI extremamente flexível e facilmente adaptada. Como tal, as equipes de desenvolvimento pode organizar
em torno de vários modelos de apoio, administração, desenvolvimento, formação e gestão. Estes cenários ajudar discussões guia sobre
possíveis configurações para as funções do QlikView em um ambiente de desenvolvimento.

É recomendável que o cliente consultar os seus próprios padrões de TI para o desenvolvimento, pois podem conduzir esta decisão, ou
pelo menos diminuir as escolhas permitidos. QlikTech não promove expressamente um desses cenários sobre os outros, mas pede que
os clientes determinar por si mesmos qual dessas configurações podem funcionar melhor, dada a natureza do desenvolvimento QlikView
e os conjuntos de habilidades que existem.
Diretrizes de Boas Práticas: Desenvolvimento
Em um continuum de totalmente centralizado para totalmente descentralizado, a seguir estão 5 opções para estruturas de equipe
QlikView:

1) completamente centralizado

Equipe Central Distribuído Team (s)


Suporte de Infra-estrutura Usuários finais

QlikView administradores do QlikView


aplicação de suporte QlikView
Desenvolvedores QlikView Designers
Gerentes de Projeto

Nesta opção, os departamentos não precisa fornecer os desenvolvedores, pessoal de apoio e administradores para usar aplicativos QlikView.
Eles pedem novas aplicações e, em seguida, consumi-los juntamente com os serviços centrais do QlikView. Pontos fortes nesta abordagem são o
controle, compartilhamento conjunto de habilidades, consistência e governança, já que todos os serviços são contidos para uma equipe.
Diretrizes de Boas Práticas: Desenvolvimento

2) Co-Desenvolvimento (v1)
Equipe Central Distribuído Team (s)
Suporte de Infra-estrutura Usuários finais

Administradores QlikView QlikView Designers


Suporte QlikView Aplicação Gerentes de projeto
QlikView Developers

Nesta opção, o desenvolvimento empresarial é mantido como uma função central, permitindo a criação de scripts e modelagem de dados para

serem manipulados por especialistas desenvolvedores do QlikView e profissionais de dados. Departamentos são responsáveis ​por todo o

treinamento, MGMT projeto, design de aplicativos, testes e suporte.

Os pontos fortes desta abordagem são que o trabalho BI back-office ainda está centralizada, mas o design e gerenciamento de projetos são
feitas nas equipes de negócios, de modo que eles podem se mover em um ritmo mais rápido, parcialmente independente de recursos de TI.
Diretrizes de Boas Práticas: Desenvolvimento

3) Co-Desenvolvimento (v2)
Equipe Central Distribuído Team (s)
Suporte de Infra-estrutura Usuários finais

Administradores QlikView Suporte QlikView Aplicação


QlikView Developers QlikView Designers
Gerentes de Projeto

Nesta opção, o apoio foi transferido para os departamentos, mas Projeto Mgmt é retido na equipe central para melhor permitir a
perícia e controle de projetos QlikView. Departamentos são responsáveis ​por todo o treinamento, design de aplicativos e suporte.
Pontos fortes desta abordagem são semelhantes ao modelo v1 Co-Desenvolvimento, com exceção do Application Support
QlikView agora também distribuído às equipes de negócios. Isso libera mais recursos de TI e coloca algumas responsabilidades
nas equipes distribuídas para fornecer apoio e treinamento para seus usuários finais.
Diretrizes de Boas Práticas: Desenvolvimento

4) Na maior parte descentralizada

Equipe Central Distribuído Team (s)


Suporte de Infra-estrutura Usuários finais

Administradores QlikView QlikView aplicação de suporte QlikView


Desenvolvedores QlikView Designers
Gerentes de Projeto

Nesta opção, os departamentos são responsáveis ​por todo o treinamento, MGMT projeto, design de aplicativos, scripts, desenvolvimento,
teste e suporte. A equipa Central ainda está fornecendo suporte de infra-estrutura e Administração QlikView. Isso permite que uma pequena
equipe de TI (geralmente menos de 2 pessoas) para administrar os direitos, as configurações do servidor e processamento em lote
(recargas). Pontos fortes desta abordagem são que a equipe centralizada (TI) é muito pequena.
Diretrizes de Boas Práticas: Desenvolvimento

5) totalmente descentralizado

Equipe Central Distribuído Team (s)


Suporte de Infra-estrutura Usuários Finais administradores do
QlikView QlikView aplicação de suporte
QlikView Desenvolvedores QlikView
Designers Gerentes de Projeto

Nesta opção, infra-estrutura ainda é mantida centralmente, mas todos os outros aspectos do desenvolvimento QlikView, testes,
suporte, treinamento um uso são distribuídos aos departamentos. Isso requer distribuídos equipes para ser treinado em todos os
aspectos do QlikView. A força desta opção é que não há recursos específicos do software necessário em uma equipe central. No
entanto, o desafio desta abordagem é que esses recursos específicos do software terá de estar presente em várias equipes
distribuídas, possivelmente sobrepostos.

Escolhendo uma estrutura de equipe de desenvolvimento é um passo importante em uma implantação corporativa do QlikView. Enquanto as

opções de Co-Desenvolvimento (# 2 e # 3) são os mais populares hoje em dia, a opção certa para cada cliente é aquele que corresponda às

suas necessidades e pontos fortes.


Diretrizes de Boas Práticas: Desenvolvimento
Centros QlikView de Excelência
QlikTech recomenda que os clientes execução implantações empresariais de QlikView considerar fortemente a formação de um Centro
de Excelência QlikView (ou Competency Center). Isso pode ser tão formal ou informal, conforme necessário, mas os serviços e
sinergias compartilhados em um centro de excelência permitir uma poupança e cobertura significativas para implantações corporativas.

QlikView Centro de Excelência (CoE)


Integrada por uma equipa mista de TI e de negócios usuários, QVCoE centraliza o conhecimento organizacional
e as melhores práticas para padronizar, implementar e gerenciar soluções de inteligência de negócios da
organização. Objetivos.

1. Desenvolver e compartilhar QlikView melhores práticas


Diretrizes de Boas Práticas: Desenvolvimento
2. Garantir a funcionalidade e operação de aplicações QlikView
3. Criar e implementar uma arquitetura de BI comum
4. Promover o uso de BI em toda a organização

Estrutura de organização
• Centralizada ou descentralizada, dependendo da cultura da empresa, conjuntos de habilidades das equipes envolvidas e

políticas

• Pode ser dedicado ou virtual


• Deve “pensar grande”, mas começar pequeno

• Permitir e planejar o crescimento do QlikView e companhia

benefícios

• Aumentar a credibilidade e confiança em informações corporativas


• RollOut o uso de BI para toda a empresa
• Acelerar o processo de tomada de decisão

• Otimizar recursos e reduzir custos


• inovação de processos de negócios através de visões de BI

• Continuamente evoluir aplicações QlikView BI para apoiar mudanças nos requisitos de negócios

Passos:

1. Patrocinador Executivo
2. mandato e objetivos COE
3. Financiamento

4. / linhas de informação estrutura organizacional


5. As áreas funcionais
6. papéis obrigatórios
7. COE KPIs

QlikTech pode fornecer materiais e modelos para ajudar a definir os serviços centralizados, KPIs, estruturas e práticas
recomendadas para criar um Centro de Excelência QlikView. Isso deve ser dimensionado e escopo para ser compatível com a
implantação do QlikView. Ou seja, ele pode começar pequeno e depois crescer como sua implantação QlikView cresce.
Diretrizes de Boas Práticas: Desenvolvimento
Treinamento

Uma estratégia de formação eficaz é essencial na criação, em curso atualizar ou implantação de qualquer aplicativo QlikView. Se você
está prestes a embarcar em um pequeno painel de vendas para um único gestor ou uma implementação mundial de milhares de
usuários, a estratégia de formação irá afectar grandemente o sucesso do projeto e como as pessoas utilizam o sistema para executar de
forma eficiente os seus empregos.

Os quatro áreas-chave e as suas ofertas de treinamento QlikView estão listados abaixo:

Este papel é responsável por desenvolver e documentar o documento QlikView de acordo com os
requisitos especificados.

Construir o seu primeiro QlikView

QlikView desenvolvedor 1

QlikView desenvolvedor 2
QlikView desenvolvedor 3
Definir Análise SAP
Connector

Esse papel centra-se em usabilidade e desenvolve a interface do usuário do documento QlikView de


acordo com os requisitos.

Construir o seu primeiro QlikView


QlikView Designer 1 QlikView
Designer 2

Este papel é responsável por hardware, sistemas operacionais e horários de trabalho.

Gestão do Sistema - Visão geral


Document Manager
Implementação empresarial

Este papel é um consumidor de aplicativos QlikView.

QlikView versão para usuários finais


Diretrizes de Boas Práticas: Desenvolvimento

A tabela a seguir mostra a formação potencial para vários papéis, incluindo aqueles listados acima:

QlikTech recomenda que os clientes participar Developer, Designer e formação Sistemas de administração para QlikView, a fim
de maximizar o retorno sobre o investimento em hardware e software QlikView. A profundidade de cursos a serem tomadas
dependerão das necessidades de sua implantação. Por favor, consulte o seu Serviços Regionais diretor da QlikTech ou seu
Executivo de Contas para discutir as opções.
Diretrizes de Boas Práticas: Desenvolvimento
resumo
QlikView é uma solução de BI muito rápido e flexível. Embora existam algumas peças móveis (QVDs e QVWs) para gerenciar o
desenvolvimento, existem infinitas combinações ou recursos, processos, ambientes, usos, plataformas de entrega e desenhos
que podem ser aplicadas. Com velocidade vem a necessidade de algum governança e consistência, e QlikView é nenhuma
exceção a isso.

Estas boas práticas não são totalmente abrangente. Uma boa estratégia para se manter atualizado com as melhores práticas é
aumentar o uso de documentação como esta com outras formas de entrada. Algumas delas são:

- comunidade on-line do QlikView com 10.000 s de usuários - QlikCommunity


- QlikTalks - encontros locais e regionais QlikView, onde as melhores práticas, novas funcionalidades, soluções
de vitrine e especialistas fornecedores são realçados.
- QlikTech Serviços Especializados - uma série de serviços são projetados para ajudar uma equipe QlikView chegar até a
velocidade muito rapidamente com as melhores práticas de desenvolvimento, arquitetura e administração. Contacte o
seu Executivo de Contas ou Serviços Director Regional para obter informações sobre os serviços disponíveis a partir
QlikTech e seus parceiros certificados em todo o mundo.

- grupos de desenvolvedores - grupos locais para um cliente ou organizados por vários clientes estão se formando em

muitas cidades. Verifique para ver se há um grupo de usuários local em sua cidade através QlikCommunity.

QlikTech insta veementemente os clientes a ter tempo para aprender as melhores práticas e técnicas que otimizam as
implantações e acelerar o tempo de entrega para o QlikView. Considere a implementação dessas melhores práticas e outros em
sua implantação. Eles são uma ótima maneira de acelerar os sucessos do QlikView ainda mais!