ESPECIFICAÇÃO E INTEGRAÇÃO

Transcrição

1 \ Sistema Integrado de Gestão de Administrativa - White Paper - ESPECIFICAÇÃO E INTEGRAÇÃO

2 Controle de Versão Versão Responsabilidade Início de elaboração Final de elaboração Atividade 0.01 Renato Crivano 06/04/ /04/2009 Versão prévia para a homologação das equipes da CSIS 0.02 Renato Crivano 07/10/ /10/2010 Revisão para envio ao CJF q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 2

3 Índice 1 Introdução Premissas gerais Premissas de Integração Topologia Diagrama de componentes Descrição dos componentes básicos... Erro! Indicador não definido. 2.3 Descrição dos Componentes Típicos de um Módulo Banco de Dados Corporativo Controle de Acesso Autenticação Autorização Simulação de usuário ou equipe Cadastro de Terceirizados Cadastro de Órgãos Externos Marcadores SIGA-WS: Webservices SIGA-WF: Workflow Instanciação Mecanismo de referência entre Wf e Ex Mecanismo de monitoramento Integração de interface gráfica Wf x Ex ANEXO 1: Modelo do Banco de Dados Corporativo ANEXO 2: Dependências Entre os Componentes do SIGA...14 q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 3

4 1 Introdução O Sistema Integrado de Gestão Administrativa SIGA integra diversos módulos responsáveis por gerir todos os aspectos administrativos dos órgãos judiciais. No presente momento, alguns componentes já estão disponíveis, são eles: 1. Expedientes 2. Workflow 3. Serviços 4. Cadastro de RH 5. Benefícios 6. Treinamento O próximo módulo a ser implantado será de Gestão de Identidade. Este componente será capaz de controlar identidades e restringir acessos de acordo com os requisitos impostos pelo MoReq-Jus. Também será possível sincronizar a base de dados de identidades do Siga com um servidor Microsoft Active Directory, inclusive configurando automaticamente permissões de acesso a diretórios, grupos de e caixas postais no Microsoft Exchange Server. 1.1 Premissas gerais Antes de entrar em detalhes sobre a arquitetura do SIGA, é importante elencar as principais premissas que norteiam esse projeto: 1. Modular: cada módulo deve ser relativamente independente dos demais, de maneira a paralelizar o desenvolvimento, facilitar a manutenção e minimizar a propagação de erros entre módulos. Deve suportar a implantação apenas de alguns de seus componentes. 2. Multi-Órgão: pode ser usado por qualquer órgão interessado, bastando para tanto que o órgão disponibilize informações sobre sua estrutura interna e seus funcionários. 3. Cadastro não assistido: para desonerar servidores da TI, o SIGA deve permitir que usuários se cadastrem e recebam senhas de acesso de forma automática. 4. Web: para facilitar a disseminação, a instalação e a atualização de versões. E, também, para possibilitar o uso a partir de qualquer lugar e de qualquer sistema operacional. 5. Open-source: para poupar recursos públicos e para garantir acesso ao código-fonte de todos seus componentes. 1.2 Premissas de Integração Os esforços de integração partiram da visão de criar um sistema único web composto de diferentes módulos de, sendo que: 1. Cada módulo (ou grupo de módulos) deve possuir seu banco de dados específico. 2. Apenas os dados principais residam em um banco de dados compartilhado. 3. Módulos podem precisar fazer chamadas à outros módulos, que estão no mesmo grupo ou em grupos diferentes. 4. Cada módulo deve possuir sua aplicação web especifica e existe também uma pagina inicial do sistema (portal). q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 4

5 5. Alguns componentes web devem ser compartilhados e a interface deve ter toda a mesma aparência. 2 Topologia 2.1 Diagrama de componentes 2.2 Principais frameworks Todos os módulos do siga são desenvolvidos utilizando os frameworks abaixo: 1. WebWork (framework web atualmente conhecido como Struts Action 2) 2. Hibernate (mapeamento objeto relacional e abstração de banco de dados) 3. Lucene (busca textual) 4. jbpm (workflow) q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 5

