We are proud to announce the release of Xoom 3.6. This release introduces: significant new features, such as bidirectional communication in the 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 (SMT)

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

the stage of the import (in the status bar)
a progress bar showing progress within each stage
any errors and warnings (in the log)

Errors and warnings are also reported during the reading (and export) of the 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 the import file 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 of 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 such 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 exported 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 in Xoom folder.

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 collections 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 (that 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 in Xoom folder.

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 in Xoom folder.

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 in Xoom folder.

Treatment of product properties

Xoom will automatically remove properties that do not exist in the imported 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 sendSXP messages toXoom 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 pipeline is now updated with theXoom response (previously it was left intact and theXoom response was ignored). This means that in automation scenarios the response can now be saved for future reference.Xoom Processor’s branching capability allows you to do everything you couldpreviously by simply enclosing eachXoom set instruction in brackets to create its own branch of the pipeline. For example, importingXoom file config.xml toserver1 andserver2 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 xoom:set 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
insert-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 imports in administrative 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 import.

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.

Zany Ants

Configuration, enlightened.

Xoom 3.6 has been released