Relatórios com Metamodelos – Complemento

Semana passada eu mostrei como montar um relatatório a partir de um metamodelo. Hoje eu vou encerrar o assunto com mais algumas dicas.

Concepts

Um dos pilares de um bom relatório é a qualidade da apresentação, e nesta qualidade inclui-se a consistência, ou seja, dados do mesmo tipo possuem a mesma aparência, ou no mínimo possuem algum padrão.

Um relatório ordinário, construído a partir de um SQL, tem seus campos formatados livremente. Se por um lado isso é bom, já que dá espaço irrestrito para o autor do relatório passar sua mensagem, por outra é ruim, porque obriga esse mesmo autor a uma formatação tediosa, repetitiva. Fora o aborrecimento de repetir sempre a mesma coisa, ainda podemos acabar esquecendo ou mudando algum detalhe ao longo do tempo.

Um concept, ou conceito, é um padrão de formatação definido dentro do metamodelo e obedecido integralmente pelo PRD. Acesse esta página para obter mais informações sobre concepts.

Vamos fazer um exercício: criaremos um conceito de texto destacado e aplicaremos ao relatório do post anterior. Primeiro, abrimos o PME e carregamos o metamodelo do Beltrano OLTP. Em seguida acessamos o editor de conceitos (concept editor):

Acessando editor de conceitos no PME.
Acessando editor de conceitos no PME.

Nele clicamos sobre o conceito Base e depois clicamos no sinal de + no canto superior direito dessa seção. Uma janela se abrirá, pedindo o nome do conceito – eu eu chamei de Destaque. Como criamos o novo conceito a partir do Base, Destaque herdou as propriedades deste. Caso contrário, se tívéssemos criado um conceito na raiz, ele teria nascido vazio e precisaria receber todos os atributos prentendidos.

Com o conceito Destaque selecionado, clique no elo ao lado do atributo Color of Text. Isso quebra a herança e nos permite redefinir aquele atributo, mantendo o restante:

Novo conceito: destaque (fonte em cor vermelha).
Novo conceito: destaque (fonte em cor vermelha).

Dê ok e, de volta à interface principal do PME, localize um campo na camada de apresentação – Neste exemplo eu selecionei Autor. Clique com o botão da direita sobre ele e selecione Set Parent Concept… para escolher o conceito desejado. Selecione Destaque na janela que se abrirá e Ok para aplicar.

Atribuindo conceito a campo Autor.
Atribuindo conceito a campo Autor.

Feito! Quando o campo Autor for usado no relatório, ele aparecerá em cor vermelha, em destaque:

Conceito entra em ação automaticamente.
Conceito entra em ação automaticamente.

Notou a festa do caqui que está o layout do relatório, na parte de cima da figura? Mas como o PRD vai respeitar o definido no metamodelo, o relatório vai sair arrumadinho, apenas com o nome do autor em vermelho!

Outro exemplo: digamos que precisamos formatar a coluna da direita como um valor monetário, usando a máscara R$ #.###,00. Alteramos ou criamos um conceito no metamodelo, exportamos e reaplicamos o metamodelo à consulta previamente criada:

Altere um conceito para alterar o relatório.
Altere um conceito para alterar o relatório.

Reaplicar o metamodelo a um relatório aberto no PRD é meio chato. Como o PRD não embute o metamodelo no relatório, bastaria purgar o cache ou fechar o relatório e recarregá-lo para forçar o PRD a reler o XMI. Por puro e simples hábito, eu apelo para força bruta: simplesmente apago e recrio a fonte e as consultas (apelando para um copy-paste básico, já que ninguém é de ferro…)

Para relatórios publicados no BA Server não é preciso nada: basta republicar o modelo a partir do PME, ou recarregá-lo no quadro Manage Data Sources e já está valendo. A série 5 do BA Server veio com purga e recarga automática de metamodelos na republicação.


Só essa simplicidade e praticidade, na minha opinião, já é o bastante para fazer valer a pena usar um MQL ao invés de SQL.

Prompts

