1. Processo Judicial Eletrônico (PJe)

1.1. Definição

O Conselho Nacional de Justiça (CNJ) iniciou, em 2009, o programa de desenvolvimento e implantação do sistema PJe no Poder Judiciário brasileiro. O objetivo dessa iniciativa é a completa implementação do processo judicial em meio eletrônico em todos os tribunais, nos seus mais diversos segmentos e competências. O instrumento para sua concretização é o sistema Processo Judicial Eletrônico (PJe).

O PJe é um sistema computacional desenvolvido pelo CNJ em parceria com diversos tribunais, Conselho da Justiça Federal (CJF) e Conselho Superior da Justiça do Trabalho (CSJT), além de contar com a contribuição do Conselho Nacional do Ministério Público (CNMP), da Ordem dos Advogados do Brasil (OAB), Advocacia‑Geral da União (AGU) e Defensorias Públicas.

Sob o aspecto de um software, o PJe caracteriza‑se pela proposição da prática de atos jurídicos e acompanhamento do trâmite processual de forma padronizada, mas considerando características inerentes a cada ramo da Justiça. Objetiva a conversão de esforços para a adoção de solução única e gratuita aos tribunais, atenta à racionalização de gastos com elaboração ou aquisição de softwares, permitindo o emprego de recursos financeiros e de pessoal em atividades dirigidas à missão do Poder Judiciário. O sistema funciona inteiramente pela Internet, possui distribuição gratuita aos órgãos do Judiciário, utiliza soluções tecnológicas open source e tem como diretriz a utilização de criptografia nos registros dos atos processuais, por intermédio de certificação digital no padrão ICP‑Brasil, de modo a garantir a integridade e a segurança das informações.

1.2. Histórico

O desenvolvimento do PJe foi iniciado pelo Tribunal Regional Federal da 5ª Região (TRF5). Posteriormente, a partir da atuação do CNJ, diversos outros tribunais celebraram acordos de cooperação técnica com o intuito de conjugar esforços entre os órgãos para o desenvolvimento do sistema, com adoção de estratégias tecnológicas que permitissem a utilização do software em todos os procedimentos judiciais de maneira configurável e flexível, respeitadas as características peculiares do trâmite processual de cada ramo da Justiça. No decorrer do processo de desenvolvimento, o CNJ deu conhecimento do projeto aos demais segmentos do Poder Judiciário, o que levou à adesão sequente dos Tribunais de Justiça dos estados, Tribunais de Justiça Militar Estadual, Justiça do Trabalho e, por fim, Justiça Eleitoral.

Em 2009, foi celebrado o Acordo de Cooperação Técnica n. 73/2009 entre o CNJ, o CJF e os cinco TRFs. O Acordo de Cooperação Técnica n. 43/2010 foi firmado entre o CNJ e 14 Tribunais de Justiça Estaduais.

1.3. Regulamentação

Em dezembro de 2013, foi aprovada a Resolução CNJ n. 185/2013, que instituiu o PJe como sistema nacional de processamento de informações e prática de atos processuais. A resolução estabeleceu parâmetros para a implementação e funcionamento do referido sistema e instituiu o Comitê Gestor Nacional do Sistema, no qual têm assento todos os segmentos do Judiciário, bem como os representantes dos principais usuários externos, em especial, CNMP, Conselho Federal da OAB, AGU e Defensoria Pública da União (DPU). Cada segmento de Justiça e também os tribunais possuem seus próprios Comitês, com a reprodução da representação externa.

1.4. Marcos temporais

Em 2014, o CNJ formou a primeira turma de desenvolvedores de software dos Tribunais de Justiça dos Estados aptos a contribuir para a codificação do sistema PJe. Tal iniciativa teve como finalidade a descentralização do trabalho de desenvolvimento do sistema que, até então, estava concentrado na equipe técnica do CNJ. O objetivo é que, a médio prazo, os tribunais possam manter equipes dedicadas ao desenvolvimento do PJe e que o time técnico do CNJ, nesse cenário, passe a atuar prioritariamente na gerência, orientação e validação das demandas e soluções implementadas pelos tribunais.

Em 2015, foi criada a Divisão de Gestão do Processo Judicial Eletrônico no CNJ, funcionando como estrutura organizacional específica para o tratamento das questões vinculadas ao programa PJe.

Em 10/3/2015, foi publicada a Portaria n. 26/2015, que institui a Rede de Governança do PJe.

1.5. Recursos necessários

A implantação do sistema PJe prevê a aquisição e a utilização de recursos de infraestrutura tecnológica de informação e comunicação, treinamento de magistrados e servidores de diversas áreas, bem como serviços de terceiros, passagens e diárias.

1.6. Utilização do Sistema

Atualmente, o PJe está em funcionamento em todos os ramos da Justiça, quais sejam Federal, Estadual, Trabalhista, Militar e Eleitoral.

O acesso a cada uma das implantações pode ser feito por intermédio do endereço: www.pje.jus.br/navegador.

Atualmente tramitam mais de 8,5 mil processos no sistema PJe, o qual já está implantado em 54 tribunais, quais sejam:

Segmento

Tribunais

Justiça Estadual

TJAM, TJBA, TJCE, TJDFT, TJES, TJGO, TJMA, TJMG, TJMT, TJPA, TJPB, TJPE, TJPI, TJPR, TJRN, TJRO, TJRR e TJRS

Justiça Militar

TJMMG, TJMRS e TJMSP

Justiça Federal

TRF1, TRF3 e TRF5*

Justiça Eleitoral

TSE, TRE/AM, TRE/GO, TRE/PB, TRE/RS e TRE/TO

Justiça do Trabalho*

TRT1, TRT2, TRT3, TRT4, TRT5, TRT6, TRT7, TRT8, TRT9, TRT10, TRT11, TRT12, TRT13, TRT14, TRT15, TRT16, TRT17, TRT18, TRT19, TRT20, TRT21, TRT22, TRT23 e TRT24

Dados de 16/11/16

*O TRF5 e os tribunais da justiça do trabalho utilizam uma versão própria do PJe, demais tribunais utilizam a versão nacional

1.7. Portfólio de projetos

A seguir, serão enumerados os projetos de caráter estruturante, outros voltados à expansão e ao aprimoramento do sistema e ainda projetos‑satélites.

  1. PJe 2.0

  2. Maratona PJe - apresentação de ferramentas tecnológicas que contribuíssem para a evolução do sistema PJe em sua arquitetura 2.0;

  3. Escritório Digital - integrar os sistemas processuais dos tribunais brasileiros, entre eles o PJe, e permitir ao usuário, especialmente aos advogados, centralizar em um único endereço eletrônico a tramitação dos processos de seu interesse;

  4. E‑carta - solução completa de comunicação, criada para atender às necessidades de empresas e de órgãos públicos quanto ao envio de documentos oficiais, tais como citações judiciais, comunicados e multas, que exigem sigilo no processamento de conteúdo e comprovação de entrega ao destinatário;

  5. Plenário Virtual - funcionalidade do PJe destinada à votação eletrônica dos processos, com a dispensa de sessão presencial e ampla publicidade dos julgamentos;

  6. PJe‑Office (Assinador Digital) - solucionar problemas de compatibilidade dos atuais navegadores de internet com a tecnologia da certificação digital por eles exigida (java plugin);

  7. Sistema Nacional de Videoconferências - ferramenta satélite e independente do PJe que permite a realização de reuniões e práticas de atos processuais como oitivas e interrogatórios, reduzindo‑se gastos com deslocamentos e outros suportados pelo Poder Judiciário;

  8. Sistema Nacional de Gravação de Audiências - solução de gravação audiovisual para registrar atos processuais, seu uso pode ou não ser integrado ao PJe;

  9. PJe Mídias - ferramenta para manutenção de mídias de um processo em local seguro, pela internet, de modo a permitir fácil acesso a todos os atores do processo, do ponto de vista interno e externo;

  10. Navegador PJe - versão personalizada do navegador Mozilla Firefox com os pré-requisitos necessários à utilização do sistema PJe nos tribunais brasileiros;

  11. Sistema de Execução Penal Unificado (SEEU) - ferramenta de controle unificado de toda a execução penal e das informações relacionadas ao sistema carcerário brasileiro em todo território nacional;

  12. PJe Estatístico - utilizado para coletar dados estatísticos a serem encaminhados obrigatoriamente por todos os órgãos do Poder Judiciário, e também para atender o Provimento n. 49/2015 da Corregedoria Nacional de Justiça, que instituiu e regulamentou o Módulo de Produtividade Mensal do Poder Judiciário dos juízes e serventias judiciárias.

