Ejemplo 3 - Parámetros opcionales de la API

Introducción y estructura de datos

La API de Sales Layer tiene parámetros obligatorios pero también parámetros opcionales.

En el tercer ejemplo de exportación de ítems usando el SDK haremos una exportación utilizando algunos de estos parámetros opcionales permitidos por la API. Estos parámetros influyen en la exportación de datos de la API consonante al tipo de valor pasado en el parámetro.

Los parámetros usados en este ejemplo son:

group_category_id: parámetro que define si los productos con varias categorías serán exportados como un solo producto o si saldrá un mismo producto por cada categoría. Es decir, si el parámetro está en false y un producto tiene dos categorías el producto será exportado dos veces.
first_parent_level: parámetro que define si el padre asociado a un producto modificado será exportado. En el caso de modificación de una categoría se exportará las categorías inmediatamente arriba, en el caso de modificación de un producto, se exportará las categorías directamente asociadas y, en el caso de modificación de una variante, se exportará el padre de la variante.
same_parent_variants: parámetro que define si los formatos que comparten el mismo padre serán exportados cuando uno de esos formatos haya sido modificado.

Para más información: Resto de parámetros modeladores | Centro de Ayuda de Sales Layer.

Para este ejemplo utilizaremos de nuevo el conector creado en el Ejemplo 1, con la misma configuración de tablas (ver la configuración de tablas en el Ejemplo 1) y con los mismos filtros y parámetros:

Una vez más para los ítems a exportar el único parámetro a tener en cuenta será su estado visible porque no hemos añadido filtros de búsqueda o etiquetas en el conector.

Al elegir los ejemplos que están en modo visible, para entender perfectamente el uso de los parámetros, optamos por elegir pocos productos y variantes.

Para las categorías tenemos 14 visibles:

Para los productos elegimos tres, teniendo en cuenta que uno de ellos tiene variantes (producto con referencia 42PH420305221) y otro es multi-categoría (producto con referencia AAPA780310002):

Para las variantes elegimos las variantes del producto anteriormente elegido:

Para la prueba del funcionamiento de los parámetros usaremos el producto AAPA780310002 para probar el parámetro group_category_id, usaremos el producto 42PM506120061 para probar first_parent_level y usaremos las variantes del producto 42PH420305221 para same_parent_variants.

Código

Para exportar los datos con los parámetros anteriormente dichos, podríamos poner el siguiente ejemplo de código:

<?php 
define('LOC_BASE', dirname(__FILE__) . '/');
require(LOC_BASE.'SalesLayer-Conn.php');
require(LOC_BASE.'lib/nice_r-master/Nicer.php');
?>

<!DOCTYPE html>
<html dir="ltr" lang="en-US">
<head>
    <link rel="stylesheet" type="text/css" href="lib/nice_r-master/nice_r.css?version=<?php echo filemtime(LOC_BASE.'lib/nice_r-master/nice_r.css'); ?>"/>
    <script type="text/javascript" src="lib/nice_r-master/nice_r.js?version=<?php echo filemtime(LOC_BASE.'lib/nice_r-master/nice_r.js'); ?>"></script>
</head>

<body>
    <?php

    //SL connector credencials
    $connector_id = 'CN12347H3308C4486';
    $secret_key = '7aeb575d9bf15bfa238e8f01842417a2';

    $last_update= "1597958324";

    //Create object with the credentials on the connector in SL
    $SLConn = new SalesLayer_Conn ($connector_id, $secret_key);

    $SLConn->set_group_multicategory(true);
    $SLConn->set_first_level_parent_modifications(true);
    $SLConn->set_same_parent_variants_modifications(true);

    $SLConn->get_info($last_update);

    if ($SLConn->has_response_error()) {
        echo "<h4>Error:</h4>\n\n Code: ".$SLConn->get_response_error().
             "<br>\nMessage: ".           $SLConn->get_response_error_message();
    } else {
        echo "<h4>Response OK</h4>\n".
             "<p>".
             "API version: <b>".            $SLConn->get_response_api_version()          ."</b><br />\n".
             "Time: <b>".                   $SLConn->get_response_time('unix')                 ."</b><br/>\n".
             "Default language: <b>".       $SLConn->get_response_default_language()     ."</b><br/><br />\n".
             "</p>";

        //Print API response
        $n = new Nicer($SLConn->get_response_table_data());
        $n->render();
        echo "<hr/>";
    }       
    ?>
</body>
</html>

Será el momento de empezar creando una clase SalesLayer_Conn()con las credenciales del conector como parámetros. Estas credenciales están presentes en el conector de Sales Layer y las hemos guardado en los parámetros de $connector_id y $secret_key (ver Ejemplo 1).

Posteriormente, empezamos a definir los parámetros:

