CONSOLIDAÇÃO DA DOCUMENTAÇÃO TÉCNICA...A sua estrutura de arquivos de configuração ficaria da seguinte maneira: -NBPA.config Aqui estarão todas as configurações que dizem

CONSOLIDAÇÃO DA

DOCUMENTAÇÃO TÉCNICA

ARQUITETURA DE SISTEMAS - AS

Versão 01.00.00

Salvador (BA), dezembro de 2018

SEFAZ-BA Secretaria da Fazenda do Estado da Bahia SGF Superintendência da Gestão Fazendária DTI Diretoria de Tecnologia da Informação GEPIN Gerência de Politicas da Informação

Secretaria da Fazenda do Estado da Bahia 17/12/18

DTI - Diretoria de Tecnologia da Informação

Página - 2 Consolidação_tecnica_AS_VS_02_R4.docx

CONTROLE DE VERSÃO

Versão Data Responsável Histórico

01.00.00 19/11/2019 AS Criação do Documento




RESUMO

O presente documento contempla os Padrões de Elaboração Documentos a serem

adotados pelos desenvolvedores da Secretaria da Fazenda do Estado da Bahia. Esse

Manual abrange os padrões de formatação de Manuais, Modelos e Artefatos da

Metodologia de Desenvolvimento e Manutenção de Sistema (MDMS), como também

pela Administração de Dados para a documentação de padrões e procedimentos.

Todos os Manuais citados acima podem ser acessados através do PRT – Procedimentos de

Rotinas de Tecnologia (http://prt.sefaz.ba.gov.br/).

http://prs.sefaz.ba.gov.br/




Índice

1. INTRODUÇÃO ........................................................................................................... 5

2. PADRÃO DE ARQUIVOS DE CONFIGURAÇÃO ................................................ 5

3. URLs DOS REPOSITÓRIOS DE COMPONENTES SEFAZ E SONAR ........... 10

4. MENU HORIZONTAL ANGULAR ....................................................................... 15

5. NOVAS DIRETRIZES PARA INTEGRAÇÕES DE SISTEMAS ....................... 15

6. TEMPLATES DE MENU – SISTEMA PRINCIPAL E SEUS MÓDULOS ....... 17

7. PADRÃO DE DESENVOLVIMENTO, LAYOUT/IDENTIDADE VISUAL E

UTILIZAÇÃO DE COMPONENTES PARA TODOS OS PROJETOS DA INDRA 24




1. INTRODUÇÃO

Este documento contém a consolidação de todos os padrões e boas práticas encaminhados

pela equipe AS, até o momento. Nesta versão foi contemplado dois novos itens: Padrão dos

arquivos de configuração e URLs dos Repositórios de componentes SEFAZ e Sonar.

2. PADRÃO DE ARQUIVOS DE CONFIGURAÇÃO

2.1. Aplicações - LEGADO

Para a correta aplicação do padrão sugerido, é necessário que as estruturas de arquivos de

configurações obedeçam às recomendações exemplificadas a seguir.

Para efeito de exemplo, utilizaremos o sistema legado SLCT. A sua estrutura de arquivos de

configuração ficaria da seguinte maneira:

-ASLIB.config

Este arquivo deverá conter as chaves referente à configuração do ASLIB na aplicação.

É possível informar uma chave do tipo “autenticação”, e atribuir valores relativos à mesma

como, por exemplo, “habilitar” ou “não” o certificado digital.

Este arquivo poderá conter configurações do Crystal Reports e deverá conter uma chave

referenciando a connectionString a ser utilizada.

Exemplo de uso:

<Add key="DefaultConnectionString" value="HOMOLOGACAO"/>

-ConnectionStrings.config

Deve conter apenas a chave com a connectionString referente ao ambiente onde

o arquivo será publicado.

-Packages.config (Padrão do .NET)

Exemplo de uso:

<package id="Microsoft.AspNet.WebApi.Core" version="5.2.4"

targetFramework="net452" />

<package id="Microsoft.AspNet.WebApi.Cors" version="5.2.3"


-SLCT.config

Este arquivo substitui o “appSettings.config”. Aqui deverão estar todas as configurações que

dizem respeito apenas a esta aplicação. Exemplo de chave: “EmailGestor”,

“Mensagens_de_alerta”.

-Web.config

Deve referenciar o arquivo connectionStrings.config bem como o arquivo que contém as

configurações específicas da aplicação como, SLCT.config.

IMPORTANTE: Não é permitido informar login e/ou senha nas chaves dos arquivos de

configuração sem que os mesmos estejam criptografados. A exceção para este caso é para

acessos FTP onde, por inviabilidade técnica, não seja possível o uso da criptografia e,




portanto, devendo ser tratado o assunto junto às áreas de Arquitetura, Infraestrutura e

Segurança.

-RegExUrlMapping.config

Configuração de rotas via expressão regular do ASLIB

2.2. API | .NET 4.5.2 com ASLIB 2.2.0



Para efeito de exemplo, utilizaremos a API NBPA. A sua estrutura de arquivos de


-NBPA.config

Aqui estarão todas as configurações que dizem respeito apenas a esta aplicação.

Nota: Embora esta aplicação tenha sido utilizada no exemplo, atualmente ela não atende ao

padrão pois utiliza o arquivo -appSettings.config em detrimento ao recomendado.

Exemplo de uso:

<add key="ano_inicio_etapa" value="2015" />


Este arquivo contém uma lista dos componentes utilizados no projeto e suas respectivas

versões, bem como frameworks.

Exemplo de uso:



-Web.config


configurações específicas da aplicação como, NBPA.config.





Segurança.




2.3. ANGULAR



Para efeito de exemplo, utilizaremos a solução Angular NBPP (com Service Worker). A sua

estrutura de arquivos de configuração ficaria da seguinte maneira:

-Web.config

Este arquivo torna-se necessário para aplicativos Angular apenas para habilitar a

funcionalidade de URL Rewrite no servidor IIS, e expor as rotas de comunicação, protocolos

de compatibilidade de browser, e o nome da página principal que será aberta ao acessar o

endereço da mesma via navegador, por exemplo.

Exemplo de uso:

<rewrite>

<rules>

<rule name="NBPP Routes" stopProcessing="true">



<match url=".*" />

<conditions logicalGrouping="MatchAll">



<add input="{REQUEST_FILENAME}" matchType="IsFile"

negate="true" />



<add input="{REQUEST_FILENAME}" matchType="IsDirectory"

negate="true" />



<add input="{REQUEST_URI}" pattern="^/(api)" negate="true" />

</conditions>



<action type="Rewrite" url="/index.html" />

</rule>

</rules>

</rewrite>




2.4. API com ASLIB 2.2.0 ou 3.0.0 | ANGULAR



Para efeito de exemplo, utilizaremos a solução API FCAS. A sua estrutura de arquivos de


- ASLIB.xml

Configurações referentes ao ASLIB e conexão com o banco de dados.




Exemplo de uso:



-FCAS.config

Este arquivo substitui o “appSettings.config”. Aqui deverão estar todas as configurações que

dizem respeito apenas a esta aplicação.

-Web.config

Para o Backend:


configurações específicas da aplicação como, NBPA.config.





Segurança.

Para o FrontEnd:

Pode conter ou não o arquivo “web.config” na raiz do pacote publicável. Caso tenha, atentar

para a informação da página inicial do sistema, ou seja, observar as configurações de rotas

(url rewrite).




2.5. .NET 4.5.2 com Entity Framework 6.X + ASLIB.ENTITY



Para efeito de exemplo, utilizaremos a aplicação MFCVI ou SIGEP. A sua estrutura de

arquivos de configuração ficaria da seguinte maneira:

-ConnectionStrings.config

Deve conter apenas a chave com a connectionString referente ao ambiente onde o arquivo

será publicado.




Exemplo de uso:



-Web.config


configurações específicas da aplicação como, MFCVI.config.





Segurança.

2.6. ASLIB ORM



Para efeito de exemplo, utilizaremos a aplicação PPFF. A sua estrutura de arquivos de


- ASLIB.xml

Não é necessário conter informações específicas de banco de dados Ex: instância, banco,

timeout etc.




Exemplo de uso:






-Web.config (Padrão do .NET)


configurações específicas da aplicação como caso seja necessário. Não é obrigatório a

existência do arquivo de configuração do escopo da aplicação (ex.: PPFF.config).

3. URLs DOS REPOSITÓRIOS DE COMPONENTES

SEFAZ E SONAR

Foi realizada a migração do TFS 2010 para o TFS 2018, bem como evoluímos nosso

gerenciador de pacotes, permitindo reunir todos os repositórios em um só servidor

(tfs.sefaz.ba.gov.br).

Desta forma, todos estes repositórios terão função de proxy e cache o que vai proporcionar

melhorias consideráveis dentre elas as seguintes:

1. Mais segurança com varredura e proteção do antivírus;

2. Armazenamento dos componentes permitidos em cache local;

3. Redução de tráfego de rede para internet;

4. Possibilidade de invalidar todo o cache, caso necessário;

5.ZPossibilidade de permitir/proibir download de componentes não autorizados;

6. Remover componente específico do cache;

7. Centralização do acesso a estes repositórios em um único servidor, não sendo mais

necessária liberação acesso no firewall a URLs respectivas;

8. Pesquisa das versões atuais via web;

9. Acesso ao “help/readme” dos componentes com exemplos via web (Angular e

Typescript);

10.Controle centralizado de atualizações.

Favor verifiquem seus ambientes e atualizem

(caso necessário) conforme listagem abaixo:




NPM (Angular / Typescript):

http://tfs.sefaz.ba.gov.br:4873/repository/npm/

1. Acessar a o diretório: %userprofile%

2. Abrir o arquivo “.npmrc” que deverá conter apenas a seguinte linha:

registry=http://tfs.sefaz.ba.gov.br:4873/repository/npm/

NUGET (.NET – VB.Net e C#) – Não utilizar o repositório público

http://tfs.sefaz.ba.gov.br:4873/repository/nuget/

Data limite para DESATIVAÇÃO do servidor anterior: 20/09/2018

Como atualizar:

1. No Visual Studio, menu Tools ou Ferramentas escolher NuGet Package

Manager / Gerenciador de Pacotes Nuget

http://tfs.sefaz.ba.gov.br:4873/repository/npm/

http://tfs.sefaz.ba.gov.br:4873/repository/nuget-sefaz/




2. Clicar em Package Sources e substituir o Source do repositório SEFAZ.

Que deverá ser o principal e único.

3. Desmarcar o repositório público do nuget e clicar em OK.







Maven (Java):

Proxy: Busca em todos os repositórios privados e públicos

http://tfs.sefaz.ba.gov.br:4873/repository/maven-public/

Componentes internos – Releases (apenas para publicação de componentes,

inicialmente do e-Fiscalização)

http://tfs.sefaz.ba.gov.br:4873/repository/maven-releases/

Componentes internos – Snapshots (apenas para publicação de componentes,

inicialmente do e-Fiscalização)

http://tfs.sefaz.ba.gov.br:4873/repository/maven-snapshots/

URL do Sonar – Apenas criado um DNS, não houve modificação

http://sonar.sefaz.ba.gov.br:9000

VMS FÁBRICAS (informativo):

Portas e servidores necessários para acesso ao TFS, Sonar e Repositórios:

1. Sonar

- Versão Sonar: 7.2.1

– DNS: tfs.sefaz.ba.gov.br

- Servidor atual: NILOPOLIS

a. HTTP 9000

http://tfs.sefaz.ba.gov.br:4873/repository/maven-public/

http://tfs.sefaz.ba.gov.br:4873/repository/maven-releases/

http://tfs.sefaz.ba.gov.br:4873/repository/maven-snapshots/

http://sonar.sefaz.ba.gov.br:9000/




2. TFS e Repositórios (Nuget, Maven, NPM)

– DNS: tfs.sefaz.ba.gov.br

- Servidor atual: MONTEFORMOSO

a. http 80

b. http 8080

c. http 4873

4. MENU HORIZONTAL ANGULAR

Reitero que o HTML gerado pela GERAD que foi disponibilizado para fábrica conforme e-

mail anexo, foi um protótipo para o desenvolvimento do RF (e-mail anexo) do ASLIB

angular transcrito abaixo:

RF. Desenvolver Componente Menu Horizontal

Desenvolver o componente padrão de menu horizontal, que será utilizado em alguns sistemas

web da SEFAZ, para possibilitar que sistemas que atuem como módulos de outros sistemas

possam manter suas funcionalidades sem a necessidade de alteração do sistema pai em

decorrências de alterações no menu, quando for criada uma nova funcionalidade no módulo.

Observo que o protótipo era apenas para a visualização do layout discutido em reunião, e foi

desenvolvido e disponibilizado apenas para exemplificação da solução, com os recursos e aporte

técnico da equipe Web design da GERAD, sem contemplar os requisitos exigidos para

implementação desta funcionalidade pela Indra.

Portanto, entendemos que os ajustes citados no seu e-mail não cabem a GERAD, e sim faz parte

da demanda do ASLIB Angular que está sob a responsabilidade da Indra.

5. NOVAS DIRETRIZES PARA INTEGRAÇÕES DE

SISTEMAS

Com os primeiros projetos sendo implantados pela nova Fábrica de Software, surgiram

dúvidas sobre as novas diretrizes relativas à integração de sistemas.

Fizemos um alinhamento entre os gerentes das três áreas (GDSAT. GDAF e GEPIN) e o

diretor da DTI sobre este assunto. É importante ressaltar que estas diretrizes buscam

possibilitar o início da mudança do modelo de integração de sistemas da SEFAZ-BA, em

vista dos problemas associados ao modelo atual.

Segue o que ficou acertado. Caso tenham dúvidas e/ou sugestões de complementos/ajustes,

fiquem à vontade para se manifestar:




1) A regra para integração dos novos sistemas/módulos que serão desenvolvidos com

outros sistemas/módulos existentes é sempre usarmos webservices em detrimento da

integração via procedures de banco de dados.

2) A não utilização de webservices, e consequente integração via procedures, só será

