Arquitetura de Software
O E-Docs é um sistema complexo, possuindo muitos módulos em sua arquitetura de software para permitir sua escalabilidade. O início de seu desenvolvimento se deu num formato mais monolítico, mas conforme cresceu sua utilização, foi necessário segmentar sua execução em vários serviços diferentes. Atualmente, o sistema passa por uma revisão de sua arquitetura, aproveitando os anos de experiência neste e em outros projetos para simplificar decisões arquiteturais e trazer uma estrutura mais simples e fácil de manter, com foco em desempenho e escalabilidade.
Diagrama de referência:
Clique no diagrama para abrir em alta resolução em uma nova aba.
O diagrama traz uma visão geral do sistema, mostrando:
- App Web e API Pública, parte do E-Docs Clássico (IIS), que funcionam como porta de entrada dos usuários e integradores;
- Todos os serviços da E-Docs Next-Gen Architecture (E-Docs NA), organizados nos quatro agrupamentos (Primários, Auxiliares, Dependências Tecnológicas e Especialistas);
- A plataforma tecnológica de hardware e infraestrutura sobre a qual o sistema é executado, detalhada em Arquitetura de Hardware;
- O ecossistema de integrações e dependências externas, como Acesso Cidadão, Organograma, Lotação, E-Flow, Cyclus, Tramita, Permissão ES e Notifica, detalhado em Integrações.
Este artigo é focado na arquitetura de software. Assim, as próximas seções detalham cada um dos módulos do E-Docs Clássico e do E-Docs NA.
E-Docs Clássico
Projeto inicial do E-Docs, cuja primeira versão data de 2018. Os sistemas deste conjunto são construídos em .NET 5 e executados em ambiente IIS.
Web
Aplicação Web do E-Docs, acessível em https://e-docs.es.gov.br. É a porta de entrada dos usuários no navegador e a interface pela qual se opera praticamente todo o sistema: captura de documentos em suas diversas modalidades, elaboração e fase de assinatura, encaminhamentos e caixas, autuação de processos e os demais atos processuais, cópia de processo, credenciamento, classificação documental e classificação da informação, entre outros.
Responde também pela autenticação do usuário, feita por integração com o Acesso Cidadão.
Nem tudo exige login. A validação de arquivos é uma consulta pública e anônima, servida pela mesma aplicação, que permite a qualquer pessoa conferir se um PDF em mãos foi realmente capturado no E-Docs e se continua íntegro.
Possui interface responsiva, o que permite o uso do E-Docs tanto no desktop quanto em dispositivos móveis.
API Pública
API pública do E-Docs, acessível em https://api.e-docs.es.gov.br. Permite que outros sistemas se integrem ao E-Docs para capturar e encaminhar documentos, praticar atos processuais como autuação, despacho e entranhamento, e consultar informações de apoio, como agentes, caixas e classificação documental.
A autenticação usa client credentials do Acesso Cidadão, e cada conjunto de operações é liberado por escopos específicos, concedidos ao sistema integrador. Assim, um integrador só alcança aquilo para o que foi autorizado.
Convivem duas versões: a V2, vigente e única indicada para novas integrações, e a V1, descontinuada.
Este artigo trata da API como módulo da arquitetura. O detalhamento dos recursos, os ambientes de Treinamento e Produção, o fluxo de autenticação e o passo a passo para solicitar acesso estão na seção API Pública.
Background Jobs
Executa as tarefas agendadas e recorrentes do E-Docs, que independem da conectividade do usuário no momento da execução. Reúne dezenas de rotinas, que se agrupam nos seguintes propósitos:
- Credenciamento: cancelamento diário das solicitações de credenciamento de documentos e de processos dirigidas a usuários que se tornaram inativos.
- E-Docs Chain: geração periódica dos Documentos-Elo.
- Indexação: inclusão de processos, encaminhamentos e agentes no motor de busca, além da conferência entre o que está indexado e o que consta no banco de dados.
- Classificação da Informação: desclassificação automática dos documentos cuja classificação de sigilo expirou.
- Áudio e vídeo: finalização das capturas cujos arquivos foram convertidos pelo Processador de Áudio e Vídeo.
- Resiliência da fila de processamento: reencaminhamento de eventos perdidos, não processados ou não concluídos, e novas tentativas de pós-processamento.
- Consistência de dados: correção de registros incompletos, como agentes sem nome e processos sem custódia.
- Limpeza dos buckets temporários: expurgo diário dos arquivos temporários no MinIO, com janelas de retenção distintas por finalidade.
- Manutenção de infraestrutura: garantia de existência dos buckets no MinIO, remoção de locks distribuídos perdidos e expurgo do histórico antigo do Hangfire.
O horário e a frequência de cada rotina, aqui e nos demais módulos do sistema, estão em Jobs Recorrentes.
Process Jobs
Sistema de filas do E-Docs, baseado no Outbox Pattern. É onde são executadas as operações mais pesadas do sistema: as capturas de documentos em todas as suas modalidades, os encaminhamentos e os atos processuais, como autuação, despacho, entranhamento, sobrestamento e encerramento. Ao todo, quase trinta tipos de evento distintos.
O processamento não acontece em uma fila única. Ele é dividido em filas dedicadas, cada uma com seu próprio conjunto de workers, de modo que um tipo de tarefa não monopolize os recursos e prejudique os demais:
- Roteamento: lê o evento gravado no banco e o direciona para a rotina que sabe tratá-lo, conforme o tipo do evento.
- Transação: executa o processamento principal, ou seja, o trabalho de negócio propriamente dito.
- Pós-processamento: dispara as tarefas que sucedem a operação principal, como indexação e credenciamento.
- Verificação: confere se a indexação do que foi processado ocorreu como esperado.
- Recuperação de caixa: trata as recuperações de caixa, em duas etapas separadas, uma de preparação e outra de execução.
O dimensionamento de cada fila é proporcional ao volume e à criticidade do que ela processa. As filas de roteamento, transação e pós-processamento, que sustentam o fluxo principal, são as mais numerosas em workers. Já a recuperação de caixa opera com pouquíssimos, por ser uma operação administrativa, pontual e de alto custo, que não deve competir com o uso corrente do sistema.
Gerador de PDF
API de manipulação de arquivos PDF do E-Docs. Realiza operações como carimbar, mesclar e gerar arquivos a partir de templates HTML.
Certificado
Valida certificados digitais ICP-Brasil antes da captura de documentos assinados, garantindo que o certificado estava válido e não revogado no momento da assinatura.
Certificado Outbound
Componente que faz o acesso externo (outbound) à internet em nome da API de Certificado, para consultas de cadeias de certificação e listas de revogação.
DevArea
Aplicação de suporte do E-Docs, que permite aos desenvolvedores consultar dados e executar operações para diagnosticar e corrigir falhas ou comportamentos inesperados.
Test Area
Ambiente isolado utilizado pela equipe de desenvolvimento para validar funcionalidades do E-Docs.
E-Docs Next-Gen Architecture (E-Docs NA)
Projeto de modernização do E-Docs. Tem como intuito principal reescrever o back-end de todas as funcionalidades do sistema, de forma modular. Usa o conceito de serviços distribuídos e conectados via APIs REST, agrupados em funções especializadas por tarefa, tecnologia ou conceito.
Os sistemas deste conjunto acompanham a versão mais recente do .NET, atualmente o .NET 10, e são executados de forma containerizada no OCP (OpenShift).
A arquitetura se inspira em microsserviços, mas evita a comunicação excessiva entre os serviços: cada chamada às APIs busca resolver casos de uso específicos, garantindo eficiência e desempenho.
Este artigo descreve o que são os módulos do E-Docs NA. Para entender por que essa arquitetura foi adotada (a motivação, os padrões de projeto como CQRS e Outbox, a estratégia de migração com feature flags e control flags e os números de operação do sistema), consulte E-Docs Next-Gen Architecture.
Serviços Primários de Negócio
São os serviços responsáveis pela execução direta dos casos de uso do sistema. Adotam o padrão CQRS, separando operações de leitura (Query) das de escrita (Command), além do padrão Dispatch/Process para os casos de uso mais pesados.
ENQ - E-Docs Negócio Query
Abriga todos os casos de uso de leitura (query) do sistema, seguindo a filosofia do CQRS. Inclui contadores, listagens, detalhes e relatórios quantitativos. A partir desta API são construídas várias páginas do sistema, como caixas de processos, caixas de encaminhamentos e contadores da tela inicial. O objetivo é prover informações de forma rápida e eficiente, sem processamento adicional.
Contém consultas de praticamente todos os módulos de negócio do E-Docs: Documentos (capturados, para assinar, em elaboração), Encaminhamentos, Processos e seus atos (autuação, despacho e outros), credenciamento de documentos e de processos, entre outras.
Também abriga as consultas de Classificação Documental (Plano de Classificação e Classes Documentais, cuja manutenção é de responsabilidade do APEES) e de Classificação da Informação (Fundamentos Legais para sigilo e informações classificadas, sob responsabilidade da SECONT).
Acessa o banco de dados do E-Docs.
ENC - E-Docs Negócio Command
Executa os casos de uso de escrita do sistema, sendo a parte Command do padrão CQRS, contraponto ao ENQ. Concentra as operações de inserção, atualização e exclusão de dados, como marcar encaminhamentos como pendentes ou resolvidos e organizá-los nas pastas da caixa de entrada. As funcionalidades que utilizam o padrão Dispatch/Process ficam em serviços dedicados.
Abriga também a manutenção do Organizador de Processos: a criação e a alteração das associações de processos, suas categorias e a ordem dos processos dentro de cada associação.
Suas rotinas podem realizar consultas necessárias para a execução das escritas, como buscar informações para aplicar validações.
Executa operações em nome do usuário logado, exigindo um token de usuário válido oriundo do Acesso Cidadão, de forma a garantir a autoria das ações. Acessa o banco de dados do E-Docs.
ENB - E-Docs Negócio Base
Centraliza regras de negócio comuns a vários módulos do sistema, evitando duplicação de código e reduzindo o risco de versões divergentes da mesma regra.
Em relação a documentos, abriga a lógica de acesso aos documentos do E-Docs. Suas principais funcionalidades são o PodeVer (calcula se o usuário tem permissão para visualizar o conteúdo de um documento capturado) e o PodeUsar (define se o usuário pode usar um documento em encaminhamentos e processos). Com base nessas informações, também gerencia a obtenção da URL de visualização dos documentos capturados.
Em relação a processos, possui a lógica de cálculo do ProcessoStatus, um objeto contendo informações críticas ao processo, como custódia atual, situação (encerrado ou não), último ato e último ato de movimentação. Usado em vários pontos do sistema onde se lida com processos administrativos.
Também abriga a lógica de permissionamento das principais funções do sistema, tratando de documentos, encaminhamentos e processos.
Como apoio a todos os cálculos citados acima, o ENB gerencia o UsuarioLogadoCache, um objeto carregado no momento do login do usuário, contendo várias informações suas: papéis que possui, grupos onde é membro, locais onde é gestor, locais com delegação e permissões explícitas. Esse objeto é mantido em cache, permitindo que os cálculos sejam feitos da forma mais rápida possível.
Acessa o banco de dados do E-Docs.
END - E-Docs Negócio Dispatch
Concentra as funcionalidades do E-Docs que dependem do padrão Dispatch/Process. Realiza a fase de Dispatch, fazendo validações e preparando os dados que serão usados na fase de Process, e enfileirando os eventos de processamento.
Atende hoje a captura de documentos e os encaminhamentos, além de expor as consultas de acompanhamento e as estatísticas dos eventos de processamento. Os atos processuais ainda são executados pelo E-Docs Clássico e serão migrados adiante.
Executa operações em nome do usuário logado, exigindo um token de usuário válido. Acessa o banco de dados do E-Docs.
Para um exemplo concreto desta fase aplicada a um caso de uso real, consulte o estudo de caso do fluxo de captura de documentos.
ENP - E-Docs Negócio Process
Realiza a parte de processamento das funcionalidades do E-Docs que dependem do padrão Dispatch/Process, acompanhando o mesmo escopo do END: captura de documentos e encaminhamentos. Recebe do END, por API, os eventos a enfileirar e, ao final, atualiza a situação do evento de processamento e dispara as tarefas de pós-processamento (como indexação dos dados, credenciamento de acessos e envio de notificações).
Executa em um Hangfire dedicado, com base de dados própria, trabalhando com conceito de fila seguindo o Outbox Pattern. Adicionalmente, acessa o banco de dados do E-Docs.
Para um exemplo concreto desta fase aplicada a um caso de uso real, consulte o estudo de caso do fluxo de captura de documentos.
ENT - E-Docs Negócio Tasks
Executa tarefas agendadas ou em segundo plano, que independem da conectividade do usuário no momento da execução. É o destino, na nova arquitetura, das tarefas recorrentes que hoje rodam no Background Jobs do E-Docs Clássico: geração de Documentos-Elo, rotinas de limpeza, rotinas de validação, entre outras. A migração dessas tarefas é gradual.
Executa em um Hangfire dedicado, com base de dados própria. Também acessa o banco de dados do E-Docs. Possui uma API de acionamento, consumida pelo ENP.
EPC - E-Docs Processo Cópia
Módulo dedicado à geração de Cópias de Processo. Existem processos tão grandes e volumosos no E-Docs, alguns com milhares de atos e dezenas de milhares de documentos, que a geração de uma cópia justifica um módulo próprio.
Isolar esse caso de uso permite controlar melhor os recursos consumidos e garante que a geração da cópia de um processo gigante não degrade o desempenho das demais funcionalidades do sistema.
Executa em um Hangfire dedicado, com base de dados própria. Também acessa o banco de dados do E-Docs.
ECH - E-Docs Credenciamento Handler
O ECH está em fase de concepção. Por isso, ainda não aparece nas tabelas de atributos e de dependências ao final deste artigo.
Concentrará a lógica de credenciamento de documentos, normalmente executada após a fase de Process dos encaminhamentos e dos atos processuais. É o credenciamento que define quais agentes passam a ter acesso de leitura aos documentos que recebem.
Acessará o banco de dados do E-Docs.
Serviços Auxiliares de Negócio
São serviços de apoio que fornecem dados e funcionalidades complementares aos serviços primários. Concentram responsabilidades específicas para garantir padronização e reuso.
EAQ - E-Docs Agente Query
Centraliza e padroniza a obtenção de agentes no E-Docs. Também traz consultas de permissões de usuário e outras informações correlatas.
Um agente no E-Docs possui seis tipos possíveis: Órgão, Unidade, Grupo, Papel, Cidadão e Sistema. Para mais detalhes sobre o conceito, consulte o artigo Agente.
A entrega das informações ocorre por meio do objeto AgenteDto, cuja montagem é responsabilidade do EAC.
Acessa o banco de dados próprio de agentes e, em alguns casos, também o banco de dados do E-Docs.
EAC - E-Docs Agente Carga
Realiza as cargas de dados que alimentam o Agente Query, mantendo a base sincronizada com as fontes originais. As informações têm três origens: o sistema Organograma (Órgãos e Unidades), o Acesso Cidadão (Cidadãos e Sistemas) e o Lotação (Papéis e Grupos/Comissões).
A partir dessas três fontes, o EAC monta o objeto AgenteDto, uma estrutura de dados unificada e transversal a toda a arquitetura, que padroniza a representação de um agente. Essa consolidação leva em consideração questões de negócio do E-Docs, como, por exemplo, se o patriarca está habilitado para usar o sistema.
Executa em um Hangfire dedicado, com base de dados própria (a base de agentes). Eventualmente, também acessa o banco de dados do E-Docs.
EUM - E-Docs Usuário Manager
Gerencia funções personalizadas dos usuários: papel preferencial, delegação de acesso, processos e encaminhamentos favoritos, preferências gerais e escolha das categorias de notificação que o usuário deseja ou não receber.
Mantém ainda o histórico das delegações de acesso, permitindo consultar as concessões passadas por usuário e por local.
Executa operações em nome do usuário logado, exigindo um token de usuário válido oriundo do Acesso Cidadão, de forma a garantir a autoria das ações. Possui base de dados própria.
ENO - E-Docs Notificação Composer
Compõe e envia as notificações do sistema. Dado um tipo de notificação (captura, assinatura, encaminhamento, despacho, entre outros), define quais agentes serão notificados, monta a mensagem e aciona a API do sistema estruturante de Notificações do Prodest, que cuida da entrega.
Possui uma API para envio das notificações, cuja única função é disparar um job fire-and-forget no Hangfire, com até cinco tentativas automáticas em caso de falha. No futuro, avalia-se a conversão dessa lógica para passar a usar o padrão Outbox.
Executa em um Hangfire dedicado, com base de dados própria. Também acessa o banco de dados do E-Docs.
EDA - E-Docs Document Analyzer
Contém a lógica de extração e sanitização do conteúdo de documentos PDF. O texto extraído passa por uma limpeza que remove caracteres de controle, escapes e cabeçalhos inseridos pelo próprio E-Docs, de modo que sobre apenas o conteúdo útil. É o EDA que alimenta o EEI9 com esse conteúdo, viabilizando a busca textual dentro dos documentos.
Identifica também as páginas passíveis de OCR, ou seja, aquelas em que não há texto a extrair por se tratarem de imagem.
Abriga ainda um trabalho exploratório de IA, com geração de resumo de documento por modelo de linguagem, ainda em caráter de prova de conceito.
Executa em um Hangfire dedicado, com base de dados própria. Trabalha com conceito de fila seguindo o Outbox Pattern. Também acessa o banco de dados do E-Docs.
ECO - E-Docs Config
Sistema oficial de configuração do E-Docs. É o ponto único de consulta das duas formas de acionamento controlado de funcionalidades do sistema: as feature flags e as control flags.
As feature flags permitem ligar e desligar funcionalidades para um conjunto restrito de usuários, viabilizando a liberação gradual por órgão. Elas não são cadastradas no ECO: cada flag é uma ação do recurso Feature Flag no cadastro do sistema ECO no Acesso Cidadão Admin, e a liberação se dá pelos perfis ali associados. Em tempo de execução, o ECO consulta o sistema Permissão ES para saber se o usuário possui aquela ação. A consulta é fail-safe: qualquer falha na obtenção das permissões resulta em flag desligada.
As control flags existem para os casos em que não é possível determinar o usuário. Funcionam como uma chave liga-desliga única, válida para todos os usuários de uma vez. Ficam na base de dados própria do ECO, organizadas em agrupadores, e são servidas com cache de curta duração para não onerar as chamadas.
Além da API, o ECO possui uma interface Web para o cadastro e a manutenção das control flags e de seus agrupadores.
Possui base de dados própria. Ambos os conceitos são detalhados em E-Docs Next-Gen Architecture.
ECC - E-Docs Classificação Carga
O ECC ainda não foi implementado. Sua construção está prevista para começar em algum momento de 2027.
Realizará a carga das informações de Plano de Classificação Documental e suas classes, obtidas a partir do sistema Cyclus, para as tabelas internas do E-Docs.
Serviços de Dependências Tecnológicas
São serviços que concentram e padronizam a comunicação do E-Docs com tecnologias específicas, como bancos de dados orientados a documentos e armazenamento de objetos.
EEI9 - E-Docs Elastic Index 9
Responsável por incluir, alterar e excluir dados no índice do Elasticsearch 9, processo conhecido como indexação. Transforma os dados persistidos no banco de dados em um modelo de pesquisa e os envia ao Elasticsearch.
Não possui regras de negócio explícitas. Para montar o modelo de pesquisa, recorre ao EAQ, de onde obtém os dados dos agentes, e ao EDA, de onde obtém o conteúdo textual extraído dos documentos PDF.
Executa em um Hangfire dedicado, com base de dados própria. Trabalha com conceito de fila seguindo o Outbox Pattern. Acessa também o banco de dados do E-Docs, de onde lê os dados a serem indexados.
EEQ9 - E-Docs Elastic Query 9
Concentra e encapsula toda a lógica de consulta ao Elasticsearch 9 em um único ponto da arquitetura. Contém todas as queries específicas no formato que o Elasticsearch entende e é responsável por sua execução. O retorno é composto por primitivas ou por objetos que representam a estrutura de dados indexada no Elasticsearch.
Não possui regras de negócio explícitas e, por isso, precisa receber todos os parâmetros necessários para a execução das queries. A exceção é o controle de acesso aos documentos: nas consultas de documento, o EEQ9 recorre ao ENB para aplicar o PodeVer e o PodeUsar, de modo que o resultado da busca traga apenas o que o usuário pode efetivamente acessar.
EMM - E-Docs Minio Manager
Concentra e encapsula toda a lógica específica relacionada ao MinIO em um único ponto da arquitetura. Conhece todos os buckets utilizados pelo E-Docs e fornece a geração de URLs de acesso e escrita aos documentos, considerando questões de segurança como o tempo de expiração dos links.
Importante destacar que o EMM não recebe o arquivo em si: o upload dos arquivos é feito diretamente ao MinIO, usando sua API, pelos demais módulos.
Não depende de nenhum outro serviço da arquitetura. Além do servidor MinIO, acessa o banco de dados do E-Docs, de onde lê os dados dos documentos necessários para localizar o arquivo correspondente no bucket certo.
Serviços Especialistas
São serviços com responsabilidades muito específicas, normalmente associadas a um tipo de processamento ou a uma integração particular.
DOC-M - E-Docs Document Models
Possui modelos de documentos padrão e fragmentos de páginas, usados na geração de diversos tipos de documentos no E-Docs. São exemplos de modelos:
- Página de Metadados de documento capturado
- Registro de Encaminhamento
- Termos de Autuação, Despacho e demais atos processuais
- Capa de Cópia de Processo
- Corpo de um Documento Elaborado via interface do E-Docs
A partir dos dados informados, preenche um determinado modelo e retorna o resultado em formato HTML, com trechos de CSS inline e eventuais imagens embutidas em formato Base64.
Este serviço torna a criação e a manutenção de modelos muito mais fácil e flexível, dada a utilização de HTML e CSS na formatação dos documentos, em contraste com bibliotecas tradicionais de construção de PDF.
P-AV - Processador Áudio e Vídeo
Processa e converte arquivos de áudio e vídeo para um formato padronizado, adequado ao armazenamento e ao uso pelo E-Docs.
Executa em um Hangfire dedicado, trabalhando com conceito de fila seguindo o Outbox Pattern. Acessa o banco de dados do E-Docs.
P-PDF - Processador de PDF
É o único ponto de entrada de manipulação de PDF da nova arquitetura, executando operações como conversão de HTML para PDF, otimização, padronização e remoção de assinaturas; quando a operação exige assinatura com certificado ICP-Brasil, aciona o A-PDF.
A-PDF - Assinador PDF
Possui uma função única: assinar documentos PDF com certificado ICP-Brasil. É acionado exclusivamente pelo P-PDF, nunca diretamente pelos demais módulos da arquitetura.
A intenção original era manter a lógica de assinatura dentro do próprio P-PDF. A separação foi necessária por causa da biblioteca iText, a única que atendeu aos requisitos de assinatura do E-Docs. Isolar a dependência em um serviço à parte evita que a licença do iText se estenda ao restante do projeto e mantém o P-PDF livre dessa amarra.
E-Docs CDN
CDN (Content Delivery Network) usado pelo E-Docs para entregar imagens, scripts e estilos de forma rápida e independente da aplicação. Simplifica a manutenção e permite o reuso em futuras aplicações web.
E-Docs E-Flow API
Funciona como integração entre os sistemas E-Docs e E-Flow, respondendo às perguntas que o E-Docs precisa fazer sobre fluxos. Suas consultas se dividem em dois grupos:
- Definições de fluxo: quais fluxos estão disponíveis, em quais locais e em quais patriarcas existem fluxos publicados.
- Execuções de fluxo: os fluxos pendentes para o usuário e seu contador, os que ele iniciou, os que já respondeu (por usuário ou por caixa), o status de uma execução, o ator responsável por resolvê-la e as informações necessárias ao envio de notificações. Traz ainda as execuções vinculadas a encaminhamentos.
Para isso, acessa a base de dados do E-Flow (não a do E-Docs). Recorre ao EAQ para obter os agentes e ao ENB para saber quais caixas e papéis o usuário alcança, de forma que o resultado respeite as regras de acesso do E-Docs.
Este módulo é mantido pelo time do E-Flow, e não pela equipe de desenvolvimento do E-Docs. Está listado aqui para fins de documentação e compreensão da arquitetura.
Resumo dos atributos arquiteturais
A tabela abaixo consolida quatro características técnicas dos módulos do E-Docs NA: uso de Hangfire dedicado para processamento em segundo plano, existência de base de dados própria, acesso ao banco de dados do E-Docs e adoção do padrão Outbox para enfileiramento de tarefas. É um resumo prático do que está descrito nas seções acima.
| Módulo | Possui API | Hangfire dedicado | Base própria | Acessa banco do E-Docs | Outbox Pattern |
|---|---|---|---|---|---|
| ENQ - Negócio Query | Sim | Sim | |||
| ENC - Negócio Command | Sim | Sim | |||
| ENB - Negócio Base | Sim | Sim | |||
| END - Negócio Dispatch | Sim | Sim | |||
| ENP - Negócio Process | Sim | Sim | Sim | Sim | Sim |
| ENT - Negócio Tasks | Sim | Sim | Sim | Sim | |
| EPC - Processo Cópia | Sim | Sim | Sim | Sim | |
| EAQ - Agente Query | Sim | Sim | Sim | ||
| EAC - Agente Carga | Sim | Sim | Sim | ||
| EUM - Usuário Manager | Sim | Sim | |||
| ENO - Notificação Composer | Sim | Sim | Sim | Sim | |
| ECO - Config | Sim | Sim | |||
| EDA - Document Analyzer | Sim | Sim | Sim | Sim | Sim |
| EEI9 - Elastic Index 9 | Sim | Sim | Sim | Sim | |
| EEQ9 - Elastic Query 9 | Sim | ||||
| EMM - MinIO Manager | Sim | Sim | |||
| DOC-M - Document Models | Sim | ||||
| P-AV - Processador Áudio e Vídeo | Sim | Sim | Sim | Sim | |
| P-PDF - Processador de PDF | Sim | ||||
| A-PDF - Assinador PDF | Sim | ||||
| E-Docs CDN | |||||
| E-Flow API | Sim | Não¹ |
¹ A E-Flow API acessa a base de dados do E-Flow (não a do E-Docs) para realizar suas consultas.
Dependências entre módulos
A tabela abaixo mapeia as dependências de chamadas entre os módulos do E-Docs (Clássico e NA). Cada linha representa um módulo consumidor; cada coluna, um módulo consumido. A marcação Sim indica que o módulo da linha utiliza, em pelo menos um caso de uso, o módulo da coluna.
Dependências de plataforma e infraestrutura (banco de dados, MinIO, Elasticsearch, Hangfire, OpenShift, sistemas estruturantes do Prodest) não estão representadas aqui: o foco é apenas em chamadas entre sistemas do E-Docs.
| Módulo | ENQ | ENC | ENB | END | ENP | ENT | EAQ | EUM | ENO | ECO | EDA | EEQ9 | EMM | DOC-M | CDN | P-AV | P-PDF | A-PDF | E-Flow | Gerador PDF |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Web | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | ||||||||||||
| Api Pública | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||||
| Background Jobs | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | ||||||||||||
| Process Jobs | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||
| DevArea | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||||
| Test Area | Sim | Sim | Sim | Sim | Sim | |||||||||||||||
| ENB | Sim | Sim | ||||||||||||||||||
| ENC | Sim | Sim | ||||||||||||||||||
| ENQ | Sim | Sim | Sim | Sim | Sim | |||||||||||||||
| END | Sim | Sim | Sim | Sim | Sim² | |||||||||||||||
| ENP | Sim | Sim | Sim | Sim | Sim | Sim² | ||||||||||||||
| EPC | Sim | Sim | Sim | Sim | Sim² | |||||||||||||||
| EAQ | Sim | Sim | ||||||||||||||||||
| ENT¹ | ||||||||||||||||||||
| EAC¹ | ||||||||||||||||||||
| ECO¹ | ||||||||||||||||||||
| EDA | Sim | Sim | ||||||||||||||||||
| ENO | Sim | Sim | Sim | Sim | ||||||||||||||||
| EUM | Sim | |||||||||||||||||||
| EEI9 | Sim | Sim | ||||||||||||||||||
| EEQ9 | Sim | |||||||||||||||||||
| P-PDF | Sim | |||||||||||||||||||
| E-Flow API | Sim | Sim | ||||||||||||||||||
| Módulo | ENQ | ENC | ENB | END | ENP | ENT | EAQ | EUM | ENO | ECO | EDA | EEQ9 | EMM | DOC-M | CDN | P-AV | P-PDF | A-PDF | E-Flow | Gerador PDF |
¹ EAC, ENT e ECO não possuem dependência de chamada a outros módulos do E-Docs. O EAC consome os sistemas estruturantes que alimentam a base de agentes (Organograma, Acesso Cidadão e Lotação); o ECO consome o sistema Permissão ES, pelo qual lê as feature flags do usuário.
² Os módulos da E-Docs NA que manipulam PDF (END, ENP e EPC) ainda utilizam o Gerador de PDF do E-Docs Clássico. A substituição pelo P-PDF está em construção. Vale notar que o A-PDF nunca é chamado diretamente: quem o aciona é sempre o P-PDF.
Outras Soluções
Soluções complementares que compõem o ecossistema do E-Docs, mas que não fazem parte do núcleo de processamento do sistema.
Web Portal
Portal inicial do E-Docs, acessível em https://edocs.es.gov.br. Trata-se de um hotsite construído em Orchard.
Este hotsite é mantido pelo Arquivo Público (GESTAD), e não pelo time de desenvolvimento do E-Docs. Está listado aqui para fins de documentação e compreensão do ecossistema.
Docs
Página de documentação do E-Docs, acessível em https://docs.e-docs.es.gov.br. Reúne informações sobre a arquitetura do sistema, o detalhamento dos serviços, as principais regras de negócio e outras informações relevantes.