Partager des données via un hub 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 diffuser du contenu vers des services tiers intégrés à Looker via un serveur de hub d'action.

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

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

Pour commencer à utiliser les actions, vous pouvez:

• Utilisez les actions existantes de Looker disponibles dans Looker Action Hub.
• Créez une action personnalisée et publiez-la dans le Looker Action Hub pour une utilisation publique.
• Créez et publiez une action personnalisée sur un serveur de hub d'action privé pour un usage privé.

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

Vous pouvez également configurer plusieurs hubs d'actions 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 correspondant à 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 Actioner de Looker et expose des actions populaires. Toutes les données que vos utilisateurs envoient à l'aide d'une action seront traitées temporairement sur le serveur Looker Action Hub plutôt que sur votre instance Looker.

Looker est déjà intégré à plusieurs services. Pour savoir comment activer ces services, consultez la page Paramètres d'administration – Actions.

Exigences concernant Looker Action Hub

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

Looker Action Hub doit pouvoir envoyer et recevoir des requêtes API de différentes manières:

• 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 traiter 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 de hub d'action local 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 local spécifique pour les actions OAuth et par flux.

Requêtes envoyées par l'instance Looker au réseau Looker Action Hub

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

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

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

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

Le navigateur de l'utilisateur Looker doit pouvoir envoyer des requêtes 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 compatibles avec les résultats diffusés ou qui utilisent OAuth.

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

Les requêtes du Looker Action Hub vers une instance Looker se présentent sous les formes suivantes:

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

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

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

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

Pour utiliser les intégrations Looker, le hub d'action Looker doit pouvoir communiquer avec l'instance Looker et remplir ces exigences. Cela n'est pas toujours possible avec les instances Looker hébergées par le client, pour diverses raisons. Si la communication bidirectionnelle entre le hub d'action Looker et l'instance Looker n'est pas possible, celui-ci peut présenter un comportement inattendu ou indésirable, tel qu'un blocage de requêtes ou des actions indisponibles.

Pour résoudre le problème potentiel de la plate-forme d'action Looker qui ne permet pas de communiquer avec l'instance Looker, les administrateurs de Looker peuvent implémenter l'une des solutions présentées ci-dessous. La solution ou 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 de Looker peuvent consulter leur responsable de compte Looker pour activer la fonctionnalité de licence public_host_url. Cette fonctionnalité de licence révèle l'option de démarrage de --public-host-url, qui permet aux administrateurs de spécifier un nom d'hôte <public_host_url> pouvant être résolu et différent de l'instance <host_looker_url>. public_host_url remplace le nom d'hôte pour certaines URL de rappel Looker Action Hub spécifiques et achemine ces URL via un proxy inverse dont public_host_url est un nom pouvant être résolu publiquement. Ce proxy inverse n'accepte que les requêtes provenant des adresses IP de sortie statiques pour Looker Action Hub. Les administrateurs Looker qui utilisent cette méthode doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles le Looker Action Hub envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.

• Si l'URL d'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 ou utiliser des actions compatibles avec les résultats diffusés ou qui utilisent OAuth. Pour résoudre ce problème, les administrateurs de Looker doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles le hub d'action Looker envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.

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

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

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

Créer une action personnalisée

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

Pour créer une action personnalisée:

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

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

Configurer un dépôt de développement

Looker Action Hub est un serveur Node.js écrit en TypeScript, une petite couche qui s'ajoute au code JavaScript moderne qui ajoute des informations de type pour aider à détecter les erreurs de programmation. Si vous connaissez bien JavaScript, la majeure partie du langage TypeScript devrait vous être familière.

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

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

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

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

   git clone [e-mail]: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. Remplissez votre répertoire avec les fichiers nécessaires à l'exécution de votre action. Pour obtenir un exemple de structure de fichiers, consultez le dépôt GitHub des actions.

Looker vous recommande également d'ajouter:

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

Écrire une action

Une exigence de conception pour le serveur Looker Action Hub est qu'il reste complètement sans état. Par conséquent, le stockage d'informations dans l'application ou le service d'action n'est pas autorisé. Toute information requise pour effectuer 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'activité de l'action, ainsi que des formats de données ou de visualisation à spécifier. L'action peut également être configurée pour les flux d'autorisation OAuth 2.0.

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

Le format de ces paramètres peut être différent si vous utilisez l'API Looker Action.

