Category Archives: SOAPUI

The category is mainly a disscusion forum about using SOAPUI as SOA testing tool

Prepare test case in SoapUI using SQL script and custom properties

When prepare test case in SOAPUI, you might need to select a bunch of data from database to create your test cases. This can be done by using JDBC request as test steps in SoapUI.

The next step is to save script result (data set) in properties that can be retrieved by other test steps for example SOAP request. But how to extract values from result xml and save as string list? Assume we need to read MEMBER field from above sample.

Here is the answer. We can add a new property transfer step in SoapUI. Use XQuery script to read MEMBER field from xml.

XQuery script:

for $id in //Results[1]/ResultSet[1]/Row/MEMBER
return string($id)

The output result: “12345678 23456789” will be saved into properties where you defined as target.

Almost there! As SQL script returns a list of member then we will read each individual member from list and populate them into SOAP request.image003

Groovy script: ${=testSuite.getPropertyValue(“abc”).tokenize(‘ ‘)[0]} utilize tokenize function that returns the first member in the list.


Asynchronous web service using WS-Addressing in webMethods

WS-Addressing in short

· a W3C standard for embedding addressing information in the SOAP message = less dependence on the transport protocol.
· Message identification via MessageID.
· Request-response matching via RelatesTo (very important for asynchronous scenarios; the synchronous case does not require this because it is tied to a single HTTP connection).
· Support for more complex message flows via ReplyTo and FaultTo.

To process responses asynchronously using WS-Addressing

· Ensure that the WS-Addressing policy you want to use is attached to the web service descriptor.
· While invoking the corresponding web service connector service, specify this response endpoint address as the value for ReplyTo and/or FaultTo address.

Example project

Create a new flow service named debugLog in designer. This service is to divide input1 by input2 and return the value as output. Below is the service input/output signature.

Create another flow service named debugLogResponse in designer. This service uses the output signature of debugLog as its input signature. We need this service to help creating mock service in SOAPUI.

Create another 2 flow services debugLogAdd and debugLogAddResponse similar to we have created above. The debugLogAdd service is to add input1 by input2 and return the value as output.

Now we should have 4 flow services in designer. Add them all into WS provider descriptor and then add Addressing as policy.

Import the WSDL that contains 4 operations in SOAPUI.

Create mock services which handle the web service response from webMethods asynchronously.

Enable WS-A configuration for debugLog web service in SOAPUI. Make sure you have ticked the checkbox of “Enable WS-A addressing” and “Generate MessageID”. The response is 2 which worked out as 4/2.

Receive response asynchronously. Use “Reply to” field in WS-addressing header to redirect the response to a call back endpoint. The client sends the request with an indication (ReplyTo header) that he wants the response to a third actor – the callback endpoint (mock service in this example). The server replies immediately with an HTTP 202 status which informs the client that the request has arrived and its processing has started. When the task is finished the server sends a request to the callback endpoint (listening at ReplyTo address). This is the response that the client expects. The response will be correlated with the corresponding request using the RelatesTo header.

Set reply to as http://localhost:8080/ which mock service is running on that port.

Check the response received by mock service.

We can also send back the SOAP Fault asynchronously by using Fault to field in WS-Address header. To capture SOAP Fault in mock service, you need to choose an operation to handle any incoming SOAP Fault. I choose debugLogResponse in my example.

Now we can change input 2 as zero to force an exception in flow service then a SOAP fault will be return as response.

Check mock service to find the SOAP Fault returned.

X.509 Authentication implemented as WS-Security policy

X.509 Authentication implemented as WS-Security policy

In cryptography, X.509 is an important standard for a public key infrastructure (PKI) to manage digital certificates and public-key encryption and a key part of the Transport Layer Security protocol used to secure web and email communication.

An ITU-T standard, X.509 specifies formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

The X509Authentication policy uses X.509 certificates to provide client authentication and includes a Timestamp token to guard against replay attacks. This policy does not enforce signatures or encryption.

Implement X.509 authentication in webMethods

Attach X509 Authentication policy to your web service descriptor in webMethods

Refer to: to setup client certificate in SOAPUI and webMethods.

Add outgoing WS-Security configurations for X.509 in SOAPUI. Make sure you have included timestamp.

Apply WS-Security setting to your SOAP request.

If you switch to “Raw” format of the request, you can find X509 in the security token segment.

Implement X.509 authentication with encryption

Similar to the previous steps, attach X509 Authentication, Signature and Encryption policy to your web service descriptor in webMethods

The server certificate is used by encrypt the SOAP message. You can download server certificate by access WSDL via HTTPS. Export the server certificate in X.509 der format. Save server certificate into a java key store (.jks)

