Looker Blocks anpassen

Auf dieser Seite finden Sie eine Übersicht über Best Practices und Beispiele dazu, wie Sie die folgenden Cortex Framework Looker-Blöcke an Ihre spezifischen Geschäftsanforderungen anpassen können:

Installation

Es gibt verschiedene Möglichkeiten, die Cortex Framework Looker-Blöcke zu installieren. Weitere Informationen finden Sie in der Dokumentation unter Looker-Blöcke bereitstellen. Wir empfehlen jedoch, das Repository zu forken, da dies die einfachste Methode ist, Blöcke an Ihre Geschäftsanforderungen anzupassen.

Die Looker-Blöcke für das Cortex Framework wurden in einem mehrschichtigen Ansatz erstellt, bei dem jede Ebene der vorherigen Ebene ein inkrementelles Logikelement hinzufügt:

Basisebene: Maschinell generierte LookML-Ansichten, die auf Quelltabellen verweisen.
Core Layer: Manuelle Änderungen, mit denen neue Felder hinzugefügt oder Felder der Basisebene geändert werden.
Logische Ebene: Hier können Sie Definitionen und Joins für verschiedene Ansichten ansehen.

Die Verwendung von Verfeinerungen ist für diesen mehrschichtigen Ansatz und für die Anpassung von entscheidender Bedeutung. Um dem DRY-Prinzip (Do Not Repeat Yourself) zu folgen, werden extends und constants verwendet. Dynamische Inhalte für Labels, SQL-Anweisungen, HTML- und Linkattribute werden mit der Liquid-Vorlagensprache generiert.

Allgemeine Best Practices von Google:

Dateien und Ordner organisieren

Im Looker-Block stellt jeder Ordner eine Sammlung von Objekttypen dar, z. B. Ansichten, Explores und Dashboards. Jedes einzelne Objekt wird in einer separaten Datei definiert. Der Projektstamm enthält die folgenden wichtigen Dateien:

.model-Datei
Manifestdatei
README- und andere Markdown-Dateien
Marketplace-Dateien (wenn der Block auch im Looker Marketplace verfügbar ist)

Dateibrowser

Abbildung 1. Beispiel für die Ordnerstruktur im Looker-Block.

Modell

Durch die modulare Dateiverwaltung wird die Datei model des Projekts mit den folgenden Parametern schlank gehalten:

connection
include

Folgende Dateitypen sind enthalten:
- Komponenten (Datengruppen, named_value_formats, falls relevant)
- Explores (Explores sind nicht in der Modelldatei definiert)
- Dashboards

Die include-Anweisungen für die im Block verwendeten Ansichten werden in jeder einzelnen Explore-Datei definiert und nicht an diesem Speicherort, wie im folgenden Beispiel gezeigt:

connection: "@{CONNECTION_NAME}"

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

Manifest

In der Manifestdatei werden die Konstanten angegeben, auf die im gesamten Projekt verwiesen wird. Hier einige Beispiele für die Konstanten, die für unsere Blöcke verwendet werden:

Verbindungsname
Projekt-ID
Berichts-Dataset

In Cortex Framework-Looker-Blöcken werden auch Konstanten verwendet, um Folgendes zu definieren:

Labels anzeigen
Feldlabels
HTML-Formate
URL-Links
Dashboardnamen

Prüfen Sie die für den Looker-Block definierten Konstanten und passen Sie die Werte nach Bedarf an. Änderungen werden überall dort übernommen, wo auf die Konstante verwiesen wird.

Nutzerattribute

Für einige Looker-Blöcke müssen Nutzerattribute von einem Administrator in der Looker-Instanz definiert werden. Mit diesen Benutzerattributen für Standardsprache oder ‑währung können Sie die Darstellung von Dashboards für einzelne Nutzer oder Gruppen anpassen. Weitere Informationen zu den erforderlichen Nutzerattributen finden Sie in der Übersicht für die einzelnen Blöcke.

