No exemplo acima, teríamos o produto integrado RM, com a aplicação origem sendo PR11_BRA. Os valores acima são fictícios.

          Vejamos agora a imagem do novo cadastro de adapters:

   Nova tela do cadastro de adapters do Protheus

          Como funciona o roteamento no Protheus?

          No grid de roteamento cadastramos as informações sobre o produto integrado no campo Produto (XB0_PROD), onde informamos o produto do roteamento. No campo Aplicação Ori. (XB0_SOUIRCE) indicaremos a aplicação origem do produto integrado.

          No campo Envia (XB0_SENDER) iremos informar se aquela rota é para envio e recebimento (1=Sim) ou somente para a geração da ResponseMessage (2=Não). E qual co o comportamento do EAI para ambos os casos?

          Quando é disparada uma integração no Protheus o EAI busca neste grid de roteamento informações de todas as rotas cadastradas com Envia=1-Sim. Ele então faz o disparo da integração para cada rota cadastrada. Rotas configuradas com o campo Envia=2-Não não são enviadas. Como não é possível, em múltiplos envios, realizar controles de transação entre todos os sistemas e também pelo alto tempo de  resposta quando existem vários sistemas integrados, para que seja possível cadastrar mais de uma rota de envio o adapter deve estar configurado, no campo Método (XX4_METODO), com a opção 2=Assíncrono_METODO), com a opção 2=Assíncrono. Caso não seja encontrada nenhuma rota de envio, o processo padrão é executado (envio utlizando os parâmetros).

          Mensagens com mais de uma rota são geradas na fila do EAI Protheus com um único diferencial, o seu UUID (Universally Unique Identifier). É gerada uma nova mensagem na fila por rota de envio, que são depois processadas normalmente pelo Schedule Protheus.

          Quando o Protheus recebe uma Mensagem Única TOTVS síncrona nada muda no processo. A ResponseMessage é devolvida para quem enviou a mensagem.

          Já no recebimento de uma Mensagem Única TOTVS assíncrona, o processo torna-se diferente. A BusinessMessage é recebida no Protheus, gravada na fila de mensagens do EAI (tabela XX3) e é gerada a ReceiptMessage, que é devolvida para quem enviou a mensagem. Após o processamento da mensagem na fila do EAI é gerada então uma ResponseMessage. Para enviar esta mensagem, o EAI Protheus busca no adapter relacionado se existe alguma rota cadastrada (independentemente do valor do campo Envia) com o produto e aplicação de origem recebidos na mensagem. Caso seja encontrada rota, a ResponseMessage é enviada para esta rota. Caso não seja encontrada são utilizados para o envio os valores contidos nos parâmetros MV_EAIURL2, MV_EAIMETH, MV_EAIWS, MV_EAIPASS e MV_EAIUSER.

          O campo Url (XB0_URL) contém o endereço de webservices do EAI para o qual será enviada a mensagem.

          O campo Client Ws (XB0_WS) contém o nome do client de webservices utilizado para esta integração. Ele já vem com o valor default wseaiservice, que é client interno do EAI de controle do Framework Protheus. Caso seja necessário a criação de outro client, este deve ser compilado no repositório de dados Protheus com um nome diferente do client padrão, e o nome da classe deve ser colocada neste campo.

          No campo Método (XB0_METH) deve ser incluído no o nome do método de webservices que será consumido no envio da mensagem. Este campo já vem com o valor padrão receiveMessage, que é o método padrão do EAI TOTVS.

          Os campos Usuário WS (XB0_USR) e Senha Ws (XB0_PSW) devem ser alterados quando existe autenticação de webservices pelo outro EAI. Caso não exista , esta necessidade estes campos podem continuar vazios. Lembrando que o O EAI TOTVS Mensagem Única trabalha com autenticação do tipo basic, conforme a RFC (Request for Comments) 2617.

          Basicamente, quando possuímos rotas cadastradas, os valores dos parâmetros a seguir são substituídos pelos seguintes campos:

•      MV_EAIURL2 - Campo Url (XB0_URL)
•      MV_EAIMETH - Campo Método (XB0_METH)
•      MV_EAIWS - Campo Client WS (XB0_WS)
•      MV_EAIPASS - Campo Usuário WS (XB0_USR)
•      MV_EAIUSER - Campo Senha Ws (XB0_PSW)

          Vamos mostrar como cadastrar as rotas para um adapter de Mensagem Única TOTVS. Vamos utilizar para este exemplo o adapter FINA010 (Cadastro de Naturezas).

