This significant release contains a new versioning script supporting per-item
configuration versioning with Git, Mercurial and Subversion, major improvements on
installation file information retrieval, some enhancements of Xoom Processor, usability
improvements of Settings Migration Tool and some other minor improvements and bug fixes.
New versioning script
We are introducing a completely rewritten versioning script that takes advantage of Xoom Processor,
and its ability to retrieve and store Xoom data in various ways. Support for the
three revision control systems (Git, Mercurial and Subversion) has been made more robust. Here
is the summary of major improvements:
- In Xoom Processor, retrieved configuration can be saved as a Xoom folder,
with a well-defined structure and multiple files, each containing a single item.
Taking advantage of this, the versioning script now supports Xoom folders in all three
supported revision control systems. The result of such per-item
configuration versioning is a much more detailed change log. Changes to items
are immediately apparent: previously, to find changes, you had to inspect the contents of a
single large XoomXML file, containing thousands of items. This also means that,
for the first time, there is now a very simple way to inspect the complete history of changes
of each individual item.
- When several operations need to be performed on the result of a single
query, for example an automated production of several reports from the same data, the
subsequent reports can now be performed on a previously stored result of a query,
eliminating the need to repeatedly query the Xoom server for the same information. This
results in faster execution of a script and a lesser load on the Service Optimization server.
- The support for revision control systems is now much more robust, with more built-in checks,
more specific, more detailed and friendlier error messages, and higher degree of control over
the behaviour of the script when things go wrong, such as whether partially successful
retrieval of information should be committed or rolled back. In addition, the
queries are now configured per repository and it is now much harder to accidentally
store information outside the versioned directories.
- A command line parameter specifying a commit message is now supported. This is particularly
useful when the script is run interactively and there is a need to describe what changes were
made and why. There are a number of other new command line parameters, the documentation of
which can be seen using the standard Get-Help PowerShell commandlet.
File configuration retrieval
The component for file information retrieval has also been rewritten. The main two
new capabilities are the ability to use Xoom parameter values and expressions in the Path
definition for file information retrieval, and that recursive directory traversal is
now supported.
The representation has also changed somewhat, and now looks like this:
<File xoom:id="File[${Xoom.InstallDirectory}|Reports\ReferencesReport.xsl]">
<LocalPath>Reports\ReferencesReport.xsl</LocalPath>
<Path>${Xoom.InstallDirectory}</Path>
<Name>ReferencesReport.xsl</Name>
<FullPath>C:\Program Files (x86)\Zany Ants\Xoom\Reports\ReferencesReport.xsl</FullPath>
<Size>3281</Size>
<LastModificationDate>2013-01-10 10:58:05</LastModificationDate>
<MD5>DD-9B-48-5D-84-08-E1-AD-B3-B4-F5-D5-AA-D5-BE-6D</MD5>
<Version />
<Extension>xsl</Extension>
</File>
FullPath is what used to be Path, and is now the only bit of information that is environment specific (and
will hence be ignored when environments are compared, meaning that Xoom installed
on disk C: can easily be compared with Xoom installed on disk D: on a different system). All
other information uses a logical position derived from Path,
which in this example is defined using a Xoom parameter specifying the Xoom installation
directory. LocalPath describes the file's path relative to Path (which serves as a logical base directory), and Path preserves its literal value from the query definition
and doesn't get modified.
The IDs for a file are now its Path and LocalPath (previously they were a full directory name and file
Name). The final minor change is that Extension no longer starts
with a dot.
There are now two pre-defined file information retrieval queries: one for
Service Optimization, which includes the .dll and .exe files in the Bin directory and all files in the Web
directory with all its children; and another for Xoom itself, which retrieves the
information on all files in both the main Xoom folder and the W6 plug-in folder, in each
case including all subdirectories. The queries are defined in
XoomConfig.xml.
Settings Migration Tool
Settings Migration Tool now remembers and reconstructs checked items and categories when a session is
refreshed or a connection is established to a different Xoom server. Collections that
were loaded and that contained checked items will be reloaded; Collections that
were loaded but contained no checked items will not. For Collections that
weren't loaded, any checked categories remain checked after the refresh.
This behaviour is helpful in situations where a lengthy review of configuration has
to be interrupted so that the session can be renewed. This can now be done safely without having
to recheck all the items.
Xoom Processor
Xoom Processor now supports the console as its output (using @ in place of a target), and prints out
usage when called without parameters.
It also supports canonicalisation of XML and various other formatting options. These features
are explained in the Xoom Processor documentation.
Other improvements
- A new report ActiveScheduleAgentsReport has been added. The report provides detailed
configuration (down to a Decomposition and Background Optimization step
configuration) of all active Background Optimization Agents in the
system.
- Events, Objective types, SXP Object Reference, and Rule types are now
sorted alphabetically in XoomXML, making it easier to compare XoomXML files using
non-Xoom tools.
- A more informative error message is now issued is cases where a data-entry required in the
deployment of a specific logic component can't be found on the target system. Most
commonly this happens when a required customisation wasn't installed.
- A number of distinct event log sources are now registered and used by Xoom, making it
easier to filter Xoom messages by context (most commonly the tool in use).
Bug fixes
- Named queries in Xoom Explorer are now sorted by name.
- The ordering of Collections in the DEFAULT query in the
generic version of Xoom has also been fixed.
- When an attempt is made to modify the IsProduct property of
an existing Collection, Xoom no longer stops processing and reports an error.
Instead, a warning is placed in the Event log, stating that the IsProduct property cannot be changed on existing
Collections, and the rest of the changes to the Collection are
deployed. If the sole difference is in IsProduct
property alone, then Xoom will not register a difference and will not allow
deployment. This is because the IsProduct property
can't be changed and has no functional consequences. The only functional differences are the
Collection's icon colour in Service Optimization Structure tool and the inability to manually delete
product Collections, both of which are irrelevant outside the context of
configuration management.