JKS that contains server certificate

Add server certificate into keystore in SOAPUI.

Add outgoing WS-Security configurations for X.509 with encryption in SOAPUI. You need to have timestamp, signature and encryption as required by webMethods policy. The “password” value for encryption is not needed, because no private key is needed to encrypt a SOAP message.


To decrypt and validate signatures of the response messages, you need to setup incoming WS-Security configurations. Since the WS-Security headers of the response message contain most of the information required to decrypt or validate a message, the only configuration needed by SoapUI is which keystore or truststore that should be used.

The decrypt keystore should be the same keystore you used as signature in outgoing WSS and the signature keystore should be the one you used as encryption in outgoing WSS.

Apply WS-Security setting to your SOAP request and test it!

The response SOAP body has been decrypted correctly. You can find the encrypted response value by switch to “Raw” view. The raw value is stored in field CipherValue.

There are some known issues in SOAPUI 5.1.3. Please refer the following link to fix it.

Easiest fix is this:
Go to C:Program FilesSmartBearSoapUI-5.1.3lib
Rename wss4j-1.6.16.jar to wss4j-1.6.16.jar.old
Copy wss4j-1.6.2.jar from same location for SoapUI 4.5 to this folder.

Basic Authentication vs WS-Security username token

Basic Authentication vs WS-Security username token

Basic-authentication and WS-security username/password authentication both are different and independent.

Basic Authentication
Basic authentication is used in HTTP where user name and password will be encoded and passed with the request as a HTTP header.

POST http://localhost:5565/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: “zzHenry_webServiceSecurity_Provider_providerWSD_http_Binder_debugLog”
Content-Length: 325
Host: localhost:5565
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Authorization: Basic AAAAA=

<soapenv:Envelope xmlns:soapenv=”; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;

Username and password will be encoded using base64 and which is used in authorization header.

The most common to access a webservice hosted in webMethods is using basic authentication. In SOAPUI, at “Authentication” tab, choose “Basic” as authorization type and provide username and password. If you switch to “Raw” format of the request, all the HTTP headers are visible and you can see the Basic Authorization header is highlighted in yellow.

When we use Basic-authentication, the username and password setting is on the HTTP headers not in the SOAP message which might include SOAP header and SOAP body.

WS-Security username token

You can secure webservices using WS-Security username/password authentication mechanism that is a simple mechanism to secure services. It enforces user to provide Username Token security header in the SOAP requests. When create webservice descriptor in webMethods, you need to attach “Username over Transport” policy, this will force Username Token as part of the SOAP request.

To setup WS-Security in SOAPUI, please refer to:

Add client self-signed certificate into keystore.

Add outgoing WS-Security configuration. Below is the sample to add username token as security.
Enter the username/password that has the privilege to access webMethods webservice.
Add timestamp as part of security as this is defined in webMethods policy file.

Apply WS-Security setting to your SOAP request. Open the SOAP request that you want to apply the username token to and click the Authentication tab in the bottom corner and select the outgoing WSS configuration.

Test your request in SOAPUI. Remember to use HTTPS endpoint instead of HTTP.

If you switch to “Raw” format of the request, all SOAP message content is visible and you can see the Username Token in WS-Security is highlighted in yellow.

POST https://localhost:5575/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: “zzHenry_webServiceSecurity_Provider_providerWSD_http_Binder_debugLog”
Content-Length: 1226
Host: localhost:5575
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

<soapenv:Envelope xmlns:soapenv=”; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<wsse:Security xmlns:wsse=”; xmlns:wsu=””&gt;
<wsu:Timestamp wsu:Id=”TS-7991F70E1E3D94C684146294521076478″>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C684146294521076477″>
<wsse:Username>def </wsse:Username>
<wsse:Password Type=””>def</wsse:Password&gt;

Execution ACL permission

If you have both username/password in HTTP header and username token in SOAP header, which account will be used to execute webservice in webMethods?

When request comes to webMethods, Integration Server will check if account in HTTP header has the privilege or not. Once account in HTTP header has the permission, then Integration Server use the account in SOAP header to execute the service. In the other words, account in HTTP header should have the permission to access Integration Server while account in SOAP header should have the permission to execute the service.

To test this scenario, you can’t really do it using SOAPUI, use PowerShell instead. It gives more power to manipulate the xml request.

<soapenv:Envelope xmlns:soapenv=”; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<wsse:Security xmlns:wsse=”; xmlns:wsu=””&gt;
<wsu:Timestamp wsu:Id=”TS-7991F70E1E3D94C6841462949426574114″>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C6841462949426574113″>
<wsse:Username> def </wsse:Username>
<wsse:Password Type=””&gt; def </wsse:Password>

