Partager des données via un centre d'action

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 options permettant de créer des actions personnalisées que vous pouvez demander à ajouter au Looker Action Hub ou à votre propre serveur Action Hub privé. Cette page explique également comment lancer un serveur local Action Hub pour tester vos actions personnalisées ou exécuter un serveur de hub d'action privé.

Pour commencer à utiliser des actions, vous pouvez:

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

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

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 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 d'administration – Actions pour savoir comment activer ces services existants.

Exigences concernant Action Hub pour Looker

Looker Action Hub doit pouvoir envoyer et recevoir des requêtes API des manières suivantes:

Si votre déploiement Looker ne peut pas gérer 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 local Action 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'actions locales spécifiquement pour les actions OAuth et de streaming.

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

Les requêtes adressées à actions.looker.com sont associées à une adresse IP dynamique. Les requêtes sortantes 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 de la programmation de l'action.

Requêtes du navigateur de l'utilisateur Looker vers le réseau Action Hub de Looker

Le navigateur de l'utilisateur Looker doit être en mesure d'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 de la programmation de l'action.

Requêtes du réseau Action Hub de Looker 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 qui utilisent OAuth.

Une action de flux de données permet à l'action d'utiliser les requêtes qui fournissent tous les résultats. Les actions sur lesquelles OAuth est activé utilisent l'authentification par utilisateur via des flux OAuth 2.0. Les actions OAuth doivent stocker les identifiants des utilisateurs dans leur instance Looker source, car Looker Action Hub est sans état et mutualisé. De plus, il 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 sur place dans l'instance Looker avant d'être envoyées à Looker Action Hub. Pour cette raison, Looker Action Hub doit pouvoir à la fois résoudre le <host_looker_url> avec une adresse IP et envoyer des requêtes au réseau où réside votre instance Looker.

Looker Action Hub dispose d'adresses IP de sortie statiques d'où 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 utiliser toutes les actions compatibles avec les résultats diffusés ou utilisant 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 répondre à ces exigences. Cela n'est pas toujours possible avec les instances Looker hébergées par un client, et ce pour diverses raisons. Si la communication bidirectionnelle entre Looker Action Hub et l'instance Looker n'est pas possible, Looker Action Hub 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 l'impossibilité de communiquer entre Looker Action Hub et 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épend 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 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> résoluble 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 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 des adresses IP de sortie statiques de 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 lui envoyer de requêtes, 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 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 ne convient à 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 compatibles avec les résultats diffusés en continu ou utilisant OAuth.

  • Pour déployer un hub d'action 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.

En outre, il est possible que les actions OAuth et de streaming ne soient pas utilisables sur une instance Looker hébergée par un client si l'instance utilise un certificat SSL délivré 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 Action Hub de Looker. 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, vous pouvez:

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

Comme pour toute action, vous devrez peut-être configurer vos modèles LookML avec des paramètres spécifiques avant de pouvoir l'utiliser pour envoyer 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 ajoutée au code JavaScript moderne qui ajoute des informations de type pour aider à détecter les erreurs de programmation. Si vous connaissez JavaScript, vous devriez connaître la plupart du langage TypeScript.

L'exécution de Looker Action Hub 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 pouvez 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 l'action. Consultez le dépôt GitHub d'actions pour obtenir un exemple de structure de fichiers.

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

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

Écrire une action

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

Le contenu exact du fichier d'actions varie en fonction du service, du type ou du niveau d'action de l'action, et des formats de données ou de visualisation à spécifier. Cette 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 l'action. Une méthode /form est également disponible. Elle permet de recueillir 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 apparaîtront dans le pop-up Envoyer ou Planifier lorsque les utilisateurs sélectionneront l'action comme destination pour l'envoi de données.

Lorsque vous écrivez votre fichier d'actions, incluez au moins les paramètres suivants, marqués comme Required, dans votre définition d'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. Incluez le nom, le libellé et la description sous forme de chaîne pour chaque paramètre. Ce sont les champs qui apparaissent 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 vers une destination d'action, vous pouvez spécifier un attribut utilisateur pour lequel une valeur doit être définie pour un utilisateur. 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 nécessite plusieurs champs. RequiredField
supportedDownloadSettings Non Valeur booléenne qui détermine si l'action recevra une URL de téléchargement à usage unique pour faciliter un flux de données illimité. Le paramètre 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 l'action recevra un lien à usage unique permettant de définir state pour un utilisateur spécifique pour cette action. Booléen
usesStreaming Non Valeur booléenne qui détermine si l'action est compatible avec les résultats de requête diffusés en continu. Cochez la colonne Uses data streaming (Yes/No) (Utilise le streaming de données (Yes/No)) 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 locale. Pour en savoir plus, consultez les bonnes pratiques Configurer un Action Hub locale pour les actions utilisant OAuth ou le streaming. Booléen
minimumSupportedVersion Non Version minimale de Looker dans laquelle l'action apparaîtra dans la liste Action Hub du panneau Administration. chaîne

Des exemples issus des actions Looker Action Hub sont disponibles sur GitHub pour référence.