Um recurso crucial para relatórios são os “prompts”, ou filtros, que permitem ao usuário escolher uma determinada fatia dos dados para apresentação. O PRD oferece esse recurso sob o nome de parameters. Um parameter – ou prompt – é uma variável preenchida pelo usuário em tempo de execução, que entra na consulta como algum tipo de restrição. Por exemplo, a consulta abaixo retorna todos os clientes de um determinado “tipo”, filtrando a consulta pelo conteúdo do prompt tipo_selecionado:

    SELECT cliente, estado, cidade
    WHERE tipo = ${tipo_selecionado}

Não é um mecanismo complicado, mas não é trivial o bastante para eu mostrá-lo aqui completamente. Assistam este vídeo que verão como fazer um prompt.

Quando usamos uma consulta MQL, de metadados, aplicar a restrinção é um pouco mais simples. Os passos são esses:

  1. Construa um relatório com MQL, como o que fizemos no post passado;
  2. Crie uma consulta (MQL, SQL, tanto faz) que retorne a lista de opções que o cliente pode selecionar;
  3. Crie o parâmetro no PRD usando essa consulta como fonte;
  4. Volte para a consulta principal e, usando a interface de criação de consultas, adicione o filtro e insira o parâmetro.

No nosso caso vamos filtrar o relatório de vendas do Alexandre por UF.

Primeiro, construímos uma consulta em MQL que traz a lista de estados:

Lista de UFs criada no construtor de consultas MQL.
Lista de UFs criada no construtor de consultas MQL.

O MQL dessa consulta é:

    <mql>
      <domain_type>relational</domain_type>
      <domain_id>BeltranoOLTP</domain_id>
      <model_id>BV_MODEL_1</model_id>
      <model_name>Beltrano OLTP</model_name>
      <options>
        <disable_distinct>false</disable_distinct>
        <limit>-1</limit>
      </options>
      <selections>
        <selection>
          <view>BC_CLIENTES_PF</view>
          <column>BC_ESTADOS_UF_2</column>
          <aggregation>none</aggregation>
        </selection>
      </selections>
      <constraints/>
      <orders>
        <order>
          <direction>asc</direction>
          <view_id>BC_CLIENTES_PF</view_id>
          <column_id>BC_ESTADOS_UF_2</column_id>
        </order>
      </orders>
    </mql>
    </pre>

Construímos um paramater alimentado por essa consulta, chamado UF:

Novo parâmetro UF, alimentado pela consulta Query 2 do metamodelo.
Novo parâmetro UF, alimentado pela consulta Query 2 do metamodelo.

Depois inserimos esse parâmetro, UF, na consulta que popula o relatório: colocamos a coluna que vai ser filtrada na seção constraints e aplicamos uma igualdade para o parâmetro.

Inserindo o parâmetro na consulta principal com o editor de MQL.
Inserindo o parâmetro na consulta principal com o editor de MQL.

O truque é envolver o parâmetro em chaves, { e }. Com isso o construtor de consultas reconhece que se trata de um parâmetro e não de um valor ordinário, e ajusta a consulta automaticamente. A título de comparação, observe o filtro para pegar apenas as vendas do Alexandre.


Ao adicionar um nome cercado por { e } nos filtros, o construtor de consulta realiza duas coisas:

  1. Define um parâmetro no início da consulta
    <mql>
      <domain_type>relational</domain_type>
      <domain_id>BeltranoOLTP</domain_id>
      <model_id>BV_MODEL_1</model_id>
      <model_name>Beltrano OLTP</model_name>
      <options>
        <disable_distinct>false</disable_distinct>
        <limit>-1</limit>
      </options>
      <parameters>
        <parameter defaultValue="XX" name="UF" type="STRING"/>
      </parameters>
      <selections>
        <selection>
          <view>BC_PEDIDOS</view>
    <...restante da consulta...>        
    
  2. E usa esse parâmetro na seção conditions:
    <...começo da consulta...>
      <constraints>
        <constraint>
          <operator>AND</operator>
          <condition>CONTAINS([BC_PEDIDOS.BC_VENDEDOR_NOME_COMPLETO];"Alexandre")</condition>
        </constraint>
        <constraint>
          <operator>OR</operator>
          <condition>[BC_CLIENTES_PJ.BC_ESTADOS_UF_3] = [param:UF]</condition>
        </constraint>
      </constraints>
    

