Veja as novidades nas interfaces de webServices SOAP no Magic xpi, a partir da sua versão 4.13. 
Prover interfaces para a publicação de webServices, REST ou SOAP, sempre foi um dos pilares da plataforma o Magic xpi desde a sua concepção.
Desde muitas versões, esta interface era provida pelo SystInet (WSO2).
Porém, iniciando da versão 4.13 (e subsequentes), esta interface agora é provida pelo Apache Tomcat 9.
Vamos ver o que mudou.
Desenhando uma interface de WebService SOAP
Do ponto de visto do arquiteto de integração, que desenha as soluções através do Magic xpi Studio, os procedimentos não mudaram.
Inicia-se com a definição de um “Recurso“:
cujo endereço agora é /webserviceprovider, e prossegue-se com a definição do “Serviço” e suas operações:
Com o botão “Management” temos acesso ao assistente que gera (cria) o módulo deste serviço, a ser publicado no Apache Tomcat 9:
Este processo de “deploy” pode ser feito em outros ambientes (QAS ou PROD por exemplo), através do utilitário “Environment Settings” da instalação do Magic xpi.
E por fim, este serviço está pronto para ser configurado em uma “Trigger” de um fluxo de integração:
Fácil, rápido e simples, exatamente como sempre foi.
Gerenciamento dos WebServices Providos
O “Console de Gerenciamento” também está disponível com o Apache Tomcat 9, agora no endereço: http://<servidor>:<porta>/webserviceprovider/service.
Mas com uma interface muito mais concisa e simples:
Ele nos dá acesso à lista der serviços atualmente publicados (disponíveis), e ao WSDL de cada um, que deve ser distribuído/disponibilizado aos potenciais consumidores destes serviços.
Backend de Atendimento às Chamadas
A estrutura de instalação, claro, mudou um pouco. É aqui onde encontraremos as maiores diferenças em relação as versões anteriores.
O Apache Tomcat 9 fica localizado numa pasta chamada “Runtime\apache-tomcat” e a aplicação (WAR) que provê de fato estas interfaces SOAP (webserviceprovider.war), na pasta “xpi_webserver” na $HOME da instalação do Magic xpi:
Nela, o arquivo “xpi_webserver\webservice-config\config.properties” contém as informações de onde as chamadas remotas estarão sendo atendidas, e como localizar o GigaSpaces do Magic xpi:
Internamente, a pasta “%MAGIC_XPI_HOME%\Runtime\apache-tomcat” é chamada de CATALINA_HOME, e a pasta “%MAGIC_XPI_HOME%\xpi_webserver”, CATALINA_BASE.
O nome serviço agora se chama: Magic xpi 4.?? Soap Service:
O fluxo interno de execução/comunicação permanece o mesmo:
o cliente envia uma requisição SOAP até o endereço do Apache Tomcat 9 (antes era ao SystInet/WSO2), que abre uma requisição de execução (Message) dentro do GigaSpaces e fica aguardando a sua conclusão/tratamento, devolvendo então a resposta recebida para o cliente que fez esta requisição.
Este é um processo síncrono.
Algumas configurações também assumem valores default, como por exemplo 90s de timeOut na comunicação (retorno) da mensagem enviada ao GigaSpaces.
Mas isso também é configurável. Como no programa de execução do Apache Tomcat 9 (%MAGIC_XPI_HOME%\xpi_webserver\bin\RunSoapServer.bat) temos a configuração:
set CATALINA_HOME=%MAGIC_XPI_HOME%\Runtime\apache-tomcat
é justamente nesta pasta (%CATALINA_HOME%) que o Tomcat procura por um arquivo chamado ‘mgreq.ini‘ para obter alguma customização adicional aos serviços.
Por exemplo: na imagem abaixo vemos o ajuste deste timeOut entre Tomcat e GigaSpaces para 3min (180s):
Testando tudo
E por fim, com o endereço do WSDL, podemos testar toda esta estrutura com um software de consumo, como o SoapUI por exemplo:
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui