In that article I suggested to create a set of properties with the actual working values on project level to be refered in the endpoint urls (hostname:port
This works fine for me. However, in my quest to the most comfortable way of registering and toggling between those values, I found a few enhancements quite convenient.
First of all, after the property-transfer step, I created a manual step, listing the values of the working properties, with a remark that it should contain the values of the particular target environment:
My Localhost version of this testcase will run into:
The second enhancement was that I moved my Target Environment property values to the "set
Since the testcase is environment-specific, I don't need a target-environment reference in the property-names. And also, they are scoped and thus not referable within other testsuites/testcases, preventing errors.
Moving those properties in SoapUI is pretty labor-intensive. But moving those in the source is quick (and dirty). If you open the SoapUI project xml file, you'll find the project-properties at the bottom of the file:
<con:properties> <con:property><con:name>CSServiceURI</con:name><con:value>ContentServer/PS_StoreDocumentToCSStage_v1</con:value> </con:property><con:property><con:name>CSServiceHost</con:name><con:value>localhost:7001</con:value></con:property> <con:property><con:name>CSUser</con:name><con:value>svc_GSA</con:value></con:property> <con:property><con:name>CSPassword</con:name><con:value>welcome1</con:value></con:property> <con:property><con:name>CSHost</con:name><con:value>localhost:8088</con:value></con:property> <con:property><con:name>CSAuthenticationURI</con:name><con:value>ContentServer/Authentication</con:value></con:property> <con:property><con:name>CSSearchServiceURI</con:name><con:value>ContentServer/SearchService</con:value></con:property> <con:property><con:name>CSDocumentManagementURI</con:name><con:value>ContentServer/DocumentManagement</con:value></con:property> <con:property><con:name>CSAuthenticationToken</con:name><con:value>TsiKqmREU78MhR4Po%2FJFlsv3OzGUAnDsDsPDcymSnxI%3D</con:value></con:property> </con:properties>
Copy and paste the properties to move (since I did so allready you'll don't find my target-env properties here anymore) to a seperate file to get them together.
Then find the target-testcase in the file (in this example "SetLocalEnvironment"):
You'll find at the end of the testcase an empty properties element (<con:properties/>). Open it up (<con:properties> </con:properties> ) and copy and paste the properties within the element.
SoapUI doesn't do formatting of the xml, so you might want to add line-feeds like I did in this example.
Finally you need to change the property-transfer-lines. In the example above, you'll see that I found the transfer-step and added line-feeds for each "<con:transfers ..."
<con:transfers setNullOnMissingSource="true"... some other properties... ><con:name>CSServiceHost</con:name><con:sourceType>CSServiceHost-Dev</con:sourceType><con:sourceStep>#Project#</con:sourceStep><con:targetType>CSServiceHost</con:targetType><con:targetStep>#Project#</con:targetStep><con:upgraded>true</con:upgraded></con:transfers>
You'll find in this line the source step: "<con:sourceStep>#Project#</con:sourceStep>" and target step: "<con:targetStep>#Project#</con:targetStep>". Change the value of the source step to: "<con:sourceStep>#TestCase#</con:sourceStep>". Now the property is refered from the testcase instead of the project. The property on project level can be deleted.
Renaming the properties can better be done from the UI, since SoapUI will then change the property-name also in every reference. Even in soap-requests. So after changing the file in your ascii-editor reload the project in SoapUI. And make the final changes and do the tests.
Now, although this is a nice example of source-hacking from outside the UI, you can't expect any support on this of course. So enable a proper version-control and test the SoapUI properly.
