Partager des données via un hub d'actions

En plus de diffuser du contenu vers les destinations intégrées de Looker, vous pouvez utiliser des actions, également appelées intégrations, pour envoyer du contenu à des services tiers intégrés à Looker via un serveur Action Hub.

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

Pour commencer à utiliser des actions, vous pouvez :

Une fois l'action ajoutée au hub d'actions, un administrateur Looker peut activer l'action afin de l'utiliser pour envoyer le contenu Looker à ces services.

Vous pouvez également configurer plusieurs hubs d'actions si vous souhaitez utiliser les intégrations de Looker via le hub d'actions Looker et héberger vos propres actions privées ou personnalisées. Les actions de chaque centre d'actions apparaissent sur la page Actions du panneau Admin.

Looker Action Hub

Looker héberge et fournit Looker Action Hub, un serveur sans état qui implémente l'API Action de Looker et expose les actions populaires. Toutes les données envoyées par vos utilisateurs à l'aide d'une action sont provisoirement traitées sur le serveur Looker Action Hub, et non dans votre instance Looker.

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

Exigences de Looker Action Hub

Looker Action Hub doit pouvoir envoyer et recevoir des requêtes API de la manière suivante :

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

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

Les requêtes destinées à actions.looker.com sont résolues vers une adresse IP dynamique. Les requêtes sortantes provenant de l'instance Looker doivent pouvoir atteindre les points de terminaison suivants:

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 du navigateur de l'utilisateur Looker vers le réseau Looker Action Hub

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

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

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

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

L'Action Hub de Looker doit envoyer des requêtes à l'instance Looker pour les actions qui acceptent les résultats diffusés ou qui utilisent OAuth.

Une action de traitement par flux lui permet d'utiliser les requêtes qui renvoient tous les résultats. Les actions pour lesquelles OAuth est activée utilisent l'authentification par utilisateur via les flux OAuth 2.0. Les actions OAuth doivent stocker les identifiants utilisateur dans leur instance Looker source, car le hub d'actions Looker est sans état et multi-tenant, et ne stocke aucun identifiant spécifique à l'utilisateur.

Les requêtes de l'Action Hub de Looker vers une instance Looker se présentent sous 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 sur place dans l'instance Looker avant d'être envoyées à Looker Action Hub. Pour cette raison, le hub d'actions Looker doit pouvoir résoudre le <host_looker_url> en adresse IP et envoyer des requêtes sur le réseau sur lequel se trouve votre instance Looker.

Looker Action Hub dispose d'adresses IP de sortie statiques dont proviennent toujours les requêtes: 35.153.89.114, 104.196.138.163 et 35.169.42.87. Les administrateurs des 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 qui acceptent les résultats en streaming ou qui utilisent OAuth.

Remarques concernant 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 respecter les exigences Looker Action Hub. Cela n'est pas toujours possible avec les instances Looker hébergées par le client, pour diverses raisons. Si la communication bidirectionnelle n'est pas possible entre Looker Action Hub et l'instance Looker, celle-ci peut présenter un comportement inattendu ou indésirable, comme des requêtes suspendues ou des actions indisponibles.

Pour résoudre le problème potentiel de Looker Action Hub ne pouvant pas communiquer avec l'instance Looker, les administrateurs Looker peuvent implémenter l'une des solutions présentées plus loin sur cette page. La solution ou la combinaison de solutions appropriée dépendra de l'architecture de l'instance Looker:

  • Si l'instance hébergée par le client n'est pas 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 contacter un spécialiste commercial Google Cloud pour activer la fonctionnalité de licence public_host_url. Cette fonctionnalité de licence révèle l'option de démarrage --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 celui de l'instance <host_looker_url>. Le public_host_url remplace le nom d'hôte de certaines URL de rappel Looker Action Hub et les achemine via un proxy inverse dont le public_host_url est un nom pouvant être résolu publiquement. Ce proxy inverse n'accepte les requêtes que provenant des adresses IP de sortie statiques de l'Action Hub de Looker. Les administrateurs Looker qui utilisent cette méthode doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles l'Action Hub de Looker 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 la diffusion de résultats ou OAuth. Pour résoudre ce problème, les administrateurs Looker 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 aucune des solutions mentionnées ci-dessus n'est adaptée à l'architecture des instances Looker, les administrateurs Looker peuvent déployer un Action Hub hébergé par le client pour toutes les actions, ou uniquement pour les actions qui prennent en charge la diffusion de résultats ou qui utilisent OAuth.

  • Pour déployer un hub d'actions hébergé par le client, vous devez vous assurer que le fichier JAR est hébergé sur un serveur public afin qu'Action Hub de Looker puisse communiquer avec. Toutefois, cette solution n'est pas recommandée.