group_category_id: con la llamada a la función del SDK set_group_multicategory().
first_parent_level: con la llamada a la función del SDK set_first_level_parent_modifications().
same_parent_variants: con la llamada a la función del SDK set_same_parent_variants_modifications().

Las tres funciones aceptan como parámetro un valor booleano y, dependiendo si es true o false, los datos exportados por la API cambiarán.

Podremos ver sus diferencias en el análisis de los Resultados.

Para la llamada a la función get_info() de la clase elegimos la fecha de last_update posterior a la última fecha de modificación, para así hacer cambios en Sales Layer y observar los resultados. Siempre que hagamos un cambio, tenemos que cambiar la fecha de last_update en el código para exportar el ítem (o ítems) modificados en el cambio.

Nota: la fecha suele guardarse entre sincronizaciones para usarse siempre en la siguiente llamada.

Después de verificar que la API no ha devuelto errores a través de la función has_response_error() imprimimos con las funciones del SDK, la información relevante:

versión de la API a través de la función get_response_api_version()
fecha en UNIX de la hora exacta de la llamada a la API con la función get_response_time()
idioma por defecto del PIM llamando la función get_response_default_language()

Posteriormente y con la ayuda de la librería Nice_r (https://github.com/uuf6429/nice_r) imprimimos los datos que nos ha devuelto la API con la función get_response_table_data().

Ejecución y resultados

Para ejecutar el script tenemos que tener en cuenta los parámetros pasados a la API.

En el ejemplo de código utilizado anteriormente tenemos los siguientes parámetros:

group_category_id: true
first_parent_level: true
same_parent_variants: true

Pueden ser cambiados entre true o false como veremos enseguida.

Empezaremos por estudiar la respuesta de la API sobre el parámetro group_category_id. Este parámetro hace que un producto multi-categoría se exporte tantas veces como su número de categorías.

Vamos a volver al producto multi-categoría con la referencia AAPA780310002:

Vemos que sus categorías tienen como referencia ACCE01 y VERA02:

Con el parámetro en true, el producto se exportará como un único producto con 2 categorías en el campo de section_reference:

Si tenemos el parámetro en false, el producto se exportará dos veces, pero con diferentes valores en el campo section_reference (campo donde se encuentra la referencia de categoría):

Cambiando el parámetro a true la API exporta el ítem una única vez con dos categorías en el campo section_reference. Cuando lo hagamos con el parámetro en false, la API exportará el ítem duplicado, pero cambiando el campo section_reference.

Es el momento de hablar de la respuesta de la API al parámetro first_parent_level , parámetro que define si el ítem superior a un ítem modificado será igualmente exportado.

Para ello, haremos un cambio en el producto de referencia 42PM506120061.

Con el parámetro en true, al realizar este cambio, además del producto exportado se exporta el árbol de categorías:

Con el parámetro a false, con el cambio solo se exporta el producto:

Como podemos observar la API exportó el ítem superior en la jerarquía.

Si lo probamos haciendo un cambio en la tabla de variantes, cambiando una variante, con el parámetro en true, obtenemos el mismo resultado: los ítems inmediatamente arriba exportarán, en este caso, el producto padre.

Vamos a ver un ejemplo cambiando la variante F234946 con la referencia del padre de 42PH420305221:

Como vemos, con el parámetro en true se exporta el padre y la variante:

Con el parámetro en false se exporta solamente la variante:

Por último, probaremos la exportación de la API usando el parámetro same_parent_variants. Este parámetro, cuando está en true, exporta todas las variantes del mismo padre cuando una de sus variantes es modificada.

Recordemos que tenemos las siguientes variantes en modo visible y que pertenecen a la misma referencia padre:

Con el parámetro en true, cambiando una de las variantes, las tres referencias serán exportadas de este modo:

Con el parámetro en false, cambiando una de las variantes, solo la modificada será exportada:

A modo de resumen, este sería el funcionamiento de la API dependiendo del tipo de parámetro:

group_category_id - con la llamada a la función del SDK set_group_multicategory()

Parámetro	true	false
Resultado	El producto se exportará solo una vez con las categorías agrupadas en el mismo campo.	El producto se exportará según el número de categorías que tiene, conteniendo solo una categoría en el campo de referencia de categoría.

first_parent_level - con la llamada a la función del SDK set_first_level_parent_modifications()

Parámetro	true	false
Resultado	El ítem superior en la jerarquía de un ítem modificado será igualmente exportado	Solamente se exporta el ítem modificado.

same_parent_variants - con la llamada a la función del SDK set_same_parent_variants_modifications()

Parámetro	true	false
Resultado	Todas las variantes pertenecientes al mismo padre y de una variante modificada serán exportadas.	Solamente se exporta la variante modificada.