2. Processo de desenvolvimento no PJE

2.1. Principais ferramentas

Jira – gerenciador de desenvolvimento de demandas http://www.cnj.jus.br/jira/issues/?filter=17405];

Git – sistema de controle de versões do código http://git.cnj.jus.br/pje/pje/merge_requests];

Jenkins – gerenciador de integração;

Slack – ferramenta de comunicaçãoda comunidade https://comunidadepje.slack.com/]];

Wildfly - servidor de aplicação http://wildfly.org/news/2015/10/26/WildFly902-Released].

2.2. Conhecimentos necessários e desejáveis

2.2.1. Necessários

  • Linguagem de programação Java;

  • Persistência com JPA e Hibernate;

  • Linguagem SQL do banco de dados PostgreSQL;

  • JSF; (PJE1)

  • Angular4+; (PJE2)

  • SpringBoot, SpringCloud; (PJE2)

  • JavaScript;

  • Wildfly 9.0.2;

  • Uso da ferramenta Eclipse.

2.2.2. Desejáveis

  • Uso da ferramenta Maven;

  • Uso das ferramentas Git e GitLab;

  • Padrões de projeto (design patterns);

  • JBPM;

  • Uso da ferramenta de controle de demandas JIRA;

  • Ter tido algum contato de uso com o sistema PJe.

2.3. Processo de desenvolvimento do PJe

image

2.3.1. Criar demanda

  • Nesta etapa a necessidade do tribunal é transformada em demanda no sistema gerenciador de demanda (Jira);

  • As demandas podem ser criadas tanto pelos tribunais, quanto por qualquer pessoa participante dos times envolvidos no desenvolvimento do PJe;

  • Antes da criação da demanda, deve-se fazer uma pesquisa preliminar no Jira em busca de demandas já relacionadas, demandas duplicadas ou até de informações de configuração para resolver a necessidade do tribunal.

2.3.2. Triar

  • Etapa de responsabilidade da equipe do CNJ;

  • É feita uma avaliação das informações mínimas de entendimento das demandas e se a necessidade já não está sendo atendida por outra demanda;

  • Uma pré-classificação é realizada e necessidades urgentes (normalmente relacionadas a problemas de produção) já são encaminhadas diretamente à equipe responsável para um atendimento prioritário, demais demandas seguem para a etapa de classificação e priorização.

2.3.3. Classificar

  • A classificação das demandas depende da prioridade dos tribunais, da complexidade e da sua criticidade;

  • A prioridade dos tribunais deve ser encaminhada no e-mail prioridade@cnj.jus.br e pode ser visualizada de forma consolidada no link: https://goo.gl/tiHR4c;

  • Demandas classificadas ganham uma ordem de classificação que pode ser verificada no campo Bussiness Value, a partir desta ordenação as demandas são encaminhadas a uma fila para serem desenvolvidas em uma das fábricas de desenvolvimento dos tribunais participantes do PJe Nacional.

2.3.4. Atribuir

  • Após a etapa de classificação a demanda aguarda a disponibilidade de uma das fábricas de desenvolvimento;

  • Havendo uma fábrica disponível ela é direcionada para o líder da equipe de desenvolvimento, a pessoa responsável pela distribuição interna e pelo acompanhamento do desenvolvimento das demandas;

  • Não há um padrão para a atribuição das demandas aos desenvolvedores dentro de cada fábrica:

    • Em algumas o líder da equipe repassa para seus desenvolvedores demanda por demanda;

    • Em outras o líder já aloca várias demandas a cada desenvolvedor;

    • Em outras os desenvolvedores têm liberdade de se vincular às demandas.

2.3.5. Desenvolver

  • Esta etapa também ocorre na fábrica de desenvolvimento dos tribunais e é de responsabilidade de cada desenvolvedor;

  • O desenvolvimento deve seguir os padrões do projeto, de acordo com as informações disponíveis na wiki do projeto em http://www.pje.jus.br/wiki/index.php/Desenvolvedor;

  • Os desenvolvedores devem ficar atentos ao campo “Sprint do grupo”, pois deve-se priorizar o desenvolvimento na seguinte ordem (do mais prioritário, para o menos): Urgente, Sprint 1.7.2.x, Sprint 2.0.x, Proxima Release, ficando atento às demandas “Rejeitadas pela homologação negocial”, “Solução recusada” ou “MR Reprovado”, pois estas são demandas já desenvolvidas que precisam de ajustes para serem entregues em definitivo;

  • O desenvolvedor deve ficar atento à descrição da própria demanda, às regras de negócio do projeto e caso haja o planejamento dos cenários de teste incluídos na issue do jira;

  • Ao final do processo de desenvolvimento, o desenvolvedor deverá:

    • abrir um novo MR no GIT para o branch 1.7.2.x ou master.2x_WF – com a identificação da issue do Jira;

    • transitar a issue (do Jira) para a situação “Homologação Técnica”;

    • Incluir evidência (preferencialmente um vídeo) exibindo o funcionamento da solução dada.

2.3.6. Revisar

  • Realizada pela equipe técnica do PJe do CNJ;

  • A etapa tem o objetivo de garantir a qualidade geral do código e de auxiliar na disseminação do conhecimento sobre as ferramentas do projeto entre os desenvolvedores;

  • Nesta etapa serão feitos testes gerais da solução e será cobrada a evidência e a explicação técnica da solução dada pelo desenvolvedor;

  • Mais detalhes deste processo e as boas práticas que são avaliadas encontram-se aqui;

  • Ao final desta etapa o revisor poderá solicitar ajustes ao desenvolvedor ou poderá aprovar a solução dada e integrá-la ao branch correspondente.

2.3.7. Planejar/Executar teste

  • Realizada pela equipe de testes terceirizada ou por tribunal voluntário no processo de homologação;

  • Tem por objetivo garantir que a demanda foi concluída atendendo aos requisitos propostos, observando o cumprimento ao que foi disposto na demanda e a ausência de impactos nocivos que por ventura não tenham sido detectados na fase de revisão;

  • Em caso de detecção de não cumprimento da demanda à sua proposta, seja por erro ou por inconformidade negocial a demanda deverá ser recusada. As justificativas para a recusa devem ser descrita, bem como deverá ser anexado vídeo evidenciando as inconformidades;

  • Feita a recusa, o testador submete a demanda ao desenvolvedor responsável.

2.3.8. Integrar

  • Tarefa realizada por desenvolvedores masters do PJe;

  • Quando a demanda já estiver homologada negocialmente e tecnicamente, ela estará passível de integração;

  • O processo de integração consiste na importação do código resultante de demanda para versões de estabilização;

  • As versões de estabilização se tornaram versões de produção após aprovação dos testes de integração

2.3.9. Homologar

  • O processo de homologação consiste na validação da versão estabilização como um todo;

  • Este passo é executado pela equipe de testes;

  • A partir da aprovação dos testes a versão está pronta para ser empacotada e distribuída.

2.3.10. Versionar

  • Realizada pela equipe técnica do PJe do CNJ;

  • Após a homologação a versão é fechada, ganha uma numeração com padrão 2.x.y.z;

  • É criada uma tag de versão;

  • O pacote da versão é formado com os war e ear da versão, banco de dados limpo, scripts de migração e release notes.

  • O pacote é disponibilizado nos canais de acesso dos tribunais (ftp e owncloud);

  • Os tribunais são notificados sobre o lançamento da versão, suas melhorias e correções.

2.4. Fluxo de lançamento de versões

Estamos utilizando o Gitflow Workflow que foi desenvolvido e foi publicado pela primeira vez por Vincent Driessen. O Gitflow Workflow define um modelo de branches desenvolvido para as releases de projetos, provendo um framework robusto para o gerenciamento de grandes projetos. Pode-se encontrar mais informações sobre essa abordagem aqui e aqui.

Imagem gitflow

2.4.1. Branchs principais

O repositório central do CNJ armazena dois branches principais e perenes: Imagem main branches

  • master

  • develop

Considera-se o branch origin/master o branch do qual o código da sua cabeça HEAD sempre refletirá um estado pronto para produção.

Considera-se o branch origin/develop o branch do qual o código da HEAD sempre refletirá um estado com as últimas alterações aprovadas para a próxima release. Pode-se chamá-lo de "branch de integração". A partir daqui derivam-se os branches candidatos à nova versão (release branches).

Quando o código integrado ao branch develop chegar a um ponto de estabilização e estiver pronto para ser lançado, todas as alterações deverão ser mergeadas diretamente no branch master e com isso deverá ser gerada uma nova tag com final .0, por exemplo: 2.1.3.0. Falaremos deste processo com detalhes mais a frente.

Toda vez que houver um novo merge no branch master, por definição, pode-se lançar uma nova versão de produção. E, em teoria, podemos criar gatilhos para lançar essa nova versão, disponibilizar o binário e comunicar aos servidores de produção dos tribunais sempre que isso acontecer, para que sejam atualizados automaticamente.

2.4.2. Branchs de suporte

Auxiliando os branchs principais master e develop, nosso modelo de desenvolvimento utiliza outros tipos de branchs de suporte para permitir o desenvolvimento das demandas, a estabilização das releases e para auxiliar na rápida resolução de problemas em produção. Diferentemente dos branchs principais, os branchs de suporte não são perenes e devem ser removidos em algum momento.

Os principais tipos de branch que deverão ser utilizados são:

  • feature branches

  • release branches

  • hotfix branches

Cada um desses branches possui um propósito e segue regras específicas, como qual deve ser seu branch originário e para quais branchs devem ser feitos seus merges.

Feature branches

Imagem feature branches

Propósito

O feature branch é efetivamente o branch no qual será feito o desenvolvimento das issues, uma vez que ao desenvolvedor foi atribuída uma issue no Jira e este a colocou na situação "Em progresso", deverá criar o novo branch com a identificação da issue, exemplo: PJELEG-123, fazer o desenvolvimento e ao final submeter o merge ao branch develop. O branch será removido quando, eventualmente, seu código for integrado ao branch develop ou caso seu código seja descartado por algum motivo.

Regras do branch
  • Cria-se a partir de: branch develop

  • Submete-se o merge request ao: branch develop

  • Convenção de nome do branch: <NÚMERO-DA-ISSUE><Texto_complementar_opcional>, exemplo: PJELEG-123 ou PJELEG-123_meu-feature-branch

  • Regras de revisão: O grupo revisor dos tribunais deverá realizar a revisão do código submetido, seguindo o modelo estabelecido pelo próprio grupo revisor.

Release branches
Propósito

Ao final da sprint de revisão do grupo revisor, gera-se uma TAG no branch develop (essa TAG terá o nome: "`<NÚMERO-RELEASE-PRETENDIDA>-RC`, exemplo: 2.1.3.0-RC ") e a partir dessa TAG o novo release branch (esse branch terá o nome: release-<NÚMERO-RELEASE-PRETENDIDA>, exemplo: release-2.1.3.0).

O release branch oferece suporte à preparação da nova release de produção. Este branch permite que se faça os últimos ajustes no código e pequenas correções de estabilização para que seja possível o lançamento da nova versão de produção. Fazendo essas atividades diretamente no release branch o branch develop fica liberado para receber a integração de outras features da nova sprint de revisão.

Quando é criado o novo release branch inicia-se uma nova sprint de estabilização da release. Recomenda-se que todos os tribunais tenham um ambiente com a cópia da base de produção e que seja atualizado automaticamente na criação e atualização desses release branches.

Problemas impeditivos identificados durante a estabilização da versão candidata deverão ser registrados em issue de tipo específico "Bugfix release". Importante frisar que somente devem ser considerados "Bugfix releases" os erros graves que impeçam o usuário de completar uma tarefa ou abrir uma tela ou, ainda, aqueles que causem grande dano à tramitação do processo, como erros no protocolo de processos ou no agendamento periódico de prazos, por exemplo. Outros tipos de problemas (menos danosos) deverão ser registrados no Jira com o tipo 'Defeito' e seguir o fluxo já estabelecido.

As demandas criadas durante a estabilização da versão como "Bugfix releases" deverão ser corrigidas preferencialmente pelo mesmo tribunal que as identificou. No entanto, caso o tribunal não tenha condições de faze-lo, o grupo revisor será o responsável. O MR será direcionado ao branch da release (release-<NÚMERO-RELEASE-PRETENDIDA>) e seguirá como prioridade para a revisão dos demais membros do grupo revisor.

Ao final da sprint de estabilização da release (com sugestão de 2 semanas), se não houver nenhum "Bugfix release", a release estará automaticamente homologada (por todos os tribunais que fazem parte do projeto PJe) e será lançada a nova versão. Nesse momento, o coordenador do grupo de nacional de revisão solictará ao CNJ que seja gerada a versão oficial. O CNJ, por sua vez, realizará o merge do release branch no branch master e automaticamente no branch develop, também será lançada a TAG oficial da versão no branch master, no exemplo: 2.1.3.0.

Regras do branch
  • Cria-se a partir de: branch develop

  • Submete-se o merge request ao: branches master e haverá um procedimento automático para replicá-lo ao branch develop

  • Convenção de nome do branch: release-<NÚMERO-RELEASE-PRETENDIDA>, exemplo: release-2.1.3.0

  • Regras de revisão: Os tribunais deverão homologar a aplicação de forma geral e verificar se as funcionalidades principais estão estáveis o suficiente para que seja lançada a nova release. O grupo revisor dos tribunais deverá realizar a revisão das alterações de estabilização de forma prioritária.

Hotfix branches

Imagem Hotfix branches

Propósito

Hotfix branches são parecidos com os release branches em termos de que são preparações para novas releases de produção, apesar de não serem planejados. Esses branches surgem da necessidade de se agir rapidamente frente a um estado não desejado da aplicação na versão de produção. Quando um problema crítico na versão de produção precisa ser resolvido imediatamente.

Durante a correção do problema crítico libera-se a equipe para continuar trabalhando na revisão/integração das features no branch develop, enquanto outra pessoa prepara uma rápida correção da versão de produção.

Os problemas graves encontrados em produção e que precisam ser corrigidos rapidamente deverão ser registrados no Jira com o tipo "Hotfix" e sua correção deverá ser submetida ao branch master para revisão do grupo revisor em prioridade máxima. Quando for integrada a correção deverá ser lançada uma nova release de Hotfix, cuja numeração variará sequencialmente o último número da última release, ex.: 2.1.3.1, 2.1.3.2, 2.1.3.3 …​

