Introdução

Contexto: Apresentação geral do contexto arquitetura dos sistemas e suas fases de implantação.
Tags: aquila, sistemas, rudis, magma

1. Visão Geral

O ecossistema composto pelas aplicações Katarsis, RUDIS, MAGMA e Àquila pode ser definido, em sua finalidade geral, como uma Solução Integrada de Governança, Automação e Saneamento de Dados Processuais, essencial para, governança de dados e produção de insumos para inteligência artificial, e a modernização da gestão e a conformidade do Tribunal com as diretrizes nacionais definidas pelo Datajud/CNJ.

Essa solução configura um ecossistema de indicadores para Business Intelligence (BI), Qualidade, Governança e Auditoria de Dados Data-Driven em tempo real, cujo objetivo central é transformar dados processuais brutos em informações precisas e estratégicas para a tomada de decisões, além de insumos para inteligência artificial.

Adicionalmente, o Àquila, subsidiado pelos três primeiros produtos, oferece a Governança de execução, diagnóstico e estratégia do Prêmio de Qualidade CNJ em todos os Eixos, oferecendo ao gestor uma visibilidade ampla para um acompanhamento centralizado de todos os itens a serem aferidos.

O processo de integração e customização, se dá em etapas, definidas conforme o termo de referência prévio a contratação.

1.1 Rudis

O RUDIS é o acrônimo para Real-time Unified Data Information Store (Armazenamento Unificado de Informações de Dados em Tempo Real)

1.1.1 Para que o RUDIS serve?

Os principais objetivos do RUDIS são: centralizar os dados processuais e garantir a consistência e qualidade das informações dentro do Tribunal, prover insumos para inteligência artificial e facilitar a integração de novas aplicações através de APIs.

1.1.2 Ele serve especificamente para:

Centralização e integração: Implementar a estrutura necessária para operar a aplicação de centralização de dados, estabelecendo a integração inicial entre os sistemas processuais (conforme a distribuição do conversor existente no momento da contratação), o DataJud e o CODEX.
Consistência de dados: garantir a consistência estrutural dos dados processuais.
Suporte à automação: Preparar a base de dados para suporte ao processamento assíncrono e à integração de mensagens, oferecendo suporte técnico e estrutural para futuras automações.
Monitoramento e Governança: o RUDIS é crucial para a integração com a plataforma Magma, permitindo garantir indicadores precisos em tempo real a serem utilizados nas visualizações de dados gerenciais e no monitoramento de indicadores internos e do CNJ.

1.1.3 Como o RUDIS funciona ?

O RUDIS é implantado como um módulo de centralização e atua como um ponto central de integração e validação no fluxo de dados do Tribunal. As entregas relativas à sua implementação incluem a "Implementação acoplada", a "Incorporação de funcionalidades (API / Mensageria)", o "Mapa de Indicadores" e a "Autonomia e redundância de dados". Cada uma destas etapas, traz consigo funcionalidades, no qual o escopo pleno da aplicação é idealizado após a total conclusão das etapas.

Seu funcionamento está estruturado da seguinte forma:

Fluxo Bidirecional de Dados: é capaz de prover um fluxo bidirecional de dados entre o Codex, o Extrator e os sistemas processuais.
Fonte de Dados: a centralização é realizada utilizando o sistema processual como fonte primária de dados. As informações são extraídas, transformadas e carregadas (ETL) para um Data Warehouse centralizado, totalmente disponível para uso interno através de APIs, com autenticação e auditoria.
Integração e Consistência: suporte a integração de sistemas processuais internos, aprimorando a consistência das bases de dados com o DataJud, o que aumenta os índices de completude e qualidade das informações.
Acesso Programático (APIs): suas funcionalidades podem ser expandidas com automações, garantidas pela consistência dos serviços e o acesso programático via APIs, oferecendo bibliotecas customizáveis para integração. Essas bibliotecas são, em sua maioria, desenvolvidas em Python e Java.
Operação Autônoma e Eficiente: as rotinas implementadas no RUDIS são automatizados para assegurar sua operação confiável e contínua.
Integração com outros Sistemas: na ultima fase de implementação, é finalizado o processo de integração do RUDIS com os demais sistemas contratados, incluindo o Katarsis (sistema de correção de inconsistências) e o Magma (plataforma de governança e geração automática de indicadores para BI em tempo real).
Consolidação: o escopo global de monitoramento, controle, governança e automação da implementação de referência de visualização de dados a partir do sistema Magma, é consolidado em conjunto com a última fase do RUDIS.

1.1.3 Como é a arquitetura do Rudis ?