Parte superior do cadastro de adapters, onde cadastramos a rotina FINA010

          No exemplo acima, cadastramos a mensagem como síncrona. Neste caso, poderemos somente cadastrar uma rota de envio (mas podemos cadastrar mais de uma rota de resposta)

          Vamos agora cadastrar as rotas no grid de roteamento:

´

Rotas cadastradas para o adapter

          Veja que cadastramos mais de uma rota para um adapter síncrono. Mas somente uma é rota de envio. As demais são apenas rotas de resposta.

          Pelo exemplo acima, quando realizarmos qualquer operação de inclusão, alteração ou exclusão de registros do cadastro de naturezas o EAI Protheus irá enviar a Mensagem Única TOTVS síncrona para o produto DATASUL, no endereço listado na primeira linha. Quando for necessário gerar uma ResponseMessage de uma Mensagem Única TOTVS assíncrona que tenha chegado no Protheus, ele irá buscar dentre as três linhas deste grid qual é o produto e aplicação de origem contidos na mensagem original recebida pelo Protheus. Caso seja encontrado, a mensagem será disparada para a rota cadastrada.

          Vamos agora cadastrar o adapter MATA070 (BANK) com mais de uma rota de envio.

Adapter com mais de uma rota de envio

    Detalhe do roteamento

          Vemos no exemplo acima que cadastramos mais de uma rota de envio. Neste caso ao iniciar uma integração no Protheus, o EAI irá buscar na tabela de rotas quais rotas existem disponíveis para envio. Será gerada uma mensagem única por rota de envio. Neste nosso exemplo, serão geradas duas mensagens na fila do EAI, uma endereçada para o produto RM e outra endereçada para o produto DATASUL. As mensagens são iguais, diferenciadas apenas pelo seu UUID. Depois de geradas na fila, as mensagens seguem o fluxo padrão descrito na seção envio de mensagens assíncronas.

          Quando for necessário gerar uma ResponseMessage de uma Mensagem Única TOTVS assíncrona que tenha chegado no Protheus, ele irá buscar dentre as três linhas deste grid qual é o produto e aplicação de origem contidos na mensagem original recebida pelo Protheus. Caso seja encontrado, a mensagem será disparada para a rota cadastrada.

          Caso não exista rota cadastrada no adpater, o seu comportamento padrão não será alterado.

          Na parte inferior deste cadastro existe um último grid de Tags para Busca. É possível incluir neste campo tags nas quais se deseja pesquisar o valor, e o valor destas tags é gravada concatenada com '|', posteriormente no campo XX3_REFER, no mesmo registro da mensagem.

Âncora
_Toc403759537 _Toc403759537

Cadastro de De/Para de Empresas

         No EAI Protheus existe a possibilidade de se cadastrar, para as Mensagens Únicas TOTVS, um relacionamento entre a Empresa e Filial de processamento que chegou na mensagem com uma existente no Protheus. Isto se deve ao fato de que, na Mensagem Única TOTVS os valores trafegados na mensagem são sempre do sistema que enviou a mensagem, cabendo ao sistema receptor a tradução das informações trafegadas. Desta forma é enviada na mensagem o valor do correspondente a Empresa e Filial do sistema que originou a mensagem o que, em muitas vezes, não coincide com o código destas entidades no Protheus.
Vamos observar os campos deste cadastro, no menu Ambiente/Schedule/Emp.Fil Msg. Unica (APCFG050):

Figura 5 - Tela do cadastro de De/para de Empresas e FiliaisDe

• Referência (XXD_REFER) – Marca de referência do de/para. Esta marca é o atributo name da tag Product no path /TOTVSMessage/MessageInformation/;
  
  
• Company (XXD_COMPA) – Valor da empresa recebida na mensagem. Este valor é o conteúdo da tag CompanyId no path /TOTVSMessage/MessageInformation/;
  
  
• Branch (XXD_BRANCH) Valor da filial recebida na mensagem. Este valor é o contéudo da tag BranchId no path /TOTVSMessage/MessageInformation/;
  
  
• Emp. Protheus (XXD_EMPPRO) – Código da empresa/Grupo correspondente no Protheus;
  
  
• Fil.Protheus (XXD_FILPRO) – Código da filial correspondente no Protheus. Deve ser incluído o valor completo da filial no Protheus.

          Estes valores podem ser encontrados no cabeçalho da mensagem. Veja a imagem do cabeçalho aqui.

          A transformação dos valores recebidos para os valores de contexto do Protheus é realizada automaticamente pelo EAI Protheus. Como isto é realizado pode ser verificado no tópico Montagem de ambientes no recebimento das mensagens pelo EAI Protheus.

