Até a versão 4.x o Pentaho BI Server usava um repositório que misturava sistema de arquivos com bancos de dados, e era muito prático de mexer. Só tinha um problema: era tosco pra dedéu. A Pentaho aproveitou a reforma geral que deu à luz o BA Server 5.0 e adotou um repositório “profissa”. A partir da versão 5.0 o servidor passou a usar o JackRabbit como repositório oficial.

Eis a definição do projeto pela Apache Foundation, que cuida desse projeto:


O repositório de conteúdo Apache Jackrabbit é uma implementação 100% aderente à API de Repositórios de Conteúdo para Tecnologia Java (JCR especificada nas JSR 170 e JSR 283.)


Logo a seguir dizem que um repositório de conteúdo é “um provedor de armazenamento hierárquivo de conteúdo com suporte para conteúdo estruturado e não-estruturado, busca por texto, versionamento, transações, observação e mais”. Interessante! Será que o repositório do BA Server suporta versionamento? O que é observação? Perguntas para outro post!

Para os usuários do BA Server esse novo formato se traduz em segurança aumentada, mais integração com a plataforma e seus serviços, maior flexibilidade e melhor performance em geral. Uma das mudanças trazidas por esta nova tecnologia é o processo de migração de soluções (do conteúdo gerado no servidor) entre duas versões do BA Server. Antes era só copiar as pastas particulares do diretório ./pentaho-solutions de uma instalação para outra, atualizar o servidor do destino e estava feito.

Ou quase. Na verdade, havia um trabalho meio chato nesse caminho, já que você tinha que levar também as permissões por pasta e objetos e cuidar de alguns outros detalhes. No final das contas, só quem tinha a versão Enterprise (paga) é que tinha um processo de migração mais facilitado.

A adoção do Jackrabbit tornou esse processo de migração mais profissional também para a comunidade. E isso tudo eu escrevi só para dizer que neste post eu vou dividir com vocês o que eu aprendi quando precisei migrar um servidor da série 5.x.


AVISO IMPORTANTE!!!

Mesmo que tenha resolvido meu caso, esse procedimento é experimental!! Estou compartilhando aqui o pouco que eu aprendi para resolver a minha necessidade. Se você decidir aplicá-lo a seu ambiente, o fará por sua conta e risco. Eu não posso ser responsabilizado por nenhuma de suas ações!


Isto posto, terei prazer em ajudar se você tiver algum problema ou dúvida – basta postar um comentário. ;-)

Preparando o Cenário

Para que você aprenda o processo, sem ser atrapalhado por um monte de pequenos detalhes que podem aparecer no caminho, eu sugiro que monte um ambiente simples, no qual você possa testar o processo e praticá-lo à vontade, até aprendê-lo e só então aplicá-lo ao seu ambiente.

Para montar esse ambiente eu sugiro o BA Server 5.4, mas em princípio esse processo deve ser compatível com qualquer versão das séries 5.x e 6.x – mais uma vantagem da adoção de um padrão. Apenas esteja atento para o fato de que o programa que faz a exportação/importação pode ser diferente (pouco ou muito) de uma versão para outra, como, por exemplo, ter um switch a mais ou a menos.

Nosso ambiente terá dois BA Servers, um de origem e outro de destino. Para conseguir isso apenas descompacte o ZIP do BA Server 5.4 para pastas ora com um nome, ora com outro. Neste exemplo o diretório do BA Server de origem chama-se ./biserver-ce e o de destino, ./biserver-ce_DESTINO

Diretório /opt/pentaho/5.4 com dois BA Servers.
Diretório /opt/pentaho/5.4 com dois BA Servers.

Não é possível rodar dois BA Servers simultaneamente sem alterar diversas configurações em pelo menos um deles. Por isso, para manter tudo o mais simples possível e focar só no processo de migração, não vamos rodar os dois ao mesmo tempo, mas apenas um de cada vez: rodamos o de origem, exportamos o repositório, paramos esse servidor, subimos o de destino e importamos o pacote extraído do outro.

Vamos lá!

Exportando o Repositório

