Personnaliser les blocs Looker

Cette page présente les bonnes pratiques et des exemples pour adapter les blocs Looker Cortex Framework suivants à vos besoins spécifiques :

Installation

Vous pouvez installer les blocs Looker Cortex Framework de plusieurs manières, comme indiqué dans la documentation Déployer des blocs Looker. Toutefois, nous vous recommandons de dupliquer le dépôt car il s'agit de la méthode la plus simple pour personnaliser les blocs en fonction de vos besoins.

Les blocs Looker Cortex Framework ont été créés selon une approche par couches, où chaque couche ajoute un élément de logique incrémental à la couche précédente :

Couche de base : vues LookML générées par une machine faisant référence à des tables sources.
Couche principale : modifications manuscrites qui ajoutent de nouveaux champs ou modifient les champs de la couche de base.
Couche logique : définitions d'exploration et jointures entre différentes vues.

L'utilisation de perfectionnements est essentielle pour cette approche par couches et pour la personnalisation. Pour suivre le principe DRY (Do Not Repeat Yourself, Ne vous répétez pas), les extensions et les constantes sont utilisées. Le contenu dynamique des libellés, des instructions SQL, des propriétés HTML et des liens est généré à l'aide du langage de création de modèles Liquid.

Bonnes pratiques générales de Google :

Organisation des fichiers et des dossiers

Dans le bloc Looker, chaque dossier représente un ensemble de types d'objets (tels que des vues, des explorations, des tableaux de bord, etc.). Chaque objet individuel est défini dans un fichier distinct. La racine du projet contient les fichiers clés suivants :

Fichier .model
Fichier manifeste
Fichier README et autres fichiers Markdown
Fichiers Marketplace (si le bloc est également disponible sur le Marketplace Looker)

Explorateur de fichiers

Figure 1 : Exemple d'organisation des dossiers dans le bloc Looker.

Modèle

La gestion modulaire des fichiers permet de simplifier le fichier model du projet à l'aide des paramètres suivants :

connexion
include

Les types de fichiers inclus sont les suivants :
- Components (groupes de données, named_value_formats le cas échéant)
- Explores (les explorations ne sont pas définies dans le fichier de modèle)
- Dashboards

Les instructions include pour les vues utilisées dans le bloc sont définies dans chaque fichier d'exploration individuel, plutôt qu'à cet emplacement, comme le montre l'exemple suivant :

connection: "@{CONNECTION_NAME}"

include: "/components/**/*.lkml"
include: "/explores/**/*.explore"
include: "/dashboards/**/*.dashboard"

Fichier manifeste

Le fichier manifeste spécifie les constantes auxquelles il est fait référence dans un projet. Voici quelques exemples de constantes utilisées pour nos blocs :

Nom de connexion
ID du projet
Ensemble de données de création de rapports

Les blocs Looker Cortex Framework utilisent également des constantes pour définir les éléments suivants :

Libellés de vue
Libellés de champ
Formats HTML
Liens URL
Noms des tableaux de bord

Examinez les constantes définies pour le bloc Looker et modifiez les valeurs en fonction de vos besoins. Les modifications s'appliquent partout où la constante est référencée.

Attributs utilisateur

Certains blocs Looker nécessitent que des attributs utilisateur soient définis dans l'instance Looker par un administrateur. Ces attributs utilisateur pour la langue ou la devise par défaut vous permettent de personnaliser l'affichage des tableaux de bord par utilisateur ou par groupe. Pour en savoir plus sur les attributs utilisateur requis, consultez la présentation de chaque bloc.

Vues

Les vues du dossier de base sont celles générées automatiquement à l'aide de l'option "Créer une vue à partir d'une table". Ces fichiers ont été modifiés de manière minimale :

L'ID du projet et le nom de l'ensemble de données ont été remplacés par des constantes.
Les vues basées sur des enregistrements imbriqués ont été déplacées dans des fichiers distincts.
Toutes les définitions de champs d'exploration inutiles ont été supprimées.

Des modifications importantes de ces vues, telles que des libellés, de nouvelles dimensions et mesures, ont été créées dans le dossier Core à l'aide de perfectionnements, extensions ou tables dérivées.

Dans le dossier principal, les vues sont nommées avec un suffixe indiquant leur type :

_rfn pour le perfectionnement.
_ext pour la vue nécessitant une extension.
_sdt pour la table dérivée basée sur SQL.
_ndt pour la table dérivée native.
_pdt pour la table dérivée persistante.
_xvw pour la vue faisant référence à des champs provenant de plusieurs vues.

Exemple de suffixe

Figure 2 : Exemple de suffixe indiquant le type de vue.

Chaque définition de vue commence par des annotations qui fournissent des informations générales, y compris des descriptions, des sources, des références, des champs étendus et d'autres notes pertinentes.

Annotations

Figure 3 : Exemple d'annotations dans une définition de vue.

Enregistrements répétés imbriqués