Lorsque vous rédigez votre fichier d'action, incluez au moins les paramètres suivants indiqués comme obligatoire dans votre définition d'action:

Paramètre	Requis	Description	Type de données
name	Yes	Nom unique de l'action. Il doit être unique pour toutes les actions dans Looker Action Hub.	string
url	Yes	URL absolue du point de terminaison /execute pour cette action.	string
label	Yes	Libellé lisible de l'action.	string
supportedActionTypes	Yes	Liste des types d'actions compatibles avec l'action Les valeurs valides sont "cell", "query" et "dashboard".	string
formURL	Non	URL absolue du point de terminaison /form pour cette action.	string
description	Non	Description de l'action.	string
params	Non	Tableau de parameters pour l'action. Incluez le nom, le libellé et la description au format de chaîne pour chaque paramètre. Voici les champs qui figurent sur la page "Activation" de l'action dans le panneau Admin. Pour gérer la façon dont les utilisateurs peuvent envoyer des données à une destination d'action, vous pouvez spécifier un attribut utilisateur pour lequel l'utilisateur doit avoir une valeur définie.	parameters
supportedFormats	Non	Liste des formats de données 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".	string
supportedFormattings	Non	Liste des options de mise en forme disponibles pour l'action. Les valeurs valides sont "formatted" et "unformatted".	string
supportedVisualizationFormattings	Non	Liste des options de mise en forme de la visualisation compatibles avec l'action. Les valeurs valides sont "apply" et "noapply".	string
iconName	Non	Un URI de données représentant une icône pour l'action.	string
requiredFields	Non	Liste des champs obligatoires avec lesquels cette action est compatible. Si cette liste comprend plusieurs entrées, l'action requiert plusieurs champs.	RequiredField
supportedDownloadSettings	Non	Booléen qui détermine si l'action recevra une URL de téléchargement à usage unique pour faciliter la diffusion illimitée des données. 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, supportedDownloadSettings = url. Si la valeur est usesStreaming = false, supportedDownloadSettings = push.	Booléen
usesOAuth	Non	Valeur booléenne qui détermine si l'action est une action OAuth. Cela permettra de déterminer si l'action recevra un lien à usage unique permettant de définir state pour un utilisateur spécifique.	Booléen
usesStreaming	Non	Valeur booléenne indiquant si l'action est compatible avec les résultats de requête diffusés en streaming. Consultez la colonne Résultats oui/non par flux de la liste des services intégrés. Les actions qui génèrent des résultats en streaming peuvent nécessiter la configuration d'un serveur de hub d'action local. Pour en savoir plus, consultez la page Configurer un hub d'action locale pour les actions qui utilisent OAuth ou streaming.	Booléen
minimumSupportedVersion	Non	Version minimale de Looker dans laquelle l'action apparaît dans la liste Action Hub du panneau Admin.	string

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

Types d'actions compatibles

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

• Action au niveau de la requête:cette action envoie une requête entière. Par exemple, l'action de segmentation 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 un tableau de données. Ce type d'action est différent des actions sur les données, qui peuvent être définies pour des dimensions ou des mesures à l'aide du paramètre action. Pour envoyer des informations à partir d'une cellule spécifique dans un tableau, Looker utilise des tags pour mapper les actions sur les cellules correspondantes. Les actions doivent spécifier les balises qu'elles acceptent dans requiredFields. Pour mapper des actions et des champs, les champs de LookML doivent spécifier les balises avec lesquelles ils sont mappés avec le paramètre tags de LookML. Par exemple, l'action de message Twilio utilise un tag phone pour permettre aux développeurs LookML de contrôler les champs de numéro de téléphone sur lesquels l'action Twilio s'affichera.
• Action au niveau du tableau de bord:une action au niveau du tableau de bord permet d'envoyer l'image d'un tableau de bord. Par exemple, l'action SendGrid envoie des images de tableau de bord par e-mail.

Ajouter des attributs utilisateur à des actions personnalisées

