soapUI Tip: Options for Refreshing a WSDL Definition

here’s a quick tip for soapui users that i have been stumbling over recently.  soapui allows you to refresh an already defined service definition from an updated wsdl file.  but, it’s easy to blow away the data that’s in your soap test steps if you chose the wrong options.

first, here’s the specific task i’m talking about.  you have an existing soapui workspace that has interface definitions already imported and you have at least one test suite using that interface.  now you’ve made a change to the wsdl and you need to refresh your interface definition in soapui and update the soap test steps in your test suite.  clearly, you want to update the soap requests to match the new wsdl without losing the test data that already exists in the test steps.  you reload a wsdl definition by right-clicking on an interface definition in soapui as shown below.

here’s a rundown of the effect of some of the “update definition” parameter configurations.  i haven’t gone through every permutation of the parameters, just the ones that seem most useful.  i’ve portrayed the configurations in terms of actions you’re likely to want to take after changing your wsdl.

• you added a new operation to the wsdl and you want to add default requests for it.

• you made a change to an existing operation in your wsdl and you want to regenerate existing requests using the new schema without creating optional elements. this configuration will cause you to lose the data in your existing requests .

• you made a change to an existing operation in your wsdl and you want to regenerate existing requests using the new schema and create optional elements. this configuration will cause you to lose the data in your existing requests, unless the elements are optional .

• you made a change to an existing operation in your wsdl and you want to regenerate existing requests using the new schema and create optional elements.  this configuration will keep the existing data in tact.

• you made a change to an existing operation in your wsdl and you want to regenerate existing requests and test steps using the new schema without creating optional elements.  this configuration will keep the existing data in tact but will remove optional elements from the existing requests .

• you made a change to an existing operation in your wsdl and you want to regenerate existing requests and test steps using the new schema and maintain optional elements.  this configuration will keep the existing data and optional elements in tact.

• the last configuration is the safest bet for most refreshes.  it combines all of the above. that means that it picks up all wsdl changes and incorporates them into both default requests and your soap test steps.  none of your existing data will be overwritten.  it also opens up a window that lists exactly which items have been modified.

i have not mentioned the “keep soap headers” and “create backups” parameters because i have not used them yet.

i suggest playing around with the “update definition” feature a little before using it.  soapui is a powerful tool, so it assumes you know what you want.  it accomplishes that by exposing panels with lots of parameters on them, like the “update definiton” panel.  if you get yourself into a bind, remember that you can just reload the project you’re working on by right-clicking on the project name and choosing “reload project”.  this option will reload the project into the workspace without saving the changes you just made.

from http://thewonggei.wordpress.com/2010/12/29/soapui-tip-options-for-refreshing-a-wsdl-definition/