Ao rodar o relatório o PRD cria e apresenta um controle do tipo drop-down, populado com a lista dos estados. Sempre que um estado é selecionado, o relatório é automaticamente filtrado:

Filtro aplicado em consulta MQL.
Filtro aplicado em consulta MQL.

Um bom uso dessas possibilidades é criar relatórios que se adequam a cada usuário: basta usar o parâmetro pré-definido env::username para filtrar a consulta pelo nome do usuário na plataforma desde que esse usuário possua um nome igual registrado no banco de dados.

Por exemplo, se eu registrar no Pentaho BA Server os vendedores com o mesmo nome que possuem no Beltrano OLTP, eu posso filtrar os dados montando uma constraint do tipo Vendedor CONTAINS {env::username}.

Experimente!

8.3 Segurança

Por fim, mas não menos importante, um metamodelo pode restringir o conteúdo de uma consulta em função das permissões de acesso – controle de segurança – dos dados.

Como sempre, a idéia é simples: definimos um filtro de dados no metamodelo que usa o nome do usuário e, eventualmente, seu papel, para montar um controle de exibição baseado no controle de acesso.

Como fazer:

  1. No Pentaho BA Server, usando o papel de administrador, registre todos seus usuários. Eu fiz isso com os usuários da Beltrano;
  2. Com Pentaho Metadata Editor edite o metamodelo e registre um filtro no nível do modelo de negócio, seção Data Constraints: qualquer consulta contra esse modelo de negócio vai embutir aquele filtro automaticamente. Salve e publique o metamodelo no servidor;

    Registrando filtro no PME.
    Registrando filtro no PME.
  3. No PRD basta remover qualquer filtro local. Por exemplo, eu removi o filtro de usuário “Alexandre”, deixando o relatório trazer dados de todos os vendedores, indistintamente. Salvei e publiquei o metamodelo.

Feito! :-)

Para testar, acessei a plataforma com duas contas: Fábio e Alexandre. Como o relatório consome metadados, e os metadados são completamente filtrados por meio do atributo Data Constraints no Business Model, os dados apresentados já estão filtrados.

Resultado do filtro por controle de segurança.
Resultado do filtro por controle de segurança.

8.4 Conclusão

“Nossa, Fábio! Que maravilha!”, dirão vocês, “e não tem nenhuma desvantagem?”

Sim, tem: justamente adicionar uma outra camada para manutenção. Se usamos apenas SQL, qualquer alteração no banco entra em efeito imediatamente para o relatório. Se usarmos um metamodelo vamos precisar atualizar a camada de metadados antes de poder sequer testar as mudanças no PRD. Fazer uma pequena alteração na formatação pode forçar o analista a quebrar o vínculo do campo com a metaconsulta, perdendo a vantagem do modelo centralizado, ou então obrigar a uma atualização do metamodelo, cascateando a publicação de uma nova versão.

Há uma segunda desvantagem, mas é mais sutil e, talvez, pior: aparentemente não há como fazer UNIONs! Isso não é um problema para modelos bem comportados, mas modelos como o do Beltrano – que nem é tão exótico assim – se quebram quando tentamos fazer certas combinações numa só consulta. Por exemplo, no modelo transacional, não é possível escrever um único SQL que traga todos os clientes PF e PJ. É preciso duas consultas, coladas a posteriori com UNION, para então chegar ao conjunto completo. E eu não achei como fazer isso com MQL.

Ou seja, as vantagens de uso de um metamodelo vêm com um preço: um processo de desenvolvimento com mais alguns passos. Se isso vai compensar no final é uma questão respondida projeto a projeto.

Até a próxima! :-)

Anúncios

Novo Livro: Pentaho 5.0 Reporting by Example

A Packt lançou um novo livro sobre o PRD (Pentaho Report Designer): o Pentaho 5.0 Reporting by Example – P5RbE.

O sub-título do livro é “Guia para Iniciantes” e ele entrega exatamente o que promete. O livro é bem detalhado, preciso, completo e razoavelmente bem escrito. Como os autores não são falantes nativos de inglês (são castelhanos), o texto é ligeiramente esquisito. No final das contas esse detalhe é irrelevante e não afeta a qualidade do material.

