Ir para o conteúdo

 Voltar a Manuais
Tela cheia

Desenvolvimento Colaborativo e de Módulos

13 de Maio de 2016, 17:13 , por Nei Jobson da Costa Carneiro - | Ninguém seguindo este artigo por enquanto.

Manual de Desenvolvimento de Módulos SEI 3.0

Segue Manual de Desenvolvimento de Módulos para o SEI 3.0.0, descrevendo todas as APIs disponíveis para integração, estrutura do projeto e as convenções de nomenclatura a serem seguidas. Link para Download do Manual de Módulos do SEI 3.0

 

Configuração de Projetos de Módulos para o SEI no Gitlab

  1. Criação do Grupo referente ao órgão desenvolvedor do módulo, que será seu principal mantenedor. Por exemplo: anatel
  2. Os projetos de módulo devem ser criados abaixo do Grupo correspondente (escolher o “namespace” do Grupo do órgão), conforme padrão de nome a seguir: grupo/mod-sei-nomemodulo  (por exemplo: anatel/mod-sei-wscomplementar)
  3. Dentro do projeto os códigos do módulo devem estar dispostos na estrutura original de pastas do SEI, nas pastas em que cada arquivo deve ser inserido, sem conter nenhum arquivo original do SEI. Ou seja, devem estar apenas nas pastas finais, inclusive arquivos de script de instalação/atualização dispostos na raiz do SEI ou SIP e todo o conjunto de arquivos do módulo em sei/institucional/pasta_mod). Exemplo: https://softwarepublico.gov.br/gitlab/anatel/mod-sei-wscomplementar/tree/master
  4. O projeto de módulo do órgão mantenedor será considerado o projeto “Oficial”.
  5. A branch “master” do projeto Oficial do módulo deve ser protegida e os usuários com permissão nesta master devem estar sob a coordenação do órgão correspondente ao Grupo. Assim, independente de qualquer coordenação negocial prévia, as evoluções devem ser remetidas à master do projeto Oficial por meio de “Merge Request”, que será avaliado pela equipe do projeto Oficial.
  6. Somente quando forem efetivados todos os merges, o órgão consolidará e testará nova release do módulo com base na master e, estando tudo estável, criará Tag referente a nova versão do módulo e publicará link para a Tag por e-mail para a Comunidade de Negócio e Técnica do SEI no Portal do SPB. Exemplo: https://softwarepublico.gov.br/gitlab/anatel/mod-sei-wscomplementar/tags
  7. As tags devem seguir o seguinte padrão de numeração: v.f.s (exemplos: 1.0.0; 2.3.5; 2.0.3)
    1. a primeira posição referente à letra “v” é referente à versão principal, que deve marcar a primeira versão estável e em produção do módulo (1.0.0) e ser alterado apenas quando for liberada nova release com conjunto de funcionalidades ou mudança estrutural significativa.
    2. a segunda posição referente à letra “f” é referente a novas funcionalidades e melhorias pontuais estáveis e em produção do módulo (1.1.0).
    3. a terceira posição referente à letra “s” é referente a correções referentes a sustentação, seja de erros técnicos ou de negócio, já estáveis e em produção do módulo (1.1.3).

Configuração de Labels e Milestones para gestão das Issues no Gitlab

Exemplo de Wiki com orientações e configuração padrão de Labels e Milestones: https://softwarepublico.gov.br/gitlab/anatel/mod-sei-wscomplementar/wikis/home

Criar os Labels abaixo para serem utilizados na abertura de cada Issue:

  1. defeito                                         (vermelha)
  2. correção de regra de negócio    (amarela)
  3. melhoria de regra de negócio     (rojo)
  4. funcionalidade nova                   (verde)
  5. prioridade alta                             (azul)
  6. prioridade baixa                          (bege)
  7. prioridade normal                        (cinza)

  

