We are happy to announce the release of Xoom 3.10.6. This release brings two notable new features: transition to ZanyScript 2 in knowledge base processing, and the introduction of a much more powerful mechanism for filtering collections and items that shouldn’t be retrieved or deployed by Xoom.

ZanyScript 2

ZanyScript 2 introduces a richer type system and more expressive syntax for expressing conditions in the knowledge base. A more extensive post will be written on the subject in the near future, so we’ll only take a look at a few examples here.

ZanyScript 1 supports two value types for the interpretation of parameters: strings and numbers. Let’s take a look at an example of parameter Product.W6.Version.Number, which would contain 8030000 for Service Optimization 8.3.

${Product.W6.Version.Number}

results in a string value of the parameter, whereas

#{Product.W6.Version.Number}

interprets the parameter value as a number 8030000.

The determinant of how the parameter should be interpreted is the character before the opening curly brace: $ for strings, # for numbers. The type of the interpretation is important for comparison: if compared as a string, 08 is smaller than 7 (in string comparison, 0 comes before 7), but numerically it’s greater.

ZanyScript 2 introduces two additional prefixes: ? for Boolean, and % for version number. For example, if Product.W6.ServerVersion is 8.3.0, then

%{Product.W6.ServerVersion} ge 8.1.7

returns true, because version 8.3 is greater than 8.1.7. (Version literals are also new, so 8.1.7 above will be interpreted as a version number.)

Another new feature in ZanyScript 2 are default values. While ZanyScript 1 would report an error if a parameter specified in the condition doesn’t exist, ZanyScript 2 allows the default value to be provided in case the parameter hasn’t been set. For example:

?{Product.W6.Objects.EncryptAuditConnectionString} ?? true

will result in true if parameter Product.W6.Objects.EncryptAuditConnectionString hasn’t been set. If it has, its value will be interpreted as a Boolean. An error will be reported if the parameter is set, but its value can’t be interpreted as a Boolean.

Filtering collections and items

Before this release, Xoom did not provide a general means to control which collections and items get retrieved from Service Optimization, and which collections and items get deployed.

Two parameters existed that dealt with two specific types of items: Product.W6.Objects.IncludeAgentsStatusSettings and Product.W6.Objects.IncludeAgentsTriggersSettings controlled whether two types of settings, agent statuses and agent triggers (both effectively transactional and intended for synchronisation between Service Optimization servers), should be included in the configuration representation or not. Both defaulted to false.

In this release, we are introducing a more comprehensive mechanism for managing these exclusions. Here is the relevant part of XoomParams.xml:

<xm:parameter name="Product">
  <xm:parameter name="W6">
    <xm:parameter name="Objects">
      <xm:parameter name="Deployment">
        <xm:parameter name="ExcludedCollections">Server</xm:parameter>
        <xm:parameter name="ExcludedItems"/>
      </xm:parameter>
      <xm:parameter name="Retrieval">
        <xm:parameter name="ExcludedCollections">
              Audit
              AuditEngineer
        </xm:parameter>
        <xm:parameter name="ExcludedItems">
              Setting[[Application]|Agents|AgentsManagerUI|]
              Setting[[Application]|Agents|AgentsStatus
              Setting[[Application]|Agents|AgentsTriggers
              Setting[[Application]|Audit|AuditClient|ClientUI]
              Setting[Zany Ants|Cache|
        </xm:parameter>
      </xm:parameter>
    </xm:parameter>
  </xm:parameter>
</xm:parameter>

Exclusions for retrieval (lines 8-20) and deployment (lines 4-7) are defined separately. This is desirable because we want to include certain items in the configuration representation for reference management and configuration versioning, but we do not want to deploy them. Servers are a good example of that.

For each side of the transport, we also separately specify collections and individual items. In the example above, we have the following:

• Line 5: A collection named Server is excluded from deployment. As mentioned above, we probably never want to deploy server changes.
• Line 6: No individual items are currently excluded from deployment in this example. Servers will already have been covered by the collection exclusion above.
• Lines 9-12: Collections Audit and AuditEngineers will not be retrieved. They are large and contain transactional data.
• Lines 13-19: The following settings will be excluded due to their transactional nature: agents manager UI settings (there will often be multiple such settings with the same identity), agent statuses, agent triggers, audit client UI. Zany Ants cache settings will also be excluded by default because they are intended for synchronisation between different Service Optimization servers connected to the same environment.

When specifying exclusions, different names can be separated by a comma, a semicolon or a new line character. The spaces before and after the name are also removed. For example, if parameter Product.W6.Objects.Retrieval.ExcludedCollections had a value Audit, AuditEngineer, the effect would be exactly the same as lines 9-12 above.

Collections are excluded based on the exact name match, while items are excluded by matching the beginning of their Xoom ID. For example, line 18 above excludes all settings with Owner Zany Ants and Category Cache, regardless of what their SubCategory and Name may be.