FAS 8.1 Upgrade Notes – Rezolve Ai Support Portal

Introduction

FAS 8 brings a concept of scopes. They will allow the creation of more flexible configuration structures and avoid duplication. A scope is a container for triggered entities and synonyms. A scope itself can have triggers. Scopes can be nested. In this case, a child scope inherits all the triggers of its parents. Respectively a triggered entity (e.g. a ranking) inherits triggers of all its parent scopes. A root scope is just a container and does not have any triggers.

Another major concept of this version is fine-grained publication: it is now possible to publish an arbitrary set of trigger-based entities and synonyms. The review/approval workflow has been enhanced as well.

Business Manager

Scopes

The ability to manage a scope structure (System -> Management -> Scopes Manager) has been introduced.
To remain backwards compatible with the previous universe-locale-based configuration, Universe and Locale triggers have been introduced. A universe trigger is responsible for matching a universe which comes from a request. A locale trigger is responsible for matching a locale. It is more flexible because it allows a wildcard for a language or the country. So, it is possible to create a locale trigger for all locales with the English language or for all languages in Belgium.
Permissions functionality became more flexible: access is assigned to a role per scope (and all its children) and entity type. For instance, users of a specific role can be responsible only for campaigns and rankings for webshops in the Netherlands. They would not be able to influence other scopes. There is a special option for those users to see campaigns/rankings for parent scopes (if any). Please note that if a role has access to entities in a scope, this implies both read and write privileges.
The universe/locale selector is gone in all BM pages except those under the System tab. There is a button to select scopes to show entities from. So, a user can work with all their scopes simultaneously or with any of their subsets.
It is possible to sort entities by their scope. In this case, they will be sorted similarly to their triggering order. The exception is Facets - we need to reverse the sorting order to achieve the result similar to preview pages.
It is possible to move an entity to the scopes hierarchy by changing its parent scope. In this case, all its inherited triggers will be replaced by ones from a new chain of parents.
It is possible to copy an entity to other scopes. In this case, all its inherited triggers will be replaced by ones from a new chain of parents as well.
It is possible to re-order scopes on the same level of the hierarchy. It will impact the order in which the entities will be triggered/shown.
It is only possible to delete a bare scope (if it doesn't contain any entities).

Publication

Logically every entity gets two status fields: live status and publication status. From the live status perspective, an entity can be ALIVE, ARCHIVED, DELETED or WIPED. Only alive entities can trigger.
From the publication perspective, an entity can be in EDITING (so it is not synchronised on an indexer and live nodes), WAITING_FOR_PUBLICATION and PUBLISHED (synchronised) state.
A user can send one or more entities in the EDITING state to publication. After that, those entities will be read-only until they get published or rejected (cancelled).
A user can cancel the publishing of any entity (for instance, if they notice a mistake in a campaign's title). In this case, the entity becomes editable again and can be sent to publication later.
The entity status column now reflects an entity's publication status and shows whether an entity is enabled.
A role with publishing permission can access all scopes or their sub-set. For instance, one can be allowed to publish entities for webshops in the Netherlands.
A new tab, 'Publication', is shown if a user's role has publishing permissions. The user can see all entities sent for publication and their status. A user can select some or all these entities and publish them by creating a publication set. The user can also cancel (reject) publications of any entity (for example, because there has been a mistake).
We keep the changes history for every trigger-based entity (or synonyms). As soon as publishing is done, its snapshot is stored in its history for each published version. It will be possible to restore this concrete version later. The entity itself obtains PUBLISHED status and can be modified further.
It is possible to see the history of the publications made. For every publishing set, it is possible to see its content (on the level of entities).
- Since FAS 8.1.12, the history size is bound to a maximum of 100 entries and a maximum of 30 days (so, if there were more publications during the last 30 days, only the last 100 will be visible)
It is possible to restore the system's state up to a certain publishing state. In this case, the system will 'replay back' the selected set and all sets published after it. So, the indexer will obtain a state similar to the one just before publishing the set a user restores. Note: Before FAS 8.1.4, reverting will lose all the unpublished changes.
System pages are considered to be one publishable entity. It is possible to send them to publication. In this case, all the system settings become read-only until they get published or rejected.
Users, roles and permissions do not get synchronised between indexer and live nodes.

Date time trigger

The date trigger gets replaced by a date-time one. The new trigger can specify whether an entity should be triggered more flexibly, with up to a minute precision.

Password hashing

Starting with FAS 8.1.10, you can choose to hash the users' passwords, preventing anyone from knowing the passwords, as they are not stored as plain text. This is optional and must be explicitly enabled in system.xml: bizusermanagement/@hash-passwords must be set to "true".

When the parameter is set, you need to run a full reindex for the passwords to be hashed. This is an irreversible operation - once the passwords are hashed there is no way for anyone to know what they are, and they will remain hashed even if hashing is disabled in system.xml.

The passwords are hashed using the Bcrypt algorithm. It allows setting a variable cost - how much time is needed to try a password. Generally, a higher value is more secure, but it will also take more time to log in to FAS. This can be configured with bizusermanagement/@bcrypt-cost in system.xml. It has a default value of 11, and it is the algorithm's iteration count as a power of two. The cost of 10 will be twice as fast as 11, 12 will be twice as slow, etc. If login is too slow, you may make it quicker by using a smaller value.

Migration

Migration from FAS 7.5 is supposed to be automated and transparent. It is done once, during the upgrade from 7.5 to 8.1.
The initial scopes structure is created after the universes and locales the system. So, universe scopes would become the first level of the hierarchy, and every universe scope will have sub-scopes for all the locales the system has. Each universe/locale scope will have a respective universe/locale trigger so that the initial experience will be exactly like in FAS 7.5. Please note that secondary universes with no entities will not be converted to scopes.
The migration process provides the best effort to make permission assignment very similar to the one in 7.5. After the migration, the permission assignment can be tweaked.
The migration process ensures entities have unique identifiers across the system (which was not the case in 7.5)
A new trigger type (date-time) must be declared:
```
<trigger-type basetype="date" url-param="date_time" name="date-time" />
```
It is possible to keep the old (date) trigger behaviour. Instead of declaring a new trigger type, a special setting needs to be provided: com/fredhopper/targeting/@legacy-date-trigger-behavior in system.xml should be set to true.
For the migration to produce a consistent result, it is necessary to publish the configuration in FAS 7.5 right before the upgrade to FAS 8.1.
When entities with the same Start and End date are created with the legacy date trigger, they will still have the old format written without the time component (even though the BM shows the same date and time - 12.00 AM). This means the entity will trigger for the whole date period. If the entity gets saved, the time component is attached, and then the entity will not be triggered, as both the start and end date (with time attached) are the same and included in the formatting.

Deployment

FAS 8 requires Oracle Java 8 update 45 or later (see Install Java for more information).

FAS 8 requires the Fredhopper Deployment Agent version 2.0.3 or later.

FAS stores triggered entities and synonyms in a binary database instead of business.xml and localisation files. Therefore modification of the entities is possible only via REST API.

Old configuration REST API will continue working, providing there is no change in the scope structure after a migration (i.e. only universe/locale scopes). We are working on the next version of REST API.

An indexer and live node will not contain the same configuration replica anymore. A live node will know only the entities which can trigger (ALIVE). The indexer contains all the entities, their history, publication set history, roles, users and permissions.