O Pentaho Data Integration (PDI, antigo Kettle) oferece uma quantidade de opções para se comunicar com o “mundo exterior”. Por exemplo, ele permite envio de e-mails tanto em transformações quanto em jobs por meio de passos nativos, ou mensagens por mensageria instantânea (Instant Messaging, IM) através de plug-ins.
Plug-in PDI que envia notificações a smartphones Apple ou Android.
Um uso clássico dessa capacidade é o envio de algum tipo de notificação ao final de um processo de ETL. O PDI pode mandar um e-mail para todos os interessados, informando se o processo transcorreu em ordem, ou se houve algum erro, e qual é o estado atual dos dados. Essa transformação faz isso:
Transformação que monta e envia e-mail com relatório para uma lista de destinatários.
Foi exatamente essa transformação que eu usei em um projeto recente, e ela funcionou perfeitamente!… Em desenvolvimento. Em outras palavras, rodava beleza quando eu a testava no Spoon, que é a interface gráfica do PDI, mas falhava fragorosamente ao rodar no ambiente de produção, via linha de comando. Depois de um pouco de tentativa e erro eu consegui resolver todos os problemas, soluções que eu divido com vocês no post de hoje.
Mudança de Ambientes
A primeira dificuldade é o fato de os bancos de dados, seus IPs, usuários e senhas serem diferentes em cada ambiente. Se em desenvolvimento o banco chama-se dw_corp, com usuário e senha postgres, em localhost:5432, em produção sem dúvida será diferente – no mínimo a política de segurança da empresa vai cuidar de ter usuário e senha “protegidos”, i.e., que só o gestor do processo em produção sabe qual é.
Resolvemos essa dificuldade parametrizando toda e qualquer referência ao banco de dados (e por extensão a diretórios, servidores de apoio etc.)
Conexão PDI
Parametrizar uma conexão PDI é simples: basta usar variáveis para registrar os valores de parâmetro de uma conexão. A figura abaixo mostra uma conexão com o banco Beltrano OLTP parametrizada:
Conexão PDI parametrizada.
Daí é só registrar essas variáveis e seus valores no arquivo kettle.properties, que fica dentro do diretório .kettle, na raiz do usuário. Seu ambiente de desenvolvimento terá valores para o PDI acessar os seus bancos, enquanto que em produção deve existir um arquivo análogo, configurado adequadamente para esse ambiente, pelo próprio gestor da máquina de produção.
Conexão PRD
Eu queria enviar relatórios bonitos, bem formatados, e não um simples arquivo texto com algumas contagens e por isso eu usei o Pentaho Report Designer. Daí, de cara eu sabia que teria o mesmo problema: valores de conexão diferentes para cada ambiente. Infelizmente, porém, o PRD não pode usar as mesmas variáveis que o PDI usa. Não dá para colocar o mesmo ${BELTRANO_OLTP_HOST} da conexão do PDI no PRD, mas dá para usar uma fonte de dados JNDI, que é um tipo de conexão disponível por meio do ambiente Java.
Eu tive sorte em descobrir como usar JNDI. Nem pense em me perguntar o que é ou como funciona…
Definir uma fonte JNDI no PRD é simples: apenas selecione esse tipo e forneça um nome:
Conexão JNDI no relatório PRD.
E onde são registradas os parâmetros de uma conexão JNDI? No arquivo default.properties, dentro do diretório /home/<USUÁRI>/.pentaho/simple-jndi, neste formato:
Os itens driver e url são particulares de cada banco. O restante é sempre igual.
Parametrizando o PRD no PDI
Com a parametrização do PDI e do PRD eu conseguia montar e rodar processos e relatórios nos dois ambientes sem me preocupar com mais nada, desde que cada um rodasse independentemente do outro. Ou seja, uma transformação executada pelo PDI, e um relatório pelo PRD – no máximo dentro do servidor Pentaho.
Mas eu queria rodar o relatório a partir do PDI!
O primeiro obstáculo foi fácil: onde eu definiria a conexão JNDI do PDI, que – pela simples definição de JNDI – seria repassada a um PRD disparado a partir do PDI? No arquivo jdbc.properties, na pasta ./data-integration/simple-jndi. Basta copiar para ali a definição do outro default.properties, e lembrar de fazer a mesma coisa no ambiente de produção.
Parametrizando o Parametrizador
Ah, se fosse tudo tão lógico e simples!
Foi aqui que a porca torceu o rabo: em desenvolvimento, na interfave gráfica, todas as variáveis eram “vistas” pelo Spoon por default – todas as definições JNDI, por exemplo. Mas ao tentar rodar em produção apareceu uma mensagem nada a ver…
INFO 15-07 09:13:31,507 - Beltrano JNDI Postgres - New database connection defined
ERROR 15-07 09:13:31,534 - Count incomplete revisions - An error occurred, processing will be stopped:
Error occured while trying to connect to the database
java.io.File parameter must be a directory. [/home/users/kettle/CLIENT/simple-jndi]
Depois de cavocar o Google um pouco, eu descobri que, a partir da versão 4.1, o PDI passou a aceitar que o arquivo com as definições JNDI ficasse em qualquer lugar, e não apenas dentro do ./data-integration.
Trecho que chama o Java, dentro dos scripts. Note a variável -DKETTLE_JNDI_ROOT.
Para complicar a vida do desenvolvedor, o Spoon preenche essa variável automaticamente, apontando diretamente para o diretório que contém o arquivo de definições, mas o Kitchen e o Pan, não!
Essa modificação precisa ser feita pelo gestor do ambiente de ETL. Para definir a localização do arquivo de propriedades JNDI basta alterar a variável -DKETTLE_JNDI_ROOT,que é definida no final da chamada do Kitchen ou Pan (e até mesmo do Spoon, mas lembre-se que o Spoon faz coisa a mais), setando-o uma linha antes da chamada ao Java, desta forma:
Note que eu apontei a variável para o meu diretório-padrão. Você deve inserir o diretório correto para sua instalação, não apenas copiar o exemplo acima, cegamente.
Pronto! Finalmente o PRD passou a rodar, parametrizado, dentro do PDI, tanto em desenvolvimento quanto em produção!
Veja este post no fórum internacional, aqui reproduzido parcialmente para o caso de ter sumido=.)*
Post do fórum Pentaho no qual é solucionado esse problema.
Conclusão
Uma das eternas promessas da TI é oferecer gestão por exceção. Nesta modalidade, os gestores de alguma coisa são notificados quando esta alguma coisa assume um estado inadequado. Por exemplo, quando os valores de indicadores caem fora de certas faixas, ou quando um erro surge em algum sistema. Na gestão por exceção, o sistema não dá um pio enquanto tudo estiver certo, e dispara notificações quando as coisas saem dos trihos.
Ferramentas de ETL também carregam essa promessa. Dependendo do marketing, ora vende-se a idéia de avisar o gestor do processo de ETL tão cedo ocorra um erro, ou notificar os clientes que os dados foram carregados e estão pronto.
O PDI pode executar a tal gestão por exceção: basta incutir-lhe a lógica de notificação e os mecanismos de comunicação adequada. Como vimos neste post, dá para desenhar um relatório de alta qualidade, renderizá-lo em PDF e transmiti-lo por e-mail para um ou mais destinatários, sempre que uma condição desejada é atingida.
Colocar isso tudo para rodar, porém, são outros quinhentos. Neste post vimos como parametrizar tanto o relatório PRD quanto os artefatos PDI para garantir que o processo funcionará em desenvolvimento e em produção.
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.
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).
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.
Feito! Quando o campo Autor for usado no relatório, ele aparecerá em cor vermelha, em destaque:
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.
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:
Construa um relatório com MQL, como o que fizemos no post passado;
Crie uma consulta (MQL, SQL, tanto faz) que retorne a lista de opções que o cliente pode selecionar;
Crie o parâmetro no PRD usando essa consulta como fonte;
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.
Construímos um paramater alimentado por essa consulta, chamado UF:
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.
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:
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.
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:
No Pentaho BA Server, usando o papel de administrador, registre todos seus usuários. Eu fiz isso com os usuários da Beltrano;
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.
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.
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.
É hoje! às 19H00min nos reuniremos no Escritório Geek, a base da IT4Biz no centro de São Paulo (ao lado do Metrô São Bento) para bater um papo, comer um pão de queijo e trocar experiências.
Eu vou falar sobre os logs do PDI – como capturá-los e o que dá para fazer com eles. Depois eu vou postar aqui um artigo, com todos os detalhes.
P.S.: a abreviação PenSaPUG é invenção minha e em nada oficial. Só para constar, significa Pentaho São Paulo User Group. Se você tiver uma idéia melhor, estamos aceitando sugestões. Falando alto parece raça de cachorro – ou sapo…
The today aging Pentaho Solutions was the first authoritative source of Pentaho Platform information, but it was far from practical no matter how good. Even those already into the platform had to scratch their heads a little to translate all that knowledge into action. A lot of us simply need much more than was made available. We needed pretty-a-porter how-to’s with which solve our daily paings with each Pentaho Suite component. And that’s the niche Packt has been neatly filling out: they are running into the HUNDREDS of published Cookbooks, on a lot of topics. Yeah, I know, it is starting to sound an unintended pun “we’ve got IT covered.” <chuckles>
This new book covers a lot of the newest Pentaho Suite version (v.5) recipes. Except for PDI (which already featured a dozen Packt books), the book comes into almost everything else: BA Server, Metadata Editor, Schema Workbench, PRD, and some Enterprise Edition operations, besides a bit of C*Tools.
The Good
It is a relativelly complete compendium of everything that deserves atention on the Pentaho Plaform:
BA Server: how to set up data sources (JNDI, Analysis, Metadata etc.), how to tie it to an LDAP server and manage users/roles;
Metadata: it is the first place to seriously show how to use “concepts”, an importanta metadata ahn… concept. Also, there are a lot of important tips on metadata modeling, like complex join and calculated fields;
OLAP: how to create cubes with Schema Workbenche, with calculate members, how to publish it and generate OLAP views with Saiku;
PRD: very complete, with recipes to build prompts, sub-reports, charts (including the tricky sparkline), besides having a PDI transformation for report source.
Were it not enough Mr. Ramazinas goes on to show recipes on less searched for things like interface customization and C*Tools (CDE) introduction, always with hands on, detailed examples.
Raising the bar, the book offer recipes on the Pentaho Enterprise Edition. Although Pentaho Community Edition abbility to offer everything the Enterprise Edition does, Enteprise Edition adoption is on the rise and a lot of its resources rest unusedor not fully explored by its customers. Being usefull for the sheer amount and coverage of the recipes, the book becomes even more interesting for the EE recipes it brings:
Analyzer: operations with OLAP client;
Dashboard Designer: dashboard editing made easy;
Interactive Report: ad hoc reporting, the heir to the gone WAQR;
Mobile: the inedit iPad and smart phones interface.
More than just helping those with Pentaho EE, the book opens it to those who have not bought it. IMHO, this is an excelent opportunity to get acquainted with Pentaho EE, a high quality yet cheap (very cheap for what it offers!!) versatily BI product.
Also, more than offering an extensive list of how-to’s, Packt’s cookbook format makes it for a very understandable experience for it tells not only how to do each of its recipes, but also why it works and how it does and what else there is to see. Every recipe has at least an image. Even in the grayscale Kindle all of them have a good look.
For its detailed content, its broadness (lots of things on both CE and EE) and its usability, Pentaho BA Cookbook is another must-have volume on the Pentaho Platform practioner library, and even more for a casual dabbler.
The Bad
Ok, the book shines – it is very good, have no question about it. But…
Kindle (Touch – my device) version (the one I reviewed) does not stop at the chapters divisions when one sweeps the finger vertically across the screen. Instead it jumps to the beggining. Annoying;
Some recipes are too trivial. If the user really needs somebody telling it, then he also needs help on how to setup the software, which the book does not do – and of course not! Recipe books show recipes, now how to cook or who to buy and setup a cooktop;
I missed some important recipes, like how to setup BA Server with other databases. There are instructions on how to do that at Pentaho’s Infocenter. However there are some other recipes which have Infocenter how-to’s too, but they’re in the book nonetheless;
I missed performance tunning recipes, like setting an external cache or turning on and using aggregated tables;
The subjects does not look like well separated. For instance, the schedulling is part of the Pentaho BA Server, but it makes a full chapter in the fartest corner of the book, chapter away from the BA Server chapter. Maybe it would make more sense to have one after another, if not totally made into a single chapter;
Plugins: Pentaho Marketplace’s plugins are growing by the day, but the book says little about them. It only briefs mention two of them (Saiku and Logs), besides internationalization.
None of those things diminishes the book value, however.
The… Italian
Packt is a trully global enterprise. Their writers come from all over the world and in fact most of them write in a foreign language – English. Well, Mr. Sérgio Ramazina is itallian and as every good latin (just like me, brazillian), tends to thing in a more literall English. Reading the book you almost can hear his accent in phrasings like “This is the idea that stays behind the concept of(…)” (locus 2028.) The English-born speaker would rather have a simpler “(…) the idea behind the concept(…)” Mr. Ramazina quite used up his quota, but it never impairs the reading. It is kind of easier for me, in fact, because as a Brazillian I also tend to think on that style of English. Maybe it might be stranger for a, say, Japanese reader (as it is a bit awkward for me to read Japanese writers in English.)
Anyway, I just though of making a note so you know what to expect. The book is good and the reading flows ok, just a bit… creatively. <grin>
Conclusion
Have installed Pentaho BA Server 5 and know not where to begin with? Were commited to migrate a legacy 4.8 BI Server to 5? New to Report Designer 5 or banging head against the wall with some JNDI configuration and metadata editing? Wait no further, Packt’s new Pentaho BA Cookbook is your book: a wealth of immediatelly usefull how-to’s (recipes), well layd-out and explained in details. Lots of topics on both the BA Server and its clients, as well as some topics on the Enterprise Edition. Even if it does need some improvent, this is the book to go after for Pentaho Suite 5!
O hoje defasado Pentaho Solutions foi a primeira fonte oficial de informações sobre a plataforma, mas ele não era um livro prático, ainda que bom. Mesmo que já conhecia e usava a plataforma precisava bater um pouco a cabeça para aproveitar o conhecimento ali depositado. Muitos de nós precisávamos mais do que aquilo. Nós precisávamos de receitas prontas para resolver os nossos problemas e dificuldades com cada componente da Suite Pentaho. Esse é o nicho que a Editora Packt vem preenchendo diligentemente: já são CENTENAS de “cookbooks” – literalmente “livros de receitas” – cobrindo todo tipo de necessidade de TI.
Neste volume estão cobertas várias receitas a versão 5.0 da Suite Pentaho, hoje a mais nova. Excetuando o PDI, que já tem uma boa meia-dúzia de livros na Packt, ele aborda praticamente tudo o restante: BA Server, Metadata Editor, Schema Workbench, PRD, e algumas operações com a Enterprise Edition além de um pouco de C*Tools.
The Good
É um compêndio relativamente completo de tudo que merece atenção na plataforma:
BA Server: como configurar fontes de dados JNDI, integrar com LDAP e gerenciar fontes de dados;
Metadados: é o primeiro lugar que mostra como usar “concepts”, além de outras dicas importantes (como criar campos calculados e junções complexas);
Schema Workbench: como criar um cubo, como membros calculados e tudo;
PRD: muito completo, com receitas para construir relatórios com prompts e sub-relatórios, incluindo o uso de “sparklines”, além de usar transformações do PDI como fontes de dados.
Não bastasse a grande quantidade de receitas, todas úteis, o livro ainda vai além disso e oferece receitas de coisas menos buscadas, como customização da interface e introdução ao CDE (C*Tools) – sempre com exemplo prático.
A obra também traz receitas sobre o Pentaho Enterprise Edition, o que leva seu nível a um outro patamar. Apesar de a versão comunitária ser capaz de oferecer todos recursos, a adoção da EE está crescendo, e muitos recursos ainda restam por ser plenamente utilizados por esses clientes. Se o livro já é útil pela simples qualidade e pela variedade de receitas, ele se torna ainda mais interessante com receitas que cobrem:
Analyzer: cliente OLAP;
Dashboard Designer: editor de dashboards
Interactive Report: para criação de relatórios ad hoc via web (parente do Saiku Reporting e do finado WAQR);
Mobile: a interface para iPad e celulares.
Mais do que ajudar quem possui o EE, o livro mostra grandes detalhes do produto a quem não o possui. Na minha opinião isso é excelente, porque dá a chance de conhecer de perto as vantagens do EE – que é um produto de alta qualidade e (muuuuito) baixo custo.
Finalmente, o livro não apenas tem uma lista extensa de como-fazers, mas o formato de livro de receitas da Packt traz a receita em si e explicações de como e porque as coisas acontecem, e orientação sobre que direção seguir para obter mais informações, ou o sobre o que mais há para aprender. Todas as receitas têm ao menos uma figura, e todas as figuras são claras e bem definidas. O formato Kindle (no qual eu li o livro) sempre piora um pouco as imagens, mas mesmo assim ainda ficou muito bom.
Pelo detalhismo do conteúdo, sua amplitude (incluindo muitas coisas de CE e EE) e a usabilidade de todas as receitas, o Pentaho BA Cookbook mostra-se mais um volume indispensável para quem usa a Plataforma Pentaho no seu dia-a-dia, para o estudante eventual e mesmo para o iniciante.
The Bad
Que não reste dúvida: o livro é muito bom e muito útil. Se você precisa aprender sobre a Plataforma Pentaho, versão 5, esse é o livro.
Isto posto, há um bocado de coisas que ainda não estão 100%:
A versão Kindle não tem as divisões de capítulo: se você arrastar o dedo na tela, o livro pula para o início ao invés de para o capítulo seguinte/anterior;
Algumas das receitas são muito triviais. Se o leitor precisa daquela receita, então ele precisa de ajuda também para instalar os programas, mas o livro não mostra isso (claro: livros de receita não ensinam a comprar fogão e a ligar o fogo!)
Senti falta de receitas importantes, como instalar o BA Server CE com outros bancos de dados. Essa orientação existe no Pentaho Infocenter, e por isso talvez não tenha sido incluída. Mas algumas outras coisas existem no Infocenter e mesmo assim entraram no livro;
Senti falta de receitas de performance, como instalação de cache externo e aplicação de tabelas pré-agregadas;
Há um pouco de mistura de assuntos, e a separação ainda pode ser melhorada. Por exemplo, há um capítulo só com receitas da nova interface do BA Server, bem no início, e um outro com receitas sobre agendamento quase no final. Como é tudo assunto do BA Server, talvez fizesse mais sentido estarem juntas ou no mínimo subsequentes;
Plugins: a quantidade de plugins no Pentaho Marketplace vem crescendo a olhos vistos, mas o livro aborda apenas dois plugins (Saiku e Logs), além da internacionalização;
Nenhuma dessas coisas atrapalham o livro, mas elas estão lá (ou não) de qualquer forma.
The… Italian
A Packt é uma editora internacional, verdadeiramente global e seu elenco de escritores reflete isso: eles têm gente literalmente do mundo todo e o fato é que todos precisam escrever em, no mínimo, inglês. Há essa multitude de culturas e línguas forçosamente enquadradas em uma língua (para o autor) estrangeira. Resultado: uma presença maior ou menor de expressões curiosas, atípicas do inglês falado por nativos.
O Sérgio Ramazina é italiano e como bom latino (assim como nós, brasileiros), tende a pensar em inglês mais literalmente. Por exemplo, quase dá para ouvir seu sotaque em expressões como “This is the idea that stays behind the concept of(…)” (locus 2028.) Um nativo escolheria uma frase mais sintética, com outro verbo: “This is the idea behind the concept of(…)”
O autor meio que esgotou a cota dele desses regionalismos, mas isso não chega a atrapalhar a leitura. Com certeza causam alguma estranheza em quem esteja mais acostumado ao inglês escorreito, mas para mim, latino com o Sérgio, essas expressões são transparentes porque fazem sentido em português. Talvez leitores de outras nacionalidades sintam alguma dificuldade – como quando eu preciso reler trechos escritos por japoneses, por exemplo.
Conclusão
Instalou a versão 5 da suite Pentaho? Migrou e agora precisa fazer o que já fazia? Quer começar com Pentaho, baixou o produto mas agora está em dúvida sobre como realizar cada tarefa?
Então o Pentaho BA Cookbook é o seu livro: rico em receitas úteis, detalhadas e bem explicadas. Ele aborda assuntos variados, todos relevantes, sobre o servidor e alguns dos clientes Pentaho. Ainda que precise de algumas melhorias (e nestas não se incluem as idiossincrasias de autor), e não traga absolutamente tudo que existe (o que seria um exagero de qualquer forma), esse é o livro sobre a versão 5.0!
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:
Preparação da máquina, instalação do PRD e do BI Server, configurações;
Controles da interface, tipos de fontes de dados, conexões etc.
Relatórios com grupos, ordenação, funções e totalizadores;
Formatação de páginas, como zebramento, numeração, data, cabeçalho, rodapé etc.;
Sub-relatórios;
Prompts (filtros dinâmicos);
Gráficos: explica o que é cada tipo e ainda ensina a fazer vários modelos, como de barra, torta, linha, área e sparklines;
Interação: relatórios que abrem outros relatórios a partir de links;
Integração com BI Server (ou BA Server): como publicar, atualizar, agendar para execução;
Outros assuntos: customização com CSS, crosstab (em cima de SQL!), variáveis de ambiente (detectar usuário logadono BI Server, por exemplo) etc.
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.
Recebi um problema novo para tratar, que já veio com solução. Me passaram um relatório a ser desenvolvido no Pentaho Report Designer (PRD) que deve ter vários prompts (parâmetros.) Alguns são caixas de texto simples, como nome do projeto, e outros vêm de consultas, como lista de departamentos. Dois ou três deles, porém, são listas que não vêm de nenhuma tabela. O PRD só popula drop-downs, radio buttons e check boxes a partir de um SQL (ou eu acredito que só faz assim – não investiguei muito mais.)
O fato é que eu precisava de uma consulta dummy (boneco) que retornasse algumas linhas, tais como “sim, não, talvez” para alimentar um radio-button. Como eu disse, recebi o relatório, e ele veio com um desses casos resolvidos. Eu examinei a consulta:
SELECT TEXTO,VALOR
FROM
(SELECT ‘Sim’ AS TEXTO,’1′ AS VALOR
UNION
SELECT ‘Não’AS TEXTO,’2’ AS VALOR
UNION
SELECT ‘Talvez’ AS TEXTO,’3′ AS VALOR) AS DUMMY
ORDER BY 2
Oras! Essa eu não sabia! É uma tabela dummy!! A consulta foi escrita para Postgres, mas com certeza existem comandos equivalentes para MS SQL Server, Oracle, MySQL e outros bancos.
Genial, não? :-) E nem fui eu quem fez isso!
Então é assim: sempre que precisar de uma lista que não existe em uma tabela para popular um prompt no PRD, construa a consulta boneco acima e seja feliz.
É isso.
ADENDO: a consulta tinha dois erros, um de nome de campo e outro de aspas simples em volta dos valores. Corrigido. Nada como tomar o próprio remédio…
Geek BI 