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:
- Utilisez les actions existantes de Looker disponibles dans Looker Action Hub.
- Créez et publiez une action personnalisée dans Looker Action Hub pour un usage public.
- Créez et publiez une action personnalisée sur un serveur Hub d'action privé pour un usage privé.
Une fois l'action ajoutée au Action Hub, un administrateur Looker peut activer 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:
- De l'instance Looker au réseau Looker Action Hub
- Du navigateur de l'utilisateur Looker au réseau Looker Action Hub
- Du réseau Looker Action Hub à l'instance Looker
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>
. Lepublic_host_url
remplace le nom d'hôte de certaines URL de rappel Looker Action Hub et les achemine via un proxy inverse dont lepublic_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
et35.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
et35.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:
- Configurer un dépôt de développement
- Rédiger votre action
- Tester votre action
- 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 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 suivant utilise Git.
Clonez le dépôt
looker-open-source/actions
localement:git clone git@github.com:looker-open-source/actions.git
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
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. Par conséquent, le stockage d'informations dans l'application ou le service d'action n'est 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è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 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" |
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 dansrequiredFields
. 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ètretags
de LookML. Par exemple, l'action Twilio Message utilise un tagphone
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:
- Un administrateur Looker devra peut-être créer l'attribut utilisateur correspondant à
user_attribute_param
s'il n'existe pas déjà. - 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
.) - 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ètreparams
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.
- 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.
- 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è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 | 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:
Ajoutez le fichier d'action (par exemple,
my_action.ts
) àactions/src/actions/index.ts
.import "./my_action/my_action.ts"
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
Installez les dépendances Node.js du serveur Looker Action Hub.
yarn install
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.
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
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
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
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"
Définissez votre libellé Action Hub:
heroku config:set ACTION_HUB_LABEL="Your Action Hub"
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"
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.
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 Sur 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 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.
- Si votre action s'affiche sans aucune erreur, vous pouvez la publier.
- Si vous souhaitez continuer à héberger votre action en mode privé, vous pouvez la publier sur votre page d'action privée.
- Si vous souhaitez publier votre action pour qu'elle soit utilisée par tous les clients Looker, consultez la section Publier sur Looker Action Hub.
Publier et activer une action personnalisée
Il existe deux options de publication pour les actions personnalisées:
- Publication sur Looker Action Hub: votre action est ainsi disponible pour tous les utilisateurs de Looker.
- Publication sur un serveur privé Action Hub: votre action n'est disponible que sur votre instance Looker.
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.
Saisissez la commande suivante :
git push <your fork> <your development branch>
Créez votre demande d'extraction avec le dépôt
looker-open-source/actions
comme cible.Remplissez les champs Looker Marketplace et Formulaire d'envoi 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 dansactions.looker.com
. Une fois le code déployé, il sera disponible pour tous les clients Looker.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 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 ;;
}
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 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.
Étape suivante
Découvrez comment envoyer le contenu d'une présentation ou d'une exploration ou d'un tableau de bord à un service intégré.