6 2.3 Descrição dos componentes básicos Todas as funcionalidades que são comuns aos diversos módulos que compõem o SIGA, estão codificadas na forma de bibliotecas JAR. A integração entre os diferentes módulos que compõem o SIGA se dá através de seis componentes, são eles: 1. Banco de Dados Corporativo: Possui algumas tabelas com os dados que são fundamentais para todos os módulos do SIGA, conforme será explicado na próxima seção. 2. Siga-base.jar: Possui as classes mais básicas do modelo. Esse componente é tão genérico que pode ser reutilizado inclusive em outros projetos que não sejam parte do SIGA. O objetivo é disponibilizar determinados artefatos, totalmente independentes de ambiente Web ou de conexão com banco de dados, que possam ser estendidos ou implementados pelas aplicações, produzindo uma padronização nas escolhas arquiteturais. Sigabase.jar também disponibiliza diversos métodos utilitários. 3. Siga-cp.jar: Possui o DAO de conexão com o Banco de Dados Corporativo e todas as classes que são persistidas nesse repositório. Essas classes são utilizadas em todos os módulos do SIGA para representar pessoas, lotações, cargos, funções, etc. 4. Siga-libs.jar: Esta biblioteca completa as dependências obrigatórias de todos os módulos do SIGA, disponibilizando várias classes e interfaces que padronizam a maneira como os módulos devem interagir com o Container Web. Alguns componentes contemplados nessa biblioteca são: a. SigaActionSupport: classe abstrata que deve ser estendida por todas as ações do WebWork que compõem os módulos do SIGA. Essa classe já implementa o mecanismo de autenticação e substituição, e o acesso ao DAO. b. Taglib de componentes visuais do SIGA, incluindo: i. Controle de seleção de pessoas, lotações, etc. Este controle deve ser estendido sempre que um módulo precisar de uma caixa de seleção. ii. Tags relativos ao controle de acesso (descrito abaixo). iii. Tags para o menu. c. Demais tags utilitários. 5. Siga-ws.jar: Esta biblioteca define as interfaces de todos os webservices que são disponibilizados pelos módulos do SIGA. 2.4 Descrição dos Componentes Típicos de um Módulo Ao desenvolver um módulo para o SIGA, é importante dividir a solução em três componentes básicos, são eles: 1. Banco de Dados: Deve ser capaz de armazenar a informações específicas do módulo pretendido. Também deve permitir a integração com o BD Corporativo, inclusive garantindo a integridade referencial. (Em nosso ambiente Oracle, utilizamos synonyms para obter esse efeito). 2. Biblioteca de classes: Todos os objetos que compõem o modelo do domínio, bem como um façade para isolar a complexidade do modelo, devem estar nessa biblioteca. Esse isolamento permite que a camada de visão seja totalmente intercambiável e independente da lógica do negócio. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 6

7 3. Aplicação Web: É um programa especificamente desenvolvido para ser executado em um Container Web. Atualmente utilizamos o framework WebWork como arquitetura obrigatória para os módulos do SIGA, mas outras alternativas podem ser estudadas e implementadas no futuro. 3 Banco de Dados Corporativo Alguns dados são tão fundamentais que precisam estar disponíveis para todos os módulos que compõem o SIGA. Embora o grupo de módulos de RH seja detentor das informações mais precisas sobre os servidores e magistrados, parte dessas informações tem que ser disponibilizadas para os outros módulos. Em especial, informações sobre os funcionários, suas lotações, cargos e funções comissionadas são tão básicas que precisamos possuir não somente a base da SJRJ, mas também de qualquer outro órgão que utilize o SIGA. Para resolver esse problema, criamos o banco de dados Corporativo, que concentra somente estas informações essenciais para todos os módulos do SIGA. O banco Corporativo é atualizado a partir da importação de arquivos XML provenientes dos diversos órgãos que utilizam o SIGA. Atualmente, realizamos diariamente a importação dos XMLs do TRF2, SJRJ e SJES. O modelo de dados do banco Corporativo pode ser visto no Anexo 1. 4 Controle de Acesso O controle de acesso ao SIGA se baseia na implementação de um mecanismo de autenticação, que não requer o cadastro manual de cada usuário. Para tanto, enviamos a senha de cada usuário para o que foi previamente informado através do arquivo XML de importação dos dados de pessoas e lotações. Os mecanismos de autenticação e autorização são detalhados a seguir. 4.1 Autenticação Utilizamos um sistema de Single-Sign-On (SSO) do container Java para garantir que o usuário possa navegar entre os diversos módulos que compõem o SIGA, fazendo apenas um login. Um usuário pode se cadastrar informando o seu número de matrícula e seu CPF. A partir dessas informações, o Portal SIGA verifica a existência desse usuário na tabela DP_Pessoa do banco de dados Corporativo e emite uma senha diretamente para o previamente cadastrado. Se houver necessidade, o Portal SIGA também é capaz de realizar as operações de lembre e troca de senha. A classe abstrata SigaActionSupport, que tem que ser estendida por cada action dos módulos, é responsável por mapear o usuário autenticado em um objeto do tipo DpPessoa. Sendo assim, sempre que é necessário saber quem está utilizando o sistema, basta chamar um método disponível em todas as actions chamado getcadastrante(). Determinadas autorizações são parametrizadas diretamente no sistema de autenticação, sendo implementadas através da criação de roles para os usuários e pela configuração do container, através dos arquivos web.xml, para aplicar de filtros baseados em máscaras de urls. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 7