Criar os Milestones abaixo, para que sejam utilizados durante o tratamento da Issue:

      1. Nova

      Demanda nova ainda não submetida à discussão negocial pela Comunidade de Negócio ou Comunidade Técnica do PEN.

      2. Em discussão negocial

      Demanda nova submetida à discussão negocial pela Comunidade de Negócio ou Comunidade Técnica do PEN.

      3. Aceita

      Demanda nova aceita pela Comunidade de Negócio ou Comunidade Técnica do PEN.

      4. Em desenvolvimento

      Demanda aceita e definido quem efetivará o desenvolvimento.

      5. Resolvida

      Demanda desenvolvida, pendente de merge para release principal e posterior publicação.

      6. Fechada

      Demanda desenvolvida, merge realizado e release incluindo o desenvolvimento publicada.

      7. Rejeitada

      Demanda rejeitada, seja pela pertinência da nova demanda ou por não se tratar de um defeito de fato.

 

Metodologia de desenvolvimento colaborativo no Gitlab

Antes de mais nada, é importante lembrar que qualquer desenvolvimento deve ser previamente discutido em nível negocial com o órgão mantenedor do projeto Oficial, podendo ser diretamente ou também em conjunto com outros órgãos por meio das listas de e-mail sei-negocio ou sei-tecnico do projeto SEI no Portal do SPB. Somente depois de ultrapassada as discussões negociais é que o desenvolvimento colaborativo deve ser iniciado.

