Skip to content

Resolved views

A resolved view is a simplified view of a PIM entity that is intended for consumption in an external system such as a webshop.

Simplified means that it is resolved to a specific segmentation.

PIM exposes the following views:

  • Published product views
  • Product hierarchy views
  • Attribute views
  • Attribute predefined values views
  • Brand views
  • Global list views

Requesting views

Resolved views are fetched via the api and when doing so the target segmentation must be passed in the request.

For example:

Suppose the external system is a webshop (Channel dimension) that operates in Denmark (Market dimension). The end user is using a tablet (Device dimension) and is physically located in Denmark (speaks Danish, so Translation culture dimension is da-DK). These four dimensions constitute the target segmentation which has a segmentation id and must be marked for view generation.

With this information, the frontend can request a view of say a product catalogue item targeted to that specific segmentation.

This way knowledge on how to resolve segmented values is kept internally in PIM and frontend doesn't need to understand PIM's complex internal data model.

Lifecycle of views

Resolved views for some entity only exist for a specific segmentation if the segmentation has its Auto publish to frontend flag set to true. This means that if the flag is disabled, any existing views related to that segmentation will be deleted.

Under the assumption that the flag is enabled, then views are created, updated, and deleted automatically as a result of internal events in PIM.

In general, views follow the lifecycle of the entities they represent, so in effect the views exist if the entities they represent exist.

The only exception to the rule above is published product views that have the additional requirement that the product catalogue item they represent must have state Published. If the state is changed to Unpublished then the view will be deleted even though the data in PIM isn't deleted.

In general, there's no need to manually manage or rebuild views, however, PIM does allow rebuilding the views on demand if needed for some reason.

Webhooks when views are created / generated

When views are created / rebuilt, webhooks are emitted. This makes it possible for the consuming application to maintain an index based on the resolved views by pushing delta updates based on the webhooks.

The following webhooks are related to resolved views:

  • PublishedProductViewsCreated
  • ProductHierarchyViewsCreated
  • AttributeViewsCreated
  • AttributePredefinedValuesViewsCreated
  • BrandViewsCreated
  • GlobalListViewsCreated

View maintenance

It is the responsibility of PIM to maintain resolved views. PIM does this via its internal domain event system and some background job processing.

Relevant PIM Job Runner recurring jobs are:

  • ForwardStoredDomainEvents
  • WatchAllGeneratedViewsAndModels
  • EnsureConsistencyOfGeneratedProductViews

PIM automatically calculates and schedules views for regeneration whenever it is needed. There is, however, also a PIM UI page where views can be scheduled for regeneration even though no changes are on the views: Administration --> Frontend Models. It should never be necessary to schedule views for regeneration, so it is not recommended to manually do so.

Structural version

The resolved views may evolve over time. Properties may be added and properties may be removed, or properties may be restructured.

The purpose of the structural version is to ensure that changes are visible and can be applied in a rolling manner where existing views are not necessarily rebuilt immediately, but consumers can use the structural version to make decisions on how to handle the view.

It is important to note that the resolved views are part of our API contract and follow our API versioning strategy, meaning that the same policy for deprecations and breaking changes applies.

Read more about the structural versions of each of the resolved view types of PIM here.