News

Xoom 3.10 has been released

We are proud to announce the release of Xoom 3.10. This is a major release, bringing significant functional and performance improvements, and a host of new features in particular targeting more selective transport and deployment control on Service Optimization environments.

Client tools

The language of client tools has been clarified and consolidated in order to make it clearer and bring it in line with the documentation. Instead of import and export, the function of which was sometimes unclear (e.g. does import means import from file to a tool or to the managed system?), we now use the following verbs with more clearly defined meaning:

  • Retrieve means getting configuration from Xoom server to the client tool.
  • Save means saving XoomXML with the retrieved configuration in a file.
  • Load means loading XoomXML from a file to the client tool.
  • Deploy means sending the configuration via Xoom server to the targeted managed system so that it becomes current configuration.

Xoom Explorer’s transformation drop-down has doubled in size to facilitate the choice between transformations with very long names.

File handling

File handling capabilities have been significantly revamped and enhanced.

The naming of a number of elements describing the file have changed in order to make them clearer. 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>

will now become

<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:

  • LocalPath element previously indicated relative path from base directory specified in Path element, which was quite confusing. In response, RelativePath and BaseDirectory are now used instead.
  • The content of BaseDirectory now start with “? ” (question mark followed by space). This makes 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 where to put literal strings in quotes and where not.
  • 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 was 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 the structural filtering (for example, by specifying RelativePath 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 are used as queries and which bits 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 also introduced the capability to not just monitor the files, but also transport them between systems. This is achieved by specifying the attribute content-storage=”embedded”, such as in this example that defines 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 the result embedded inside the XoomXML file as Base64-encoded string.

Two new parameters in XoomParams.xml control the behaviour related to content transport:

  • Xoom.FileTweaky.AllowWriteToSpecialFolder.Windows (defaults to false) specifies whether Xoom will attempt to write to the Windows folder or not.
  • Xoom.FileTweaky.ContentStorage.Embedded.MaximumFileSize (defaults to 1048576, or 1Mb) specifies the maximum size (in bytes) of the file that Xoom will attempt to embed for transport.

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 associates 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.

RulesReport and ObjectivesReport have been rewritten from scratch. The new versions are much better able to represent the configuration of rule and objective types that weren’t encountered before and hence don’t have special handling. The reports also sport a more elegant look.

Several changes were made to StructureReport:

  • 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 less than 1,000 items; and
  • the information from each virtual collection (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 PowerShell CmdLet called Invoke-W6ServerStateOperation. The CmdLet is self-documenting in the standard PowerShell way, and allows all or specific servers to be locked, unlocked, started or stopped.

We 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 back to what it was, resulting in a single sync for all clients in which all updates are synchronised at once.

Other

  • The types where keys are references to items of other types (with again possibly nested references within their keys) are now handled correctly, whether or not those references are empty. Previously, those items’ keys weren’t fully interpreted, and hence the transport of those items could fail when different keys of the referenced items were used on different systems.
  • References can now be declared without explicit IDs (i.e. using default keys for whatever the targeted type happens to be) even when secondary keys are defined. This enables more concise declarations, and eliminates a common cause of errors in the knowledge base.
  • Reference interpretations now take optional attributes neutral-values (defaults to empty and -1) and neutral-values-separator (defaults to comma) as parameters. This makes the identification of cases where references shouldn’t be interpreted much cleaner and more powerful.
  • Fixed a bug that caused some templates, in particular ClickMobile “Web Administrative Settings” to be excluded from configuration along with client user settings. (The workaround was to include all client user settings, but that is obviously not an ideal situation.)
  • New interpretations and corrections to erroneous interpretations were added to the knowledge base, as well as a few additional convenience types.
  • Other minor bug fixes and improvements in error messages.