Developing and interfacing with web services can be tough. What do you do when there are firewall rules blocking you from talking to a third party provider; the network team can't resolve it for a week, and you have 5 days to come up with at least some kind of prototype? What if the third party provider's web services go down, or aren't deployed yet?
I've seen many cases where examples like this will completely stop any development from proceeding - if you can't make calls to a web service, how can you develop or test code which relies on it?
Fear not, there are a number of solutions available for creating a temporary set of web services for development and testing purposes.
If you're using a SOAP based web service, and have a wsdl, you can mock the web service locally as a mock service. (There are options for REST services too)
Mock Services
If you have at least a wsdl for the web service you need to talk to, you're in luck! Mocking the service is incredibly simple, and is almost completely seamless to the code which needs to interact with the service, as it's often just a case of changing the endpoint you're talking to.
There are a couple of methods of mocking services, the simplest of which for SOAP is with soapUI, which I will be covering. Alternatives include Apiary (for REST services), Mockable (for SOAP and REST), and wiremock as an alternative to soapUI, amongst others.
To get started in soapUI, armed with your wsdl (URL or file), create a new soap project:
Then right click the project and choose 'Generate MockService...':
This presents a dialogue box where you can choose which methods to mock, the name of the service, and the port it will be exposed on locally:
In this example, since I am telling it to start immediately, running on 8088 and calling it '/mymock' this means if I hit http://localhost:8088/mymock?wsdl, then the wsdl will be retrieved:
By this point, we are running our own version of the web services specified by the wsdl, however they aren't going to provide us with anything other than the wsdl at this point, so we must define the responses we want the service to return.
To do this, choose the service you want to mock in soapUI and expand the crosshair, then double click a response. This will open up the response editor where we can create different responses:
With this single response set up, we can open up the original web service we loaded in soap, change the endpoint of our request to match our mock service, and run the request to retrieve a response from the mock service:
If you had some code which was calling the 'sayHello' web service, that code could be pointed to our mock service endpoint and it would work as if we were calling the real service. This is the quickest solution to mocking a wsdl based soap service; for example if you're using a third party provider during development and their test instance goes down.
That's all very awesome, but what if you need the responses to be a little more dynamic? No problem.
SoapUI offers a handful of solutions for making your mock services more dynamic.
Firstly, you can create a handful of different responses for a given web service method, and calling the mock service successively will cycle through the responses in the order they were created. This is the default behaviour and is identified by the SEQUENCE dispatch. The different dispatches can be viewed by double clicking on the mock operation (e.g. 'sayHello' in our example):
The next dispatch type is RANDOM, which, as the name suggests, just randomly picks one of the mock responses that have been created. QUERY_MATCH and XPATH both allow the use of XPath expressions, and finally SCRIPT allows Groovy scripts to be used to select the mock response which is returned. The string returned by the script determines the name of the mock response which gets used. These are all mechanisms for selecting the mock response to use, although the mock responses themselves can also use scripting to alter behaviour depending on input/circumstance.
To use scripting in a response, it is useful to establish a placeholder variable in the response:
A script can then be used to make decisions based on the input, and the placeholder(whose name can be anything you choose) can be set using context.placeholdername = "mynewvalue". For example, a script which checks the request for the name 'philip' and changes response accordingly(click the script button at the bottom of the response editor to write the script):
Using a Groovy XMLSlurper and the Groovy notation for traversing XML is the easiest way of extracting values from the request; in the above example the following two lines are used to extract the value of the name node:
def req = new XmlSlurper().parseText(mockRequest.requestContent)
def name = "${req.Body.sayHello.hellorequest.name}"
For the SCRIPT dispatch, the same concept applies; the only difference is that instead of setting a placeholder, the String return value of the script will determine the response used, so a multitude of scripts can be used to create a very dynamic mock service.
More information available here, here, here, and here.
Happy mocking!
And a gratuitous picture of me giving a talk to our offshore developers in Hyderabad:
To do this, choose the service you want to mock in soapUI and expand the crosshair, then double click a response. This will open up the response editor where we can create different responses:
With this single response set up, we can open up the original web service we loaded in soap, change the endpoint of our request to match our mock service, and run the request to retrieve a response from the mock service:
That's all very awesome, but what if you need the responses to be a little more dynamic? No problem.
SoapUI offers a handful of solutions for making your mock services more dynamic.
Firstly, you can create a handful of different responses for a given web service method, and calling the mock service successively will cycle through the responses in the order they were created. This is the default behaviour and is identified by the SEQUENCE dispatch. The different dispatches can be viewed by double clicking on the mock operation (e.g. 'sayHello' in our example):
The next dispatch type is RANDOM, which, as the name suggests, just randomly picks one of the mock responses that have been created. QUERY_MATCH and XPATH both allow the use of XPath expressions, and finally SCRIPT allows Groovy scripts to be used to select the mock response which is returned. The string returned by the script determines the name of the mock response which gets used. These are all mechanisms for selecting the mock response to use, although the mock responses themselves can also use scripting to alter behaviour depending on input/circumstance.
To use scripting in a response, it is useful to establish a placeholder variable in the response:
A script can then be used to make decisions based on the input, and the placeholder(whose name can be anything you choose) can be set using context.placeholdername = "mynewvalue". For example, a script which checks the request for the name 'philip' and changes response accordingly(click the script button at the bottom of the response editor to write the script):
Using a Groovy XMLSlurper and the Groovy notation for traversing XML is the easiest way of extracting values from the request; in the above example the following two lines are used to extract the value of the name node:
def req = new XmlSlurper().parseText(mockRequest.requestContent)
def name = "${req.Body.sayHello.hellorequest.name}"
For the SCRIPT dispatch, the same concept applies; the only difference is that instead of setting a placeholder, the String return value of the script will determine the response used, so a multitude of scripts can be used to create a very dynamic mock service.
More information available here, here, here, and here.
Happy mocking!
And a gratuitous picture of me giving a talk to our offshore developers in Hyderabad:
Comments
Post a Comment