Partager des données via un hub d'actions

En plus de diffuser du contenu vers des destinations intégrées de Looker, vous pouvez utiliser des actions (également appelées intégrations) pour diffuser du contenu vers des services tiers intégrés à Looker via un serveur de hub d'action.

Les actions diffusées via un serveur de hub d'action diffèrent des actions de données, qui sont définies par le paramètre LookML action.

Cette page vous présente les options de création d'actions personnalisées que vous pouvez demander à ajouter au Looker Action Hub ou à votre propre serveur d'actions privées. Cette page explique également comment créer un serveur Hub d'actions local pour tester vos actions personnalisées ou exécuter un serveur de hub d'action privé.

Le schéma ci-dessous illustre les options de workflow disponibles pour intégrer des actions via un hub d'action hébergé en mode privé ou via le hub d'action hébergé par Looker:

Une fois l'action ajoutée au hub d'actions, un administrateur Looker peut l'autoriser à diffuser du contenu Looker à ces services.

Vous pouvez également configurer plusieurs hubs d'action si vous souhaitez utiliser les intégrations de Looker via le Action Hub de Looker, et héberger vos propres actions privées ou personnalisées. Les actions liées à chaque hub d'action s'affichent sur la page Actions du panneau Administration.

Hub d'action Looker

Looker héberge et fournit Looker Action Hub, un serveur sans état qui implémente l'API Action de Looker et expose des actions populaires. Toutes les données que vos utilisateurs envoient à l'aide d'une action seront traitées temporairement sur le serveur Looker Action Hub plutôt que dans votre instance Looker.

Looker est déjà intégré à plusieurs services. Consultez la page de documentation Paramètres de l'administrateur – Actions pour savoir comment activer ces services.

Exigences concernant Looker Action Hub

Pour utiliser les intégrations Looker, Hub Action Hub doit pouvoir communiquer avec l'instance Looker et remplir ces exigences. Les administrateurs d'instances hébergées par le client devront peut-être prendre en compte des facteurs supplémentaires lorsqu'ils choisiront d'activer les intégrations Looker à partir de Looker Action Hub, en particulier les intégrations compatibles avec les résultats diffusés ou qui utilisent OAuth.

Looker Action Hub doit pouvoir envoyer et recevoir des requêtes API comme suit:

Si votre déploiement Looker ne peut pas répondre à ces requêtes ou si la fonctionnalité de liste d'autorisation d'adresses IP est activée sur votre instance Looker, envisagez de configurer un serveur de hub d'action local pour diffuser des actions Looker ou des actions personnalisées privées. Les administrateurs d'instances hébergées par le client peuvent également déployer un serveur d'action local spécifiquement pour les actions OAuth et par flux.

Requêtes depuis l'instance Looker vers le réseau Looker Action Hub

Les requêtes envoyées à actions.looker.com aboutissent à une adresse IP dynamique. Les requêtes sortantes provenant de l'instance Looker doivent pouvoir atteindre ces points de terminaison:

actions.looker.com/
actions.looker.com/actions/<name>/execute
actions.looker.com/actions/<name>/form

où name est le nom programmatique de l'action.

Requêtes envoyées par le navigateur de l'utilisateur Looker au réseau Looker Action Hub

Le navigateur de l'utilisateur Looker doit pouvoir envoyer des requêtes à ces points de terminaison Looker Action Hub (pour OAuth):

actions.looker.com/actions/<name>/oauth

où name est le nom programmatique de l'action.

Requêtes depuis le réseau Looker Action Hub vers l'instance Looker

Looker Action Hub doit envoyer des requêtes à l'instance Looker pour les actions compatibles avec les résultats diffusés ou utilisant OAuth.

Une action de streaming permet de consommer des requêtes qui fournissent tous les résultats. Les actions OAuth utilisent l'authentification par utilisateur via des flux OAuth 2.0. Les actions OAuth doivent stocker les identifiants utilisateur dans leur instance Looker source, car Looker Action Hub est sans état et mutualisé, et ne stockera aucun identifiant spécifique à l'utilisateur.

Les requêtes de Looker Action Hub vers une instance Looker prennent les formes suivantes:

GET <host_looker_url>/downloads/<random_40_char_token>
POST <host_looker_url>/action_hub_state/<random_40_char_token>