8 4.2 Autorização O sistema de autorização do SIGA é bem mais sutil. Ele se baseia na configuração, em banco de dados, de regras de negócio que têm por finalidade definir quais funcionalidades estão disponíveis para cada usuário. Como os itens de configuração que dão origem as regras de negócio são de granularidade muito fina, optamos por implementar as tabelas de configuração dentro do modelo de banco de dados específico de cada módulo, e não no banco Corporativo. Um exemplo disso é a configuração do módulo de expedientes do SIGA (SIGA-EX) que exigem que os memorandos de substituição sejam assinados digitalmente na SJRJ, mas que permite que sejam emitidos em papel no TRF2 e na SJES. O sistema de autorização é composto por duas classes principais e algumas auxiliares. As classes principais são descritas abaixo: CompetenciaBL: classe que diz especificamente quem tem permissão para fazer o que. Atualmente conta com 50+ funções, todas com a mesma interface. ConfiguracaoBL: classe que trabalha com configurações em banco de dados, se valendo da integridade referencial, e aplica configurações personalizadas em vários aspectos da aplicação 4.3 Simulação de usuário ou equipe Uma importante característica dos módulos do SIGA é permitir que uma pessoa utilize o sistema para substituir outra que está de férias ou ausente por qualquer outro motivo. Esse processo é controlado totalmente pelos recursos comuns do SIGA, não sendo necessário nenhuma implementação específica em cada módulo. Ao identificar um usuário, o SIGA também identifica se ele está atuando no sistema em nome de outra pessoa ou de outra lotação. Essa informação é repassada para as Actions dos módulos do SIGA a partir de propriedades no SigaActionSupport. São elas: 1. getcadastrante(): retorna um objeto DpPessoa que representa o usuário logado; 2. getlotacadastrante(): retorna um objeto DpLotacao que representa a lotação do usuário logado; 3. gettitular(): retorna um objeto DpPessoa que representa a o usuário que está sendo substituído; 4. getlotatitular(): retorna um objeto DpLotacao que representa a lotação que está sendo substituída. Caso não se esteja realizando nenhuma simulação (substituição) no momento, tanto getcadastrante quanto gettitular apontarão para a mesma pessoa, e também serão iguais os resultados de getlotacadastrante e getlotatitular. Na prática, utiliza-se os dados do cadastrante para o log de quem realizou as tarefas no sistema, e as informações do titular para escolher que dados deverão ser apresentados e quais as permissões serão concedidas. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 8

9 5 Cadastro de Terceirizados Os terceirizados são armazenados nas tabelas do BD Corporativo exatamente da mesma maneira que os servidores e magistrados, ou seja, na tabela DP_Pessoa. Hoje em dia, não temos dados de terceirizados lá porque nossos dados são extraídos do MUMPS, que não possui tais informações. No entanto, o novo módulo de cadastro de RH será capaz de incluir no XML de importação esses dados, inclusive informando também a lotação e todos os papéis relacionados com cada funcionário terceirizado. 6 Cadastro de Órgãos Externos O novo módulo de cadastro de RH já inclui um cadastro de órgãos externos, que foi inicialmente pensado para permitir a informação do órgão originário dos servidores cedidos. Utilizaremos esse cadastro para manter a tabela de órgãos externos, e importaremos esses dados através de XML para o BD Corporativo. Sugestão: utilizar a integração que temos com o banco de dados da Receita Federal para alimentar automaticamente essa tabela a partir da informação do CNPJ. Ainda falta definir quem será responsável por manter o cadastro de órgãos externos. Atualmente essa tarefa é realizada pela própria informática em parceria com a CGOR. 7 Marcadores Existirão 5 tipos de marcadores conforme a tabela abaixo: Código Tipos de Marcadores Quem pode marcar e desmarcar 1 Sistema O sistema cria as marcas, ninguém pode criar movimentações para marcar ou desmarcar 2 Geral Qualquer pessoa que possa movimentar o móbil 3 Lotação e sublotações Pessoas da lotação responsável ou de sublotações 4 Lotação Pessoas da lotação responsável 5 Pessoa Somente a pessoa responsável pelo marcador Alguns marcadores são criados para atender a necessidades específicas dos módulos do SIGA, como por exemplo para refletir os estados dos documentos do SIGA-EX, mas outros marcadores poderão ser criados pelos próprios usuários. As marcas serão sempre aplicadas pelo próprio sistema. No caso do SIGA-EX, ela são concluídas a partir da análise das movimentações dos documentos. Dessa forma, para que se possa aplicar manualmente um marcador, é necessário que exista um tipo de movimentação específico para isso. Também deve existir um tipo de movimentação cujo objetivo é remover uma marcação. Exemplos de marcações q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 9