admitida quando alguma dessas hipóteses ocorrer:

a. Se tratar de integração de um novo sistema/módulo com um sistema/módulo com

previsão de desativação em curto ou médio prazo. O objetivo, neste caso, é não gastarmos

recursos com um sistema que deva “morrer” em pouco tempo;

b. O projeto de origem e o projeto alvo da integração fizerem parte do mesmo projeto

pai. Ou seja, não será necessária a utilização de webservices para integração de dois

subprojetos de um mesmo sistema já que o principal objetivo dessa forma de integração é

tornar os processos de negócio independentes entre si;

c. Houver alguma outra forte justificativa para não utilização da integração via

webservices. Esta justificativa pode ser técnica (desempenho ou impossibilidade tecnológica,

etc.) ou relativa a alguma restrição do negócio (impeditivos em relação a prazos e/ou custos

do projeto);

i. Não deverão ser aceitas justificativas baseadas meramente em menor esforço ou menor

custo de implementação;

ii. Não servirá como justificativa a existência prévia de procedure que disponibilize a mesma

integração pretendida;

3) O desenvolvimento dos webservices de integração, tanto no projeto de origem como no

projeto alvo, devem, preferencialmente, ser feitos pela própria Fábrica de Software, com as

seguintes premissas:

a. Para os desenvolvimentos nos sistemas alvo, deverão ser abertos projetos ou subprojetos

