| What's new / Release notes | |
This major new release introduces first-class support for Windows PowerShell scripting to Xoom, and with it a new product, Service Optimization Tuning Toolkit. This exciting development brings a host of new scripting and automation capabilities to configuration management, as well as major improvements to the way ClickSchedule configuration can be tuned and maintained, with direct operational impact.
Windows PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-line shell and associated scripting language built on the .NET Framework. Due to its range of capabilities and widespread use, a lot of systems administrators will already be familiar with Windows PowerShell, and it is therefore a natural way of enabling Xoom automation capabilities on Microsoft Windows systems.
In order for Service Optimization to correctly interpret the references to Objects within SXP messages, any referenced Object needs to have an entry in Object References, and also an Index containing those same Properties in the same order. These Indexes are sometimes missing, and Service Optimization does not contain a mechanism to verify whether they are there, or to create them when they aren’t. The result of such missing Indexes is unpredictable errors that only become visible quite late in the project, or even in production, when data of sufficient richness becomes available.
Given a XoomXML file containing Service Optimization structure (i.e. Scheme and an Object Reference setting), this transformation creates a XoomXML file that will, on deployment, create the Indexes that are required for proper interpretation of all the defined Object References that are currently missing from configuration.
The transformation also takes an optional parameter IncludeExistingIndexes which, if specified, will cause the transformation to include all Indexes that are required by existing Object References, regardless of whether they are currently missing or not.
This new report creates a GraphML document intended for visualisation of dependencies between specified Collections in Service Optimization Scheme. The resulting file can be loaded into yEd or any other suitable tool that supports GraphML in order to produce beautiful visualisations of Scheme dependencies. This is extremely useful when trying to understand what Objects constitute configuration and master data, and which Collections are effectively transactional due to the nature of their dependencies: this last point is essential in migration and upgrade scenarios.
Due to the potential extreme complexity of the resulting graph, the report expects a parameter called IncludedSourceCollections. The parameter is a string starting and ending with a space, and containing all Collections that should be included in the graph as part of the core group from which dependencies will be calculated. (The dependent Collections will also be included in the graph, but they won’t be considered to be sources of further references.) For example, if all dependencies of District, Region, Group and Setting Collections are to be visualised, then the parameter should be ” District Region Group Setting “, with each Collection name preceded and followed by a space.
Another version of the transformation with fewer capabilities but better support for scripting using freely available tools is also provided. This transformation is called SchemeDependenciesDot.xsl, and produces a dot file used by Graphviz graph visualisation software.
This is a new report based on the Scheme Customisations report report. In addition to everything that is in that report, this report adds two sections above Scheme customisations. The first lists all Collections in the Scheme, including their ID, Collection type and storage type, Object References (where they exist) and Property definitions. The second lists all configurations, including their Collection type, storage type, convertor ProgID and Property definitions.
This report is currently work in progress and will receive significant revisions in the future versions. However, we decided to include it with this release as even in its current form it is extremely useful.
Transformations that produce XoomXML with xoom:set special form have been modified to emit select instead of xpathattributes, as those are more descriptive and better aligned with other XML technologies such as XSLT. The two attributes are currently equivalent, but xpath will be deprecated in the future.
Rules report now also lists Rule types, not just Rule categories.
Product.W6.Objects.EncryptClickContactNotificationSmtpPassword: If true (default), the notification SMTP password (Setting[[Application]|ClickContact|NotificationSMTPPassword|]/Body) in ClickForecast will be encrypted.
Product.W6.Objects.EncryptClickExpressImportAgentPassword: If true (default), the password used by ClickExpress Import agent while calling SXPClickExpressImportTool (Setting[[Application]|Agent|ClickExpress Import|*]/Body/SXPClickExpressImportTool/Password) will be encrypted.
The installer now accepts an optional parameter DISABLESERVICESTART (defaults to 0) which can be used to successfully complete Xoom installation without attempting to start the Xoom service. This is very useful when Xoom service can’t be started for an unknown reason: it is much easier to obtain detailed logging for an installed version of Xoom than from repeatedly running the installer.