De plus, les actions OAuth et de streaming peuvent ne pas être utilisables sur une instance Looker hébergée par un client si l'instance utilise un certificat SSL émis par une autorité de certification qui ne figure pas dans cette liste de certificats racine.

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 Looker Action Hub. Pour voir des exemples de code fonctionnel, vérifiez les actions existantes dans le dépôt looker-open-source/actions de GitHub.

Pour créer une action personnalisée, procédez comme suit :

  1. Configurer un dépôt de développement
  2. Rédiger votre action
  3. Tester votre action
  4. Publier et activer votre action, soit dans Looker Action Hub, soit sur votre propre serveur Action Hub 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 livrer 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 superposée au JavaScript moderne qui ajoute des informations de type pour aider à détecter les erreurs de programmation. Si vous connaissez JavaScript, la plupart du langage TypeScript devrait vous être familière.

L'exécution d'Action Hub Looker nécessite les logiciels suivants :

  • Node.js
  • Node Version Manager (NVM, pour sélectionner la version de Node.js appropriée)
  • 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 suivant 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 portant le nom de votre action dans le répertoire actions/src/actions. Exemple :

    mkdir actions/src/actions/my_action

  3. Commencez à remplir votre répertoire avec les fichiers dont vous avez besoin pour exécuter votre action. Pour obtenir un exemple de structure de fichiers, consultez le dépôt GitHub d'actions.