Âncora
_Toc403759538 _Toc403759538

Cadastro de De/para de Mensagens Únicas

          De acordo com as definições da Mensagem Única TOTVS os valores transitados nas mensagens refletem sempre os códigos dos produtos que as enviam. Por este motivo existe um facilitador que pode ser utilizado pelas Mensagens Únicas TOTVS. Através do cadastro de De/Para de mensagens é possível realizar o relacionamento dos códigos recebidos e associar com os códigos internos do Protheus.
      Vamos verificar os campos deste cadastro, no menu Ambientes/Schedule/De.Para Msg.Unica (APCFG070):

Figura 6 - Tela do Cadastro de De/Para de Mensagem Única TOTVS

        Os campos do formulário deste cadastro são:

• Referência (XXF_REFER) – Marca do produto que enviou a mensagem para o Protheus;
  
  
• Tabela (XXF_TABLE) – Nome físico da tabela na qual o registro que será realizado o de/para será inserido. Exemplo para a tabela SA1, no grupo de empresas 18: SA1180;
  
  
• Alias(XXF_ALIAS) – Alias da tabela do registo registro ao qual o de-para se refere. Exemplo: SA1;
  
  
• Campo (XXF_FIELD) – Nome do Campo ao qual se refere o de-para.

       O grid deste cadastro possui dois campos:

• Valor Externo (XXF_EXTVAL) – Valor que é recebido na mensagem;
  
  
• Valor Interno (XXF_INTVAL) – Correspondente do valor no Protheus.

         Normalmente não há necessidade de manipulação deste cadastro pelo usuário. Os adapters da Mensagem Única TOTVS realizam a manutenção e consulta do mesmo.

        Importante: O preenchimento do formulário deste cadastro é definido para cada mensagem no Protheus, e a regra para os campos Tabela, Alias, Campo, Valor Externo e Valor Interno é definida pelo criador da mensagem. O Acesso acesso e manipulação das informações deste facilitador não são realizados pela camada do EAI Protheus e sim pela camada do adapter. A utilização ou não deste recurso pelo adapter é de responsabilidade da equipe que o criou.
         As rotinas utilizadas internamente pelos adapters para realizar a manipulação destes registros são demonstradas no tópico Funções funções utilizáveis no EAI Protheus.

Âncora
_Ref402799344 _Ref402799344

Âncora
_Toc403759539 _Toc403759539

Parâmetros importantes do EAI Protheus

        O EAI Protheus utiliza alguns parâmetros de sistema para definir o comportamento da integração. Estes parâmetros são listados abaixo:

• MV_EAIURL – Parâmetro que indica ao EAI Protheus para qual endereço de Webservices a mensagem será disparada. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =ESB;
  
  
• MV_EAIPORT – Parâmetro que indica ao EAI Protheus qual o método de Webservices será consumido no envio da mensagem. Este parâmetro é carregado com o valor default WSCHANNELReceiver. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =ESB;
  
  
• MV_EAIESBC – Parâmetro que indica qual a versão do Webservice do TOTVS ESB para o qual o EAI Protheus irá realizar o envio da mensagem. Este parâmetro deve ser informado no formato <versão>.<release>. Exemplo: 11.1. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =ESB;
  
  
• MV_EAIXSD – Parâmetro com o diretório no qual estarão os XSDs utilizados na validação das mensagens do EAI. Possui como valor default o diretório relativo '\xsd\totvsmessage'. Este diretório é criado automaticamente no Protheus. Este parâmetro é utilizado somente quando a mensagem é do tipo Mensagem Única TOTVS. Para as mensagens do tipo TOTVSIntegrator que possuem adapter configurado a validação do XSD gerado pelo modelo de dados contra a mensagem é realizado de forma automática;
  
  
• MV_EAIURL2 - Parâmetro que indica ao EAI Protheus para qual endereço de Webservices a mensagem será disparada. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =EAI;
  
  
• MV_EAIWS - Parâmetro que indica ao EAI Protheus qual o cliente de Webservices utilizado para envio a outro EAI. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =EAI e tem como conteúdo default o valor WSEAISERVICE. O Client de Webservices do EAI TOTVS não precisa ser recompilado, pois ele é de controle interno. Importante: Para integrações com o produto DATASUL o valor deste parâmetro deve ser alterado para WSEAIDATASUL;
  
  
• MV_EAIMETH – Parâmetro que indica o método de Webservice que será consumido no envio da mensagem. . Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =EAI e tem como conteúdo default o valor receiveMessage. Normalmente este parâmetro não deve ser alterado, pois o método utilizado nas integrações via Mensagem Única TOTVS é padronizado com este nome.
  
  
• MV_EAIUSER – Parâmetro para envio do usuário de acesso a camada de Webservices no sistema destino. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =EAI. Este parâmetro somente deve ser configurado quando o sistema que irá receber a mensagem oriunda do EAI Protheus possuir autenticação de usuários na camada de Webservices;
  
  
• MV_EAIPASS – Parâmetro para envio da senha do usuário de acesso a camada de Webservices no sistema destino. Este parâmetro é utilizado quando o adapter está cadastrado com o Canal Envio (XX4_CHANEL) =EAI. Este parâmetro somente deve ser configurado quando o sistema que irá receber a mensagem oriunda do EAI Protheus possuir autenticação de usuários na camada de Webservices;