específicos;

b. Os gestores e/ou líderes dos sistemas alvo deverão ser envolvidos o mínimo possível, com

as especificações sendo feitas, quando couber, pela própria Fábrica e/ou líder do projeto de

origem;

c. Quando, além da mera integração, houver necessidade de outros ajustes no sistema alvo,

será avaliado, caso a caso, a conveniência desses ajustes serem feitos pela Fábrica ou pela

própria equipe do sistema alvo;

d. A Fábrica deverá fazer a passagem para a equipe do sistema alvo, quando o

desenvolvimento da integração ficar a seu cargo;

4) A área de Administração de Dados (AD) da GEPIN deverá fazer a Governança dos

webservices criados para integração, assim como já o faz para as procedures de bancos de

dados.

a. Antes da criação de um novo webservice de integração, AD deverá ser consultada para

identificar a existência prévia de outro serviço ou procedure que forneça a integração

pretendida;

i. Quando já houver um webservice que ofereça parte da integração pretendida, deve-se dar

preferência para ajustar o webservice existente, ao invés se criar um novo;




ii. Quando um novo webservice disponibilizar integração que já exista via procedures, AD

deverá fazer uma Avaliação de Impacto com o objetivo de controlar a adaptação das

aplicações existentes para consumo do novo serviço no lugar da integração via banco:

