Personaliza los bloques de Looker

En esta página, se proporciona una descripción general de las prácticas recomendadas y ejemplos para adaptar los siguientes bloques de Looker de Cortex Framework a tus requisitos comerciales específicos:

Instalación

Puedes instalar los bloques de Looker de Cortex Framework de varias maneras, como se detalla en la documentación sobre la implementación de bloques de Looker. Sin embargo, te recomendamos que bifurques el repositorio como el método más sencillo para personalizar los bloques y adaptarlos a tus necesidades comerciales.

Los bloques de Looker de Cortex Framework se crearon con un enfoque en capas, en el que cada capa agrega una pieza de lógica incremental a la capa anterior:

Capa base: Vistas de LookML generadas por máquina que hacen referencia a tablas de origen
Capa principal: Cambios escritos a mano que agregan campos nuevos o modifican los campos de la capa base
Capa lógica: Definiciones de exploración y uniones en diferentes vistas

El uso de refinamientos es clave para este enfoque en capas y para la personalización. Y para seguir el principio DRY (no te repitas), se aprovechan las extensiones y las constantes. El contenido dinámico de las etiquetas, las instrucciones SQL, el HTML y las propiedades de los vínculos se genera con el lenguaje de plantillas Liquid.

Prácticas recomendadas generales de Google:

Organización de archivos y carpetas

Dentro del bloque de Looker, cada carpeta representa una colección de tipos de objetos (como vistas, exploraciones, paneles y otros). Cada objeto individual se define en un archivo separado. La raíz del proyecto contiene los siguientes archivos clave:

Archivo .model
Archivo de manifiesto
README y otros archivos Markdown
Archivos de Marketplace (si el bloque también está disponible en Looker Marketplace)

Navegador de archivos

Figura 1. Ejemplo de organización de carpetas dentro del bloque de Looker

Modelo

La administración modular de archivos hace que el archivo model del proyecto sea más eficiente con los siguientes parámetros:

conexión
include

Los tipos de archivos incluidos son los siguientes:
- Componentes (grupos de datos, named_value_formats cuando corresponda)
- Exploraciones (las exploraciones no se definen en el archivo del modelo)
- Paneles

Las instrucciones include para las vistas utilizadas en el bloque se definen dentro de cada archivo de exploración individual, en lugar de en esta ubicación, como se muestra en el siguiente ejemplo:

connection: "@{CONNECTION_NAME}"

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

Manifiesto

En el archivo de manifiesto, se especifican las constantes a las que se hace referencia en todo el proyecto. Algunos ejemplos de las constantes que se usan para nuestros bloques son los siguientes:

Nombre de la conexión
ID del proyecto
Conjunto de datos de informes

Los bloques de Looker de Cortex Framework también usan constantes para definir lo siguiente:

Ver etiquetas
Etiquetas de campo
Formatos HTML
Vínculos de URL
Nombres de panel

Revisa las constantes definidas para el bloque de Looker y modifica cualquiera de los valores para que coincidan con tus necesidades. Los cambios se aplican en cualquier lugar al que se haga referencia a la constante.

Atributos de usuario

Algunos de los bloques de Looker requieren atributos de usuario que un administrador defina en la instancia de Looker. Estos atributos de usuario para el idioma o la moneda predeterminados te permiten personalizar la forma en que se muestran los paneles por usuario o grupo. Consulta la descripción general de cada bloque para obtener más información sobre los atributos de usuario obligatorios.

Vistas

Las vistas que se encuentran en la carpeta Base son las que se generan automáticamente con Crear vista desde la tabla. Estos archivos se modificaron mínimamente:

Se reemplazaron el ID del proyecto y el nombre del conjunto de datos por constantes.
Se movieron las vistas basadas en registros anidados a archivos separados.
Se quitaron las definiciones de campos de detalles innecesarias.

Las modificaciones significativas de estas vistas, como las etiquetas, las dimensiones y las métricas nuevas, se crearon en la carpeta Core con refinamientos, extensiones o tablas derivadas.

Dentro de la carpeta principal, las vistas se nombran con un sufijo que indica el tipo de vista que es:

