Quando aplicações consomem dados do CIGAM — seja por meio dos serviços disponibilizados ou pela camada de objetos do banco de dados — é necessário informar os parâmetros de data e hora utilizados no controle de gravação dos registros. Dessa forma, é possível filtrar apenas os registros que foram alterados a partir da data e hora informadas.

Caso esses parâmetros não sejam informados, o sistema retornará todos os dados do cadastro correspondente.

O CIGAM não realiza controle por flags de leitura ou integração. Caso esse tipo de controle seja necessário, ele deverá ser implementado pelas aplicações de terceiros em suas próprias tabelas.

Em integrações, recomenda-se também informar os parâmetros correspondentes à chave única do cadastro, permitindo a obtenção de um registro específico quando necessário.
O controle de acesso é realizado por meio do parâmetro PIN, que será detalhado posteriormente.

Quando aplicações de terceiros enviam dados para o CIGAM, as informações são registradas na tabela de integração, desde que sejam aceitas pelo sistema. A importação e o processamento desses dados ocorrerão somente quando o programa específico da Aplicação de Importação for executado.

Caso algum dado não seja aceito, nenhum registro será inserido na tabela de integração. Nessa situação, será retornada ao sistema chamador uma mensagem de erro contendo o código e a descrição do problema.

Para o controle de existência de registros, as camadas de consulta disponibilizam uma lista contendo apenas os campos-chave de todos os registros existentes na tabela. Essa lista permite que a aplicação de terceiros compare essas informações com sua base local e identifique registros que tenham sido excluídos no CIGAM.

Se a tabela possuir um grande volume de registros ou ocorrerem muitas exclusões, pode-se optar pela criação de uma trigger para consumir o respectivo serviço a cada exclusão realizada.

No entanto, é importante considerar que o uso de triggers pode impactar negativamente a performance da aplicação, especialmente quando acionadas por requisições de webservices.

Serviços disponíveis

Compras

Configurador

Estoque

Faturamento

Financeiro

Genérico

Projetos

Estrutura dos registros

A tabela de integração é onde devem ser inseridos os registros a serem posteriormente importados pelo CIGAM.

Todos os tipos de cadastros utilizam essa mesma tabela. Para identificar qual rotina de importação será responsável pelo processamento de cada registro, é utilizado o campo Tipo.

Alguns exemplos de valores para esse campo são:

MATCAD - Cadastro de materiais
EMPCAD - Cadastro de empresas

Essa tabela possui um grande número de campos, projetados para atender às necessidades de diferentes tipos de cadastros do CIGAM. Entretanto, apenas os campos ID e Tipo são indexados, garantindo melhor desempenho nas consultas essenciais.

Camada de Serviços

A camada de serviços atua como porta de entrada para as integrações com o CIGAM.

Para cada tipo de cadastro/registro, existe um serviço específico responsável pelo recebimento e tratamento das informações. Além dos parâmetros próprios de cada rotina, esses serviços também incluem o parâmetro PIN, utilizado para identificar o usuário ou a aplicação responsável pela requisição.

Controle de Status dos Registros

A tabela de integração possui um campo de controle de status, utilizado para gerenciar o processamento dos registros.

Quando existe relacionamento máster-detalhe, o controle de status é realizado no registro máster. Esse mecanismo evita que o programa de importação seja executado enquanto os dados ainda estão sendo inseridos.

Dessa forma, o status do registro máster só é liberado após a inclusão de todos os registros de detalhe, garantindo a consistência das informações.

Outra estratégia possível é que o programa de integração insira o registro máster por último, assegurando também a integridade dos dados no momento da importação.

Consulta à Tabela de Integração

Existe um webservice de listagem da tabela de integração que permite consultar os registros utilizando diferentes filtros, como:

ID da tabela
Data de inclusão do registro
Tipo de registro
Combinações desses filtros

Esse serviço auxilia aplicações de terceiros a verificar se um determinado registro já foi importado, permitindo um controle mais eficiente dos dados integrados.

Validação de parâmetros

Durante a requisição de um serviço, caso algum parâmetro obrigatório não seja informado, o sistema retornará uma mensagem de erro indicando o nome do parâmetro ausente.