Resumidamente, qualquer desenvolvimento colaborativo deve seguir os seguintes passos:

  1. Na página principal do projeto “Oficial” no Gitlab (exemplo: https://softwarepublico.gov.br/gitlab/anatel/mod-sei-wscomplementar), no canto direito clique em “Fork” e selecione o “namespace” do Grupo do órgão que pretende colaborar com o desenvolvimento.
  2. Depois de instalados os softwares necessários ao desenvolvimento colaborativo e a máquina virtual em Vagrante do ambiente de desenvolvimento padrão do SEI localhost (https://softwarepublico.gov.br/social/sei/manuais/documentacao-de-apoio - seção “Ambiente de Desenvolvimento - Vagrant”), deve seguir o Roteiro de Uso do TortoiseGit.
  3. Realizado o Fork do projeto “Oficial”, pegue o endereço SSH do Fork e no seu microcomputador escolha a pasta única para acumular todos os projetos do Gitlab. Clique com o botão direito do mouse dentro da pasta e selecione “Git Clone...” para fazer o clone do projeto Fork (este remote deve ser identificado como “origin”).
  4. Em seguida, dentro da pasta clonada, clique com o botão direito do mouse e selecione TortoiseGit > Settings > Git > Remote. Adicione mais um “Remote”, com o nome de “Oficial” e indique o endereço SSH do projeto Oficial: git@softwarepublico.gov.br:anatel/mod-sei-wscomplementar.git
  5. Na pasta do projeto no seu micro, faça um “Switch/Checkout” para a master do remote “origin” (que é o Fork do projeto Oficial), abra uma Branch para o desenvolvimento pontual e pode trabalhar a vontade fazendo commits e Push para o Git e até merges para a master do Fork.
  6. Somente depois de estável e testado o desenvolvimento previamente no SEI localhost (ambiente Vagrant), fazer o Push da Branch para o remote “origin” e no Gitlab do Projeto Fork abrir um “Merge Request” dessa Branch para a “master” do Projeto Oficial. Dessa forma, o desenvolvimento pontual feito pelo órgão colaborador foi submetido ao órgão mantenedor da solução.

 

Padrão de script PHP de Instalação/Atualização de módulos para o SEI

O SEI possui no “infra_php” tratamentos próprios para cada tipo de banco de dados de operação (MySQL, SQL Server e Oracle). Assim, as atualizações do core do SEI e instalações/atualizações de módulos que envolverem alterações em banco de dados do SEI devem ser operadas por meio de scripts PHP que utilizam as funções de banco próprias do SEI.

Destaca-se que, se o módulo depender da inclusão de novos recursos, menus e perfis no SIP para seu funcionamento, deve ser implementado igualmente script de banco para o SIP para tais alterações no banco do SIP de forma automatizada. Ainda, todo módulo deve ter um arquivo LEIAME.txt na pasta principal do módulo com orientações sobre sua instalação.

Abaixo segue especificação padrão para a construção do referido script de instalação/atualização de módulos para o SEI:

COMO Sistema, GOSTARIA que o script de instalação/atualização reconhecesse instalação/versão já existente PARA ter comportamentos e mensagens próprios

Localização: Módulo de Peticionamento Eletrônico

Tema: Instalação/Atualização do Módulo

Critérios de Aceitação:

  1. Que o script de instalação/atualização do módulo perceba que não tem nenhuma versão anterior instalada e faça a instalação completa do módulo em sua versão mais atual (a versão do script correspondente), gravando ao final a versão do módulo em parâmetro próprio no SEI em Infra > Parâmetros.
  2. Que o script de instalação/atualização do módulo perceba que já existe alguma versão do módulo instalada a partir da leitura do parâmetro próprio no SEI em Infra > Parâmetros e atualize o módulo gradualmente versão por versão de forma automática, atualizando ao final a versão do módulo em parâmetro próprio no SEI em Infra > Parâmetros.
  3. Exemplo: Uma instância do SEI com o módulo instalado em sua versão 2.1.0 poderia ser atualizado diretamente para a versão 2.3.0, mesmo a versão 2.1.0 não sendo a versão imediatamente anterior. O script irá verificar todas as versões, a partir da 2.1.0, que precisarão ser instaladas e irá gradualmente instalar versão por versão, até chegar na versão atual.
  4. O script de instalação/atualização do módulo ser montado utilizando as bibliotecas de persistência e funções do “infra_php” já existentes no SEI (framework de banco), viabilizando a construção de um script que funcionará em qualquer dos SGBDs compatíveis com a arquitetura atual do SEI (MySQL, SQL Server e Oracle). Não deve, portanto, ser montado script de instalação/atualização fazendo uso de instruções nativas/específicas de um SGBD em particular.
  5. A numeração de versões do módulo deve conter sempre 3 dígitos no formato (exemplos: 0.0.1, 1.0.5, 0.5.1 etc...) e não deverá usar letras nem caracteres especiais.
  6. Antes da execução do script os usuários de banco do SEI e do SIP no ambiente devem ter permissões ampliadas, se forma a conseguir executar CREATE e DROP de tabelas no banco. Tal requisito deve ser destacado no roteiro de instalação/atualização no arquivo LEIAME.txt do módulo.
  7. A execução do script deverá seguir os passos descritos abaixo:

  

      Script 1 – Atualizações no banco de dados do SEI

  1. Usuário faz a requisição do script (navegador ou execução em linha de comando no servidor);
  2. O script faz a configuração das variáveis básicas necessárias para a correta execução do script (habilita log/debug, aumenta tempo máximo de execução de script no PHP, amplia tamanho máximo de memória que o script PHP poderá consumir dentre outras configurações necessárias);
    1. Exibição de mensagem de inicialização do script com o texto “INICIANDO ATUALIZAÇÃO DA VERSÃO DO MÓDULO <nome_modulo> <numero da versão atual do módulo>”;
  3. Consultar na tabela apropriada (INFRA_PARAMETRO) do banco de dados se há uma versão do módulo já instalada, qual é a versão e a partir desta informação aplicar um dos dois comportamentos descritos acima (itens 1 e 2);
  4. O sistema cria (instrução CREATE TABLE) e depois destrói (instrução DROP TABLE) tabela de teste no banco de dados para confirmar se o usuário do banco de dados possui a permissão necessária para realizar este tipo de operação;
  5. Caso o usuário de banco de dados possua as permissões necessárias, devem ser executadas as devidas atualizações na base de dados. Se não possuir as permissões, o script deve ser interrompido com mensagem própria;
    1. Sistema deve atualizar na tabela INFRA_PARAMETRO do banco de dados a versão do módulo que foi instalada;
    2. Sistema deve exibir mensagem notificando conclusão das atualizações do módulo na base de dados.
  6. Em caso de sucesso sistema exibe a mensagem FIM e registra a conclusão da operação na tabela de log (INFRA_LOG).

  

       Script 2 – Atualizações n no banco de dados do SIP

  1. Usuário faz a requisição do script (navegador ou execução em linha de comando no servidor);
  2. O script faz a configuração das variáveis básicas necessárias para a correta execução do script (habilita log/debug, aumenta tempo máximo de execução de script no PHP, amplia tamanho máximo de memória que o script PHP poderá consumir dentre outras configurações necessárias);
    1. Exibição de mensagem de inicialização do script com o texto “INICIANDO ATUALIZAÇÃO DA VERSÃO DO MÓDULO <nome_modulo> <numero da versão atual do módulo>”;
  3. Consultar na tabela apropriada (INFRA_PARAMETRO) do banco de dados se há uma versão do módulo já instalada, qual é a versão e a partir desta informação aplicar um dos dois comportamentos descritos acima (itens 1 e 2);
  4. O sistema cria (instrução CREATE TABLE) e depois destrói (instrução DROP TABLE) tabela de teste no banco de dados para confirmar se o usuário do banco de dados possui a permissão necessária para realizar este tipo de operação;
  5. Caso o usuário de banco de dados possua as permissões necessárias, devem ser executadas as devidas atualizações na base de dados. Se não possuir as permissões, o script deve ser interrompido com mensagem própria;
    1. Sistema deve atualizar na tabela INFRA_PARAMETRO do banco de dados a versão do módulo que foi instalada;
    2. Sistema deve exibir mensagem notificando conclusão das atualizações do módulo na base de dados.
  6. Em caso de sucesso sistema exibe a mensagem FIM e registra a conclusão da operação na tabela de log (INFRA_LOG).

 

Fluxos Alternativos:

  • Se durante a execução do script ocorrer algum erro/exceção PHP (ex: alguma instrução de banco indevida, banco de dados sair do ar ou qualquer outro tipo de imprevisto que produza uma exceção na execução do script) deve ser exibida na tela uma mensagem de notificação e devem ser gravados detalhes do erro no log do sistema (na tabela INFRA_LOG do SEI ou do SIP, conforme script executado).
  • Se o script identificar que a versão atual do módulo já está instalada, exibe mensagem de notificação apropriada, registra um erro na tabela de log (INFRA_LOG) e não prossegue com a execução do script.
  • Se uma versão mais atual que o script já estiver instalada no sistema, exibe mensagem de notificação apropriada, registra um erro na tabela de log (INFRA_LOG) e não prossegue com a execução do script.

 

Padrão de Modelagem de Dados de Módulos para o SEI

De forma geral, o modelo de dados do SEI está documentado na página https://softwarepublico.gov.br/social/sei/manuais/documentacao-de-apoio - seção “Padrão de Modelagem de Dados”.

Contudo, para não existir confusão entre as tabelas de bando de dados do core do SEI com tabelas dos módulos, deve seguir ainda os padrões abaixo:

md_nomemd_funcaotabela

  1. md = indica que é uma tabela de módulo
  2. nomemd = abreviação que identifica o módulo em si
  3. funcaotabela = é o nome da tabela em si, com sua função dentro do módulo

Em razão de especificidades do “infra_php”, tabelas de sequencial de auto incremento devem incluir no início o termo “seq_” e repetir o nome da tabela principal correspondente no restante do nome.

      Exemplo: “md_lit_fase” e “seq_md_lit_fase”; em que “md” identifica que é uma tabela de módulo, “lit” identifica o módulo em si (no caso, Controle de Processos Litigiosos), “fase” identifica a função desta tabela e “seq_” identifica que é a tabela de sequencial de auto incremento correspondente.

A identificação do módulo no nome das tabelas deve ser o menor possível (recomenda-se no máximo três caracteres), tendo em vista o limite geral de até 30 caracteres para o nome das tabelas e demais objetos de banco, em razão de limitação de banco de dados Oracle no qual o SEI também funciona.

Por fim, destaca-se que para banco MySQL sempre deve utilizar a engine “InnoDB”.

 

Padrão de Codificação PHP de Módulos para o SEI

De forma geral, o padrão de codificação PHP do SEI está documentado na página https://softwarepublico.gov.br/social/sei/manuais/documentacao-de-apoio - seção “Padrão de Codificação PHP”.

Contudo, com disponibilização da função “PaginaSEI::tratarHTML” no arquivo “infra_php/InfraPagina.php” na Atualização 7 do SEI 2.6.0 que realiza tratamento HTML para evitar vulnerabilidade de XSS, deve-se aplicar a referida função em campos de cadastro de texto em todos os formulários do módulo e também nas telas de exibição dos textos correspondentes cadastrados.

Segue abaixo exemplos de aplicação da função “PaginaSEI::tratarHTML” em código PHP de módulo do SEI:

Campo “value”, com a função:

value="<?=PaginaSEI::tratarHTML($objFaseLitigiosoDTO->getStrNome());?>"

Campo “textarea”, com a função:

<textarea type="text" id="txtDescricao" rows="3" name="txtDescricao" class="infraText" onkeypress="return infraMascaraTexto(this,event,250);" maxlength="250" tabindex="<?=PaginaSEI::getInstance()->getProxTabDados()?>"><?=PaginaSEI::tratarHTML($objFaseLitigiosoDTO->getStrDescricao());?></textarea>

Para informações a serem reinderizadas em javascript, com a função:

      }

      if ($bolAcaoDesativar || $bolAcaoReativar || $bolAcaoExcluir){

        $strId = $arrObjFaseLitigiosoDTO[$i]->getNumIdFaseLitigioso();

        $strDescricao = PaginaSEI::getInstance()->formatarParametrosJavaScript(PaginaSEI::tratarHTML($arrObjFaseLitigiosoDTO[$i]->getStrNome()));

      }

 

Continuação...


Nova atualização da Base de Referência - SEI 2.6.0

16 de Junho de 2015, 12:36, por Michele Cristina

Disponibilizada nova atualização da Base de Referência para o Poder Executivo relacionada à versão 2.6.0 do SEI.



Apresentação no CADE

16 de Junho de 2015, 12:35, por Michele Cristina

No dia 14/04 o CADE fará uma apresentação do Projeto Cade em Papel para os Órgãos: Secretaria de Portos da Presidência da República, Eletrobras, Terracap, IPEA, MCTI, Embratur, GDF, Ancine, Trensub, FioCruz, Fundação Palmares, que estão interessados em conhecer o planejamento e experiência de implantação do SEI.



Portaria 9 do GSI da PR

16 de Junho de 2015, 12:34, por Michele Cristina

PRESIDÊNCIA DA REPÚBLICA



Portaria 11 do GSI da PR

16 de Junho de 2015, 12:33, por Michele Cristina

PRESIDÊNCIA DA REPÚBLICA



Evento Processo Eletrônico Nacional

16 de Junho de 2015, 12:32, por Michele Cristina

O Ministério do Planejamento, Orçamento e Gestão convida os órgãos e servidores interessados em conhecer o Processo Eletrônico Nacional (PEN) e a solução Sistema Eletrônico de Informações (SEI) a participarem do Encontro Processo Eletrônico Nacional - Rumo ao Aprimoramento da Gestão Pública.