Update Node Versions

Description

The Update Node Versions service creates new versions of nodes which link to new versions of node types and member type targets, to update a node structure to later node versions.

The typical case, known as a "relink", is that the service is passed a package. The latest version of the package node and all nodes within it are examined. If the type or any targets are within the package, but are not the latest version, then these are updated to be the latest version, if necessary creating a new version of the node with the new type version and/or to hold the new version of the targets. This is repeated until there is no more relinking to be done.

Parameters control what combination of the node, its immediate contents and all its descendants are updated. Multiple nodes can be selected for the update.

Input

<UpdateNodeVersions>
<userLogonReference>userid</userLogonReference>
<password>password</password>
<action>impact|update|quiet</action> <UpdateList>
<Update>
<nodeReference/>
<updateNode>true|false/updateNode>
<updateContents>true|false</updateContents>
<updateAll>true|false</updateAll>
</Update>
</UpdateList>
<source>true|false|node.reference</source>
<draftSource>true|false</draftSource>
</UpdateNodeVersions>

Update repeats.

action controls what the service will do.

  • impact calculates and returns the impact of the update
  • update performs the update and returns a description of what it has done
  • quite performs the update but does not return a description of what it has done

Pass the references of the nodes to be updated in the update list.

The three parameters updateNode, updateContents and updateAll control what is updated. updateNode means that the node itself should be updated, updateContents means that its immediate contents should be updated, and updateAll means that the immediate contents and all lower-level contents should be updated. All three default to true. updateAll is ignored if updateContents is not true.

You can use updateNode to switch off parts of an update. For example, if you set the node reference to somecompany.mypackage with updateNode, updateContents and updateAll left to default, then set somecompany.package.subpackage with updateNode and updateContents of false, then the update would include everything in somecompany.mypackage except for somecompany.package.subpackage.

The caller must have admin authority over all the update nodes, except for those with updateNode and updateContents set to false.

By default, the node update will update to the draft versions of any nodes, though the caller must have permission to use draft nodes of any nodes outside of the update nodes. You can change this by setting source and draftSource:

  • Set source to false to limit looking for updates to the update nodes themselves.
  • Set source to a node reference to only update to a node or to any nodes in a package.
  • Set draftSource to false to disallow updates to draft versions.

Output

<UpdateNodeVersions>
<errorNumber>0</errorNumber> <UpdateList> <Update> <nodeReference/> <nodeVersionNumber/> <nodeName/> <updateType>version|change</updateType> <typeUpdateType>none|change</typeUpdateType> <nodeReferenceType/> <nodeVersionNumberType/> <nodeNameType/> <MemberUpdateList> <MemberUpdate> <nodeReferenceMemberType/> <nodeVersionNumberMemberType/> <nodeNameMemberType/> <nodeReferenceTarget/> <nodeVersionNumberTarget/> <nodeNameTarget/> </MemberUpdate> </MemberUpdateList> </Update> </UpdateList>
</UpdateNodeVersions>

The update list shows what will be updated or what has been updated, and is only returned for an action of impact or update.

Each updated node is returned in a section. The node is identified by its reference, new version number and name. updateType indicates whether a new version will be created, or the node changed without creating a new version.

If the type is updated, typeUpdateType will be set to change and the new type version number and name are given. (They are not passed if the type is not to be updated.)

The updates for each member are listed. The new version of the target is shown.

The only expected errors are parameter errors and the user not authorised to administer the update nodes.

Treatment of comments

Node member comments are retained when node versions are updated, but are not carried over when new versions are created.

Errors

101 - Not authorised

105 - user error, typically because node reference cannot be found.

Class

com.metrici.xerula.UpdateNodeVersionsService