What's new / Release notes
Parent topic: Release notes

Xoom 3.10

This major release brings significant functional and performance improvements, and a host of new features, in particular targeting more selective transport and deployment control in Service Optimization environments.

Xoom client tools

We have changed our terminology in order to make it clearer and bring it in line with the documentation. Terms such as import and export, which were ambiguous (e.g. does import means import from file to a tool, or from tool to the managed system?), have been replaced by the following, more clearly defined, terms: The Transformation drop-down in Xoom Explorer has doubled in width to handle transformations with very long names.

File handling

File handling capabilities have been significantly revamped and enhanced. A number of elements describing the file have been renamed for clarity. For example, what used to be: 
<File xoom:id="File[${Product.W6.BinDirectory}|W6Bindings.dll]">
  <LocalPath>W6Bindings.dll</LocalPath>
  <Path>${Product.W6.BinDirectory}</Path>
  <Name>W6Bindings.dll</Name>
  <FullPath>C:\Program Files (x86)\ClickSoftware\Service Optimization\bin\W6Bindings.dll</FullPath>
  <Size>43520</Size>
  <LastModificationDate>2014-07-29 20:16:20</LastModificationDate>
  <MD5>38-EC-C4-5B-78-2E-D9-DD-36-B9-EB-4F-6C-F3-7B-C2</MD5>
  <Version>BUILD_8.1.10.9581 - 8.1.10 Patch 007</Version>
  <Extension>dll</Extension>
</File>
now becomes 
<File xoom:id="File[? ${Product.W6.BinDirectory}|W6Bindings.dll]">
  <RelativePath>W6Bindings.dll</RelativePath>
  <BaseDirectory>? ${Product.W6.BinDirectory}</BaseDirectory>
  <Name>W6Bindings.dll</Name>
  <LocalPath>C:\Program Files (x86)\ClickSoftware\Service Optimization\bin\W6Bindings.dll</LocalPath>
  <Size>43520</Size>
  <CreationTime>2015-10-12T16:27:59</CreationTime>
  <LastWriteTime>2015-10-12T16:27:59</LastWriteTime>
  <Checksum algorithm="sha1">dc586c7948bd8877d69f40dbde7350e98e837d7b</Checksum>
  <Version>BUILD_8.1.10.9581 - 8.1.10 Patch 007</Version>
  <Extension>dll</Extension>
</File>
The differences are subtle, but some of them are quite important:
  • The LocalPath element previously indicated the relative path from the base directory specified in the Path element. This was quite confusing. In response, RelativePath and BaseDirectory are now used instead.
  • The content of BaseDirectory now starts with "? " (question mark followed by space). This is to make it explicit that the content of the element is a ZanyScript expression, not a literal string. Previously, this was only implied, making it harder to know when to put literal strings in quotes.
  • FullPath, which indicated a full file path on the local file system, has been replaced with LocalPath, which is more descriptive of that information.
  • LastModificationDate has been replaced by CreationTime and LastWriteTime, both of which are now expressed in an ISO format instead of localised format that was subject to interpretation.
  • MD5 element is now replaced by Checksum element that explicitly notes the algorithm used, in this case SHA1.
The expressiveness of file queries has also been improved. The two predefined queries have now been moved to XoomCustom.xml, and are now defined like this: 
<xpi:query name="Service Optimization Files Info">
  <Files>
    <File base-directory="? ${Product.W6.BinDirectory}" filter="*.dll;*.exe"/>
    <File base-directory="? ${Product.W6.RootDirectory} + '/Web'" recursive="true" exclude-path="/Log"/>
  </Files>
</xpi:query>
 
<xpi:query name="Xoom Files Info">
  <Files>
    <File base-directory="? ${Xoom.InstallDirectory}" recursive="true" exclude-path="/XoomLog;/XoomTemp;/XoomTrace"/>
    <File base-directory="? ${Product.W6.Xoom.PluginDirectory}" recursive="true" exclude-path="/XoomTrace"/>
  </Files>
</xpi:query>

There is now an explicit distinction between structural filtering (for example, by specifying a relative path element under the query) and explicit querying as demonstrated here. Attributes are used to define the parameters for explicit queries, such as: base-directory, filter, recursive and exclude-path, above. Previously, the situation was much less defined, and it wasn’t clear which bits were used as queries and which as structural filters.

The expressive capabilities are now also much greater. Most importantly, we are now able to exclude the file paths that are not interesting, such as logging and temporary directories.

We have also introduced the capability to transport files between systems. This is achieved by specifying the attribute content-storage="embedded". For example, here we define a query that can be used to copy ClickMobile custom JavaScript files: 
<xpi:query name="ClickMobile JavaScript Files">
  <Files>
    <File base-directory="? ${Product.W6.RootDirectory} + '/Web/ClickMobileWeb/CustomScripts'"
          filter="*.js" content-storage="embedded"/>
  </Files>