Aufrufe

Ansichten im Ordner „Base“ werden automatisch mit „Ansicht aus Tabelle erstellen“ generiert. Diese Dateien wurden nur geringfügig geändert:

Projekt-ID und Dataset-Name wurden durch Konstanten ersetzt.
Ansichten, die auf Nested Records basieren, wurden in separate Dateien verschoben.
Alle unnötigen Drilldown-Felddefinitionen wurden entfernt.

Wichtige Änderungen an diesen Ansichten, z. B. Labels, neue Dimensionen und Messwerte, wurden im Ordner Core mit Verfeinerungen, Erweiterungen oder abgeleiteten Tabellen vorgenommen.

Im Kernordner werden Ansichten mit einem Suffix benannt, das den Typ der Ansicht angibt:

_rfn für die Verfeinerung.
_ext für Ansicht, die eine Erweiterung erfordert.
_sdt für SQL-basierte abgeleitete Tabelle.
_ndt für die native abgeleitete Tabelle.
_pdt für persistente abgeleitete Tabellen.
_xvw für Ansichten, in denen auf Felder aus mehreren Ansichten verwiesen wird.

Beispiel für Suffix

Abbildung 2: Beispiel für ein Suffix, das den Ansichtstyp angibt.

Jede Ansichtsdefinition beginnt mit Anmerkungen, die Hintergrundinformationen wie Beschreibungen, Quellen, Referenzen, erweiterte Felder und andere relevante Hinweise enthalten.

Annotationen

Abbildung 3. Beispiel für Anmerkungen in einer Ansichtsdefinition.

Verschachtelte wiederkehrende Datensätze

Für zugrunde liegende Tabellen mit verschachtelten wiederholten Datensätzen erstellt Looker separate Ansichten, um diese Datensätze zu entnesten. Im Oracle EBS Looker-Block hat die Tabelle sales_orders beispielsweise ein verschachteltes wiederholtes Struct mit dem Namen lines. In Looker werden diese als zwei separate Ansichten behandelt: sales_orders und sales_orders__lines.

Wenn Sie diese nicht verschachtelten Datensätze in Looker Studio zusammenführen möchten, müssen Sie den Join mit dem Attribut sql in Verbindung mit dem Befehl UNNEST definieren.

UNNEST-Befehl

Abbildung 4: Beispiel für einen Join mit dem Attribut „sql“ in Verbindung mit dem UNNEST-Befehl.

Weitere Informationen finden Sie unter Nested BigQuery Data in Looker modeln.

Looker-Block-Code aufrufen und verstehen

Die Looker-Blöcke des Cortex Framework enthalten ausführliche Kommentare in den Ansichten und anderen Objekten. Um die Codenavigation und das Codeverständnis zu verbessern, empfiehlt es sich, die Option „LookML einblenden“ in der LookML-Entwicklungsumgebung zu verwenden.

LookML-Abschnitte ein- und ausblenden

Abbildung 5. Klicken Sie auf „LookML einblenden“.

LookML entfalten

Abbildung 6. Klicken Sie, um den LookML-Code aufzuklappen.

Nochmal falten

Abbildung 7. Klicken Sie noch einmal, um den LookML-Code wieder zu minimieren.

Felder

Der Begriff field bezieht sich auf Objekte wie dimension, measure, filter oder parameter. Bei diesen neueren Blöcken haben wir folgende Grundsätze berücksichtigt:

Dimensionen werden mit snake_case benannt (Kleinbuchstaben und Unterstrich zwischen Wörtern). Beispiel: customer_name
Spaltennamen aus zugrunde liegenden Tabellen werden verwendet, um Dimensionen zu benennen. Labels können Dimensionen zugewiesen werden, um ihnen einen geschäftsfreundlichen Namen zu geben. Eine Dimension mit dem Namen division_hdr_spart kann beispielsweise als „Division ID“ bezeichnet werden.
Bei Tabellen mit vielen Spalten sind Felder standardmäßig ausgeblendet. Legen Sie mit einer Verfeinerung der Ansicht die hidden-Property für die Teilmenge der Felder, die in einem Explore angezeigt werden sollen, auf „no“ fest. Wenn ein Feld nicht wie erwartet angezeigt wird, kann das Problem durch Bearbeiten dieser Feldeigenschaft behoben werden.
Die Attribute View_label und group_label werden verwendet, um Felder in einem Explore zu organisieren, sofern dies möglich ist.
Für Felder, die in mehreren Ansichten verwendet werden, werden Eigenschaften wie das Label in einer „gemeinsamen“ Ansicht festgelegt, die dann in andere Ansichten erweitert wird. So wird die Definition der Property zentralisiert und die Wiederverwendbarkeit gefördert. Alle erforderlichen Änderungen werden in der Ansicht „common“ verwaltet. So wird dafür gesorgt, dass Änderungen in allen Ansichten berücksichtigt werden, in denen die Ansicht „common“ erweitert wird.
Parameter, die in mehreren Explores verwendet werden, oder Felder, die auf mehrere Ansichten verweisen, werden in einer Ansicht mit dem Suffix _xvw definiert, die nur Felder enthält. Weitere Informationen finden Sie unter Inkonsistenzen in Explores vermeiden.

Beispiele bearbeiten

In diesem Abschnitt finden Sie Beispiele für gängige Anpassungen.

Feld einblenden

Die Basisansicht umfasst alle Dimensionen aus einer zugrunde liegenden Tabelle. Wenn die meisten Dimensionen nicht sichtbar sein müssen, wird eine Verfeinerung verwendet, um alle Felder standardmäßig auszublenden. Dazu muss die fields_hidden_by_default-Property auf „yes“ festgelegt werden. Die Teilmenge der Felder, die für die enthaltenen LookML-Dashboards relevant sind, wurde wieder eingeblendet. Im folgenden Beispiel wird eine Basisansicht mit dem Namen sales_orders mit einer Dimension namens item_posnr betrachtet.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

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

Die Verfeinerung dieser Ansicht wird in einer Datei mit dem Suffix _rfn definiert. Durch die Verfeinerung wird die Ansichtseigenschaft fields_hidden_by_default auf „yes“ gesetzt. Das bedeutet, dass alle Felder anfangs ausgeblendet sind. Wenn Sie das Feld item_posnr in der Ansicht sehen möchten, legen Sie die Eigenschaft „hidden“ auf „no“ fest.

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Label der Parameteransicht ändern

Mehrere Looker-Blöcke verwenden eine gemeinsame Gruppe von Parametern, die in einer separaten Datei definiert sind. Der Oracle EBS-Block verwendet beispielsweise die Datei otc_common_parameters_xvw. In dieser Ansicht wird das Label „🔍 Filter“ angezeigt, das als Konstante in der Manifestdatei definiert ist.

So ändern Sie dieses Label:

Suchen Sie in der Manifestdatei nach der Konstanten label_view_for_filters.
Bearbeiten Sie den Wert der Konstanten entsprechend dem ausgewählten Label.
Speichern Sie die Manifestdatei. Die Änderung wird automatisch überall übernommen, wo auf die label_view_for_filters-Konstante verwiesen wird.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

Alternativ können Sie zur Ansicht otc_common_parameters_xvw wechseln und die Property „label“ auf den gewünschten Wert bearbeiten.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Neue Messung hinzufügen

Neue Maßnahmen können direkt der entsprechenden Optimierung hinzugefügt werden. Im folgenden Beispiel wird der Verfeinerung für Kundenaufträge eine neue Messung hinzugefügt:

