Knowledge Base

Appearance

Unicité d'une clef composée ​

Ce document décrit l'approche recommandée quant à l'implémentation de la notion d'unicité sur une clef composée d'au moins deux valeurs sur un item.

Exemples d'utilisation ​

Cible: Rendre unique le couple "Référence fournisseur/fournisseur" au sein d'une table

C'est notamment le cas d'utilisation de cette fonctionnalité par Fnac/Darty.

Dans ce cas, on cherche à rendre unique le couple "Référence fournisseur/fournisseur" au sein de la table "Produits".

Exemple, si l'on considère la table ci-dessous:

#EANRéférence fournisseurFournisseur
13838782461613ASamsung
24016803051930AApple

On souhaite pouvoir empêcher l'édition du field Fournisseur de l'item #2 pour lui donner la valeur Samsung, puisque le couple A/Samung est déjà utilisé par l'item #1.

Création d'une formula sur un identifier ​

Pour modéliser l'unicité d'un couple de deux fields au sein d'une table, on utilise une formula sur un identifier.

xml
<Table key="PRODUCTS">
    <Title>Produits</Title>
    <Desciption>Table des produits</Desciption>
    <Position>1</Position>
    <Color>RED</Color>
    <Schema>
        <Identifiers>
            <Identifier key="EAN" index="1" level="PRODUCT">
                <Title>EAN</Title>
            </Identifier>
            <Identifier key="SUPPLIER_REF-SUPPLIER_CODE" index="2" level="PRODUCT">
                <Title>Couple Référence Fournisseur/Fournisseur</Title>
            </Identifier>
        </Identifiers>
        <Formulas>
            <Identifier key="SUPPLIER_REF-SUPPLIER_CODE">
                <Rule priority="1">
                    <Conditions>
                        <Condition-Group>
                            <Condition source="SUPPLIER_REF" operator="EMPTY"/>
                        </Condition-Group>
                        <Condition-Group>
                            <Condition source="SUPPLIER" operator="EMPTY"/>
                        </Condition-Group>
                    </Conditions>
                    <Action type="REMOVE_VALUE"/>
                </Rule>
                <Rule priority="2">
                    <Conditions>
                        <Condition-Group>
                            <Condition source="SUPPLIER_REF" operator="NOT_EMPTY"/>
                            <Condition source="SUPPLIER" operator="NOT_EMPTY"/>
                        </Condition-Group>
                    </Conditions>
                    <Action type="SET_TEXT">
                        <Template trim-spaces="true"><![CDATA[{{source("SUPPLIER_REF")}}-{{source("SUPPLIER","key")}}]]></Template>
                    </Action>
                </Rule>
            </Identifier>
        </Formulas>
    </Schema>
</Table>
  • Ici, on utilise la propriété d'unicité sur l’identifier SUPPLIER_REF-SUPPLIER_CODE pour empêcher la création de deux couples "Référence fournisseur/fournisseur" identiques.
  • On remarque qu'une première rule est utilisée pour supprimer le couple "Référence fournisseur/fournisseur" si l'un des deux fields est vide. Cela permet notamment de ne pas tenir compte de la règle d'unicité sur le couple "Référence fournisseur/fournisseur" si l'un des deux fields est vide. Ce paramétrage permet notamment de gérer le cas ci-dessous:

Temps 1 - Si l'on considère les items ci-dessous, l'identifier SUPPLIER_REF-SUPPLIER_CODE dispose de la formula ci-dessous:

#EANSUPPLIER_REFSUPPLIERSUPPLIER_REF-SUPPLIER_CODE
1761234567890ref-aSamsungref-a-Samsung
2761234567891Samsung

Temps 2 - On supprime la valeur ref-a sur l'item #1:

#EANSUPPLIER_REFSUPPLIERSUPPLIER_REF-SUPPLIER_CODE
1761234567890Samsung
2761234567891Samsung

dans le cas ci-dessus:

  • si l'on considère la règle de concaténation identifier SUPPLIER_REF-SUPPLIER_CODE = SUPPLIER_REF + SUPPLIER, on obtient une valeur identique pour les items #1 et #2. Nous nous retrouvons dans l'incapacité de créer deux items avec une SUPPLIER_REF et un SUPPLIER dont la valeur est "Samsung".
    • C'est pour la raison ci-dessus que la règle de concaténation SUPPLIER_REF-SUPPLIER_CODE = SUPPLIER_REF + SUPPLIER n'est évalué que si les deux valeurs sont non-vides.
  • Si on ne supprime pas la valeur précédemment calculée pour l'identifier SUPPLIER_REF-SUPPLIER_CODE au moment de supprimer la valeur ref-a sur l'item #1, nous nous retrouvons avec une valeur incohérente pour l'item #1 sur l'identifier SUPPLIER_REF-SUPPLIER_CODE.
    • C'est pour cette raison que l'on propose ici une rule qui supprime la valeur de l'identifier SUPPLIER_REF-SUPPLIER_CODE quand l'une ou l'autre des valeurs est vide.

Se référer au document traitant du comportement des identifiers cible de formula pour plus d'informations.

