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. 

...

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.

...

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.

...

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

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

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.