Introduction
FAS 21.2 is compatible with the previous release.
Changes in the query language
In 21.2, we add two additional parameters that would help reduce response size. They are extensions to the fh_suppress parameter capability.
| Parameter value | Semantics | Example |
|---|---|---|
| campaigns:url-params | suppresses rendering all link tags for campaigns | &fh_suppress=campaigns:url-params |
| items:url-params | suppresses rendering the link tag for items in the "lister" page | &fh_suppress=items:url-params |
New configuration REST APIs
Publication API
The Publication API enhances the existing Configuration API used to create and manage business rules.
This API has been extended to include publication capabilities, so the Configuration API now covers the entire lifecycle of a rule, allowing for powerful automation.
FAS 21.2 adds the ability to create publication sets via REST API.
Service for managing published rules
| URL | Method | Request/Params | Response | Description |
|---|---|---|---|---|
| /publications/publicationQueue?scope_id=s1&scope_id=s2 | GET | scope_id: filter publications by scope id, multiple ids can be passed | Publications as XML/JSON | List all entities waiting for publication in the queue. |
| /publications/publicationQueue/id | GET | id: id of an entity waiting in the publication queue | PublicationEntry as XML/JSON | Returns an individual entity waiting for publication in the queue. |
| /publications/publicationQueue | POST | Publications as XML/JSON | PublicationResults as XML/JSON | Sends list of entities to the publication queue. |
| /publications/publicationQueue | DELETE | Publications as XML/JSON | PublicationResults as XML/JSON | Removes list of entities from the publication queue. |
Service for managing published rules
| URL | Method | Request/Params | Response | Description |
|---|---|---|---|---|
| /publications/publicationSet | GET | <empty> | PublicationSets as XML/JSON | Returns all existing publication sets in the system. |
| /publications/publicationSet/<id> | GET | id: id of publication set | Publications as XML/JSON | Returns a publication set found by id with it's entries. |
| /publications/publicationSet | POST | PublicationSetInfo as XML/JSON | <empty> Location header pointing to the created set |
Creates a publication set with a given name and given publication ids from the publication queue. |
| /publications/publicationSet/<id>/revert | POST | id: id of publication set | PublicationResults as XML/JSON | Reverts a publication set and brings the system back to the state previous to their publication. Any local changes of all previously published entities made after their last publication will be saved as a draft version and are accessible from the entity history window for inspection or restoration. All publication sets done after this one will be reverted as well. |
Multi-Site API
The new Multi-Site API alleviates some of the pain points currently faced when configuring multi-site strategies.
The API will be able to retrieve current multi-site configurations, perform CRUD operations on existing strategies and automatically reload the configuration. This reduces the manual effort required when making configuration changes and the risk of error as some actions can be automated. It allows easier access to multi-site files, making the integration process easier, removes the requirement
of reindexing and reduces the onboarding time for partners.
API usage:
| URL | Method | Request | Response | Response Codes |
|---|---|---|---|---|
| /multi-site | GET | <empty> | The full multi-site configuration. It has a main tag multi-site-config containing multiple strategy tags. | 200 OK - always |
| /multis-site/<name> | GET | <empty> | Returns a single strategy by its name. | 200 OK - if strategy found 404 NOT FOUND - if the strategy is not found |
| /multi-site | POST | A single strategy | <empty> | 201 CREATED - if it's a new strategy 204 NO CONTENT - if it's an existing strategy 400 BAD REQUEST - if the strategy is invalid |
| /multis-site/<name> | DELETE | <empty> | <empty> | 204 NO CONTENT - if deleted 400 BAD REQUEST - if the strategy is in use and can't be deleted 404 NOT FOUND - if the strategy is not found |
Changes in default system settings (system.xml)
FHR Tracking
FAS 21.2 allow tracking of events in the Merchandising Studio. It is planned for future versions of this configuration to be rolled out automatically and not need a change in the system configuration.
For now, the node /com/fredhopper/bm/analytics should be added to system.xml to enable the feature:
<node name="com"> <map /> <node name="fredhopper"> <map /> <node name="bm"> <map /> <node name="analytics"> <map> <!-- If analytics should be enabled. True or False, default value is false --> <entry key="analytics-enabled" value="true" /> <!-- API Key of the Amplitude project in which events will be sent --> <entry key="amplitude-api-key" value="da44ccd9c06d7c20771ca6dcecfd37a6" /> <!-- The id of the container created in Google Tag Manager --> <entry key="gtm-container-id" value="GTM-WPG45XP" /> </map> </node> </node> </node>
As of FAS 21.2.1, the above values can be read from the environment (passed by the controller).
- AMPLITUDE_API_KEY: One for Amplitude API key
- GTM_CONTAINER_ID: One for GTM container ID
Caching of expensive float computations
In FAS 21.2.4, you can modify the size of the FloatUtils cache - this can decrease indexing time for large repetitive datasets. For example, repetitive in with multiple similar variants data.
It should be used with caution, though the evaluation should be done for the respective dataset before usage in production. Default values are respectively 0 and 0, so the cache is not used by default.
<node name="com"> <map /> <node name="fredhopper"> <map /> <node name="util"> <map /> <node name="FloatUtils"> <map> <!-- Caches to use for converting scaled/unscaled values. This may help some customers, but it showed performance degradation so it's turned off by default (set to 0). The previous values used that you can try, are scaled: 500000, unscaled: 50000. --> <entry key="scaled-cache-size" value="500000"/> <entry key="unscaled-cache-size" value="50000"/> </map> </node> </node> </node>
Memory usage reduction via value deduplication
Depending on the dataset, the data structure that stores localised attribute values (aka multi-language values), contains duplicate strings. These duplicates are attribute values that are equal across different locales for the same attribute.
AS of FAS 21.2.4, those strings can be deduplicated by using the same instance (that is, by interning strings).
The deduplication optimisation can be disabled by a feature flag, as it could slightly increase memory usage in some specific datasets.
<node name="com"> <map /> <node name="fredhopper"> <map /> <node name="attribute"> <map /> <node name="AttributeType"> <map> <entry key="use-value-deduplication" value="true" /> </map> </node> </node> </node>
The default value is true.
Changes in the folder structure
Custom dictionary files
Moved out dictionaries/override and dictionaries/extra folder out from /etc to /config folder so that decomposition dictionaries could be added easier to FAS. The semantics of these folders are:
- dictionaries/override - if dictionary files are available here, this folder will be used to read dictionaries instead of what is located under /etc/dictionaries/default (this is shipped by default from FAS). So the purpose of this folder is to override any default dictionaries provided by FAS.
- dictionaries/extra - this folder is always consulted, so any additional dictionaries should be put here.
For the changes to take effect 'Linguistic analyzers' page under the System tab needs to be re-saved (this will reload the respective business.xml configuration).
As of FAS 21.2.5, the above structure is also part of the versioning mechanism of FAS. Dictionaries can be added through the controller's unpublished-indexer-config folder for the customer's environment, keeping the same structure:
- unpublished-indexer-config/dictionaries/extra
- unpublished-indexer-config/dictionaries/override
After reindex, dictionaries are propagated to the indexer node. From there, they can be published to the live nodes.
Note: To take effect, the dictionaries MUST be part of the indexing process, hence should be present on the indexer while indexing.
Otherwise, just added to the pipeline afterwards, they will not take full effect (will not augment the search index as expected).
Migration
Migrating from FAS 21.1 to 21.2 requires no specific steps.
Kommentare
0 Kommentare
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.