O proprio tribunal que reportou o defeito crítico deverá preferencialmente codificar a correção; para os tribunais que não tenham desenvolvedores disponíveis, a equipe de revisão de código deverá tratar o problema com prioridade.

Regras do branch
  • Cria-se a partir de: branch master

  • Submete-se o merge request ao: branches master e um procedimento automático replicará aos branches develop e release-<NÚMERO-RELEASE-PRETENDIDA> em andamento

  • Convenção de nome do branch: <NÚMERO-ISSUE>, exemplo: PJELEG-4321

  • Regras de revisão: Os tribunais deverão homologar a aplicação de forma geral e verificar se as funcionalidades principais estão estáveis o suficiente para que seja lançada a nova release. O grupo revisor dos tribunais deverá realizar a revisão das alterações de estabilização de forma prioritária.

3. PJE2.0

3.1. Apresentação

Nos anos de 2011 a 2012, houve grande e acelerada expansão do PJe, principalmente na Justiça do Trabalho, o que agravou problemas que afetaram principalmente o desempenho do sistema. No período, as equipes técnicas identificaram a necessidade de definir novo modelo arquitetural sustentável para o PJe, alicerçado com atributos de qualidade como testabilidade, manutenibilidade, escalabilidade e segurança. Além disso, o sistema precisava conter requisitos que facilitasse a sua utilização, ou seja, com design voltado principalmente para a facilidade de uso (usabilidade) e com desenho universal (acessibilidade).

Um dos problemas de desempenho detectado foi a baixa performance da aplicação, que vinha comprometendo diretamente o seu uso, afetando negativamente a satisfação e a produtividade do usuário. Outro problema dizia respeito à dificuldade de se testar o sistema, desde o nível negocial, que é o que atesta o correto funcionamento, até o nível técnico. Merece referência também o fato de o sistema ter sido construído com excessivo acoplamento entre os seus diversos módulos, prejudicando sobremaneira a sua manutenibilidade, já que não há uma clara divisão entre as camadas da arquitetura, além do fato de simples modificações realizadas em parte do sistema causarem impacto grande em outras.

Segundo estatísticas mais recentes, o total de demandas judiciais em tramitação chegou perto dos 100 milhões em 2014. Naquele ano, praticamente uma em cada duas ações judiciais (45%) ingressou na Justiça em meio virtual. Ao todo, 11,8 milhões de processos começaram a tramitar eletronicamente.

Se, por um lado, havia a necessidade de rever a arquitetura do PJe, por outro, diversos tribunais já o utilizavam como principal sistema de acompanhamento processual, tornando‐se complexa a evolução do sistema em plena operação. Além disso, apesar de o PJe ter sido desenvolvido com vistas a ser único em todo o Judiciário, as dificuldades enfrentadas no dia a dia das implantações levaram a intervenções que implicaram versões diferentes e com consequente prejuízo ao aproveitamento de inovações tecnológicas aproveitáveis a todos.

Avaliados os cenários, o Comitê Gestor Nacional do PJe decidiu pela construção de uma nova versão do PJe, com o envolvimento de todos os segmentos de Justiça. Nesse cenário, as versões atuais continuariam em produção sem qualquer manutenção evolutiva, apenas corretiva; as novas funcionalidades seriam implementadas apenas na nova versão, cujos módulos poderiam ser gradativamente ativados em paralelo à versão atual.

3.2. Objetivos

  • Revisar e definir um modelo arquitetural sustentável para o PJe em médio e longo prazo, com atributos de qualidade como testabilidade, manutenibilidade, escalabilidade e segurança;

  • Unificar as versões implementadas nos diversos segmentos de Justiça;

  • Garantir a continuidade do sistema até a implementação da nova versão pelos tribunais;

  • Tornar o sistema mais amigável e acessível;

  • Facilitar a construção e evolução colaborativa do sistema.

3.3. Arquitetura - PJe 2

A nova arquitetura do PJe foi pensada para ser modular e permitir a substituição gradativa da implementação em JSF (PJe1) pela implementação em AngularJS (PJe2). Assim, atualmente cerca de 95% da versão 2.0 do PJe ainda é composta pela mesma arquitetura da versão do PJe1. O PJe 2 possui uma arquitetura baseada em serviços. Pensando nos erros identificados na arquitetura do PJe 1, o PJe 2 foi pensado em ser modular de maneira a minimizar efeitos adversos na dinâmica do processo de desenvolvimento, tal como o efeito borboleta, muito comum no processo de desenvolvimento do PJe 1.

No PJe 2 os serviços são expostos através de EJBs remotos. Fachadas REST dão acesso aos módulos negociais do sistema. Isso permite um acesso universal multiplataforma aos serviços (WEB, mobile, desktop).

Imagem

3.4. Separação em camadas

Seguindo o modelo MVC o PJe 2 utiliza o AngularJS nas camadas de visão e controle. O restante da aplicação faz uso de tecnologias Java.

Image

3.5. Problemas da arquitetura na prática

Alguns problemas começaram a ser notados mesmo na nova arquitetura proposta e implementada pelo CNJ. A modularização buscada até então não estava servindo de baseline para escalar o processo de desenvolvimento, de modo a desidratar o PJe 1.x e ao mesmo passo hidratar o PJe em seus módulos negociais.

As fachadas REST estavam começando a se tornar grandes controllers e repetiam muitas vezes códigos que estavam na controller da camada de visão angular. Verificou-se grande acoplamento entre o angular e sua fachada REST. Outro problema era a dificuldade em delimitar o escopo dos módulos negociais, desta maneira era difícil se identificar onde cada funcionalidade migrada do PJe 1 se encaixaria no PJe 2.

Tecnologias elencadas para o desenvolvimento da nova versão não permitiam uma escalabilidade horizontal, de modo que continuava sendo um monolito, não permitindo uma racionalização mais adequada dos recurso de infraestrutura. Os tribunais, por exemplo, continuariam tendo que fazer deploy de todo o monolito em uma mesma configuração de infraestrutura.

Outro fator problemático da primeira implementação do PJe 2 estava na burocracia de comunicação entre o PJe 1 e o PJe 2. Havia um excesso de lookups entre os serviços para resolver questões de autorização. Haviam ainda serviços do PJe 2 que consultavam serviços do PJe 1 em suas camadas DAO, isso tudo tornava a interação entre as versões algo muito complexo e passível de erros de difícil identificação.

A camada angular estava obrigada a ser disponibilizada no mesmo deploy do PJe 2, o que, mais uma vez representava uma limitação na racionalização dos recursos de infra.

4. PJe 2.1 - Uma nova proposta arquitetural