Em mais de 300 páginas, com muitas imagens e ilustrações, ele aborda tudo que alguém precisa para começar a criar relatórios com o PRD:

  1. Preparação da máquina, instalação do PRD e do BI Server, configurações;
  2. Controles da interface, tipos de fontes de dados, conexões etc.
  3. Relatórios com grupos, ordenação, funções e totalizadores;
  4. Formatação de páginas, como zebramento, numeração, data, cabeçalho, rodapé etc.;
  5. Sub-relatórios;
  6. Prompts (filtros dinâmicos);
  7. Gráficos: explica o que é cada tipo e ainda ensina a fazer vários modelos, como de barra, torta, linha, área e sparklines;
  8. Interação: relatórios que abrem outros relatórios a partir de links;
  9. Integração com BI Server (ou BA Server): como publicar, atualizar, agendar para execução;
  10. Outros assuntos: customização com CSS, crosstab (em cima de SQL!), variáveis de ambiente (detectar usuário logadono BI Server, por exemplo) etc.
  11. Como embutir o PRD em outras aplicações via API Java.

Ele não apenas mostra como funciona cada recurso, em razoável detalhamento, mas ainda traz vários exemplos documentados passo-a-passo para que o leitor possa – de fato – aprender PRD seguindo esses exemplos. Os exercícios são construídos em cima da base de dados de exemplo Sákila, do MySQL.

Se você precisa de uma ferramenta para criar relatórios, stand-alone, no Pentaho BI Server ou para embutir na sua aplicação, o P5RbE é o seu livro. Como todo material de BI, se você nunca mexeu com o assunto, ele vai parecer um pouco esquisito, mas depois de um tempo você se acostuma.

Aspectos Positivos

Apesar de se dizer para iniciantes, é o livro mais completo de PRD que eu conheço (e eu li praticamente todos que existem sobre esse assunto.) Ele não apenas tem uma profundidade adequada, mas também abrange muitos assuntos. Como já trata a versão 5.0 da suite, ele vai continuar a ser útil por muito tempo – não vai ficar defasado tão cedo. Há muitas figuras e ilustrações, facilitando bastante o entendimento de cada exemplo. Os exemplos são relevantes e detalhados o bastante para ser transposto sem grandes dificuldades para os casos particulares que cada leitor com certeza terá.

Aspectos Negativos

O assunto é árido e o livro, para quem nunca mexeu no assunto, pode parecer um pouco sem pé-nem-cabeça em alguns trechos. Algumas poucas figuras são feias, e outras têm uma resolução estranha, como se houvessem sido ampliadas a partir de um screenshot de baixa resolução. E como eu já disse, o inglês dele às vezes é um pouco esquisito para quem já está acostumado com o inglês dos norte-americanos (e mesmo com o dos ingleses/australianos), mas nenhum desses fatores prejudica a leitura ou diminui a qualidade do livro.

Formatos

A Packt publicou esse livro em formatos eletrônicos diversos (PDF, ePub etc.) e em meio físico. Quando você compra pelo site deles, você ganha acesso a todas essas versões. Fique atento: isso não acontece se você comprar pela Amazon. Logo o melhor é comprar pelo site da Packt: você vai precisar transferir o arquivo manualmente para o Kindle, e em troca passa a dispor de vários formatos. Eu li o formato PDF (e gravei um ePub no meu Kindle) e a editoração é impecável.

Conclusão

Se você precisa montar relatórios com o PRD, ou precisa escolher uma ferramenta para criar relatórios, este livro é feito sob medida para você. Por outro lado, se você está começando em BI e está buscando material de estudo, deixe esse livro para mais tarde, já que a vantagem de cobrir só o PRD vai ser uma desvantagem justamente por ser muito específico.

Aviso Legal

A Packt me ofereceu uma cópia do livro em troca de eu resenhá-lo no meu blog e em fóruns nos quais eu participo. Faço questão de deixar claro aqui que esta resenha não é decorrente de uma das minhas frequentes compras de livro. Em todo caso, eu vou requisitar à empresa na qual trabalho a compra de algumas cópias, porque ele está muito bom e vai resolver nossas necessidades de material de referência do PRD.