Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Informações
titleÍndice

Índice
stylesquare

Instalação e configuração do EAI2

...

A Instalação do EAI2 vai junto da Mídia do TOTVS 11produto

O Cliente deve solicitar a instalação e configuração ao responsável pela criação do ambiente “Testes ou Produção”. 

Acesso/Segurança: Para ter acesso a esta área o usuário deve ser do tipo “SUPER” “EAI” desta forma terá acesso as configurações do Monitor EAI2.

Parametrizando a aplicação interna

...

A aplicação Interna “Host Application” é gerada na implantação do EAI2, através do WIZARD no programa Manutenção de Aplicativos (html.aplicativos-eai) .

Ao acessar pela primeira vez o EAI2 e não tendo um Host Application cadastrado aparecerá tela de wizard para realizar o cadastro do Host Application.

...

Podemos executar manutenções na Aplicação Interna, basta acionar o botão “Configuração”“Editar Aplicativo Interno”.

Image RemovedImage AddedImage Added

Transações disponíveis

...

Para visualizar as transações disponíveis para o Aplicativo Interno, basta clicar no botão Transações Disponíveis:

Image Added

No botão "Atualizar Transações" é feito o processo que atualiza as novas transações disponíveis para o EAI2, sempre que liberado uma nova transação será necessário atualizar está para que a mesma fique disponível para uso.

  • GradeModo Habilitado:  Através Através desta grade coluna conseguimos parametrizar todas as transações que vamos usar nas integrações. Podemos usar as seguintes configurações para as transações
    • Ambos: Significa que esta transação será Enviada e Recebida pelo EAI2;
    • Envio: Significa que esta transação somente é enviada pelo EAI2;
    • Recebimento: Significa que esta transação somente é Recebida pelo EAI2.
  • Geração do XML das Transações Disponíveis: O Analista é responsável em criar ou manutenir o XML para identificar as novas transações. Estes XML ficam no TFS dentro das estruturas dos módulos. 

...

Informações
titleEstrutura XML

Na tag <class> deve ser informado a Classe do Adapter desenvolvido.

Image Modified

Já no botão "Configuração", é possível alterar a parametrização do Host Application informando os seguintes dados:

  • Host name: Nome do Host Application que está sendo cadastrado;
  • Product name: Nome do produto (Já vem preenchido);
  • Product version: Versão do produto (Já vem preenchido);
  • Usuário: Nome Usuário;
  • Senha: (usuário e senha cadastrados no produto);
  • Descrição: Descrição do Host Application;
  • Validar XSD: Se for selecionado o checkbox não é feita validação da  mensagem. A validação serve para verificar se a mensagem está seguindo o formato de Mensagem Única TOTVS e é realizado com base no XSD.

...

Nota

Suporte a múltiplas versões por transação

O EAI2 suporta mais de uma versão por transação. Anteriormente, apenas a maior versão de uma transação era utilizada.

Esta funcionalidade é liberada ativada por padrão.


Rotas de envio

...

É o caminho definido entre Host application e um External applications (origem/destino).

Pode ser considerado como uma ponte onde faz a conexão entre as transações de um Host Applications com as transações de um External Applications.

Image RemovedImage Added

Através da ROTA é possível identificar as versões das transações. Quando existir divergência de versão esta será mostrada em vermelho e com ícone de alerta ao usuário.

...

Informações
titleExemplo

Mensagem de Pedidos de Venda, esta mensagem pode ser enviada para várias aplicações. Porém tenho uma integração que é com a UMOVE-ME “MOBILE” e neste caso somente os Pedidos de Venda de determinados Representantes devem ser enviado para o Mobile.

Então quando vou desenvolver o BO/API de negócio para envio desta mensagem devo criar a “LISTA exemplo: PedUmoveme”.  Desta forma a mensagem só será enviada para FILA “PedUmoveme”. Com isso não vou honerar minha integração, tendo que filtrar no recebimento as mensagens que desejo.

O Desenvolvedor do Adapter precisa programar a interface ISenderAdapterContext e criar o método "getContextNames" que retorna uma lista com os contextos do Adapter por exemplo:

METHOD PUBLIC CHARACTER getContextNames(): 
        RETURN "Geral,MOBILE":U. 
END METHOD.

O “usuário” poderá configurar o tipo de envio da mensagem Assincrona ou Sincrona, porém esta opção só estará disponível para o usuário final escolher se a área de negócio ao construir o Adapter habilitar para isso. Esta opção estará disponível no configurador do EAI2 na ABA “Contexto de Envio”.

Para manter a compatibilidade das mensagens atuais com as novas REGRAS todas as mensagens atuais “Já construídas e homologadas” vão entrar no contexto “Padrão”, onde o usuário não poderá alterar o tipo de envio destas mensagens. Permanecendo o tipo de envio definido. Caso as áreas de negócio da Linha Datasul identifique a necessidade de deixar o tipo de envio disponível para o usuário alterar - estas deverão alterar a construção do Adapter para prever este gerenciamento.