Pour les actions personnalisées, vous pouvez ajouter des attributs utilisateur dans le paramètre params de votre fichier d'action. Si le paramètre est obligatoire, chaque utilisateur doit disposer d'une valeur pour cet attribut 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 soit considérée comme une 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 encore.
2. Définissez une valeur valide pour l'attribut utilisateur des utilisateurs ou groupes d'utilisateurs devant diffuser du contenu vers votre destination d'action. Ces utilisateurs doivent également disposer d'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 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 Admin, required: true signifie qu'un utilisateur doit avoir une valeur non nulle et valide définie pour cet attribut pour voir l'action lors de la livraison des données, et sensitive: true signifie que l'attribut utilisateur est chiffré et ne s'affiche jamais dans l'UI Looker une fois qu'il est saisi. Vous pouvez spécifier plusieurs sous-paramètres 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 d'activation/de paramètres des actions, un administrateur Looker doit configurer les champs du formulaire de l'action pour extraire des informations de l'attribut utilisateur en cliquant sur l'icône d'attribut utilisateur à droite du champ approprié et en sélectionnant l'attribut utilisateur souhaité.

Paramètres requiredField dans les actions au niveau des cellules

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

Paramètre	Requis	Description	Type de données
tag	Non	Si ce champ est présent, il correspond à un champ contenant ce tag.	string
any_tag	Non	Si elle est présente, elle remplace tag et correspond à un champ qui comporte l'une des balises fournies.	string
all_tags	Non	Si ce champ est présent, il remplace tag et correspond à un champ contenant toutes les balises fournies.	string

Formats de données compatibles

La classe DataActionRequest définit le format de diffusion de données disponible pour l'action à utiliser. Pour les actions au niveau des requêtes, la requête contient une pièce jointe disponible 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 des cellules, la valeur de la cellule sera présente le DataActionRequest.

Configurer une action pour OAuth

Les actions OAuth ne peuvent pas être configurées à partir du Looker Action Hub pour les instances Looker pour lesquelles la fonctionnalité Liste d'autorisation d'adresses IP est activée ou qui ne répondent pas aux exigences de Looker Action Hub. Pour en savoir plus sur la configuration d'une action pour OAuth, consultez la page Bonnes pratiques pour configurer un hub d'action locale pour les actions qui utilisent OAuth ou diffuser des contenus en streaming.

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

Flux OAuth d'actions 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 activée ou activée par l'état, Looker stocke un état par utilisateur et par action, de sorte que chaque combinaison utilisateur/action possède un événement OAuth indépendant.

Le processus 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é au sein du service cible. Si l'utilisateur est déjà authentifié, l'action doit renvoyer un code /form normal conformément à la requête /execute requise. Si l'utilisateur n'est pas authentifié, l'action renvoie un lien qui initialise un flux OAuth.

Enregistrement de l'état avec l'URL OAuth

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

Si l'utilisateur n'est pas authentifié avec le point de terminaison, le /form renvoyé doit contenir un form_field de type oauth_link qui renvoie 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 crée la redirection dans la méthode oauthUrl(...) sur une action OAuth, comme indiqué dans Dropbox OauthUrl.

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

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

Dans le point de terminaison /oauth, un redirect_uri pour le hub d'action est également créé et transmis à la méthode oauthUrl(...) de l'action. Ce redirect_uri, au format /actions/src/actions/my_maction/oauth_redirect, est le 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 POST state sur Looker. La prochaine fois qu'un utilisateur fera une demande à cette action, l'état nouvellement enregistré sera envoyé à Looker Action Hub.

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

Une fois votre fichier d'action créé, 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 dans le texte 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 un test complet, vous pouvez tester votre action sur votre instance Looker en hébergeant un serveur de hub d'action privé. Ce serveur doit être sur l'Internet public et disposer d'un certificat SSL valide. Il doit pouvoir initier et recevoir des connexions ou des requêtes HTTPS vers et depuis Looker. Pour cela, vous pouvez utiliser une plate-forme cloud, comme Heroku, comme illustré dans l'exemple suivant, ou vous pouvez utiliser n'importe quelle plate-forme répondant aux exigences mentionnées ci-dessus.

Configurer un serveur Hub d'action local

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

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

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

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

   heroku login
   heroku create
   git push heroku
   

3. Heroku renverra l'URL publique qui héberge maintenant le hub d'action pour vous. Accédez à l'URL ou exécutez heroku logs pour vérifier que le hub d'action est en cours d'exécution. Si vous oubliez l'URL publique, vous pouvez exécuter ce qui suit 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 la ligne de commande, définissez l'URL de base de votre Hub d'actions:

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

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

   heroku config:set ACTION_HUB_LABEL="Your Action Hub"
   

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

   heroku run yarn generate-api-key
   

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

   yarn generate-api-key
   

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

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

   heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
   

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

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

   • En bas de la liste des actions, cliquez sur Ajouter un hub d'action.
   • Saisissez l'URL Action Hub 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 pour inclure le paramètre tags approprié.

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

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

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

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

