Diese Seite wurde von der Cloud Translation API übersetzt.

Looker Blocks anpassen

Auf dieser Seite finden Sie Best Practices und Beispiele dazu, wie Sie die folgenden Looker-Blöcke des Cortex-Frameworks an Ihre spezifischen Geschäftsanforderungen anpassen können:

Installation

Es gibt mehrere Möglichkeiten, die Looker-Blöcke des Cortex-Frameworks zu installieren. Eine detaillierte Anleitung dazu finden Sie in der Dokumentation Looker-Blöcke bereitstellen. Wir empfehlen jedoch, das Repository zu forkieren, da dies die einfachste Methode ist, Blöcke an Ihre Geschäftsanforderungen anzupassen.

Die Looker-Blöcke des Cortex-Frameworks wurden in einem mehrschichtigen Ansatz erstellt, bei dem jede Schicht der vorherigen eine inkrementelle Logik hinzufügt:

Basisebene: Maschinell generierte LookML-Ansichten, die auf Quelltabellen verweisen.
Grundlage: Handschriftliche Änderungen, durch die neue Felder hinzugefügt oder Basisebenenfelder geändert werden.
Logische Ebene: Hier können Sie Definitionen und Joins in verschiedenen Ansichten untersuchen.

Die Verwendung von Optimierungen ist für diesen mehrstufigen Ansatz und für die Anpassung entscheidend. Um dem DRY-Prinzip (Don't Repeat Yourself, d. h. „Wiederhole dich nicht“) zu folgen, werden Erweiterungen und Konstanten eingesetzt. Dynamische Inhalte für Labels, SQL-Anweisungen, HTML- und Linkeigenschaften werden mit der Liquid-Vorlagensprache generiert.

Allgemeine Best Practices von Google:

Datei- und Ordnerorganisation

Innerhalb des Looker-Blocks steht jeder Ordner für eine Sammlung von Objekttypen (z. B. Ansichten, Explores, Dashboards usw.). 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 (falls der Block auch im Looker Marketplace verfügbar ist)

Dateibrowser

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

Modell

Mit der modularen Dateiverwaltung wird die model-Datei des Projekts mit den folgenden Parametern optimiert:

connection
include

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

Die include-Anweisungen für die im Block verwendeten Ansichten werden nicht an diesem Speicherort, sondern in jeder einzelnen Explore-Datei definiert, wie das folgende Beispiel zeigt:

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 Konstanten, die für unsere Blöcke verwendet werden:

Verbindungsname
Projekt-ID
Dataset für die Berichterstellung

In Looker-Blöcken für Cortex Framework werden außerdem Konstanten verwendet, um Folgendes zu definieren:

Labels anzeigen
Feldlabels
HTML-Formate
URL-Links
Dashboardnamen

Sehen Sie sich die für den Looker-Block definierten Konstanten an und ändern Sie die Werte nach Bedarf. Änderungen werden überall dort angewendet, 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 Nutzerattributen für die 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 zu den einzelnen Blöcken.

Aufrufe

Im Ordner „Base“ befinden sich Ansichten, die automatisch mit der Funktion „Ansicht aus Tabelle erstellen“ generiert wurden. Diese Dateien wurden nur geringfügig geändert:

Projekt-ID und Dataset-Namen durch Konstanten ersetzt.
Ansichten, die auf verschachtelten Einträgen basieren, wurden in separate Dateien verschoben.
Unnötige Definitionen für Drilldown-Felder wurden entfernt.

Im Ordner Core wurden mithilfe von Optimierungen, Erweiterungen oder abgeleiteten Tabellen erhebliche Änderungen an diesen Ansichten vorgenommen, z. B. Labels, neue Dimensionen und Messwerte.

Im Ordner „core“ werden Ansichten mit einem Suffix benannt, das den jeweiligen Ansichtstyp angibt:

_rfn für die Verfeinerung.
_ext für die Ansicht, für die eine Erweiterung erforderlich ist.
_sdt für SQL-basierte abgeleitete Tabelle
_ndt für native abgeleitete Tabelle.
_pdt für persistente abgeleitete Tabelle.
_xvw für Felder in der Ansicht, die auf Felder aus mehreren Ansichten verweisen.

Beispiel für ein Suffix

Abbildung 2 Beispiel für ein Suffix, das den Typ der Ansicht angibt.

Jede Datenansichtsdefinition beginnt mit Anmerkungen, die Hintergrundinformationen enthalten, darunter Beschreibungen, Quellen, Verweise, erweiterte Felder und andere relevante Hinweise.

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 entschachteln. Im Oracle EBS Looker-Block enthält die Tabelle sales_orders beispielsweise ein verschachteltes wiederholtes Struct namens lines. In Looker werden diese als zwei separate Ansichten behandelt: sales_orders und sales_orders__lines.

Wenn Sie diese nicht verschachtelten Datensätze im Explore zusammenführen möchten, müssen Sie die Zusammenführung mithilfe der Property sql in Verbindung mit dem Befehl „UNNEST“ definieren.

UNNEST-Befehl

Abbildung 4: Beispiel für eine Verbindung mit der Eigenschaft „sql“ in Verbindung mit dem Befehl „UNNEST“.

Weitere Informationen finden Sie unter Verschachtelte BigQuery-Daten in Looker modellieren.

Looker-Block-Code aufrufen und verstehen

Die Looker-Blöcke des Cortex-Frameworks enthalten umfangreiche Kommentare in den Ansichten und anderen Objekten. Um die Codenavigation und -Lesbarkeit zu verbessern, wird empfohlen, die Option „LookML minimieren“ zu verwenden, die in der LookML-Entwicklungsumgebung verfügbar ist.

LookML zusammenfalten

Abbildung 5 Klicken Sie auf „LookML minimieren“.

LookML entfalten

Abbildung 6. Klicken Sie, um die LookML zu maximieren.

Noch einmal falten

Abbildung 7. Klicken Sie noch einmal, um die LookML wieder einzublenden.

Felder

Der Begriff field bezieht sich auf Objekte wie dimension, measure, filter oder parameter. Bei diesen neueren Blöcken haben wir uns an folgenden Prinzipien orientiert:

Die Namen von Dimensionen werden im Kamel-Case (Kleinbuchstaben und Unterstrich zwischen den Wörtern) geschrieben. Beispiel: customer_name
Die Namen der Dimensionen werden aus den Spaltennamen der zugrunde liegenden Tabellen abgeleitet. Labels können auf Dimensionen angewendet werden, um ihnen einen nutzerfreundlichen Namen zu geben. Eine Dimension mit dem Namen division_hdr_spart kann beispielsweise als „Abteilungs-ID“ beschriftet werden.
Bei Tabellen mit vielen Spalten sind Felder standardmäßig ausgeblendet. Legen Sie mithilfe einer Ansichtsbegrenzung für die Teilmenge der Felder, die in einem Explore angezeigt werden sollen, die Property hidden auf „Nein“ 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 gegebenenfalls zu organisieren.
Für Felder, die in mehreren Ansichten verwendet werden, werden Eigenschaften wie das Label in einer „gemeinsamen“ Ansicht festgelegt, die anschließend in andere Ansichten erweitert wird. Bei diesem Ansatz wird die Definition der Property zentralisiert, was die Wiederverwendbarkeit fördert. Alle erforderlichen Änderungen werden in der Ansicht „Gemeinsam“ verwaltet. So werden Änderungen in allen Ansichten übernommen, in denen die Ansicht „Gemeinsam“ erweitert wird.
Parameter, die in mehreren Explores verwendet werden, oder Felder, die auf mehrere Ansichten verweisen, werden in einer reinen Feldansicht mit dem Suffix _xvw definiert. Weitere Informationen finden Sie unter Inkonsistenzen in Explores vermeiden.

Beispiele bearbeiten

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

Ausgeblendete Felder einblenden

Die Basisansicht umfasst alle Dimensionen aus einer zugrunde liegenden Tabelle. Wenn die meisten Dimensionen nicht sichtbar sein müssen, werden alle Felder standardmäßig mit einer Aufschlüsselung ausgeblendet. Legen Sie dazu für die Property fields_hidden_by_default den Wert „yes“ fest. Die für die enthaltenen LookML-Dashboards relevanten Felder wurden entsperrt. Im folgenden Beispiel wird eine Basisdatenansicht mit dem Namen sales_orders mit einer Dimension namens item_posnr verwendet.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

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

Die Verfeinerung dieser Ansicht ist in einer Datei mit dem Suffix _rfn definiert. Durch die Einschränkung wird die Ansichtseigenschaft fields_hidden_by_default auf „Ja“ gesetzt. Das bedeutet, dass alle Felder zu Beginn ausgeblendet sind. Wenn das Feld item_posnr in der Ansicht angezeigt werden soll, legen Sie für die Eigenschaft „Ausgeblendet“ den Wert „Nein“ fest.

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Label der Parameteransicht ändern

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

So ändern Sie dieses Label:

Suchen Sie in der Manifestdatei nach der Konstante label_view_for_filters.
Ändern Sie den Wert der Konstante in das ausgewählte Label.
Speichern Sie die Manifestdatei. Die Änderung wird automatisch überall dort übernommen, wo auf die Konstante label_view_for_filters verwiesen wird.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

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

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Neuen Messwert hinzufügen

Neue Messwerte können direkt der entsprechenden Verfeinerung hinzugefügt werden. Im folgenden Beispiel wird ein neues Messwert zur Filterung nach Kundenaufträgen hinzugefügt:

view: +sales_orders {

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

Zweite Ebene für die Filterung hinzufügen

Neue Einschränkungen können auf vorhandenen Einschränkungen basieren. Betrachten Sie die folgende Beispieldatei sales_orders_rfn.view mit der Messwertberechnung sales_orders, aus der das Messwert average_sales erstellt wird:

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

So erstellen Sie eine zweite Verfeinerungsdatei:

Erstellen Sie eine neue Datei für die Verfeinerung und geben Sie ihr den Namen sales_orders_rfn2.view.
Erste Verfeinerungsdatei einschließen: Dadurch werden alle Definitionen aus sales_orders_rfn in sales_orders_rfn2 übernommen.
Labeleigenschaft bearbeiten: Ändern Sie das Attribut label von average_sales in „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 Refine-Datei in Explore einschließen: Dadurch werden alle Definitionen und Verbesserungen aus sales_orders_rfn2 in das Explore einbezogen.
```
include: "/views/core/sales_orders_rfn2.view"
explore: sales_orders {
}
```

Neue Ebene für die Datenbereinigung erstellen

Die Verfeinerung einer im Cortex Framework-Looker-Block definierten Basisansicht 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:

Erstellen Sie eine neue Datei für die Verfeinerung. 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 übernommen.

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

Neue Einschränkung in die explorative Datenanalyse aufnehmen: Verwenden Sie die neue Datei in der Property include anstelle der Einschränkung, die 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.

Bearbeiten für alle Dashboards

Wenn Sie den Filtertyp für alle Dashboards ändern möchten, suchen Sie die Vorlagendatei, in der der Filter definiert ist. Bearbeiten Sie den ui_config-Typ und die Anzeigeeigenschaften gemäß 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

Bearbeiten für ein bestimmtes Dashboard

Wenn Sie einen Filter in einem bestimmten Dashboard ändern möchten, suchen Sie die Dashboarddatei und geben Sie den Filternamen zusammen mit den ausgewählten Eigenschaften ein, 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 customer_country-Filters für die otc_order_status.dashboard ändern möchten, werden nur diese Eigenschaften in die Dashboard-Datei aufgenommen. Die restlichen Properties 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.