Regras Gerais

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

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.

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.

Conflito de tamanhos e tipos de campos

...

• 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, nao não poderão existir De-Parade/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.

...

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 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

...

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.

...

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.

...

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.

Exemplo:

 Image Removed