Quando houver mais de um parâmetro obrigatório não informado, todos os nomes serão listados na mesma mensagem, facilitando a identificação e a correção pela aplicação integradora.

Para parâmetros cuja obrigatoriedade depende do preenchimento de outro campo, será exibido um asterisco (<*>) após o nome do parâmetro.
Essa marcação indica que o parâmetro se torna obrigatório apenas quando o campo relacionado for informado.

Tabela de integração e log

Tabelas envolvidas:

Integração: %GEINTEGRADOR%
Log de integração: %GEINTEGRADORLOG%

Todas as alterações de dados enviadas ao CIGAM permanecem registradas na tabela de integração até serem processadas pela Aplicação de Integração. Sempre que uma das camadas do sistema realizar alterações nessa tabela, será incluído automaticamente um registro correspondente na tabela de log.

Como as tabelas de integração e log possuem campos com nomes genéricos — utilizados para atender diferentes cadastros e rotinas do CIGAM — tanto a consulta quanto a inclusão de dados devem ser realizadas por meio das camadas responsáveis, que apresentam os campos com as nomenclaturas adequadas para cada tipo de cadastro.

Banco de dados de integração

As tabelas de integração e log ficam armazenadas em um banco de dados separado. Esse banco é acessado:

Pelas aplicações do CIGAM, por meio do Database CIGAM_INTEGRA
Pela Aplicação de Integração (componente CGIntegrador.ecf)

Caso o banco de dados de integração seja diferente do banco utilizado pelo CIGAM — inclusive quando houver apenas mudança de database ou usuário — deve ser configurada uma connection string chamada INTEGRACAO no arquivo de configuração da aplicação.

Também é necessário informar o banco de dados dessa nova conexão no parâmetro providerName.

Exemplo:

 <add  name="CIGAM"  connectionString="Server=servidor;Database=BD;User ID=USER;Password=SENHA;" />
 
 <add  name="INTEGRACAO"  connectionString="Server=servidor;Database=BD;User ID=USER;Password=SENHA;"  providerName="02" />

O código do banco de dados do CIGAM deve ser informado na configuração BANCO_DADOS da aplicação.

Exemplo:

 <add key="BANCO_DADOS" value="03" />

Registro de requisições

Para registrar requisições provenientes de aplicações de terceiros, deve-se utilizar o parâmetro CGREQUISICAOWS.

Caso seja necessário registrar requisições apenas de serviços específicos, utiliza-se o parâmetro CGREQUISICAOWS_ seguido do tipo de registro correspondente.

Por exemplo, para registrar requisições relacionadas ao cadastro de notas fiscais, o parâmetro seria: GREQUISICAOWS_CADNF1.

Esses parâmetros devem ser configurados no arquivo web.config, na seção settings, ou diretamente no arquivo settings.config, quando existir.

Exemplo de configuração:

 <add  key="CGREQUISICAOWS" value="C:\cigam\Temp\" />
 
 <add  key="CGREQUISICAOWS_CADNF1" value="C:\cigam\Temp\NF\" />

Caso não seja necessário registrar requisições em arquivos, nenhum desses parâmetros precisa ser configurado.

Registros correlatos

A tabela de integração pode conter registros correlatos ainda pendentes de importação. Um exemplo comum ocorre nas relações pedido → itens → grade do item.

Nesse cenário, quando o pedido for importado, o sistema verificará se existem itens vinculados a esse pedido. Da mesma forma, durante a importação de um item do pedido, será verificada a existência de registros de grade do item associados.

Nesse processo, somente os registros com status liberado serão avaliados e poderão ser importados ou recusados.

Registros correlatos que não estiverem liberados não serão processados naquele momento e, consequentemente, não serão reavaliados posteriormente. Para evitar que registros permaneçam indevidamente na tabela de integração, será executada uma rotina de limpeza.

Essa rotina tem como objetivo excluir registros com ID correlato cujo registro máster já não esteja mais pendente de importação. Cada exclusão realizada por essa rotina será registrada em log específico, garantindo o rastreamento das operações efetuadas.

Segurança