O RUDIS foi projetado dentro de uma arquitetura modular e distribuída, integrando diversos componentes responsáveis pela coleta, transformação e sincronização de dados oriundos das fontes processuais do tribunal.

No núcleo, o RUDIS estabelece comunicação com:

RabbitMQ: utilizado para o gerenciamento de filas e orquestração assíncrona dos fluxos de dados.
PostgreSQL: banco de dados dedicado ao RUDIS, garantindo isolamento e confiabilidade no armazenamento das informações tratadas.
S3: suporte ao armazenamento distribuído de arquivos e objetos, permitindo escalabilidade e integração com processos de ingestão e análise.

Além disso, o RUDIS interage diretamente com um conjunto de microserviços especializados:

Extratores: responsáveis por acessar as bases processuais do tribunal (ex.: extrator-pjepg, extrator-pjesg) e também sistemas específicos, como o SEEU (extrator-seeu) ou ambientes legados (extrator-legado).
Conversores e proxies: realizam a normalização e adaptação dos dados coletados, preparando-os para integração no RUDIS. Isso inclui camadas intermediárias (conversor-proxy-pjepg, conversor-proxy-pjesg) conectadas aos conversores finais (conversor-pjepg (codex), conversor-pjesg (codex)).

Esse ecossistema garante que o RUDIS consiga:

Extrair informações diretamente dos sistemas processuais do tribunal.
Incorporar dados do SEEU a partir do ambiente do Codex CNJ.
Sincronizar registros provenientes de sistemas legados por meio do MTD.
Manter a interoperabilidade entre diferentes fontes e formatos, assegurando consistência e qualidade dos dados repassados ao CNJ.

1.2 Magma

O MAGMA é uma plataforma completa de governança e geração automática de indicadores para Business Intelligence (BI) em tempo real. É um sistema de gestão e calculo de indicadores para visualização de dados analíticos.

1.2.1 Para que o MAGMA serve?

O principal objetivo do Magma é fornecer uma ferramenta estratégica para a gestão de desempenho e a conformidade do Tribunal com as exigências do Conselho Nacional de Justiça (CNJ).

1.2.2 Suas finalidades incluem:

Geração de Indicadores em Tempo Real: o Magma tem como foco a geração automática de indicadores para BI em tempo real, permitindo a gestão de metas orientada a dados (data-driven) e inteligência judicial.
Monitoramento e Governança: é utilizado para o monitoramento de indicadores internos e do CNJ, garantindo que os indicadores utilizados nas visualizações de dados gerenciais sejam precisos e em tempo real.
Gestão do Prêmio CNJ de Qualidade: a plataforma conta com um módulo de GESTÃO DO PRÊMIO (integração com Aquila e painel). Este módulo:
- Apresenta visualmente, em tempo real, o nível de atendimento (pontos) no ranking do CNJ.
- Indica os eixos (como Produtividade, Dados e Tecnologia) que precisam de maior atenção para garantir os melhores níveis para o Selo.
Acesso Granular: oferece acesso granular a todos os indicadores monitorados através dos seus dos parâmetros persistidos.

1.2.3 Como o MAGMA irá funcionar?

A operação do Magma envolve intensa integração com a infraestrutura de dados recém-implantada:

Integração de Dados: o Magma é integrado totalmente ao RUDIS (Real-time Unified Data Information Store) para garantir que os indicadores sejam precisos e em tempo real.
Visualização de Dados: Irá fornecer visualizações de dados analíticos por meio de dashboards interativos, desenvolvidos utilizando as capacidades do Codex ou ferramentas de BI integráveis, para monitorar os indicadores de qualidade.
Alerta Automático: uma de suas funcionalidades é o envio de alertas em caso de variação significativa nos indicadores.
Público-Alvo: As visualizações e o dashboard não se resumem a tomadas de decisões negociais, mas são direcionados às equipes técnicas responsáveis pela governança de dados e integridade dos sistemas.
Consolidação: O escopo global de monitoramento, controle, governança e automação da implementação de visualização de dados a partir do sistema Magma é consolidado em conjunto com a última entrega do RUDIS.
Controle de Governanças Manuais: aqueles indicadores que não tiverem viabilidade de integração via dados judiciais monitorados pelo Rudis ou Kartarsis podem ser controlados no Magma através da inserção manual de metadados e evidências para acompanhamento da pontuação do Prêmio CNJ.

1.2.4 Como é a arquitetura do MAGMA ?

Principais Componentes Arquiteturais

