The thing with Asynchronous Request Response services is, as I used to describe it, that they're in essence two complementary Request-Only (Fire and Forget) services. That is, the client submits a request to the Asynchronous Request Response service, and at a certain point waits for the response by listening to an endpoint.
To make this work, the responding Asynchronous Request Response service should be told, which endpoint it should call with the response and which correlation id should be used. The WS-Addressing standard is used for that. All nicely explained in the before mentioned article.
In most customer-cases the problem is that your Client SoapUI or ReadyAPI project should catch the response, but the service is running on a SOA Suite in the datacenter and is not allowed to get to your local machine.
MobaXterm makes it very easy to create a tunnel. You can have a remote tunnel, that enables a local listening endpoint, that forwards every request to a remote service. Very handy if you have a Vagrant project with only a NAT NetworkAdapter, where Vagrant enabled a ssh endpoint on port 2222. You can easily create a Local tunnel on port 7101, for instance, to the remote ssh session on port 2222, that enables you to get to the weblogic console on the remote VM running on http://darlin-vce:7101/console.
To create a tunnel, just open the MobaSSHTunnel - Grahpical port forwarding tool:
This will open:
You can create a new SSH tunnel or edit a current one using the cogs icon under settings. For instance, to be able to do the Local port forwarding to get to your Weblogic console on your Vagrant box, create a tunnel as follows:
On the left you can enter a local port. That is the port you can use on your localhost. On the top right you can enter an host and port for the address to post your request to (does not need to be localhost). Then bottom right you need to provide an ssh session. A bit inconvenient is that you can't select a session from the sessions pane. Provide a host, port and user to connect to your ssh server.
What happens is that MobaXterm creates an SSH session, and a local endpoint. Every thing posted to the local endpoint is posted on the remote server to the give address. In this case I can go on my browser and enter https;//localhost:7101/console and it will bring me to the Weblogic Console on my Vagrant box. Neat, isn't it?
To get the remote Async Service respond to your local machine, you can also create a we need a tunnel that works the otherway around: we need Remote Port Forwarding:
Configuring is similar to Local port forwarding, however, now on the remote server a listen endpoint is created, and everything that is posted to the localhost:7777 adress (in this example) is forwarded to the address entered on the local server. In this case it is forwarded to localhost:7777, but it could be something else.
In our ReadyAPI project I created a Groovy script as follows:
def testCase = testRunner.testCase def env = testCase.testSuite.project.activeEnvironment.name if (env != "o02-12c" && env != "o02" ) { log.info "Environment: "+env+", so set callbackIp to "+InetAddress.localHost.hostAddress testRunner.testCase.setPropertyValue( "callbackIp", InetAddress.localHost.hostAddress) } else { log.info "Environment: "+env+", so set callbackIp to localhost" testRunner.testCase.setPropertyValue( "callbackIp", "localhost") }
In ReadyAPI you can define environments, with the project property activeEnvironment.name it can be queried.
If the environment points to one of our development environments, I set the callbackIp testcase property to "localhost". But for the default environment, I use InetAddress.localHost.hostAddress to get the local ip address. This will be the ip address of our CD/CI tool, that runs ReadyAPI from a script.
You can set the WS-Addressing ReplyTo address as follows, for instance:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:add="http://schemas.xmlsoap.org/ws/2003/03/addressing"> <soapenv:Header> <add:ReplyTo> <add:Address>http://${#TestCase#callbackIp}:7777/MyMockResponseURI</add:Address> </add:ReplyTo> </soapenv:Header> <soapenv:Body>
Then this address is used to do the callback. Make sure the tunnel is started:
You can also have the tunnel auto started (with the blue man-running-icon) or auto-reconnected (with the purple lightning icon).
This may also be very relevant in testing services on Oracle SOA Cloud Service, or Integration Cloud.
Happy tunneling!
No comments:
Post a Comment