Pour les tables sous-jacentes contenant des enregistrements répétés imbriqués, Looker crée des vues distinctes pour les désimbriquer. Par exemple, dans le bloc Looker Oracle EBS, la table sales_orders comporte une structure répétée imbriquée nommée lines. Looker les traite comme deux vues distinctes : sales_orders et sales_orders__lines.

Pour joindre ces enregistrements désimbriqués dans l'exploration, vous devez définir la jointure à l'aide de la propriété sql associée à la commande UNNEST.

Commande UNNEST

Figure 4 : Exemple de jointure à l'aide de la propriété "sql" associée à la commande UNNEST.

Pour en savoir plus, consultez la section Modéliser des données BigQuery imbriquées dans Looker.

Parcourir et comprendre le code du bloc Looker

Les blocs Looker Cortex Framework contiennent de nombreux commentaires dans les vues et autres objets. Pour améliorer la navigation et la compréhension du code, il est recommandé d'utiliser l'option "Plier le code LookML" disponible dans l'environnement de développement LookML.

Plier le code LookML

Figure 5 : Cliquer sur "Plier le code LookML".

Déplier le code LookML

Figure 6 : Cliquer pour déplier le code LookML.

Plier à nouveau

Figure 7 : Cliquer pour replier le code LookML.

Champs

Le terme field fait référence à des objets tels que dimension, measure, filter ou parameter. Dans ces blocs plus récents, nous avons suivi les principes suivants :

Les dimensions sont nommées à l'aide de la snake_case (minuscules et trait de soulignement entre les mots). Exemple : customer_name.
Les noms de colonnes des tables sous-jacentes sont utilisés pour nommer les dimensions. Des libellés peuvent être appliqués aux dimensions pour leur donner un nom plus adapté à l'entreprise. Par exemple, une dimension nommée division_hdr_spart peut être libellée "ID de division".
Pour les tables comportant de nombreuses colonnes, les champs sont masqués par défaut. À l'aide d'un perfectionnement de la vue, définissez la propriété hidden sur "no" pour le sous-ensemble de champs à afficher dans une exploration. Si un champ ne s'affiche pas comme prévu, vous pouvez résoudre le problème en modifiant cette propriété de champ.
Les propriétés View_label et group_label sont utilisées pour organiser les champs dans une exploration, le cas échéant.
Pour les champs utilisés dans plusieurs vues, les propriétés telles que le libellé sont établies dans une vue "commune", qui est ensuite étendue à d'autres vues. Cette approche centralise la définition de la propriété, ce qui favorise la réutilisation. Toutes les modifications nécessaires sont gérées dans la vue "commune", ce qui garantit que les modifications sont reflétées dans toutes les vues où la vue "commune" est étendue.
Les paramètres utilisés dans plusieurs explorations ou champs qui font référence à plusieurs vues sont définis dans une vue de champ uniquement avec le suffixe _xvw. Pour en savoir plus, consultez la section Éviter les incohérences entre les explorations.

Exemples de modification

Cette section fournit des exemples de personnalisations courantes.

Afficher un champ

La vue de base englobe toutes les dimensions d'une table sous-jacente. Lorsque la plupart des dimensions n'ont pas besoin d'être visibles, un perfectionnement est utilisé pour masquer tous les champs par défaut. Pour ce faire, définissez la propriété fields_hidden_by_default sur "yes". Le sous-ensemble de champs pertinents pour les tableaux de bord LookML inclus a été affiché. L'exemple suivant considère une vue de base nommée sales_orders avec une dimension appelée item_posnr.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

  dimension: item_posnr {
    type: string
    sql: ${TABLE}.Item_POSNR
  }
}

Le perfectionnement de cette vue est défini dans le fichier avec le suffixe _rfn. Le perfectionnement définit la propriété de vue fields_hidden_by_default sur "yes", ce qui signifie que tous les champs sont initialement masqués. Pour afficher le champ item_posnr dans la vue, définissez la propriété masquée sur "no".

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Modifier le libellé de la vue des paramètres

Plusieurs blocs Looker utilisent un ensemble partagé de paramètres définis dans un fichier autonome. Par exemple, le bloc Oracle EBS utilise le fichier otc_common_parameters_xvw. Cette vue affiche le libellé "🔍 Filtres", qui est défini comme une constante dans le fichier manifeste.

Pour modifier ce libellé :

Recherchez la constante label_view_for_filters dans le fichier manifeste.
Modifiez la valeur de la constante en fonction du libellé de votre choix.
Enregistrez le fichier manifeste. La modification sera automatiquement reflétée partout où la constante label_view_for_filters est référencée.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

Vous pouvez également accéder à la vue otc_common_parameters_xvw et modifier la propriété "label" en fonction de la valeur de votre choix.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Ajouter une mesure

Vous pouvez ajouter directement de nouvelles mesures au perfectionnement approprié. L'exemple suivant montre une nouvelle mesure ajoutée au perfectionnement des commandes commerciales :