Depois de expandir o ZIP do BA Server, suba-o: abra um terminal, mude de diretório e comande ./start-pentaho.sh.


Se você não tem idéia de como fazer isso, bolas, porque está se metendo a migrar a coisa? :-) Mas se você é como eu, que não desiste só porque não está entendendo nada, e quiser experimentar mesmo assim, baixe o capítulo de degustação do meu livro Pentaho na Prática.


Com ele no ar, acesse-o (URL http://localhost:8080/pentaho) com usuário admin e senha password e mude alguma coisa. Apague um arquivo, remova um diretório, criei e salve alguma análise com o jPivot etc. Se você não modificar nada, não vai notar o resultado do processo.

Eu removi todos os usuários, menos o admin, e criei alguns novos. Montei uma visão OLAP com jPivot e salvei em admin. Daí criei uma pasta pública chamada Rodas de Aço e movi para lá todo conteúdo das subpastas do Steel Wheels, apagando esta. No final ficou assim:

Origem: note as pastas de usuários e pública.
Origem: note as pastas de usuários e pública.

Pronto para exportar!

  • O servidor deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de origem;
  • Comande:
./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log

Se tudo der certo a saída no terminal vai ser mais ou menos esta:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$ ./import-export.sh --export --url=http://localhost:8080/pentaho --username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip --charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
Export Completed
Response Status: 200
Export written to: /tmp/Repositorio_54_Origem.zip
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$

E você terá um zip, na pasta /tmp, contendo o repositório de arquivos do servidor:

Conteúdo do arquivo de backup do repositório.
Conteúdo do arquivo de backup do repositório.

Note que interessante: ainda existem diretórios ocultos, como o famoso /bi-developers, uma coleção de exemplos de uso do BI Server.

E uma “pegadinha”: parece que nenhum dos diretórios de usuários, que estavam vazios, foram exportados. Isso não é verdade, pois eles aparecem se listarmos o conteúdo do arquivo em um terminal (ou talvez com algum outro programa que não o File Roller):

fabio@pentaho:/tmp$ unzip -l Repositorio_54_Origem.zip 
Archive:  Repositorio_54_Origem.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2016-06-29 13:02   home/
        0  2016-06-29 13:02   home/Everton/
        0  2016-06-29 13:02   home/Fabio/
        0  2016-06-29 13:02   home/Joe/
        0  2016-06-29 13:02   home/admin/
     7052  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot
      186  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot.locale
       62  2016-06-29 13:02   home/index_pt_BR.locale
        0  2016-06-29 13:02   public/
        0  2016-06-29 13:02   public/bi-developers/
(...)
       84  2016-06-29 13:02   public/index.locale
       64  2016-06-29 13:02   public/index_pt_BR.locale
   961634  2016-06-29 13:02   exportManifest.xml
---------                     -------
 10708536                     2014 files
fabio@pentaho:/tmp$

O comando de exportação para Windows tem apenas as diferenças do sistema operaciona: muda de .sh para .bat e tudo que é / vira c:\ :

import-export.bat --export --url=http://localhost:8080/pentaho
--username=admin --password=password
--file-path=%USERPROFILE%\AppData\Local\Temp\Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true
--logfile=%USERPROFILE%\AppData\Local\Temp\logfile_export.log

Ao contrário do Linux, que por padrão tem um diretório /tmp universal, no Windows cada usuário tem seu próprio diretório temp. Ele pode ser referenciado pela variável %USERPROFILE%\AppData\Local\Temp, que usamos acima.


Importando o Repositório

Baixe o servidor de origem e suba o de destino. Pronto?

  • O servidor de destino deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de destino;
  • Comande:
./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip
--logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true

Ele vai passar um tempo “pensando” e depois começar a cuspir a saída do processamento:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_DESTINO$ ./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin --password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip --logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
done response = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Repository Import Log</title>
<style type="text/css">
<!--
body, table {font-family: arial,sans-serif; font-size: x-small;}
th {background: #336699; color: #FFFFFF; text-align: left;}
-->
</style>
</head>
<body bgcolor="#FFFFFF" topmargin="6" leftmargin="6" style="font-family: arial,sans-serif; font-size: x-small">
<hr size="1" noshade>
Log session start time Wed Jun 29 15:00:44 BRT 2016<br>
<br>
<table cellspacing="0" cellpadding="4" border="1" bordercolor="#224466" width="100%">
<tr style="background: #336699; color: #FFFFFF; text-align: left">
<th>Time</th>
<th>Import File</th>
<th>Level</th>
<th>File:Line</th>
<th>Message</th>
</tr>
(...)

Isso vai continuar por mais um monte de linhas, varrendo o arquivo inteiro até o final. As mensagens no final devem ser assim:

(...)
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:53</td>
<td title="Message">Start File Import</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level"><font color="#993300"><strong>WARN</strong></font></td>
<td>Log4JRepositoryImportLogger.java:181</td>
<td title="Message">Public</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:47</td>
<td title="Message">End Import Job</td>
</tr>
</table>
<br>
</body></html>

Na minha contagem, o processo soltou exatas 63636 linhas, incluindo o cabeçalho com mensagens sobre o Java no início – e era um repositório mínimo. :-O

Vamos verificar o resultado? Eis o estado do repositório do servidor de destino antes da importação do backup:

Servidor de destino antes da restauração.
Servidor de destino antes da restauração.

Após fazer a importação usando o import-export.sh temos:

Servidor de destino após a restauração.
Servidor de destino após a restauração.

Observe que não aparece nenhuma das pastas de usuário do servidor de origem, que nós sabemos que existiam no arquivo ZIP, e continuam existindo as pastas que já existiam no destino, ou seja, não foram apagadas.


Volto a frisar: teste o processo algumas vezes para evitar surpresas. Neste exemplo migramos pastas vazias, mas de usuários que não existiam no destino. E se elas não estivessem vazias na origem? Eu fiz o teste: arquivos de diretórios de usuários que não existem no destino, não são importados. Isso é muito importante: arquivos que vêm de diretórios de usuários, na origem, que não existem no destino, são perdidos!! Para funcionar, o usuário precisa existir no destino!


Como Funciona?

É bem simples, na verdade: a Pentaho construiu um programa, import-export.sh (Linux e MacOS) ou import-export.bat (Windows), que chama um “processo” (classe? método?) diretamente no código do servidor. Eis o conteúdo da versão Linux/MacOS (observe a última linha do bloco a seguir:)

#!/bin/sh
DIR_REL=`dirname $0`
cd $DIR_REL
DIR=`pwd`
#cd -
 
. "$DIR/set-pentaho-env.sh"
setPentahoEnv
 
# uses Java 6 classpath wildcards
# quotes required around classpath to prevent shell expansion
"$_PENTAHO_JAVA" -Xmx2048m -XX:MaxPermSize=256m -classpath "$DIR/tomcat/webapps/pentaho/WEB-INF/lib/*" org.pentaho.platform.plugin.services.importexport.CommandLineProcessor ${1+"$@"}

Esse programa possui várias opções e parâmetros. Para ver a lista completa de opções, basta rodar o comando sem nenhum switch:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$ ./import-export.sh
 
(... mensagens de erro por falta de parâmetros ...)
 
usage: importexport
Unified repository command line import/export tool
 -a,--url <arg>                      url of repository (e.g.
                                     http://localhost:8080/pentaho)
 -a_ds,--analysis-datasource <arg>   Analysis datasource description
 -a_xmla,--xmla-enabled <arg>        Analysis XMLA enabled flag
 -c,--charset <arg>                  charset to use for the repository
                                     (characters from external systems
                                     converted to this charset)
 -cat,--catalog <arg>                catalog description
 -ds,--datasource-type <arg>         datasource type
 -e,--export                         export
 -f,--path <arg>                     repository path to which to add
                                     imported files, or to export from
                                     (e.g. /public)
 -fp,--file-path <arg>               Path to directory of files for
                                     import, or path to .zip file for
                                     export
 -h,--help                           print this message
 -i,--import                         import
 -l,--logfile <arg>                  full path and filename of logfile
                                     messages
 -m,--permission <arg>               apply ACL manifest permissions to
                                     files and folders  (import only)
 -m_id,--metadata-domain-id <arg>    Metadata domain ID
 -o,--overwrite <arg>                overwrite files (import only)
 -p,--password <arg>                 repository password
 -params,--params <arg>              parameters to pass to REST service
                                     call
 -r,--retainOwnership <arg>          Retain ownership information  (import
                                     only)
 -res,--resource-type <arg>          Import/Export resource type
 -rest,--rest                        Use the REST (Default) version (not
                                     local to BI Server)
 -u,--username <arg>                 repository username
 -v,--service <arg>                  this is the REST service call e.g.
                                     acl, children, properties
 -w,--withManifest <arg>             Export Manifest ACL file included
                                     (export only)
Common options for import & export using REST ServicesExample arguments
for import:
--import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/public
--file-path=c:/temp/steel-wheels
--logfile=c:/temp/logfile.log
--permission=true
" + "--overwrite=true
--retainOwnership=true
Example arguments for export:
--export --url=http://localhost:8080/pentaho --username=admin
--password=password
--file-path=c:/temp/export.zip --charset=UTF-8 --path=/public
--withManifest=true--logfile=c:/temp/logfile.log
Example arguments for running REST services:
--rest --url=http://localhost:8080/pentaho --username=admin
--password=password
-path=/public/pentaho-solutions/steel-wheels/reports
--logfile=c:/temp/logfile.log --service=acl
 
(... Erros por falta de parâmetro ...)
 
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$

Então, por exemplo, para exportar apenas o diretório do usuário Joe, usando para isso o usuário admin, que possui todas as permissões de acesso, o comando fica:

./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/PastaDoJoe.zip
--charset=UTF-8 --path=/home/Joe --withManifest=true --logfile=/tmp/logfile_export.log

Note que não exportamos simplesmente “Joe”, mas sim “/home/Joe”. Isso porque a pasta do Joe existe dentro de uma outra subpasta, como você pode observar ao notar o atributo Source nesta figura:

Pasta do Joe no diretório /home.
Pasta do Joe no diretório /home.

E é por isso que usamos --path=/ para exportar/importar o repositório inteiro: / é a raiz de tudo.

O processo de importação segue as mesmas regras, só que no sentido inverso: levando o conteúdo exportado para dentro de um repositório.

Não deixe de consultar o Pentaho Infocenter (ou Pentaho Help) para aprender mais sobre isso:

Curiosamente, a página do BA Server 6 fala que o procedimento exporta tudo, incluindo usuários e permissões, mas não consegui encontrar essa informação no arquivo ZIP. O exportManifest.xml, que registra a lista de pastas e arquivos, e seus respectivos donos e permissões, não mostra nada. E só para tirar a cisma, tentei importar no 6 o repositório do 5, mas o seis não registrou nenhum dos usuários que eu criei no cinco. Pode ser que essas páginas estejam se referindo a alguma ferramenta que vai junto da versão Enterprise (paga), indisponível na Community.

Conclusão

Vimos como usar o programa import-export.sh/bat para exportar o repositório de arquivos de um servidor Pentaho e importar em outro. Depois da substituição do mecanismo de repositório que existia até a versão 4.8, esse método é a única forma de fazer a migração entre dois servidores – uma tarefa necessária quando se instala uma nova versão do Pentaho BA Server e queremos levar tudo que nossos usuários já fizeram.

Mostrei um exercício simples, “migrando” o repositório entre duas instâncias da versão 5.4, para que você possa estudar o processo livre de problemas paralelos. Você pode usar o que aprendeu para experimentar uma migração real, levando os arquivos de uma versão 5.x para a 6.x, por exemplo.

Além disso, ainda é preciso levar os usuários e seus papéis, e todas as conexões de dados, metamodelos e esquemas OLAP. Mesmo assim a nova tecnologia Jackrabbit é mais prática (em especial para a versão CE) que o antigo formato, tosco pra dedéu, de filesystem + banco de dados.

Feliz migrações! ;-)

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s