| Data de elaboração |
15/07/2026
|
| Responsável pelo estudo |
Moisés
|
| Equipe do estudo |
Caveiras
|
| Alvo |
Novo Portal do DIOF
|
| Origem |
O portal institucional atual do DIOF encontra-se implementado em WordPress, o que atende publicação institucional básica, porém apresenta limitações para evolução de serviços digitais, integração com sistemas corporativos e escalabilidade.
|
| Objetivo |
Propor técnica e operacionalmente a implementação de um novo Portal do DIOF, com ingestão e publicação de edições (HTML/PDF), navegação por sumário e busca textual eficiente sobre o acervo.
|
| Observações |
Este documento sintetiza arquitetura, tecnologias, riscos e plano de implantação. Estimativas formais (sprints/esforço) dependem do escopo final, integrações e infraestrutura alvo.
|
- Edição: conjunto de publicações do DIOF em uma data, podendo haver código/numeração (ex.: 22, 22.1, 22.2).
- Sumário: estrutura navegável extraída do HTML para orientar a leitura (Poder → Atos → Secretarias/Órgãos).
- Secretaria/Órgão: agrupador de publicações, identificado por um item de cabeçalho no HTML.
- Publicação: bloco de conteúdo no HTML (ex.:
<div class="publicacao">), associado a uma secretaria e identificado por âncora.
- Protocolo: identificador de uma publicação (preferencialmente extraído de
p.protocolo).
- Âncora (AnchorId):
id presente no HTML para deep-linking e navegação (#...).
- Indexação: processo de ler o HTML, extrair estrutura e texto, persistir no banco e preparar busca.
- FTS (Full-Text Search): mecanismo nativo do SQL Server para busca textual.
- RedisSearch (RediSearch): motor de busca em Redis Stack para indexação e consulta textual.
- Job: processamento assíncrono em background (ex.: Hangfire).
A proposta do novo Portal do DIOF visa modernizar a plataforma de publicação e consulta do diário oficial, garantindo:
- Publicação e consulta de edições em HTML/PDF.
- Navegação por sumário hierárquico (itens do próprio documento).
- Busca textual rápida com resultados navegáveis (abrir diretamente a publicação/trecho).
- Maior autonomia tecnológica para evoluções (integrações, novos serviços, expansão do acervo).
A solução proposta adota uma arquitetura modular, permitindo selecionar o mecanismo de busca textual mais adequado ao contexto institucional (SQL Server Full-Text Search ou RedisSearch/RediSearch), mantendo o restante do domínio (ingestão, indexação do HTML, navegação por sumário e leitura) estável.
A solução é uma aplicação Web/API baseada em stack Microsoft, composta por:
- Backend (ASP.NET Core / Minimal APIs)
- Endpoints de ingestão, indexação, leitura, catálogo e busca.
- UI (Blazor Web App – Interactive Server)
- Navegação por edição, sumário, filtros e abertura de publicações.
- Persistência (SQL Server + Entity Framework Core)
- Metadados da edição, estrutura do sumário/secretarias, publicações e índice textual.
- Indexação de HTML (AngleSharp)
- Parse do HTML e extração estruturada.
- Processamento assíncrono (Hangfire)
- Jobs para indexação e reindexações em background.
- .NET 10
- ASP.NET Core Minimal APIs
- Blazor Web App (Interactive Server)
- Entity Framework Core + SQL Server
- Busca textual (uma das opções abaixo)
- SQL Server Full-Text Search
- Redis Stack / RediSearch
- AngleSharp (parsing HTML)
- Hangfire (jobs em background, com dashboard)
Entidades principais:
- Edicao
- Data de publicação, código/número, status (rascunho/publicada), timestamps.
- ArquivoEdicao
- Referência ao HTML/PDF e metadados (etag/hash) para controle de mudanças.
- SumarioItem
- Itens (Poder/Atos/Secretaria) com título, âncora e ordem.
- Secretaria
- Nome/sigla, âncora e ordem.
- Publicacao
- Secretaria, protocolo, âncora, timestamps.
- PublicacaoIndice
- Texto normalizado da publicação para busca.
Regra importante:
- Unicidade de protocolo por edição: (EdicaoId, Protocolo)
Recomendações para o HTML gerado:
- Itens de sumário devem ter
id estável e classes identificáveis.
- Secretarias/órgãos devem ser marcadas por cabeçalhos (
h2) com classes específicas.
- Publicações devem ser blocos (
div.publicacao) com id (âncora) e, preferencialmente, protocolo explícito (p.protocolo).
Estratégia de interpretação:
- Ao percorrer o documento em ordem, a “secretaria atual” é atualizada quando se encontra o cabeçalho de secretaria.
- Cada publicação encontrada é vinculada à secretaria atual.
- Recebe dados da edição e referências para HTML/PDF.
- Possui idempotência para evitar duplicidade em caso de retry.
- Detecta alteração de conteúdo (etag/hash) e marca necessidade de reindexação.
Ponto crítico: URLs expiráveis
- Recomendação: baixar o conteúdo na ingestão e persistir em armazenamento interno do portal (storage) para garantir disponibilidade e reprodutibilidade.
Objetivo:
- Extrair e persistir:
- sumário (estrutura),
- secretarias,
- publicações,
- texto de cada publicação.
Tratamento de exceções previsto:
- Quando houver duplicidade de protocolo na mesma edição, deve ser aplicado ajuste determinístico (ex.: sufixo
-2, -3) para garantir unicidade sem falhar a indexação.
- Edição só entra no catálogo público após indexação.
- Publicação controla o que é visível e buscável.
- UI exibe sumário hierárquico.
- Ao selecionar um item (secretaria/ato), renderiza o trecho correspondente do HTML.
- Resultado de busca abre o bloco exato (âncora) da publicação.
O portal deve suportar busca textual sobre o acervo (por publicação), com duas opções equivalentes de implementação, a serem escolhidas conforme o contexto de infraestrutura, operação e requisitos de busca:
- SQL Server Full-Text Search
- Redis Stack / RediSearch
As duas abordagens podem ser implementadas de forma intercambiável desde que o contrato do serviço de busca (entrada/saída) permaneça estável.
Pontos positivos
- Integração direta com o banco de dados transacional (menos componentes na infraestrutura).
- Operação centralizada em um único stack (SQL Server).
- Implementação simples quando os dados indexados já residem no SQL Server.
Pontos negativos / limitações
- Requer recursos e habilitação do Full-Text no SQL Server (equipe de dba/infra).
- Funcionalidades de busca avançada e experiência (ranking/snippets/highlight) podem exigir trabalho adicional na aplicação.
Pontos positivos
- Motor dedicado para busca textual, com foco em performance e consultas flexíveis.
- Permite phrase search e controle mais direto de parâmetros de busca.
- Evolui bem para cenários de acervo grande e alto volume de consultas, quando bem operado.
Pontos negativos / limitações
- Requer pipeline de reindexação (sincronização SQL → Redis) e monitoramento do índice.
- Necessita governança clara para consistência (quando reindexar, como lidar com falhas, etc.).
- Hangfire para jobs de indexação e reindexação.
- Encadeamento típico:
- indexar HTML
- (quando aplicável) reindexar o mecanismo de busca escolhido
- HTML inconsistente ou sem marcadores estáveis
- Mitigação: contrato formal do HTML, validação na ingestão, alertas.
- URLs temporárias/expiráveis (HTML/PDF)
- Mitigação: armazenamento interno (storage) com referência persistente.
- Indexação demorada em grandes volumes
- Mitigação: jobs em background, filas, escalabilidade horizontal.
- Duplicidade de protocolo por edição
- Mitigação: regra de desduplicação determinística durante indexação.
- Ingerir edição
- Como sistema gerador, quero enviar metadados e conteúdo HTML/PDF para o portal, com idempotência.
- Reindexar edição
- Como administrador, quero disparar reindexação do HTML quando necessário.
- Publicar/Despublicar edição
- Como administrador, quero controlar quando uma edição fica visível ao público.
- Listar edições
- Como usuário, quero navegar por edições publicadas por data/período.
- Abrir edição e navegar no sumário
- Como usuário, quero clicar em itens do sumário e ver o trecho correspondente do diário.
- Buscar texto
- Como usuário, quero pesquisar termos/frases e abrir diretamente a publicação encontrada.
- Integrações com sistemas internos (ex.: PPE) por API/eventos.
- Ampliação de filtros e ranking de resultados.
- Observabilidade completa (logs estruturados, métricas, tracing).
- Estratégia de migração e publicação do acervo histórico em lotes.
A proposta técnica estabelece uma base moderna e escalável para o novo Portal do DIOF, com ingestão robusta, indexação estruturada do HTML, navegação por sumário e busca textual eficiente.
Para a busca textual, as duas opções (SQL Server Full-Text Search e RedisSearch/RediSearch) devem ser consideradas de igual valor. A decisão deve ser guiada por critérios objetivos (infra disponível, custo operacional, requisitos de busca e estratégia de escalabilidade). Independentemente da escolha, recomenda-se manter processamento assíncrono (ex.: Hangfire) para indexações e reindexações, garantindo previsibilidade e boa experiência para administração e usuários.