Data Factory > rules-engine-execute-rules

TL;DR;

This task allows to execute the mapping rules linked to a table.

Name:

TIP

The full documentation of the behavior of this task is detailed in the Learning Center.

Notes générales

L'application des règles de mappings ne permet pas de créer des items, seulement de les mettre à jour
L'application de règles de mapping sur une table qui n'en possède pas ne génère pas d'erreur. (un message de type "warning" est simplement affiché dans la vue de détail de l'exécution du job au sein de l'application settings)
Les règles de mapping appliqué à des éléments qui possèdent par ailleurs une formulas sont ignorées. Ces règles ne sont pas exécutées et un message est ajouté au rapport d'erreur.
Les attributs (et tables) cibles archivés sont ignorés. On n’applique donc pas la règle sur les attributs cibles archivés.
Si un attribut source est archivé, on considère sa valeur comme vide. (Dans le cadre des conditions sur une règle de mapping)
Dans le cas d’une « action », si un « Field » source est archivé, mais dispose d’une valeur, on traite tout de même cette valeur (même logique pour les tables sources archivées)
L’application des règles a le même impact que d’éditer un attribut, elle implique une mise à jour du formatage conditionnel sur les items ciblés.

Exemple d'usage dans un job

Appliquer les règles de mapping quotidiennement

1.	Exécute Mapping Exécute les règles de mapping et génère un fichier item

Générer en plus un rapport

1.	Exécute Mapping Exécute les règles de mapping et génère un fichier item
2.	Transform XSLT Générer le fichier pour la tâche Generate Excel
3.	Generate Excel Générer un rapport de ce qui a été importé

Appliquer les règles de mapping après avoir importé les données de l’ERP

1.	FTP Get Récupérer le fichier qui provient de l’ERP sur le FTP
2.	CSV to XML Transformer le fichier CSV au format XML
3.	Transform XSLT Générer un fichier items.xml pour la tâche d’import items
4.	Import Items Importer les produits qui viennent de l’ERP
5.	Execute Mapping Exécute les règles de mapping sur la table Fnac
6.	Execute Mapping Exécute les règles de mapping sur la table Boulanger

Les Entrées / Sorties

Exemple de définition de cette tâche en JSON

json

{
    "name": "rules-engine-execute-rules",
    "taskReferenceName": "execute_mapping_rules",
    "description": "The business description of the task",
    "type": "SUB_WORKFLOW",
    "optional": false,
    "inputParameters": {
        "mode": "ALL",
        "tableKey": "products",
        "accountKey": "f6955931-851e-4e4d-b1c7-6129b43b8d8a",
        "partitions": [
            "active"
        ]
  }
}

Détails sur l'exécution des règles de mapping

Rapprochemement des items

On appelle ici rapprochement entre deux items le fait d'établir une règle de correspondance entre deux items appartement chacun à un level au sein de deux tables différentes. Exemple: Identifier l'équivalent d'un item donné (appartenant à une level sur une table) sur une table et un level cible

Le rapprochement des items s'effectue à l'aide des Source-Tables définies depuis l'interface ou lors de l'import des règles de mapping.

Règles générales

Il ne peut exister qu'une unique Source-Table (lien entre deux identifiers) entre deux levels de deux tables différentes
- Voir également ce document pour plus d'informations sur l'import des liens entre les tables Source-Table
Pour rappel, un level ne possède qu'un unique level parent sur une table donnée
On peut identifier l'item d'une table cible correspondant à un item donné sur une table source en rapprochant les levels de ces tables. Pour cela on procède de la manière suivante:
- 1. Partant d'un level donné sur la table cible, s'il existe un lien vers la table source, on suit ce lien
- 1. S'il n'existe pas de lien vers la table source, on passe au level parent (si le level possède un parent)
On considère qu'il existe un lien entre un level donné sur une la table cible et l'ensemble des levels traversés sur la table source en suivant le protocole mentionné précédemment
Il est possible d'utiliser au sein d'une règle de mapping sur un level donné de la la table cible, tout field, classification ou identifier appartenant à un level lié au level courant par la méthode précédente.

Exemples

Rapprochement simple entre deux tables mononiveau

Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 1 de la table cible retailer-A-products et le level Level 1 de la table source products
- 1. On part du level Level 1 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier Product Code du level Level 1 de la table cible retailer-A-products et l'identifier model du level Level 1 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 1 de la table source products ne possède pas de parent. On s'arrete donc à ce level.
On a établi un lien entre le level Level 1 de la table cible retailer-A-products et le level Level 1 de la table source products. On peut donc tenter d'appliquer la règle de mapping A entre le field Title de la table cible retailer-A-products et le field Title de la table source products

Dans l'exemple ci-dessous, les items A et B de la table on une correspondance au sein de la table source products

Rapprochement entre une table cible mononiveau et une table source multiniveau

Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 1 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 1 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier EAN13 du level Level 1 de la table cible retailer-A-products et l'identifier EAN13 du level Level 3 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 3 de la table source products possède un parent, on remonte donc jusqu'au niveau parent Level 2
- 1. Le level Level 2 de la table source products possède un parent, on remonte donc jusqu'au niveau parent Level 1
- 1. Le level Level 1 de la table source products ne possède pas de parent. On s'arrête donc à ce level.
On a établi un lien entre le level Level 1 de la table cible retailer-A-products et les levels Level 1, Level 2 et Level 3 de la table source products. On peut donc tenter d'appliquer les règles de mapping A, B, C et D ci-dessus.
- Dans cette configuration, l'ensemble des fields, identifier et classification de la table source products peuvent être utilisé dans des règles de mapping au sein de la table cible retailer-A-products

L'exemple ci-dessus illustre l'application des règles décrites un peu plus haut sur 4 items de la table cible retailer-A-products

Rapprochement entre une table cible mononiveau et une table source multiniveau - Illustration d'un cas limite

Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 1 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 1 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier Product-Code du level Level 1 de la table cible retailer-A-products et l'identifier model du level Level 1 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 1 de la table source products ne possède pas de parent. On s'arrête donc à ce level.
On a établi un lien entre le level Level 1 de la table cible retailer-A-products et le level Level 1 de la table source products. Cependant, nous ne sommes pas capable d'établir un lien avec les levels Level 2 et Level 3 de la table source products.
- On peut donc tenter d'appliquer la règle de mapping A
- On ne peut cependant pas appliquer les règles B, C et D ci-dessus. Dans ce cas, un log est ajouté dans le rapport d'exécution (UNABLE_TO_SELECT_AN_ITEM_IN_THE_SOURCE_TABLE)
- Dans cette configuration, seuls les fields, identifier et classification présent sur le level Level 1 de la table source products peuvent être utilisés dans des règles de mapping au sein de la table cible retailer-A-products

L'exemple ci-dessus illustre l'application des règles décrites un peu plus haut sur 4 items de la table cible retailer-A-products
On remarque que les règles de mapping n'ont pu s'appliquer sur deux items, faute d'avoir pu trouver une correspondance dans la table source. Dans ce cas, un log est ajouté dans le rapport d'exécution (UNABLE_TO_FIND_AN_ITEM_IN_THE_SOURCE_TABLE)

Rapprochement entre une table cible multiniveau et une table source mononiveau

Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 1 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 1 de la table cible retailer-A-products
- 1. Le level Level 1 de la table cible retailer-A-products ne possède ni parent ni lien Source-Table avec la table source products. On s'arrête donc à ce level.
Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 2 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 2 de la table cible retailer-A-products
- 1. Le level Level 2 de la table cible retailer-A-products ne possède pas de lien Source-Table avec la table source products mais possède un parent, on remonte donc jusqu'au niveau parent Level 1
- 1. Le level Level 1 de la table cible retailer-A-products ne possède ni parent ni lien Source-Table avec la table source products. On s'arrête donc à ce level.
Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 3 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 3 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier EAN13 du level Level 3 de la table cible retailer-A-products et l'identifier EAN13 du level Level 1 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 1 de la table source products ne possède pas de parent. On s'arrête donc à ce level.
On a établi un lien entre le level Level 3 de la table cible retailer-A-products et le level Level 1 de la table source products. Cependant, nous ne sommes pas capable d'établir un lien entre les levels Level 1 et Level 2 de la table cible retailer-A-products et les levels de la table source products.
- On peut donc tenter d'appliquer les règles de mapping C et D
- On ne peut cependant pas appliquer les règles A et B ci-dessus. Dans ce cas, un log est ajouté dans le rapport d'exécution (UNABLE_TO_SELECT_AN_ITEM_IN_THE_SOURCE_TABLE)
- Dans cette configuration, l'ensemble des fields, identifier et classification présent sur le level Level 1 de la table source products peuvent être utilisé dans des règles de mapping au sein du level Level 3 de la table cible retailer-A-products

