Para acompanhar sessões gravadas de instalação e configuração do sistema, assista os vídeos nos seguintes links:
Caso esteja interessado na instalação via Docker, acesse a documentação referente no banch docker, arquivo
docker/README.md
.
Esse roteiro visa detalhar os procedimentos a serem seguidos para instalar e configurar o Sistema de Programa de Gestão, aqui chamado SISPG, ferramenta de apoio tecnológico para acompanhamento e controle do cumprimento de metas e alcance de resultados nos termos da Instrução Normativa Nº 65, de 30 de julho de 2020. Esse é um documento técnico destinado às áreas de tecnologia dos órgãos que visam adotar o SISPG como ferramenta de gestão do teletrabalho. Detalha tecnologias, padrões e pacotes que devem ser implantados para ter o sistema funcionando dentro dos ambientes de cada órgão.
Dimensionamento de recursos, pré-requisitos, dependências, etc.
Passa-se, então, à configuração dos componentes da aplicação. O sistema segue modelos de arquitetura de micro serviços e utiliza estruturas separadas para o front-end e para o back-end. Diante disso, faz-se necessário configurar diferentes pacotes para o correto funcionamento da aplicação.
Sequência de instalação sugerida:
Etapa | Tópico | Módulo |
---|---|---|
1ª Etapa | Base de Dados |
|
2ª Etapa | Back-End |
API |
3ª Etapa | Front-End |
Gateway e APP |
Importante: Sugere-se as etapas acima destacadas para a correta instalação do SISGP.
O sistema foi desenvolvido utilizando o banco de dados Microsoft SQL Server com a ferramenta ORM da Microsoft Entity Framework Core nas funções de persistência e com SQL ANSI nas funções de consulta a dados. Em teoria, essa configuração permite que diferentes tecnologias de bancos de dados sejam utilizadas. Entretanto, a equipe de tecnologia da Susep garante a compatibilidade e realizou testes apenas com o Microsoft SQL Server.
install/
na seguinte ordem:
install/1. Criação da estrutura do banco de dados - Obrigatorio.sql
;install/2. Inserir dados de domínio - Obrigatorio.sql
;install/Criação da tabela pessoa alocacao temporaria - Obrigatorio.sql
;install/4. Inserir dados de teste - Opcional.sql
;5. Alteracoes da estrutura do BD para a V7.sql
;6. Alteracoes da estrutura do BD para a V8.sql
.Uma vez criada a estrutura de banco de dados, é necessário fazer a importação dos dados do órgão no SIAPE para a estrutura do sistema.
TOME NOTA: O script
Inserir dados de teste
traz um exemplo de carga com dados fictícios (CPFs gerados aleatoriamente e unidades da estrutura da Susep), serve para permitir o acesso e a validação do sistema. Assim que o sistema entrar em produção, os dados da tabelaPessoa
eUnidade
cadastrados por esse script devem ser apagados da base de dados.
Os perfis do sistema serão derivados da estrutura real do órgão. Desse modo, servidores que não tem função de chefia no órgão recebem valor null
na coluna tipoFuncaoId
da tabela Pessoa
deste modo terão habilitadas apenas funções de acompanhamento dos seus próprios planos de trabalho, ao passo que servidores com função de chefia poderão ter acesso aos planos de trabalho das suas respectivas equipes e terão acesso às funções de programas de gestão (cadastro, seleção, avaliação, etc). Servidores que trabalham na área de indicadores poderão, além de acompanhar seus próprios planos de trabalho, cadastrar as listas de atividades do órgão e dos demais setores.
https://github.com/henrique-prog/pdg-carga-de-dados
Em determinadas situações como, por exemplo, no caso fictício em que o titular da unidade está de férias e o substituto de licença, pode ser necessário ter pessoas no órgão com acesso total ao sistema para evitar que o trabalho do setor fique parado. Para suprir tal necessidade, existe o perfil Gestor com controle total da ferramenta.
O cadastro de gestores do sistema é feito na tabela
CatalogoDominio
. Basta inserir um registro nessa tabela com a coluna classificação preenchida com o valorGestorSistema
e a coluna descrição preenchida com o id da pessoa que terá perfil de gestor.
A publicação deve ser feita em algum servidor de aplicação. Sugere-se o Internet Information Services (IIS) na seguinte estrutura:
As pastas APP, gateway e APIdevem ser convertidas em aplicações no IIS e sugere-se que rodem sob um mesmo Application Pool.
TOME NOTA: Para ambiente de desenvolvimento/homologação, é suficiente apenas servidor interno. Já para produção, faz-se necessário um servidor interno e outro externo, e nesse caso as pastas
Gateway
eAPP
deverão estar no servidor externo enquanto a pastaAPI
estará no servidor interno.
As pastas APP, Gateway e API devem ser convertidas em aplicações no IIS e sugere-se que rodem sob um mesmo Application Pool. Os nomes e as estruturas das pastas poderão variar de acordo com a conveniência do Órgão, todavia será importante conhecer o caminho para cada uma delas.
Para facilitar o entendimento do roteiro, considera-se que os seguintes caminhos foram configurados:
https://**servidorExterno**/sisgp/app
https://**servidorExterno**/sisgp/gateway
https://**servidorInterno**/sisgp/api
- Criar um Pool de Aplicativos chamado “sisgp”.
- Criar um novo site vinculado ao pool “sisgp” e apontando para o caminho físico da pasta “api”.
- Criar um novo site vinculado ao pool “sisgp” e apontando para o caminho físico da pasta “gateway”.
- Criar um novo site vinculado ao pool “sisgp” e apontando para o caminho físico da pasta “app”.
O back-end concentra as regras de negócio e a interação da aplicação com o banco de dados e é composto por dois pacotes, API e Gateway.
A API é onde estão as regras de negócio, funcionalidades, operações de persistência e de consulta aos dados do sistema.
TOME NOTA: Alguns métodos só funcionarão quando invocadas por meio do Gateway. Entretanto, com algum conhecimento de chamadas HTTP é possível executar chamadas a alguns métodos da API. Por isso, recomenda-se que esse pacote fique em um ambiente acessível apenas por meio da máquina onde está hospedado o Gateway.
API
)web.config
, alterar o valor da variável ASPNETCORE_ENVIRONMENT com um dos valores a seguir, de acordo com o ambiente: Dev, Homolog ou Prod.Settings/connectionstrings.AMBIENTE.json
, informar os valores para conexão com o banco de dados, sendo data source
o servidor, initial catalog
o nome do banco, User ID
o usuário e Password
a senha.Settings/appsettings.AMBIENTE.json
, configurar o servidor de e-mail SMTP e o LDAP para autenticação dos usuários - ESTA ETAPA PODE OCORRER APÓS VALIDAÇÃO DA APLICAÇÃO COM USERS DE TESTE.Após instalação e configuração da base de dados e API, recomenda-se a validação dessas etapas pela seguinte URL:
**URL da Aplicação**/api/api/v1/dominio/ModalidadeExecucao
Se a instalação foi realizada corretamente, deverá retornar um json com as modalidades de trabalho da tabela catálogo domínio.
Dotnet susep.sisrh.webapi.dll
O retorno é o possível erro.
O Gateway adiciona camadas de segurança, cache e outros recursos à API. É essencial para o funcionamento do sistema, para a prevenção de ataques e outros problemas.
gateway
)web.config
, alterar o valor da variável ASPNETCORE_ENVIRONMENT
com um dos valores a seguir, de acordo com o ambiente: Dev, Homolog ou Prod.Settings/appsettings.**AMBIENTE**.
, informar a url da API no campo authority
.Settings/ocelot.**AMBIENTE**.json
, dentro do objeto ReRoutes
, substituir todos os campos Host
e Port
pelas do servidor da API. Caso a API esteja com https, alterar todos os DownstreamScheme
. Caso a API não esteja na raiz do servidor, completar os caminhos em todos os DownstreamPathTemplate
. Já no final do arquivo substituir o campo BaseUrl
pela url do gateway.Após instalação e configuração do Gateway, recomenda-se a validação dessa etapa pela seguinte URL:
**URL da aplicação**/gateway/dominio/ModalidadeExecucao
Se a instalação foi realizada corretamente, deverá retornar um json com as modalidades de trabalho da tabela catálogo domínio (mesmo retorno da validação da API).
Dotnet susep.sisrh.webapi.dll
O retorno é o possível erro.
O front-end é a camada de apresentação do sistema. Construída em angular, teoricamente, pode ser publicada em qualquer servidor de aplicação que rode node.js.
ClientApp\dist\env.js
Nos dois pontos em que aparece, deve ser alterado de https://sitedoorgao/sisgp/gateway para o caminho do gateway no seu órgão.
ClientApp\dist\Index.html
A tag base deve ser alterada para refletir o caminho em que a aplicação está publicada entro do site do seu órgão. Exemplo: O acesso à aplicação é feito por meio do caminho https://sitedoorgao/sisgp/app, a tag deve ter o valor /app/.
web.config
A tag action do tipo Rewrite deve ser alterada para refletir o caminho em que a aplicação está publicada entro do site do seu órgão, conforme configuração feita anteriormente para o arquivo index.html.
app
)ClientApp/dist/env.js
, alterar o valor das variáveis window.__env.identityUrl
e window.__env.apiGatewayUrl
para a url do gateway;ClientApp/dist/index.html
, dentro da tag <base />
, colocar no href o caminho da publicação da pasta app no servidor;ClientApp/dist/web.config
, dentro da tag <action />
do tipo Rewrite, colocar na url o caminho da publicação da pasta app no servidor;Após instalação e configuração da aplicação, recomenda-se a validação dessa etapa acesdo a aplicação com os usuários de teste cadastrados na carga de teste:
URL da aplicação
sisgp_gestor
sisgp_cg
sisgp_coget
sisgp_coordenador
sisgp_diretor
sisgp_servidor
sisgp_servidor1
sisgp_servidor2
sisgp_servidor3
sisgp_servidor4
Obs.: Senha para todos os usuários ("qualquer carácter")
ATENÇÃO Assim que o sistema entrar em produção, os dados da tabela
Pessoa
eUnidade
cadastrados por esse script devem ser apagados da base de dados.
Ocelot.json
/pactotrabalho/{pactoTrabalhoid}/reabrir
AppSettings.json
5. Alteracoes da estrutura do BD para a V7.sql
: Alterações na estrutura do banco
Ocelot.json
6. Alteracoes da estrutura do BD para a V8.sql
: Alterações na estrutura do banco