As aplicações de terceiros não utilizam o cadastro de usuários nem os direitos do CIGAM, pois não possuem meios adequados para gerenciar essas informações.

A autenticação e o controle de acesso são realizados através de PINs e da chave de criptografia (CHAVE_CRYPTA), definidos no arquivo de configuração do ambiente do Web Service, na seção <appSettings>.

📌 PIN

O PIN é utilizado para identificar quem está realizando a requisição e determinar quais serviços estarão disponíveis para cada integração. Esse parâmetro deve ser configurado no arquivo de configuração do Web Service.

No exemplo a seguir, requisições que utilizarem o PIN XW@#25Qo terão acesso apenas aos serviços CADMAT e CADEMP. Os demais PINs (@#0Q1o2, W#12@Abfg e 20020004) não possuem restrições definidas e, portanto, podem acessar todos os serviços.

  <appSettings>
    <add key="pin" value="XW@#25Qo;@#0Q1o2;W#12@Abfg;20020004" />
    <add key="XW@#25Qo" value="CADMAT;CADEMP" />
  </appSettings>

💡 Recomendação: Defina PINs com alto nível de complexidade, contribuindo para aumentar a segurança das informações trafegadas entre os sistemas.

📌 CHAVE_CRYPTA

A CHAVE_CRYPTA é utilizada para criptografar e descriptografar dados sensíveis transmitidos entre o CIGAM e aplicações externas, garantindo a confidencialidade e integridade da comunicação.

Essa chave também deve ser configurada no <appSettings> do ambiente do Web Service.

  <appSettings>
    <add key="CHAVE_CRYPTA" value="MinhaChaveSegura123!" />
  </appSettings>

Todos os sistemas envolvidos na integração devem utilizar a mesma CHAVE_CRYPTA.
Caso as chaves estejam divergentes entre os ambientes, ocorrerão erros de descriptografia e falhas de comunicação.
A alteração da chave deve ser coordenada em todos os pontos de integração.
Mantenha a chave em sigilo e compartilhe somente com equipes autorizadas.

Requisição e resposta dos Webservices

Os webservices do CIGAM suportam as tecnologias SOAP e REST/JSON.
Na utilização do padrão REST/JSON, os parâmetros devem ser enviados por POST, e o nome do método deve ser informado diretamente na URL da requisição. As respostas dos serviços também podem ser obtidas em ambos os formatos.

Quando o retorno do serviço contiver mais de um registro, a exportação será realizada utilizando duas coleções (objetos): uma para as colunas e outra para os dados. Nesse formato, as colunas recebem cabeçalhos identificadores (por exemplo: c1, c2, c3...), que são utilizados como referência pelos registros retornados.

Existe ainda a opção EXPORT_HEADERS, que pode ser configurada no arquivo de configuração do ambiente do Web Service (seção <appSettings>). Essa opção define se a exportação deverá utilizar sempre os cabeçalhos de colunas, independentemente da quantidade de registros retornados.

Exemplo de configuração:

 <appSettings>
   <add key="EXPORT_HEADERS" value="N" />
 </appSettings>

Essa configuração também pode ser incluída no arquivo Settings.

Quando o nome da coluna no banco de dados for diferente do nome utilizado no CIGAM/CGData, a coleção de nomes de colunas incluirá uma tag adicional contendo essa identificação.

Campos que ainda não possuem nome definido (por exemplo: Campo31, Campo32) não serão exportados. A exceção são os campos de usuário, identificados por nomes iniciados com Usr.

No formato JSON, é necessário atribuir explicitamente ambas as propriedades, pois não é possível definir um valor diretamente na tag principal como ocorre no XML. Nesses casos, o apelido da coluna será informado na propriedade db_alias.

Em ambos os formatos, o primeiro nó da estrutura corresponde ao valor da tradução do Nome Lógico da tabela exportada.
As colunas são agrupadas na coleção col, enquanto os dados dos registros são agrupados na coleção reg.
Todos os dados são retornados utilizando codificação UTF-8.

Exemplo de resposta em XML e JSON

XML