1. As aplicações existentes deverão fazer os ajustes na integração quando de uma nova

versão não corretiva do sistema;

2. Este ajuste poderá ser dispensado quando se tratar de aplicação com previsão de

desativação a curto e médio prazo ou por outra justificativa a ser avaliada caso a caso;

5). Essas diretrizes devem ser adotadas em todos os novos sistemas a serem desenvolvidos

pela SEFAZ-BA, tanto na modalidade de Fábrica de Software como nos desenvolvimentos

internos.

6). Os desenvolvimentos dos webservices de integração deverão seguir as orientações e

padrões técnicos definidos pela área de Arquitetura de Sistemas (AS) e pela equipe de

Infraestrutura da GETEC.

6. TEMPLATES DE MENU – SISTEMA PRINCIPAL E

SEUS MÓDULOS

Pontos Abordados:

- A INDRA apresentou os slides em anexo, mostrando a necessidade do Sistema MFC

(Malha Fiscal Censitária) com ênfase no módulo de verificação de indícios (MFCVI) que

será desenvolvido por essa empresa.

- Foi mostrado a opção atual (existente na SEFAZ) para criação de MENU no Sistema

Principal e nos seus respectivos módulos, sabendo-se que cada Sistema é uma “aplicação”.

OPÇÃO 1(slide)

- Foi apresentada uma proposta para a criação de MENU no Sistema Principal (macro itens)

e MENU interno nos respectivos módulos (subitens), com o objetivo de tornar essas

aplicações mais “independentes”. OPÇÃO 2 (slide)

- Foram apresentados os principais “motivos” e os principais pontos positivos e negativos

dessas duas opções. A INDRA sugere a OPÇÃO 2. Porém queria verificar com as áreas de

AS e GERAT se existe impedimento técnico ou descumprimento de algum padrão interno

SEFAZ, antes de apresentar a proposta para avaliação do Gestor do MFC.

- A GERAT informou que não há impedimentos. Porém informou sobre a necessidade de ser

feito um estudo de viabilidade gráfica antes de emitir um parecer.

- Foi esclarecido pela GERAT e AS que essa solução requer alteração no TEMPLATE

PADRÃO de aplicação web (GERAT) e no ASLIB (AS).




Pontos Acordados:

- A INDRA enviar esse e-mail com o resumo dos itens tratados nessa reunião, bem como

uma sugestão de itens do MENU (ainda não confirmados pelo Gestor) para a GERAT

realizar o estudo de viabilidade gráfica.

- A GERAT ficou de informar um prazo para retorno deste estudo e apresentará o modelo

(menu) em reunião. A sugestão dessa área é só levar a proposta para o gestor após esse

retorno.

- A GERAT informou que irá considerar a possibilidade “mobile” apesar de não ser um