Cadastrando as aplicações externas

...

Esta área tem o objetivo de auxiliar o usuário nas configurações necessárias para o correto funcionamento do EAI2.

Através desta área podemos adicionar Aplicação Externa, que serão utilizadas pelo EAI2 para o envio das mensagens.

Image RemovedImage AddedImage Added

Através desta tela, é possível adicionar aplicações externas informando:

  • Tipo de conexão: este valor está descrito na tag <portType> do WSDL. Utilize a URL do campo acima para obter o WSDL e conferir o valor. Abaixo seguem os valores padrão.
    • Logix e Protheus: EAISERVICESOAP.
    • RM: IConWSEAIService
    • PIMS: PIMSConnectorCDATAWS.
  • Endereço WSDL: (aplicação externa) dependendo da aplicação externa;
  • Nome da Porta;
  • Usuário;
  • , há um formato específico, que geralmente segue um dos modelos abaixo:
    • Logix e Protheus: http://<servidor>:<portaTCP>/EAISERVICE.apw?wsdl
    • RM: http://<servidor>:<portaTCP>/EAIService/MEX?wsdl
    • PIMS: http://<servidor>:<portaTCP>/PIMSConnectorCDATAWS/EAIService?wsdl
  • Usuário: opcional
  • Senha: opcionalSenha.

Após confirmar o cadastro da aplicação externa é mostrado as transações disponíveis da aplicação externa que cadastramos.

Estas informações são geradas com base no WHOIS que a aplicação externa retorna.

Image Removed


Estrutura De-Para

...

Este cadastro tem objetivo de converter os valores e chaves correspondentes entre produtos durante a troca de mensagens.

Esta conversão acontece no recebimento das mensagens, é neste momento que é disparado o de-para de conversão. O processo atualiza as estruturas do “de-para” conforme o XML disponibilizado pela TOTVS.

Image RemovedImage AddedImage Added

O Processo de “De-Para” está dividido em duas partes que estão detalhadas abaixo:

...

XML De-Para: O Analista é responsável em criar ou manutenir o XML para identificar a estrutura do de-para que vai usar nas novas transações. Estes XML ficam no TFS dentro das estruturas dos módulos. Essa estrutura é usado no “RECEBIMENTO” da mensagem. Geração do XML: A definição da estrutura do De-Para “XML” é gerado pela equipe de desenvolvimento da Totvs e disponibilizado na mídia de instalação e será através deste XML que será criado a estrutura do “DE-PARA”.

Bloco de código
languagexml
themeEmacslanguagexml
linenumberstrue
<?xml version="1.0" ?> 
<internalId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<internalIdRow>
		<Code>CompanyInternalId</Code> 
		<FieldList>cod_empresa</FieldList> 
		<File>fnd_empres</File> 
	</internalIdRow>
</internalId>

 

Onde:

  • <internalId> - Será detalhado mais abaixo;
  • <Code> - Nesta tag deve ser informado o nome do campo "de-para". É um nome livre, sem caracteres especiais;
  • <FieldList> - Nesta tag deve ser informado o nome do campo da tabela. Pode ser um ou N campos separado por vírgula “,”;
  • <File> - Nesta tag informamos o nome da tabela.

...

  • Se o WSDL é válido;
  • Se o ambiente está ativo;
  • Se a aplicação Externa possui as Transações Ativas e na versão correta.

InternalId

...

É utilizado para converter campos de chaves primárias de aplicativos externos para a chave primária do aplicativo interno.

Durante a troca de mensagens, o aplicativo externo pode ter mais, menos ou diferentes campos correspondentes à chave primária. Assim, fica impossível identificar qual registro corresponde aos valores recebidos na mensagem. Isso pode ocorrer com vários aplicativos externos ao mesmo tempo e para a mesma mensagem. Para resolver essa situação, tornando-a invisível para o Helper e o Adapter durante a extração dos dados recebidos, foram criadas as funções do InternalId.

Foi adicionado um código interno (InternalId) no XML da mensagem para identificar os campos chaves do aplicativo externo. Chegando ao destino, os campos são convertidos para os valores locais no corpo da estrutura do Helper.

Exemplo:

Tabela de empresas
LOGIXPROTHEUS
Código da empresaCódigo da empresaCódigo da filial
010102
020103
030104
040201


Desta forma, a partir do exemplo, tem-se que a empresa “01” do Logix corresponde à empresa e filial "01” “02”. Se fosse enviado somente o código da empresa, quando o Protheus enviasse o código “01” conflitaria com três códigos no Logix, tornando falha a troca de mensagens.

A construção da InternalId será em uma classe que deve instanciar a classe IInternalId e implementar as funções seguindo os exemplos abaixo. A partir das funções definidas, a classe de InternalId deve ser utilizada no Adapter, pois os campos definidos para internalid estarão contemplados no Helper.