Ontem (dia 09/01) fizemos o lançamento de um site que desenvolvemos usando Groovy e Grails, um desafio e tanto, pela responsabilidade de colocar o sistema no ar e pelo timing do projeto. Todo o site e a integração com o sistema legado (onde algumas informações ainda estão sendo gerenciadas), tiveram que sair do simples “create app” para produção em 2 meses. Esse é também o grande motivo para a falta de tempo de postar mais por aqui.

Trata-se dos sites http://www.imoveisnomorumbi.com.br e http://www.imoveisnopanamby.com.br, site de duas imobiliárias do mesmo grupo, que negocia imóveis de alto padrão nestes dois bairros.

Algumas informações interessantes sobre o projeto:

Tecnologia e Infraestrutura: O site antigo usava SQLServer como banco de dados e tecnologia ASP. Como usamos Groovy e Grails, por trás temos uma JVM Java em execução, e o banco de dados, o bom e velho MySQL.

Antes, para suportar o ASP, o IIS era usado como web server, e agora Um apache balanceia as requisições aos dois Tomcats. Tudo isto está deployado e rodando em um Cloud Server da Locaweb, por opção do cliente, onde já mantinha a conta antiga.

Integração com o sistema legado: Para a integração do modelo de dados antigo e o novo modelo, construímos rotinas de importação dos dados usando Groovy SQL, uma maneira  fácil, muito fácil, de fazer rotinas em banco de dados.

Plugins utilizados: Ahhh, os bons e velhos plugins do Grails, não canso de dizer que esta é a melhor parte do Grails! Foram usados os plugins:

Grails-Mail, para envio dos e-mails e formas de contato do site
Grails-Acegi, para autenticação e segurança
Grails-Cookie, para manipulação dos cookies do cliente
Grails-Navigation para criação de menus/submenus da interface administrativa
Grails-RichUi para alguns componentes gráficos como auto-complete e nuvem de tags
Grails-RuntimeLogging, um ótimo plugin para moder trabalhar com o nível de log de cada artefato (controller, service, etc), da app em runtime
Grails-Settings para algumas parametrizações da aplicação.

E com certeza, se eu tivesse pesquisado com um pouco mais de tempo, teria usado outros plugins para evitar algum trabalho que tenha feito na mão. E é claro, além disso, bastante (mesmo) jquery, ajax e json.

É isso, qualquer dúvida sobre o projeto, como aconteceu, soluções e problemas, basta comentar!

Obrigado a todos!

Pra quem acompanha a lista de discussões e o andamento do projeto, o Solr 1.4 já está prontinho para ser lançado tem algum tempo. O pessoal de dev estava apenas esperando o lançamento do Lucene 2.9 para oficializar o lançamento.

Quando então foi lançado, o pessoal do Solr empacotou o framework como RC, disponibilizou para download e na hora do lançamento (pra ser mais preciso, um dia antes), dois bugs significativos foram levantados no Lucene 2.9. A equipe do Solr os avaliou com calma, entrou em alinhamento com os devs do Lucene (alguns fazem parte de ambas as equipes) e decidiram por bem aguardar o Lucene 2.9.1 para efetuar o anúncio oficial do Solr 1.4.

Pois bem, com o lançamento oficial do Lucene 2.9.1 hoje a tarde, o pessoal do Solr já correu, e empacotou em uma versão final a release tão esperada, 1.4.

Amanhã, dia 07, será feito o lançamento final do Solr 1.4 sem mais delongas. Pois bem, é só aguardar! Mas se você quiser dar uma olhadinha antes, é só baixar os pacotes antes de serem replicados para o mirror central entrando aqui: http://people.apache.org/~gsingers/solr/1.4.0/.

Eu, em uma olhada muito, mas muito rápida por cima de algumas funcionalidades do Solr 1.4 (direto no wiki), levantei alguns pontos e encaminhei na lista de e-mails dos colaboradores da empresa em que trabalho. Não estão agrupados, muito menos organizados, mas segue como esboço e rascunho de um post que valeria a pena.

• SolrServer – SolrJ HTTP
  • Configuração
    • Timeout
    • Quantidade de retentativas
  • SolrJ altamente evoluído para criação da queries e integrado aos searchcomponents
• DataImportHandler
  • Transformers
    • Clob Transformer: Permite pegar dados direto de colunas clob no banco de dados
    • HTML Stripper: Atua em campos com conteúdo HTML, removendo tags e deixando apenas o conteúdo
  • Agora é possível usar o DIH indexando até conteúdos de um ‘datasource’ de e-mail, deixando ele fazer pooling em um e-mail e indexando o que chega.
  • Eventos callback após indexação
• Replicação
  • Configuração interna a aplicação – Funciona como um RequestHandler
  • Dashboard de administração, permite ver como estão as replicações, qual indice está em cada nó, status do download de novos indices
  • Permite replicação interna, via HTTP, não sendo mais necessário usar apenas rsync
    • Com isso, possibilidade de usar em windows
    • Menos configuração de infra estrutura
    • Maior visibilidade do status da replicação
• Indexação
  • indexação de grandes quantidades de documentos via streaming
    • conexão é aberta com o master, e permanece assim enquanto necessário.
  • Anotação @Field para poder adicionar um POJO direto ao índice, sem ter que transformar em SolrInputDocument
• Componentes de busca (alguns presentes no 1.3 completos, outros eram beta, outros nem existiam)
  • Sugestão de busca
  • Spelling
  • Highlight