Âncora
_Toc403759540 _Toc403759540

Classe FWEAI

         A classe FWEAI é a classe responsável por criar os objetos principais do EAI Protheus. Para verificar o funcionamento desta classe, acesse a sua documentação no TDN clicando aqui.

Âncora
_Ref402863016 _Ref402863016

Âncora
_Toc403759541 _Toc403759541

Montagem de ambientes no recebimento das mensagens pelo EAI Protheus

        O EAI Protheus permite o processamento das mensagens recebidas na empresa e filial indicadas no cabeçalho da mensagem.
Para mensagens do envelope TOTVSIntegrator o valor recebido nas tags DocCompany (empresa) e DocBranch (filial) são consultados e seus valores utilizados para determinar ao EAI Protheus qual será o par Empresa/Filial no qual o ambiente será criado. Caso o valor destas tags sejam inválidos no contexto do Protheus (empresa e filial inexistente ou inválidas) é retornado uma mensagem de SoapFault para o sistema que enviou a mensagem.

          Para mensagens da arquitetura de Mensagem Única TOTVS (TOTVSMessage) estes valores são recebidos nas tags CompanyId (Empresa) e BranchId (Filial). Estas tags estão no path /TOTVSMessage/MessageInformation do XML recebido. Para as Mensagens Única TOTVS existe um comportamento adicional para a montagem de ambientes. Primeiramente é verificado se o par empresa/filial recebido na mensagem existe no De-para de Empresas no Protheus (tabela XXD). Caso seja encontrado o relacionamento de de-para no Protheus o ambiente é montado com os valores encontrados. Caso não seja encontrado o relacionamento é realizada a tentativa de montagem de ambiente com os valores recebidos diretamente na mensagem. Em ambos os casos (encontrando o relacionamento e não encontrando-o) a empresa e filial são validadas, e em caso de não possibilidade de processamento é retornada um SoapFault para o sistema que enviou a mensagem.

Âncora
_Toc403759542 _Toc403759542

O Ponto de entrada EAICHGEMP

          O Ponto de entrada EAICHGEMP é um ponto de entrada utilizado, no recebimento das mensagens únicas pelo EAI Protheus para que seja possível dizer para qual empresa e filial o ambiente deverá ser aberto. O array PARAMIXB enviado neste ponto de entrada recebe possui cinco elementos:

• Paramixb[1] =Marca recebida na mensagem. Esta marca é o atributo name da tag Product no path /TOTVSMessage/MessageInformation/;
  
  
• Paramixb[2] =Nome da aplicação recebida na mensagem. Este valor é o conteúdo da tag SourceApplication no path /TOTVSMessage/MessageInformation/. O Protheus envia nesta tag o nome do ambiente no qual a mensagem foi gerada;
  
  
• Paramixb[3] =Nome da mensagem única. Este valor é o conteúdo da tag Transaction no path /TOTVSMessage/MessageInformation/;
  
  
• Paramixb[4] =Código da empresa recebido na mensagem. Este valor é o conteúdo da tag CompanyId no path /TOTVSMessage/MessageInformation/;
  
  
• Paramixb [5] =Código da filial recebido na mensagem. Este valor é o conteúdo da tag CompanyId no path /TOTVSMessage/MessageInformation/.

          O retorno esperado deste ponto de entrada é um array de duas posições, sendo a primeira posição o valor da empresa/grupo e a segunda posição o valor completo da filial. Exemplo de retorno esperado do ponto de entrada = {'18',' D MG 01'}. A empresa e filial retornados no array devem ser válidas no contexto do Protheus.
           Caso seja retornado um array vazio neste ponto de entrada, o EAI segue o caminho descrito no tópico Montagem de ambientes no recebimento das mensagens pelo EAI Protheus.