Updating SOAP projects using WSDL refactoring (Pro)

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

Getting ready

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.

How to do it...

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 getInvoice operation gets renamed to retrieveInvoice
• New operations such as updateInvoice and deleteInvoice are added
• The invoiceNo field is renamed to id
• A new field dueDate is added to the invoice document
• The companyName field is removed in favor of a new customerRef field

These changes will result in a CRUD style interface, with some basic schema changes:

1. Firstly, open the project (the previous recipe's project: InvoiceSOAPv3) and right-click on InvoiceServicePortBinding and 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.
2. In the Transfer Operations window, SoapUI correctly maps createInvoice and leaves getInvoice in red to indicate that it has no mapping in the new WSDL. Correct this by clicking and dragging getInvoice on top of retrieveInvoice in the New Schema section, to end up with a result as shown in the following screenshot:
   
3. Click on Next to proceed to the Refactor Schema window. Correct the getInvoice request in a similar way as shown here:
   
4. Then, click on the red createInvoice operation. Here, map invoiceNo to id, but company cannot 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:
   
5. 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 the invoiceNo XPath's Assertion InvoiceNoShouldBe12345 by copying the Old XPath value into the New Xpath box and changing invoiceNo to id (as shown in the next screenshot), and then click on Finish:
   
6. Click on Yes in the Update Definition pop up to update the requests with the new v3 endpoint. 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 TestSteps need to be manually updated to the v3 endpoint.
• 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 Assertion Invoice12345ShouldHaveCompanyNameOfTestCompany option 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.

There's more...

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.