view: +sales_orders {

  measure: customer_count {
    type: count_distinct
    sql: ${customer_id}
   }
}

Ajouter une deuxième couche de perfectionnement

Vous pouvez créer de nouveaux perfectionnements à partir de perfectionnements existants. Prenons l'exemple du perfectionnement de sales_orders dans le fichier sales_orders_rfn.view, qui crée la mesure average_sales :

include: "/views/base/sales_orders"
view: +sales_orders {
  measure: average_sales {
    type: average
    sql: ${order_value}
  }
}

Pour créer un deuxième fichier de perfectionnement :

Créez un fichier de perfectionnement : nommez-le sales_orders_rfn2.view.
Incluez le premier fichier de perfectionnement : toutes les définitions de sales_orders_rfn seront intégrées à sales_orders_rfn2.
Modifiez la propriété de libellé : remplacez la propriété label de average_sales par « dépense moyenne » ou tout autre libellé de votre choix.

Ajoutez une nouvelle dimension : incluez le code de la nouvelle dimension dans le fichier sales_orders_rfn2.view.

include: "/views/core/sales_orders_rfn.view"
view: +sales_orders {

  measure: average_sales {
    label: "Average Spend"
  }

  dimension: customer_name_with_id {
    type: string
    sql: CONCAT(${customer_id},' ',${customer_name})
  }
}

Incluez le deuxième fichier de perfectionnement dans l'exploration : toutes les définitions et améliorations de sales_orders_rfn2 seront intégrées à l'exploration.
```
include: "/views/core/sales_orders_rfn2.view"
explore: sales_orders {
}
```

Créer une couche de perfectionnement

Le perfectionnement de toute vue de base définie dans le bloc Looker Cortex Framework peut être remplacé s'il ne répond pas à vos besoins spécifiques. Vous pouvez modifier directement le fichier _rfn pour supprimer les définitions de champs inutiles ou en ajouter de nouvelles.

Vous pouvez également créer un fichier de perfectionnement :

Créez un fichier de perfectionnement : nommez-le sales_invoices_rfn et enregistrez-le.
Incluez la vue de base : toutes les définitions de la vue de base sales_invoices seront intégrées à sales_invoices_rfn.

Ajoutez les personnalisations de votre choix : veillez également à définir une dimension comme clé primaire.

include: "/views/base/sales_invoices.view"

view: +sales_invoices {

  fields_hidden_by_default: yes

  dimension: invoice_id {
    hidden: no
    primary_key: yes
    value_format_name: id
  }

  dimension: business_unit_name {
    hidden: no
    sql: CONCAT(${business_unit_id}, ":",${TABLE}.BUSINESS_UNIT_NAME) ;;
  }
}

Incluez le nouveau perfectionnement dans l'exploration : utilisez le nouveau fichier dans la propriété include au lieu du perfectionnement fourni dans le bloc Looker Cortex Framework.
```
include: "/views/my_customizations/sales_invoices_rfn.view"

explore: sales_invoices {
}
```

Modifier les filtres de tableau de bord LookML

L'ensemble commun de filtres de tableau de bord utilisé dans plusieurs tableaux de bord LookML est défini dans un tableau de bord nommé avec le suffixe _template et étendu à chaque tableau de bord. Une fois étendus, les objets de filtre peuvent être modifiés si nécessaire pour un tableau de bord spécifique.

Modifier tous les tableaux de bord

Pour modifier le type de filtre de tous les tableaux de bord, recherchez le fichier de modèle qui définit le filtre. Modifiez le type ui_config et affichez les propriétés en fonction des paramètres de votre choix. Cette modification s'appliquera à tous les tableaux de bord qui étendent le modèle. Voici un exemple de otc_template.dashboard :

- dashboard: otc_template
  extension: required

  filters:
  - name: customer_country
    title: "Sold to Customer: Country"
    type: field_filter
    default_value: ''
    allow_multiple_values: true
    required: false
    ui_config:
      type: dropdown_menu
      display: popover
    explore: countries_md
    field: countries_md.country_name_landx

Modifier un tableau de bord spécifique

Pour modifier un filtre dans un tableau de bord spécifique, recherchez le fichier du tableau de bord et incluez le nom du filtre ainsi que les propriétés de sélection qui nécessitent une modification. Cette modification sera limitée au tableau de bord unique. Par exemple, pour modifier le titre, le type d'UI et l'affichage du filtre customer_country pour le otc_order_status.dashboard, seules ces propriétés seraient incluses dans le fichier du tableau de bord. Les propriétés restantes seraient héritées du modèle étendu.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

  filters:
  - name: customer_country
    title: "Customer Country"
    ui_config:
      type: dropdown_menu
      display: inline

Pour en savoir plus sur la création et la modification de tableaux de bord LookML, consultez la section Créer des tableaux de bord LookML.