Tester les actions au niveau des cellules

Configurez un champ LookML avec les balises appropriées pour votre action. Dans votre instance Looker, exécutez une requête 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 vous recevez des erreurs, vous devrez actualiser complètement le tableau de données après avoir corrigé ces erreurs.

• Si votre action est effectuée sans erreur, vous pouvez publier votre action.
• Si vous souhaitez continuer à héberger votre action en privé, vous pouvez la publier dans votre hub d'action privé.
• Si vous souhaitez publier votre action afin qu'elle soit utilisée par tous les clients Looker, consultez la section Publier sur le Centre d'action Looker.

Publier et activer une action personnalisée

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

• Publier sur Looker Action Hub: votre action est ainsi disponible pour tous les utilisateurs de Looker.
• Publication sur un serveur de hub d'action privé: 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 sur Looker Action Hub

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

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

1. Saisissez la commande suivante :

   git push <your fork> <your development branch>
   

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

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

   Looker va examiner 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 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 déployé, le code sera disponible pour tous les clients Looker.

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

Publication sur un serveur de hub d'action privé

Si certaines de vos actions personnalisées sont privées pour votre entreprise ou votre cas d'utilisation, ne les ajoutez pas au dépôt looker-open-source/actions. À la place, créez un hub d'action privé en utilisant le même framework Node.js que pour tester votre action.

Vous pouvez configurer votre serveur de hub d'action interne sur votre propre infrastructure ou à l'aide d'une plate-forme d'application cloud (par exemple, Heroku). N'oubliez pas de copier l'Action Hub Looker sur votre serveur d'actions privé avant le déploiement.

Configurer 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 fournit des informations sur les balises obligatoires pour le service, le cas échéant.

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

En revanche, le service Twilio Send Message (Envoyer un message avec Twilio) envoie un message à une liste de numéros de téléphone. Il nécessite une requête incluant un champ de numéro de téléphone et utilise le paramètre tags pour identifier le champ contenant 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 ;;
}

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

Fournir des données avec une action

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

• Fournir une cellule de données
• Fournir l'intégralité d'un tableau de bord ou d'une requête (à partir d'un aperçu ou d'une exploration)

Fournir des données mobiles

Les actions au niveau du champ sont indiquées sur la page Actions du panneau Admin par une description qui indique "Cette action peut être utilisée avec des champs" ou avec la mention Oui dans la colonne Utilisation autorisée des champs de la liste des services intégrés.

Les actions au niveau du champ sont conçues pour fournir une cellule de données au service spécifié. Leur fonctionnement est semblable à celui des actions sur les données, à la différence qu'elles sont diffusées via l'API Looker Action. Au lieu de définir un paramètre LookML action pour une dimension ou une mesure, vous devez configurer votre modèle LookML en taguant les champs pertinents avec les informations fournies dans la colonne Balises pour cette action de la liste des services intégrés.

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

1. Affichez les données que vous souhaitez transmettre via un style, un tableau de bord ou une fonctionnalité Explorer. Si le service indique "Action possible avec les requêtes comportant un champ balisé", votre requête ou l'une des tuiles du tableau de bord doit inclure un ou plusieurs champs avec les balises requises.

2. Le champ balisé dans chaque cellule de la vignette "Looker", "Tableau de bord" ou "Explorer" contient une liste déroulante, indiquée par des points de suspension (...). Cliquez sur les points de suspension pour afficher les actions disponibles pour ce lien.

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

Fournir des données de tableau de bord ou de requête

Sur la page Actions du panneau Admin, les actions au niveau des requêtes sont accompagnées de la description "Cette action peut être utilisée avec des requêtes comportant un champ associé à la balise..." ou "L'action peut être utilisée avec n'importe quelle requête". Conformément à la colonne Envoi ou planification de la liste des services intégrés, vous pouvez fournir l'option Chaque ligne (dans un affichage ou une exploration). Les actions au niveau de la requête sont conçues pour fournir l'ensemble des résultats de requête d'une exploration ou d'un aperçu au service spécifié.

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

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

Pour proposer un look ou une exploration, consultez la page Présentation de l'affichage et des explorations.

Pour accéder aux tableaux de bord, consultez les pages de documentation Fournir d'anciens tableaux de bord et Planifier et envoyer des tableaux de bord.