Relaciones entre las tablas de Categorías, Productos y Variantes y sus resultados de extracción de datos en la API

Las tablas de Categorías, Productos y Variantes son un elemento esencial de la plataforma PIM de Sales Layer. Existe una relación especial entre ellas, que va a producir un comportamiento de expulsión del API acorde a la configuración de parámetros del conector, y a los valores de algunos de los parámetros utilizados en la petición HTTP al servicio web del API.

Este comportamiento afectará siempre y cuando las tablas se encuentren activas para expulsión de datos. 

En la siguiente gráfica se puede ver el orden en la jerarquía de tablas de Sales Layer PIM, del que se excluyen las posibles tablas de Material de Venta, tablas que se encuentran aisladas de la jerarquía aun cuando incluyan relaciones hacia o desde las tablas primarias.  

Los resultados de extracción de la API por defecto van a tomar en cuenta en un instante de tiempo X, y por tanto arrastrar los cambios producidos en los niveles superiores de jerarquía hasta los niveles inferiores. Aun cuando no se hayan producido cambios en estos niveles. Será responsabilidad del proceso de sincronización que realiza las peticiones a la API decidir cómo tratar la información recibida, que en muchos casos simplemente podrá ser ignorada.

Por ejemplo, un cambio de estado en una categoría que tiene asociados diez productos generará una salida bien de modificación (M), bien de eliminación (D), sobre dichos productos, aun cuando no se haya producido un cambio directo sobre ellos. Del mismo modo, si cada uno de esos productos tiene asociadas dos variantes, la API enviará también información de cambios para las veinte variantes asociadas.

Las combinaciones siguen un algoritmo basado en diferentes factores que permitirán garantizar una correcta utilización en los procesos de sincronización externos como tiendas online, catálogos web, etc.

La combinación en las peticiones a la API de los parámetros parents_category_tree , first_parent_level y same_parent_variants , van a permitir alterar el comportamiento de la información enviada por la API en los procesos de extracción (en las fases de sincronización de cambios) para adaptar esta a los diferentes requerimientos de aplicaciones externas.

Por ejemplo, ante la desactivación de una categoría en el lado del PIM, supongamos un cambio de estado de Visible a Invisible, la API enviará información actualizada de aquellos productos asociados que debieran ser eliminados (D), de aquellos que deberían mantenerse (M), quizás porque pertenecen al mismo tiempo a otra categoría visible. De esta forma un proceso de sincronización que realice peticiones a la API para actualizar la visibilidad del producto en una tienda online, podrá realizar las actualizaciones necesarias dentro del propio mecanismo de su tienda para actualizar las visibilidades de producto. Todo ello sin que haya sido necesario alterar la visibilidad de esos productos o variantes en el lado del PIM de Sales Layer. De este modo no se verán afectados otros procesos u otras posibles tiendas online que estuvieran haciendo uso de los mismos productos bajo, quizá, otra marca.

Del mismo modo, si por ejemplo utilizamos habilitado el parámetro first_parent_level en las peticiones API al modificar un producto, por ejemplo su visibilidad, la API también enviará como información de cambio la de su/s categorías padre, de modo que un proceso externo de sincronización puede saber sobre qué categorías actuar, por ejemplo para actualizar el número de productos asociados en el lado front de una web.

Es solo un ejemplo de la plasticidad y potencia en el intercambio de información entre la solución PIM y la API de Sales Layer. Puedes elegir la que mejor se adapte a tu modelo de negocio.

En la mayoría de los casos, se pueden dar soluciones rápidas a las necesidades de un modelo de negocio con la configuración de peticiones por defecto.