Tendo sentido na pele todos estes problemas, a equipe do CNJ começou uma grande discussão interna sobre os avanços e dificuldades que o PJe 2 nos trazia numa perspectiva de futuro. Apesar dos problemas citados a nova arquitetura também nos trouxe boas perspectivas a respeito da abordagem ao problema. Algo notório é que sim, é possível migrar aos poucos os recursos do PJe 1 para uma nova arquitetura mais enxuta e com novas tecnologias. É indiscutível que o PJe precisa se renovar para abarcar o volume de processos e usuários que o sistema se propõe a atender, assim como não se discute que as tecnologias utilizada na versão 1 não darão conta por muito mais tempo da demanda que nosso sistema recebe diariamente. A arquitetura modular monolítica proposta inicialmente resolvia alguns problemas, mas ainda era permissiva com erros do passado. Os módulos não tinham escopos negociais bem definidos, o que permitiria que desenvolvedores acabassem por fugir ao escopo sempre que se vissem em alguma dificuldade para resolução de um problema. Esse tipo de abordagem ao código é o fator causador de diversos problemas enfrentados no PJe 1, as classes não possuem escopos bem definidos e portanto não é difícil notar, por exemplo, métodos de escopo do processo que fazem alterações a outras entidades do sistema, que nada têm a ver com aquele contexto negocial. Todo esse panorama nos direcionou a estratégia de desenvolvimento de um sistema baseado em micro serviços. Um sistema modular, mas não monolítico. A ideia é que cada escopo negocial bem definido seja envolto em um micro serviço. Por exemplo, poderíamos extrair toda a lógica negocial de audiências do PJe 1 e criar um serviço totalmente separado, com projeto separado, deploy separado e banco de dados separado. Esse serviço seria implementado e o PJe 1 se tornaria um cliente desse serviço para realizar atividades, como, marcar uma audiência, consultar audiências e etc. Este tipo de abordagem permite que a implementação esteja focada naquele contexto negocial, facilitando o trabalho das equipes de negócio, desenvolvimento e testes. Outro benefício está na racionalização dos recursos tecnológicos, permitido ao tribunal que reserve para o serviço somente a quantidade adequada de recursos computacionais para que o serviço se comporte de maneira saudável. O PJe passa, portanto a se comportar como um sistema mais moderno, dono de uma API REST composta por sua nuvem de serviços. Serviços estes que poderão ser disponibilizados para o público externo que deseje consumir os serviços através de aplicações mobile ou outros tipos de aplicações.

4.1. A interação entre os serviços

Cada contexto negocial terá portanto seu micro serviço, mas como estes serviços se comunicaram entre si? Muitas vezes o serviço de sessão de julgamento produzirá uma informação dizendo que o processo foi julgado, e neste momento o serviço de processo judicial deverá lançar uma movimentação.

Este tipo de interação irá funcionar como uma coreografia, onde cada serviço sabe exatamente o que fazer conforme as informações surgem em seu ecossistema. As informações serão passadas aos serviços através de um serviço de filas de mensagens, sempre que um processo for julgado o sistema de sessão irá enviar ao serviço de fila uma mensagem com informações referentes aquele julgamento. Neste momento um serviço será responsável por consumir a fila e redirecionar as mensagens a outros serviços através de uma estratégia baseada no conceito de webhooks. Um ou vários serviços estarão inscritos para receberem as mensagens para um dado evento, o serviço de webhooks será responsável por inscrever os serviços e direcionar as mensagens. Quando o serviço de processo receber a mensagem via webhook ele deverá saber que é necessário lançar uma movimentação no processo, após isso ele também deverá notificar ao serviço de mensagem que uma nova movimentação foi lançada, de modo que os serviços que se interessam por movimentações ajam como devem agir.

É importante que todo esse ecossistema funcione como uma nuvem de serviços, de modo que seja possível que o tribunal crie, por exemplo duas instâncias do serviço de consulta processual, ou até mais caso a demanda deste serviço cresça. Para isso é necessário um mecanismo de descoberta de serviços. Cada vez que iniciamos um serviço ele deve se registrar como um serviço ativo, esperando requisições de clientes. Este tipo de mecanismo funciona como um DNS e permite distribuir as requisições de maneira mais racional utilizando, por exemplo, um algoritmo round robin.

4.2. Um cliente para o PJe

Todos esses serviços precisam ser disponibilizados para o usuário, e para isso não usaremos mais o AngularJS, e sim o Angular que está em sua versão 4. A decisão de partir para a nova versão do Angular se motiva pelas grandes melhorias implementadas na versão, pela flexibilidade do TypeScript, pela rápida adoção da comunidade e pela baixa quantidade de código legado em angularJS no PJe 2.

O novo cliente angular estará totalmente separado e desacoplado dos serviços. Ele deverá se comportar como um cliente externo qualquer do sistema, utilizando-se da API de serviços do PJe.

Enquanto convive com o PJe 1, o nosso cliente Angular irá residir em um singelo iframe e talvez necessite se comunicar com a tela do PJe 1, como estarão em domínios separados a interação será efetivada através de mensagens entre janelas.

A nova versão do angular é baseada em componentes, o que nos permitirá criar um arcabouço de componentes que visem facilitar a implementação padronizada das telas do PJe, tendo como base a acessibilidade e experiência do usuário.

4.3. Como tudo se conecta?

image

Descrevendo o diagrama acima temos o Angular 2+ como porta de entrada, cliente onde o usuário terá acesso aos vários serviços do PJe. O cliente angular irá acessar a API REST através de um serviço de borda, denominado “Gateway”. O Gateway nada mais é do que um serviço dentro da nossa nuvem de serviços, este conhece todos os outros e servirá de encaminhador das requisições do cliente.

Cada serviço, ao ser iniciado, se registra no “Discovery” informando que está disponível para aceitar as requisições. O Discovery também se encarrega de realizar load balancing entre os serviços registrados, desta maneira, se temos três instâncias de Processo, nesse serviço Discovery irá distribuir as requisições, de modo a não carregar uma mais que as outras.

O serviço OAuth2 se encarrega de controlar o acesso de usuários e serviços aos serviços da nuvem, sendo possível restringir o acesso a determinados serviços de acordo com as credenciais do usuário ou sistema.

Podemos perceber que cada micro serviço terá um contexto bem definido, inclusive sendo dono de seu próprio banco de dados, o qual poderá utilizar da tecnologia mais adequada para atender a proposta daquele serviço. Portanto não será mandatório que se use sempre um banco de dados relacional, por exemplo.

Os serviços irão ainda lançar seus logs para uma pilha ELK (Elastic, Logstash e Kibana). Os logs deverão observar não somente questões relacionadas a erros, mas também a sucesso das operações. Deste modo será possível avaliar a saúde dos serviços, se estão respondendo rápido, ou se estão muito lentos e com erros e precisam, portanto, de uma refatoração ou melhoria.

Como mencionado antes, os serviços funcionaram em modo de coreografia, onde cada serviço sabe bem o que fazer de acordo com o que acontece na nuvem. O RabbitMQ é um Message Broker que se responsabilizará por enfileirar as mensagens. Estas serão consumidas pelo serviço de webhooks que se encarregará de distribuir para os diversos serviços de nossa nuvem.

Sim, aquilo ali no topo é o PJe 1. Entenda o PJe 1 como um serviço também. Temos um serviço monolítico com muitas coisas que ainda não sabemos separar, portanto, inicialmente a versão legada servirá como um serviço sim, compondo a nova nuvem de serviços do PJe. A ideia é que a cada serviço “novo” criado o PJe legado se tornará um pouco menor. É importante dizer ainda, que o legado deverá se comportar como os outros serviços, escutando as filas do RabbitMQ, mandando mensagens para o RabbitMQ e autenticado através do serviço de autorização.

4.4. Estruturando um módulo/micro serviço

Cada módulo, ou micro serviço, terá seu próprio domínio. Cada um deverá ser responsável por resolver um problema. A construção de módulo será iniciada pela equipe de negócio, que definirá um contexto bem definido para aquele pretenso serviço. Os requisitos negociais serão elicitados e a partir daí a equipe técnica começa a atuar.

A primeira tarefa da equipe técnica é definir a fachada REST, que irá prover as funcionalidades a serem acessadas pela camada de visão ou por outros módulos do PJe, ou ainda por outros sistemas externos.

