Beginning in PRPC 6.2, the Connector and Metadata wizard allows system architects to use the RuleSet and RuleSet Version capabilities in PRPC to manage true versioning of WSDL and XSD metadata.

When re-importing changed WSDL or XSD files that represent the external system"s data model, users can specify a new RuleSet or RuleSet version for the PRPC artifacts generated by the accelerator. This allows users to generate new SOAP connectors and XML mapping rules for changed WSDL and XSD metadata that use the same class structure as earlier executions of the accelerator, minimizing the configuration required to incorporate external data model changes into an existing PRPC application.

In versions of PRPC earlier than 6.2, even minor changes in the WSDL or XSD require a full regeneration of PRPC artifacts. To update the data model in these earlier PRPC versions , you must either delete and regenerate all of the rules that were generated previously, or use a different, non-conflicting base class for each unique version of the metadata.

Suggested approach

The Connector and Metadata Wizard in PRPC 6.2+ allows the system architect to override existing SOAP connector or XML mapping rule instances with rules that are created at a higher RuleSet version. If the developer specifies a target RuleSet or RuleSet version that is different than previous imports of the WSDL or XSD metadata, the accelerator does not display the steps that require the developer to rename or overwrite matching duplicate rule instances.

In addition, rule generation in the accelerator is optimized to only generate new class and property definitions for those fields that have been added to, or changed from the previous set of XML schema definitions. This results in significantly fewer generated rules and faster overall accelerator performance when loading new versions of WSDL or XSD metadata.

Example

The following demonstrates the use of the versioning features in PRPC 6.2 and later from a Parse XML or XML Stream rule.

If the WSDL or XSD file specified on the XML tab has changed, click Update on the Mapping tab to regenerate the PRPC artifacts generated by the accelerator.

Update re-launches the accelerator that was used to generate it. The first screen of the accelerator displays an informational message to users suggesting that they specify a higher RuleSet version.

By using this field, rules that were generated for the previous version of the metadata can be rebuilt in a higher RuleSet version, so that they do not require other changes to the existing configuration.

In the Review and Save step of the wizard, you can see how the content of the generated mapping rules has changed since the previous version of the metadata was loaded.

The Difference Count column displays the number of fields that have changed in the tree structure of the map rule. Click on the icons in the Difference Report column, to download a CSV file that lists the nodes that have been changed for that rule since the previous version of the map rule. Click Open Diff Report to get a full list of all the changes.

You can launch the Connector and Metadata Wizard from the landing page, > Integration > Connectors > Connector and Metadata, rather than from the Update button on the Parse XML or XML Stream rule. In that case you can set the Ruleset and Ruleset Version of the generated rules as described here, but the wizard does not generate a difference report.

Handling Incompatible Metadata Changes

If the WSDL or XSD metadata has redefined a type such that the associated PRPC class or property definitions are incompatible with the earlier versions, the accelerator generates new class or property rule instances with unique names that do not conflict with the earlier versions.

For example, a new class rule is created by the accelerator if the new version is derived from a different parent class or its abstract/concrete value has changed. A new property rule instance is generated by the accelerator if the new version has a different mode, type, or page class value.

The renaming is handled entirely by the accelerator and does not require input from the user. After the accelerator completes, the renamed classes are visible in the Class Explorer view, and the renamed properties are visible in the tree view displays of the updated XML mapping rules.