_rfn para el refinamiento
_ext para la vista que requiere extensión
_sdt para la tabla derivada basada en SQL
_ndt para la tabla derivada nativa
_pdt para la tabla derivada persistente
_xvw para la vista que hace referencia a campos de varias vistas

Ejemplo de sufijo

Figura 2. Ejemplo de sufijo que indica el tipo de vista

Cada definición de vista comienza con anotaciones que proporcionan información de contexto, incluidas descripciones, fuentes, referencias, campos extendidos y otras notas relevantes.

Anotaciones

Figura 3. Ejemplo de anotaciones dentro de una definición de vista

Registros repetidos anidados

Para las tablas subyacentes que contienen registros repetidos anidados, Looker crea vistas separadas para desanidar estos registros. Por ejemplo, en el bloque de Looker de Oracle EBS, la tabla sales_orders tiene una estructura repetida anidada llamada lines. Looker los trata como dos vistas distintas views: sales_orders y sales_orders__lines.

Para unir estos registros desanidados dentro de la exploración, debes definir la unión con la propiedad sql junto con el comando UNNEST.

Comando UNNEST

Figura 4. Ejemplo de unión con la propiedad "sql" junto con el comando UNNEST

Para obtener más información, consulta Cómo modelar datos anidados de BigQuery en Looker.

Navega y comprende el código del bloque de Looker

Los bloques de Looker de Cortex Framework contienen comentarios extensos en las vistas y otros objetos. Para mejorar la navegación y la comprensión del código, se recomienda usar la opción Fold LookML disponible en el entorno de desarrollo de LookML.

Cómo plegar LookML

Figura 5. Haz clic en Fold LookML

Desplegar LookML

Figura 6. Haz clic para desplegar el LookML

Vuelve a plegar

Figura 7. Haz clic para volver a plegar el LookML

Campos

El término field hace referencia a objetos como dimension, measure, filter o parameter. Dentro de estos bloques más nuevos, seguimos estos principios:

Las dimensiones se nombran con snake_case (minúsculas y guion bajo entre palabras). Por ejemplo: customer_name.
Los nombres de las columnas de las tablas subyacentes se usan para nombrar las dimensiones. Se pueden aplicar etiquetas a las dimensiones para proporcionarles un nombre apto para la empresa. Por ejemplo, una dimensión llamada division_hdr_spart se puede etiquetar como "ID de división".
En el caso de las tablas con muchas columnas, los campos están ocultos de forma predeterminada. Con un refinamiento de la vista, establece la propiedad hidden en "no" para el subconjunto de campos que se mostrarán en una exploración. Si un campo no aparece como se esperaba, editar esta propiedad del campo puede resolver el problema.
Las propiedades View_label y group_label se usan para organizar los campos dentro de una exploración, cuando corresponda.
Para los campos que se utilizan en varias vistas, las propiedades como la etiqueta se establecen dentro de una vista "común", que luego se extiende a otras vistas. Este enfoque centraliza la definición de la propiedad, lo que promueve la reutilización. Cualquier modificación necesaria se administra dentro de la vista "común", lo que garantiza que los cambios se reflejen en todas las vistas en las que se extiende la vista "común".
Los parámetros que se usan en varias exploraciones o campos que hacen referencia a varias vistas se definen en una vista solo de campo con el sufijo _xvw. Para obtener más información, consulta Cómo evitar inconsistencias en las exploraciones.

Ejemplos de edición

En esta sección, se proporcionan ejemplos de personalizaciones comunes.

Cómo mostrar un campo

La vista base abarca todas las dimensiones de una tabla subyacente. Cuando no es necesario que la mayoría de las dimensiones sean visibles, se usa un refinamiento para ocultar todos los campos de forma predeterminada. Para ello, se establece la propiedad fields_hidden_by_default en "yes". Se mostró el subconjunto de campos relevantes para los paneles de LookML incluidos. En el siguiente ejemplo, se considera una vista base llamada sales_orders con una dimensión llamada item_posnr.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

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

El refinamiento de esta vista se define en el archivo con el sufijo _rfn. El refinamiento establece la propiedad de vista fields_hidden_by_default en "yes", lo que significa que todos los campos se ocultan inicialmente. Para mostrar el campo item_posnr en la vista, establece la propiedad oculta en "no".

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Cómo cambiar la etiqueta de la vista de parámetros

