Histórico da Página
| Informações | ||||
|---|---|---|---|---|
| ||||
|
A este servidor falso foi dado o nome de EAI Fake, que nada mais é que um webservice, um JOB e alguns templates disponíveis no próprio servidor do EAI real do Logix e que irá se comportar como se fosse um produto oposto.
...
- WebService EAIServiceFake – simula o produto oposto, disponível no mesmo local onde já se encontra o EAIService, que é o webservice do real do EAI Logix.
- JOB EAIStarterFake – permite que o servidor falso envie mensagem para outro EAI.
- Diretório \fakexml – contém os arquivos modelo ou de entrada que serão respondidos pelo EAIServiceFake ou arquivos que serão enviados por ele.
Instalação
...
As classes necessárias ao funcionamento do EAI Fake já fazem parte da instalação padrão do EAI.
Porém os arquivos de templates devem ser obtidos do TFS e copiados para a pasta (criar) \fakexml dentro do diretório de instalação do totvs. O local dentro do diretório totvs corresponde ao RootPath, ou seja, pode ser c:\totvs ou c:\totvs\logix, dependendo de com foi feita a instalação.
Download da pasta com o conteúdo do EAI Fake: fakexml.zip
Configuração
...
O primeiro passo para que o EAI Fake possa ser utilizado por outro produto é definir por quais mensagens ele irá responder. Isto é feito editando o arquivo \fakexml\resposta_WhoIs.xml. Este arquivo é o modelo de resposta da transação WhoIs, que é a primeira mensagem trocada entre dois produtos que querem se comunicar.
Exemplo
...
| Bloco de código | ||||
|---|---|---|---|---|
| ||||
<TOTVSMessage>
<MessageInformation version="1.000">
<UUID>[[newuuid]]</UUID>
<Type>Response</Type>
<Transaction>WhoIs</Transaction>
<StandardVersion>1.0</StandardVersion>
<SourceApplication>fake</SourceApplication>
<Product name="Logix" version="11.0"/>
<GeneratedOn>2001-12-31T12:00:00</GeneratedOn>
<DeliveryType>sync</DeliveryType>
</MessageInformation>
<ResponseMessage>
<ReceivedMessage>
<SentBy>[[sourceapp]]</SentBy>
<UUID>[[sourceuuid]]</UUID>
</ReceivedMessage>
<ProcessingInformation>
<ProcessedOn>[[processedon]]</ProcessedOn>
<Status>ok</Status>
</ProcessingInformation>
<ReturnContent>
<EnabledTransactions>
<Transaction>
<Name>WhoIs</Name>
<Mode>both_enabled</Mode>
<Version>1.000</Version>
</Transaction>
<Transaction>
<Name>UnitOfMeasure</Name>
<Mode>both_enabled</Mode>
<Version>1.000</Version>
</Transaction>
<Transaction>
<Name>CustomerVendor</Name>
<Mode>receive_enabled</Mode>
<Version>1.000</Version>
</Transaction>
</EnabledTransactions>
</ReturnContent>
</ResponseMessage>
</TOTVSMessage> |
Dentro deste arquivo você deve editar o elemento <EnabledTransactions> para conter as transações que você irá testar, para cada transação especifique o modo de envio/recebimento com um dos valores BOTH_ENABLED, SEND_ENABLED e RECEIVE_ENABLED.
O EAI (eai10000 do Logix) deverá registrar o EAI Fake como um External Application, apontando para o Webservice EAIServiceFake, conforme as figuras abaixo:
Para instruções sobre como cadastrar um External Application, consulte o tópico Cadastramento de Aplicativos Externos.
Teste simulado de integração usando o EAI Fake
...
O desenvolvimento de uma integração sempre pressupõe que existem dois produtos se comunicando, um produto A e um produto B.
Isto também implica que um teste real da integração só poderá ser feito quando os dois produtos estiverem com a integração praticamente pronta. Como neste cenário o primeiro teste só será feito depois de muito código desenvolvido, vários erros poderão ser descobertos de uma vez só.
O problema é que a partir do momento que as equipes dos dois produtos estão focadas no teste, e sempre que um erro é descoberto, o produto B paralisa o teste para fazer a correção e o produto A tem que aguardar a correção. Facilmente outro erro pode ser descoberto depois no produto A e a situação se inverte.
Este cenário muito comum no início dos testes de integração é o grande prolongador do tempo gasto nesta etapa.
Por isso é muito importante que as equipes isoladamente consigam testar a integração de forma unitária, sem precisar esperar que o seu próprio desenvolvimento e o do produto oposto estejam completos.
Para apoiar nos testes unitários de integração foi criado um servidor “falso” do EAI Logix, quem tem como objetivo simular o funcionamento de um produto oposto. Ao mesmo tempo em que dá total liberdade para o desenvolvedor controlar a forma como a mensagem será recebida ou respondida pelo “produto oposto”, neste caso, o servidor falso do Logix. Ou seja, o desenvolvedor do produto A, controla a forma como o produto B irá responder, simuladamente.
Simulação de envio
...
Para fazer com que o EAI Fake envie mensagem, é necessário configurar o JOB EAIStarterFake no arquivo totvsappserver.ini, com as configurações abaixo:
Exemplo
...
| Bloco de código | ||||
|---|---|---|---|---|
| ||||
[ONSTART]Jobs=4GLJOBEAI2
[4GLJOBEAI2]
Environment=<ambiente>
Main=EAIStarterFake |
O EAIStarterFake irá monitorar o arquivo \fakexml\enviar.xml enviar o seu conteúdo para a url especificada no arquivo \fakexml\url.txt a cada 5 segundos. Após cada envio, o arquivo enviar.xml tem seu conteúdo apagado.
A URL a ser informada no arquivo url.txt não deve conter o sufixo ?wsdl, exemplo: http://localhost:9090/EAISERVICE.apw.
A resposta do envio desta mensagem será gravada no arquivo \fakexml\retorno.xml, que pode conter a própria mensagem de resposta, ou a descrição de algum erro, se ocorrer.
Simulação de recebimento
...
- Toda mensagem que for enviada para o EAI Fake será grava no arquivo \fakexml\entrada.xml.
- Se a mensagem for assíncrona, o EAI Fake irá responder imediatamente com o arquivo \fakexml\recibo.xml.
- Se a mensagem for síncrona, o EAI Fake irá procurar por um arquivo com o nome resposta_<mensagem>.xml (exemplo resposta_Item.xml) e responder, senão dará um retorno vazio.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas