- v1.0.0-latest-prod
Catalogs allow grouping of items under a common label. It is commonly used by merchandisers to represent how products are distributed across store and channels. For example, it is common to have catalogs by region as a vehicle for defining how stores in different localities are merchandised differently. This is often thought of as products, but can be any piece of data in the catalog service that is influenced by your catalog partitioning scheme.
Catalogs of type DIGITAL_CONTENT, referred to as "Profiles", are used to represent how content is distributed across the various channels. Profiles act as Catalogs behind the scenes, so you get all the same functionality when working with the Content Services (i.e. Content Items).
Catalogs are able to be arranged in a tree structure with inheritance from a base catalog(s) down to leaf catalogs. Such a structure allows for interesting composition and re-usability of concepts. The goal is to compose a set of catalogs that are assigned to a storefront and represent the data mix that is visible to customers of that store.
Changes made in a catalog at any level may participate in sandboxing workflows. Furthermore, when deployed, changes will trickle down the catalog inheritance tree as part of a process entitled Propagation. Propagation is aware of changes at a field level. A process called Collision Detection detects if a change for a field already exists in a more derived catalog and will stop propagation on that field change if found.
Catalog are generally considered to be ONLINE, PENDING or OFFLINE. ONLINE catalogs are always visible to both admin and storefront contexts. PENDING catalogs are only visible in the admin. OFFLINE catalog contents are visible to neither context.
Catalogs can inherit information from other catalogs as either a REFERENCE or a CUSTOMIZABLE. REFERENCE relationships are read-only in the new catalog. CUSTOMIZABLE relationships are fully editable.
Catalogs can be assigned to a storefront in one of two different modes: REFERENCE or CUSTOMIZABLE. REFERENCE assignments are visible, but read-only. CUSTOMIZABLE assignments are fully editable. All catalog assignments automatically inherit changes from parent catalogs.
The Application is used to drive catalog (and therefore merchandise) visibility during the shopping experience. It is useful to note that there are two tenant filtering concepts: catalog discrimination and application discrimination. Catalog discrimination is based on the catalogs visible to the current application. Application discrimination is more straightforward, and for those entities that are filtered on application rather than catalog, visibility can be based solely on the current application, and catalog is ignored.
The primary goal of the tenant service is to manage the creation and upkeep of Catalog and Application domain. This information is available to tooling (e.g. the admin tool) to drive catalog or application selection and is included during request interaction with other microservices that themselves manage catalog or application discriminated domain. See Data Requirements for more information on how catalogId and applicationId are utilized during microservice request calls for filtering and persistence.
It is important to note that in addition to managing the various tenant domain components, the Tenant service is also responsible for emitting events upon domain persistence that are consumed by other services that themselves manage catalog or application discriminated domain. These services are responsible for consuming the update events and syncing the tenant domain structure locally. As a result, copies of the structure kept by the Tenant service are duplicated in the backing datastore of every service that manages catalog or application discriminated domain.