• Resposta da busca em vários novos formatos
  • php nativo
  • json (já existia mas não era oficial)
  • xml (normal)
  • ruby

E muito mais…

Solr é um framework uma ferramenta para a construção de servidores de indexação e busca on top of índices lucene.

Possui todas as funcionalidades que existem em um sistema moderno de busca, como paginação, highlight de campos, flexão das palavras e etc. Na minha opinião, de tudo que trabalhei nos últimos anos, sem dúvida, formam o conjunto mais poderoso de frameworks.

O Solr abstrai a camada Java do Lucene e disponibiliza uma interface http para a execução da consulta, fazendo com que fique muito fácil a integração com sistemas não-java.

Um dos recursos avançados de indexação com Solr são os Transformers a serem usados juntamente com o DataImportHandler. Com eles, você pode processar o texto antes de ser indexado. (Um outro post sobre configuração básica de Solr e de DIH deve vir em breve).

Semana passada, precisei de um transformer que pudesse retirar todas as tags HTML do texto a ser indexado (malditos editores rich text em javascript). Como o projeto aqui está usando Solr 1.3 não tive a possibilidade de usar o HTMLStripTransformer que virá no Solr 1.4 (e está enroscado pra sair). Então acabei tendo que criar um semelhante para a funcionalidade.

A criação de transformers é muito simples (imho, simplista até demais, fazendo com que as vezes, o desenvolvedor se perca durante a implementação). Deve ser desenvolvida uma classe simples, que implementa um método com a seguinte assinatura:

public Map<String, Object> transformRow(Map<String, Object> aRow, Context context)

Quando disse que é simplista demais, é pelo fato de que, (imho novamente), condições restritivas como esta deveriam estar documentadas em interfaces, mas não, quando necessário, o método é chamado via reflection, tendo certeza que ele está implementado.

No meu caso, eu precisaria além de implementar o Transformer, deixar explícito no arquivo de configuração do DIH (data-config.xml) quais os campos que deveriam receber o tratamento desta tag, fiz isso adicionando a tag removeHtml no nó de cada campo (não, este xml não passa por validação).

<field name="txt" column="texto" removeHtml="true" />

Com isto, estamos deixando claro para o DIH que o valor que retornar da query na coluna texto será repassado ao Solr para indexação no field txt (definido no schema.xml) e terá processamento do meu HtmlTransformer. Ah, não podemos esquecer da declaração do transformer para a entidade:

<entity name="posts" transformer="br.com.lucastex.dih.transformer.HtmlTransformer" />

Pronto, a classe está agora carregada e pronta para ser chamada quando um campo necessitar. Agora, vamos a implementação da classse. No meu caso, ela ficou bem trivial, pois o campo em questão nunca será multivalorado (ou seja, não preciso tratar a possibilidade do argumento ser um List, mas apenas uma String.

package br.com.lucastex.dih.transformer;

import java.util.Map;

import org.apache.commons.lang.StringEscapeUtils;
import org.apache.solr.handler.dataimport.Context;
import org.apache.solr.handler.dataimport.DataImporter;
import org.apache.solr.handler.dataimport.RegexTransformer;
import org.apache.solr.handler.dataimport.Transformer;

public class HtmlTransformer extends Transformer {

  public static final String TAG = "removeHtml";

  public Map<String, Object> transformRow(Map<String, Object> aRow, Context context) {

    for (Map<String, String> map : context.getAllEntityFields()) {
      if (!Boolean.TRUE.toString().equals(map.get(TAG)))
        continue;
      String columnName = map.get(DataImporter.COLUMN);
      String sourceColumnName = map.get(RegexTransformer.SRC_COL_NAME);
      if (sourceColumnName == null)
        sourceColumnName = columnName;
      Object value = aRow.get(sourceColumnName);
      if (value instanceof String) {
        String result = stripHtml((String) value);
        aRow.put(columnName, result);
      }
    }
    return aRow;
  }

  private String stripHtml(String text) {
    try {
      String cleanText = StringEscapeUtils.unescapeHtml(text.replaceAll("\\<.*?\\>", " "));
      cleanText = cleanText.trim().replaceAll("\n"," ");
      cleanText = cleanText.replaceAll("\t"," ");
      cleanText = cleanText.replaceAll("[\\s]+", " ");
      return cleanText;
    } catch (Exception e) {
      //trata exception de acordo com seu contexto solr
    }
    return text;
  }
}

Bom, o código é bem auto-explicativo. Basicamente recebe o além do contexto em execução do Solr/DIH, um Map de String e Object, que contém todos os campos e valores da linha que está sendo analisada/indexada no momento. Vale lembrar que este modelo de passagem de parâmetro é feito exatamente como descrito no Pattern BCDR.

Enfim, as linhas 18 e 19 garantem que o código só será executado para campos que tenham declarado a tag removeHtml=true como descrito anteriormente.

A linha 24 recupera o valor original do campo, ou seja, o que foi retornado pela query no banco de dados, e nas linhas 26 e 27 o resultado é tratado (através da chamada para o método stripHtml) e devolvida ao Map.

Ou seja, este é o momento onde você tem acesso a todos os campos que estão vindo do banco antes de irem ao índice. É nesta hora que você duplica seus campos, faz tratamentos, aplica padrões e templates, enfim trabalha a informação bruta original do banco de dados.

Já o método de remoção de tags HTML, não é nada além de um conjunto de regexes encadeadas  com uma ajudinha do StringEscapeUtils (que saudade deste post) do Commons-lang.

Simples como