Definidas as funcionalidades daquele novo serviço a equipe inicia a implementação do backend. Perceba que neste momento é possível que haja paralelismo entre a equipe que desenvolve o backend e a equipe que irá desenvolver o frontend. Inclusive é encorajador que se adote uma abordagem paralela. Equipes distintas trabalhando para frontend e backend evitarão acoplagem do serviço ao frontend, resultando em um serviço mais puros e enxutos que pode ser utilizado por outros sistemas, inclusive.

A dimensão de cada serviço pode ser variável. É importante que não sejam muito grandes nem muito pequenos. Um universo de muitos serviços pequenos pode tornar a coreografia dos serviços algo muito complexo de se manter, cada pequena alteração pode impactar em uma grande necessidade de reimplementação nos demais serviços. Os serviços também não devem ser grandes demais, um serviço muito grande representa algo que está tratando muitos problemas e acaba por se tornar um novo monolito.

O tamanho de um serviço é ideal quando, caso queiramos implementar todo o serviço, o tempo de codificação não passe de duas semanas. Certamente isso não é uma regra, mas uma notação a ser levada em consideração ao implementar novos serviços.

Cada micro serviço terá arquitetura simples, de modo a atender o seu contexto negocial. Dada a complexidade majorada de um determinada serviço, este pode ter um leve alteração arquitetural para atender a seu contexto. A abordagem de micro serviços permite um ambiente totalmente agnóstico de ponta a ponta, entretanto ter cada pedaço com uma tecnologia diferente torna a manutenção do sistema muito dependente de pessoas ou equipes específicas.

image

4.5. Tecnologias aplicadas

4.5.1. SpringBoot

O SpringBoot é uma solução criada pela Pivotal para entregar uma aplicação Spring de maneira rápida e que esteja pronta para produção, sem que haja necessidade de um monte de configurações como acontece muito em aplicações java para WEB. Com um simples java -jar, por exemplo, é possível iniciar uma aplicação java web com um tomcat embarcado, sem necessidade de executar deploy de um arquivo war. Esse tipo de solução colabora na escalabilidade horizontal e na entrega contínua.

4.5.2. SpringCloud

SpringCloud é o conjunto de ferramentas que possibilita um desenvolvimento rápido dos principais padrões de computação distribuída. O SpringCloud se integra aos serviços SpringBoot para prover um ambiente distribuído interligado utilizando suas bibliotecas para descoberta de serviços, roteamento, circuit-breakers, e etc. Entre as bibliotecas disponibilizadas estão as que dão suporte à suite Netflix para computação em nuvem.

  • Eureka

    • Serviço REST utilizado como service register. Cada serviço ao ser iniciado se registra no Eureka Server que será responsável por manter um catálogo de serviços ativos. Através deste catálogo é possível atribuir outros comportamentos ao sistema, como load balancing e circuit break;

  • Zuul

    • Serviço de borda, que tem como principal função ser um ponto único de entrada, distribuindo as requisições entre as diversas instâncias de serviços que estão registrados em sua nuvem

  • Hystrix

    • Faz o papel de monitorador dos serviços mantendo um conjunto de dados com informações a respeito da execução dos serviços. É seu papel também operar o circuit break;

4.5.3. Angular 6+

Tecnologia para a camada de apresentação, o Angular em sua nova versão traz diversas melhorias identificadas a partir do feedback da comunidade em relação a sua amplamente utilizada primeira versão. A nova versão traz inovação na forma como compor a aplicação frontend através de componentes. Há também uma grande flexibilidade trazida através da utilização da linguagem TypeScript. O Angular tem grande aceitação de comunidade e mostra importantes inovações relacionadas a performance das aplicações desenvolvidas na nova versão.

4.5.4. RabbitMQ

Message broker responsável por prover o meio através do qual os serviços irão compor o coreografia do sistema. O RabbitMQ suporta diversos protocolos de mensageria, é capaz de ser executado de maneira distribuída e é altamente escalável, tudo isso colabora para uma alta disponibilidade que um broker deve ter para manter a coreografia entre os serviços.

4.6. Mais PJe 2.1 e menos PJe 1.x

A nova arquitetura do PJe 2 foi pensada para que a transição de tecnologia se desse de maneira gradual. Para isso é necessário que funcionalidades que hoje estão no PJe 1 sejam migradas para a nova arquitetura. Há que se notar, entretanto, que essa tarefa não é das mais triviais, ainda mais quando se fala de um sistema do porte do PJe.

Sua natureza caracterizada pela complexidade negocial evidencia que esse tipo de transição não será simples, e demandará um grande esforço das equipes técnicas do PJe.

A dificuldade se inicia pela dificuldade em enxergar os contextos negociais dentro do sistema. Passando por isso ainda temos o grande acoplamento entre as camadas na arquitetura atual do PJe 1. As classes representa muitos contextos de negócio ao mesmo tempo, resultando assim em um grande emaranhado de dependências entre as entidades do sistema.

O primeiro passo para "emagrecer" o PJe 1 está na identificação dos serviços de infraestrutura que estão no código da aplicação. Serviços como autenticação, log, armazenamento de binários, e outros. Estes serviços possuem contextos mais bem definidos, e por consequência possuem menos dependências e acoplamento ao código.

Os módulos negociais que estão atualmente dentro do PJe 1 passarão por um processo de reestruturação lógica dentro do próprio legado, para somente após esse passo se tornar um micro serviço com vida própria.

O processo de reestruturação lógica consiste no isolamento das classes que tenham relação com o domínio analisado. Na prática o que ocorrerá é a separação das classes em pacotes específicos daquele contexto negocial. Neste momento serão identificadas dependências e duplicidades. A partir dessa visão mais isolada poderemos também reconhecer melhor o que faz e o que não faz parte daquele contexto de negócio.

É neste momento que identificaremos também as dependências a nível de banco de dados. A separação lógica das classes servirá de base para que possamos isolar as tabelas e identificar suas constraints. Mapear as dependências entre as entidades nos dará a visão de quais entidades ou quais domínios possuem uma relação direta ou indireta com o domínios em análise, isso nos servirá, por exemplo, para identificar outras entidades que façam parte do contexto de negócio que estamos tentando destacar do PJe.

Após esse primeiro momento ocorrerá a construção do novo micro serviço que se preocupará apenas em atender aquele contexto bem definido identificado no passo anterior. O novo serviço terá seu próprio domínio, e por isso não terá que se preocupar com impactos em outros pontos do sistema.

Com o novo micro serviço pronto a próxima etapa é retirar aquele código do legado. Se a tarefa de separação lógica do domínio tiver sido bem executada esse passo não deverá ser problemático, tendo em vista que o domínio foi logicamente isolado, o que se deve fazer é remover as classes pertinentes. Caso seja necessário o legado deverá expor um serviço para receber eventos do novo módulo, de modo a tratar aquele evento e utilizá-lo de acordo com seu domínio de negócio.

5. Configurando o ambiente de desenvolvimento PJeLegacy (.war) com Eclipse

5.1. Pré-requisitos mínimos do sistema

  • Java JDK 8 (Oracle ou OpenJDK)

  • Eclipse IDE

  • PostgreSQL 9.4 ou superior

  • Apache Maven 3

  • Wildfly 9.0.2 com mojarra 1.2

  • Docker 18.09 ou superior

  • Node 8 ou superior

  • NPM 6 ou superior

  • Git client

5.2. Configurações do Maven

No diretório raiz do usuário será necessário alterar/criar o arquivo settings.xml que se encontrar na pasta .m2.

$ cd ~/.m2
$ touch settings.xml

Incluir o seguinte conteúdo no arquivo settings.xml

