Personalizar bloques de Looker

En esta página se ofrece un resumen de las prácticas recomendadas y ejemplos sobre cómo adaptar los siguientes bloques de Looker de Cortex Framework a los requisitos específicos de tu empresa:

Instalación

Puedes instalar los bloques de Looker de Cortex Framework de varias formas, tal como se explica en la documentación Implementar bloques de Looker. Sin embargo, te recomendamos que crees una bifurcación del repositorio como método más sencillo para personalizar los bloques y adaptarlos a las necesidades de tu empresa.

Los bloques de Looker de Cortex Framework se han creado con un enfoque por capas, en el que cada capa añade una parte incremental de lógica a la capa anterior:

  • Capa base: vistas de LookML generadas por la máquina que hacen referencia a tablas de origen.
  • Capa principal: cambios escritos a mano que añaden campos nuevos o modifican los campos de la capa base.
  • Capa lógica: consulta las definiciones y las combinaciones de diferentes vistas.

El uso de refinamientos es fundamental para este enfoque por capas y para la personalización. Además, para seguir el principio DRY (Do Not Repeat Yourself), se utilizan extends y constants. El contenido dinámico de las etiquetas, las instrucciones SQL, el HTML y las propiedades de los enlaces se genera mediante el lenguaje de plantillas Liquid.

Prácticas recomendadas generales de Google:

Organización de archivos y carpetas

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

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

Explorador de archivos

Imagen 1. Ejemplo de una carpeta de organización en el bloque de Looker.

Modelo

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

  1. conexión

  2. incluir

    Entre los tipos de archivos incluidos se encuentran los siguientes:

    • Componentes (grupos de datos, named_value_formats cuando sea pertinente)
    • Exploraciones (las exploraciones no se definen en el archivo de modelo)
    • Paneles de control

Las declaraciones include de las vistas utilizadas en el bloque se definen en cada archivo Explorar, 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"

Archivo de manifiesto

El archivo de manifiesto especifica las constantes a las que se hace referencia en todo el proyecto. Estos son algunos ejemplos de las constantes que se usan en nuestros bloques:

  • 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
  • Enlaces de URL
  • Nombres de los paneles de control

Revisa las constantes definidas para el bloque de Looker y modifica los valores que necesites. Los cambios se aplican en cualquier lugar donde se haga referencia a la constante.

Atributos de usuario

Algunos Looker Blocks requieren que un administrador defina atributos de usuario en la instancia de Looker. Estos atributos de usuario de idioma o moneda predeterminados le permiten personalizar cómo se muestran los paneles de control 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 mediante CreateView from Table. Estos archivos se han modificado mínimamente:

  • Se han sustituido el ID del proyecto y el nombre del conjunto de datos por constantes.
  • Se han movido las vistas basadas en registros anidados a archivos independientes.
  • Se han eliminado las definiciones de campos de desglose innecesarias.

Se han creado modificaciones significativas en estas vistas, como etiquetas, nuevas dimensiones y medidas, en la carpeta Principal mediante refinamientos, extensiones o tablas derivadas.

En la carpeta principal, las vistas tienen un sufijo que indica el tipo de vista que es:

  • _rfn para acotar la búsqueda.
  • _ext para ver el contenido que requiere una extensión.
  • _sdt para tablas derivadas basadas en SQL.
  • _ndt para la tabla derivada nativa.
  • _pdt para la tabla derivada persistente.
  • _xvw para ver los campos de referencia de varias vistas.

Ejemplo de sufijo

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

Cada definición de vista empieza con anotaciones que proporcionan información general, como descripciones, fuentes, referencias, campos ampliados y otras notas relevantes.

Anotaciones

Imagen 3. Ejemplos de anotaciones en una definición de vista.

Registros repetidos anidados

En el caso de las tablas subyacentes que contienen registros repetidos anidados, Looker crea vistas independientes 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 trata estos elementos como dos vistas distintas: sales_orders y sales_orders__lines.

Para unir estos registros sin anidar en Explorar, debes definir la unión con la propiedad sql junto con el comando UNNEST.

Comando UNNEST

Imagen 4. Ejemplo de combinación con la propiedad "sql" junto con el comando UNNEST.

Para obtener más información, consulta el artículo Cómo modelar datos anidados de BigQuery en 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 Plegar LookML, disponible en el entorno de desarrollo de LookML.

Plegar LookML

Imagen 5. Hacer clic en Plegar LookML.

Desplegar LookML

Imagen 6. Haz clic para desplegar el LookML.

Volver a plegar

Imagen 7. Haz clic para volver a plegar el LookML.

Campos

