Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Objetivos e formas de uso

A O objetivo da Mensagem Padronizada TOTVS (TOTVS Standard Message - TSM) estabelece alguns é estabelecer padrões que devem ser seguidos por todos os aplicativos que participam da integração. Estes padrões estabelecem alguns definem os tipos de mensagens suportadas bem como informações obrigatórias que devem fazer parte do seu conteúdo.A composição do conteúdo de cada uma das mensagens de negócio será definida em conjunto com especialistas de negócio e não faz parte do escopo deste documento.

A anatomia básica de uma mensagem de negócio permite que dentro de uma mensagem específica seja definido se defina apenas o modelo do conteúdo de negócio e retorno. Entretanto, mas quando a mensagem completa for trafegar quando for necessário um maior controle das mensagens trafegadas entre os produtos, é possível acrescentar modelos adicionais (como o modelo de dado para retorno de status de processamento), de forma todas as informações citadas acima também necessárias façam parte da estrutura da mensagemde uma única estrutura de mensagem.

A composição do conteúdo da mensagem no que diz respeito ao negócio será definida em conjunto com especialistas de negócio e não faz parte do escopo deste documento.

As orientações descritas neste documento, portanto, visam atender os dois modelos de integração existentes: API e Transactions.

Veja abaixo um exemplo do JSON de uma mensagem padronizada completa mensagem padronizada completa, em formato JSON, (incluindo header para controle da camada de EAI), trafegada no modelo Transactions:

<tópico informações comuns não existe>

(informação) Clique aqui para obter mais informações sobre o modelo de integração Transactions


No caso de JSON simplificado conteúdo trafegado no modelo para API, trabalhamos apenas com o conteúdo da propriedade "Content" será utilizado, desconsiderando o header.

Veja abaixo o exemplo do mesmo JSON definido acima, porém como atendendo ao modelo de request/response de uma API.

...

Aviso

O campo "segment" deve ser preenchido de forma coerente com o que já está em uso nos outros schemas e APIs de nossa base (sem ao menos diferenciação de casepor exemplo, deve-se manter o "case" em uso, evitando variações como "HealthCare" em uma mensagem, e "Healthcare" em outra). Para isso, visite o API Reference e verifique como o segmento que você quer adicionar está escrito.

...