$user = ‘abc’
$pass = ‘abc’
$pair = “$($user):$($pass)”

$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))

$basicAuthValue = “Basic $encodedCreds”

$dict = @{}



[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$response=Invoke-WebRequest ‘https://localhost:5575/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port&#8217; -Method POST -Body $request -ContentType ‘text/xml; charset=utf-8’ -Headers $dict


To verify it, insert wm build-in service wm.monitor.util:getCurrentUser into your flow service, it will return the account that execute service.

Setup client certificate authentication in webMethods and test with SOAPUI

webMethods has three types of Client Authentication when Integration Server performing requests that arrive on its HTTPS port. One of them is Require Client Certificates, this means Integration Server requires client certificates for all requests.

By using a client certificate, you don’t need to provide user/pin to identify yourself when login to Integration Server.

What is a client certificate?

A client digital certificate or client certificate is basically a file, usually protected with a password and loaded into a client application (usually as PKCS12 files with the .p12 or .pfx extension).

Config Integration Server as an SSL Server

– Generate a public/private key pair using key store explorer. This certification will be used as server certification.

o Select key store type as JKS.

o Enter key pair alias. Use your server domain name as alias.

o Enter key store password. This key store password is important when setup key store in webMethods.


– Install the certificate in Integration Server

o Install the keystore via Security -> Keystore -> Create Keystore Alias on IS’s web frontend.

o To verify the key store has been loaded.

o Install the certificate via Security -> Certificates -> Edit Certificates Settings. Please notice we don’t have truststore setup at the moment and we will setup this up when we create client certificate.

– Add an HTTPS Port in Integration Server:

o Add HTTPS port via Security -> Ports -> Add Port

o Select require client certificate as client authentication methods. Again here we will setup truststore alias later.

o Test the HTTPS connection by navigating to https://localhost:5575 in IE.

The certificate error is ok, because we self-signed our certificate. Add the certificate to the list of trusted certificates and move on. If you use a “real” certificate later, the error will go away.

Config SOPAUI as SSL client

– Similar to generate server certificate, generate a client certificate using key store explorer but choose PKCS #12 as store type

o Select key store type as PKCS #12.

o Enter key pair alias. Use your name and local pc name as alias.

o Enter key store password. This key store password is important when setup key store in SOAPUI.

– Export client certificate and include it in trust store. This is to enable webMethods integration server to accept a self-signed certificate.

o Right click on the key pair, select export -> export certificate chain. Select X.509 as export format.

o Create java key store (.jks) to include the cert that generate in the previous step.

– Config trust store in webMehtods.

o Create truststore via Security -> Keystore -> Create Truststore Alias on IS’s web frontend.

o We should have both keystore and truststore setup in webMethods by now.

o Install the truststore via Security -> Certificates -> Edit Certificates Settings. Select truststore as alias from the drop down list.

o The final step to associate client certificate with a correspondence user in webMethods via Security -> Certificates -> Configure Client Certificates Settings.

– Use client certificate in SOAPUI

o Select the client key store in SOAPUI preference -> SSL settings.

o Test your client cert in SOAPUI! You will find the SSL information in the response.

As I mentioned at the beginning, try to login to IS’s web frontend using HTTPS to see if you were asked for a user/pin!

Create date-time UTC string in SOAPUI using groovy

When test web services in SOAPUI, the web service security policy might require current date-time stamp to be passed in security token. This is a bit annoy when test the web service you have to change the date-time string manually. You can use properties scripting provided by SOAPUI to resolve this issue.

When you pass an invalid timestamp in the request, the response will like this



Here is the article to use properties in SOAPUI.—properties/property-expansion.html

There are two common cases of inserting dynamic date-time value in SOAPUI using groovy:
1. Insert formatted timestamp value. Use SimpleDateFormat in this case:
${=new java.text.SimpleDateFormat(“yyyy-MM-dd’T’HH:mm:ss”).format(new Date())}
2. Format timestamp as xsd:dateTime value. Use DatatypeFactory to create instance of newXMLGregorianCalendar:

Then you can convert the date-time value into UTC format:
1. Insert formatted timestamp value. Use SimpleDateFormat in this case:
${=new java.text.SimpleDateFormat(“yyyy-MM-dd’T’HH:mm:ss.SSS’Z'”).format(new Date(System.currentTimeMillis()+5*60*1000))}
2. Format timestamp as xsd:dateTime value. Use DatatypeFactory to create instance of newXMLGregorianCalendar:

Below is how it should look like in



The last step is to include these properties in your web service request.soapui.request




This is useful when creating automation test suite.