Ces URL sont générées directement sur l'instance Looker avant d'être envoyées à Looker Action Hub. Pour cette raison, Looker Action Hub doit pouvoir résoudre <host_looker_url> en adresse IP et envoyer des requêtes au réseau dans lequel se trouve votre instance Looker.

Looker Action Hub possède des adresses IP de sortie statiques dont les requêtes proviennent toujours : 35.153.89.114, 104.196.138.163 et 35.169.42.87. Les administrateurs d'instances hébergées par Looker qui ont activé la liste d'autorisation d'adresses IP doivent ajouter ces adresses IP pour utiliser les actions compatibles avec les résultats diffusés ou qui utilisent OAuth.

Remarques sur les instances hébergées par le client

Pour utiliser les intégrations Looker, Looker Action Hub doit pouvoir communiquer avec l'instance Looker et remplir ces exigences. Ce n'est pas toujours possible avec des instances Looker hébergées par le client, et ce pour diverses raisons. Si la communication bidirectionnelle entre le Looker Action Hub et l'instance Looker n'est pas possible, ce dernier peut présenter un comportement inattendu ou indésirable, tel que des requêtes suspendues ou des actions indisponibles.

Pour résoudre le problème potentiel de Looker Action Hub qui ne parvient pas à communiquer avec l'instance Looker, les administrateurs Looker peuvent implémenter l'une des solutions présentées ci-dessous. La solution adaptée ou la combinaison de solutions dépendra de l'architecture de l'instance Looker:

  • Si l'instance hébergée par le client ne peut pas être résolue par Looker Action Hub (c'est-à-dire que Looker Action Hub ne peut pas recevoir de requêtes de l'instance Looker), les administrateurs Looker peuvent consulter leur responsable de compte Looker pour activer la fonctionnalité de licence public_host_url. Cette fonctionnalité de licence révèle l'option de démarrage de --public-host-url, qui permet aux administrateurs de spécifier un nom d'hôte <public_host_url> pouvant être résolu, différent de l'instance <host_looker_url>. public_host_url remplace le nom d'hôte de certaines URL de rappel Looker Action Hub spécifiques et achemine ces URL de rappel via un proxy inverse dont le public_host_url est un nom pouvant être résolu publiquement. Ce proxy inverse n'accepte que les requêtes provenant des adresses IP de sortie statiques pour Looker Action Hub. Les administrateurs Looker qui utilisent cette méthode doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles Looker Action Hub envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.

  • Si l'URL de l'instance hébergée par le client peut être résolue par l'instance Looker, mais que Looker Action Hub ne peut pas envoyer de requêtes à l'instance Looker, les utilisateurs risquent de ne pas pouvoir configurer ni utiliser d'actions compatibles avec les résultats diffusés ou utilisant OAuth. Pour résoudre ce problème, les administrateurs Looker doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles le Looker Action Hub envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.

  • Si aucune des solutions mentionnées ci-dessus n'est appropriée pour l'architecture d'instance Looker, les administrateurs de Looker peuvent déployer un hub d'action hébergé par le client pour toutes les actions ou uniquement pour les actions compatibles avec les résultats diffusés ou qui utilisent OAuth.

  • Pour déployer un hub d'action hébergé par le client, vous devez vous assurer que le fichier JAR est hébergé sur un serveur public afin que Looker Action Hub puisse communiquer avec lui. Toutefois, Looker ne recommande pas cette solution.

Les actions OAuth et de traitement par flux peuvent également ne pas être utilisables sur une instance Looker hébergée par le client si l'instance utilise un certificat SSL émis par une autorité de certification qui ne figure pas sur cette liste.

Créer une action personnalisée

Cette section décrit les étapes à suivre pour écrire et tester une action personnalisée à l'aide du code source de Looker Action Hub. Pour voir des exemples de code fonctionnel, vérifiez les actions existantes dans le dépôt looker-open-source/actions sur GitHub.

Vous pouvez créer une action personnalisée de plusieurs façons:

  1. Configurer un dépôt de développement
  2. Écrire votre action
  3. Tester votre action
  4. Publication et activation de votre action, soit dans le Looker Action Hub, soit sur votre propre serveur Hub d'action privé

Comme pour toute action, vous devrez peut-être configurer vos modèles LookML avec des paramètres spécifiques avant de pouvoir utiliser l'action pour diffuser vos données.

Configurer un dépôt de développement

