This topic explains how to use Parasoft Change Advisor in SOAtest and Virtualize. It describes how to update the request or response messages that your test or service virtualization assets send.
Change Advisor automatically identifies how messages sent by your existing test and/or service virtualization assets are impacted by service changes (e.g., renamed operations, added elements or types, modified namespaces, etc.). It also automatically refactors impacted tools (individually or in bulk) based on a change template to either update your existing test or responder suite or create a new one. Change templates are created by reviewing and refining automatically-defined mappings that explain how elements/operations/resources and schemas from the original definition relate to those in the current definition. This ensures that your assets are updated as rapidly, accurately, and intelligently as possible.
Change Advisor depends on an Eclipse plugin called EMF Compare. That plugin gets installed in the full SOAtest installation, but not when SOAtest is installed from update site or plugin installer.
You can install the EMF Compare plugin using the Eclipse update site mechanism; the update site is at
If you suspect that a service has changed, the typical workflow is:
Apply that change template—on a case by case basis (to resolve specific change impacts reported by the change impact analysis) or for batch refactoring (to rapidly update all impacted tools across a project, suite, etc.)—to update your existing suite or create a new one.
SOAtest can catch unexpected service changes as soon as they occur:
When a Change Impact Analysis is run, Change Advisor reports how assets’ messages are impacted by a change in the related definition file (e.g., WSDL, schema, WADL, Swagger, RAML). This analysis can either:
Compare the assets' messages against the service definition with which they are currently configured.
Compare the assets' messages against a different service definition.
The result of this analysis helps you assess the scope and nature of changes that will be required to update your assets’ messages.
After determining what should be updated, you can apply a change template to automatically refactor the messages to suit the modified service definition. The template can be applied in a number of ways:
Change templates can be automatically generated from the Service Catalog, which is populated during change impact analysis.
Once a change template is created, we recommend that you review and fine-tune the automatically-defined mappings that explain how elements/operations/resources and schemas from the original definition relate to those in the current definition.
Reviewing and updating the automatically-defined mappings is performed in the graphical Change Template editor:
Once a change template is generated, it can be applied on a case by case basis (to resolve specific change impacts reported by change impact analysis) as well as for batch refactoring (to rapidly update all impacted tools across a project, suite, etc.)
Change Advisor can be applied to messaging tools (SOAP Client, REST Client, EDI Client, Fixed Length Client, Message Stub).
Change Advisor operates on the messages specified via Form Input if the tool is set to be constrained to WSDL or Schema, or if the Service Definition has a RAML, WADL (SOAtest), or Swagger specified. It operates on the messages specified via Form JSON if the Service Definition has a RAML, WADL (SOAtest), or Swagger specified.
For the REST Client, Change Advisor applies to path and query parameters, as well as XML or JSON payloads.
If a tool’s message is specified in a non-supported format, it will be skipped during analysis and refactoring. To update values in these formats, values in other non-message fields in these tools, or values in tools not supported by Change Advisor, use Parasoft Search and Replace. See
Simple changes to the definition file (elements are reordered, types are changed, etc.) are updated automatically.
The Change Advisor perspective is designed specifically for identifying and addressing change impacts.
To open the Change Advisor perspective:
This perspective provides:
Toolbarbuttons: Three buttons are added: Run (used to rerun change impact analysis to check that assets have been refactored properly) Perform Change Impact Analysis (described below), and Refactor Using a Change Template (described below).
Change impact analysis compares the service definition that was originally used to construct the tools’ messages vs. either
Change impact analysis will report only changes that are relevant to the tools you’re analyzing. For example, if the service no longer includes an optional element that your tools never used, a change impact will NOT be reported.
Typical use cases for running change impact analysis in SOAtest are:
To run change impact analysis from Change Advisor:
For instance, assume you have selected a suite that includes assets based on 3 different service definitions. Analysis with the Scan the selected assets against their current service description option will compare all of those assets vs. the current version of their correlated service definitions. If you select Scan the selected assets against a specified service description—and you specify the location of the existing and updated version of 1 of the 3 service definitions used by those assets— the analysis will be applied to only the assets that use that specified service description. Assets based on the 2 other definitions will not analyzed.
To run change impact analysis (vs. the current version of the assets’ existing service definitions) during regular test execution:
As the analysis runs, analysis progress will be reported in the progress view as well as the console view. Note that if an asset is reported as "skipped," this indicates that it did not have messages specified in a supported format (e.g., Form Input).
The results of the analysis will be reported in the Quality Tasks view. A Change Impact layout is provided to help you review change impacts. If the Quality View is not already using this layout, you can enable it by clicking the Change Impact Layout toolbar button in the results view:
You can also open this layout from that view’s drop-down menu.
The results are organized by service, suite/location, and the type of change:
To open the tool whose message needs to be updated:
To see the tool’s location within your projects:
Change templates are created as described in Defining a Change Template. There are two ways to apply a change template:
To apply a change template:
In the second page of the wizard, indicate where you want to save the updated assets. The default is to save the updated assets in a new location so that you’re creating a new set of tests or responders rather than overwriting your original assets.
The refactoring will update messages as defined in the change template. Tools for removed operations will be disabled, but not deleted.
A change template specifies how to map the elements/operations/resources and schemas (either XML or JSON) from one service version to those in another. Once a change template is defined, it can be applied to update assets impacted by a service change: either to remedy specific change impacts reported after a change impact analysis or to perform a batch update on selected tools, suites, or projects. For instance, if FundPrepaid is mapped to FundPrepaidRequest in a change template, applying this template will update FundPrepaid to FundPrepaidRequest in the selected tools’ messages.
Change templates are created, reviewed, and modified from the Parasoft Change Advisor perspective.
To create a change template:
To rename a service or version, right-click its Service Catalog node, then choose the appropriate Rename command. The names specified here will be used in the Refactor Using a Change Template wizard.
Note that if you have both SOAtest and Virtualize installed, the Operations node will be split into two nodes:
• Client View: For SOAtest messaging clients (covers request parameters)
• Responder View: For Virtualize message responders (covers response parameters)
A change template will then be created and opened in the Change Template editor.
The change template automatically maps elements/operations/resources and their schema from the original service definition to the new one according to Parasoft’s heuristics:
Elements/operations/resources are mapped in the Map Elements/Operations/Resources tab.
Each element’s schemas are mapped in the Map Schemas tab.
As you are reviewing the mappings, you can use the filters available at the top of the editor to focus on high probability matches, matches needing review, or unnmatched items.
As you review and modify the change template, you can perform the following actions:
|To achieve this...||Do this...|
|Specify that two unmapped items are correlated.||Select both items, then click Connect.|
|Specify that two mapped items are NOT cor-related.||Select both items, then click Disconnect.|
|Specify the default value for an unmatched item.||Right-click that item, select Configure Default Value for Added [item_name], then specify the appropriate value in the dialog that opens.|
|Indicate that a "match needing review" has been reviewed (turning a yellow mapping to a green one).||Right-click any area of the mapping, then choose either Mark Match [mapping] as Reviewed or Mark Match [mapping] and Child Matches as Reviewed.|
|Indicate that an unmatched item has been reviewed.|
Right-click that element, then choose either Mark [item_name] as Reviewed or Mark [item_name] and Children as Reviewed.
As you’re mapping elements/operations/resources and schemas, you can refer to the Properties view for details about the item you’re trying to map. For example:
The following icons are used to mark XML items in the Change Template editor:
The following icons are used to mark JSON items in the Change Template editor:
If your team wants to share change templates, either share the project that contains that template, or copy the template from one workspace to another.
For a tutorial on using Change Advisor, see Updating Tests as Services Change.