Partager des données via un Action Hub

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 présente les différentes options pour 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 hub d'action local pour tester vos actions personnalisées ou exécuter un serveur hub d'action privé.

Pour commencer à utiliser les actions, vous pouvez:

Une fois l'action ajoutée au Action Hub, un administrateur Looker peut enable l'action afin de l'utiliser pour envoyer le contenu Looker à ces services.

Vous pouvez également configurer plusieurs Action Hub si vous souhaitez utiliser les intégrations de Looker via Looker Action Hub 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 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 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 des manières suivantes:

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 d'action locale hub pour diffuser des intégrations Looker privées ou des actions personnalisées. Les administrateurs d'instances hébergées par le client peuvent également déployer un serveur d'action locale spécifiquement pour OAuth et les actions 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

Looker Action Hub doit envoyer des requêtes à l'instance Looker pour les actions qui prennent en charge la diffusion de résultats 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 Looker Action Hub est sans état et mutualisé, et ne stocke 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 instantanément dans l'instance Looker avant d'être envoyées à Looker Action Hub. Pour cette raison, Looker Action Hub doit être en mesure de résoudre le <host_looker_url> en une adresse IP et d'envoyer des requêtes au réseau dans lequel réside 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 d'instances hébergées par Looker qui ont activé la liste d'autorisation d'adresses IP doivent ajouter ces adresses IP pour pouvoir utiliser les actions compatibles avec la diffusion des résultats ou 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 ne peut pas être résolue par Looker Action Hub (c'est-à-dire si Looker Action Hub ne peut pas recevoir de requêtes de l'instance Looker), les administrateurs Looker peuvent contacter un spécialiste des ventes 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 que les requêtes provenant d'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 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 Action Hub hébergé par un 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, 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.

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

  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 détecter les erreurs de programmation. Si vous maîtrisez JavaScript, vous devriez être familiarisé avec la plupart du langage TypeScript.

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

  • 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 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 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 aurez besoin pour exécuter votre action. Consultez le dépôt GitHub des actions pour voir un exemple de structure de fichiers.

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

  • Un fichier README pour expliquer le but et les moyens d'authentification pour votre action
  • Une icône PNG à afficher dans Looker Action Hub (ou dans l'Action Hub privée sur votre instance Looker) et dans les fenêtres de diffusion 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 d'exécution de l'action, et des formats de données ou de visualisation qui doivent être spécifiés. 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 écrivez votre fichier d'action, incluez au moins les paramètres suivants marqués comme Required dans la définition de votre action:

Paramètres 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 pour 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 de parameters pour l'action. Indiquez le nom, le libellé et la description au format chaîne pour chaque paramètre. Ces champs s'affichent sur la page d'activation de l'action dans le panneau Administration. Pour gérer la façon dont les utilisateurs peuvent transmettre des données à une destination d'action, vous pouvez spécifier un attribut utilisateur pour lequel un utilisateur doit avoir une valeur définie. 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 prises en charge par 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 Booléen qui détermine si l'action est une action OAuth. Cela déterminera si l'action recevra un lien à usage unique afin de 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. Consultez la colonne Utilise le flux 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 Hub d'actions locales. Pour en savoir plus, consultez la page Configurer un hub d'actions locales pour les actions qui utilisent OAuth ou les flux. 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 segment, par exemple, est une action au niveau de la requête.
  • Action au niveau d'une cellule:une action au niveau d'une cellule envoie la valeur d'une seule cellule spécifique d'un tableau de données. Ce type d'action est différent des actions sur les 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 pour cet attribut définie dans son compte utilisateur ou pour un groupe d'utilisateurs auquel il appartient, en plus de l'autorisation send_to_integration, afin que l'action s'affiche en tant qu'option de destination lors de l'envoi ou de la planification de 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 pour les utilisateurs ou les groupes d'utilisateurs qui doivent envoyer du contenu à 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'attributs 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 ou d'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, cliquez sur l'icône Attribut utilisateur à droite du champ approprié, puis sélectionnez 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ètres 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 S'il est présent, il remplace tag et correspond à un champ qui contient l'une des balises fournies. chaîne
all_tags Non S'il est présent, il remplace tag et correspond à un champ qui contient tous les tags fournis. 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 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 sera présente dans 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 pour définir une valeur booléenne indiquant les méthodes OAuth nécessaires pour authentifier un utilisateur dans une action. Pour chaque action dont l'état ou le protocole OAuth est activé, Looker stocke un état par utilisateur et par action, de sorte que chaque action et combinaison d'utilisateurs 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 comporter une méthode permettant de déterminer si l'utilisateur est authentifié dans le service cible. Si l'utilisateur est déjà authentifié, l'action doit renvoyer un /form normal, conformément à ce que demande la requête /execute. 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, 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é 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 cet state_url chiffré doit être transmis à Looker Action Hub.

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 PUBLIER state dans Looker. La prochaine fois qu'un utilisateur demandera cette action, le nouvel état 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 les exigences de package Node.js que vous avez utilisées dans la rédaction de 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 terminer les tests, vous pouvez tester votre action sur votre instance Looker en hébergeant un serveur d'action 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 comme 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 Hub d'action locale

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 suivre facilement votre code et, si vous le souhaitez, de 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. Dans 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 votre libellé Action Hub:

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"

  6. Looker utilise un jeton d'autorisation pour se connecter à 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 dans cet exemple, utilisez plutôt:

    yarn generate-api-key

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

  7. Définissez le secret du hub 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 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 des requêtes

Dans votre instance Looker, configurez votre modèle LookML à l'aide de balises, si nécessaire. Créer et enregistrer 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 Send Test (Envoyer le test) pour envoyer les données. L'état de l'action s'affiche dans l'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 tags appropriés 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 … 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 Looker Marketplace et Action Hub. Pour en savoir plus sur les exigences concernant les formulaires, consultez Envoyer du contenu à Marketplace Looker.

    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 privé Action Hub

Si certaines de vos actions personnalisées sont réservé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.

Configuration d'un modèle LookML à utiliser avec une action

Pour les actions personnalisées et celles disponibles dans Looker Action Hub, vous devez identifier les champs de données pertinents en utilisant le paramètre tags dans votre modèle LookML. La page Actions du panneau Admin fournira des informations sur les balises requises pour le service, le cas échéant.

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 Twilio Send Message nécessite une requête qui inclut un champ de numéro de téléphone et qui utilise le paramètre tags pour identifier celui qui contient des 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 ne nécessitant 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 Admin.

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

Étapes suivantes

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