Looker Action Hub est un serveur Node.js écrit en TypeScript, une petite couche sur le code JavaScript moderne qui ajoute des informations de type pour détecter les erreurs de programmation. Si vous connaissez JavaScript, vous connaissez la plupart du langage TypeScript.

L'exécution de Looker Action Hub nécessite le logiciel suivant:

  • Node.js
  • Gestionnaire de versions de nœuds (NVM, pour sélectionner la bonne version de Node.js)
  • Yarn (pour gérer les dépendances)

Une fois que vous avez installé le logiciel requis, vous êtes prêt à configurer votre environnement de développement. L'exemple ci-dessous utilise Git.

  1. Clonez le dépôt looker-open-source/actions localement:

    git clone git@github.com:looker-open-source/actions.git

  2. Créez un répertoire avec le nom de votre action dans le répertoire actions/src/actions. Exemple :

    mkdir actions/src/actions/my_action

  3. Remplissez votre répertoire avec les fichiers dont vous avez besoin pour exécuter l'action. Consultez le dépôt d'actions GitHub pour obtenir un exemple de structure de fichiers.

Looker vous recommande également d'ajouter:

  • Un fichier README pour expliquer l'objectif et les moyens de l'authentification pour votre action
  • Icône PNG à afficher dans Looker Action Hub (ou hub d'action privé sur votre instance Looker) et dans les fenêtres de livraison de données Looker
  • Tous les fichiers de test que vous souhaitez exécuter sur votre code d'action (à ne pas confondre avec les tests d'action)

Écrire une action

Une exigence de conception pour le serveur Looker Action Hub est qu'il reste complètement sans état. Par conséquent, le stockage d'informations dans l'application ou le service d'action n'est pas autorisé. Toutes les informations requises pour effectuer l'action doivent être fournies dans les appels de requête du fichier d'action.

Le contenu exact du fichier d'action varie en fonction du service, du type ou du niveau de fonctionnement de l'action, et des formats de données ou de visualisation à spécifier. L'action peut également être configurée pour les flux d'autorisation OAuth 2.0.

Les fichiers d'action sont basés sur la méthode d'API /execute. Les requêtes de l'API Looker reçoivent un DataActionRequest chaque fois qu'un utilisateur exécute l'action dans Looker. Le DataActionRequest contient toutes les données et métadonnées nécessaires à l'exécution de votre action. Il existe également une méthode /form qui permet de collecter des informations supplémentaires auprès de l'utilisateur avant qu'il n'exécute l'action. Les champs que vous spécifiez dans /form s'afficheront dans le pop-up Send (Envoyer) ou Schedule (Planifier) lorsque les utilisateurs sélectionneront l'action comme destination de leur livraison de données.

Si vous utilisez l'API Looker Action, le format de ces paramètres peut sembler différent.

Lorsque vous rédigez votre fichier d'action, veillez à inclure au moins les paramètres obligatoires dans la définition de votre action:

Parameter Requis Description Type de données
name Yes Nom unique de l'action. Il doit être unique pour toutes les actions dans le Looker Action Hub. chaîne
url Yes URL absolue du point de terminaison /execute pour cette action. chaîne
label Yes Libellé lisible pour l'action. chaîne
supportedActionTypes Yes Liste des types d'actions acceptés par l'action. Les valeurs valides sont "cell", "query" et "dashboard". chaîne
formURL Non URL absolue du point de terminaison /form pour cette action. chaîne
description Non Description de l'action. chaîne
params Non Tableau parameters pour l'action. Incluez le nom, le libellé et la description au format de chaîne pour chaque paramètre. Voici les champs qui s'affichent sur la page d'activation du panneau Administration. Pour gérer la façon dont les utilisateurs peuvent envoyer des données à une destination d'action, vous pouvez spécifier un attribut utilisateur pour lequel l'utilisateur doit avoir une valeur définie. parameters
supportedFormats Non Liste des formats de données acceptés par l'action. Les valeurs valides sont "txt", "csv", "inline_json", "json" et "json_detail", "json_detail_lite_stream", "xlsx", "html", "wysiwyg_pdf", "assembled_pdf", and "wysiwyg_png". chaîne
supportedFormattings Non Liste des options de mise en forme acceptées par l'action. Les valeurs valides sont "formatted" et "unformatted". chaîne
supportedVisualizationFormattings Non Liste des options de mise en forme de la visualisation compatibles avec l'action. Les valeurs valides sont "apply" et "noapply". chaîne
iconName Non Un URI de données représentant une icône pour l'action. chaîne
requiredFields Non Liste des champs obligatoires avec lesquels cette action est compatible. Si cette liste contient plusieurs entrées, l'action requiert plusieurs champs. RequiredField
supportedDownloadSettings Non Booléen qui détermine si l'action recevra une URL de téléchargement à usage unique pour faciliter l'accès illimité aux données. Il est défini par le paramètre usesStreaming, qui est une valeur booléenne true/false. Si la valeur est usesStreaming = true, supportedDownloadSettings = url. Si la valeur est usesStreaming = false, supportedDownloadSettings = push. Booléen
usesOAuth Non Valeur booléenne déterminant si l'action est une action OAuth. Cela permettra de déterminer si l'action recevra un lien à usage unique permettant de définir state pour un utilisateur spécifique de cette action. Booléen
usesStreaming Non Valeur booléenne indiquant si l'action est compatible avec les résultats de requête diffusés. Consultez la colonne Diffusion autorisée des résultats dans la liste des services intégrés. Les actions qui diffusent des résultats en direct peuvent nécessiter la configuration d'un serveur de hub d'action local. Consultez l'article Configurer un hub d'action local pour les actions utilisant OAuth ou le streaming du centre d'aide Looker pour en savoir plus. Booléen
minimumSupportedVersion Non Version minimale de Looker dans laquelle l'action apparaît dans la liste Action Hub du panneau Admin. chaîne