Types d'actions acceptés

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:il s'agit d'une 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 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 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 compatibles dans requiredFields. Pour mapper des actions et des champs, les champs LookML doivent spécifier les balises auxquelles ils sont mappés à l'aide du paramètre tags LookML. Par exemple, l'action Twilio Message utilise une balise phone afin que les développeurs LookML puissent contrôler les champs de numéro de téléphone sur lesquels l'action Twilio doit s'afficher.
  • Action au niveau du tableau de bord:une action au niveau du tableau de bord permet l'envoi d'une 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'actions. Si le paramètre est obligatoire, chaque utilisateur doit disposer d'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, pour 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 à 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 de formulaire qu'un administrateur Looker doit configurer sur la page d'activation de l'action depuis la liste Actions du panneau Administration. Dans le paramètre params de votre fichier d'actions, 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 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 lorsque des données sont transmises, et sensitive: true signifie que l'attribut utilisateur est chiffré et ne s'affiche jamais dans l'UI Looker une fois qu'il a été 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 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/d'activation de l'action, un administrateur Looker doit configurer les champs du formulaire de l'action pour extraire les informations de l'attribut utilisateur. Pour ce faire, cliquez sur l'icône d'attribut utilisateur à droite du champ approprié et sélectionnez l'attribut utilisateur souhaité.

Paramètres requiredField dans les actions au niveau de la cellule

Pour les actions au niveau des cellules, vous pouvez configurer les champs LookML de votre modèle pour envoyer des 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 S'il 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 contenant l'une des balises fournies. chaîne
all_tags Non S'il est présent, il 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 de la requête, la requête contiendra une pièce jointe pouvant être dans 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 de sorte 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 depuis l'API Action Looker.

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 où OAuth ou état est activé, 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 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 aux exigences de 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 reçoit un state_url à usage unique pour 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 va au 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 à Looker Action Hub.

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

Dans le point de terminaison /oauth, un redirect_uri est également créé pour le hub d'action et transmis à la méthode oauthUrl(...) de l'action. Cet 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 sur Looker. La prochaine fois qu'un utilisateur effectuera une requête pour 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'actions é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 écrire votre action. Exemple :

    yarn add aws-sdk
yarn add express

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

    yarn install

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

yarn test

Tester une action

Pour effectuer des tests complets, vous pouvez essayer votre action sur votre instance Looker en hébergeant un serveur d'action Hub 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 ci-dessus.

Configurer un serveur local Action Hub

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 des fonctionnalités utilisant des branches pour pouvoir suivre facilement votre code et, si vous le souhaitez, créer facilement une demande d'extraction 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 l'exemple ci-dessous, pour transférer une branche vers Heroku, configurez votre dépôt Git avec Heroku comme option distante dans la ligne de commande:

    heroku login
heroku create
git push heroku

  3. Heroku renvoie l'URL publique qui héberge à présent le hub d'action que vous utilisez. Accédez à l'URL ou exécutez heroku logs pour vérifier qu'Action Hub est en cours d'exécution. Si vous oubliez l'URL publique, vous pouvez exécuter la commande suivante dans votre ligne de commande:

    heroku info -s | grep web_url

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

  4. Dans votre 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 à 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, saisissez:

    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'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 qui ne sont pas indiquées ici.

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

    • En bas de la liste des actions, cliquez sur Add Action Hub (Ajouter Action Hub).
    • Saisissez l'URL Action Hub et, éventuellement, une clé secrète.
    • Recherchez votre action dans la liste Actions du menu Administration de Looker.
    • Cliquez sur Activer.

Si votre action nécessite que des types de données spécifiques soient transmis depuis Looker, veillez à configurer tous les modèles pour inclure le paramètre tags approprié.

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

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

Dans votre instance Looker, configurez votre modèle LookML avec des balises, si nécessaire. Créer et enregistrer un Look Sur le Look enregistré, cliquez sur le menu en haut à droite et sélectionnez Send (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 apparaîtra dans l'historique du programmeur, dans le panneau Administration. Si votre action rencontre une erreur, elle s'affichera dans le panneau Administration, et Looker enverra 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 … dans le menu déroulant. Si vous recevez des erreurs, vous devrez actualiser complètement le tableau de données après les avoir 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 sur le Looker Action Hub

Cette approche est la plus simple et fonctionne pour toute action que vous souhaitez mettre à la disposition de toute personne utilisant 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 Marketplace et Action Hub Looker. Pour en savoir plus sur les exigences concernant le formulaire, consultez Envoyer du contenu à Marketplace Looker.

    Looker examinera votre code d'action. Nous nous réservons le droit de refuser votre demande de relations publiques, 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 le code déployé, il sera disponible pour tous les clients Looker.

  4. Activez l'action dans votre instance Looker afin qu'elle apparaisse en tant qu'option pour la diffusion de données.

Publier sur un serveur de hub d'action privé

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 Action Hub privé à l'aide du 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'applications dans le cloud (Heroku, dans notre exemple). 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 les actions disponibles dans Looker Action Hub, 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 fournira des informations sur les balises requises pour le service, le cas échéant.

Par exemple, l'intégration de 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 est défini sur 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 le champ de la requête 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 ;;
}

Pour une intégration qui ne nécessite pas de balises, le sous-texte "L'action peut être utilisée avec n'importe quelle requête" s'affiche sur la page Actions du panneau Administration.

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.

Étapes suivantes

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