FAS 19.1 Upgrade Notes

FAS 19.1 APIs are compatible with the previous release.

This release introduces the following major changes:

• Terminology: The Business Manager has been renamed to Merchandising Studio.
• All configuration publications are done via Zookeeper instead of the traditional syncserver/syncclient mechanism if it runs with CRU.
• CRU exposes prepublished synonyms via REST API. They work in sync with the Merchandising Studio. So, if a synonym gets updated via REST API, the change will be reflected in the Studio and vice versa.

New DA & JDK

FAS 19.1 makes use of the new Deployment Agent 2.2.0.

The cloud version is also expected to run on the latest available JDK 8: 1.8u201.

FAS/CRU interactions

If CRU is enabled, two key features of FAS 19.1 (Synonym REST API and instant configuration publications) become available. Generally, CRU and FAS communicate via REST API.

Another component which plays its role when CRU is on is an Apache Zookeeper instance. It runs on the Indexer server and helps synchronise the configuration between FAS Indexer, FAS live, and CRU.

Synonyms REST API

CRU 19.1 has Synonyms REST API, allowing reading and updating synonyms on the prepublished environment. The endpoints resemble other configuration entity endpoints in FAS. The interactive documentation can be provided upon request.

Instant configuration publications

When CRU is on, all configuration publications done in the Merchandising Studio get synchronised to FAS and CRU via Zookeeper. Because of its swift notification system, it now takes a few seconds (instead of minutes) to apply the configuration change to the live environment. This table summarises what gets synchronised to where.

Last publication on a CRU/live node

FAS live node needs to know the latest read publication to restore its state on a restart.

In the previous FAS 8 versions, FAS live nodes used to store this info in the config/entities/import.properties file. 

Now, if CRU is on, this info is stored in the config/configData.properties file because the config/entities directory is not getting created anymore. 

CRU uses the same mechanism, so the file name is the same. Please note that the file is transient and does not get stored in the configuration capture.

Multi-market rules

Mapping by custom triggers

Since FAS 19.1, it is possible to resolve a conflation attribute via a custom trigger. It can be done by adding a specific resolver to a custom resolution strategy.

Example:

<config>
    <strategy type="custom">
        <name>markets</name>
        <default-map-value>en_gb</default-map-value>
        <values>
            <entry key="en_gb">en_gb</entry>
            <entry key="en_ie">en_ie</entry>
        </values>
        <resolver type="custom-trigger">
            <custom-trigger name="markets_123" default-value="en_gb" />
        </resolver>
    </strategy>
</config>

In this case, if a customer has attributes price_en_gb and price_en_ie, they will be conflated to the attribute price_{markets}. To provide resolution to a concrete attribute, a customer would need to define a custom trigger with the parameter name markets_123 and values en_gb and en_ie. Based on an incoming query's markets_123 parameter, the resolution will happen. If the parameter is not provided, the attribute will be resolved using the default value, i.e. the result will be price_en_gb.

Changes in the response

Every FAS response now contains its unique identifier "rid".

Example:

<page xmlns="http://ns.fredhopper.com/XML/output/6.1.0" qid="237" rid="cf923320-1afe-4b2d-8851-2cbca4ee254d">

Changes in the behaviour

Logging errors by SOAP endpoint

Previously some errors caused by requests via SOAP were not logged. Now, this is fixed, and possible exceptions get logged in fredhopper.log.

System publications history cleanup

FAS deletes all system settings publications older than max at the start of the indexer node. The possible restoration age is 30 days by default, which should make configuration captures considerably smaller.

Indexing time for large catalogs

Indexing time for the customers with large catalogs (millions of items) is expected to be significantly improved, so their re-index should become faster.

Changes in default system settings (system.xml)

The /com/fredhopper/SyncServer/ReplicationItems node now contains a new entry:

<!-- Replication items which will be sync via Zookeeper if CRU is enabled.
Patterns must match to concatenated "path", "/" and "name-pattern" of entries
described in the "ReplicationItems" section here -->
<node name="ReplicationItemsToExcludeForCru">
    <map>
        <entry key="pattern" value="business/business.xml, business/trigger-types.xml, business/i18n/localization.*.xml, business/scopes/xml/.*\.xml, business/entities/.*\.xml" />
    </map>
</node>

This entry describes files which do not get synchronised via SyncServer when CRU is on. We disable the synchronisation of all configurations because it is now synchronised via Zookeeper. Having two synchronisation mechanisms working in parallel could bring the system to an inconsistent state.