Varios bloques de Looker usan un conjunto compartido de parámetros definidos en un archivo independiente. Por ejemplo, el bloque de Oracle EBS usa el archivo otc_common_parameters_xvw. Esta vista muestra la etiqueta "🔍 Filtros", que se define como una constante dentro del archivo de manifiesto.

Para modificar esta etiqueta, haz lo siguiente:

Ubica la constante label_view_for_filters en el archivo de manifiesto.
Edita el valor de la constante con la etiqueta que elegiste.
Guarda el archivo de manifiesto. El cambio se reflejará automáticamente en cualquier lugar al que se haga referencia a la constante label_view_for_filters.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

Como alternativa, navega a la vista otc_common_parameters_xvw y edita la propiedad "label" con el valor elegido.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Cómo agregar una métrica nueva

Se pueden agregar métricas nuevas directamente al refinamiento pertinente. En el siguiente ejemplo, se muestra una métrica nueva agregada al refinamiento de los pedidos de ventas:

view: +sales_orders {

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

Cómo agregar una segunda capa de refinamiento

Se pueden crear refinamientos nuevos a partir de los existentes. Considera el refinamiento de sales_orders en el archivo sales_orders_rfn.view, que crea la métrica average_sales como en el siguiente ejemplo:

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

Para crear un segundo archivo de refinamiento, haz lo siguiente:

Crea un archivo de refinamiento nuevo: asígnale el nombre sales_orders_rfn2.view.
Incluye el primer archivo de refinamiento: Esto incorporará todas las definiciones de sales_orders_rfn en sales_orders_rfn2.
Edita la propiedad de etiqueta: Cambia la propiedad label de average_sales a "gasto promedio" o cualquier otra etiqueta elegida.

Agrega una dimensión nueva: Incluye el código de la dimensión nueva en el sales_orders_rfn2.view archivo.

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

Incluye el segundo archivo de refinamiento en la exploración: Esto incorporará todas las definiciones y mejoras de sales_orders_rfn2 en la exploración.
```
include: "/views/core/sales_orders_rfn2.view"
explore: sales_orders {
}
```

Cómo crear una capa de refinamiento nueva

Se puede reemplazar el refinamiento de cualquier vista base definida dentro del bloque de Looker de Cortex Framework si no cumple con tus requisitos específicos. El archivo _rfn se puede editar directamente para quitar definiciones de campos innecesarias o agregar otras nuevas.

Como alternativa, crea un archivo de refinamiento nuevo:

Crea un archivo de refinamiento nuevo: asígnale el nombre sales_invoices_rfn y guárdalo.
Incluye la vista base: Esto incorporará todas las definiciones de la vista base sales_invoices en sales_invoices_rfn.

Agrega las personalizaciones elegidas: Asegúrate de definir también una dimensión como clave primaria.

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

Incluye el nuevo refinamiento en la exploración: Usa el archivo nuevo en la propiedad include en lugar del refinamiento proporcionado en el bloque de Looker de Cortex Framework.
```
include: "/views/my_customizations/sales_invoices_rfn.view"

explore: sales_invoices {
}
```

Cómo editar los filtros del panel de LookML

El conjunto común de filtros de panel que se usa en varios paneles de LookML se define en un panel con el sufijo _template y se extiende a cada panel. Una vez extendidos, los objetos de filtro se pueden modificar según sea necesario para un panel específico.

Edición para todos los paneles

Para cambiar el tipo de filtro de todos los paneles, ubica el archivo de plantilla que define el filtro. Edita el tipo ui_config y muestra las propiedades con la configuración elegida. Este cambio se aplicará a todos los paneles que extiendan la plantilla. A continuación, se muestra un ejemplo 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

Edición para un panel específico

Para modificar un filtro en un panel específico, ubica el archivo del panel e incluye el nombre del filtro junto con las propiedades de selección que requieren modificación. Este cambio se limitará al panel único. Por ejemplo, para cambiar el título y el tipo de IU y la visualización del filtro customer_country para el otc_order_status.dashboard, solo se incluirían estas propiedades en el archivo del panel. Las propiedades restantes se heredarían de la plantilla extendida.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

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

Para obtener más información sobre la creación y modificación de paneles de LookML, consulta Cómo crear paneles de LookML.