10 Um documento é urgente (Geral) Um documento é marcado com um marcador que foi criada por uma pessoa somente para sua visualização (Pessoa) Um documento é marcado com uma lista que foi criada por uma pessoa e deve ser visualizada por todas as pessoas da mesma seção Um documento recebe uma marcação do sistema, e passa a figurar na lista de atividades de uma pessoa e uma lotação 8 SIGA-WS: Webservices A biblioteca de webservices se baseia no framework Apache CXF, que foi escolhido pela simplicidade de uso e pela possibilidade de disponibilizar os serviços diretamente em um servlet da própria aplicação web em questão. Por exemplo, o SIGA-EX disponibiliza seus serviços no endereço: A configuração do CXF não está sendo feita através do Spring, pois isso tem resultado em erros muito difíceis de debugar. Portanto, sugere-se que o mesmo método de configuração utilizado no EX e no WF seja implementado em todos os outros módulos. 9 SIGA-WF: Workflow O módulo de workflow do SIGA é capaz de orquestrar diversos processos através da utilização dos Webservices que permitem a comunicação entre os módulos do SIGA. Esse módulo é independente e capaz de ser acoplado a outros futuros módulos do SIGA. Ao desenvolver um novo módulo para o SIGA, é importante pensar nas interfaces desse módulo com os demais e, em especial, com o SIGA-WF Dessa forma, por exemplo, podemos automatizar o processo de produção, tramitação e destinação dos expedientes e processos administrativos controlados pelo SIGA-EX. A seguir, para exemplificar, descrevemos o planejamento de integração entre o SIGA-WF e o SIGA-EX. 9.1 Instanciação Um workflow pode ser criado quando um documento é finalizado, ou independentemente do sistema de expedientes. Quando é finalizado um documento que automaticamente inicia um workflow, são criadas N variáveis de contexto, uma para cada via do documento, e cada variável tem nome do tipo: doc_a e valor do tipo RJ-MEM-2007/ A. Também é criada uma variável doc_documento que recebe RJ-MEM-2007/ Mecanismo de referência entre Wf e Ex Uma instância de processo se dirá relacionada com um documento se o documento a criou. Ou seja, se existe em seu contexto, uma variável doc_documento cujo valor é a sigla do documento criador. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 10

11 Uma determinada via de um documento estará relacionada a uma ou mais tarefas de workflow, se houver uma variável de controle cujo nome inicie por doc_, seja readonly e o valor seja a sigla da via. Uma tarefa pode estar relacionada com mais de um documento, para tal, basta que existam mais de uma variável iniciada por doc_. Uma instância de processo poderá ser relacionada com um documento (ou via de) mesmo depois de ser criada. Para tal, basta que seja acrescentada ao contexto uma variável na forma doc_* e que essa variavel seja posteriormente referenciada em uma tarefa como readonly. <node> <variáveis> <variável name= doc_a type= readonly /> </variáveis> </node> 9.3 Mecanismo de monitoramento Determinadas alterações realizadas no SIGA-EX devem produzir efeitos no SIGA-WF. Para obter esse resultado, utiliza-se a classe WfBD, pertencente ao SIGA-WF, que possui um método chamado: void atualizarworkflowdedocumento(string sigla); Esse método deve ser chamado sempre que houver uma modificação em qualquer documento do SIGA-EX, e o parâmetro sigla informado poderá conter a via ou não, ou seja: pode ser da forma RJ-MEM-2007/ A ou RJ-MEM- 2007/ Quando esse método for chamado, será realizada uma consulta para identificar todas as instâncias de processos que possuem tarefas cujo nome das variáveis de campos readonly sejam like o que foi passado. No trecho de código abaixo, podemos ver um node que seria executado caso o valor da variável doc_a fosse like o valor informado no parâmetro sigla do método atualizarworkflowdedocumento. <node> <variáveis> <variável name= doc_a type= readonly /> </variáveis> <chamar action isassinado > <se resultado == true> <tranferir para próximo node> </se> </chamar> </node> 9.4 Integração de interface gráfica Wf x Ex Na página de exibição de documento do sistema de expedientes: Aparecer um Box com cada tarefa de workflow relacionada àquele documento ou as suas vias. Lembrar que também existe a possibilidade da tarefa aparecer para o documento geral e que podem aparecer mais de uma tarefa na mesma posição. Esses boxes devem possuir links que levem para a visualização da tarefa no sistema de workflow. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 11

12 A variável readonly que criou a referência ao documento não deve ser apresentada nesse box Na página de visualização de tarefas do sistema de workflow (inbox): Deve haver um link na variável que faz a referência para um documento do SIGA-EX. Quando esse link for clicado, o browser navegará para a página do SIGA-EX que apresenta o documento em questão. q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 12

13 10 ANEXO 1: Modelo do Banco de Dados Corporativo q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 13

14 11 ANEXO 2: Dependências Entre os Componentes do SIGA q:\csis\04 Sistemas\00 Projeto SIGA\01 Documentacao\SIGA Especificacao e Integracao.doc Página 14