|
|
| Data de elaboração |
19/01/2026 |
| Responsável pelo estudo |
João Marcos Sales Oliveira (UX/DEV) |
| Equipe do estudo |
João Marcos Sales Oliveira (UX/DEV)
Mayron Vinícius Souza Linhares (PO) |
| Alvo |
Portal do Diário Oficial de Rondônia (DIOF) |
| Origem |
Objetivo Estratégico: Transformar o Diário Oficial em uma ferramenta de consulta ativa, modernizando a experiência de busca e agilizando a localização precisa dos atos oficiais publicados.
- Contexto: A interface atual restringe a busca apenas à seleção de datas.
- Escopo: Mapeamento de mecanismos e ferramentas que permitam a consulta textual nos diários publicados no portal atual. |
| Objetivo |
Apresentar opções viáveis de ferramentas de busca e indexação, comparando prazos e complexidade técnica para subsidiar a decisão da gestão. |
| Documentação correlata |
1. Yoast SEO: XML Sitemaps
2. Google Developers: Arquivos indexáveis (PDF) |
| Observações |
Este estudo foca em soluções aplicáveis ao portal atual. A possibilidade de reescrita completa da plataforma é citada como visão estratégica de futuro. |
A análise da página inicial atual do Portal do DIOF revela uma limitação crítica de usabilidade: o sistema não oferece busca por conteúdo, apenas um filtro por data.
Os arquivos são listados apenas com a etiqueta da data, sem metadados descritivos. Isso gera um cenário de «busca às cegas»:
- Fluxo Manual: O cidadão precisa baixar o PDF, abrir e pesquisar termo a termo (
Ctrl+F).
- Volume Massivo: Com 10.211 arquivos e estimativa de 4.000.000 de páginas, a recuperação manual da informação é inviável.
- Necessidade: Implementar uma ferramenta capaz de indexar o interior dos arquivos para recuperação da informação.
Foram mapeadas três abordagens técnicas para habilitar a busca textual, classificadas por complexidade de implementação.
Manter a estrutura atual e utilizar plugin de mercado para otimizar a leitura pelo Google.
- Capacidade Técnica: A Google confirma oficialmente que seu motor de busca é capaz de indexar o conteúdo textual de arquivos PDF. Isso valida tecnicamente o uso do buscador externo para ler o acervo do DIOF.
- Funcionamento: Instalação do plugin Yoast SEO para gerar Sitemaps XML específicos para os arquivos PDF. O Googlebot lê esses mapas e indexa o conteúdo dos arquivos automaticamente.
- Veredito: Solução de Curto Prazo.
- Prós: Custo Zero de licenciamento, implementação célere (< 2 semanas) e não exige desenvolvimento de código customizado.
- Contras: A experiência do usuário é fragmentada (o link direciona para a capa do PDF, exigindo nova busca interna) e existe latência na atualização dos dados (não ocorre em tempo real).
Manter a estrutura atual, adicionando um serviço dedicado de busca (On-Premise).
- Funcionamento: Uma Máquina Virtual (VM) Linux com Elasticsearch processa os PDFs no momento do upload (via plugin ElasticPress + Ingest Attachment) e cria um índice de busca local.
- Veredito: Solução de Médio Prazo (Melhor Custo-Benefício).
- Prós: Aproveita o portal existente, oferece busca em tempo real (instantânea) e destaca o trecho encontrado (Snippet), elevando a transparência.
- Contras: Exige esforço de configuração de servidor e integração de plugins no ambiente legado.
Desenvolvimento de novo portal integrado ao ecossistema de publicação (PPE/GovDoc/SEI).
- Conceito: Desenvolvimento de um novo portal utilizando tecnologias modernas (C# / .NET), visando a integração nativa com o ecossistema de sistemas do Estado (PPE, GovDoc, SEI).
- Visão Estratégica: Esta alternativa representa uma modernização completa da arquitetura, eliminando a dependência de CMS de terceiros (WordPress) e permitindo maior controle sobre o fluxo de dados e segurança.
- Necessidade de Estudo Específico: Devido à complexidade da arquitetura de armazenamento de documentos (que envolve orquestração entre IDs do PPE e repositórios externos como GovDoc), esta opção não pode ser tratada apenas como uma «feature de busca». Ela exige um Estudo de Arquitetura de Software dedicado para mapear as integrações necessárias.
- Veredito: Visão de Futuro (Longo Prazo).
- Prós: Arquitetura limpa, performance otimizada e soberania tecnológica.
- Contras: Alto custo de desenvolvimento e complexidade de integração com sistemas legados.
Comparativo para apoiar a decisão sobre qual ferramenta adotar.
| Critério |
A: Google (Yoast) |
B: WP + Elastic |
C: Novo Portal (.NET) |
| Qualidade da Busca |
⭐️ Básica |
⭐️⭐️⭐️ Excelente |
⭐️⭐️⭐️ Excelente |
| Tempo de Entrega |
🚀 Curto (2 Sprints) |
📅 Médio (5 Sprints) |
🐢 A Definir (Depende de Estudo) |
| Origem dos Dados |
Leitura de PDF (Google) |
Leitura de PDF (Tika) |
Integração Complexa |
| Complexidade |
Baixa (Configuração) |
Média (Infraestrutura) |
Altíssima (Arquitetura) |
| Infraestrutura |
Zero |
1 VM Linux |
Servidores Windows/Linux |
| Status |
Viável Imediatamente |
Viável Imediatamente |
Requer Estudo Próprio |
As estimativas abaixo consideram ciclos de Sprints de 10 dias úteis.
- Sprint 1: Instalação de Plugin Yoast SEO, configuração de Sitemaps e ajustes de permissão de leitura.
- Sprint 2: Validação da propriedade no Google Search Console, submissão do índice e monitoramento da propagação.
- Sprint 1: Configuração de Infraestrutura (Docker) e VM Linux.
- Sprint 2: Instalação do Elasticsearch e Plugin Ingest Attachment.
- Sprint 3: Integração Backend (ElasticPress) e Sincronização.
- Sprint 4: Processamento do Legado (Indexação em massa).
- Sprint 5: Implementação do Frontend de Busca e Homologação.
- Estimativa: A definir (Necessita de Estudo Prévio).
- Justificativa: Diferente das outras opções, esta alternativa envolve a integração com múltiplos sistemas legados (PPE, GovDoc, SEI). Não é possível estimar um prazo de desenvolvimento seguro sem antes realizar uma fase de Discovery Técnico e mapeamento de APIs/Banco de Dados. Recomenda-se a abertura de um estudo arquitetural específico para mensurar o esforço desta iniciativa.
Considerando que este estudo visa apresentar ferramentas para viabilizar a consulta textual no portal existente, as recomendações são:
- Ação Imediata (Opção A): Instalar o Yoast SEO (2 Sprints). Esta medida de baixo esforço garante que os documentos sejam descobertos pelos mecanismos de busca públicos, mitigando a invisibilidade atual do acervo.
- Evolução Recomendada (Opção B): Para uma experiência de busca profissional e em tempo real, a adoção do Elasticsearch (5 Sprints) é o caminho técnico mais robusto e viável dentro da arquitetura atual.
- Visão de Futuro (Opção C): A construção do Novo Portal em C# é reconhecida como a evolução natural da plataforma. Recomenda-se que seja tratada em um projeto estratégico de Modernização Tecnológica, iniciando-se por um estudo arquitetural específico, não sendo a via recomendada para solucionar o problema imediato da busca textual.
A tabela a seguir apresenta as versões do estudo, com datas de criação e atualização:
|
|
|
|
| Versão |
Data da Criação |
Data da Atualização |
Notas da Versão |
| 2 |
19/01/2026 |
21/01/2026 |
Ajuste de Escopo e Título.
Alterações:
• Mudança de título para «Estudo Técnico: Opções e Ferramentas para Consulta Textual»;
• Posicionamento da Opção C (Novo Portal) como Visão Estratégica de Futuro (Longo Prazo), demandando estudo arquitetural próprio para estimativa de cronograma;
• Foco nas ferramentas aplicáveis ao portal atual (Google e Elasticsearch). |
| 1 |
19/01/2026 |
19/01/2026 |
Elaboração inicial focada em solução On-Premise. |