requisito do Sistema. Também foi informado que há um limite para a quantidade de itens no

Menu interno do módulo (7 itens macros podendo esses terem subitens, sem restrição de

limite de subitens). A ideia é usar MENU HORIZONTAL.

- Após a avaliação da GERAT será apresentada a proposta para o GESTOR. Esse

aprovando, a ideia é aplicar essa mesma solução para os demais módulos do Sistema MFC.

- Aplicação MFC é do setor TRIBUTÁRIO (TEMPLATE ASLIB AZUL), conforme

informado pela GDSAT.

- MENU APLICAÇÃO PRINCIPAL (SISTEMA MFC) - Rascunho

Batimentos

Verificação de Indícios

Monitoramento On-Line

Gestão

- MENU INTERNO DO MÓDULO VERIFICAÇÃO DE INDÍCIOS (SISTEMA MFCVI) -

Rascunho

Menu Cadastro

Tipo de Indício

Ordem de Verificação

Processo de Verificação

Exceção

Menu Fiscalização

Acompanhar Fiscalização

Registrar Manifestação Fiscal




Menu Consulta

Tipos de Indício

Selecionar Indício para fiscalização

Consultar Indício

Ordens de Verificação de Indícios

Processo de Verificação

Exceção

Importar Dados

Carregar resultados de batimentos

- Os itens de MENU acima podem vim a ser alterados pelo GESTOR, porém deve ser