Des exemples issus des actions Looker Action Hub sont disponibles sur GitHub.

Types d'actions compatibles

Looker accepte trois types d'actions, comme spécifié dans le paramètre supportedActionTypes de votre action: la requête, la cellule et le tableau de bord.

  • Action au niveau de la requête:cette action envoie une requête entière. L'action de segmentation, par exemple, est une action au niveau de la requête.
  • Action au niveau de la cellule:l'action au niveau d'une cellule envoie la valeur d'une seule cellule spécifique dans un tableau de données. Ce type d'action diffère des actions sur les données, qui peuvent être définies pour des dimensions ou des mesures à l'aide du paramètre action. Pour envoyer des informations à partir d'une cellule spécifique dans une table, Looker utilise des tags pour mapper les actions sur les cellules correspondantes. Les actions doivent spécifier les balises compatibles avec requiredFields. Pour mapper des actions et des champs, les champs de LookML doivent spécifier à quelles balises ils sont mappés avec le paramètre tags de LookML. Par exemple, l'action Twilio Message utilise un tag phone afin que les développeurs LookML puissent contrôler les champs de numéros de téléphone sur lesquels l'action Twilio apparaîtra.
  • Une action au niveau du tableau de bord:une action au niveau du tableau de bord permet d'envoyer l'image d'un tableau de bord. Par exemple, l'action SendGrid envoie des images de tableau de bord par e-mail.

Ajouter des attributs utilisateur à des actions personnalisées

Pour les actions personnalisées, vous pouvez ajouter des attributs utilisateur dans le paramètre params de votre fichier d'action. Si le paramètre est obligatoire, chaque utilisateur doit avoir une valeur pour cet attribut définie dans leur compte utilisateur ou pour un groupe d'utilisateurs auquel il appartient, en plus de l'autorisation send_to_integration. L'action apparaît alors comme une option de destination lors de l'envoi ou de la planification du contenu.

Pour ajouter un attribut utilisateur à votre action:

  1. Un administrateur Looker devra peut-être créer l'attribut utilisateur correspondant à user_attribute_param s'il n'existe pas déjà.
  2. Définissez une valeur valide pour l'attribut utilisateur des utilisateurs ou groupes d'utilisateurs devant diffuser du contenu vers votre destination d'action. Ces utilisateurs doivent également disposer des autorisations send_to_integration.
  3. Le paramètre params représente les champs de formulaire qu'un administrateur Looker doit configurer sur la page d'activation de l'action à partir de la liste Actions du panneau Admin. Dans le paramètre params de votre fichier d'action, incluez les éléments suivants:
  params = [{
    description: "A description of the param.",
    label: "A label for the param.",
    name: "action_param_name",
    user_attribute_name: "user_attribute_name",
    required: true,
    sensitive: true,
  }]