Integração com Rudis e Rudis-MQ: o Magma recebe dados processuais extraídos e tratados pelo Rudis, com suporte a comunicação assíncrona via mensageria, garantindo robustez e resiliência no fluxo.
Magma-MQ: camada interna de mensageria que gerencia filas e processamentos paralelos, permitindo que os dados sejam tratados de forma desacoplada e escalável.
PostgreSQL: banco central do Magma, dedicado à persistência, modelagem e governança dos dados analíticos. É a base de apoio para a geração de indicadores em tempo real e serve de fonte para visualizações.
Power BI (não obrigatório): camada de apresentação, responsável por dashboards e relatórios dinâmicos que refletem os dados já tratados e validados, possibilitando análises gerenciais e estratégicas. Pode ser utilizado qualquer ferramenta de visualização, pois toda regra negocial dos indicadores estão persistidos no Magma.
Importação MTD: módulo que viabiliza a ingestão de dados de sistemas legados e outras fontes externas, assegurando que todo o ecossistema analítico seja abrangente e atualizado.

1.3 Kartarsis

O KATARSIS é um sistema essencial dentro do Eixo de Desenvolvimento e Automação (Eixo 04) do projeto de saneamento de dados do Tribunal.

1.3.1 O que é o Katarsis ?

O Kartarsis é um sistema integrado ao sistema processual. Seu propósito fundamental é ser uma ferramenta para identificar e corrigir inconsistências nos dados, sendo um dos principais desenvolvimentos desse eixo de automação.

1.3.2 Para que serve o Katarsis ?

O objetivo principal da implementação do Katarsis é garantir maior precisão e qualidade nas informações processuais.

Ele serve para:

Correção de Inconsistências: Identificar e corrigir inconsistências em movimentos, classes, assuntos e outros elementos relacionados à qualidade de dados.
Alinhamento com o CNJ: Assegurar o alinhamento com os padrões do CNJ, garantindo a completude dos registros e a precisão nos movimentos processuais.
Retroalimentação de Dados: Permitir a retroalimentação de informações do DataJud para o PJe.
Governança: O sistema está inserido na infraestrutura de governança e monitoramento, sendo um dos sistemas que monitoram dados judiciais, juntamente com o RUDIS e o MAGMA.

1.3.3 Como o Katarsis irá funcionar ?

O Katarsis funcionará como um módulo de validação e correção que opera diretamente integrado ao sistema processual:

Integração e validação: é um sistema integrado ao sistema processual. Na prática, funcionará como um módulo de validação integrado ao sistema processual que realiza validações automáticas dos dados antes da submissão ao DataJud pelos meios já utilizados pelo Tribunal.
Uso de Scripts e APIs: sua operação pode envolver, além do seu core, o uso de scripts em Python ou outra linguagem adequada para automatizar a correção de códigos de movimentos incorretos ou faltantes, com base em regras de negócio e validações.
Retroalimentação Automática: conta com uma API de Retroalimentação que permite corrigir automaticamente as inconsistências identificadas pelo DataJud e enviar essa correção de volta para o sistema processual, ou para uma zona de validação/curadoria.
Inteligência Artificial (IA): por estar integrado através de API's, sua arquitetura facilita o processo de integração para consumo de modelos de inteligência artificial, que podem ter finalidades diversas no âmbito de qualidade de dados.
Automações Potenciais: ele é projetado para poder realizar automatizações como, correção automática de erros de digitação, preenchimento automático de campos obrigatórios com base em dados existentes e validação automática de datas e prazos processuais.
Saneamento Específico: permite a inclusão do histórico de movimentos ausentes e de documentos migrados diretamente no processo, permitindo que as políticas de sigilo e LGPD sejam atendidas.

1.3.4 Como é a arquitetura do Katarsis ?

Principais Componentes da Arquitetura

Purificadores (PJePG, PJeSG e eProcPG): módulos responsáveis por acessar diretamente as bases processuais do tribunal. Eles aplicam regras de saneamento e identificação de inconsistências, enviando os dados tratados ao Katarsis por meio da katarsis-api.
Katarsis: núcleo central do sistema, responsável por consolidar, tratar e corrigir as informações recebidas dos purificadores. Ele integra as correções com o banco de dados relacional (PostgreSQL) e gerencia o fluxo de saneamento junto a outros módulos.
Importação via MTD: mecanismo que possibilita a ingestão de documentos e registros migrados fora do PJe/Eproc, permitindo correção, inclusão e alinhamento desses dados ao processo.
PostgreSQL: repositório dedicado, onde são armazenados o controle/auditoria dos dados saneados e retroalimentados, garantindo consistência e rastreabilidade.
Integração com Rudis: por meio da rudis-api, o Katarsis alimenta o ecossistema de governança e monitoramento de dados, enviando informações saneadas para o Rudis e, via Rudis-MQ, para as camadas de mensageria.

