Muitas implementações de soluções de gestão de conteúdo envolvem a migração de grandes quantidades de documentos de sistemas legados para o novo repositório. Neste post iremos analisar algumas opções e estratégias de migração que podem ser usadas, além de conhecer alguns fatores que podem impactar na performance.
OBS: O objetivo deste post não é ser um material completo sobre importação, uma vez que este assunto envolve diversos fatores. O processo de migração deve ser feito por especialistas, sempre seguindo as orientações da documentação. O Suporte Oracle também pode ser acionado em caso de dúvidas.
Extração do Legado
O grande desafio é realmente extrair os documentos dos repositórios legados, uma vez que a maioria é baseada em tecnologias antigas, e não oferecem muitas opções de integração, como java ou web services. A dica aqui é exportar os documentos para uma estrutura de pastas, e os metadados (atributos) para uma planilha Excel. Outra opção mais avançada é o desenvolvimento de uma aplicação que extrai os documentos do legado, ao mesmo tempo em que importa os documentos para o Content. Isso funciona melhor com menores volumes, mas para milhões e milhões de documentos, pode ser um caminho mais lento e sujeito à erros.
Preparando o ambiente para importação
O Content vem configurado out-of-the-box para funcionar em diferentes cenários, o que significa que ele não está nativamente otimizado para um cenário de importação em massa. Por isso, é recomendável fazer as seguintes configurações:
- Aumentar o tamanho da heap da JVM. Isso pode ser feito pelo Weblogic Console, seguindo a documentação. Um valor de 2GB é o ideal. Também é importante definir o mínimo e máximo com o mesmo valor (2048m), por motivos de performance.
- Caso não seja necessário converter para PDF, iniciar um workflow, e indexar full-text, o Fast CheckIn passa a ser um recurso altamente recomendável: com ele, o tempo de inserção é praticamente instantâneo! Porém, o documento só poderá ser buscado através dos metadados (conforme eu descrevi em um post anterior).
- Caso exista a necessidade de gerar o thumbnail, mas não a conversão para PDF, o Inbound Refinery não precisa ser usado; a partir da versão 11.1.1.6, o próprio Content Server pode gerar os thumbnails, sem a necessidade de enviar o arquivo para o IBR. Esta configuração pode ser feita no menu Administration –> Configure Thumbnail Options
OBS: Lembre-se que esta operação irá passar a onerar o Content Server, portanto o dimensionamento do ambiente deverá ser feito de acordo, para acomodar esta nova demanda.
- Normalmente, os arquivos importados precisam de conversão e indexação, portanto o cenário de importação que iremos trabalhar será dividido em 3 etapas: Carga, Conversão e Indexação.
A recomendação é separar as etapas, ou seja, enquanto o BatchLoader estiver sendo executado, os servidores de Inbound Refinery devem ficar desabilitados (fora do ar), e o Auto-Indexer do Content (no applet Repository Manager, aba Indexer) deve ficar desabilitado:
Desta forma, podemos garantir que não haverá contenção no banco de dados, e que cada atividade tem todos os recursos à disposição. OBS: Não é mandatório separar as camadas desta forma, e para uma importação pequena (dezenas de milhares ou centenas de milhares), a importação, conversão e indexação podem ser feitas em paralelo. Mas quando estamos falando em milhões, é melhor separar as etapas.
- Carga:
Nesta etapa, os documentos serão armazenados no repositório. A ferramenta padrão para esta atividade é o BatchLoader. Esta ferramenta trabalha com um arquivo texto de importação, que lista todos os arquivos que devem ser importados, e os atributos de cada um. O segredo aqui é usar um Excel como base para os atributos, porque com uma macro simples é possível gerar o arquivo de saída no formado do BatchLoader. Se você quiser um arquivo de exemplo com a macro, deixe um comentário!
Recomendações:
- Tire os servidores de IBR do ar e desabilite o Auto-Index antes de iniciar a importação.
- Caso você tenha um cluster de WebCenter Content (o que é sempre recomendado 
, divida a carga entre os nós do cluster. Ou seja, ao invés de importar 200.000 documentos no primeiro nó, importe 100.000 em cada nó do cluster, ao mesmo tempo. Isso vai otimizar bastante o processo de importação.
- Separe a carga em arquivos de batch. Cada arquivo deverá ter entre 10.000 e 15.000 documentos. Porém, é possível executar vários arquivos de batch na sequência, para que tenhamos 100.000, 200.000, 300.000 importações por vez.
Após terminar a importação, podemos fazer uma query no banco de dados para acompanhar o status do nosso processo:
select DSTATUS, count(DSTATUS) from REVISIONS group by DSTATUS;
GENWWW 100.000
DONE 0
RELEASED 1.549.327
GenWWW são os documentos que acabaram de ser importados, e agora precisam ser convertidos. Após convertidos, os documentos mudarão o status para Done. Finalmente, quando terminarem de ser indexados e estiverem prontos para serem utilizados, ganharão o status Released.
OBS: Naturalmente o status DONE não vai aparecer no resultado da query se estiver com valor zero. Eu adicionei a informação apenas para esclarecimento.
- Conversão:
A primeira dica é ter mais de uma instância de Inbound Refinery, preferencialmente em servidores físicos separados. O IBR não trabalha em cluster, portanto a configuração é muito simples, e você pode descontinuar os IBRs extras uma vez que a sua importação tenha terminado. 4 instâncias é um número bom para grandes importações. Basta registrar todas as instâncias como Providers no WebCenter Content, e ele distribui a carga automaticamente.
Uma vez que as importações terminaram, vamos ter algumas centenas de milhares de arquivos na fila de conversão (status GenWWW). A configuração out-of-the-box do WebCenter Content não prevê uma fila de conversão deste tamanho, portanto vamos ter que inserir um parâmetro de configuração no config.cfg do WebCenter Content, que vai definir como ele controla a fila de indexação:
- RefineryJobExpirationTime: define por quanto tempo um documento vai ficar na fila de conversão até expirar. O tempo padrão são 4 horas (14400 segundos). Vamos modificar este valor para 86400 (24 horas). Portanto, o parâmetro fica:
RefineryJobExpirationTime=86400
Antes de reiniciar o Content, vá no menu Administration –> System Audit Information. Na seção Tracing Sections, defina o tracing para ibrsupport. Desta forma poderemos ver se o parâmetro foi corretamente configurado:
Após reiniciar o Content vá no menu Administration –> System Audit Information e clique no link View Server Output. Aqui vemos como ficaram os parâmetros:
OBS: No config.cfg, o parâmetro é definido em segundos (86400), mas no output do sistema ele é representado em milissegundos (86400000).
Inicie os IBRs. Você pode acompanhar a evolução da conversão pela Web, na aba Items In Queue do IBR:
Ou pelo banco de dados, com estas queries:
select DSTATUS, count(DSTATUS) from REVISIONS group by DSTATUS;
(monitore a quantidade de GENWWW), e
select count(*) from refineryjobs;
Quando o número de GenWWW chegar à zero, podemos iniciar a Indexação. O resultado da query fica:
GENWWW 0
DONE 100.000
RELEASED 1.549.327
- Indexação:
Se o seu banco de dados estiver com uma capacidade de processamento boa, você pode fazer a indexação ao mesmo tempo em que faz as conversões. Porém, ambos os processos utilizam pesadamente o banco de dados, portanto em sistemas com menos recursos, é interessante separar os processos.
Para iniciar a indexação, basta habilitar o auto-indexador no applet do Repository Manager. Você vai perceber que o processo iniciará em alguns momentos.
Uma vez que tudo estiver terminado, você pode iniciar o próximo lote.
Vale a pena testar estas quantidades para chegar no volume ideal para o seu ambiente: você pode importar muito mais do que 100.000 durante o dia, e deixar a conversão e a indexação rodando à noite, para importar mais no dia seguinte.
Até a próxima!