où user_attribute_name est l'attribut utilisateur défini dans le champ Name (Nom) de la page User Attributes (Attributs utilisateur) de la section Users (Utilisateurs) du panneau Admin, required: true signifie qu'un utilisateur doit avoir une valeur non nulle et valide définie pour cet attribut utilisateur pour voir l'action lors de l'envoi des données, et sensitive: true signifie que l'attribut utilisateur est chiffré et ne s'affiche jamais dans l'UI Looker une fois qu'il est saisi. Vous pouvez spécifier plusieurs sous-paramètres pour les attributs utilisateur.

  1. Déployez vos mises à jour sur le serveur Action Hub.
    • Si vous ajoutez une action, un administrateur Looker doit l'activer en cliquant sur le bouton Activer à côté de l'action sur la page Actions du panneau Administration.
    • Si vous mettez à jour une action existante, actualisez la liste des actions en cliquant sur le bouton Actualiser. Cliquez ensuite sur le bouton Paramètres.
  2. Sur la page des paramètres/actions de l'action, un administrateur Looker doit configurer les champs du formulaire d'action pour extraire les informations de l'attribut utilisateur en cliquant sur l'icône d'attribut utilisateur à droite du champ approprié et en sélectionnant l'attribut utilisateur souhaité.

Paramètres requiredField dans les actions au niveau des cellules

Pour les actions au niveau des cellules, vous pouvez configurer les champs LookML de votre modèle pour fournir des données à cette destination d'action en spécifiant les tags compatibles avec votre action dans le paramètre requiredFields de votre fichier d'action.

Parameter Requis Description Type de données
tag Non Le cas échéant, correspond à un champ contenant ce tag. chaîne
any_tag Non Si elle est présente, elle remplace tag et correspond à un champ qui contient l'une des balises fournies. chaîne
all_tags Non Si elle est présente, elle remplace tag et correspond à un champ contenant toutes les balises fournies. chaîne

Formats de données compatibles

La classe DataActionRequest définit le format de diffusion de données disponible pour l'action. Pour les actions au niveau de la requête, la requête contient un rattachement qui peut prendre plusieurs formats. L'action peut spécifier un ou plusieurs supportedFormats, ou laisser l'utilisateur choisir le format en spécifiant tous les formats possibles. Pour les actions au niveau des cellules, la valeur de la cellule sera présente le DataActionRequest.

Configurer une action pour OAuth

Les actions compatibles avec OAuth ne peuvent pas être configurées à partir du Looker Action Hub pour les instances Looker sur lesquelles la fonctionnalité Liste d'autorisation d'adresses IP est activée ou qui ne répondent pas aux exigences de Looker Action Hub. Pour en savoir plus sur la configuration d'une action pour OAuth, consultez l'article Configurer un hub d'action locale pour les actions utilisant OAuth ou le streaming du centre d'aide Looker.

Vous pouvez configurer votre action pour que les utilisateurs puissent s'authentifier dans l'action avec OAuth. Même si Looker Action Hub doit rester sans état, vous pouvez appliquer un état via une requête de formulaire via l'API Looker Action.

Flux OAuth d'action Looker

Pour les actions dans Looker Action Hub, vous pouvez étendre un OAuthAction au lieu d'un Hub.Action pour définir une valeur booléenne indiquant les méthodes OAuth nécessaires pour authentifier un utilisateur dans une action. Pour chaque action OAuth ou activée, Looker stocke un état par utilisateur et par action, de sorte que chaque combinaison action/utilisateur possède un événement OAuth indépendant.

Le flux de création d'actions implique généralement une requête /form suivie d'une requête /execute. Pour OAuth, la requête /form doit disposer d'une méthode permettant de déterminer si l'utilisateur est authentifié au sein du service cible. Si l'utilisateur est déjà authentifié, l'action doit renvoyer une valeur /form normale, conformément aux exigences de la requête /execute. Si l'utilisateur n'est pas authentifié, l'action renvoie un lien qui initialise un flux OAuth.

Enregistrement de l'état avec l'URL OAuth

Looker envoie une requête HTTP POST avec un corps vide au point de terminaison ActionList. Si l'action renvoie uses_oauth: true dans sa définition, elle recevra un state_url à usage unique dans chaque requête /form de Looker. state_url est une URL spéciale à usage unique qui définit l'état d'un utilisateur pour une action donnée.

