Conflito de tamanhos e tipos de campos

Conflitos entre tamanhos e tipos de campos são presença constante nos projetos de integração. Vamos a seguir mostrar exemplos destes conflitos e analisar as alternativas de solução.

A regra geral é que:

• Valerá o tipo de dado mais amplo entre os produtos
• Existem informações que são consideradas oficiais, que não podem ser convertidas, portanto, não poderão existir de/para. Ex. Notas Fiscais
• Existem informações que são integradas com sites do governo e deverão respeitar o tamanho permitido pelas integrações fiscais. Além do tamanho, a maioria das integrações fiscais, não permitem o envio das informações com máscara.
• Para os campos que podem ser convertidos, deverão gerar um InternalId para efetuar os cadastros, ou seja, a geração do de/para ocorre no lado que tem a restrição.

É muito mais barato e rápido alterar os produtos para restringir o tamanho de um campo, pois geralmente acontecerá apenas em um campo de entrada e mediante configuração. Do que alterar o produto para aumentar o tamanho de um campo, que irá afetar o campo de entrada, as tabelas, todos os programas e funções que usam esta tabela e em todas as telas e relatórios que ele aparece. Aumentar tamanho de campos é inviável.

As mensagens são únicas e utilizadas em diferentes integrações, que serão implantadas em diferentes clientes, cada um com um cenário diferente. Existem casos em que o cliente já possuía os dois produtos a serem integrados com bases populadas, onde os códigos terão que ser alinhados (de/para manual). Também existem casos, onde em uma das pontas da integração a implantação é nova e a base está vazia. A integração desenvolvida deverá ter flexibilidade para trabalhar com todos estes cenários.

De/para devem ser automatizados ao máximo.

Campos de chave primária ou estrangeira

Chaves primárias que podem ter ou não significado próprio. Alguns tipos de campos chave acabam fazendo parte do entendimento do usuário, então deve haver um cuidado maior em preservar valores equivalentes entre os produtos. Outros tipos de campos chave possuem uma chave natural atrelada, exemplo: código do cliente possui CNPJ, código do veículo possui placa, código do item pode possuir EAN-13.

Solução na mensagem: Valerá o maior tamanho entre todos os produtos envolvidos

Solução no produto: Caso o valor recebido seja incompatível com o tamanho do produto recebedor gerará de/para.

Documentos oficiais

Campos chave onde o seu valor possui um significado importante. Estes valores não podem ser truncados ou convertidos senão perdem significado.

Exemplo: CPF, CNPJ, Placa de veículo, documentos oficiais (Notas Fiscais, Ordem de Produção)

Solução na mensagem: Quando são documentos oficiais valerá o tamanho oficial do documento, sem máscara.

Solução nos produtos: A mensagem de integração no produto A deverá enviar o seu valor integral para o produto B.

Campos descritivos

Campos que descrevem chaves, são alimentados por pessoas, então não existe uma forma computacional de reduzi-lo e manter o seu significado.

Exemplo: Descrição do item, nome do cliente, detalhamento do chamado

Solução na mensagem: Vale o maior tamanho entre os produtos. Isto possibilita que em integrações entre produtos com grande capacidade não ocorra a perda de informação pela restrição de um produto com menor capacidade e que muitas vezes nem faz parte da implantação.

Solução no produto:

1. Quem receber deverá truncar a informação para a sua capacidade, o que evitará o erro de TRUNCATE no banco.

2. Caso não seja aceitável a perda de informação ao TRUNCAR, o produto de maior capacidade deverá criar um limitador configurável para o campo de entrada da informação.
3. Deverá estar documentado na integração que caso não seja aceitável a perda de informação, o produto A deverá ser configurado para limitar o tamanho do campo de texto em questão

Capacidade de listas

Cada produto tem uma limitação própria para a capacidade de itens em estrutura pai & filho.

Exemplo: Itens do pedido, itens da nota fiscal

Solução na mensagem: O tamanho das listas deverá ficar livre.

Solução no produto: O produto A deverá permitir configurar a quantidade máxima de registros a serem adicionados na lista. O produto B deverá validar no seu adapter se a lista recebida é maior que a sua. capacidade, e retornar erro na mensagem caso este limite seja ultrapassado.

Conflito entre valores fixos e valores cadastráveis

Existem informações nas entidades integradas que podem ter valores fixos em um produto e valores cadastráveis em outro. Um exemplo disso é o “Tipo do Documento”, que está configurado da seguinte forma nos produtos:

• Logix é uma lista fixa
• Datasul é uma lista fixa
• Protheus é pré-cadastrado e permite mudar
• RM é cadastro livre

Como existem produtos com cadastro dinâmico, parte-se do princípio que os valores em questão serão dinâmicos. A regra de que “vale o tipo mais amplo” deve ser considerada também neste caso.

A seguir as regras que devem nortear a decisão sobre como esta informação irá se comportar na integração.

1. Quando ocorrer uma integração entre um produto fixo e outro dinâmico, deve-se dar preferência por fazer o cadastro dinâmico igual aos valores fixos. Neste caso é interessante impedir o cadastro de novos tipos dinâmicos além dos fixos existentes. 
   1. Caso o cadastro dinâmico já existir na base e for diferente dos valores fixos, deverá ser preenchido o de/para relacionando-se os valores.
2. Quando ocorrer uma integração entre dois produtos fixos, deve-se preencher o de/para do campo relacionando os valores. Este de/para deverá estar preenchido nos dois produtos.
3. Quando ocorrer uma integração entre dois produtos dinâmicos, deve-se (se possível) dar preferência por fazer o cadastro ainda não existente com valores iguais ao cadastro já existente. Se não for possível, deve-se preencher o de/para do campo relacionando os valores. Este de/para deverá estar preenchido nos dois produtos.

Conflito entre conteúdo de campos (informações concatenadas)

Existem informações nas entidades integradas que podem ser concatenadas em um produto e separadas em outro.

Exemplo: DDI+DDD+Telefone

• Produto A: campos separados para cada uma das informações.
• Produto B: campo único e livre para digitação do usuário. O usuário pode digitar:
  • 011 9999-9999 ou (011) 9999-9999 ou somente o telefone 9999-9999
• Produto C: campo único que permite digitação padronizada e com máscara. Exemplo:
  • (055) (011) 9999-9999

No recebimento deverá ser tratado a tag conforme regra do produto.

Na mensagem única deverá ser documentado a regra de preenchimento do campo, para facilitar o entendimento dos produtos, que estão enviando ou recebendo a informação.

"Telefone"{


	...


	...

     "x-totvs": [
     	{
     		"product": "Protheus",
            "field": "SA1.A1_TEL",
            "required": true,
            "type": "char",
            "length": "09",
            "note": "Permite somente o número do telefone",
            "available": true,
            "canUpdate": false
        },
        {
            "product": "RM",
            "field": "",
           	"required": true,
            "type": "char",
            "length": "20",
            "note": "Permite informar DDD + Telefone/Celular com máscara",
            "available": true,
            "canUpdate": false
         }
     ]
}