Páginas filhas
  • Padrão TOTVS EAI (Parceiros)
Ir para o final dos metadados
Ir para o início dos metadados

 

Caso o parceiro não consiga utilizar o produto EAI de alguma linha de produto TOTVS será necessário fazer uma implementação mínima do padrão EAI.

Esta implementação deverá seguir as regras abaixo: 

  • O padrão de envio será por web services, utilizando SOAP como método de transporte das mensagens;

  • O namespace será padronizado como http://www.totvs.com

  • O servicename será padronizado como "EAIService";

  • O portname utilizará como prefixo o nome do servicename, tendo como sufixo a tecnologia utilizada (padrão encontrado nos geradores de código atuais):  "EAIServiceSOAP";

  • A assinatura do método deverá ser: "string RECEIVEMESSAGE(string inMsg)". O Protheus envia receiveMessage;

  • Para a utilização do cliente padrão, será adicionado um custo inicial no ato de envio da primeira mensagem para "descoberta" dos padrões acima citados, de modo case-insensitive, e fixados em caso de sucesso, tendo como input do usuário apenas o endereço do web service e conseqüente autenticação HTTP (usuário e senha). Exceção: não se aplica ao Protheus;
  • O conteúdo das mensagens a serem transmitidas deverá ser UTF-8;

Padronização do nome do produto

É importante que os parceiros que implementem a sua versão do EAI ou que utilizem a versão de alguma linguagem existente, adotem um nome padronizado (como seu nome de produto) e aprovado pelo comitê técnico de integração TOTVS.

Este nome deverá seguir algumas regras:

  1. Nome Fantasia principal do parceiro
  2. Ter no máximo 15 caracteres
  3. Escrito sempre em maiúsculo
  4. Não conter caracteres especiais ou espaços

Abaixo alguns exemplos de nomes de parceiros:

SOFTSITE     <Product name="SOFTSITE" version="xx.xx"/>
TRADEEASY    <Product name="TRADEEASY" version="xx.xx"/>
ACQUAMANAGER <Product name="ACQUA" version="xx.xx"/>

 

Mensagem de Resposta

 

O EAI exige a implementação de mensagens que  atestem o recebimento e processamento de uma mensagem denominada "BusinessMessage". Este "atestado" é a garantia de que mensagem não se perdeu no meio do caminho e a relação da chave primária do registro que originou a mensagem com o registro no sistema de destino. Desta forma, é imperioso que se verifique se implemente mensagens de respostas de acordo com a documentação abaixo:

Mensagens Síncronas

Mensagens Assíncronas
Para garantir a unicidade e relação entre os registros da origem e Destino, deve-se implementar o conceito de InternalID.

 

  • Sem rótulos