settings.xml
<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <servers>
        <server>
            <username>NOME_DE_USUARIO_DO_ARTIFACTORY</username>
            <password>SENHA_DE_USUARIO_DO_ARTIFACTORY</password>
            <id>central</id>
        </server>
        <server>
            <username>NOME_DE_USUARIO_DO_ARTIFACTORY</username>
            <password>SENHA_DE_USUARIO_DO_ARTIFACTORY</password>
            <id>snapshots</id>
        </server>
        <server>
            <id>pje-descanso</id>
            <username>NOME_DE_USUARIO_DO_BANCO</username>
            <password>SENHA_DE_USUARIO_DO_BANCO</password>
        </server>
    </servers>
    <profiles>
        <profile>
            <repositories>
                <repository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>central</id>
                    <name>repo</name>
                    <url>http://www.cnj.jus.br/artifactory/libs-releases-local</url>
                </repository>
                <repository>
                    <snapshots />
                    <id>snapshots</id>
                    <name>repo</name>
                    <url>http://www.cnj.jus.br/artifactory/repo1</url>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>central</id>
                    <name>repo</name>
                    <url>http://www.cnj.jus.br/artifactory/libs-releases-local</url>
                </pluginRepository>
                <pluginRepository>
                    <snapshots />
                    <id>snapshots</id>
                    <name>repo</name>
                    <url>http://www.cnj.jus.br/artifactory/repo1</url>
                </pluginRepository>
            </pluginRepositories>
            <id>artifactory</id>
        </profile>
        <profile>
            <id>pje-descanso</id>
            <properties>
                <flyway.serverId>pje-descanso</flyway.serverId>
                <flyway.driver>org.postgresql.Driver</flyway.driver>
                <flyway.url>jdbc:postgresql://localhost:5432/BANCO_DO_PJE</flyway.url>
            </properties>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>artifactory</activeProfile>
    </activeProfiles>
</settings>

5.3. Configurações do SGBD Postgresql

Configurando o arquivo postgresql.con

É necessário aumentar o parâmetro max_prepared_transactions do arquivo de configuração do postgres postgresql.conf:

$ locate postgresql.conf
$ cd /etc/postgresql/9.1/main
$ sudo gedit postgresql.conf

Colocar um valor maior que 20.

Criando um banco de dados novo

Criar um novo banco com os parâmetros conforme abaixo:

image

image

Restaurar um dump no novo banco criado:
$ psql -U postgres -h localhost -d pje < "~/Dumps/dump.sql"

ou

$ pg_restore -U postgres -h localhost -v -Fc -d nome_base arquivo.dump

5.4. Configurações do servidor de aplicação Wildfly

O servidor Wildfly a ser utilizado deve conter o módulo Mojarra 1.2.

Com o intuito de facilitar a configuração do servidor wildfly ou Jboss EAP a partir do zero para o PJe 2.x, copie o arquivo http://ftp.cnj.jus.br/pje/programs/config_pje_wildfly_jboss.zip para um diretório, descompacte-o e execute o interface da linha de comando do jboss/wildfly (jboss-cli.sh) a partir do diretório descompactado criado. O motivo para executar dentro do diretório criado se deve ao fato que dentro do arquivo compactado existem 2(duas) adições ao subsystem module do wildfly/jboss a saber: 1) o driver jdbc do postgres e 2) mojarra 1.2. Desta forma, esses dois arquivos devem estar no mesmo diretório do arquivo pje-wildfly.cli!

Os servidores de aplicação não devem ter nenhuma alteração.
Sempre usar a configuração full do wildfly/jboss

Execute o comando:

<JBOSS_HOME>/bin/jboss-cli.bat -c --file=pje-wildfly.cli

Se o comando executou com sucesso, deverá aparecer a seguinte mensagem do jboss-cli:

	The batch executed successfully
process-state: reload-required
Reinicialize o wildfly/jboss.

Apenas mais alguns pontos para observar:

Configurar a memória da VM do java para o servidor wildfly/jboss pois a configuração padrão é insuficiente para o PJe
Adicionar o parâmetro -noverify na configuração da VM do Wildfly, em Open Launch Configuration
Alterar manualmente o datasource para o banco de dados desejado.

O arquivo de standalone-full.xml deve ser utilizado para subir o servidor de aplicação.

Incluir os datasources no standalone-full.xml:

settings.xml
<datasource jndi-name="java:/pjeQuartzNMDS" pool-name="pjeQuartzNMDS" enabled="true" use-java-context="true">
    <connection-url>jdbc:postgresql://localhost:5432/pje</connection-url>
    <driver>postgres</driver>
    <security>
        <user-name>postgres</user-name>
        <password>P123456</password>
    </security>
</datasource>
<xa-datasource jndi-name="java:/pjeDS" pool-name="pjeDS" enabled="true" use-java-context="true" use-ccm="true">
    <xa-datasource-property name="ServerName">
        localhost
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
        5432
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
        pje
    </xa-datasource-property>
    <xa-datasource-property name="prepareThreshold">
        0
    </xa-datasource-property>
    <driver>postgresql</driver>
    <new-connection-sql>set search_path=client,core,jt,criminal,public,acl</new-connection-sql>
    <xa-pool>
        <min-pool-size>5</min-pool-size>
        <initial-pool-size>5</initial-pool-size>
        <max-pool-size>100</max-pool-size>
        <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>postgres</user-name>
        <password>P123456</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
    <statement>
        <prepared-statement-cache-size>0</prepared-statement-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
</xa-datasource>
<xa-datasource jndi-name="java:/pjeLogDS" pool-name="pjeLogDS" enabled="true" use-java-context="true">
    <xa-datasource-property name="ServerName">
        localhost
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
        5432
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
        pje_log
    </xa-datasource-property>
    <driver>postgresql</driver>
    <xa-pool>
        <min-pool-size>5</min-pool-size>
        <initial-pool-size>5</initial-pool-size>
        <max-pool-size>100</max-pool-size>
        <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>postgres</user-name>
        <password>P123456</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
</xa-datasource>
<xa-datasource jndi-name="java:/PJE_DESCANSO_BIN_DS" pool-name="pjeBinDs" enabled="true" use-java-context="true">
    <xa-datasource-property name="ServerName">
        localhost
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
        5432
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
        pje_bin
    </xa-datasource-property>
    <driver>postgresql</driver>
    <new-connection-sql>set search_path=client,core,public</new-connection-sql>
    <xa-pool>
        <min-pool-size>5</min-pool-size>
        <initial-pool-size>5</initial-pool-size>
        <max-pool-size>100</max-pool-size>
        <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>postgres</user-name>
        <password>P123456</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
</xa-datasource>
<xa-datasource jndi-name="java:/pjeQuartzDS" pool-name="pjeQuartzDS" enabled="true" use-java-context="true" use-ccm="true">
    <xa-datasource-property name="DatabaseName">
        pje
    </xa-datasource-property>
    <xa-datasource-property name="ServerName">
        localhost
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
        5432
    </xa-datasource-property>
    <driver>postgresql</driver>
    <xa-pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
        <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>postgres</user-name>
        <password>P123456</password>
    </security>
</xa-datasource>

5.5. Alterações no arquivo standalone-full.xml

Habilitar o wildfly para aceitar conexões externas (equivalente ao -b 0.0.0.0 do jboss 5.1). Incluir entre o final da seção </extensions> e o início da seção <management> - linhas 33 a 36 aproximadamente.

    <system-properties>
        <property name="jboss.bind.address" value="0.0.0.0"/>
        <property name="jboss.bind.address.management" value="0.0.0.0"/>
    </system-properties>

Alterar o subsystem weld para incluir a cláusula require-bean-descriptor.

Antes:

<subsystem xmlns="urn:jboss:domain:weld:2.0"/>

Depois:

<subsystem xmlns="urn:jboss:domain:weld:2.0" require-bean-descriptor="true"/>

