Criação de tabelas

Para criar suas tabelas no banco de dados é necessário ter uma pasta _scripts no seu projeto com uma certa estrutura de subpastas e arquivos. Estas pastas e arquivos serão compactados automaticamente em um arquivo chamado _scripts.zip e adicionados ao seu pacote.

A tabela abaixo detalha melhor como deve ser a estrutura das subpastas e arquivos de scripts.

TipoNomeDetalhes
arquivoconfig.jsonObrigatório. Este arquivo descreve a ordem de execução dos scripts e qual banco de dados utilizar. É detalhado nas próximas seções.
subpasta

inicializacao

  • 0000-criar esquema.sql
  • 0001-criar tabela script.sql
Subpasta com scripts de inicialização. A criação do esquema próprio e da tabela de controle script devem ficar aqui. Os scripts dessa subpasta sempre são executados, por isso é importante verificar se os objetos já foram criados.
subpasta

<X>.<Y>

  • 0000-criar tabela tipos.sql
  • 0001-inclui campos novos.sql
  • 0002-altera tipo do campo.sql
Subpasta de scripts versionada, onde X e Y são números que indicam a versão do sistema ou do banco de dados. Os scripts dentro destas subpastas devem seguir uma numeração sequencial e são executados apenas 1 vez.
subpasta

dados

  • 0000-dados iniciais da tabela tipos.sql
  • 0001-registros de sistema.sql
Subpasta de scripts que populam tabelas criadas por scripts anteriores. Normalmente é utilizada para carga inicial de dados ou para garantir que dados de sistema estejam sempre presentes após a execução dos scripts. Estes scripts são sempre executados, por isso é importante garantir que os dados não serão duplicados.

Subpastas

O nome das subpastas tem um significado especial:

  • Subpastas com numeração X.Y (onde X e Y são números, por exemplo 1.0) têm a execução dos scripts controlada. Eles são executados apenas uma vez. 
  • Subpastas com outro tipo de nomenclatura não tem os scripts versionados. Isso significa que os scripts são executados toda vez que a extensão é aplicada no Master. Por isso esses scripts devem ser protegidos para reexecução. Se um certo script cria uma tabela, por exemplo, ele deve verificar se a tabela já existe antes de executar a criação da tabela para não disparar um erro e abortar a instalação ou atualização. 

Comandos SQL