Si l'utilisateur n'est pas authentifié avec le point de terminaison, le /form renvoyé doit contenir un form_field de type oauth_link qui pointe vers le point de terminaison /oauth d'une action. Le state_url doit être chiffré et enregistré en tant que paramètre state dans le oauth_url renvoyé. Exemple :

{
        "name": "login",
        "type": "oauth_link",
        "label": "Log in",
        "description": "OAuth Link",
        "oauth_url": "ACTIONHUB_URL/actions/my_action/oauth?state=encrypted_state_url"
}

Dans cet exemple, le point de terminaison /oauth redirige l'utilisateur vers le serveur d'authentification. Le point de terminaison /oauth crée la redirection dans la méthode oauthUrl(...) sur une action OAuth, comme indiqué dans Dropbox OauthUrl.

Le paramètre state contenant ce state_url chiffré doit être transmis au Looker Action Hub.

Enregistrement de l'état avec l'URI de redirection du hub d'action

Dans le point de terminaison /oauth, un redirect_uri pour le hub d'action est également créé et transmis à la méthode oauthUrl(...) de l'action. Ce redirect_uri est au format /actions/src/actions/my_maction/oauth_redirect et constitue le point de terminaison utilisé si l'authentification renvoie un résultat.

Ce point de terminaison appellera la méthode oauthFetchInfo(...), qui doit être implémentée par la méthode OauthAction pour extraire les informations nécessaires et tenter de recevoir ou d'enregistrer tout état ou auth reçu du serveur d'authentification.

Le state déchiffre le state_url chiffré et l'utilise pour POST state sur Looker. La prochaine fois qu'un utilisateur enverra une requête à cette action, l'état nouvellement enregistré sera envoyé à Looker Action Hub.

Ajouter vos fichiers d'action au dépôt Looker Action Hub

Une fois votre fichier d'action écrit, procédez comme suit dans le dépôt Looker Action Hub:

  1. Ajoutez le fichier d'action (par exemple, my_action.ts) à actions/src/actions/index.ts.

    import "./my_action/my_action.ts"

  2. Ajoutez les exigences de package Node.js que vous avez utilisées dans le texte de votre action. Exemple :

    yarn add aws-sdk
yarn add express

  3. Installer les dépendances Node.js du serveur Looker Action Hub

    yarn install

  4. Exécutez tous les tests que vous avez écrits.

yarn test

Tester une action

Pour effectuer un test complet, vous pouvez essayer votre action sur votre instance Looker en hébergeant un serveur Hub d'action privé. Ce serveur doit être sur l'Internet public et disposer d'un certificat SSL valide. Il doit pouvoir initier et recevoir des connexions ou des requêtes HTTPS vers et depuis Looker. Pour cela, vous pouvez utiliser une plate-forme cloud, comme Heroku, comme illustré dans l'exemple suivant, ou n'importe quelle plate-forme répondant aux exigences mentionnées ci-dessus.

Configurer un serveur Hub d'actions local

Dans cet exemple, nous allons effectuer l'action que nous avons développée dans le dépôt GitHub looker-open-source/actions/src/actions et valider le code dans une nouvelle branche Git. Nous vous recommandons de travailler sur les caractéristiques à l'aide de branches afin de pouvoir suivre facilement votre code et, si vous le souhaitez, créer facilement un RP avec Looker.

  1. Pour commencer, créez votre branche, puis effectuez le préproduction et validez votre travail. Exemple :

    git checkout -b my-branch-name
git add file-names
git commit -m commit-message

  2. Pour cet exemple, pour transférer une branche vers Heroku, configurez votre dépôt Git avec Heroku comme option distante dans votre ligne de commande:

    heroku login