view: +sales_orders {

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

Zweite Filterebene hinzufügen

Neue Verfeinerungen können auf vorhandenen Verfeinerungen aufbauen. Betrachten Sie die Verfeinerung von sales_orders in der Datei sales_orders_rfn.view, durch die die Messung average_sales erstellt wird, wie im folgenden Beispiel:

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

So erstellen Sie eine zweite Verfeinerungsdatei:

Neue Datei für die Verfeinerung erstellen: Geben Sie ihr den Namen sales_orders_rfn2.view.
Erste Datei zur Verfeinerung einbeziehen: Alle Definitionen aus sales_orders_rfn werden in sales_orders_rfn2 aufgenommen.
Label-Attribut bearbeiten: Ändern Sie das Attribut label von average_sales in „average spend“ (durchschnittliche Ausgaben) oder ein anderes ausgewähltes Label.

Neue Dimension hinzufügen: Fügen Sie den Code für die neue Dimension in die sales_orders_rfn2.view-Datei ein.

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

Zweite Datei für die Verfeinerung in Explore einbeziehen: Dadurch werden alle Definitionen und Verbesserungen aus sales_orders_rfn2 in das Explore aufgenommen.
```
include: "/views/core/sales_orders_rfn2.view"
explore: sales_orders {
}
```

Neue Optimierungsebene erstellen

Die Verfeinerung einer beliebigen Basisansicht, die im Cortex Framework Looker-Block definiert ist, kann ersetzt werden, wenn sie nicht Ihren spezifischen Anforderungen entspricht. Die Datei _rfn kann direkt bearbeitet werden, um unnötige Felddefinitionen zu entfernen oder neue hinzuzufügen.

Alternativ können Sie eine neue Datei für die Verfeinerung erstellen:

Neue Datei für die Verfeinerung erstellen: Geben Sie ihr den Namen sales_invoices_rfn und speichern Sie sie.
Basisansicht einbeziehen:Dadurch werden alle Definitionen aus der Basisansicht sales_invoices in sales_invoices_rfn aufgenommen.

Gewählte Anpassungen hinzufügen: Definieren Sie auch eine Dimension als Primärschlüssel.

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) ;;
  }
}

Neuen Filter in den Explore einfügen: Verwenden Sie die neue Datei in der Property include anstelle des Filters, der im Cortex Framework Looker-Block bereitgestellt wird.
```
include: "/views/my_customizations/sales_invoices_rfn.view"

explore: sales_invoices {
}
```

LookML-Dashboard-Filter bearbeiten

Die gemeinsamen Dashboard-Filter, die in mehreren LookML-Dashboards verwendet werden, werden in einem Dashboard mit dem Suffix _template definiert und in jedes Dashboard übernommen. Nach der Erweiterung können die Filterobjekte nach Bedarf für ein bestimmtes Dashboard geändert werden.

Alle Dashboards bearbeiten

Wenn Sie den Filtertyp für alle Dashboards ändern möchten, suchen Sie die Vorlagendatei, in der der Filter definiert ist. Bearbeiten Sie den Typ und die Anzeigeeigenschaften von ui_config entsprechend den ausgewählten Einstellungen. Diese Änderung gilt für alle Dashboards, die die Vorlage erweitern. Hier ein Beispiel für 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

Bearbeitung für ein bestimmtes Dashboard

Wenn Sie einen Filter für ein bestimmtes Dashboard ändern möchten, suchen Sie die Dashboard-Datei und geben Sie den Filternamen zusammen mit den auszuwählenden Eigenschaften an, die geändert werden müssen. Diese Änderung ist auf das einzelne Dashboard beschränkt. Wenn Sie beispielsweise den Titel, den UI-Typ und die Darstellung des Filters customer_country für otc_order_status.dashboard ändern möchten, würden nur diese Eigenschaften in die Dashboard-Datei aufgenommen. Die verbleibenden Eigenschaften werden von der erweiterten Vorlage übernommen.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

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

Weitere Informationen zum Erstellen und Ändern von LookML-Dashboards finden Sie unter LookML-Dashboards erstellen.