Archive for the 'SOAPUI' Category

HTTP Binding In BPEL- Testing from SOAP UI

Recently, we came across a requirement of exposing the BPEL service to be accessible over HTTP without exposing it as SOAP service. We have used the HTTP binding for this purpose. This blog provides the useful information on coming up with actual HTTP url to be used for testing as we faced issues with testing the process from EM console.

Basically the url should be some thing like below for GET invocation:

<<url given in EM>>/?<your query string>&operationName=<get operation name>

Just wanted to add simple update on this topic, the URL is working even by giving different name for operation other than default operation name ‘Request-Response’. The same has been tested from SOAP UI (GET method invocation).


Deployment of SOAP UI Mock Service to Weblogic

In this post, i show how a SOAP UI mock service can be deployed as a war to weblogic server. It’s very self explanatory and based on the examples given in SOAP UI documentation.
















Testing OSB based REST Services using SOAP UI

This post assumes the basic working knowledge of SOAP UI testing tool, Oracle Service Bus11g and developing the REST based services.

Primer on REST

REST stands for ‘Representational State Transfer’ and it was first introduced by ‘Roy Fielding’ in his 2000 doctoral dissertation. REST is another architectural style of creating the web services that is different from SOAP based web services. REST based architectures communicate primarily through the transfer of representation of resources (information) and it uses simple XML over HTTP.

RESTful services adhere to certain set of constraints and architectural principles that include the following:

    · REST based architectures are built from resources that are uniquely identified by URIs and the only allowed operations are the HTTP operations: GET, POST, PUT and DELETE.

   · REST components manipulate resources by exchanging the representations of the resources. For example, a trading account can be represented by a XML document. In RESTful architecture a trading account might be updated by posting a XML document containing the modified trading account information to its URI.

Creating New REST Project

Open the SOAP UI and click on File -> New SOAP UI Project. Enter the project name and select the option ‘Add REST Service’ and click on OK.


In the next dialog window, Enter the Service Endpoint as :port">http://<hostname>:port where OSB runs and do not include the proxy service endpoint in this and check the option ‘Create Resource’.


In the next dialog window, Enter any value for the resource name to identify the resource and give the actual Proxy Service endpoint for Resource Path and click OK.


In the next dialog window, Enter any value for method name and select the HTTP method as your Proxy Service supports. Since my OSB proxy service supports only POST I am selecting the method as POST as shown below and click on OK.


Now verify that new REST project has been created and Request1 window is opened. To test your REST based proxy, modify the Media Type to ‘text/xml’, copy the request into request window and run by clicking on green arrow icon on the top.

Adding New Request to Existing Project

Right click and select the New Request as shown below:


Enter the Request Name as you need and click Ok to open the request editor. Once the request editor opens, copy the request into the request window and run as explained earlier.


Adding New Resource to Existing Project

Right click and select New Resource as shown in the below screenshot.


Enter the Resource Name and End point as explained in previous section to add another resource (proxy in our case) and click on OK.


Verify that another resource is added to the project that we have created and enter the Method Name and select POST method as explained earlier and click on OK. And run the request after pasting it in request window.

Using ‘Think Time’ in SOA Test

Very often, we may want to introduce the fixed delay in the stubs before responding to the request that SOA stub server receives.

SOA Test has a property called ‘Think Time’ which can be used to simulate this behavior. This post talks about on how to set this value for a stub and assumes the basic working knowledge of SOA Test 6.2

Double click on the stub for which you want to introduce the delay and click on Service Options tab. Select Time Options for left menu as shown below and enter the value for Think Time in msec. For example, the following screenshot introduces 3 min delay in the stub.


Using SOA Test to Simulate Fault Scenarios

The focus on the Web services continue to grow with the emergence of Service Oriented Architecture (SOA) because of its reuse, loose coupled nature and agility it adds to business processes.

Similar to typical software application life cycle, web service testing also assumes the equal significance. Rapid creation and deployment of complex web services offer challenges to the developers and QA teams as well during testing.

Web service testing typically has the following tasks:

   · Creating Test Clients based on the WSDL

   · Invoking the Web service using the test clients by sending the requests.

   · Verifying that the actual response is similar to that of expected response.

In some of the cases where the end system is unavailable we need to create the stubs to simulate service provider behavior.

Parasoft SOA Test is a testing tool used in the Webservice Testing that can be used to perform all of the above activities.

This post assumes the basic working knowledge of SOA Test 6.2 in creating the stubs and will discuss the case of simulating the fault from the service provider.

Settings to do for Fault Case in SOA Test stubs:

– Double click on the stub in Test Case Explorer that brings up the screen similar to the below one. Copy the SOAP fault that you want to receive from the service provider in the Response tab as shown below.


– Go to the Service Options tab and click on ‘Return Status’ in the options available at the left side of the screen as shown below. Enter the ‘Return Status’ and ‘Return Message’  fields as shown in below screen.


As per WS Basic Profile, HTTP  status code 500 has to be sent to the consumer of the service when service provider sends the fault response. That’s why we are setting the value as 500 here.


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 379 other subscribers

Enter your email address to follow this blog and receive notifications of new posts by email.

%d bloggers like this: