Relationships between Categories, Products, Variants Tables and Data Extraction Results

The Categories, Products, and Variants tables are an essential element of the Core of the Sales Layer PIM platform. There is a special relationship between them, which will  result in certain behaviour in the API export according to the configuration of connector parameters, and the values ​​of some parameters used in the HTTP request to the API web service.

This behavior will be affected as long as the tables for exporting data are active.

In the following image you can see the order of the hierarchy of the Sales Layer PIM tables, from which Sales Material tables are excluded as they are tables that are isolated from the hierarchy even if they include relationships to or from the primary tables.  

The results of API extraction will, by default, take into account the changes produced in the upper levels of hierarchy down to the lower levels. Even if there have been no changes at these levels. It will be the responsibility of the synchronization process that makes the API requests to decide how to handle the information received, which in many cases can simply be ignored.

For example, a change of status in a category that has ten associated products will generate an output of either modification (M), or deleted (D), on those products, even if there has been no direct change on them. Similarly, if each of these products has two variants associated with them, then the API will also send the changed information for the twenty associated variants.

The combinations follow an algorithm based on different factors that will ensure proper use in external synchronization processes such as online stores, web catalogs, etc.

The combination in the API requests of the parameters parents_category_tree, first_parent_leve and same_parent_variants, will allow for the altering of the behavior of the information sent by the API in the extraction processes (when synchronizing changes) to adapt this to the different requirements of external applications.

For example, before the deactivation of a category on the PIM side, imagine that its status changed from Visible to Invisible, the API will send the updated information of those associated products that should be deleted (D),  and of those that should be maintained (M), perhaps because they belong to another visible category at the same time. By these means of a synchronization process that makes requests to the API to update the visibility of the products in an online store, you can make the necessary updates within the mechanism of your store to update product visibility. All this is without it being necessary to alter the visibility of these products or variants on the side of the Sales Layer PIM. This will not affect other processes, or other possible online stores that were using the same products, perhaps under another brand.

Similarly, if for example we use enabled, the parameter first_parent_level in API requests, when modifying a product, for example its visibility, the API will also send as changed information, the information of its parent categories, so that an external synchronization process could know which categories to act on, for example to update the number of associated products on the front side of a website.

This is just an example of the flexibility and power for the exchange of information between the PIM solution and the Sales Layer API. You can choose the one that best suits your business model.

In most cases the default request configuration can ensure efficient and quick solutions, meeting the needs of a business model.