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 out 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 parameter Product.W6.Version.Number, which would contain 8030000 for Service Optimization 8.3. The following script results in a string value of the parameter:

    ${Product.W6.Version.Number}

whereas this interprets the parameter value as a number ( in this case, 8030000):

    #{Product.W6.Version.Number}

The character before the opening curly brace determines how the parameter is rendered: $ for strings, # for numbers. The difference between the two becomes apparent during comparison: if rendered as a string, 08 is smaller than 7 (in string comparison, 0 comes before 7), but if rendered as a number 08 is greater than 7.

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 (i.e. the default value) 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 or 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:

 1 <xm:parameter name="Product">
 2  <xm:parameter name="W6">
 3    <xm:parameter name="Objects">
 4      <xm:parameter name="Deployment">
 5        <xm:parameter name="ExcludedCollections">Server</xm:parameter>
 6        <xm:parameter name="ExcludedItems"/>
 7      </xm:parameter>
 8      <xm:parameter name="Retrieval">
 9        <xm:parameter name="ExcludedCollections">
10              Audit
11              AuditEngineer
12        </xm:parameter>
13        <xm:parameter name="ExcludedItems">
14              Setting[[Application]|Agents|AgentsManagerUI|]
15              Setting[[Application]|Agents|AgentsStatus
16              Setting[[Application]|Agents|AgentsTriggers
17              Setting[[Application]|Audit|AuditClient|ClientUI]
18              Setting[Zany Ants|Cache|
19        </xm:parameter>
20      </xm:parameter>
21    </xm:parameter>
22  </xm:parameter>
23</xm:parameter>

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

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 Xoom identity. For example, line 18 above excludes all Settings with Owner Zany Ants and Category Cache, regardless of what their SubCategory and Name may be.