Os comandos serão executados, dentro da mesma pasta, pelo ordem de numeração e, por isso, todos os arquivos devem ter nomes começando com 4 dígitos (formato ####-). A numeração não precisa ser sequencial, mas deve estar entre 0000 e 9999. 

É uma boa prática colocar, após a numeração, um texto descrevendo o que o script faz, como pode ser visto na imagem abaixo. 

Exceto pela numeração inicial, não há uma regra para o restante do nome. Você pode utilizar a descrição como achar melhor. Porém, não renomeie os scripts após eles terem sido aplicados no banco, pois o nome completo é utilizado pelo Master para controle da execução.

O arquivo config.json

O arquivo config.json é obrigatório para a execução do scripts. Nele você deve

  1. Definir qual banco de dados vai utilizar.
  2. Definir o schema de dados que será utilizado pela sua extensão.
  3. Definir a sequência das pastas para execução dos scripts.


Exemplos

sqlite3
{
   "sqlite":"plugins\\extensao\\database\\extensao.db",
   "schema":"dbo",
   "pastas":[
      “inicializacao”,
      “1.0”,
      "dados"
   ]
}
pgsql
{
  "pgsql": "ncrsolution",
  "schema":"<nome da extensao>",
  "pastas":[
    “inicializacao”,
    “1.0”,
    "dados"
  ]
}
mssql
{     
  "sqlserver": "<produto>",
  "schema": "<nome da extensao>",
  "pastas":[
    "inicializacao",
    "1.0",
    "dados"
  ]
}

Banco de dados

Os scripts pode ser aplicados em 3 servidores de banco de dados.

sqlserverO Master executa os scripts nas bases do POS e CBO que estão no Sql Server. Os scripts devem ser compatíveis com Sql Server 17 ou superior.
pgsql

O Master executa os scripts na base ncrsolution, mantida pelo Postgres embarcado do sistema. Os scripts devem ser compatíveis com PostgreSQL 10.

sqliteO Master cria o banco SQLite, caso não exista, e aplica os scripts nele. Estes bancos são locais e só podem ser acessados por aplicações que rodem no terminal master.


Para rodar os scripts no PGSQL.

Sempre utilize a chave "pgsql": "ncrsolution". Como nome do schema, utilize o nome da sua extensão para fácil localização e também para evitar colisão com outros schemas já criados.

"pgsql": "ncrsolution",
"schema":"<nome da extensao>"

Para rodar os scripts no SQLite3.

O SQLite não tem suporte a schemas, por isso não é necessário incluir a chave schema para esse engine.

"sqlite":"plugins\\extensao\\database\\<nome da extensao>.db",

Para rodar os scripts no Sql Server.

Utilize a chave "sqlserver": "<produto>" para indicar em qual banco de dados os scripts devem ser aplicados. Como nome do schema, utilize o nome da sua extensão para fácil localização e também para evitar colisão com outros schemas já criados.

"sqlserver": "pos",
"schema":"<nome da extensao>"
Notas

Quando nenhuma das 3 chaves é informada no arquivo config.json, o banco de dados será definido pela chave produto do manifesto. 

  • "produto": "pos" - Os scripts serão aplicados na base do POS
  • "produto": "cbo" - Os scripts serão aplicados na base do CBO
  • "produto": "master" - Os scripts serão aplicados na base ncrmaster do PGSQL
  • "produto": "universal" - Obriga a definição do banco de dados. Na falta de uma das 3 chaves o sistema não aplica os scripts e apresenta mensagem de erro por falta da chave.
Tabela script

A tabela script é necessária sempre que você utilizar scripts que são versionados no banco. Os scripts versionados não são reaplicados quando um pacote é atualizado com novos scripts.

Somente scripts em pastas no formato X.Y (onde X e Y são números) são versionados. Se sua extensão possui scripts desse tipo, será necessário criar um schema (exceto sqlite3) e a tabela script, dentro desse schema.

Abaixo temos exemplos da criação da tabela script nos engines de banco de dados suportados. Estes scripts devem ser colocados na pasta inicializacao. Repare que em todos os exemplos verificamos antes se o schema e a tabela existem antes de criá-los.


SQLite3

Criação da tabela script (sqlite3)
CREATE TABLE IF NOT EXISTS 'script' 
(
  'versao'	TEXT NOT NULL,
  'script'	TEXT NOT NULL,
  'dt_exec' TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
)
GO

CREATE INDEX IF NOT EXISTS 'script_pk' ON 'script' 
(
  'versao',
  'script'
);

PostgreSQL

Criação de schema e da tabela script (pgsql)
create schema if not exists extensao;
go

create table if not exists extensao.script
(
  versao character varying(10) not null,
  script character varying(100) not null,
  dt_exec timestamp not null default current_timestamp,
  constraint script_pkey primary key (versao, script)
);

SQL Server

Criação de schema (sqlserver)
if not exists(select * from sys.schemas where name = 'extensao') 
  exec('create schema extensao')
go

if object_id('extensao.script') is not null
return 

create table [extensao].[script]
( 
  [versao] [varchar](10) not null, 
  [script] [varchar](100) not null, 
  [dt_exec] [datetime] not null default getdate(), 
  constraint [script_pk] primary key clustered 
  ( 
    [versao] asc, 
    [script] asc 
  ) on [PRIMARY] 
) 
go
Acesso aos bancos de dados

Caso você precise de acesso às tabelas criadas por você, pode obter as credenciais de acesso aos bancos de dados utilizando uma das formas apresentadas abaixo.

Dados de conexão nos terminais padrão

Nos terminais normais, consultar o arquivo <pasta NCR Solution>\client\config\launcher.conexao

Exemplo de launcher.conexao
{
  "dados_conexao": {
    "usuario": "ncrcolibri",
    "senha": "!23465479280e1e5f2f574f",
    "servidor": "PC-PITTYBULL",
    "banco": "colibri-master",
    "banco_pos": "pos-neemo",
    "banco_cbo": "cbo-sandiego"
  },
  "dados_pgsql": {
    "usuario": "ncrmaster",
    "senha": "!0346545d7f5940007f4340",
    "pgsql": true,
    "banco": "ncrsolution",
    "servidor": "localhost",
    "porta": 4500
  },
  "portas": {
    "colibri_catalogo": 4100,
    "d-connect": 5600,
    "ncr_lock": 27272,
    "colibri_server": 4300,
    "ncr_master": 4000,
    "mensagens": 4200,
    "pgsql": 4500
  }
}

Dados de conexão nos terminais Master

No terminal master, consultar o arquivo <pasta NCR Solution>\master\config\ncrmaster.cfg

Exempo de ncrmaster.cfg
[Banco]
servidor = localhost
usuario = ncrcolibri
senha = !23465479280e1e5f2f574f
estado_base = 
banco_pos = pos-neemo
banco_cbo = cbo-sandiego

[BancoPG]
usuario = ncrmaster
senha = !0346545d7f5940007f4340
banco = ncrsolution

[Portas]
colibri_server = 4300
ncr_lock = 27272
colibri_catalogo = 4100
ncr_master = 4000
mensagens = 4200
pgsql = 4500
d-connect = 5600


Em ambos será possível obter as seguintes informações

  • Nome ou endereço do servidor MSSQL;

  • Nomes dos bancos;
  • Usuários;
  • Senhas de acesso (criptografadas);
  • Portas IP (Pgsql e Master).

O servidor PGSQL está sempre instalado na mesma máquina do Master, portanto tem o mesmo endereço.

As senhas de usuário do banco de dados são criptografadas. Para descriptografá-las utilize o endpoint disponível na API do Master.;

Para usar o endpoint de descriptografia você precisa 

  • Do servidor e porta do Master, que podem ser obtidos dos arquivos citados acima.
  • Da chave de licença da sua extensão, também conhecida como api key. Ela foi gerada automaticamente para você ao cadastrar sua extensão no Market Place.
  • Da licença do Colibri atualizada no Master, com sua extensão ativada na licença.

É vedada a criação de objetos e gravação de dados em schemas e tabelas do POS. 

Porém você pode criar seus próprios schemas e tabelas em nossos bancos, conforme descrito nos tópicos anteriores.