FAS 8.4 Upgrade Notes

Introduction

FAS 8.4 APIs are compatible with the previous release.

This release introduces the following major changes:

• Users can define rules which span multiple markets or channels (Beta). Requires additional configuration (multi-site.xml).
• Users can operate in a local time zone for the Business Manager. Requires additional configuration (system.xml).

Multi-market rules

Customers model a multi-market or multi-channel business one of two ways: through multiple universes or using one universe with multiple market-specific attributes.

For integrations that rely on the single universe model, FAS 8.4 makes it possible to specify facets, ranking attributes and rankings that work across multiple markets to channels.

To enable this feature, the mapping of market-related attributes must be done in a new configuration file: multi-site.xml. By default, this file is not included in the site configuration.

FAS 8.4 supports two mapping strategies for this feature: by locale name or by market selector attribute.

Mapping by locale name

In this strategy, market-specific attributes get the respective locale's country name as a suffix. For example, price_gb reflects a price in the UK, while price_ie reflects a price in Ireland.

When mapping by locale name, multi-site.xml has the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <strategy>locale</strategy>
</config>

When this strategy is applied, the Business Manager displays market-specific attributes such as price_gb and price_ie as one template attribute (for example, price_{locale}). Users will be able to set up a facet, a ranking cocktail, or a ranking using the attribute template. FAS substitutes the respective attribute when processing queries when a locale is specified.

Mapping by the market selector attribute

In this strategy, market-specific attributes must contain a suffix corresponding to a special market selector attribute. For example, price_uk reflects a price in the UK, while price_ie reflects a price for Ireland. This strategy also requires that all queries have a special attribute (for example, market) that selects the actual market.

When mapping by market selector, multi-site.xml has the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <strategy>attribute</strategy>
    <attribute>
        <name>market</name>
        <default-value>uk</default-value>
    </attribute>
</config>

When this strategy is applied, the Business Manager displays market-specific attributes such as price_uk and price_ie as one template attribute (for example, price_{market}). Users will be able to set up a facet, a ranking cocktail, or a ranking using the attribute template. FAS substitutes the respective attribute when processing queries when the respective market selector attribute is passed in the query. FAS defaults to the specified default-value market if no market selector attribute is passed.

Future FAS versions will support more strategies to define market-specific attributes. Thus, the multi-market configuration file is subject to change. 

Local time zone in Business Manager

Users can now configure the Business Manager to use their preferred local time zone. Users can only set one time zone; multiple time zones are not supported.

Configuring the preferred time zone

The preferred time zone can be set in system.xml by adding the following parameter: /com/fredhopper/bm@time-zone-region-id

The parameter value must be valid from the standard list of time zones (examples: Australia/Sydney, CET, Europe/Berlin, etc.).

The Business Manager still operates in the time zone of a server (UTC for all cloud instances) by default.

All timestamps which appear in filenames are specified in UTC, disregarding the time zone setting.

Restrictions

1. The legacy date triggers do not support the preferred time zone. You need to use date-time triggers to benefit from this feature.
2. When the preferred time zone is specified (and FAS is restarted), all timestamps of the rules, rule versions, publications and date-time triggers will be adjusted automatically.

Rules with date-time triggers using a schedule that spans the day (for example, 11 PM---2 AM) need to be re-saved and re-published after specifying a preferred time zone. 

The preferred time zone is reflected in the expressions of the date-time triggers. This might affect distributed merchandising teams who operate cross-regionally (across multiple time zones).

Changes in Search behaviour

Restricting the search string length

Previously FAS had no explicit restrictions on the length of the search string. Search strings cannot exceed 20 tokens or 150 characters for stability reasons. FAS returns an error in the response if one of these restrictions is breached. However, the response is still rendered.

The restriction parameters can be tweaked in system.xml:

/com/fredhopper/search/validator@max-query-tokens (20 by default)

/com/fredhopper/search/validator@max-query-length (150 by default)

The search string is split into tokens for validation by using whitespace character(s) as separators. Whitespace characters are the space, tabulation HT, linefeed LF, vertical tabulation, form feed FF, and carriage return CR.

Tweaking the weight of relational search

 In some cases, FAS has a default selection expressed like a target. For example:

<universe-ref universe="catalog01related" ref-attribute="primary_id">
    <selection-criterium field-name="is_available" display-name="is_available" skey="is_available" universe="catalog01related"/>
</universe-ref>

In this example, is_available is an integer field, and only a few values are possible. A relational search field for product colour is also configured. When a user looks for products of a specific colour, the system takes into account both their colour and availability when selecting a variant to show. By default, the system prefers available products, so products with different colours might be returned.

FAS 8.4 introduces a system.xml setting that influences this algorithm: /com/fredhopper/search/relational@relational-target-weight (1.0 by default).

If you set a sufficiently large value (for example, 1000000.0), the system will start 'preferring' product colour to product availability.