Item/Variant/Product parent references
Background information
For an introduction to items variants and products see:
Datamodel - Repository
Types area
Custom area
General
In the hierarchy the product is at the top level, so it can't have a parent and has no subentity to store the reference. In 3 PPD the variant is on the level beneath products and according to that it has a subentity to store the reference to its parent product. At the lowest level there is the item. In 3PPD its parent is a variant and this parent reference is stored in the subentity Higher-level variant. In 2PPD the parent of an item is the product. This reference is stored in the subentity Higher-level product. In 2PPD mode the entity variant and the subentity Higher-level variant will be removed from the runtime repository whereas in 3PPD the Higher-level product item subentity remains in the repository.
Logical Keys
As you can see, in all subentites are the following four logical keys:
Reference type: Defines the relationship of this reference. In the parent context only the following three numbers may be logical key value
100 - Parent relation to a product of an item
110 - Parent relation to a product of a variant
120 - Parent relation to a variant of an item
Referenced object type: entityId of the parent object (product 1100; variant 1200)
Referenced variant/product SupplierAid
Referenced catalog: MASTER
All logical keys except the ReferencedSupplierAid are not editable and preset with a fix value (depending of the entity). The parent object can change but there is business logic making sure that each object has one parent at most. This means there is none or exactly one data set for all of the subentities discussed here.
Future Plans
We would like to simplify the business model for parent relationships. Instead of different subentities we have a single field containing the parent proxy in mind. If the changes took place, the way to implement what is described on this page is to use the RelationHandler. However, today we don't know where in the roadmap this feature might fit.
How to resolve all objects with a parent relationship to one of the objects in a given list
2 PPD: Resolve all assigned items for a list of products
EntityItemList entityItemList = new ArticlesOfProductsList( productProxies );EntityItem[] entityItems = entityItemList.toEntityItems( new NullProgressMonitor() );Revision: current revision context
Datasource: Master catalog
3 PPD: Resolve all assigned variants for a list of products
EntityItemList entityItemList = new VariantsOfProductsList( productProxies ); EntityItem[] entityItems = entityItemList.toEntityItems( new NullProgressMonitor() );Revision: current revision context
Datasource: Master catalog
3 PPD: Resolve all assigned items for a list of variants
EntityItemList entityItemList = new ArticlesOfVariantsList( variantProxies ); EntityItem[] entityItems = entityItemList.toEntityItems( new NullProgressMonitor() );Revision: current revision context
Datasource: Master catalog
How to resolve all parent objects for a list of objects
2 PPD: Resolve all parent products for a list of items
RepositoryService repositoryService = RepositoryComponent.getRepositoryService();Entity productEntity = repositoryService.getEntityByIdentifier( ProductCoreConst.ENTITY_PRODUCT );CatalogProxy currentCatalog = CatalogContext.getInstance().getCatalogProxy();ReportListModelQuery query = new ProductsByArticlesQuery( articleProxies, currentCatalog );EntityItemList productEntityItemList = query.toEntityItemList( productEntity );EntityItem[] products = productEntityItemList.toEntityItems( aProgressMonitor );Revision: HEAD
Note that ListModelQuery is deprecated and not part of the API. It's better to use an EntityReport. Unfortunately there is no EntityReport with this functionality ready to be used. However, this might change in the future!
3 PPD: Resolve all parent variants for a list of items
RepositoryService repositoryService = RepositoryComponent.getRepositoryService();Entity variantEntity = repositoryService.getEntityByIdentifier( VariantCoreConst.ENTITY_VARIANT );CatalogProxy currentCatalog = CatalogContext.getInstance().getCatalogProxy();ReportListModelQuery query = new VariantByArticleQuery( articleProxies, currentCatalog );EntityItemList variantEntityItemList = query.toEntityItemList( variantEntity );EntityItem[] variants = variantEntityItemList.toEntityItems( aProgressMonitor );Revision: HEAD
Note that ListModelQuery is deprecated and not part of the API. It's better to use an EntityReport. Unfortunately there is no EntityReport with this functionality ready to be used. However, this might change in the future!
3 PPD: Resolve all parent products for a list of variants
RepositoryService repositoryService = RepositoryComponent.getRepositoryService();Entity productEntity = repositoryService.getEntityByIdentifier( ProductCoreConst.ENTITY_PRODUCT );CatalogProxy currentCatalog = CatalogContext.getInstance().getCatalogProxy();ReportListModelQuery query = new ProductByVariantQuery( variantProxies, currentCatalog );EntityItemList productEntityItemList = query.toEntityItemList( productEntity);EntityItem[] productss = productEntityItemList.toEntityItems( aProgressMonitor );Revision: HEAD
Note that ListModelQuery is deprecated and not part of the API. It's better to use an EntityReport. Unfortunately there is no EntityReport with this functionality ready to be used. However, this might change in the future!
Creating a superordinate object
Exclude fields
The creation of a superordinate object is basically a clone operation using the merge.
For setting values, the command operators (like initializers, validators and setters) of the product are used. Therefore the item is internally handled like a product (in 2PPD).
This means if you want to exclude certain fields from this process you have to set the field of the product (as example of the superordinate object) to cloneable = false. It's clonable and not mergeable because the merge uses a ClonePredicate in this case, which is checking the cloneable attribute of the fields.