heroku create
git push heroku

  3. Heroku affiche alors l'URL publique qui héberge le hub d'actions. Accédez à l'URL ou exécutez heroku logs pour vérifier que le hub d'action est bien en cours d'exécution. Si vous oubliez l'URL publique, vous pouvez exécuter la commande suivante dans la ligne de commande:

    heroku info -s | grep web_url

    Heroku renverra votre URL publique. Par exemple : https://my-heroku-action-server-1234.herokuapp.com

  4. Dans la ligne de commande, définissez l'URL de base de votre hub d'action:

    heroku config:set ACTION_HUB_BASE_URL="https://my-heroku-action-server-1234.herokuapp.com"

  5. Définissez le libellé du hub d'action:

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"

  6. Looker utilise un jeton d'autorisation pour se connecter au hub d'actions. Générez le jeton dans votre ligne de commande:

    heroku run yarn generate-api-key

    Si vous n'utilisez pas Heroku, comme dans cet exemple, utilisez plutôt:

    yarn generate-api-key

    Heroku renvoie votre jeton d'autorisation. Par exemple : Authorization: Token token="abcdefg123456789"

  7. Définissez votre clé secrète d'action à l'aide de la clé secrète:

    heroku config:set ACTION_HUB_SECRET="abcdefg123456789"

    Les déploiements hébergés par le client peuvent nécessiter la configuration de variables d'environnement supplémentaires non décrites ici.

  8. Ajoutez votre action sur votre instance Looker locale en accédant à Admin > Actions.

    • Au bas de la liste des actions, cliquez sur Ajouter un hub d'actions.
    • Saisissez l'URL du centre d'action et, si vous le souhaitez, une clé secrète.
    • Recherchez votre action dans la liste Actions du menu Admin de Looker.
    • Cliquez sur Activer.

Si votre action nécessite la transmission de types de données spécifiques depuis Looker, veillez à configurer tous les modèles de façon à inclure le paramètre tags approprié.

Vous êtes maintenant prêt à tester votre action !

Tester des actions au niveau du tableau de bord et des requêtes

Dans votre instance Looker, configurez votre modèle LookML avec des tags, si nécessaire. Créez et enregistrez un style. Sur la page enregistrée, cliquez sur le menu en haut à droite, puis sélectionnez Send (Envoyer) comme destination de l'action. Si vous disposez d'un formulaire pour la livraison, Looker l'affiche dans la fenêtre Envoyée.

Cliquez sur Envoyer le test pour envoyer les données. L'état de l'action s'affiche dans l'historique du planificateur du panneau Admin. Si une erreur se produit, elle s'affiche dans le panneau Admin. Looker envoie alors un e-mail contenant le message d'erreur à l'utilisateur qui a envoyé l'action.

Tester les actions au niveau des cellules

Configurez un champ LookML avec les balises appropriées pour votre action. Dans votre instance Looker, exécutez une requête incluant ce champ. Recherchez le champ dans le tableau de données. Dans la cellule, cliquez sur ... et sélectionnez Envoyer dans le menu déroulant. Si vous recevez des erreurs, vous devrez actualiser complètement le tableau de données après avoir corrigé ces erreurs.

Publier et activer une action personnalisée

Il existe deux options de publication pour les actions personnalisées:

Une fois votre action publiée, vous pouvez l'activer depuis la page Actions du panneau Administration.

Publication dans Looker Action Hub

Cette approche est la plus simple et fonctionne pour toutes les actions que vous souhaitez rendre disponibles à tous les utilisateurs de Looker.

Une fois votre action testée, vous pouvez envoyer un RP au dépôt looker-open-source/actions dans GitHub.

  1. Saisissez la commande suivante :

    git push <your fork> <your development branch>

  2. Créez votre demande d'extraction avec le dépôt looker-open-source/actions comme cible.

  3. Remplissez le formulaire d'envoi Looker Marketplace. Pour en savoir plus sur les exigences concernant les formulaires, consultez la page Envoyer du contenu à Looker Marketplace.

    Looker examinera votre code d'action. Nous nous réservons le droit de refuser votre RP, mais nous pouvons vous aider à résoudre les problèmes que vous rencontrez et vous proposer des suggestions d'amélioration. Nous fusionnons ensuite le code dans le dépôt looker-open-source/actions et le déployons dans actions.looker.com. Une fois déployé, le code sera disponible pour tous les clients Looker.

  4. Activez l'action dans votre instance Looker afin qu'elle apparaisse comme option de distribution des données.

Publication sur un serveur Hub d'actions privé

Si vous disposez d'actions personnalisées réservées à votre entreprise ou pour votre cas d'utilisation, vous ne devez pas ajouter votre action au dépôt looker-open-source/actions. À la place, créez un hub d'action privé à l'aide du framework Node.js que vous avez utilisé pour tester votre action.

Vous pouvez configurer votre serveur de hub d'action interne sur votre propre infrastructure ou à l'aide d'une plate-forme d'applications cloud (comme Heroku). N'oubliez pas de dupliquer Looker Action Hub sur le serveur du hub d'action privée avant le déploiement.

Configurer un modèle LookML à utiliser avec une action