obedecido o limite de 7(sete) itens para o Menu interno do módulo (sem restrição para os seus

subitens.

Desktop




Desktop Submenu

Mobile




Mobile Menu

Desktop




Desktop Submenu

Mobile_Hover




Mobile Submenu




7. PADRÃO DE DESENVOLVIMENTO,

LAYOUT/IDENTIDADE VISUAL E UTILIZAÇÃO DE

COMPONENTES PARA TODOS OS PROJETOS DA

INDRA

Conforme acordado esta ATA, servirá como definição de Arquitetura

PADRÃO DE ARQUITETURA:

1 . Os padrões definidos pela Indra para desenvolvimento de WebAPI utilizados no NBPA

devem ser aplicados e seguidos por todos os projetos, que deverão ser ajustados até no máximo

liberação de uma próxima versão.

LAYOUT / IDENTIDADE VISUAL:

2 . Os sistemas deverão seguir padrão de identidade visual aprovado pela SEFAZ/GERAD,

onde:

FRONT-END

Deve ser desenvolvido utilizando o ASLIB e componentes de terceiros, exceto em casos

excepcionais como o NBPP com layout pré-aprovado pela SEFAZ.

COMPONENTES AUTORIZADOS:

ASLIB – Biblioteca de componentes

@aslib/common 3.0.0-rc.6

@aslib/components 3.0.0-rc.5

@aslib/core 3.0.0-rc.4

@aslib/dual-list 3.0.2

@aslib/enviroment 3.0.0-rc.7

@aslib/grid 3.0.0-rc.6

@aslib/icon 3.0.2

@aslib/input-info 3.0.0-rc.3

@aslib/loading 1.0.0-rc.2

@aslib/modal 3.0.4




@aslib/security 3.0.0-rc.10

@aslib/template 3.0.0-rc.6

@aslib/theme 3.0.0-rc.5

@aslib/title 3.0.3

ASCAS – Controle de Acesso

@ascas/core 3.0.0-rc.14

COMPONENTES DE TERCEIROS:

§ ANGULAR:

o "@angular/cli": "1.7.4"

o “@angular/**”: “>5.0.0 <6.0.0”

o “typescript”: “>=2.4.2 <2.7.0”

§ DIVERSOS:

· "@ng-bootstrap/ng-bootstrap": "1.1.2" ou “^1.0.0”

· “primeng/inputmask” : “5.2.5”

· “primeng/multiselect” : “5.2.5”

· “primeng/autocomplete” : “5.2.5”

· “primeng/editor”: “5.2.5”

· "@ng-idle/core": "^2.0.0-beta.15"

· "@ng-idle/keepalive": "^2.0.0-beta.15"

· "ng2-currency-mask": "4.4.1"

· "ng-recaptcha": "^2.1.1"

· "underscore": "^1.8.3"

· "rxjs": "^5.5.6"

· "bootstrap": Embutido no ASLIB

· "font-awesome": Embutido no ASLIB

UTILIZAÇÃO:

O exemplo de código para utilização dos componentes está publicado em:

http://poctsf:4873/

http://poctsf:4873/







LAYOUT VISUAL:

PRÉ-LOADING

i. Arquivo .angular-cli.json

ii. Arquivo: index.html

MODAL:

@aslib/modal




DUAL-LIST:

@aslib/dual-list




LOADING

@aslib/loading

BUILD E PUBLICAÇÃO:

Utilizar o seguinte padrão de código:

ng build --prod --aot -ec --base-href /sistemas/dscad/-base-href /sistemas/dscad/

Não deverá ser utilizada tag de environment. Ex: --env=hml ou –env=prod, etc. Utilizar

o ASLIB/ENVIROMENT para detecção automática do ambiente.

MIGRAÇÃO ANGULAR 5 – COMPATIBILIDADE COM AOT (Ahead of Time

Compilation):

Seguir roteiro disponibilizado pela Indra em Abril de 2018 (anexo) para atualização e

utilização dos padrões definidos acima. Caso exista versão mais nova disponibilizar

para SEFAZ.

BACK-END:

COMPONENTES:

Todos os componentes devem ser referenciados a partir do Nuget e/ou Nuget SEFAZ.

Para utilização de componentes de terceiros deve ser seguido o seguinte procedimento:

Solicitar prospecção via mantis, com informações do Site, documentação, utilização,

repositório e justificativa. Será realizado download do código, inspeção sonar, avaliação

de identidade visual e caso aprovado, compilado e disponibilizado via Nuget SEFAZ.

O DSCAD, não possuía configuração do repositório da SEFAZ, adicionada url:

http://labas.sefaz.ba.gov.br/sistemas/nuget/nuget/

http://labas.sefaz.ba.gov.br/sistemas/nuget/nuget/




ARQUITETURA

Padrão de desenvolvimento de Web APIs proposto pela Indra. Todos os projetos

(NBPA já utiliza)

HTTPS

C# .net 4.5.2

EntityFramework 6.1.3

ASLIB.Entity / ASLIB.Security para criptografia das ConnectionStrings

SEGURANÇA / BOAS PRÁTICAS

Web.config: Os itens devem estar criptografados, não devendo conter nenhum item não

autorizado pela área de segurança, mesmo que comentados, como:

Nomes de usuário;

Senhas;

Definições de servidor;

O código fonte não deve possuir trechos de codificação comentados, pois, no controle

de versão (TFVC) é possível realizar comparação com códigos anteriores;

Utilizar padrão de documentação da linguagem.

As configurações de CORS (Cross-origin resource sharing) não devem ser atribuídas

como “*”, ou seja, aberta a todos, o sistema deve possuir configuração para limitar o

acesso apenas ao FontEnd e/ou sistemas permitidos. Utilizar como padrão/exemplo a

configuração já utilizada no NBPA; para utilização por sistemas externos a

comunicação deverá utilizar obrigatoriamente certificado digital.

INSPEÇÃO E AUDITORIA DE CÓDIGO:

Todos os itens citados serão inspecionados;

Inspeção via SonarQube;

Deverá ser realizada pela equipe do projeto em data/hora igual ou imediatamente

posterior a criação do LABEL no TFS;

Será realizada inspeção de confirmação pela equipe responsável AS ou GQS.

Documents

CONSOLIDAÇÃO DA DOCUMENTAÇÃO TÉCNICA...A sua estrutura de arquivos de configuração ficaria da seguinte maneira: -NBPA.config Aqui estarão todas as configurações que dizem