Criação das entradas dos drivers jdbc para o jboss Dentro do arquivo standalone.xml, existe uma seção chamada <drivers>, que fica dentro da seção <datasources>, que pertence ao subsystem <subsystem xmlns="urn:jboss:domain:datasources:3.0"> e deve ser configurada em dois passos. O primeiro é a configuração do driver e o segundo, o datasource

<driver name="postgres_XA" module="org.postgresql">
    <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
</driver>
<driver name="postgres" module="org.postgresql">
    <datasource-class>org.postgresql.Driver</datasource-class>
</driver>

Importante notar que o nome do módulo module="org.postgresql" deve ser rigorosamente o nome criado no arquivo module.xml quando implantado o driver jdbc do postgres. Segue um exemplo como ficaria a seção drivers completa:

<drivers>
    <driver name="h2" module="com.h2database.h2">
        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
    </driver>
    <driver name="postgres_XA" module="org.postgresql">
        <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
    <driver name="postgres" module="org.postgresql">
        <datasource-class>org.postgresql.Driver</datasource-class>
    </driver>
</drivers>

Para testar se tudo está correto, ao iniciar o wildfly, no arquivo de log, deverão aparecer as entradas para os dois drivers criados no arquivo standalone.xml:

INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.4)
INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.4)
INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = postgres
INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = postgres_XA

5.6. Clonando o repositório do git

O pje-legacy encontra-se no repositório do PJe

Para clonar o repositório executar:

$ git@git.cnj.jus.br:pje/pje.git

5.7. JCR Storage

JCR Storage é responsável pelo armazenamento dos binários utilizados pelo PJe.

5.7.1. Clonando o repositório do git

O jcr-storage encontra-se no repositório do JCR Storage

Para clonar o repositório executar:

$ git@git.cnj.jus.br:utilitarios/jcr-storage.git

5.7.2. Gerando jar e executando JCR

Após baixar o projeto e com maven devidamente configurado, execute:

$ mvn clean package -DskipTests=true

Feito isso será gerado o arquivo jcr-storage-server-exec.jar na pasta target do server. Conceda permissão de execução e rode esse jar passando os parâmetros:

$ java -jar jcr-storage-server-exec.jar -httpPort 9000 -Dbr.jus.cnj.jcr.serverProperties=D:<HOME_DIR>/src/main/resources/server.properties

5.7.3. Configurações do JCR Storage

Próximo passo é criar um arquivo jcr-storage.properties num diretório do seu ambiente, por exemplo, D:\\jcr-storage.properties, com seguinte conteúdo:

jcr.username=admin
jcr.password=admin
jcr.url=http://localhost:9000/storage/documents
jcr.chunkSize=800000
jcr.hostMaxConn=10000

5.8. Configuração do frontend

O cliente web do Pje (PJE2-WEB) encontra-se no repositório do Pje2-WEB

Para clonar o repositório executar:

$ git@git.cnj.jus.br:pje2/pje2-clientes/pje2-web.git

Feito isso, rode o comando do npm para inicializar a aplicação na porta 4200:

$ ng serve

5.9. Configuração do Eureka e Gateway

O Eureka (Pje-Discovery) e Gateway (Pje-Gateway) são 2 componentes que podem ser instânciados através do Docker localmente.

Para isso é preciso fazer o login no registry do CNJ:

$ docker login registry.cnj.jus.br
Login: <LOGIN>
Password: <PASSWORD>
Login Succeeded

Crie um arquivo docker-compose.yml:

version: "3"
services:
  discovery:
    image: registry.cnj.jus.br/pje2/pje-discovery:latest
    ports:
    - '8761:8761'
  gateway:
    image: registry.cnj.jus.br/pje2/pje-gateway:latest
    ports:
      - '8180:8180'
      - '8181:8181'
    environment:
      - EUREKA_SERVER_DEFAULT_ZONE=http://discovery:8761/eureka/
      - HOSTNAME=localhost

Próximo passo, é executar o docker compose no diretório do arquivo yml criado:

$ docker-compose up -d

5.10. Configuração do Eclipse

5.10.1. Plugins

Filesync

Instalar o plugin FileSync para o eclipse:

image

Após a instalação, clicar com o botão direito no projeto pje-web, selecionar "Properties" e localizar o item “File synchronization”. Clicar em “Add Folder” e adicionar a pasta /src/main/webapp:

image

image

Abrir a pasta incluída, selecionar “Excluded” e clicar em “Edit”:

image

Clicar no botão “Add Multiple” do “Exclusion patterns”, selecionar todos os arquivos do WEB-INF exceto a pasta XHTML e clicar em “OK”:

image

Informar em "Default target folder" o caminho do .war:

image

JbossTools

Instalar o plugins JBoss Toos para o eclipse. Clique em Help > Eclipse Marketplace:

image

Digite Jboss Tools no campo Find e clique em Install

image

Prossiga com a instalação clicando em confirmar:

image

Após o restart do Eclipse, o ícone do JBoss Tools aparecerá em Help > About Eclipse IDE:

image

5.10.2. Flyway

No projeto pje-comum, existe um diretório chamado migrations onde estão os scripts de migração do banco do Pje para versão corrente do Pje.

Para que configurar o flyway no Eclipse, abra o pom.xml desse projeto e clique no menu Run > Run Configurations, selecione Maven Build e clique em New launch configuration:

image

Ativar o profile do flyway no arquivo settings.xml:

    <activeProfiles
        <activeProfile>artifactory</activeProfile
        <activeProfile>pje-descanso</activeProfile
    </activeProfiles>

Após esses dois passos, ao clicar em run, deverão aparecer as seguintes informações no console:

---
[INFO] ------------------------------------------------------------------------
[INFO] Building pje-comum 2.1.1.6-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] --- flyway-maven-plugin:2.2.1:migrate (default-cli) @ pje-comum ---
[INFO] Current version of schema "public": 2.1.1.4.001
[INFO] Successfully applied 56 migrations to schema "public" (execution time 00:12.485s).
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
---

5.10.3. Wildfly

Após a instalação do JBoss Tools, na aba Servers, clique com botão direito e adicione um novo server:

image

Selecione o Wildfly 9.X:

image

Selecione o Home Directory do Wildfly localmente:

image

Clicar com botão direito e adicionar o pje-web para Wildfly:

image

Overview

Ao clicar 2 vezes em cima do Server Wildfly, será exibido uma tela de Overview:

image

Clique em Open Launch Configuration:

image

Altere/inclua os seguintes argumentos na opção VM arguments:

  1. Xms: 1024 ou mais;

  2. Xmx: 1500 ou mais;

  3. –noverify: flag responsável por evitar verificaçãod o bytecode gerado;

  4. –Dpje.producao=false: flag responsável de indicação do ambiente;

  5. -Dbr.jus.cnj.pje.jcr-storage.configuration=<HOME_DIR>/jcr-storage.properties: arquivo de configuração do JCR Storage.

Ainda na janela de Open Launch Configuration, clique na aba Environment e adicione a variável ENV_PJE2_CLIENTE_URL=http://localhost:4200

Altere a opção activeByDefault para true no arquivo pom.xml no projeto pje-web, habilitando o profile do jcr-storage:

                <profile>
                        <id>jcr-storage</id>
                        <activation>
                                <activeByDefault>true</activeByDefault>
                        </activation>
                        <dependencies>
                                <dependency>
                                        <groupId>br.jus.cnj.pje</groupId>
                                        <artifactId>jcr-storage-client</artifactId>
                                </dependency>
                        </dependencies>
                </profile>

Próximo passo, é iniciar o Wildfly:

image

Dando tudo certo, ao acessar no browser o endereço a página inicial do Pje, deve ser exibida a página de login:

image