Updating a SOAP project's WSDL will often lead to changes to test endpoints, requests, responses, and/or operations. In a simple example like that of the previous recipe, this isn't a big deal. For more complex WSDL changes that involve more tests, SoapUI Pro has a nice graphical editor that manages the migration step by step.
SoapUI WSDL refactoring can help manage the following:
Adding, removing, or renaming operations
Adding, removing, or renaming request/response fields
Resulting XPath (
Assertion) updates
We'll work on the <chapter1 samples>/invoice-soap-v2-soapui-project.xml project from the previous recipe. I have also included the project <chapter1 samples>/Invoice-soap-v3-soapui-project.xml, which is the end product after the refactoring.
The new WSDL can be found at <chapter1 samples>/soap/invoicev3/wsdl/invoice_v3.wsdl.
To illustrate the WSDL refactoring functionality, we'll refactor invoice_v2.wsdl and the tests from the previous recipe to use a new WSDL invoice_v3.wsdl. This will involve the following changes:
The
getInvoiceoperation gets renamed toretrieveInvoiceNew operations such as
updateInvoiceanddeleteInvoiceare addedThe
invoiceNofield is renamed toidA new field
dueDateis added to the invoice documentThe
companyNamefield is removed in favor of a newcustomerReffield
These changes will result in a CRUD style interface, with some basic schema changes:
Firstly, open the project (the previous recipe's project:
InvoiceSOAPv3) and right-click onInvoiceServicePortBindingand select RefactorDefinition. Enter the path to the new WSDL (invoice_v3.wsdl) and tick the options to create new requests and a backup, and then click on Next.In the Transfer Operations window, SoapUI correctly maps
createInvoiceand leavesgetInvoicein red to indicate that it has no mapping in the new WSDL. Correct this by clicking and dragginggetInvoiceon top ofretrieveInvoicein the New Schema section, to end up with a result as shown in the following screenshot:
Click on Next to proceed to the Refactor Schema window. Correct the
getInvoicerequest in a similar way as shown here:
Then, click on the red
createInvoiceoperation. Here, mapinvoiceNotoid, butcompanycannot be mapped (as we are removing it), so highlight it and click on Discard. Things should look like what is shown in the following screenshot; when ready, click on Next:
On the Update XPath Expressions window, first click on Filter unchanged paths to show only the problems. We can't fix the XPath relating to
companyName, so just fix theinvoiceNoXPath'sAssertion InvoiceNoShouldBe12345by copying the Old XPath value into the New Xpath box and changinginvoiceNotoid(as shown in the next screenshot), and then click on Finish:
Click on Yes in the Update Definition pop up to update the requests with the new
v3endpoint. You should see the Update of interface successful message. This indicates that the refactoring is complete!
On inspection of the refactored SoapUI project, all artifacts appeared to be in order, with the following exceptions:
The endpoints in the
TestStepsneed to be manually updated to thev3endpoint.The automatic backup failed with an
IOException(on MacOSX). As a workaround, I recommend that you manually back up the SoapUI project XML file.The
AssertionInvoice12345ShouldHaveCompanyNameOfTestCompanyoption needs to be deleted manually.
Note
Passing The Tests
If you would like to see the tests pass again, you can generate a v3 invoice service as per the previous recipes. Then, add a minimal implementation to satisfy the current assertions. I have included a very basic implementation <chapter1 samples>/soap/invoicev3_impl, which can just be run in the same way as the first three recipes.
The refactoring tool obviously doesn't write the missing tests for the updateInvoice and deleteInvoice operations or create Assertions for the new fields. These need to be added manually to return to an acceptable level of test coverage.
In terms of possible uses for WSDL refactoring, three typical SOA patterns are:
Contract Standardization (see http://soapatterns.org/design_patterns/contract_denormalization)
Decomposed Capability (see http://soapatterns.org/design_patterns/decomposed_capability)
Service Normalization (see http://soapatterns.org/design_patterns/service_normalization)
Variations on the first pattern are perhaps the most common, that is, refactoring of a single WSDL, as per our example. This is also the only pattern that can be covered in a single pass of the WSDL refactoring feature.