Xoom 3.6

This major release introduces: significant new features, such as bidirectional communication in Settings Migration Tool; improved robustness when dealing with Scheme changes; the ability to send SXP messages from Xoom Processor; and miscellaneous other improvements and bug fixes.

Settings Migration Tool

Bidirectional communication has been introduced such that the server now updates the client with a description of what is happening during deployment. This consists of:

the stage of the deployment (in the Status bar).
a progress bar showing progress within each stage.
any errors and warnings (in the Log pane).

Errors and warnings are also reported during the retrieval of configuration.

Service Optimization Scheme support

Significant new functionality has been added to the way Xoom handles Scheme changes. The code has also been hardened to minimise any possibility of database corruption. The new features are as follows.

Creation of product Collections. Sometimes XoomXML intended for deployment contains product Collections (Business objects or Dictionaries) that are not present in the target environment. While this can be a sign of database corruption, it more often results from the way in which particular modules were installed and upgraded at the various points in a database's history.
Previous versions of Xoom reported an error in such cases, and refused to create a new Collection (the rationale being that the Service Optimization Structure Tool doesn't enable its users to create product Collections). Due to customer demand, Xoom 3.6 works around this limitation as follows:
- It verifies whether the Collection ID is already in use, and, if not, applies it, guaranteeing that the newly created Collection will be of the same size as the retrieved product Collection.
- If the ID is not available, a new ID for a custom Collection of the same size is obtained from Service Optimization.
- Once the ID has been determined, the Collection is created as though it were a regular custom Collection.
This behaviour is enabled by default, but can be turned off via a new parameter called Product.W6.Scheme.CreateProductCollections, which is located in XoomParams.xml, typically here: C:\Program Files (x86)\Zany Ants\Xoom .
Collection renames. As Service Optimization installation moves through its life cycle, Collections are sometimes renamed for archival purposes, or in the process of an upgrade. What was previously a customisation also sometimes becomes a product feature (Service Optimization typically prefixes such Collection with 'User_').
Xoom can now automatically detect such renames under a limited set of circumstances where it is safe to do so. Detection of renames will be successful if:
- the two Collections have the same ID.
- their names are related so that either the old name is a subset of the new name, or vice versa (for example, 'User_BundlerPolicy' and 'BundlerPolicy').
- there are no other Collections in the system with the new name (which would cause a name clash and database corruption)
- the two collections are structurally identical.
This behaviour is enabled by default, but can be turned off via a new parameter called Product.W6.Scheme.DetectCollectionRenames, which is located in XoomParams.xml, typically here: C:\Program Files (x86)\Zany Ants\Xoom .
Multi-value and aggregate Collection renames. With multi-value and aggregate Collections, there is less chance of confusion as their belonging to a particular Property already uniquely determines their identity (and function). Hence, the rename detection is less strict in this case. All Xoom 3.6 requires is the following:
- that the two Collections belong to the same Property (for example AdjacentDistricts belong to Districts).
- that the corresponding Properties to which the Collections belong are of the same basic type (either aggregate or multi-value).
This behaviour is enabled by default, but can be turned off via a new parameter called Product.W6.Scheme.DetectAttributeCollectionRenames, which is located in XoomParams.xml, typically here: C:\Program Files (x86)\Zany Ants\Xoom .
Property renames. Like Collections, Properties are sometimes renamed for archival purposes, in the transition from free-form values (typically text) to a limited set of values defined in a Dictionary, or in the process of an upgrade.
Xoom can now automatically detect such renames under a limited set of circumstances. Detection of renames will be successful if:
- the two Properties have the same ID.
- there are no other Properties in the system with the new name.
- the two Properties are structurally identical (this includes the structure of any multi-value or aggregate Collection associated with the Property).
This behaviour is enabled by default, but can be turned off via a new parameter called Product.W6.Scheme.DetectAttributeRenames, which is located in XoomParams.xml, typically here: C:\Program Files (x86)\Zany Ants\Xoom .
Treatment of product Properties. Xoom will automatically remove Properties that do not exist in the deployed file, and rename Properties where the change of a name has been detected (see above). By default, this functionality will only apply to custom Properties, whereas product Properties will stay intact in order to prevent the possibility of database corruption. However, it is possible to enable this functionality for product Collections as well using two new parameters:
- Product.W6.Scheme.EnableProductAttributeDeletion
- Product.W6.Scheme.EnableProductAttributeRenames
It is our recommendation that these parameters are only used in special cases where there is a good reason to override the default behaviour. Any migration that employs these parameters should be well tested before being used in production.

Xoom Processor

Added the ability to send SXP messages to Xoom servers on the local network. The format of the message is:
[serverName[localhost]]::SendSxp

The SXP that will be sent is taken from the pipeline, and the response placed in the pipeline after the call.

In this example, the SXP response is saved in a file called SxpResponse.xml:

[serverName[localhost]]::SendSxp SxpResponse.xml
Modified the set semantic. The state of the sequence is now updated with the Xoom response (previously it was left intact and the Xoom response was ignored). This means that in automation scenarios the response can now be saved for future reference. Subsequences allow you to do everything you could previously: simply enclose each Xoom set instruction in brackets. For example, deploying two XoomXML files config.xml to server1 and server2 was previously done using:
xp config.xml server1: server2:

To achieve the same result you would now use:

xp config.xml ( server1: ) server2:

This also means you can now save Xoom responses from server1 and server2 in files response1.xml and response2.xml respectively:

xp config.xml ( server1: response1.xml ) server2: response2.xml

This wasn't previously possible.

xoom:set special form

Implemented new features:

select attribute is an alias for xpath.
include-self attribute, if set to true, indicates that the body of the xoom:set element contains the root element as well, not just the contents.
include-before attribute specifies the location where the new item will be inserted, or the existing item moved, assuming the XPath resolves to a node.

Using these features, it is now possible, for example, to implement single filter deployments in User Settings, such as:

<Configuration xmlns:xoom="urn:xmlns:zanyants:xoom">
  <UserSetting>
    <UserSetting xoom:id="UserSetting[Administrator|ClickSchedule Web Client|Administrative Settings|]">
      <Owner>Administrator</Owner>
      <Category>ClickSchedule Web Client</Category>
      <SubCategory>Administrative Settings</SubCategory>
      <Name />
      <xoom:set include-self="true"
                guard="Body/configuration/views/mainViews/schedulingView[@name='schedulingView']/mainAreas/mainArea[@name='resourceGanttChart']/filterConfiguration/filters"
                select="Body/configuration/views/mainViews/schedulingView[@name='schedulingView']/mainAreas/mainArea[@name='resourceGanttChart']/filterConfiguration/filters/filter[@name='Active behind Technician']">
        <filter name="Active behind Technician" operationType="Added" filterName="Active behind Technician" onObjects="Task,Assignment" outOfDomain="false" readOnlyFilter="true">
          <condition name="condition1" operationType="Added" property="Task.Status" operation="EqualsOneOf" value="Assigned,En Route,On Site,Scheduled" readOnly="false" mandatory="false" type="Equals One Of" />
          <condition name="condition2" operationType="Added" property="Task.IsBundled" operation="IsFalse" value="False" readOnly="false" mandatory="false" type="Equals No" />
        </filter>
      </xoom:set>
    </UserSetting>
  </UserSetting>
</Configuration>

General improvements

The reports drop-down in Xoom Explorer is now larger so that the names of all product reports are clearly visible.
Automatically generated references based on the Scheme now offer full support for DisplayString attributes.
A number of additional interpretations of new Service Optimization product features have been introduced.
There have been many performance improvements in various parts of Xoom, in particular during deployment.

Bug fixes

Multi-key references (such as District identified by Name and RegionParent) are now correctly interpreted and resolved.
Bad references without a known type are now correctly logged by client tools.
Decompositions are now interpreted correctly when a multi-value engineer index is used.
Network timeouts have been increased in order to prevent the loss of connection between client and server during lengthy operations.
Networking buffer sizes have been increased to accommodate larger Xoom documents.
License requests can now successfully be generated on computers that are not part of a domain or don't have a computer name.