</xpi:query>
In this case, the file content will be gzipped and embedded inside the resulting XoomXML file as Base64-encoded string.
Two new parameters in XoomParams.xml control behaviour related to content transport:
Table 1. Xoom parameters: File content transport
Parameter Description Takes values Default Xoom release
Xoom.FileTweaky.AllowWriteToSpecialFolder.Windows Specifies whether or not Xoom will attempt to write to the Windows folder. true/false false 3.10
Xoom.FileTweaky.ContentStorage.Embedded.MaximumFileSize Specifies the maximum size in bytes of a file that Xoom will attempt to embed for transport. Bytes. 1048576 (1MB) 3.10
There is also a new calculated parameter Product.W6.RootDirectory in addition to Product.W6.BinDirectory that makes the expression of various Service Optimization-related paths more concise.

Reports and transformations

The following transformations have been added:
  • ExtractMobileWebTemplateEventsForXoomSet takes a specified ClickMobile web client template from the source configuration (parameter FromTemplate), and copies the specified events definitions (parameter EventNames) to a number of other specified templates (parameter ToTemplates).
  • ExtractMobileWebTemplateFormsForXoomSet takes a specified ClickMobile web client template from the source configuration (parameter FromTemplate), and copies the specified forms (parameter ObjectTypes) to a number of other specified templates (parameter ToTemplates).
  • ExtractMobileWebTemplatePropertiesForXoomSet takes a specified ClickMobile web client template from the source configuration (parameter FromTemplate), and copies additional properties for the specified Objects (parameter ObjectTypes) to a number of other specified templates (parameter ToTemplates).
  • ExtractMobileWebTemplateFormsPropertiesEventsForXoomSet takes a specified ClickMobile web client template from the source configuration (parameter FromTemplate), and copies the specified forms (parameter FormTypes), additional Properties for the specified Objects (parameter AdditionalPropertiesTypes) and event definitions (parameter EventNames) to a number of other specified templates (parameter ToTemplates). In other words, this transformation essentially brings the previous three transformations into one. As far as forms are concerned, there is a subtle difference between this transformation and ExtractMobileWebTemplateFormsForXoomSet: while this transformation creates a single entry for all Settings associated with all the forms (including sub-forms) associated with each Object, ExtractMobileWebTemplateFormsForXoomSet creates a separate xoom:set entry for each form and doesn’t include top-level form Settings. The two transformations should therefore be used according to the desired degree of granularity.
  • ExtractScheduleTemplateFormsForXoomSet takes a specified ClickSchedule web client template from the source configuration (parameter FromTemplate), and copies the specified forms (parameter ObjectTypes) to a number of other specified templates (parameter ToTemplates).
  • ExtractOutgoingMessagesForXoomSet and ExtractOutgoingMessagesByNameForXoomSet both result in XoomXML that extracts outgoing messages in separate xoom:set instructions for easy manual editing of the messages that should be supported. The difference between the two is that the former uses name, event and destination in order to identify different messages, while the latter uses just the name. In both cases, an index is added to distinguish between multiple messages that match the same identifying criteria, as identity of messages is not unique in Service Optimization.

Rules report and Objectives report have been rewritten from scratch. The new versions are much better able to represent configuration of Rule and Objective types that weren’t encountered before and hence don’t have special handling. The reports' appearance has also been redesigned.

Several changes were made to Structure report:
  • The report now lists all Indexes for each Collection, together with their definition.
  • The report now indicates a matching Index ID for Collections with Object Reference entries, and warns about the configuration error where there is no such matching Index.
  • Minor bugs in the navigation section of the report were fixed, and the navigation now works correctly.

DecorateWithAliases transformation has been restructured in order to make it usable in a more modular way, such as for example through import from another transformation where the alias decoration should be part of the overall process. Ultimately, this will make it much easier to write new reports and transformations where references need to be followed between items.

Xoom Corpus Generator and Diagnostic Snapshot

Xoom Corpus Generator now captures more information about the Service Optimization system that is being captured in order to make it easier to advise new customers without requesting additional data. The information that was added to the capture is:
  • the measurement of the sizes of each collection’s database table
  • the full data of all Collections with fewer than 1,000 items.
  • the information from each virtual Collection (known as configurations in ClickSoftware language).
Both Xoom Corpus Generator and Diagnostic Snapshot now also use SQLite tables for corpus data instead of XML, which makes their memory footprint dramatically smaller and enables the capture of larger and more complex environments.

Enhanced scripting capabilities for Service Optimization

We added the capability to interrogate and control the state of ClickSoftware servers connected to a Xoom server. This is implemented using a new Windows PowerShell CmdLet called Invoke-W6ServerStateOperation. The CmdLet is self-documenting in the standard Windows PowerShell way, and allows all or specific servers to be locked, unlocked, started or stopped.

We have also added the capability to temporarily stop and later restart the ClickMobile syncing using a script. Being able to do that is particularly important during production deployments where Dictionary changes are performed on a system with many ClickMobile clients. In such systems, Dictionary changes can be extremely slow and often lead to timeouts due to the need to repeatedly synchronize those changes to ClickMobile clients.

Instead, the new script StopClickMobileDictionarySync can be used to stop the syncing for all ClickMobile templates, while saving the syncronisation configuration for later. Once the Dictionary changes have been deployed, RestartClickMobileDictionarySync script is used to restore the synchronisation configuration, resulting in a single sync for all clients in which all updates are synchronised at once.

Other

Parent topic: Release notes
WebHelp output generated byXML Author