Instalação e configuração do EAI2

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

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

Bem vindo
1. Acionar o botão "Próximo".
Configurando Host Manager: Pacote de Aplicação com as funções do GetHostTypes, preencher os campos:
1. Hostname: Nome do Host Application que está sendo cadastrado;
2. Product name: Nome do produto (Já vem preenchido);
3. Productversion: Versão do produto (Já vem preenchido);
4. Usuário: Nome Usuário;
5. Senha: (usuário e senha cadastrados no produto;
6. Descrição: Descrição do Host Application;
7. 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;
8. Acionar o botão "Próximo".
InstantietHost este método retorna as Configurações do Host Application
Configurações do Agendamento do Pedido de Execução para o Saneamento da Base de Dados do EAI2
1. Ao selecionar o check será habilitado os campos:
  1. Dias de limpeza: O Usuário deve informar a quantidade de dias que o Saneamento deve considerar como histórico;
  2. Lista de todos os servidores RPW para que o usuário possa selecionar qual RPW usar para processar o Saneamento das MSG.

Com estas informações o Wizard irá criar um Pedido de Execução no RPW selecionado para a limpeza das informações processadas pelo EAI2.

Este processo é muito importante para o perfeito funcionamento do EAI2, pois ele garantirá que o EAI2 execute com uma performance boa. Uma vez que sempre irá executar a limpeza da base de dados conforme parametrização.

Só pode existir uma aplicação Interna para o EAI2, esta é a aplicação origem.

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

Linha Datasul > 3 Aplicativo Interno | Host Application > image-2023-12-11_17-53-14.png

Transações disponíveis

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

Linha Datasul > 3 Aplicativo Interno | Host Application > image-2023-12-11_18-10-53.png

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.

Modo Habilitado: Através desta 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.

Cada módulo possui seu XML identificando as transações existentes no EAI2.

adapters/fin-adapters.xml
adapters/log-adapters.xml
adapters/man-adapters.xml
adapters/hcm-adapters.xml
adapters/fis-adapters.xml

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

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.

Linha Datasul > 3 Aplicativo Interno | Host Application > image-2023-12-11_17-55-37.png

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.

Porém esta diferença de versão pode ou não causar problemas na integração. Então o Analista que irá liberar esta transação para Cliente deve ficar atento as versões que estão sendo integradas.

Detalhes das Transações da Rota selecionada:

Transação: Uma transação é a troca de mensagem realizada entre um Host Application e um ou mais External Application. Através da Mensagem Única Totvs é possível realizar transações;
Versão do host: Esta versão indica qual é a versão da transação no Host Aplication;
Versão da aplicação: Esta versão indica qual é a versão da transação no External Aplication.

Habilitar Contexto: É Obrigatório o cliente habilitar o(s) CONTEXTO(S) desejado para que as mensagens sejam processadas pelo EAI2.

Contexto: Ao abrir a árvore da “Transação” serão mostrados todos os contextos de envio das mensagens. Os CONTEXTOS são definidos pela área de negócio ao desenvolver o adapter da mensagem. Para cada CONTEXTO podemos definir o modo de Envio: Síncrona ou Assíncrona. Caso o Analista identifique que a mensagem não pode mudar o modo de envio “Síncrona ou Assíncrona” este deverá programar o adapter incluindo o tipo de envio.

Programa de Envio: É no programa “BO/API” de negócio que definimos o(s) contexto(s) específico(s) ou se deve ser enviada para FILA PADRÃO.

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.

Linha Datasul > 3 Aplicativo Interno | Host Application > image-2023-12-11_17-59-14.png

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, 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: opcional

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.

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.

Linha Datasul > 3 Aplicativo Interno | Host Application > image-2023-12-11_18-6-3.png

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

Na primeira é quando o cliente implantar o EAI2 ele terá que abrir o formulário e alimentar as informações do “de-para” para que suas integrações funcionem corretamente. Para isso deve: Ao abrir a árvore da “Transação” onde serão mostradas todas as TRANSAÇÕES e na parte superior são mostradas as informações da Aplicação externa e também algumas funções como:

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.

Já na segunda parte quando o cliente implantar o EAI2 ele terá que abrir este formulário e alimentar as informações do “de-para” para que suas integrações funcionem corretamente.

Se a empresa (na mensagem recebida) for em branco, é considerada uma mensagem ”genérica” ou “multiempresa”.
Se a empresa for diferente de branco e não existir um de-para, ela também é considerada uma mensagem “genérica” ou “multiempresa”.

Teste de conexão: Através deste botão é possível executar um Teste no ambiente. Este Teste consiste em enviar o “whois” para o endreço WSDL informado na aplicação externa e pegar o resultado desta conexão. O Teste de Conexão também pode ser feito usando o link do WSDL. Com o Teste é possível identificar:

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
LOGIX	PROTHEUS
Código da empresa	Código da empresa	Código da filial
01	01	02
02	01	03
03	01	04
04	02	01

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.