L'impact des outils utilisés dans l'import et l'export de la table ​

Plus de détails sur les formulas dans l'import de table.

Plus de détails sur les formulas dans l'import d'items.

L'impact de la création d'une clef composée unique depuis app.product-live.com ​

Concernant l'édition d'items depuis la grille ou la vue de détail ​

  • Les formules sont exécutées immédiatement après qu'une demande de mise à jour soit effectuée par l'utilisateur sur une cellule concernée par celles-ci
  • Une cellule qui est calculée par une formule ne peut être éditée manuellement (voir la tâche d'import d’items pour plus de détails)
  • L'édition d'une cellule peut être rendue impossible par l'application d'une formule. Notamment si celle-ci va à l'encontre d'une contrainte d'unicité sur un identifiant. Voir exemple ci-dessous.

Si l'on considère la table ci-dessous

╔═══╦══════════════╦══════════════╦═══════════════════════╗
║ # ║ Identifiant  ║ Code Produit ║ Fournisseur           ║
║   ║ (idenfifier) ║ (field text) ║ (field single option) ║
╠═══╬══════════════╬══════════════╬═══════════════════════╣
╠═══╬══════════════╬══════════════╬═══════════════════════╣
║ 1 ║ ABC-Samsung  ║ ABC          ║ Samsung               ║
╠═══╬══════════════╬══════════════╬═══════════════════════╣
║ 2 ║ DEF-Apple    ║ DEF          ║ Apple                 ║
╠═══╬══════════════╬══════════════╬═══════════════════════╣
║ 3 ║              ║ DEF          ║                       ║
╚═══╩══════════════╩══════════════╩═══════════════════════╝

Et la formule suivante sur l'identifier Identifiant (qui ne s'applique que lorsque les fields Code Produit et Founisseur sont renseignés voir la tâche d'import de table pour plus de détails)

Identifiant = Code Produit + "-" + Fournisseur(key)

Si l'utilisateur propose la valeur Apple pour l'item de la ligne 3, celle-ci ne peut être acceptée puisque la valeur DEF-Apple pour l'identifier Identififiant est deja prise par un autre item.

Dans ce cas, ni la mise à jour du field Fournisseur, ni la mise à jour du champ calculé Identifiant ne peut être effectuée. (voir la tâche d'import d’items pour plus de détails)

Les formulas dans un contexte partagé ​

  • La création de formula n'est permise que sur une table qui appartient à l'account courant. (On ne peut créer de formulas sur une table partagée)
  • Les formulas s'exécutent, quel que soit le contexte sur lequel on se place
    • Dans le contexte du compte courant (sur une table qui appartient au compte courant)
    • Dans le contexte d'un partenaire (sur une table qui nous est partagée)

Le cas particulier des fields cibles d'une règle de mapping ​

  • On peut créer ou mettre à jour une règle de mapping sur un field qui est la cible d'une formula.
  • Si un field est la cible d'une règle de mapping et d'une formula, seule la formula est appliqué, la règle de mapping est ignorée.

Concernant l'application de suggestions sur un item ​

  • La mise à jour des formulas s'effectue après toute collecte de donnée sur un item.
  • Un champ calculé ne peut être collecté puisque celui-ci ne peut être édité directement

Limitations connues des identifiants calculés ​

L'utilisation des identifiants calculés pour garantir l'unicité d'un couple de valeur (field, classification ou identifier, voir l'import de table pour plus de détails) comporte des limitations.

Si l'on considère la table suivante:

+---+-----------+---------------------+-----------------------+-------------+
| # | EAN       | Identifiant Composé | Référence Fournisseur | Fournisseur |
|   | index = 1 | index = 2           |                       |             |
|   |           |                     |                       |             |
+===+===========+=====================+=======================+=============+
| 1 | 1         | REF1-SAMSUNG        | REF1                  | SAMSUNG     |
+---+-----------+---------------------+-----------------------+-------------+
| 2 | 2         | REF2-SAMSUNG        | REF2                  | SAMSUNG     |
+---+-----------+---------------------+-----------------------+-------------+

Su laquelle est appliquée la formula ci-dessous:

Identifiant = Code Produit + Fournisseur(key)

Il existe plusieurs combinaisons possibles des fields Référence Fournisseur et Fournisseur permettant d'obtenir une même valeur pour Identifiant Composé.

Exemples

Valeur pour Référence FournisseurValeur pour FournisseurValeur pour Identifiant Composé
REF1SAMSUNGREF1SAMSUNG
REF1SAMSUNGREF1SAMSUNG
REF1SAMSUNGREF1SAMSUNG
REF1SAMSUNGREF1SAMSUNG
<empty>REF1SAMSUNGREF1SAMSUNG

Il n'existe pas de méthode permettant d'éliminer complètement cette limitation. Cependant, l'approche ci-dessous permette d'en limiter l'impact:

Utiliser un séparateur constitué de caractères qui ne sont idéalement pas utilisés dans les différents membres de la concaténation, ou rarement utilisés

Par exemple __ ou --.