IN CIGAM Integrador

De CIGAM WIKI
Revisão de 18h44min de 12 de março de 2026 por Camila.Oliveira (discussão | contribs) (→‎Tabela de Integração e Log)

Voltar

Integrador > Integrador padrão

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

Voltar ao início

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.

Voltar ao início

Tabela de Integração e Log

Tabelas envolvidas:

  • Tabela de Integração: %GEINTEGRADOR%
  • Tabela de 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.

Quando o Webservice recebe uma requisição, ele valida inicialmente todos os parâmetros informados. Caso algum parâmetro seja inválido, o sistema retorna um erro ao usuário e nenhum registro é inserido nas tabelas de integração ou de log.

Se os parâmetros forem válidos, o registro é inserido na tabela de integração e o Webservice retorna uma mensagem de sucesso ao usuário. Nesse momento ainda não é gerado log.

Posteriormente, quando o programa da Aplicação de Integração executa e importa o registro da tabela de integração, é criado um registro correspondente na tabela de log, contendo:

  • os dados importados
  • o usuário logado no CIGAM responsável pela importação
  • a data e hora da execução

Após o processamento, o registro é removido da tabela de integração.

Na tabela de log existe um campo que indica se o registro foi importado ou recusado. Caso seja recusado, também são armazenados o código e a mensagem de erro, evitando que registros com erro permaneçam na tabela de integração.

Quando registros pendentes são liberados posteriormente, essa ação também gera registro na tabela de log. Caso seja tentada a liberação de um registro inexistente, o sistema retorna um erro e nenhum log é gerado.

Não é realizada validação para identificar se um registro já foi liberado anteriormente, pois isso exigiria controle adicional de registros correlatos.

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

Existe ainda uma tela on-line em Genéricos → Pesquisas → Rotinas que permite ao usuário, administrador ou DBA consultar os registros da tabela de log.

A tabela de log não possui índices por padrão, visando melhor desempenho. Caso o volume de dados se torne elevado, índices podem ser criados conforme necessidade do ambiente.

Também não são gerados logs para consultas de dados realizadas no sistema.

A limpeza da tabela de log pode ser realizada conforme a necessidade do administrador do banco de dados, mantendo apenas registros de um determinado número de dias. Essa limpeza é manual, por segurança.

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.

Voltar ao início

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 utilizam formatos específicos nas requisições e respostas dos serviços. Esses formatos variam conforme o tipo de dado e a tecnologia utilizada (XML ou JSON).

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

Observações

Quando o formato XML é utilizado, os valores enviados para parâmetros de tipos especiais são validados pelo próprio serviço SOAP, que garante a tipagem correta do dado de entrada. Na exportação, os valores seguem o formato descrito na tabela anterior.

Quando o formato JSON é utilizado, alguns cuidados adicionais são necessários:

  • Campos do tipo data devem ser enviados exatamente nos formatos indicados na tabela.
  • Campos booleanos devem receber o valor true (independentemente da capitalização) para representar verdadeiro. Qualquer outro valor será interpretado como false.

Para campos do tipo hora, o formato utilizado considera 24 horas, sem o uso de dois pontos (:), seguindo o padrão HHMMSS.
Exemplo: 161050 (16 horas, 10 minutos e 50 segundos).

Configurações especiais do banco de dados

Para que os serviços acessem corretamente os dados dos tipos Date e DateTime, é necessário que a sessão com o banco de dados permita o uso de filtros de data no formato americano dd-mmm-yyyy.

Exemplos de datas nesse formato incluem 01-jan-2013, 20-feb-2013 e 12-oct-2013.

Nos bancos de dados Microsoft SQL Server, essa configuração já é aplicada por padrão, não sendo necessário realizar ajustes adicionais.

Já em ambientes com Oracle Database, esse parâmetro pode variar de acordo com o idioma do sistema operacional utilizado no momento da instalação. Nesses casos, é importante verificar se o parâmetro de sessão nls_language está configurado como AMERICAN.

Quando necessário, esse valor pode ser ajustado no Registro do Windows, garantindo que todas as sessões do banco sejam inicializadas com essa configuração.

Também é importante verificar se o Web Server que hospeda os serviços está executando em modo 32 bits (x86). Se esse modo estiver habilitado, será necessário configurar igualmente o parâmetro nls_language no Oracle Client 32 bits, assegurando que as sessões utilizem o mesmo padrão de idioma e formatação de datas.

Validação do Integrador pelo IIS

Primeiramente, para realizar a validação, é necessário acessar a pasta de instalação do Integrador (Webservices) e ajustar as configurações dos arquivos Settings.config e web.config.

É importante remover o caractere @, que vem configurado por padrão na implementação.

Arquivos a ajustar:

  • Settings.config
  • web.config


Integrador1.png


Integrador2.png


Configuração do arquivo web.config

No arquivo web.config, devem ser ajustados os campos da ConnectionString:

  • CIGAM
  • INTEGRACAO

Essas strings de conexão podem ser geradas através do programa CGConnectionString, localizado na pasta CIGAM_INSTAL, ou pode ser utilizada a mesma ConnectionString já configurada na API e nos Portais.

Outro ponto importante é o campo ProviderName, que identifica o tipo de banco de dados:

ProviderName Banco de Dados
02 SQL Server
03 Oracle

Após a configuração, é recomendado criptografar a string de conexão.

Integrador5.png


Criação da pasta Bin

Em seguida, é necessário criar a pasta Bin dentro da estrutura de instalação do Integrador.

Dentro dessa pasta devem ser adicionadas as seguintes DLLs, encontradas em CIGAM_INSTAL:

  • Cigam.Ambiente
  • Cigam.Extensions
  • Cigam.Sgbd
  • Cigam.Utils
  • Cigam.WebServices


Integrador7.png


Teste do Integrador no IIS

Após concluir as etapas anteriores, acesse o IIS (Internet Information Services).

No painel inferior, altere o modo de visualização para Content View.

Em seguida:

  1. Localize o arquivo TesteBancoDados.ashx.
  2. Selecione o arquivo.
  3. Clique em Browse.

O navegador será aberto exibindo a validação do Integrador, confirmando que a conexão com o banco de dados está funcionando corretamente.

Integrador6.png


Integrador8.png


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.

Exemplo 1

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.

Exemplo 2

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 1

   Exemplo 2:
Exemplo 2

   Exemplo 3:
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 1
   Exemplo 2:

Exemplo 2

Disponível em "https://www.cigam.com.br/wiki/index.php?title=IN_CIGAM_Integrador&oldid=156287"