JSON

 <esmateri>
   <col>
     <cd_material>c1</cd_material>
     <descricao>c2</descricao>
     <valor_imposto>c3</valor_imposto>
   </col>
   <reg>
     <c1>001</c1>
     <c2>Material Teste 1</c2>
     <c3>10</c3>
   </reg>
   <reg>
     <c1>002</c1>
     <c2>Material Teste 2</c2>
     <c3>20</c3>
   </reg>
 </esmateri>

 {
   "col": [
     {
       "cd_empresa": "c1",
       "descricao": "c2",
       "valor_imposto": {
         "db_column": "campo3",
         "db_alias": "c3"
       }
     }
   ],
   "esmateri": [
     {
       "c1": "001",
       "c2": "Material Teste 1",
       "c3": "10"
     },
     {
       "c1": "002",
       "c2": "Material Teste 2",
       "c3": "20"
     }
   ]
 }

Para validar estruturas no formato JSON, pode-se utilizar ferramentas de validação online, como o JSONLint em http://jsonlint.com.

Tipos especiais

Alguns dados terão formatos especiais na requisições e respostas.

Tipo do dado	Formato	Máscara	Exemplo	Onde
Data	XML	DateTime (conforme ambiente em que o Serviço está rodando)	01-jan-2013	Requisição
Data	XML	dd/mm/yyyy	01/01/2013	Resposta
Data	JSON	dd/mm/yyyy ou dd-mmm-yyyy	01/12/2013 ou 01-dec-2013	Requisição e Resposta
Booleano	XML	Bool (conforme tipagem)	True	Requisição
Booleano	XML	True ou False	True ou False	Resposta
Booleano	JSON	TRUE,True,true ou FALSE,False,false	True ou false	Requisição
Booleano	JSON	True ou False	True ou False	Resposta
Time	XML e JSON	161050	161050	Requisição e Resposta
Numéricos	XML e JSON	Sem separador de milhar e com ponto (“.”) como separador decimal	150 120.00 1250.33222	Requisição e Resposta

Quando utilizar o formato XML, os valores enviados para parâmetros de tipos especiais, no serviço SOAP o próprio serviço garante o dado de entrada correto. Quando exportado irá seguir conforme a tabela anterior.
Quando utilizar o formato JSON, para os campos do tipo data o dado terá que vir no formato conforme a tabela anterior e para campos do tipo booleano terá que vir um “true” (não importando a capitalização) para que seja verdadeiro, pois para qualquer outra coisa será considerado como falso.

Para campos de dados do tipo hora, terão o dia com 24 horas e sem dois pontos “:” (HHMMSS)

Configurações especiais do banco de dados

Para que os serviços acessem corretamente os dados do tipo Date e DateTime, é obrigatório que a sessão com o banco de dados permita a informação de filtros por datas no formato americano “dd-mmm-yyyy” Exemplo: 01-jan-2013, 20-feb-2013 e 12-oct-2013. Para bancos de dados SQLServer essa parametrização já vem por padrão.
Para bancos de dados Oracle esse parâmetro pode variar de acordo com o idioma do Sistema Operacional no momento da instalação. Neste caso, verifique se o parâmetro de sessão “nls_language” está definido como “AMERICAN”. Esse valor pode ser ajustado no Registro do Windows para que todas as sessões sejam inicializadas dessa forma. Observar também se o Web Server que hospeda os serviços está com o modo 32bits/x86 habilitado, pois neste caso também é necessário ajustar os “nls_language” do Client32 do Oracle.

Validação do Integrador pelo IIS

Primeiramente para essa validação, é preciso acessar a pastas de instalação do Integrador (Webservices) e ajustar as configurações dos arquivos Settings.config e web.config, lembrando de remover o @ que vem por default com a implementação:

Para o arquivo web.config deve ser ajustado os campos de ConnectionString "CIGAM" e "INTEGRACAO" que podem ser gerados pelo programa CGConnectionString que se encontra no CIGAM_INSTAL ou também ser utilizada a mesma string informada na API e Portais, lembrando que no ProviderName 02 é SQL Server e 03 Oracle. Importante criptografar a string de conexão.

Em seguida é necessário criar a pasta Bin dentro da estrutura de instalação do integrador com as DLL's (encontradas no CIGAM_INSTAL):