Pour les actions personnalisées et les actions disponibles à partir de Looker Action Hub, vous devez identifier les champs de données pertinents à l'aide du paramètre tags de votre modèle LookML.

La page Actions du panneau Administration fournit des informations sur les balises obligatoires pour le service, le cas échéant. Exemple :

L'intégration de Zapier indique qu'elle fonctionne avec toutes les requêtes. Il n'est pas nécessaire d'ajouter le paramètre tags à un champ de votre modèle LookML.

En revanche, le service Twilio Send Message (Envoyer un message de Twilio) envoie un message à une liste de numéros de téléphone. Il nécessite une requête incluant un champ de numéro de téléphone et utilise le paramètre tags pour identifier le champ de la requête qui contient des numéros de téléphone. Vous identifiez un champ de numéro de téléphone dans LookML en spécifiant tags: ["phone"] pour ce champ. Voici un exemple de code LookML correspondant à un champ de numéro de téléphone :

dimension: phone {
  tags: ["phone"]
  type: string
  sql: ${TABLE}.phone ;;
}

Veillez à identifier tous les champs obligatoires dans votre modèle LookML à l'aide du paramètre tags afin que vos utilisateurs puissent envoyer des données à l'aide du service.

Fournir des données via une action

Vos données peuvent être diffusées de plusieurs manières, selon le niveau auquel l'action est effectuée. Les actions fonctionnent au niveau du champ, de la requête ou du tableau de bord, et peuvent s'effectuer sur un ou plusieurs niveaux. Chaque action répertoriée sur la page Actions du panneau Administration décrit son utilisation. Vous pouvez :

Fournir des données mobiles

Les actions au niveau du champ sont indiquées sur la page Actions du panneau Admin par une description incluant le paramètre "Action". Celle-ci peut être utilisée avec des champs, ou avec la valeur Yes (Oui) dans la colonne Can Use from Fields (Peut être utilisé à partir de champs) de la liste de services intégrés.

Les actions au niveau du champ sont conçues pour fournir une cellule de données au service spécifié. Ils fonctionnent de la même manière que les actions de données, sauf qu'elles sont diffusées via l'API Looker Action. Au lieu de définir un paramètre LookML action pour une dimension ou une mesure, vous devez configurer votre modèle LookML en ajoutant des tags aux champs appropriés avec les informations fournies dans la colonne Tags for This Action de la liste des services intégrés.

Après avoir activé les champs de service et d'ajout de tags dans le modèle LookML, vous pouvez:

  1. Affichez les données que vous souhaitez importer dans un aperçu, un tableau de bord ou une exploration. Si le service spécifie "Action" peut être utilisé avec les requêtes comportant un champ tagué... , votre requête ou l'une des tuiles du tableau de bord doit inclure un ou plusieurs champs avec les balises requises.

  2. Le champ tagué de chaque cellule dans la zone "Regarder", le tableau de bord ou "Explorer" contient une liste déroulante, indiquée par des points de suspension (...). Cliquez sur les points de suspension pour afficher les actions disponibles pour ce lien:

  3. Dans la section ACTIONS, cliquez sur le service dont vous souhaitez recevoir les données.

Fournir des données sur le tableau de bord ou les requêtes

Les actions au niveau des requêtes sont indiquées sur la page Actions du panneau Admin par une description qui inclut "Action". Cette option peut être utilisée avec les requêtes dont le champ comporte le libellé "..." ou "Action avec n'importe quelle requête". Selon la colonne Peut envoyer ou planifier de la liste de services intégrés, vous pouvez fournir chaque ligne (dans un aperçu ou une exploration). Les actions au niveau des requêtes sont conçues pour fournir l'intégralité des résultats de requête d'une exploration ou d'une recherche au service spécifié.

Les actions au niveau du tableau de bord sont indiquées sur la page Actions du panneau Admin par une description qui inclut "Action utilisable avec n'importe quel tableau de bord". Selon la colonne Envoi ou planification dans la liste des services intégrés, vous pouvez fournir un tableau de bord. Les actions au niveau du tableau de bord sont conçues pour fournir un tableau de bord au service spécifié.

Activez le service et, si nécessaire, balisez les champs du modèle LookML.

Pour proposer un look ou une exploration, consultez la page de documentation Proposer des looks et des explorations.

Pour afficher des tableaux de bord, consultez les pages de documentation Fournir d'anciens tableaux de bord et Planifier et envoyer des tableaux de bord.