Rapprochement entre une table cible multiniveau et une table source multiniveau

Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 1 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 1 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier Product-Code du level Level 1 de la table cible retailer-A-products et l'identifier model du level Level 1 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 1 de la table source products ne possède pas parent. On s'arrête donc à ce level.
Dans l'exemple ci-dessus, on procède comme ci-dessous pour résoudre la correspondance entre le level Level 2 de la table cible retailer-A-products et les levels de la table source products
- 1. On part du level Level 2 de la table cible retailer-A-products
- 1. Il existe un lien Source-Table entre l'identifier EAN13 du level Level 2 de la table cible retailer-A-products et l'identifier EAN13 du level Level 3 de la table source products. On suit donc le lien proposé.
- 1. Le level Level 3 de la table source products possède un parent, on remonte donc jusqu'au niveau parent Level 2
- 1. Le level Level 2 de la table source products possède un parent, on remonte donc jusqu'au niveau parent Level 1
- 1. Le level Level 1 de la table source products ne possède pas de parent. On s'arrête donc à ce level.
On a établi un lien entre le level Level 2 de la table cible retailer-A-products et les level Level 1, Level 2 et Level 3 de la table source products.
Nous avons également établi un lien entre le Level 1 de la table cible retailer-A-products et le level Level 1 de la table source products.
- On peut donc tenter d'appliquer les règles de mapping A, B C, D, E et F
- Dans cette configuration, l'ensemble des fields, identifiers et classifications présents sur le level Level 1 de la table source products peuvent être utilisés dans des règles de mapping au sein du level Level 1 de la table cible retailer-A-products
- Dans cette configuration, l'ensemble des fields, identifiers et classifications présents sur les levels Level 1, Level 2 et Level 3 de la table source products peuvent être utilisés dans des règles de mapping au sein du level Level 2 de la table cible retailer-A-products

L'exemple ci-dessus illustre l'application des règles décrites un peu plus haut sur 4 items de la table cible retailer-A-products
On remarque que les règles de mapping n'ont pu s'appliquer sur certains items, faute d'avoir pu trouver une correspondance dans la table source. Dans ce cas, un log est ajouté dans le rapport d'exécution (UNABLE_TO_FIND_AN_ITEM_IN_THE_SOURCE_TABLE)

Comportements communs à l'ensemble des règles de mapping

Si une table cible est archivée, alors les règles de mapping associées à cette table ne sont pas appliquées
Le fait qu'une table source soit archivée n'a pas d'impact sur l'application des règles de mapping.
Si le lien dans matrix est archivé pour un field donné, alors on n'applique pas les règles de mapping ayant pour cible ce field
Dans le cas où un field archivé (le lien présent dans matrix) est pris comme source d'une règle de mapping, on doit considérer sa valeur comme étant vide ("")

Concernant les identifiers

Si un identifier est archivé, alors on n'applique pas les règles de mapping ayant pour cible cet identifier
Dans le cas où un identifier archivé est pris comme source d'une règle de mapping, on doit considérer sa valeur comme étant vide ("")

Concernant les classifications

L'application des règles sur les classifications s'effectue avant les règles ayant pour cible des fields (notamment pour permettre l'application de règles sur des fields spécifiques)
Si une classification est archivée, alors on n'applique pas les règles de mapping ayant pour cible cette classification
Le fait qu'une classification prise comme source soit archivée n'a pas d'impact sur l'application des règles de mapping