1.4 Aquila

1.4.1 O que é o Áquila ?

O Áquila é uma plataforma de gestão estratégica e monitoramento de indicadores de desempenho voltada ao atendimento das diretrizes do Conselho Nacional de Justiça (CNJ) e à governança interna dos tribunais. Ele se destaca como um sistema de apoio à gestão da qualidade, fornecendo mecanismos de acompanhamento, auditoria e planejamento orientados a metas.

1.4.2 Finalidade e objetivos

Gestão do Prêmio CNJ de Qualidade: permite mapear e acompanhar os itens exigidos pela premiação, associando cada indicador a artigos, incisos e eixos de governança definidos pelo CNJ.
Monitoramento de Conformidade: classifica os itens quanto ao tipo de pontuação (fixa ou gradual), forma de monitoramento (manual ou automático) e aplicabilidade, garantindo rastreabilidade dos critérios.
Diagnóstico e Auditoria: cada item pode receber diagnósticos, observações e trilhas de auditoria, assegurando que a evolução das ações esteja documentada e validada.
Plano de Ação: possibilita detalhar planos de ação vinculados a cada item, com responsáveis, prazos, cenários de pontuação (otimista, pessimista, CNJ) e recursos associados.
Gestão Colaborativa: promove o envolvimento de múltiplos perfis de usuários (gestores, técnicos, auditores), cada qual com níveis de acesso e responsabilidades específicas.

1.4.3 Principais funcionalidades

Cadastro e Filtros de Itens: pesquisa e gestão de itens vinculados a artigos, incisos e eixos (Governança, Produtividade, Transparência, Dados e Tecnologia).
Detalhamento de Item: exibição da descrição normativa, pontuação, aplicabilidade e tipo de monitoramento.
Controle Operacional: atribuição de responsáveis, substitutos e acompanhamento de períodos avaliativos.
Diagnóstico: registro de análises qualitativas e quantitativas por membros da equipe, com histórico documentado.
Planos de Ação: criação e acompanhamento de ações corretivas ou evolutivas, relacionadas diretamente a cada indicador.
Auditoria: camadas de verificação e validação para garantir integridade e consistência dos registros.

Em resumo, o Áquila atua como o núcleo de governança estratégica do tribunal, fornecendo um ambiente centralizado para:

estruturar indicadores do CNJ,
atribuir responsabilidades,
monitorar avanços,
auditar evidências, e
gerar insumos para decisões estratégicas de alta gestão.

2. Arquitetura de Implantação

Ambiente “Cloud Tribunal” (cluster Kubernetes):

EKS (ou K8s equivalente): orquestra os pods dos sistemas Áquila, Katarsis, Magma e Rudis em namespaces separados (ex.: aquila, katarsis, magma, rudis) com ConfigMaps/Secrets para parâmetros e credenciais.
Keycloak (SSO): provê identidade e acesso (OIDC/OAuth2) para os front-ends e APIs dos sistemas. Integra grupos/perfis (adm, servidor, técnico etc.).
RabbitMQ (mensageria): filas/resiliência para ingestão e processamento assíncrono (ex.: eventos do Rudis → Magma; saneamentos do Katarsis → Rudis).
Redis (cache/locks): acelera leituras, rate-limit e job locks.
PostgreSQL (WISIA-DB): banco operacional/analítico dos sistemas (modelos normalizados, fatos/dimensões, trilhas de auditoria).
S3 (objeto): armazenamento de artefatos (evidências, anexos, snapshots de indicadores, exportações MTD, etc.).
Bases Processuais (1G/2G – PJe/eProc): fontes de verdade internas do Tribunal, acessadas de forma somente leitura por extratores/purificadores (Rudis/Katarsis).

Integrações externas:

Cloud CNJ (Codex / Sinapses): consumo e/ou envio via HTTPS (MTD/Codex APIs) para conformidade e retroalimentação.
Cloud Wisia (Container Registry): pull de imagens assinadas (supply-chain) para deploys versionados no cluster do Tribunal.

Fluxos principais (alto nível):