El término field hace referencia a objetos como dimension, measure, filter o parameter. En estos bloques más recientes, hemos seguido estos principios:

  1. Las dimensiones se nombran con snake_case (letras minúsculas y guion bajo entre palabras). Por ejemplo: customer_name.
  2. Los nombres de las columnas de las tablas subyacentes se usan para asignar nombres a las dimensiones. Las etiquetas se pueden aplicar a las dimensiones para darles un nombre más adecuado para la empresa. Por ejemplo, una dimensión llamada division_hdr_spart puede etiquetarse como "ID de división".
  3. En las tablas con muchas columnas, los campos están ocultos de forma predeterminada. Con un refinamiento de la vista, asigna el valor "no" a la propiedad hidden en el subconjunto de campos que quieras mostrar en un Exploración. Si un campo no aparece como se esperaba, puede resolver el problema editando esta propiedad del campo.
  4. Las propiedades View_label y group_label se usan para organizar los campos de una exploración, si procede.
  5. En el caso de los campos que se utilizan en varias vistas, las propiedades como la etiqueta se definen en una vista "común", que posteriormente se extiende a otras vistas. Este enfoque centraliza la definición de la propiedad, lo que fomenta la reutilización. Las modificaciones necesarias se gestionan en la vista "common", lo que asegura que los cambios se reflejen en todas las vistas en las que se amplíe la vista "common".
  6. Los parámetros que se usan en varias exploraciones o los 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 el artículo Evitar inconsistencias en las exploraciones.

Editar ejemplos

En esta sección se incluyen ejemplos de personalizaciones habituales.

Mostrar un campo

La vista base incluye todas las dimensiones de una tabla subyacente. Cuando no es necesario que se vean la mayoría de las dimensiones, se usa un refinamiento para ocultar todos los campos de forma predeterminada. Para ello, se asigna el valor "yes" a la propiedad fields_hidden_by_default. Se ha mostrado 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 están ocultos al principio. Para mostrar el campo item_posnr en la vista, asigna el valor "no" a la propiedad hidden.

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

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. En esta vista se muestra la etiqueta "🔍 Filtros", que se define como una constante en el archivo de manifiesto.

Para modificar esta etiqueta, sigue estos pasos:

  1. Busca la constante label_view_for_filters en el archivo de manifiesto.
  2. Edita el valor de la constante con la etiqueta que hayas elegido.
  3. Guarda el archivo de manifiesto. El cambio se reflejará automáticamente en cualquier lugar donde se haga referencia a la constante label_view_for_filters.
Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

También puede ir a la vista otc_common_parameters_xvw y editar la propiedad "label" con el valor que quiera.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Añadir una nueva medida

Las nuevas medidas se pueden añadir directamente a la refinación correspondiente. En el siguiente ejemplo se muestra una nueva medida añadida al refinamiento de pedidos de ventas:

view: +sales_orders {

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

Añadir una segunda capa de refinamiento

Las nuevas acotaciones se pueden basar en las que ya tengas. Considera la mejora de sales_orders en el archivo sales_orders_rfn.view, que crea la medida 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:

  1. Crea un archivo de refinamiento: ponle el nombre sales_orders_rfn2.view.
  2. Incluir el primer archivo de refinamiento: se incorporarán todas las definiciones de sales_orders_rfn en sales_orders_rfn2.
  3. Editar la propiedad de la etiqueta: cambia la propiedad label de average_sales a "average spend" o a cualquier otra etiqueta que elijas.

  4. Añadir una dimensión: incluye el código de la nueva dimensión en el archivo 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})
  }
}

  5. Incluir el segundo archivo de refinamiento en Explorar: se incorporarán todas las definiciones y mejoras de sales_orders_rfn2 en Explorar.

    include: "/views/core/sales_orders_rfn2.view"
explore: sales_orders {
}

Crear una capa de acoplamiento nueva

El refinamiento de cualquier vista base definida en el framework de Cortex Looker Block se puede sustituir si no cumple tus requisitos específicos. El archivo _rfn se puede editar directamente para eliminar definiciones de campos innecesarias o añadir otras nuevas.

También puedes crear un archivo de refinamiento:

  1. Crea un archivo de refinamiento: llámalo sales_invoices_rfn y guárdalo.
  2. Incluye la vista base: se incorporarán todas las definiciones de la vista base sales_invoices en sales_invoices_rfn.

  3. Añade las personalizaciones elegidas: asegúrate de definir una dimensión como clave principal.

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

  4. Incluya la nueva mejora en Explorar: use el nuevo archivo en la propiedad include en lugar de la mejora proporcionada en el bloque de Looker de Cortex Framework.

    include: "/views/my_customizations/sales_invoices_rfn.view"

explore: sales_invoices {
}

Editar filtros de paneles de control de LookML

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

Editar todos los paneles de control

Para cambiar el tipo de filtro de todos los paneles de control, busca el archivo de plantilla que define el filtro. Edita el tipo ui_config y las propiedades de visualización con los ajustes que quieras. Este cambio se aplicará a todos los paneles de control que amplíen 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

Editar un panel de control específico

Para modificar un filtro en un panel de control específico, busca el archivo del panel de control e incluye el nombre del filtro junto con las propiedades select que requieran modificación. Este cambio se limitará a un solo panel de control. Por ejemplo, para cambiar el título, el tipo de interfaz de usuario y la visualización del customer_country filtro de otc_order_status.dashboard, solo se incluirían estas propiedades en el archivo del panel de control. Las propiedades restantes se heredarían de la plantilla ampliada.

- 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 cómo crear y modificar paneles de control de LookML, consulta el artículo Crear paneles de control de LookML.