Cette page a été traduite par l'API Cloud Translation.

Personnaliser les blocs Looker

Cette page présente les bonnes pratiques et des exemples sur la façon d'adapter les Looker Blocks du framework Cortex suivants à vos exigences métier spécifiques:

Installation

Vous pouvez installer les blocs Looker du framework Cortex de plusieurs manières, comme indiqué dans la documentation Déploiement des blocs Looker. Toutefois, nous vous recommandons de créer un fork du dépôt, car il s'agit de la méthode la plus simple pour personnaliser les blocs en fonction de vos besoins métier.

Les blocs Looker du framework Cortex ont été créés selon une approche en couches, où chaque couche ajoute une partie logique incrémentielle à la couche précédente:

Couche de base: vues LookML générées automatiquement qui font référence à des tables sources.
Couche de base: modifications manuscrites qui ajoutent des champs ou modifient les champs de la couche de base.
Couche logique: explorez les définitions et les jointures dans différentes vues.

L'utilisation de affinages est essentielle à cette approche en couches et à la personnalisation. Pour respecter le principe DRY (Don't 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 Google:

Organisation des fichiers et des dossiers

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

Fichier .model
Fichier manifeste
Fichiers README et autres fichiers Markdown
Fichiers du 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 rend le fichier model du projet allégé avec les paramètres suivants:

connexion
include

Voici les types de fichiers inclus:
- Composants (datagroups, named_value_formats le cas échéant)
- Explorations (les explorations ne sont pas définies dans le fichier de modèle)
- Tableaux de bord

Les instructions include pour les vues utilisées dans le bloc sont définies dans chaque fichier d'exploration individuel, et non à cet emplacement, comme illustré dans l'exemple suivant:

connection: "@{CONNECTION_NAME}"

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

Fichier manifeste

Le fichier manifeste spécifie les constantes référencées tout au long d'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 de Cortex Framework utilisent également des constantes pour définir les éléments suivants:

Afficher les étiquettes
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 des 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 "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:

Remplacement de l'ID de projet et du nom de l'ensemble de données par des constantes.
Les vues basées sur des enregistrements imbriqués ont été déplacées vers des fichiers distincts.
Suppression des définitions de champs de drill inutiles.

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

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

_rfn pour affiner.
_ext pour la vue nécessitant une extension.
_sdt pour une table dérivée basée sur SQL.
_ndt pour les tables dérivées natives.
_pdt pour les tables dérivées persistantes.
_xvw pour les champs de référence de vue à partir 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 Exemples 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 éliminer ces imbrications. Par exemple, dans le bloc Looker Oracle EBS, la table sales_orders contient une struct 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 non imbriqués dans l'exploration, vous devez définir la jointure à l'aide de la propriété sql en association avec la commande UNNEST.

Commande UNNEST

Figure 4. Exemple de jointure à l'aide de la propriété "sql" en association avec la commande UNNEST.

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

Parcourir et comprendre le code des blocs Looker

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

Code LookML pour les plis

Figure 5 Cliquez sur "Plier le code LookML".

Déplier le code LookML

Figure 6. Cliquez pour développer le code LookML.

Plier à nouveau

Figure 7 Cliquez pour réduire à nouveau le code LookML.

Champs

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

Les dimensions sont nommées en 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. Vous pouvez appliquer des libellés aux dimensions pour leur donner un nom plus facile à retenir. Par exemple, une dimension nommée division_hdr_spart peut être libellée "ID de division".
Pour les tableaux comportant de nombreuses colonnes, les champs sont masqués par défaut. À l'aide d'un affinement de la vue, définissez la propriété hidden sur "non" 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é.
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, des 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 "commun", ce qui garantit que les modifications sont reflétées dans toutes les vues où la vue "commun" est étendue.
Les paramètres utilisés dans plusieurs explorations ou les 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 Éviter les incohérences entre les explorations.

Exemples de modifications

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 affinement 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é rendu visible. 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
  }
}

L'affinage de cette vue est défini dans un fichier portant le suffixe _rfn. Le raffinement 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 "non".

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 EBS Oracle 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.
Remplacez la valeur de la constante par le 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" pour définir la valeur choisie.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Ajouter une mesure

Vous pouvez ajouter de nouvelles mesures directement à l'affinage concerné. L'exemple suivant montre une nouvelle mesure ajoutée à l'affinage des commandes commerciales:

view: +sales_orders {

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

Ajouter un deuxième niveau de précision

Vous pouvez créer de nouveaux raffinements à partir de ceux existants. Prenons l'exemple suivant pour examiner l'affinage 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 d'affinage:

Créez un fichier de raffinage et nommez-le sales_orders_rfn2.view.
Inclure le premier fichier d'affinage: toutes les définitions de sales_orders_rfn seront intégrées à sales_orders_rfn2.
Modifier la propriété de libellé: remplacez la propriété label de average_sales par "dépense moyenne" ou tout autre libellé de votre choix.

Ajouter une 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})
  }
}

Inclure un deuxième fichier d'affinage dans Explorer: 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 un calque d'affinage

L'affinage de toute vue de base définie dans le bloc de recherche du framework Cortex peut être remplacé s'il ne répond pas à vos exigences spécifiques. Le fichier _rfn peut être modifié directement pour supprimer des définitions de champ inutiles ou en ajouter.

Vous pouvez également créer un fichier d'affinage:

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

Ajoutez les personnalisations choisies: veillez également à définir une dimension en tant que 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) ;;
  }
}

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

explore: sales_invoices {
}
```

Modifier les filtres des tableaux 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 portant le suffixe _template et étendu dans 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.

Modification pour tous les tableaux de bord

Pour modifier le type de filtre pour tous les tableaux de bord, recherchez le fichier de modèle qui définit le filtre. Modifiez le type ui_config et les propriétés d'affichage en fonction des paramètres choisis. Cette modification s'appliquera à tous les tableaux de bord qui étendent le modèle. Voici un exemple de fichier 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 à modifier. Cette modification sera limitée à un seul tableau de bord. Par exemple, pour modifier le titre, le type d'UI et l'affichage du filtre customer_country pour 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.