Extração/Normalização: Rudis lê fontes internas (bases processuais; eventualmente S3 interno) e publica eventos em RabbitMQ; grava dados tratados no PostgreSQL.
Saneamento/Correção: Katarsis consome dados, cruza com regras (CNJ/DataJud) e opera fixes; para casos migrados, processa MTD; retroalimenta Rudis e, quando aplicável, volta ao PJe por integrações controladas.
Governança/Indicadores: Magma consolida métricas em tempo real (PostgreSQL + Redis), alimenta Power BI / painéis próprios e suporta o módulo Prêmio CNJ.
Gestão Estratégica: Áquila gerencia itens, diagnósticos, planos de ação, auditoria e perfis — tudo autenticado no Keycloak e cruzado com indicadores do Magma.
CNJ: envios/consultas ao Codex/Sinapses por HTTPS (mTLS/token), sempre outbound-only a partir do cluster.
Ciclo DevOps: imagens vêm do Container Registry (Wisia Cloud) com pull secrets e image policies.

3. FAQ - Perguntas Fequentes

1) “Como os elementos se comunicam internamente e com redes externas?”

Internamente: HTTP/HTTPS (APIs entre sistemas), AMQP (RabbitMQ), TCP 5432 (PostgreSQL), TCP 6379 (Redis), todos restritos por NetworkPolicies e SSO via Keycloak.
Externamente: HTTPS 443 para CNJ (Codex/Sinapses) e para Wisia Registry (pull de imagens). As bases processuais são internas e acessadas via DB read-only ou APIs internas.

2) “Se precisa falar com elemento interno do Tribunal, como funciona? Usuário de banco de dados ou API?”

As aplicações se comunicam conforme arquitetura, através de API e via banco de dados, módulos específicos fazem a comunicação direta via banco com a base do sistema processual, ou, em casos específicos poderão realizar acoplamento por API.
Preferência API interna (quando disponível) com OIDC (Keycloak).
Na ausência de API, usuário de banco read-only com allowlist e views dedicadas. Sem permissões DDL/DML fora do estritamente necessário.

3) “Quais as permissões mínimas?”

DB fontes: read-only por schema/tabela/view.
WISIA-DB: RW por schema do sistema, RO para BI.
RabbitMQ: vhost dedicado, publish/consume apenas nas filas do fluxo.
Redis: ACL por namespace de chaves.
S3: política por prefixo de bucket; somente o necessário.
Keycloak: scopes e roles mínimos por client.
CNJ: token/mTLS apenas para endpoints exigidos; egress 443 restrito.
Katarsis: único serviço que acessa diretamente a base de dados do sistema processual, necessita de RW em schema/tabelas específicos para realizar updates de correção.

4) “Onde está o código para rodar um scam de segurança?”

Para a execução de scans de segurança não é necessário acesso ao código-fonte. As avaliações são conduzidas sobre os artefatos implantados e os endpoints publicados, garantindo cobertura técnica e rastreabilidade:

Imagens/binários versionados (referenciados por tag + digest SHA-256) para SCA e container scanning.
Ambiente de homologação para testes dinâmicos , com usuários de teste.
Documentação Swagger/OpenAPI em todas as aplicações, expondo os endpoints para scan e validações (autenticação, autorização, headers, erros, etc.).

5) “Quais os licenciamentos de cada software?”

Terceiros (FOSS): Todos os componentes de terceiros empregados são software livre/código aberto e permanecem sob suas licenças originais (p.ex., MIT/Apache/BSD/GPL/AGPL, conforme o caso). A WISIA garante a conformidade de uso e repasse dos avisos/atribuições exigidos por tais licenças.
Aplicações WISIA: RUDIS, KATARIS, MAGMA e AQUILA são obras de titularidade da WISIA, com registro de programa de computador no INPI (proteção autoral).
Direitos concedidos ao Tribunal: Entrega de acesso integral ao repositório do código-fonte do release vigente na data da implantação final , documentação técnica, scripts de compilação e artefatos de infraestrutura (ex.: Docker/Kubernetes). Concessão de licença de uso perpétua, não exclusiva, irrevogável e gratuita para fins institucionais, com direito de estudar, modificar, compilar e implantar internamente sem royalties.
Restrições: Fica vedada a exploração comercial ou sublicenciamento a terceiros externos sem anuência da WISIA, ressalvadas as permissões já asseguradas por licenças open source de terceiros eventualmente incorporadas.

6) “Quais as versões dos softwares utilizados?”

As versões dos softwares utilizados correspondem sempre à última versão estável disponível nos repositórios oficiais de cada projeto na data da implantação/atualização. As versões exatas (número de versão, tag/commit e, quando aplicável, digest da imagem) constarão da Matriz de Versões entregue com o termo de aceite.

Observação: Sempre que houver linha LTS (Long Term Support), priorizamos a LTS mais recente; caso não exista LTS, adota-se a última release estável.