Bootstrapping

Upon starting Bloomreach Experience Manager, its configuration management mechanism determines if and how repository data needs to be bootstrapped into the repository. The following logic is applied, controlled primarily by the value of the repo.bootstrap system property.

repo.bootstrap

If no repository data has been bootstrapped before (i.e. when Bloomreach Experience Manager starts up for the first time), configuration and content are bootstrapped irrespective of the repo.bootstrap system property.

If data has been bootstrapped into the repository before the current startup, the repo.bootstrap system property controls the bootstrapping. The following values are supported:

• false
  No bootstrapping is attempted. Incoming repository data changes are not processed, and the repository data is not changed.

• true
  Incoming repository data changes are being processed in order to update the repository data.
  For the configuration part of the repository, if Bloomreach Experience Manager detects a change between the new bootstrap data and the previously bootstrapped baseline, that change is written to the repository. Unchanged nodes and properties are left untouched, such that non-bootstrap-related changes to the configuration, which are not part of the new bootstrap data, can persist across bootstrapping. Think of changes made in the Console, or by means of the CMS’ settings management plugin for examples of non-bootstrap-related changes. If applying the bootstrap changes fails in any way, none of the bootstrap changes are persisted to the repository. Upon successfully updating the configuration part of the repository, the baseline configuration is updated.
  For the content part of the repository, upon successful bootstrapping of the configuration, new definitions are bootstrapped, and new content actions are processed.
  The system part of the repository is left untouched.
  For local development, Bloomreach Experience Manager’s project archetype sets the repo.bootstrap system property to true by default. You can manually override this setting by specifying a “-Drepo.bootstrap=[false|full]” argument when starting the CMS.

• full
  The configuration part of the repository is reset to the bootstrapped configuration. “Full” bootstrapping not only persists configuration changes to the repository, it also wipes out manual configuration changes which have not been added to the project’s bootstrap data. Upon a successful full bootstrap, the configuration part of the repository matches the recorded baseline configuration. The content and system parts of the repository are treated in the same way as if the repo.bootstrap system property would have been set to true.

Configuration Baseline

Note that after bootstrap processing, the configuration model that has just been applied is also stored in the repository as a configuration baseline. This baseline is used during future bootstrap processing to determine the previously-bootstrapped state and to detect differences with the new, incoming configuration model. This baseline can be referenced in a running repository at the path /hcm:hcm/hcm:baseline. The baseline includes a copy of all configuration Source YAML files, plus the hcm-module.yaml file, organized according to the group, project, and module structure defined by the Configuration Model. All data under /hcm:hcm should be considered a read-only reference. Any changes to this data outside of bootstrap processing may lead to problematic behavior.

Upgrading to Bloomreach Experience Manager 12

Existing repositories that were configured using the bootstrapping mechanism from versions of Bloomreach Experience Manager < 12 will not contain a configuration baseline. In this case, the first time Bloomreach Experience Manager is started, it will run a full bootstrap process, as specified above, regardless of the configuration setting.