Looker vous recommande d'ajouter également les éléments suivants:

  • Un fichier README expliquant l'objectif et les moyens d'authentification de votre action
  • Une icône PNG à afficher dans Looker Action Hub (ou dans le hub d'actions privées de votre instance Looker) et dans les fenêtres de livraison de données Looker
  • Tout fichier de test que vous souhaitez exécuter sur votre code d'action (ce qui est différent du test de votre action)

Rédiger une action

L'une des exigences de conception du serveur Looker Action Hub est qu'il reste entièrement sans état. Le stockage d'informations dans l'application ou le service d'action n'est donc pas autorisé. Toute information nécessaire à l'exécution de l'action doit être fournie 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 auquel l'action s'exécute, 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 API /execute. Les requêtes de l'API Looker reçoivent un DataActionRequest chaque fois qu'un utilisateur exécute l'action dans Looker. DataActionRequest contient toutes les données et métadonnées nécessaires à l'exécution de votre action. Une méthode /form est également disponible. Elle 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 le /form s'affichent dans le pop-up Envoyer ou Planifier lorsque les utilisateurs sélectionnent l'action comme destination pour l'envoi de leurs données.

Lorsque vous rédigez votre fichier d'action, incluez au moins les paramètres suivants marqués comme Obligatoires dans la définition de l'action :

Paramètre Obligatoire Description Type de données
name Oui Nom unique de l'action. Il doit être unique pour toutes les actions dans Looker Action Hub. chaîne
url Oui URL absolue du point de terminaison /execute pour cette action. chaîne
label Oui Libellé lisible de l'action. chaîne
supportedActionTypes Oui Liste des types d'actions compatibles avec 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. Il s'agit des champs qui s'affichent sur la page d'activation de l'action dans le 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 un utilisateur doit définir une valeur. parameters
supportedFormats Non Liste des formats de données compatibles avec 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 compatibles avec 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 URI de données représentant une icône pour l'action. chaîne
requiredFields Non Liste des descriptions des champs obligatoires avec lesquels cette action est compatible. Si cette liste comporte plusieurs entrées, l'action doit comporter plusieurs champs. RequiredField
supportedDownloadSettings Non Valeur booléenne qui détermine si l'action va recevoir une URL de téléchargement à usage unique pour faciliter la diffusion illimitée des 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, alors supportedDownloadSettings = url. Si la valeur est usesStreaming = false, alors supportedDownloadSettings = push. Booléen
usesOAuth Non Valeur booléenne qui détermine si l'action est une action OAuth. Cela déterminera si un lien à usage unique sera envoyé à l'action pour pouvoir définir state pour un utilisateur spécifique pour cette action. Booléen
usesStreaming Non Valeur booléenne déterminant si l'action est compatible avec les résultats de requête diffusés en continu. Vérifiez la colonne Utilise le streaming de données (oui/non) dans la liste des services intégrés. Les actions qui diffusent des résultats peuvent nécessiter la configuration d'un serveur Action Hub local. Pour en savoir plus, consultez la page des bonnes pratiques Configurer un Action Hub local pour les actions qui utilisent OAuth ou la diffusion de données. Booléen
minimumSupportedVersion Non Version minimale de Looker dans laquelle l'action apparaîtra dans la liste Action Hub du panneau Administration. chaîne

Vous trouverez des exemples d'actions Looker Action Hub sur GitHub pour référence.

Types d'actions compatibles

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

  • Action au niveau de la requête : action qui envoie une requête complète. L'action de segmentation, par exemple, est une action au niveau de la requête.
  • Action au niveau de la cellule : une action au niveau de la cellule envoie la valeur d'une seule cellule spécifique dans une table de données. Ce type d'action est différent des actions de données, qui peuvent être définies pour les dimensions ou les mesures à l'aide du paramètre action. Pour envoyer des informations à partir d'une cellule spécifique d'un tableau, Looker utilise des tags pour mapper les actions aux cellules correspondantes. Les actions doivent spécifier les balises qu'elles acceptent dans requiredFields. Pour mapper des actions et des champs, les champs LookML doivent spécifier les balises avec lesquelles ils sont mappés à l'aide du paramètre tags de LookML. Par exemple, l'action Twilio Message utilise un tag phone pour que les développeurs LookML puissent contrôler les champs de numéro de téléphone dans lesquels l'action Twilio apparaîtra.
  • 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 aux 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 définie pour cet attribut dans son compte utilisateur ou pour un groupe d'utilisateurs auquel il appartient, en plus de l'autorisation send_to_integration, pour voir l'action en tant qu'option de destination lors de l'envoi ou de la planification de contenus.

Pour ajouter un attribut utilisateur à votre action:

  1. Un administrateur Looker peut être amené à créer l'attribut utilisateur correspondant à l'user_attribute_param s'il n'existe pas déjà.
  2. Définissez une valeur valide pour l'attribut utilisateur pour les utilisateurs ou les groupes d'utilisateurs qui doivent diffuser du contenu vers la destination de votre action. (Ces utilisateurs doivent également disposer des autorisations send_to_integration.)
  3. Le paramètre params représente les champs du formulaire qu'un administrateur Looker doit configurer sur la page d'activation de l'action dans 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 Nom de la page Attributs utilisateur de la section Utilisateurs du panneau Administration, required: true signifie qu'une valeur non nulle et valide doit être définie pour cet attribut utilisateur pour que l'utilisateur puisse voir l'action lors de l'envoi des données, et sensitive: true signifie que l'attribut utilisateur est chiffré et jamais affiché dans l'UI Looker une fois qu'il est saisi. Vous pouvez spécifier plusieurs sous-paramètres d'attribut utilisateur.

  1. Déployez vos mises à jour sur le serveur Action Hub.
    • Si vous ajoutez une nouvelle 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/de l'activation de l'action, un administrateur Looker doit configurer les champs du formulaire de l'action pour extraire des informations de l'attribut utilisateur. Pour ce faire, il doit cliquer sur l'icône de l'attribut utilisateur  à droite du champ approprié, puis sélectionner l'attribut utilisateur souhaité.

requiredField paramètre dans les actions au niveau de la cellule

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

Paramètre Obligatoire Description Type de données
tag Non Si ce champ est présent, correspond à un champ contenant cette balise. chaîne
any_tag Non Si cette valeur est présente, elle remplace tag et correspond à un champ contenant l'une des balises fournies. chaîne
all_tags Non Si cette valeur 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 des données disponible pour l'action. Pour les actions au niveau d'une requête, celle-ci contiendra une pièce jointe pouvant 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 de la cellule, la valeur de la cellule est présente sur DataActionRequest.

Configurer une action pour OAuth

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

Flux OAuth de l'action Looker

Pour les actions dans Looker Action Hub, vous pouvez étendre un OAuthAction au lieu d'un Hub.Action afin de définir une valeur booléenne indiquant les méthodes OAuth nécessaires pour authentifier un utilisateur dans une action. Pour chaque action activée par OAuth ou par état, Looker stocke un état par utilisateur et par action, de sorte que chaque combinaison d'action et d'utilisateur dispose d'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 comporter une méthode permettant de déterminer si l'utilisateur est authentifié auprès du service cible. Si l'utilisateur est déjà authentifié, l'action doit renvoyer un /form normal, conformément à ce que la requête /execute exige. Si l'utilisateur n'est pas authentifié, l'action renvoie un lien qui initialise un flux OAuth.

Enregistrer l'état avec l'URL OAuth

Looker enverra 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, un state_url à usage unique lui sera envoyé 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é auprès du 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 construit 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 hub d'actions Looker.

Enregistrer l'état avec l'URI de redirection du hub d'actions

Dans le point de terminaison /oauth, un élément redirect_uri pour le hub d'actions 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 correspond au point de terminaison utilisé si l'authentification renvoie un résultat.

Ce point de terminaison appelle 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 renvoyer le state à Looker par POST. 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, 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 toutes les exigences de package Node.js que vous avez utilisées pour rédiger votre action. Exemple :

    yarn add aws-sdk
yarn add express

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

    yarn install

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

yarn test

Tester une action

Pour effectuer des tests complets, vous pouvez tester votre action sur votre instance Looker en hébergeant un serveur de hub d'actions privé. Ce serveur doit se trouver sur l'Internet public avec un certificat SSL valide et doit pouvoir initier et recevoir des connexions ou des requêtes HTTPS vers et depuis Looker. Pour ce faire, vous pouvez utiliser une plate-forme cloud telle que Heroku, comme illustré dans l'exemple suivant. Vous pouvez également utiliser n'importe quelle plate-forme répondant aux exigences mentionnées ci-dessus.

Configurer un serveur de hub d'actions local

Dans cet exemple, nous allons appliquer 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 des fonctionnalités utilisant des branches afin de pouvoir suivre facilement votre code et, si vous le souhaitez, créer facilement un PR avec Looker.

  1. Pour commencer, créez votre branche, puis préproduisez 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 en tant qu'option distante dans votre ligne de commande :

    heroku login
heroku create
git push heroku

  3. Heroku renverra l'URL publique qui héberge désormais le Action Hub. Accédez à l'URL ou exécutez heroku logs pour vérifier que le hub d'actions est en cours d'exécution. Si vous avez oublié 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 Action Hub:

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

  5. Définissez le libellé de votre hub d'actions :

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"

  6. Looker utilise un jeton d'autorisation pour se connecter à l'Action Hub. Générez le jeton dans votre ligne de commande:

    heroku run yarn generate-api-key

    Si vous n'utilisez pas Heroku, comme nous le faisons 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 le secret de votre hub d'actions à 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 d'autres variables d'environnement qui ne sont pas décrites ici.

  8. Ajoutez votre action à votre instance Looker locale en accédant à Administration > Actions :

    • Au bas de la liste des actions, cliquez sur Add Action Hub (Ajouter un hub d'action).
    • Saisissez l'URL du hub d'action et, éventuellement, 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 les actions au niveau du tableau de bord et de la requête

Dans votre instance Looker, configurez votre modèle LookML avec des balises, si nécessaire. Créez et enregistrez un look. Dans le Look enregistré, cliquez sur le menu en haut à droite et sélectionnez Envoyer avec votre action comme destination. Si vous disposez d'un formulaire à envoyer, Looker l'affiche dans la fenêtre Envoyé.

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

Tester les actions au niveau de la cellule

Configurez un champ LookML avec les balises appropriées pour votre action. Dans votre instance Looker, exécutez une requête qui inclut ce champ. Recherchez le champ dans le tableau de données. Cliquez sur ... dans la cellule, puis sélectionnez Envoyer dans le menu déroulant. Si des erreurs se produisent, vous devrez actualiser complètement la table de données une fois ces erreurs corrigées.

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 sur la page Actions du panneau Administration.

Publier dans Looker Action Hub

Cette approche est la plus simple et fonctionne pour toute action que vous souhaitez mettre à la disposition de tous les utilisateurs de Looker.

Une fois votre action testée, vous pouvez envoyer une demande d'extraction 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 pour Looker Marketplace et Action Hub. Pour en savoir plus sur les exigences concernant le formulaire, consultez Envoyer du contenu sur la place de marché Looker Marketplace.

    Looker examinera votre code d'action. Nous nous réservons le droit de refuser votre demande, mais nous pouvons vous aider en cas de problème et vous suggérer des améliorations. Nous fusionnons ensuite le code dans le dépôt looker-open-source/actions et le déployons dans actions.looker.com. Une fois le code déployé, il sera disponible pour tous les clients Looker.

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

Publier sur un serveur de hub d'actions privé

Si vous avez des actions personnalisées qui sont privées à votre entreprise ou à votre cas d'utilisation, vous ne devez pas les ajouter au dépôt looker-open-source/actions. Créez plutôt un hub d'action privé à l'aide du même framework Node.js que vous avez utilisé pour tester votre action.

Vous pouvez configurer votre serveur Action Hub interne sur votre propre infrastructure ou à l'aide d'une plate-forme d'application basée sur le cloud (dans notre exemple, Heroku). N'oubliez pas de dupliquer Looker Action Hub sur votre serveur Action Hub privé avant le déploiement.

Configurer un modèle LookML pour l'utiliser avec une action

Pour les actions personnalisées et les actions disponibles dans le hub d'actions Looker, vous devez identifier les champs de données pertinents à l'aide du paramètre tags dans votre modèle LookML. La page Actions du panneau Administration fournit des informations sur les balises éventuellement requises pour le service.

Par exemple, une intégration Twilio Send Message envoie un message à une liste de numéros de téléphone. Sur la page Actions du panneau Administration, l'intégration affiche le sous-texte "L'action peut être utilisée avec les requêtes dont le champ comporte le tag phone".

Cela signifie que le service Envoyer un message Twilio nécessite une requête incluant un champ de numéro de téléphone et qui utilise le paramètre tags pour identifier le champ de la requête qui contient les numéros de téléphone. Pour identifier un champ de numéro de téléphone dans LookML, spécifiez 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 ;;
}

Une intégration qui ne nécessite pas de balise affichera le sous-texte "L'action peut être utilisée avec n'importe quelle requête". sur la page Actions du panneau Administration.

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

Étape suivante

Découvrez comment diffuser le contenu d'une présentation ou d'une exploration ou d'un tableau de bord dans un service intégré.