Histórico da Página
Informações | ||||
---|---|---|---|---|
| ||||
|
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”.
Transações disponíveis
...
Para visualizar as transações disponíveis para o Aplicativo Interno, basta clicar no botão Transações Disponíveis:
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 | ||
---|---|---|
| ||
Na tag <class> deve ser informado a Classe do Adapter desenvolvido. |
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çãoO 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.
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 | ||
---|---|---|
| ||
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(): 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.
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.
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.
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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<?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> |
...
- 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.
...
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.
...