CIGAM.Ambiente;

CIGAM.Extensions;

CIGAM.Sgbd;

CIGAM.Utils;

CIGAM.Webservices;

Feito isso, retornando ao IIS, no parte inferior é necessário alterar a forma de exibição para Content View, após isso selecionar o arquivo TesteBancoDados.ashx e clicar em Browse para abrir o navegador com a validação do Integrador.

Log

A tabela de log é praticamente uma cópia da tabela de integração com a adição dos campos para a data e hora da ocorrência/execução. O processo de criação e registro dos Logs será feito da seguinte forma:

O Webservice recebe a requisição e verifica se todos os parâmetros são válidos. Caso não sejam, retorna um erro ao usuário e não registra qualquer tipo de inserção na tabela de integração ou de log.
Se os parâmetros passados para o webservice forem válidos, insere na tabela de integração, retorna uma mensagem e sucesso ao usuário sem registrar log.
Quando o programa da aplicação de integração executar e importar o registro da tabela de integração, o log é criado com os dados importados (inclusive o usuário logado no CIGAM que fez a importação). Após isso, o registro da tabela de integração será apagado.
No log é um campo para saber se o registro foi importado ou recusado. Caso recursado, armazena também o código e a mensagem de erro. Isso se faz necessário para que os registros com erro não fiquem na tabela de integração.

Após liberar os registros pendentes será registrado log. Se tentar liberar um registro inexistente será retornado um erro e não será registrado log. Não será testado se está sendo liberado um registro já liberado pois teria também que ser feito um controle para a liberação dos correlatos.

Em Genéricos/Pesquisas/Rotinas existe uma tela on-line para que o usuário/administrador/DBA possa visualizar a tabela de Log.
A tabela de log não é indexada para ganho de performance. Se a tabela do log for grande, poderão ser criados os índices de acordo com as necessidades.
Não é gerado log sobre as consultas de dados efetuadas.

O log poderá ser limpo ou mantido apenas “n” dias conforme a necessidade do administrador do banco de dados (a limpeza será manual por segurança).

Aplicação de Integração

A camada de serviços e ou de banco de dados garantem “apenas” que o dado chegue até à tabela de integração. A importação dos dados é feita por um programa específico da aplicação de integração chamado Integrador.

Ao indicar statusRegistro igual a pendente o registro enviado não será integrado ao ERP CIGAM até que tenha seu status igual a liberado. Sendo possível sua liberação através do método LiberarPendentes. Também é possível criar o registro com o status Liberado sem a necessidade de requisitar um novo método para liberação.

Utilizando o retorno dos Serviços

Xml

Os serviços que utilizam o protocolo SOAP, tem como retorno uma String no formato Xml, para melhor visualização destes dados, está disponível na classe “Xml”, do namespace Cigam.Utils, um método estático chamado “XmlStringToDataTable”. Este retorna um objeto do tipo System.Data.DataTable. Segue abaixo um exemplo de implementação.

Também pode ser utilizada a classe XmlDocument, do namespace System.Xml para fazer a manipulação dos dados. Segue abaixo um exemplo de implementação.

Json

Os serviços que utilizam o protocolo REST, tem como retorno uma String no formato JSon, para trabalhar com estes dados, está disponível a classe “JSonDocument” no namespace Cigam.Utils. Esta classe fornece a interpretação da string retornada além de propriedades e métodos para manipulação dos dados. Seguem abaixo exemplos de como instanciar e alimentar a classe.

   Exemplo 1:

   Exemplo 2:

   Exemplo 3:

Esta classe também fornece uma propriedade contendo uma lista genérica que guarda objetos do tipo Cigam.Utils.JSonObject, e esta lista fornece informações sobre os registros da consulta, como o nome da coluna e o valor. Através desta classe também é possível obter o nome original das colunas, caso a consulta possua um cabeçalho de apelidos, ou saber se a consulta retornou exception, success ou query. Veja os exemplos abaixo:
   Exemplo 1:

   Exemplo 2:

Anônimo

Pesquisa

IN CIGAM Integrador

Índice